 TechNet Magazine March 2008

TechNet Magazine March 2008

Sonderbeitrag: Windows Server 2008: Einblick in die Änderungen am Windows Server 2008-Kernel

Lassen Sie sich die wichtigsten Änderungen am Windows Server 2008-Kernel, die die Zuverlässigkeit, die Leistung und die Skalierbarkeit verbessern, im Detail vorstellen. Finden Sie heraus, auf welche Weise Windows Server 2008 Threadpools besser nutzt, die Wiederherstellung nach Hardwarefehlern optimiert, die Virtualisierung mit Hyper-V verbessert und vieles mehr.

Mark Russinovich Sonderbeitrag: Windows Server 2008: Neuerungen in Active Directory-Domänendiensten

Mit Windows Server 2008 werden einige wesentliche Verbesserungen für Active Directory-Domänendienste eingeführt. Erhalten Sie einen Einblick, wie Domänencontroller ohne Schreibzugriff und Windows Server Core die Sicherheit in Ihrer Umgebung verbessern, wie der neue Server-Manager und die überarbeitete Sicherung die Verwaltung vereinfachen und wie die neuen Überwachungstools bei der Sicherstellung der Einhaltung von Richtlinien helfen.

Gil Kirkpatrick Sonderbeitrag: Windows Server 2008: Erste Schritte mit IIS 7.0

IIS 7.0 steckt voller neuer Features – zu viele für die Vorstellung in einem einzigen Artikel. Die neue Version baut auf dem stabilen, sicherheitsbezogenen Design von IIS 6.0 auf und bietet Verbesserungen, die die Verwaltbarkeit und Erweiterbarkeit der Plattform erheblich verbessern. Erhalten Sie eine Übersicht über die wichtigsten Änderungen in IIS 7.0.

Isaac Roybal Sonderbeitrag: Windows Server 2008: Richtliniengesteuerter Netzwerkzugriff mit Windows Server 2008

Wie ermöglichen Sie Netzwerkzugriff für diejenigen, die ihn benötigen, ohne die Sicherheit zu gefährden? Erfahren Sie, wie Sie mit neuen Technologien in Windows Server 2008, wie z. B. Windows-Firewall mit erweiterter Sicherheit sowie Netzwerkzugriffsschutz, einen richtlinienbasierten Ansatz zum Erreichen dieses Ziels implementieren können.

Ian Hameroff and Amith Krishnan Sonderbeitrag: Windows Server 2008: Konfigurieren von Rollen mit Server-Manager

Ein DNS-Server ist nicht zwangsläufig ein Druckserver. Ein Ansatz von Windows Server 2008 für die Verbesserung von Sicherheit und Verwaltbarkeit ist die Vereinfachung von Serverrollen, sodass Sie problemlos nur die Tools und Dienste installieren können, die Sie benötigen, und nicht mehr. Im Folgenden finden Sie eine Einführung in das Konfigurieren von Rollen und die Vereinfachung von Bereitstellungen mittels Server-Manager.

Byron Hynes Sonderbeitrag: Windows Server 2008: Bereitstellen von Windows Server 2008 mit System Center

Früher installierten Serveradministratoren Windows Server manuell mit der CD oder DVD und verbrachten dann mehrere Stunden damit, den Server zu konfigurieren. Mit der Veröffentlichung von System Center Configuration Manager 2007 und dem neuen Microsoft Deployment Toolkit können Serveradministratoren jetzt die gleichen Tools verwenden, die Desktopadministratoren schon seit Jahren nutzen, um Bereitstellungen zu automatisieren.

Tim Mintner Sonderbeitrag: Windows Server 2008: Überwachung und Einhaltung gesetzlicher Bestimmungen in Windows Server 2008

Zu den wichtigsten Verantwortlichkeiten heutiger IT-Abteilungen gehört das Überwachen von Änderungen. Dieser Vorgang trägt wesentlich zu Verständnis und Verwaltung von Systemen und Daten in einer verteilten Umgebung bei. Dieser Artikel befasst sich mit häufigen Herausforderungen, Einhaltung von Richtlinien und Vorschriften, den Grundlagen der Überwachung sowie der Erstellung einer umfassenden Überwachungsstrategie.

Rob Campbell and Joel Yoker Mitteilung der Redaktion: Willkommen bei Windows Server 2008

Joshua Hoffman Briefe: Leser sagen ihre Meinung

Toolbox: Neue Produkte für IT-Experten

Greg Steen Schwerpunkt Dienstprogramme: Windows Server-Logozertifizierung

Microsoft hat das Programm „Works with Windows Server 2008“ ins Leben gerufen, um ISVs und Kunden beim Beurteilen der Anwendungskompatibilität zu unterstützen. Im Folgenden werden die im Rahmem des Programms bereitgestellten, kostenlosen Testtools besprochen, die Ihnen dabei helfen sicherzustellen, dass Anwendungen eine verlässliche Funktionalität bieten.

Venkat Krishnamachari The Cable Guy: Migrieren des Intranets zu IPv6 mit ISATAP

Vorbereitung auf die Migration zu IPv6 In diesem Cable Guy-Artikel wird erläutert, wie Sie mithilfe einer IPv6-Übergangstechnologie IPv6-Konnektivität erhalten und zu einem IPv6-fähigen Intranet migrieren.

Joseph Davies Windows PowerShell: Forschrittsbericht

Das Einfügen von Fortschrittsfeedback in Ihre Skripts empfiehlt sich generell sowohl für unkonzentriert als auch für konzentriert arbeitende Benutzer. Im Folgenden erhalten Sie alle erforderlichen Informationen zur Fortschrittsangabe in Windows PowerShell.

Don Jones Hey, Scripting Guy!: Spielen mit dem Shellobjekt

Die Scripting Guys zeigen, wie Sie das Datum der letzten Änderung einer Datei mit einem Skript und dem Shellobjekt ändern können.

The Microsoft Scripting Guys Sicherheit auf dem Prüfstand: Verwenden des SCW unter Windows Server 2008

Sie haben sicher bereits von dem neuen Server-Manager-Tool in Windows Server 2008 gehört. Der Sicherheitskonfigurations-Assistent (Security Configuration Wizard, SCW) steht jedoch ebenfalls weiterhin zur Verfügung. Hier erfahren Sie, warum die Verwendung von SCW für Sie interessant sein könnte.

Jesper M. Johansson Die Desktopdateien: Man kann nie zu reich oder zu dünn sein

Thin Clients kommen und gehen, aber es scheint immer ein Szenario zu geben, das von ihnen profitieren kann. Heute werden sie in Kiosken und in Umgebungen verwendet, in denen lediglich Funktionen zum Webbrowsen erforderlich sind. Hier erfahren Sie, wie Sie alte Hardware mit einer Clientanwendung einem neuen Zweck zuführen können, um etwas Geld zu sparen.

Wes Miller Berichte aus der Praxis: Vorbereitung auf IT 2.0

Hier sehen Sie, warum es wichtig ist, aus der Vergangenheit zu lernen, um die Herausforderungen zu meistern, die die Zukunft für IT bereithält.

Romi Mahajan Windows Confidential: Wie aus Betaversionen Release Candidates wurden

Raymond Chen beschreibt den faszinierenden Hintergrund dessen, wie sich Benennungskonventionen für nicht endgültige Veröffentlichungen geändert haben. Außerdem appelliert er an Unternehmen, Betatests ernster zu nehmen.

Raymond Chen


 Sonderbeitrag: Windows Server&#160;2008: Einblick in die &#196;nderungen am Windows Server&#160;2008-Kernel
Sonderbeitrag: Windows Server 2008 Mark Russinovich

Einblick in die Änderungen am Windows Server 2008-Kernel
Kurz zusammengefasst:
  • Speicherverwaltung und SMB 2.0
  • NTFS-Selbstreparaturfunktion, Windows Hardware Error Architecture und Treiberüberprüfung
  • Skalierbarkeit mit E/A-Abschlussports, Threadpools und NUMA
  • Hyper-V-Virtualisierung

Windows Server 2008 ist die aktuelle Version der Serverplattform von Microsoft und enthält Änderungen auf Systemebene, die von der Speicherverwaltung
bis zur Threadplanung und vom Netzwerk bis zur Sicherheit (um nur eine kleine Auswahl zu nennen) jeden funktionalen Bereich des Betriebssystems betreffen.
Da Windows Server® 2008 den gleichen Kernel wie Windows Vista® SP1 besitzt, enthält es viele der Verbesserungen, die ich in folgenden früheren TechNet Magazin-Artikeln bereits behandelt habe: „Einblick in den Windows Vista-Kernel“, Teil 1 bis 3 (Februar, März und April 2007) und „Die Benutzerkontensteuerung von Windows Vista“ (Juni 2007). Nur sehr wenige der Features, die ich in diesen Artikeln beschrieben habe, sind ausschließlich auf Clients ausgerichtet und nicht in Windows Server 2008 enthalten, wie z. B. SuperFetch, ReadyBoost, ReadyDrive, ReadyBoot und der Multimediaklassen-Planungsdienst (Multimedia Class Scheduler Service, MMCSS).
Statt erneut auf die wichtigen Änderungen des Kernels einzugehen, die in Windows Vista eingeführt wurden und auch in Windows Server 2008 enthalten sind (z. B. die E/A-Priorisierung, die neue Startarchitektur, BitLockerTM, Codeintegrität und obligatorische Integritätsebenen), werde ich mich auf die wichtigsten Änderungen konzentrieren, die ich in diesen Artikeln nicht behandelt habe, wie z. B. die Änderungen, die sich auf Zuverlässigkeit, Leistung und Skalierbarkeit sowie auf Hyper-VTM, die neue Hypervisor-Computervirtualisierungstechnologie von Microsoft, beziehen.
Genau wie in den vorherigen Artikeln werde ich mich auch in diesem Artikel auf den Betriebssystemkernel „Ntoskrnl.exe“ und auf eng damit verbundene Systemkomponenten beschränken. So werde ich beispielsweise nicht auf Änderungen an Installation (WIM oder Windows® Imaging Format und komponentenbasierte Wartung), Verwaltung (Verbesserungen der Gruppenrichtlinie und von Active Directory®), allgemeiner Diagnose und Überwachung (Windows-Diagnose-Infrastruktur oder WDI), wichtiger Netzwerkfunktionalität (die neue Firewall und TCP/IP-Implementierung), Server Core oder Serverrollen eingehen.
Arbeiten mit Mehrprozessorsystemen
Eine der konkreten Änderungen am System besteht darin, dass Windows Server 2008 nur eine für Mehrprozessorsysteme konzipierte Version des Kernels enthält. Früher verwendete Windows eine Version, die speziell für Einzelprozessoren in Computern mit einer einzigen CPU vorgesehen war, weil sich mit dieser Version eine etwas bessere Leistung erzielen ließ, indem der Synchronisierungscode vermieden wurde, der nur in Mehrprozessorumgebungen benötigt wird. Als die Hardware immer schneller wurde, ist der durch die Optimierungen erzielte Leistungsvorteil so minimal geworden, dass auf ihn verzichtet werden kann, und heute besitzen die meisten Serversysteme mehrere Prozessoren, wodurch eine Version für Einprozessorsysteme überflüssig ist.
Abbildung 1 zeigt die Varianten des Windows Server 2008-Kernels, wobei die Version, die in einem System verwendet wird, jeweils davon abhängig ist, ob die Debugversion (Checked) oder die Einzelhandelsversion des Betriebssystems vorliegt, ob es sich um die 32-Bit-Installation oder die 64-Bit-Installation (Itanium, Intel 64 oder AMD64) handelt und (im Falle einer 32-Bit-Installation) ob das System physischen Speicher von mehr als 4 GB besitzt oder Datenausführungsverhinderung (Data Execution Prevention, DEP) unterstützt. Windows Server 2008 ist auch das letzte Windows Server-Betriebssystem, von dem noch erwartet wird, eine 32-Bit-Version zu bieten.
Figure 1 Kernelvarianten von Windows Server 2008 (Close Figure 1)

Kernel | 32-Bit | 64-Bit
Mehrprozessor | Ja | Ja
Mehrprozessor Checked | Ja | Ja
Mehrprozessor Physical Address Extension (PAE) | Ja | Nein
Mehrprozessor PAE Checked | Ja | Nein
Bei jeder Version von Windows Server steht die Leistungsverbesserung wichtiger Serverszenarios wie z. B. Dateiserverfunktionalität, Netzwerk-E/A und Speicherverwaltung im Vordergrund. Darüber hinaus bietet Windows Server 2008 mehrere Änderungen und neue Features, die es Windows ermöglichen, neue Hardwarearchitekturen zu nutzen, sich an Netzwerke mit hoher Latenz anzupassen und Engpässe zu beseitigen, die in früheren Windows-Versionen die Leistung beeinträchtigt haben. Dieser Abschnitt befasst sich mit Verbesserungen des Speichermanagers und des E/A-Systems und stellt das neue Netzwerkdateisystem SMB 2.0 vor.

Speicherverwaltung
Experiment: Anzeigen großer Datenträger-E/As
Sie können ein Dateisystemüberwachungstool wie z. B. TechNet Sysinternals Process Monitor (technet.microsoft.com/sysinternals/bb896645.aspx) verwenden, um auf einem Windows Server 2008-System nach großen Datei-E/A-Vorgängen zu suchen.
Es gibt mehrere Möglichkeiten, große Ein- und Ausgaben zu generieren. Wenn Sie ein zweites System besitzen, auf dem entweder Windows Vista Service Pack 1 oder Windows Server 2008 ausgeführt wird, können Sie auf dem Server das Überwachungstool „Process Monitor“ ausführen und die Dateikopiervorgänge zum zweiten System überwachen. Sie können große Auslagerungsdatei-E/As normalerweise auch generieren, indem Sie ein speicherintensives Programm ausführen, das den Speichermanager dazu bringt, Seiten in die Auslagerungsdatei zu schreiben.
Abbildung A zeigt das Überwachungstool „Process Monitor“ nach der Ausführung eines speicherintensiven Programms auf einem Windows XP-System. Im Optionsmenü von Process Monitor ist die Option „Enable Advanced Output“ (Erweiterte Ausgabe aktivieren) ausgewählt. Außerdem ist ein Filter eingestellt, der bewirkt, dass nur Schreibvorgänge in die Auslagerungsdatei „pagefile.sys“ angezeigt werden. Die Detailspalte zeigt, dass die Schreibausgaben 64 KB groß sind.
Abbildung A
Wenn Sie dieselben Schritte unter Windows Server 2008 ausführen, wird mit größter Wahrscheinlichkeit etwas Ähnliches wie in Abbildung B angezeigt, in der zu sehen ist, dass die meisten Schreibausgaben ungefähr 1 MB groß sind.
Abbildung B

Der Speichermanager enthält in Windows Server 2008 mehrere Leistungsverbesserungen. So gibt er beispielsweise weniger und größere Datenträger-E/As als unter Windows Server 2003 aus, wenn er Daten aus der Auslagerungsdatei abruft oder an zugeordneten Dateien Vorauslese-E/As durchführt. Die größeren Datei-E/As werden durch Änderungen im E/A-System erleichtert, durch die eine E/A-Größenbegrenzung von 64 KB aufgehoben wird, die seit der ersten Version von Windows NT® vorhanden war.
Sie müssen auch beachten, dass Datenlesevorgänge für Vorauslesevorgänge (spekulative Lesevorgänge) von zugeordneten Dateien durch den Cache-Manager unter Windows Server 2008 in der Regel zwei Mal so groß wie unter Windows Server 2003 sind und direkt in die Standbyliste (den Code- und Datencache des Systems) geleitet werden. Dieses Verhalten erübrigt die Anforderung an den Cache-Manager, virtuellen Arbeitsspeicher zuzuordnen und die Daten in den Arbeitssatz des Systems (den vom Speichermanager dem System zugewiesenen Speicher) einzulesen, was dazu führen könnte, dass sonstige Codes oder Daten, die verwendet werden, unnötigerweise aus dem Arbeitssatz entfernt werden.
Der Speichermanager führt auch beim Schreiben von Daten in die Auslagerungsdatei größere Ein- und Ausgaben durch. Während Windows Server 2003 oft Schreibvorgänge ausführt, die weniger als 64 KB umfassen, gibt der Speichermanager unter Windows Server 2008 normalerweise Schreibvorgänge aus, die 1 MB groß sind.
Die größeren Schreibvorgänge verringern nicht nur die Fragmentierung innerhalb der Auslagerungsdatei, sondern verbessern durch das Verringern der Anzahl von Schreibvorgängen in die Auslagerungsdatei auch die Leistung. Dies wiederum führt zu einer Verringerung der Anzahl von Lesevorgängen und Datenträgersuchvorgängen, die zum Zurücklesen mehrerer Seiten erforderlich sind, da sie in den meisten Fällen aneinander angrenzen.
Der Speichermanager versucht auch, andere geänderte Seiten zu schreiben, die nicht weit von der Seite entfernt sind, die in den Adressraum des besitzenden Prozesses geschrieben wird, und zielt dabei auf denjenigen Bereich der Auslagerungsdatei ab, in dem sich bereits andere angrenzende Seiten befinden. Dies minimiert ebenfalls die Fragmentierung und kann die Leistung verbessern, weil Seiten, die möglicherweise noch in die Auslagerungsdatei geschrieben werden sollen, bereits dorthin geschrieben wurden. Darüber hinaus verringert dies die Anzahl der Auslagerungslesevorgänge, die erforderlich sind, um einen Bereich angrenzender Prozessseiten in die Datei zu schreiben. Weitere Informationen dazu, wie der Speichermanager große Ein- und Ausgaben verwendet, finden Sie in der Randleiste „Experiment: Anzeigen großer Datenträger-E/As“.

SMB 2.0
Das SMB-Remotedateisystemprotokoll (Server Message Block), das auch als CIFS (Common Internet File System) bezeichnet wird, ist die Grundlage der Windows-Dateiserverfunktionalität, seit die Dateiserverfunktionalität in Windows eingeführt wurde. Im Verlauf der letzten Jahre haben die Entwurfseinschränkungen von SMB die Leistung der Windows-Dateiserverfunktionalität sowie die Fähigkeit, neue lokale Dateisystemfeatures zu nutzen, eingeschränkt. So beträgt beispielsweise die maximale Puffergröße, die in einer einzigen Nachricht übertragen werden kann, ungefähr 60 KB, und SMB 1.0 konnte symbolische Verknüpfungen auf der Seite des NTFS-Clients, die in Windows Vista und Windows Server 2008 hinzugefügt wurden, nicht erkennen.
In Windows Vista und Windows Server 2008 wurde SMB 2.0 eingeführt. SMB 2.0 ist ein neues Protokoll für die Remotedateiserverfunktionalität, das Windows verwendet, wenn es sowohl vom Client als auch vom Server unterstützt wird. SMB 2.0 verarbeitet nicht nur clientseitige symbolische Verknüpfungen und andere NTFS-Verbesserungen korrekt, sondern verwendet auch Batchverarbeitung, um die Anzahl der Nachrichten zu minimieren, die zwischen einem Client und einem Server ausgetauscht werden. Batchverarbeitung kann bei Netzwerken mit hoher Latenz wie z. B. Fernnetzen (wide-area networks, WANs) den Durchsatz verbessern, weil sie ermöglicht, mehr Daten gleichzeitig zu übertragen.
Während SMB 1.0 Ein- und Ausgaben für eine einzige Datei sequenziell durchgeführt hat, implementiert SMB 2.0 E/A-Pipelining, wodurch SMB 2.0 für dieselbe Datei mehrere gleichzeitige Ein- und Ausgaben durchführen kann. SMB 2.0 misst, wie viel Serverspeicher ein Client für die verbleibenden Ein- und Ausgaben verwendet, um zu ermitteln, wie tief dieses Pipelining gehen muss.
Aufgrund der Änderungen am E/A-Speichermanager und am E/A-System von Windows, der automatischen Optimierung des TCP/IP-Empfangsfensters sowie der Verbesserungen am Dateikopiermodul ermöglicht SMB 2.0 enorme Durchsatzverbesserungen und Verkürzungen der Dateikopierzeiten bei umfangreichen Übertragungen. Da beide Betriebssysteme SMB 2.0 implementieren, hat der Einsatz von Windows Server 2008-Dateiservern mit Windows Vista-Clients zur Folge, dass SMB 2.0 verwendet werden kann und diese Leistungsvorteile genutzt werden können.

Zuverlässigkeit durch die NTFS-Selbstreparaturfunktion
Da Zuverlässigkeit eine wichtige Servereigenschaft ist, bietet Windows Server 2008 verschiedene Verbesserungen, die Administratoren helfen, ihre Server reibungslos zu betreiben. Zu diesen Verbesserungen zählen die Online-NTFS-Konsistenzreparatur, eine neue Infrastruktur zur Hardwarefehlerberichterstattung und Erweiterungen der Treiberüberprüfung.
Bei den heutigen Speichergeräten, die einen Speicherplatz von mehreren Terabyte bieten, kann das Offlineschalten eines Volumes zur Durchführung einer Konsistenzüberprüfung einen Dienstausfall von mehreren Stunden zur Folge haben. Da erkannt wurde, dass viele Datenträgerbeschädigungen auf eine einzige Datei oder einen einzigen Abschnitt von Metadaten zurückzuführen sind, implementiert Windows Server 2008 ein neues NTFS-Selbstreparaturfeature, damit Schäden repariert werden können, während das betreffende Volume online bleibt.
Wenn NTFS eine Beschädigung erkennt, verhindert es den Zugriff auf die beschädigten Dateien und erstellt einen Systemarbeitsthread, der an den beschädigten Datenstrukturen CHKDSK-artige Korrekturen vornimmt und danach den Zugriff auf die reparierten Dateien freigibt. Während dieses Vorgangs kann auf andere Dateien weiterhin ganz normal zugegriffen werden, wodurch die Dienstunterbrechung minimal gehalten wird.

WHEA-Infrastruktur
Die WHEA-Infrastruktur (Windows Hardware Error Architecture), die in Windows Server 2008 enthalten ist, verspricht, die Verwaltung von Hardwarefehlern zu vereinfachen und proaktive Reaktionen auf Fehler zu ermöglichen, die nicht schwerwiegend sind. Da Server oft strenge Betriebszeitgarantien erfüllen müssen, ist es von entscheidender Bedeutung, bei derartigen Systemen Fehler rechtzeitig erkennen und auf sie reagieren zu können.
Eine mit OCA (Online Crash Analysis) vorgenommene Analyse der bei Microsoft gemeldeten Abstürze zeigt, dass ungefähr 10 Prozent aller Betriebssystemabstürze auf einen Hardwarefehler zurückzuführen sind, aber es war schwer oder unmöglich, die Hauptursache dieser Abstürze zu ermitteln, da bei einem Absturz nicht genügend Fehlerinformationen von der Hardware bereitgestellt und aufgezeichnet werden. Darüber hinaus hat Windows vor Windows Server 2008 keine integrierte Unterstützung für eine Überwachung der Integrität von Geräten, keine implementierte Wiederherstellung und keine Warnung vor einem bevorstehenden Ausfall bereitgestellt. Dies liegt daran, dass Hardwaregeräte kein gemeinsames Fehlerformat verwenden und keine Fehlerverwaltungssoftware unterstützen.
WHEA stellt einen einheitlichen Mechanismus zur Ermittlung der Fehlerquelle und zur Fehlerberichterstattung für Plattformgeräte einschließlich Prozessoren, Speichern, Caches und Bussen wie z. B. PCI und PCI Express bereit. Um dies zu ermöglichen, wird die in Abbildung 2 gezeigte Architektur implementiert, in deren Kern sich eine Kernel-API befindet, die von Fehlerquellen aufgerufen wird, um Fehler zu melden. Die API setzt voraus, dass für alle Fehler dasselbe Format verwendet wird, und protokolliert Fehler mithilfe von ETW-Ereignissen (Event Tracing for Windows, Ereignisablaufverfolgung für Windows). Schwerwiegende Fehler werden erst nach einem Neustart protokolliert.
Abbildung 2 Infrastruktur der WHEA-Fehlerberichterstattung
Abbildung 2 Infrastruktur der WHEA-Fehlerberichterstattung
ETW wurde in Windows 2000 eingeführt, und die Verwendung von ETW durch WHEA macht es für Hardware- und Softwarehersteller leicht, Anwendungen zur Gerätediagnoseverwaltung zu entwickeln, die WHEA-Ereignisse verwenden. Wenn ein Ereignis schwerwiegend genug ist, um zu einem Systemabsturz zu führen, stellt WHEA sicher, dass die Aufzeichnung des schwerwiegenden Fehlers in der Absturzabbilddatei gespeichert wird, damit die Administratoren die Hauptursache des Absturzes bestimmen können.
Ein weiterer wichtiger Bestandteil von WHEA ist der plattformspezifische Hardwarefehlertreiber (Platform Specific Hardware Error Driver, PSHED), der sich in der Datei „%Systemroot%\System32\Pshed.dll“ befindet. Der Kernel stellt eine Verbindung zum PSHED her und dient als Schnittstelle zur Plattform- und Firmwarehardware, wobei er praktisch als Übersetzungsschicht zwischen ihren Fehlerbenachrichtigungen und der WHEA-Fehlerberichterstattungs-API fungiert. Für jede Plattformarchitektur (x86, x64, Itanium) wird von Microsoft ein PSHED bereitgestellt, der ein Plug-In-Modell zur Verfügung stellt, damit Hardwareanbieter und -hersteller das Standardverhalten durch ein für ihre Plattformen spezifisches Verhalten ersetzen können.
Hinzu kommt, dass Komponenten des Systems, die als Schnittstelle zu anderen Fehlerquellen wie z. B. Gerätetreibern, der Hardwareabstraktionsschicht (Hardware Abstraction Layer, HAL) und dem Kernel dienen, LLHEHs (Low-Level Hardware Error Handlers) implementieren können, die eine Fehlerbedingung anfänglich verarbeiten. Ein LLHEH hat die Aufgabe, Fehlerinformationen aus dem Gerät zu extrahieren, den PSHED zu benachrichtigen, um diesem zu ermöglichen, zusätzliche Plattformfehlerinformationen zu sammeln, und anschließend die WHEA-Fehlerberichterstattungs-API des Kernels aufzurufen.

Treiberüberprüfung
Die Treiberüberprüfung, ein leistungsfähiges Tool zum Aufspüren fehlerhafter Gerätetreiber und fehlerhafter Hardware, ist seit Windows 2000 in jeder Windows-Version enthalten. Administratoren konfigurieren die Treiberüberprüfung („%Systemroot%\System32\Verifier.exe“) normalerweise zu dem Zweck, das Verhalten von Gerätetreibern, die im Verdacht stehen, Systemabstürze zu verursachen, genau zu überwachen. Die Treiberüberprüfung fängt unzulässige Treibervorgänge ab, sodass eine Absturzabbilddatei den Schuldigen eindeutig identifiziert.
Ein Nachteil früherer Implementierungen der Treiberüberprüfung besteht darin, dass die meisten Konfigurationsänderungen einen Neustart des Systems erfordern, was bei einem Produktionsserver natürlich nicht wünschenswert ist. Die Windows Server 2008-Implementierung der Treiberüberprüfung verbessert diesen Prozess, indem bei den nützlichsten Überprüfungen die Voraussetzung eines Neustarts abgeschafft wurde, wodurch es möglich ist, einen problembehafteten Server zu reparieren, ohne ihn neu starten zu müssen.
Darüber hinaus führt die Treiberüberprüfung drei neue Überprüfungen ein, die in Abbildung 3 zu sehen sind. Durch „Sicherheitsüberprüfungen“ wird sichergestellt, dass Gerätetreiber für jene Objekte, die sie als Schnittstelle zu Anwendungen verwenden, sichere Berechtigungen festlegen. Durch „Ausstehende E/A-Anforderungen erzwingen“ wird die Sicherheit eines Treibers bei asynchronen E/A-Vorgängen getestet, die nicht erst nach einer Verzögerung, sondern sofort abgeschlossen werden. Durch „Verschiedene Überprüfungen“ wird nach Treibern gesucht, die fälschlicherweise gerade verwendete Ressourcen freisetzen, WMI-Registrierungs-APIs (Windows Management Instrumentation, Windows-Verwaltungsinstrumentation) falsch verwenden und Ressourcenhandles verlieren.
Abbildung 3 Treiberüberprüfung mit aktivierten Windows Server 2008-Optionen
Abbildung 3 Treiberüberprüfung mit aktivierten Windows Server 2008-Optionen

Skalierbarkeit
Skalierbarkeit bezeichnet die Fähigkeit eines Betriebssystems oder einer Anwendung, mehrere Prozessoren und viel Speicher effektiv nutzen zu können. Mit jeder Version von Windows wird die Skalierbarkeit verbessert, indem die Verwendung von Sperren, die die Parallelität bei Mehrprozessoren verringern, minimiert oder eliminiert wird. In dieser Hinsicht bildet auch Windows Server 2008 keine Ausnahme.
Eine relativ kleine, aber bedeutende Verbesserung stellt der Code dar, der den Zeitgeberablauf ausführt. Dieser verwendet keine Verteilersperre mehr (eine von allen Synchronisierungsvorgängen niedriger Ebene verwendete systemweite Zeitplanungssperre). Die daraus resultierende Verringerung des CPU-Synchronisierungsaufwands ermöglicht Windows Server 2008-Terminalserversystemen, ungefähr 30 Prozent mehr gleichzeitige Benutzer zu unterstützen als Windows Server 2003.
Weitere Verbesserungen der Skalierbarkeit in Windows Server 2008 umfassen Abschlussportverbesserungen, eine neue Threadpoolimplementierung, eine effizientere Verwendung von NUMA-Hardware (Non-Uniform Memory Access) sowie die dynamische Systempartitionierung.

Verbesserte E/A-Abschlussportverarbeitung
Die meisten skalierbaren Windows-Serveranwendungen einschließlich IIS, SQL Server® und Exchange Server verlassen sich darauf, dass eine als „Abschlussport“ bezeichnete Windows-Synchronisierungs-API beim Ausführen von E/A-Vorgängen das Wechseln zwischen mehreren Ausführungsthreads minimiert. Dies wird dadurch erreicht, dass sie zunächst Benachrichtigungen über das Eintreffen neuer Anforderungen (z. B. Webserver-Clientverbindungen) einem Abschlussport zuordnen und einen Threadpool auf Benachrichtigungen warten lassen. Wenn eine Anforderung eintrifft, plant Windows einen Thread, der dann in der Regel andere E/A-Vorgänge ausführt, wie z. B. das Lesen einer Webseite von einem Datenträger und das Senden dieser Webseite an den Client, um die Anforderung abzuschließen.
Damit derselbe Thread so schnell wie möglich wieder dazu übergehen kann, auf weitere Clientanforderungen zu warten, führt der Thread asynchron Ein- und Ausgaben durch und ordnet E/A-Abschlüssse dem Abschlussport zu. Danach beginnt der Thread wieder, am Abschlussport zu warten, der den Thread plant, sobald entweder eine neue Anforderung eintrifft oder eine der Ein- und Ausgaben abgeschlossen ist. Auf diese Weise bleibt auf einer CPU derselbe Thread aktiv, der abwechselnd Clientanforderungen verarbeitet und am Abschlussport wartet.
Ein Nachteil der Abschlussportimplementierung früherer Windows-Versionen besteht darin, dass beim Abschluss einer Ein- und Ausgabe das E/A-System den Thread, der die Ein- und Ausgabe durchführte, anwies, sofort ein wenig Abschlussverarbeitung durchzuführen, unabhängig davon, womit er gerade beschäftigt war. Wenn andere Threads aktiv waren, hatte dies oft zur Folge, dass der Planer einen aktiven Thread verdrängte und einen Kontextwechsel zum ausgebenden Thread durchführte.
Windows Server 2008 vermeidet diese Kontextwechsel, indem es die Abschlussverarbeitung zurückstellt, bis der nächste Thread am Abschlussport wartet, dem die Ein- und Ausgabe zugeordnet ist. Dadurch wird selbst dann, wenn ein anderer Thread als Nächstes am Abschlussport wartet, zuerst die Abschlussverarbeitung durchgeführt, bevor ein anderer Code ausgeführt wird, und der Planer muss nicht zum ausgebenden Thread wechseln. Diese Minimierung von Kontextwechseln kann die Skalierbarkeit stark belasteter Serveranwendungen beträchtlich verbessern.

Effizientere Threadpools
Da es schwer sein kann, Anwendungen zu schreiben, die mehrere CPUs nutzen, wurden in Windows XP Arbeitsthreadpools eingeführt, eine Infrastruktur mit zugehöriger API, die die Details der Ausführung kleiner Arbeitseinheiten über mehrere CPUs hinweg zusammenfasst. Eine Anwendung teilt der Threadpool-API die Arbeitsschritte mit, und die Threadpool-API führt diese Arbeitsschritte danach mithilfe einer Reihe von Threads durch, die sie für jede CPU im System erstellt und verwaltet.
Das Ziel des Threadpools besteht darin, Kontextwechsel zu minimieren, indem dieselben Threads verwendet werden, um mehrere Arbeitsschritte hintereinander durchzuführen. Falls dies nicht möglich ist, weil einer der Threads dieses Pools bereits mit einer anderen Arbeit ausgelastet ist, wird der Arbeitsschritt mithilfe eines anderen Threads auf einer anderen CPU durchgeführt.
Die Threadpoolimplementierung von Windows Server 2008 nutzt die CPUs auf indirekte Weise besser, da sie von den Abschlussportverbesserungen profitiert. Zusätzlich nutzt sie die CPUs auf direkte Weise besser, da sie die Threadverwaltung so optimiert, dass Arbeitsthreads dynamisch kommen und gehen, wie sie gerade benötigt werden, um die Arbeitsauslastung einer Anwendung zu bewältigen. Darüber hinaus wurde der Kern der Infrastruktur in den Kernelmodus verlagert, wodurch die Anzahl der Systemaufrufe durch Anwendungen, die die API verwenden, minimiert wird. Außerdem macht es die neue API für Anwendungen einfacher, bestimmte Vorgänge (z. B. das Abbrechen von in die Warteschlange gestellten Arbeitsschritten beim Herunterfahren der Anwendung) durchzuführen.

NUMA-Optimierungen
Windows Server 2003 hat für NUMA-Computer Optimierungen im Threadplaner und im Speichermanager eingeführt, aber Windows Server 2008 fügt NUMA-Optimierungen im E/A-Manager hinzu und erweitert die NUMA-Optimierungen des Speichermanagers.
Bei NUMA-Systemen handelt es sich in der Regel um Mehrprozessorsysteme, bei denen der Speicher in Abhängigkeit davon, welcher Prozessor auf ihn zugreift, mit unterschiedlicher Latenz arbeitet (siehe Abbildung 4). Speicher wird in Knoten unterteilt, wobei die Latenzen zwischen CPUs und den Knoten variieren können und jede CPU als Bestandteil eines Knotens betrachtet wird, auf den sie am schnellsten zugreifen kann.
Abbildung 4 Beispiel eines NUMA-Systems
Abbildung 4 Beispiel eines NUMA-Systems
NUMA-Systeme (vor allem jene mit mehr als acht CPUs) sind oft kostengünstiger und in ihrer Leistung effizienter als UMA-Systeme (Uniform Memory Access). Während ein UMA-System Speicher für alle CPUs gleichermaßen verfügbar machen muss, kann ein NUMA-System dort, wo Speicher direkt mit einer CPU verbunden ist, Hochgeschwindigkeitsverbindungen implementieren und dort, wo Speicher und CPU weiter voneinander entfernt sind, kostengünstigere Verbindungen mit höherer Latenz einrichten.
Um bei einem NUMA-System eine effektive Skalierung durchzuführen, muss ein Betriebssystem oder eine Anwendung die Knotentopologie kennen, damit die Rechenarbeit in der Nähe jenes Speichers ausgeführt wird, der die Daten und den Code der Berechnungen enthält. So weist beispielsweise der Windows-Planer jedem Thread einen so genannten idealen Prozessor zu, bei dem es sich um jene CPU handelt, auf der der Planer den Thread immer auszuführen versucht. Diese Vorgehensweise erhöht die Wahrscheinlichkeit, dass Daten, die der Thread im Cache der CPU ablegt, bei jeder Ausführung des Threads für den Thread verfügbar sind.
In Windows Server 2003 erweitert der Planer dieses Konzept, indem er den Knoten, der den idealen Prozessor enthält, als idealen Knoten des Threads betrachtet und dann versucht, den Thread auf einer anderen CPU im idealen Knoten zu planen, falls der ideale Prozessor gerade damit ausgelastet ist, einen anderen Thread auszuführen. Der Speichermanager von Windows Server 2003 ist ebenfalls NUMA-fähig geworden und leitet, falls dies möglich ist, die Speicherzuordnungen eines Threads zum Speicher jenes Knotens, auf dem der Thread ausgeführt wird.
In Windows Server 2008 verteilt der Speichermanager die nicht ausgelagerten Speicherpuffer des Kernels (vom Kernel und von Gerätetreibern verwendeter Speicher für das Speichern von Daten, die mit Sicherheit im RAM bleiben) so über die Knoten hinweg, dass Zuordnungen aus jenem Speicher des Knotens kommen, von dem die Zuordnung ausgeht. System-PTEs (Page Table Entries, Seitentabelleneinträge) werden nicht, wie dies in Windows Server 2003 der Fall ist, aus einem beliebigen Knoten, sondern aus jenem Knoten zugeordnet, von dem die Zuordnung ausgeht, falls die Zuordnung eine neue Seitentabellenseite benötigt.
In Windows Server 2003 bevorzugt der Speichermanager dann, wenn ein Thread eine Speicherzuordnung vornimmt, jenen Knoten, auf dem der Thread zum Zeitpunkt der Zuordnung ausgeführt wird. Falls der Thread vorübergehend auf einem Knoten geplant wird, der nicht der ideale Knoten ist, gehen alle Zuordnungen, die in dieser Zeitspanne vorgenommen werden, vom nicht idealen Knoten aus. Aus diesem Grund kann dann, wenn der Thread schließlich auf seinem idealen Knoten ausgeführt wird, der Thread den im zugeordneten Speicher gespeicherten Daten oder Codes nicht so nahe sein, wie dies möglich wäre.
Um dies zu verbessern, bevorzugt der Speichermanager von Windows Server 2008 bei allen Zuordnungen eines Threads dessen idealen Knoten, auch wenn der Thread in der Nähe eines anderen Knotens ausgeführt wird. Der Speichermanager berücksichtigt auch automatisch die Latenzen zwischen Prozessoren und Knoten. Wenn also der ideale Knoten keinen verfügbaren Speicher besitzt, überprüft der Speichermanager daher jenen Knoten, der dem idealen Knoten am nächsten ist. Zusätzlich migriert der Speichermanager Seiten in seiner Standbyliste zum idealen Knoten eines Threads, wenn ein Thread auf den Code oder die Daten verweist.
Anwendungen, die ihr Zuordnungsziel kontrollieren wollen, können neue NUMA-Speicher-APIs verwenden, die es ihnen ermöglichen, einen bevorzugten Knoten für Speicherzuordnungen, Dateizuordnungsansichten und Dateizuordnungsobjekte festzulegen. Bei einer Zuordnung für eine Dateizuordnung überprüft der Speichermanager, ob vom Zuordnungsvorgang ein Knoten angegeben wird. Danach überprüft er, ob vom Dateizuordnungsobjekt ein Knoten angegeben wird. Falls beides nicht der Fall ist, verwendet er den idealen Knoten des Threads.
Vor Windows Server 2008 konnten der Interrupt und der zugehörige DPC (Deferred Procedure Call) für einen Speicher oder eine Netzwerk-E/A auf jeder beliebigen CPU ausgeführt werden, einschließlich der CPUs von Knoten, auf denen die Ein- und Ausgabe nicht gestartet wurde, was zur Folge haben konnte, dass sich die beim E/A-Vorgang gelesenen oder geschriebenen Daten im Speicher eines anderen Knotens als dem Knoten befanden, in dem auf sie zugegriffen wurde.
Um dies zu vermeiden, leitet das E/A-System von Windows Server 2008 die DPC-Ausführung zu einer CPU in dem Knoten, der die Ein- und Ausgabe gestartet hat, und Systeme mit Geräten, die PCI-Bus-MSI-X – eine Erweiterung des MSI-Standards (Message Signaled Interrupt) – unterstützen, können die E/A-Verarbeitung noch genauer lokalisieren, indem sie Gerätetreiber verwenden, die mithilfe von Windows Server 2008-APIs den Interrupt einer Ein- und Ausgabe zu dem Prozessor leiten, der die Ein- und Ausgabe gestartet hat.

Dynamische Partitionierung
Eine der Methoden, mit denen ein System skalierbarer gemacht werden kann, besteht darin sicherzustellen, dass es das dynamische Hinzufügen von Hardwareressourcen wie z. B. CPUs und Speicher unterstützen kann. Diese Unterstützung kann auch die Verfügbarkeit des Systems steigern, wenn diese Ressourcen ersetzt werden können, ohne das System neu starten zu müssen.
Windows Server 2003 unterstützte eine Speicherhinzufügung bei laufendem Betrieb, die es Servern mit Unterstützung für dynamischen Speicher ermöglichte, RAM zu verwenden, sobald dieser von einem Administrator hinzugefügt wurde. Windows Server 2008 erweitert diese Unterstützung dynamischen Speichers, indem es zulässt, dass Speicher ersetzt wird.
Wenn RAM abhängiger von ECC-Korrekturen wird (Error Correcting Code), besteht das Risiko, dass er komplett ausfällt. Aus diesem Grund kann Windows Server 2008 bei einem Server, der das Ersetzen von Speicher bei laufendem Betrieb unterstützt, Daten von ausfallenden Speicherbänken transparent auf Ersatzspeicherbänke migrieren. Bei diesem Vorgang migriert es zuerst die Daten, die unter der Kontrolle des Betriebssystems stehen. Danach fährt es Hardwaregeräte praktisch herunter, indem es sie in einen Energiesparmodus schaltet, migriert die übrigen Daten des Speichers und schaltet danach die Geräte wieder in den normalen Energiemodus, damit sie weiterarbeiten können.
Windows Server 2008 unterstützt auch das Hinzufügen und Ersetzen von Prozessoren bei laufendem Betrieb. Beim Ersetzen bei laufendem Betrieb muss die Hardware das Konzept von Ersatz-CPUs unterstützen, die entweder online geschaltet oder dynamisch hinzugefügt werden können, wenn eine vorhandene CPU Fehleranzeigen generiert. Dies ist derzeit jedoch nur bei High-End-Systemen möglich. Der Planer von Windows Server 2008 verlangsamt die Aktivitäten auf der ausfallenden CPU und migriert die Arbeit auf die Ersatz-CPU. Anschließend kann die ausfallende CPU durch eine neue CPU ersetzt werden.
Dass Windows Server 2008 das Hinzufügen von Prozessoren bei laufendem Betrieb unterstützt, ermöglicht einem Administrator, die Verarbeitungskapazität eines Servers zu steigern, ohne den Server herunterfahren zu müssen. Der Planer und die E/A-Systeme machen eine neue CPU allerdings nur für Gerätetreiber und Anwendungen verfügbar, die über neue APIs anfordern, von der Installation neuer CPUs in Kenntnis gesetzt zu werden, denn einige Anwendungen gehen grundsätzlich davon aus, dass die Anzahl der CPUs während einer Startsitzung unverändert bleibt. So könnte beispielsweise eine Anwendung für jede CPU ein Array von Arbeitswarteschlangen zuordnen, wobei ein Thread die Warteschlange verwendet, die der CPU zugeordnet ist, auf der er ausgeführt wird. Wenn dann der Planer einen der Threads der Anwendung auf eine neue CPU migriert, würde der Thread versuchen, auf eine nicht vorhandene Warteschlange zu verweisen, was dazu führen kann, dass die Daten der Anwendung beschädigt werden, wodurch die Anwendung wahrscheinlich abstürzen würde.
CPU-Hinzufügungen werden von serverbasierten Microsoft-Anwendungen wie z. B. SQL Server und Exchange Server sowie von verschiedenen zentralen Windows-Prozessen wie z. B. dem System-Prozess, dem Sitzungs-Manager-Prozess (%SystemRoot%\System32\Smss.exe) und dem Prozess für das Hosten allgemeiner Dienste (%Systemroot%\System32\Svchost.exe) unterstützt. Andere Prozesse können ebenfalls über eine Windows-API anfordern, von der Installation neuer CPUs in Kenntnis gesetzt zu werden. Wenn eine neue CPU installiert wird, weist Windows Gerätetreiber auf die bevorstehende Installation hin, startet die CPU und benachrichtigt anschließend Gerätetreiber und Anwendungen, die dafür programmiert wurden, neue CPUs nutzen zu können, damit sie ggf. Datenstrukturen zuordnen, um Aktivitäten auf der neuen CPU nachzuverfolgen.

Computervirtualisierung
Vor Windows Server 2008 wurden Virtualisierungsprodukte von Microsoft einschließlich Virtual Server 2005 durch gehostete Virtualisierung implementiert, wie in Abbildung 5 zu sehen ist. Bei der gehosteten Virtualisierung werden virtuelle Computer von einem VMM (Virtual Machine Monitor) implementiert, der (i. d. R. als Gerätetreiber) zusätzlich zu einem Hostbetriebssystem ausgeführt wird. Der VMM nutzt die Ressourcenverwaltung und die Gerätetreiber des Hostbetriebssystems, und wenn das Hostbetriebssystem die Ausführung des VMM plant, teilt der VMM die CPU durch Zeitabschnitte unter den aktiven virtuellen Computern (virtual machines, VMs) auf.
Abbildung 5 Virtualisierung gehosteter Computer
Abbildung 5 Virtualisierung gehosteter Computer
Hyper-V, das ehemals den Codenamen „Viridian“ trug, wird durch Hypervisorvirtualisierung implementiert. Der Hypervisor hat vollständige Kontrolle über alle Hardwareressourcen, und selbst das Betriebssystem Windows Server 2008, das den Computer startet und über das Sie virtuelle Computer steuern, wird praktisch auf einem virtuellen Computer ausgeführt, wie in Abbildung 6 zu sehen ist.
Abbildung 6 Hyper-V-Architektur
Abbildung 6 Hyper-V-Architektur
Der Hypervisor kann das System in mehrere virtuelle Computer partitionieren und behandelt die startende Instanz von Windows Server 2008 als Master- bzw. Stammpartition, der er direkten Zugriff auf Hardwaregeräte wie z. B. die Festplatte, die Netzwerkadapter und den Grafikprozessor gewährt. Der Hypervisor erwartet von der Stammpartition, die Energieverwaltung durchzuführen und auf Plug und Play-Ereignisse von Hardware zu reagieren. Er fängt die Hardwaregeräte-E/A ab, die in einer untergeordneten Partition gestartet wird, und leitet sie in die Stammpartition, die für den Hardwarezugriff Standardgerätetreiber von Windows Server 2008 verwendet. Auf diese Weise können Server, auf denen Hyper-V ausgeführt wird, die Windows-Unterstützung von Hardwaregeräten voll nutzen.
Wenn Sie Windows Server 2008 mit der Hyper-V-Serverrolle konfigurieren, setzt Windows die Boot Configuration Database (BCD)-Einstellung „hypervisorimagelaunchtypeboot“ auf „auto“ (automatisch) und konfiguriert den Gerätetreiber „Hvboot.sys“ dafür, beim Startvorgang schon früh zu starten. Falls die Option konfiguriert ist, bereitet „Hvboot.sys“ das System auf die Virtualisierung vor und lädt danach in Abhängigkeit davon, ob das System AMD-V- oder Intel VT-CPU-Virtualisierungserweiterungen implementiert, entweder %Systemroot%\System32\Hvax64.exe oder %Systemroot%\System32\Hvix64.exe in den Speicher.
Nachdem der Hypervisor geladen wurde, verwendet er die Virtualisierungserweiterungen, um sich unterhalb von Windows Server 2008 selbst einzufügen. Da Benutzermodusanwendungen die Berechtigungsstufe „Ring 3“ des x64-Prozessors verwenden und Kernelmoduscode bei „Ring 0“ ausgeführt wird, arbeitet der Hypervisor auf der konzeptionellen Berechtigungsstufe „Ring minus 1“, denn er kann die Ausführungsumgebung von Code, der auf der Stufe „Ring 0“ ausgeführt wird, kontrollieren.
Wenn Sie die Hyper-V-Verwaltungskonsole verwenden, um eine untergeordnete Partition zu erstellen oder zu starten, kommuniziert sie mit dem Hypervisor über den Treiber „%Systemroot%\System32\Drivers\Winhv.sys“, der die öffentlich dokumentierte Hypercall-API verwendet, um den Hypervisor anzuweisen, eine neue Partition mit einer festgelegten Größe des physischen Speichers und festgelegten Ausführungsmerkmalen zu erstellen. Der VM-Dienst (%Systemroot%\System32\Vmms.exe) innerhalb des Stamms erstellt für jede untergeordnete Partition einen VM-Arbeitsprozess (%Systemroot%\System32\Vmwp.exe), um den Status der untergeordneten Partition zu verwalten.
Eine der Methoden, mit der Windows die Leistung von Betriebssystemen untergeordneter virtueller Computer verbessert, besteht darin, dass sowohl Windows Server 2008 als auch Windows Vista so genannte „Enlightenments“ implementiert, bei denen es sich um Codesequenzen handelt, die nur dann aktiviert werden, wenn das Betriebssystem auf einem Hypervisor ausgeführt wird, der die Microsoft-Hypercall-API implementiert. Indem der untergeordnete virtuelle Computer Dienste des Hypervisors direkt anfordert, vermeidet er einen übermäßigen Aufwand an Virtualisierungscode, der notwendig wäre, wenn der Hypervisor die Absicht des untergeordneten Betriebssystems erraten müsste.
So würde beispielsweise ein Gastbetriebssystem, das keine Enlightenments für Spinlocks implementiert, die eine untergeordnete Mehrprozessorsynchronisierung ausführen, einfach in einer engen Schleife hängen bleiben und darauf warten, dass ein Spinlock von einem anderen virtuellen Prozessor freigegeben wird. Dieses Hängenbleiben in der Schleife könnte eine der Hardware-CPUs so lange binden, bis der Hypervisor den zweiten virtuellen Prozessor geplant hätte. Bei Betriebssystemen mit Enlightenments benachrichtigt der Spinlockcode in dem Augenblick, in dem er normalerweise in der Schleife hängen bleiben würde, über einen Hypercall den Hypervisor, damit der Hypervisor sofort einen anderen virtuellen Prozessor planen kann, um die verschwenderische CPU-Nutzung zu verringern.
Eine andere Methode, mit der Windows Server 2008 die Leistung virtueller Computer verbessert, besteht darin, den Zugriff virtueller Computer auf Geräte zu beschleunigen. Die Leistung wird verbessert, indem im untergeordneten Betriebssystem eine Reihe von Komponenten installiert wird, die zusammenfassend als „VM-Integrationskomponenten“ bezeichnet werden.
Wenn Sie einen virtuellen Computer ausführen, ohne Integrationskomponenten zu installieren, konfiguriert das untergeordnete Betriebssystem für die emulierten Geräte, die ihm vom Hypervisor präsentiert werden, Hardwaregerätetreiber. Der Hypervisor muss dann, wenn ein Gerätetreiber versucht, eine Hardwareressource anzusteuern, eingreifen, um die Stammpartition zu verständigen, die danach Geräte-E/A-Vorgänge durchführt, indem sie im Namen des Betriebssystems des untergeordneten virtuellen Computers standardmäßige Windows-Gerätetreiber verwendet. Da ein einziger E/A-Vorgang auf hoher Ebene (z. B. das Lesen von einem Datenträger) viele separate Hardwarezugriffe umfassen kann, kann er viele Übergänge (Abfangvorgänge) im Hypervisor und in der Stammpartition auslösen.
Windows Server 2008 minimiert Abfangvorgänge durch drei Komponenten: den VM-Bustreiber (%Systemroot%\System32\Drivers\Vmbus.sys), virtuelle Dienstclients (Virtual Service Clients, VSCs) und virtuelle Dienstanbieter (Virtual Service Providers, VSPs). Wenn Sie Integrationskomponenten in einem virtuellen Computer (virtual machine, VM) mit einem unterstützten Betriebssystem installieren, übernehmen VSCs die Rolle von Gerätetreibern und verwenden die Dienste des Vmbus.sys-Treibers im untergeordneten virtuellen Computer, um über die Hypercall- und Speicherfreigabedienste des Hypervisors übergeordnete E/A-Anforderungen an den VM-Bustreiber in der Stammpartition zu senden. In der Stammpartition leitet Vmbus.sys die Anforderung an den entsprechenden VSP weiter, der danach über die Gerätetreiber der Stammpartition die Standard-E/A-Anforderungen von Windows startet.
Wie Sie sehen können, spielt Windows Server 2008 durch seine Einführung der hypervisorbasierten Hyper-V-Virtualisierung eine wichtige Rolle in der Computervirtualisierungsstrategie von Microsoft. Weitere Informationen zu diesen und anderen Features finden Sie in der nächsten Ausgabe meines Buchs „Microsoft Windows Internals“, das in diesem Jahr veröffentlicht werden soll.

Mark Russinovich ist Technical Fellow in der Platform and Services Division von Microsoft. Er ist Mitautor von Microsoft Windows Internals (Microsoft Press, 2004) und hält häufig Vorträge auf IT- und Entwicklerkonferenzen, einschließlich Microsoft TechEd und der Professional Developers Conference (PDC). Mark Russinovich wechselte bei der Übernahme des von ihm mitgegründeten Unternehmens Winternals Software zu Microsoft. Darüber hinaus gründete er Sysinternals, wo er viele populäre Dienstprogramme einschließlich Process Explorer, Filemon und Regmon veröffentlichte.
© 2007 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.


 Sonderbeitrag: Windows Server&#160;2008: Neuerungen in Active&#160;Directory-Dom&#228;nendiensten
Sonderbeitrag: Windows Server 2008 Gil Kirkpatrick

Neuerungen in Active Directory-Domänendiensten
Kurz zusammengefasst:
  • Verwenden des neuen Server-Managers mit ADDS
  • Ausführen von Domänendiensten auf Server Core
  • Domänencontroller ohne Schreibzugriff
  • Änderungen bei Kennwörtern, Sicherung und Überwachung

Mit Windows 2000 wurde Active Directory von Microsoft eingeführt. Die nächste Hauptversion, Windows Server 2003, enthielt bedeutende Verbesserungen von Active Directory, aber keine
weltbewegenden Änderungen. Heute ist Active Directory® ein höchst ausgereifter, stabiler Verzeichnisdienst. Dennoch hat das Active Directory Team mehrere wesentliche Verbesserungen in der aktuellen Version bereitgestellt, um die Sicherheit und Verwaltbarkeit dieses zentralen Netzwerkdiensts zu verbessern.
Um das Jahr 2000 herum sorgte Active Directory beim Anmelden eines Benutzers für dessen Authentifizierung, wendete Gruppenrichtlinien für diesen Benutzer und seinen Computer an und ermöglichte ihm, einen gewünschten Drucker zu finden. Ein paar Jahre später veröffentlichte Microsoft eine eigenständige Variante mit der Bezeichnung Active Directory-Anwendungsmodus (Active Directory Application Mode, ADAM).
Doch bis 2006 hatte sich das alles geändert. Active Directory war keine bestimmte Technologie mehr. Heute ist es ein Markenname für eine Sammlung von sofort einsetzbaren Windows®-Identitäts- und Zugriffssteuerungsdiensten. Abbildung 1 bietet einen kurzen Überblick über die Active Directory-Marke.
Figure 1 Active Directory-Komponenten (Close Figure 1)

Aktuelle Active Directory-Technologie | Bisher bezeichnet als | Beschreibung
Active Directory-Domänendienste (ADDS) | Active Directory | Was früher als Active Directory bezeichnet wurde Bietet Kerberos- und NTLM-basierte Authentifizierung für Domänenbenutzer und -Computer und verwaltet Organisationseinheiten, Benutzer, Gruppen, Gruppenrichtlinien und vieles mehr.
Active Directory Lightweight-Verzeichnisdienste (ADLDS) | Active Directory-Anwendungsmodus (ADAM) | Ein Hochleistungs-LDAP-Server auf der Grundlage desselben von ADDS verwendeten Quellcodes.
Active Directory-Zertifikatdienste (ADCS) | Zertifikatdienst | Bietet leistungsfähige Authentifizierung mithilfe von X.509-Zertifikaten.
Active Directory-Rechteverwaltungsdienste (ADRMS) | Rechteverwaltungsserver | Schützt digitale Ressourcen wie Dokumente und E-Mail-Nachrichten vor nicht autorisierter Verwendung durch Erstellen von Dateien und Containern, die durch Rechte geschützt sind.
Active Directory-Verbunddienste (ADFS) | Active Directory-Verbunddienste | Bietet einmaliges Anmelden im Web und Identitätsverbund für WS-*-kompatible Webdienste.
Um die richtige Terminologie zu verwenden, geht es in diesem Artikel also um die Domänendienste. Es handelt sich jedoch um dasselbe Active Directory, an das Sie seit 2000 gewöhnt sind.

Server-Manager in Windows Server 2008
Die ersten beiden Verbesserungen für Active Directory, die hier erörtert werden, sind eigentlich keine Änderungen an den Active Directory-Domänendiensten (Active Directory Domain Services, ADDS), sondern Änderungen in Windows, die sich auf die Verwaltung von Active Directory auswirken. Die erste Änderung, der neue Server-Manager, wird angezeigt, sobald Sie Windows Server® 2008 zum ersten Mal starten. (Die zweite ist die Server Core-Installation, auf die gleich noch eingegangen wird.)
Server-Manager wird Ihnen wahrscheinlich aus dem Serverkonfigurations-Assistenten in Windows Server 2003 vertraut sein, der standardmäßig nach der Installation von Windows Server 2003 angezeigt wird. Diese Version ist jedoch für die tägliche Verwaltung nicht sehr nützlich, und alle, die ich kenne, markieren das Kontrollkästchen „Don't display this page at logon“ (Diese Seite bei der Anmeldung nicht anzeigen).
Server-Manager in Windows Server 2008 ist allerdings recht nützlich (einen Überblick über Server-Manager finden Sie im Artikel von Byron Hynes in dieser Ausgabe des TechNet Magazins). Wie Sie in Abbildung 2 sehen, ist Server-Manager jetzt ein Microsoft®-Verwaltungskonsolen (MMC)-Snap-In und keine Microsoft HTML-Anwendung (HTA). Dies bedeutet, dass eine vertraute und leicht anpassbare Benutzeroberfläche mit allen Funktionen vorhanden ist. Mithilfe von Server-Manager können Sie sofort die Installation von Serverrollen (Hauptdienste wie DNS, ADDS und IIS) und Features (Softwarekomponenten wie Microsoft .NET Framework, BitLockerTM-Laufwerkverschlüsselung und Windows PowerShellTM) verwalten. Neben der Möglichkeit zum Hinzufügen und Entfernen von Software stellt Server-Manager auch einen zentralen Punkt zum Ausführen von Diagnosetools (beispielsweise die Ereignisanzeige und PerfMon) und Systemkonfigurationsprogrammen (beispielsweise Geräte-Manager und das Windows Firewall-Snap-In) bereit. Wenn Sie die MMC-Snap-Ins zu Active Directory dazunehmen (etwa „Benutzer und Computer“, „Domänen und Vertrauensstellungen“ und „Standorte und Dienste“), verfügen Sie über eine recht gute Benutzeroberfläche für die tägliche Verwaltung Ihres Windows Server 2008-Domänencontrollers (Domain Controller, DC).
Abbildung 2 Server-Manager in Windows Server 2008
Abbildung 2 Server-Manager in Windows Server 2008

Windows Server 2008 Server Core
Windows Server Core ist eine neue Windows Installationsoption. Sie bietet eine verkürzte Version von Windows, die nur die zum Ausführen bestimmter Hauptserverrollen (einschließlich Active Directory-Domänendiensten) erforderlichen Komponenten enthält. (In Abbildung 3 sind die von Server Core unterstützen Rollen aufgeführt.) Obwohl eine Server Core-Installation über eine grafische Benutzeroberfläche verfügt, wird die Windows-Desktopshell nicht ausgeführt, und fast alle grafischen Tools zum Verwalten und Konfigurieren von Windows fehlen (siehe Abbildung 4). An ihre Stelle treten ein Befehlsfenster sowie ein ungutes Gefühl, nicht zu wissen, was Sie als Nächstes tun sollen. Wie lässt sich der Computername ändern? Wie kann eine statische IP-Adresse konfiguriert werden?
Abbildung 4 Auf der Server Core-Benutzeroberfläche gibt es nicht viel zu sehen.
Abbildung 4 Auf der Server Core-Benutzeroberfläche gibt es nicht viel zu sehen.
Die ersten Minuten einer Server Core-Installation können beunruhigend sein. Aber wenn Sie sich mit WMIC, NETSH und NETDOM wieder ein wenig vertraut gemacht haben, können Sie alle üblichen Setup- und Konfigurationsaufgaben ohne Schwierigkeit durchführen. Regedit und der Editor sind zur Erfüllung Ihrer Anforderungen an grafische Tools weiterhin vorhanden.
Der Hauptvorteil von Server Core besteht darin, dass viel Code, der bei einer typischen Windows-Installation vorhanden ist und den Sie möglicherweise für diese zentralen Serverrollen nicht brauchen, entfernt wurde. Dies verringert die potenzielle Angriffsfläche für Malware (was gut ist) und verringert das Ausmaß von Patching und Neustarts, die Sie bei den DCs durchführen müssen (was noch besser ist). Zudem sind der Datenträgerbedarf und die Festplattenanforderungen sehr viel geringer. Dies ist normalerweise kein entscheidender Faktor, kann aber in virtualisierten Serverumgebungen helfen.
Wird das Verwalten von ADDS durch den Mangel an grafischen Dienstprogrammen erschwert? Absolut nicht. Sie können fast alle Verwaltungsaufgaben von einem Remotestandort aus durchführen, indem Sie die Dienstprogramme auf Ihrer Arbeitsstation ausführen und eine Verbindung zum Domänencontroller über das Netzwerk herstellen. In Zukunft dürfte die große Mehrzahl von DCs auf Server Core-Installationen ausgeführt werden.

DCPROMO-Änderungen
Die erste Änderung, die Sie bei ADDS feststellen werden, ist das neue DCPROMO-Dienstprogramm. Es funktioniert genauso wie DCPROMO in Windows Server 2003, aber es wurde im Interesse einer einfacheren Verwendung völlig überarbeitet. Sie müssen beispielsweise nicht Ihre Anmeldeinformationen als Domänenadministrator eingeben. DCPROMO kann die Anmeldeinformationen Ihrer aktuellen Anmeldung verwenden, um den Server hochzustufen. Sie müssen auch nicht DCPROMO /ADV eingeben, um die DCPROMO-Optionen im erweiterten Modus aufzurufen. Zur Aktivierung dieser Optionen ist jetzt im ersten DCPROMO-Dialogfeld ein Kontrollkästchen vorhanden. Mithilfe des erweiterten Modus können Sie dazu den vorhandenen Domänencontroller auswählen, von dem aus die Replikation erfolgen soll. Sie können somit also die Replikationslast von DCPROMO von Ihren Produktions-DCs fernhalten.
Wenn Sie einen DC in eine neue Domäne oder Gesamtstruktur hochstufen, bietet DCPROMO Ihnen die Option, die Funktionsebene der Gesamtstruktur und der Domäne festzulegen, statt dies später zu tun. Sie können auch den Active Directory-Standort angeben, in den Sie den DC in während des Hochstufungsprozesses stellen wollen, was im unbeaufsichtigten DCPROMO-Szenario sehr nützlich ist. DCPROMO schlägt sogar den besten Standort für den DC auf der Grundlage seiner IP-Adresse vor.
Das neue DCPROMO-Dienstprogramm sammelt zudem alle Konfigurationsoptionen auf einer einzigen Seite, sodass Sie von einem Ort auswählen können, ob der neue DC ein globaler Katalog (Global Catalog, GC), ein DNS-Server oder ein schreibgeschützter DC sein soll. Sie müssen keinen unbekannten Speicherort im Active Directory-Snap-In für Standorte und Dienste aufsuchen, um den DC als GC zu kennzeichnen.
Doch das vielleicht beste Feature des neuen DCPROMO-Dienstprogramms ist die Möglichkeit, kurz vor Beginn des Hochstufungsprozesses alle DCPROMO-Einstellungen in einer Antwortdatei zu speichern. Dies ist viel einfacher (und weniger fehleranfällig) als das manuelle Zusammenbasteln der Antwortdatei. Sie können dann die Antwortdatei verwenden, um unbeaufsichtigte DCPROMOs auf anderen Servern durchzuführen. Noch eine Information für Skriptfanatiker: Alle DCPROMO-Optionen sind jetzt von der Befehlszeile aus zugänglich.

Domänencontroller ohne Schreibzugriff
Im Anfangsstadium von Active Directory stellten Unternehmen oft Domänencontroller an jedem Standort bereit, an dem sich Benutzer anmelden konnten. Dies war beispielsweise in Banken üblich, wo ein DC in jeder Zweigstelle platziert wurde. Das logische Grundprinzip bestand darin, dass Benutzer in der Zweigstelle in der Lage sein würden, sich anzumelden und auf die lokalen Netzwerkressourcen zuzugreifen, selbst wenn das WAN versagte.
Damals wurde der Bedarf an physischer Sicherheit für DCs nicht besonders gut verstanden. Beispielsweise wurden Domänencontroller einfach unter Schreibtischen platziert, wo praktisch jeder leicht auf sie zugreifen konnte. Erst einige Jahre später wurden sich Active Directory-Architekten vollständig des Sicherheitsrisikos bewusst, das durch einen ungesicherten DC entsteht, und IT-Organisationen konsolidierten ihre DCs nach und nach wieder in stärker zentralisierten Datencentern. Benutzer in Zweigstellen mussten sich dann über das WAN authentifizieren, was aber hinsichtlich der zusätzlichen Sicherheit ein lohnender Kompromiss war.
Active Directory in Windows Server 2008 ändert die Gleichung in Bezug auf Zweigstellenbereitstellungen durch die Einführung von Domänencontrollern ohne Schreibzugriff oder RODCs. Sie repräsentieren die größte Änderung an Windows Server 2008-Domänendiensten.
Das Active Directory-Team konzentrierte sich bei der Entwicklung des RODC auf die Anforderungen von Zweigstellenszenarios, wobei sich die Beteiligten das Ziel setzten, dass sich das, was in der Zweigstelle passiert, auch nur dort auswirkt. Das heißt, beim Bereitstellen eines DC in einer physisch nicht sicheren Zweigstelle kann praktisch nichts getan werden, um eine Gefährdung des DC (und der Computer, die diesem DC vertrauen) zu verhindern, aber es kann verhindert werden, dass sich diese Gefährdung von der Zweigstelle aus in der übrigen Domäne ausbreitet.
Beachten Sie, dass RODCs zwar eine enorme Änderung der ADDS-Infrastruktur bedeuten, sich aber ziemlich einfach implementieren lassen. Ihre Domäne muss sich auf der Funktionsebene der Windows Server 2003-Gesamtstruktur befinden, und es muss mindestens ein Windows Server 2008-DC in der Domäne vorhanden sein. RODCs sind nicht nur als einfache Zweigstellenlösung sinnvoll, sondern auch in mit dem Internet verbundenen Umgebungen, sowie in Situationen, in denen sich der DC im Netzwerkumkreis befindet.

Ein unerlaubt abwesender DC
In einer Zweigstelle müssen mehrere Klassen von Bedrohungen in Betracht gezogen werden. Die erste ist das Szenario, in dem der „DC gestohlen“ wird, indem sich jemand mit dem DC oder dem Datenträger des DC davon macht. Neben der lokalen Dienstunterbrechung besteht das Risiko darin, dass der Angreifer letzten Endes Zugriff auf alle Benutzernamen und Kennwörter in der Domäne gewinnt und von dort aus seine Berechtigungen erweitert, um Zugriff auf geschützte Ressourcen zu erhalten oder einen Denial-of-Service zu verursachen. Um dieser Bedrohung entgegenzuwirken, speichern RODCs standardmäßig keine Kennworthashwerte in der Verzeichnisinformationsstruktur (Directory Information Tree, DIT) des RODC. Um einen Benutzer bei erstmaliger Authentifizierung bei einem bestimmten RODC zu authentifizieren, gibt der RODC die Anforderung an einen vollständigen Domänencontroller (Full Domain Controller, FDC) in der Domäne weiter. Der FDC verarbeitet die Anforderung, und bei Erfolg erstellt der RODC eine Replikationsanforderung für den Kennworthashwert.
Ein beeinträchtigter RODC könnte unter Umständen Kennworthashwerte für vertrauliche Konten anfordern. Um dies zu verhindern, kann der Domänenadministrator eine Kennwortreplikationsrichtlinie für jeden RODC konfigurieren. Die Kennwortreplikationsrichtlinie besteht aus zwei Attributen auf dem Computerobjekt des RODC. Das msDS-RevealOnDemandGroup-Attribut enthält die „Distinguished Names“ von Gruppen-, Benutzer- oder Computerkonten, deren Kennwörter auf dem RODC zwischengespeichert werden dürfen (dies sind in der Regel die Benutzer und Computer am selben Standort wie der RODC). Das msDS-NeverRevealGroup-Attribut enthält die „Distinguished Names“ der Gruppen-, Benutzer- oder Computerkonten, deren Kennwörter nicht auf dem RODC zwischengespeichert werden dürfen (die Kennworthashwerte des Domänenadministratorkontos sollten beispielsweise nie auf einem RODC zwischengespeichert werden). Wenn der RODC den Kennworthashwert für ein bestimmtes Konto anfordert, bewertet der FDC die Anforderung anhand der Kennwortreplikationsrichtlinie, um zu bestimmen, ob der Kennworthashwert auf dem RODC repliziert werden sollte. Wenn ein DC gestohlen wird, schränkt dies das Sicherheitsrisiko für jene Kennwörter ein, die zu dem Zeitpunkt, als er aus dem Netzwerk entfernt wurde, auf dem gestohlenen RODC zwischengespeichert waren, sodass die Möglichkeit einer Gefährdung eines kritischen Kennworts beseitigt wird.
Das RODC-Computerobjekt enthält zwei weitere Attribute, mit denen Sie genau festlegen können, welche Kontenkennwörter zwischengespeichert werden sollten. Das msDS-AuthenticatedAtDC-Attribut listet die Konten auf, die beim RODC authentifiziert wurden, und das msDS-RevealedList-Attribut nennt die Konten, deren Kennwörter derzeit vom RODC gespeichert werden.
Benutzer- und Computerkennworthashwerte sind nicht die einzigen geheimen Informationen, die auf einem DC gespeichert werden. Das KrbTGT-Konto enthält die Schlüssel für den Kerberos-Schlüsselverteilungscenter (Key Distribution Center, KDC)-Dienst, der auf jedem Domänencontroller ausgeführt wird. In einem typischen Szenario nutzen alle KDCs in der Domäne dasselbe KrbTGT-Konto, und es ist möglich, dass ein Angreifer diese Schlüssel von einem gestohlenen DC abrufen und sie zum Angriff auf die übrige Domäne verwenden könnte. Doch jeder RODC hat sein eigenes KrbTGT-Konto und seine eigenen Schlüssel, sodass diese Möglichkeit beseitigt wird.
Es ist zudem nicht ungewöhnlich, dass Anwendungen Kennwörter oder andere geheime Informationen in der DIT speichern. Wenn ein Angreifer einen DC stiehlt, könnte er möglicherweise damit die Anwendungskennwörter stehlen und verwenden, um Zugriff auf die Anwendungen zu gewinnen. Um dieses Risiko zu verringern, ermöglichen Windows Server 2008-Domänendienste es Administratoren, das Read-Only DC Filtered Attribute Set (RO-FAS) zu definieren. Attribute, die Teil des RO-FAS sind, werden nie auf RODCs repliziert, sodass sie nicht von einem gefährdeten DC abgerufen werden können. Sie weisen dem RO-FAS Attribute zu, indem Sie Bit 9 (0x0200) des searchFlags-Attributs des entsprechenden attributeSchema-Objekts im Schema festlegen.

Barbaren innerhalb der Tore
Eine weitere Bedrohungsklasse für Zweigstellendomänencontroller besteht darin, dass ein lokaler Serveradministrator seine Berechtigung erweitert, indem er Berechtigungen des DC nutzt, um Zugriff auf andere Domänenressourcen zu gewinnen oder einen Denial-of-Service-Angriff durchzuführen. Auch hier gilt: wenn der lokale Administrator physischen Zugriff auf den Domänencontroller hat, kann wenig getan werden, um eine Gefährdung zu verhindern. Doch es ist möglich, den Angreifer daran zu hindern, den Zweigstellendomänencontroller zur Gefährdung anderer DCs in der Domäne zu verwenden.
Vollständige DCs in der Domäne vertrauen RODCs nicht als Domänencontroller. Von einem Vertrauensstandpunkt aus behandeln FDCs RODCs als Mitgliedsserver in der Domäne. Ein RODC ist kein Mitglied der Domänencontroller oder Domänencontrollergruppen eines Unternehmens. Das RODC-Konto hat sehr begrenzte Möglichkeiten, Informationen im Verzeichnis zu aktualisieren, und selbst wenn ein Angreifer das RODC-Konto gefährdet, erhält er fast keine nützlichen Berechtigungen.
RODCs werden nicht einmal in der normalen DS-Replikationstopologie angezeigt. Da RODCs wie normale Mitgliedsserver anstelle von Domänencontrollern aussehen, erstellt die Konsistenzprüfung (Knowledge Consistency Checker, KCC, der Prozess auf jedem DC, der für die Berechnung der DS-Replikationstopologie verantwortlich ist) keine Verbindungsobjekte von RODCs. Kein vollständiger DC oder RODC wird versuchen, von einem RODC zu replizieren. Andererseits erstellt der RODC ein Verbindungsobjekt, das eine eingehende Replikationsvereinbarung von einem vollständigen DC darstellt, doch dieses Verbindungsobjekt existiert nur im Replikat des RODC. Kein anderer DC verfügt über eine Kopie dieses Verbindungsobjekts. Von einem Replikationsstandpunkt aus sind RODCs wie Mausefallen für Verzeichnisobjekte. Objekte werden hinein-, aber nicht herausrepliziert.

Administratorrollentrennung auf RODCs
Es ist häufig der Fall, dass ein Zweigstellen-DC von einem lokalen Serveradministrator verwaltet wird, dessen Aufgaben praktisch alles umfassen, vom Ausführen von Sicherungen bis hin zum Reinigen von Tastaturen. Doch es ist ein Sicherheitsrisiko, wenn dem Administrator an einem Remotestandort die erforderlichen Rechte für die allgemeine Wartung eines Domänencontrollers gewährt werden, da der Standortadministrator seine Berechtigungen in der Domäne unter Umständen erhöhen könnte. RODCs bieten zwei Arten der Administratorrollentrennung, um diese Bedrohung zu verringern.
Bei der ersten Form der Rollentrennung kann der Domänenadministrator den RODC auf herkömmliche Weise mithilfe von DCPROMO hochstufen, oder er kann einen aus zwei Schritten bestehenden Prozess verwenden, wobei der eigentliche Hochstufungsprozess sicher an den Zweigstellenadministrator delegiert wird, ohne Domänenverwaltungsrechte zu gewähren. Der Domänenadministrator erstellt das RODC-Computerkonto vorher in der Domäne mithilfe des Active Directory-MMC-Snap-In für Benutzer und Computer, wie in Abbildung 5 dargestellt.
Abbildung 5 Vorherige Erstellung des RODC-Computerkontos
Abbildung 5 Vorherige Erstellung des RODC-Computerkontos
Durch die Auswahl von „Konto für schreibgeschützten Domänencontroller vorbereiten“ wird eine abgekürzte Version von DCPROMO ausgeführt, die alle Aufgaben durchführt, für die Administratorzugriff auf die Domäne erforderlich ist, einschließlich Erstellen des Computerkontos, Zuweisen des RODC zu einem Standort, Festlegen der Rollen des DC, Festlegen der Kennwortreplikationsrichtlinie und Definieren des Benutzers oder der Gruppe, für die Rechte zum Abschließen des DCPROMO-Vorgangs auf dem RODC erforderlich sind. Der delegierte Administrator oder die Gruppe wird im managedBy-Attribut des RODC-Computerobjekts gespeichert.
Der delegierte Administrator kann dann DCPROMO auf dem Server selbst ausführen. DCPROMO erkennt das zuvor erstellte Konto und verwandelt den Server in einen RODC. Für das Ausführen von DCPROMO auf diese Weise sind keine Domänenadministratoranmeldeinformationen erforderlich.
Die zweite Möglichkeit, eine Administratorrollentrennung für RODCs bereitzustellen, besteht im Erstellen lokaler Administratorrollen auf dem RODC selbst. Diese Rollen sehen wie lokale Computergruppen aus – sie werden in der Registrierung des RODC gespeichert und können nur auf dem RODC bewertet werden. Doch anstelle der Verwendung des Computerverwaltungs-MMC-Snap-Ins zu ihrer Verwaltung verwaltet der Administrator lokale RODC-Rollen mithilfe von NTDSUTIL. In Abbildung 6 sind die lokalen Administratorrollen auf einem RODC aufgeführt. Diese Rollen entsprechen jeweils den integrierten Gruppen in Windows.
Figure 6 Lokale RODC-Administratorrollen (Close Figure 6)

Kontenoperatoren
Administratoren
Sicherungsoperatoren
Zertifikatdienst-DCOM-Zugriff
Kryptografische Operatoren
DCOM-Benutzer
Ereignisprotokollleser
Gäste
IIS_IUSRS
Erstellungen eingehender Gesamtstrukturvertrauensstellung
Netzwerkkonfigurationsoperatoren
Leistungsprotokollbenutzer
Systemmonitorbenutzer
Prä-Windows 2000-kompatibler Zugriff
Druckoperatoren
Remotedesktopbenutzer
Replikations-Operator
Serveroperatoren
Terminal Server-Lizenzserver
Benutzer
Windows-Autorisierungszugriffsgruppe

Eigentümlichkeiten von RODCs
Da RODCs schreibgeschützt sind und kein anderer Domänencontroller von ihnen Replikationen vornimmt, zeigen RODCs einige unerwartete Verhaltensweisen. Veraltete Objekte beispielsweise, Objekte also, die überall bis auf einem bestimmten DC gelöscht wurden, weil der DC nicht in der Lage war, für eine längere Zeitdauer als die Tombstone-Gültigkeitsdauer der Gesamtstruktur zu replizieren, werden normalerweise von den ausgehenden Replikationspartnern des DC erkannt. Doch da RODCs keine eingehenden Replikationspartner haben, werden für sie keine veralteten Objekte erkannt.
RODCs stellen keine LDAP-Updatevorgänge (hinzufügen, ändern, löschen, umbenennen oder verschieben) bereit. Stattdessen geben RODCs einen Fehler mit einem LDAP-Verweis an einen beschreibbaren DC zurück, der diesen Vorgang bereitstellen kann. Wenn die Anwendung, die das LDAP-Update veröffentlicht hat, den Verweisvorgang nicht richtig behandelt, könnte die Anwendung fehlschlagen.
Wenn ein Benutzer aus einer anderen Domäne in der Gesamtstruktur versucht, sich auf einem RODC zu authentifizieren, muss der RODC in der Lage sein, auf einen vollständigen DC in seiner eigenen Domäne zuzugreifen, um das Vertrauensstellungskennwort zu erhalten, sodass die Authentifizierungsanforderung richtig an den DC in der Domäne übergeben werden kann. Wenn die Netzwerkverbindung zwischen dem RODC und dem vollständigen DC in seiner Domäne nicht verfügbar ist, schlägt die Authentifizierung fehl.

Fein abgestimmte Kennwortrichtlinien
Die Möglichkeit, mehr als eine Kennwortrichtlinie in der Domäne zu definieren, war wahrscheinlich das am häufigsten geforderte Feature für Windows Server 2008 ADDS. Wie Sie wahrscheinlich wissen, unterstützt jede Domäne in Windows 2000 und Windows Server 2003 Active Directory nur eine einzelne Kennwortrichtlinie, die auf alle Sicherheitsprinzipale in der Domäne angewendet wird. Wenn Sie eine separate Kennwortrichtlinie für eine bestimmte Gruppe von Benutzern benötigen, müssen Sie eine separate Domäne erstellen. Doch mithilfe eines neuen Features in Windows Server 2008 ADDS, das als fein abgestimmte Kennwortrichtlinien bezeichnet wird, können Sie mehrere Kennwortrichtlinien in einer Domäne definieren.
Die neue Strategie verwendet Gruppen zum Anwenden abgestimmter Kennwortrichtlinien auf Benutzer. Sie definieren die abgestimmte Kennwortrichtlinie zunächst durch Erstellen eines neuen msDS-PasswordSettings-Objekts im „CN=Password Settings Container, CN=System, DC=<domain>“-Container. Das msDS-PasswordSettings-Objekt (kurz PSO genannt) enthält Attribute, die der Kennwortrichtlinieneinstellung in der Gruppenrichtlinie entsprechen (siehe Abbildung 7).
Figure 7 Attribute im mSDS-PasswordSettings-Objekt (Close Figure 7)

Attribut | Beschreibung
mSDS-PasswordReversibleEncryptionEnabled | Boolescher Wert, der anzeigt, ob Kennwörter unter Verwendung umkehrbarer Verschlüsselung verschlüsselt sind.
mSDS-PasswordHistoryLength | Anzahl der in der Kennwortchronik verwalteten Einträge.
mSDS-PasswordComplexityEnabled | Boolescher Wert, der anzeigt, ob Einschränkungen für die Kennwortkomplexität aktiviert sind.
mSDS-MinimumPasswordLength | Ganzzahl, die die Mindestlänge des Kennworts definiert.
mSDS-MinimumPasswordAge | INTEGER8-Attribut, das das Mindestalter des Kennworts angibt, bevor es geändert werden kann.
mSDS-MaximumPasswordAge | INTEGER8-Attribut, das das Höchstalter des Kennworts angibt, bevor es geändert werden muss.
mSDS-LockoutThreshold | Ganzzahl, die die Anzahl fehlgeschlagener Anmeldungen vor einer Sperrung anzeigt.
mSDS-LockoutObservationWindow | INTEGER8-Attribut, das die Anzahl von Nanosekunden anzeigt, innerhalb derer fortlaufende fehlgeschlagene Anmeldungen erfolgen müssen, um eine Sperrung auszulösen.
mSDS-LockoutDuration | INTEGER8-Attribut, das die Anzahl von Nanosekunden anzeigt, die das Konto gesperrt ist.
Dann weisen Sie die Kennwortrichtlinie Benutzern oder Gruppen zu, indem Sie dem mehrwertigen mDS-PSOAppliesTo-Attribut des PSO die Benutzer- oder Gruppennamen hinzufügen. Wenn Sie sich erst einmal mit der Vorstellung vertraut gemacht haben, dass keine Kennwortrichtlinien auf Organisationseinheiten angewendet werden, ist alles recht einfach. Doch es gibt eine zusätzliche Komplexität.
Benutzer sind gewöhnlich Mitglieder vieler Gruppen. Was geschieht nun, wenn es mehrere widersprüchliche Kennwortrichtlinien gibt, die einem Benutzer aufgrund dieser Gruppenmitgliedschaften zugeordnet sind? In diesem Fall verwendet ADDS eine Rangfolgenbewertung, um zu bestimmen, welche Kennwortrichtlinie angewendet werden sollte. Sie funktioniert folgendermaßen:
  1. Wenn eine Kennwortrichtlinie direkt mit einem Benutzerobjekt (nicht über die Gruppenmitgliedschaft) verknüpft ist, wird diese Kennwortrichtlinie angewendet.
  2. Wenn mehrere Kennwortrichtlinien direkt mit dem Benutzer verknüpft sind, wird die Richtlinie mit dem niedrigsten Rangfolgewert (wie vom Wert des msDS-PasswordSettingsPrecendence-Attributs des PSO festgelegt) angewendet.
  3. Wenn es mehrere PSOs mit derselben Rangfolge gibt, wird das PSO mit dem niedrigsten objectGUID-Wert angewendet.
  4. Wenn keine PSOs direkt mit dem Benutzer verknüpft sind, bewertet ADDS die mit den Gruppen des Benutzers verknüpften PSOs. Wenn mehr als ein PSO vorhanden ist, wird das PSO mit dem niedrigsten Wert im msDS-PasswordSettingsPrecedence-Attribut angewendet.
  5. Wenn mehr als ein PSO mit demselben Rangfolgewert vorhanden ist, wird das PSO mit dem niedrigsten objectGUID-Wert angewendet.
  6. Wenn dem Benutzer keine PSOs zugeordnet sind, wird die Domänenkennwortrichtlinie verwendet.
Benutzerobjekte verfügen über ein neues Attribut namens msDS-ResultantPSO, mit dem geklärt werden kann, welches PSO für einen Benutzer gilt. Dieses Attribut enthält den „Distinguished Name“ des PSO, der das Kennwort dieses Benutzers steuert.
Fein abgestimmte Kennwortrichtlinien bieten Ihnen mehr Flexibilität als Sie wahrscheinlich je benötigen, doch Sie müssen diese Richtlinien sorgfältig verwalten und sie einfach halten. Es gibt kein einsetzbares Dienstprogramm zum Definieren abgestimmter Kennwortrichtlinien. Sie müssen entweder ADSIEdit verwenden oder sich nach einem Drittanbieterdienstprogramm umsehen.

Neu startbarer Active Directory-Dienst
Jedes Mal, wenn Sie einen Domänencontroller zur DIT-Wartung außer Betrieb nehmen, kommt es zu einer Störung der Servicelevels Ihres Netzwerks. Windows Server 2008-DCs bieten ein neues Feature, mit dem Sie den Verzeichnisdienst anhalten können, ohne den DC vollständig herunterzufahren.
Der NET STOP NTDS-Befehl hält ADDS auf einem Windows Server 2008-DC an. Wenn Sie dies tun, wird der Subsystemdienst für die lokale Sicherheitsautorität (Local Security Authority Subsystem Service, LSASS) auf dem DC weiter ausgeführt, doch alle zu ADDS gehörigen DLLs werden entladen, und der Verzeichnisdienst ist nicht mehr verfügbar. LSASS verhält sich dann im Wesentlichen so wie auf einem Mitgliedsserver, indem Domänenauthentifizierungsanforderungen an einen DC weitergeleitet werden. Da die DLLs, die ADDS behandeln, entladen sind, können Sie zu ADDS gehörige Patches anwenden oder eine Offlinedefragmentierung der DIT durchführen. ADDS wird dann einfach mit NET START NTDS gestartet. Für die Wiederherstellung der DIT nach einer Systemstatussicherung ist es jedoch immer noch erforderlich, im Verzeichnisdienst-Reparaturmodus zu starten.
Machen Sie sich unbedingt bewusst, dass der Verzeichnisdienst kein wirklicher Windows-Dienst ist. Er ist nach wie vor eine integrierte Komponente von LSASS, und Sie können LSASS nicht beenden, ohne den Computer herunterzufahren. Doch die Möglichkeit, den Verzeichnisdienst in Windows Server 2008 zu starten und zu beenden, ist eine praktische Option.

Sicherung und Wiederherstellung
Der gesamte Sicherungs- und Wiederherstellungsmechanismus wurde in Windows Server 2008 überarbeitet. Die Einzelheiten werden hier nicht erläutert, aber bei der neuen Windows Server-Sicherung gibt es einige Änderungen, die sich auf ADDS auswirken.
Windows Server-Sicherung ist eine volumebasierte Sicherungslösung, das heißt, es werden jeweils ganze Datenträgervolumes gesichert. Es werden nur Sicherungskopien auf Datenträgern (oder datenträgerähnlichen) Geräten erstellt. Bandunterstützung ist nicht vorhanden.
Es gibt eine Systemstatussicherungsoption für das WBADMIN-Befehlszeilensicherungsprogramm. Mithilfe des WBADMIN START SYSTEMSTATEBACKUP-Befehls können Sie jetzt ein Sicherungsabbild erstellen, das alle kritischen Systemdateien enthält, die zum Wiederherstellen von Active Directory auf einem Domänencontroller erforderlich sind. Es gibt zwar Potenzial für bis zu fünf Volumes im Sicherungssatz, doch die Volumes im Sicherungssatz enthalten dann nur die Dateien, die für eine Systemstatuswiederherstellung erforderlich sind. Noch unerfreulicher ist jedoch, dass Sie ab RC0-Build von Windows Server 2008 keine Systemstatussicherung auf einer Netzwerkfreigabe durchführen können. Zum Speichern von Systemstatussicherungsabbildern muss ein lokales Datenträgervolume verfügbar sein, und dieses Volume darf nicht Teil des Systemstatussicherungsvolumesatzes sein. Möglicherweise müssen Sie jedem Domänencontroller, auf dem Sie Systemstatussicherungen durchführen, ein neues Datenträgervolume hinzufügen.
Das Durchführen einer Systemstatuswiederherstellung ist einfach. Starten Sie einfach den DC im Verzeichnisdienst-Wiederherstellungsmodus, und führen Sie den Befehl WBADMIN START SYSTEMSTATERECOVERY aus. Das Ergebnis ist eine nicht autorisierend wiederhergestellte DIT, auf der Sie autorisierend bestimmte Objekte mithilfe von NTDSUTIL wiederherstellen können, genau wie dies in Windows Server 2003 der Fall war.
Ein Aspekt von Windows Server-Sicherung sollte besonders erwähnt werden: Sicherungsabbilder werden im Virtual Hard Disk (VHD)-Format gespeichert. Hierbei handelt es sich um dasselbe Format, das Microsoft Virtual Server 2005 zum Speichern virtueller Datenträgerabbilder verwendet. Folglich können Sie also ein mit Windows Server-Sicherung erstelltes Sicherungsabbild als Laufwerk in einem virtuellen Computer bereitstellen, der unter Microsoft Virtual Server ausgeführt wird. Dann können Sie den Sicherungsinhalt genau wie bei einem normalen Laufwerk durchsuchen!
Eine weitere Änderung in Bezug auf die ADDS-Sicherung ist die Möglichkeit, den Volumeschattenkopie-Dienst zum Erstellen von Active Directory-Snapshots zu einem bestimmten Zeitpunkt zu verwenden. Wenn Sie einen Snapshot mithilfe von NTDSUTIL erstellen, speichert der Volumeschattenkopie-Dienst das vorherige Abbild jedes Datenträgerblocks der DIT, bevor es von einem Updatevorgang überschrieben wird. Durch Kombinieren der gespeicherten vorherigen Abbilder mit der aktuellen Version der DIT kann der Volumeschattenkopie-Dienst unter sehr geringem Aufwand einen vollständigen Snapshot der DIT erstellen. Das Erstellen eines typischen Snapshots dauert unabhängig von der Größe der DIT nur ein paar Sekunden.
Für sich allein ist dies eine interessante Funktion, aber eigentlich nicht besonders nützlich. Doch in Windows Server 2008 umfasst ADDS ein Befehlszeilendienstprogramm namens DSAMAIN, wodurch das Snapshotabbild im schreibgeschützten Modus bereitgestellt werden kann. Dadurch wird, ähnlich einer ADLDS-Instanz, ein eigenständiger LDAP-Server bereitgestellt, der den Inhalt des Verzeichnisses zum Zeitpunkt des Snapshots enthält. Sie können das Verzeichnis mithilfe des LDP-Dienstprogramms oder anderer LDAP-Tools durchsuchen und Versionen der Verzeichnisobjekte von einem früheren Zeitpunkt abrufen.

SYSVOL-Replikation mit DFS-R
Windows Server 2003 R2 verfügte über einen überarbeiteten Dienst für ein verteiltes Dateisystem (Distributed File System, DFS), der einen völlig neuen Dateireplikationsmechanismus namens DFS-R umfasste. Er verwendet Remotedifferenzialkomprimierung, die den Dateireplikationsdatenverkehr wesentlich verringert, indem bestimmt wird, welche Blöcke einer Zieldatei repliziert werden müssen, um sie mit der Quelldatei zu synchronisieren. Doch Windows Server 2003 R2 verwendet immer noch den Dateireplikationsdienst (nicht DFS-R) zum Replizieren von SYSVOL zwischen Domänencontrollern. Aus diesem Grund war die SYSVOL-Replikation weiterhin Ursache von Problemen für Active Directory-Administratoren.
Beim Ausführen von Windows Server 2008 auf der Domänenfunktionsebene kann Windows Server 2008 SYSVOL mithilfe von DFS-R replizieren, wodurch die Geschwindigkeit und Stabilität der SYSVOL-Replikation verbessert wird. Aufgrund dessen ist es vernünftig, große Dateien in SYSVOL zu stellen, damit sie auf allen DCs verfügbar sind. Um DFS-R für SYSVOL zu verwenden, müssen Sie zunächst die alten SYSVOL-Daten mithilfe des DFSRMIG-Dienstprogramms nach DFS-R migrieren. Dieser Prozess umfasst vier Schritte:
  • Erstellen der für DFS-R erforderlichen Active Directory-Objekte.
  • Erstellen der neuen Dateistruktur für SYSVOL auf jedem Domänencontroller.
  • Umschalten aller Domänencontroller für die Verwendung des neuen SYSVOL.
  • Entfernen des alten SYSVOL.
Abhängig von der Größe des SYSVOL und der Anzahl vorhandener Domänencontroller kann dieser Prozess eine Weile dauern, doch die verbesserte Leistung und Zuverlässigkeit sind die Mühe wert.

Überwachen von Verbesserungen
Das Überwachungssystem in Active Directory für Windows Server 2003 hat gute und schlechte Seiten. Einerseits bietet es eine ziemlich umfassende, flexible und sichere Lösung zum Verfolgen von Änderungen im Verzeichnis. Andererseits gibt es die Ansicht, dass es bedeutende Probleme im Bereich der Benutzerfreundlichkeit aufweist.
Das Aktivieren der Überwachung von Verzeichnisänderungen auf einem Windows Server 2003-Domänencontroller läuft auf das Prinzip Alles oder Nichts hinaus – die Überwachung ist entweder ein- oder ausgeschaltet. Aufgrund des Volumens des Überwachungsdatenverkehrs auf einem ausgelasteten Unternehmens-DC kann die Überwachung daher unpraktisch werden. Das Konfigurieren des Überwachungssystems zum Produzieren der tatsächlich erforderlichen Meldungen durch Experimentieren mit einzelnen Sicherheitsbeschreibungen ist mühsam und fehleranfällig. Die Überwachungsmeldungen sind oft unverständlich und enthalten in vielen Fällen nicht die gewünschten Informationen, beispielsweise die Werte geänderter Attribute vorher und nachher. Außerdem ist das Sammeln, Korrelieren und Archivieren der Meldungen mehrerer Domänencontroller bei Verwendung der systemeigenen Windows-Tools eigentlich nicht durchführbar.
Das Verzeichnisdienstüberwachungssystem in Windows Server 2008 spricht einige dieser Probleme an. Zum einen gibt es vier neue Überwachungsunterkategorien zur Verzeichnisdienstüberwachung: „DS Access“, „DS Changes“, „DS Replication“ und „Detailed DS Replication“. Wenn Sie also nur Verzeichnisänderungen überwachen möchten, müssen Sie sich nicht durch alle Lese- und Replikationsereignisse durcharbeiten. Doch wenn Sie Objektlöschungen in das Überwachungsprotokoll aufnehmen wollen, müssen Sie „DS Access“ aktivieren. Dadurch werden Meldungen für alle DS-Objektzugriffe generiert, sodass im Grunde wieder zu viele Meldungen generiert werden. Außerdem ist es immer noch Ihre Aufgabe, die Sicherheitsbeschreibungen zum Generieren der Überwachungsmeldungen der für Sie wichtigen Objekte zu konfigurieren.
Die Überwachungsmeldungen wurden wesentlich bereinigt, sodass sie lesbar sind und die gewünschten Daten enthalten. Durch Verzeichnisänderungen werden jetzt Überwachungsprotokolleinträge generiert, die die alten und neuen Werte geänderter Attribute enthalten. Dies ist eine enorme Verbesserung. Der einzige Nachteil besteht darin, dass die alten und neuen Werte in separaten Überwachungsprotokolleinträgen erscheinen, sodass sie korreliert werden müssen, um die durchgeführte Änderung wirklich zu verstehen. Viele Add-On-Produkte zum Sammeln von Überwachungsprotokollen, einschließlich Microsoft-Überwachungssammeldienste, unterstützen eine solche Korrelation.

Verbesserungen der Benutzeroberfläche
Die Active Directory-Snap-Ins „Benutzer und Computer“, „Standorte und Dienste“ und „Domänen und Vertrauensstellungen“ waren zum Verwalten von Active Directory immer ausreichend. In Windows Server 2008 wurden die grundlegenden Verwaltungstools bereinigt und verfügen jetzt über einige praktische neue Features. Wenn Sie „Erweiterte Features“ aktivieren, zeigt das Dialogfeld „Eigenschaften“ für jedes Objekt eine zusätzliche Registerkarte mit der Bezeichnung „Attribut-Editor“ an. Dies ist die gleiche von ADSIEdit verwendete Attribut-Editorregisterkarte, mit der Sie alle Attribute des Objekts überprüfen und bearbeiten können. Die Registerkarte selbst bietet nun bessere Möglichkeiten zum Decodieren codierter Attribute, beispielsweise das userAccountControl-Attribut. Abbildung 8 zeigt, wie nahtlos der Attribut-Editor integriert ist.
Abbildung 8 Attribut-Editor in Active Directory-Benutzer und -Computer
Abbildung 8 Attribut-Editor in Active Directory-Benutzer und -Computer

Zusammenfassung
Neben den in diesem Artikel erörterten Hauptpunkten gibt es in ADDS in Windows Server 2008 noch viele andere Verbesserungen. KDC beispielsweise verwendet den 256-Bit-AES (Advanced Encryption Standard), wenn sich die Domäne auf der Windows Server 2008-Domänenfunktionsebene befindet. Sie können „Accidental Deletion Prevention“ (Zufällige Löschvorgänge verhindern) für Objekte aktivieren, indem Sie das entsprechende Kontrollkästchen auf der Objekt-Registerkarte für beliebige DS-Objekte markieren. Die Extensible Storage Engine, die den Datenverwaltungsdienst bereitstellt, wurde so verbessert, dass Ein-Bit-Fehlerkorrektur verwendet wird. Dadurch wird die Wahrscheinlichkeit verringert, dass ein Hardware- oder Softwarefehler im Datenträgersubsystem die DIT beschädigt. Der DNS-Dienst beginnt mit dem Verarbeiten von Anforderungen, noch bevor die DNS-Datenbank vollständig geladen wurde. Das DC-Locatormodul wurde so verbessert, dass es bei Nichtauffinden eines DC am gewünschten Standort versucht, einen DC am nächstgelegenen Standort zu suchen, statt einfach einen beliebigen, in der Domäne gefundenen DC zu verwenden. NTDSUTIL unterstützt jetzt RODCs und Volumeschattenkopie-Dienstsnapshots.
Windows Server 2008 bietet also eine wesentliche Anzahl von Verbesserungen in Active Directory-Domänendiensten. Insgesamt wird die Sicherheit und Verwaltbarkeit von ADDS hierdurch beträchtlich verbessert. Das Beste ist jedoch, dass zum Integrieren von Windows Server 2008 in Ihrer Active Directory-Umgebung keine Migration im großen Rahmen erforderlich ist. Vielmehr ist es ein einfacher und inkrementeller Prozess.

Gil Kirkpatrick ist CTO von NetPro und entwickelt seit 1996 Software für Active Directory. Zusammen mit Guido Grillenmeier von HP bietet er die beliebten Workshops zur Active Directory-Notfallwiederherstellung an. Gil Kirkpatrick ist darüber hinaus Gründer der Directory Experts Conference (www.dec2008.com).


 Sonderbeitrag: Windows Server&#160;2008: Erste Schritte mit IIS&#160;7.0
Sonderbeitrag: Windows Server 2008 Isaac Roybal

Erste Schritte mit IIS 7.0
Kurz zusammengefasst:
  • IIS 7.0-Architekturänderungen
  • Verwalten von IIS 7.0
  • Abwärtskompatibilität
  • IIS 7.0-Problembehandlung

Jeder IT-Shop ist anders. Jeder verfügt über seine eigenen einzigartigen Anforderungen und Ziele, insbesondere im Hinblick auf das Hosten von Websites oder Webdiensten. Webserver erfordern möglicherweise bestimmte „Zutaten“, um den Anforderungen der Organisation gerecht zu werden, des Weiteren stellt sich die Herausforderung,
dieses Rezept für mehrere Server bereitzustellen und sie alle effizient zu verwalten. Einige der wichtigsten Änderungen in IIS 7.0 haben genau dies zum Ziel – IT-Shops beim Erstellen eines Webservers oder einer Webfarm zu unterstützen.
Als ich mir die Liste all der großartigen Features in IIS 7.0 ansah, wollte ich die Details dazu unbedingt mit Ihnen teilen. Als ich erkennen musste, dass ich an dieser Stelle unmöglich alle erwähnen konnte, habe ich entschieden, zumindest die wichtigsten Features und Änderungen in IIS 7.0 zu beschreiben. Weitergehende Informationen finden Sie auf der IIS-Communitywebsite unter IIS.net.

Neue Architektur
Die wichtigsten Änderungen in IIS 7.0 beziehen sich auf die Architektur, die Anforderungsverarbeitung, die PHP-Anwendungsframeworkunterstützung und den Konfigurationsspeicher. Mit IIS 6.0 ging es bei den Features im Prinzip um „Alles oder Nichts“. Sie mussten alle Features installieren und konnten IIS nur mithilfe von ISAPI anpassen.
Bei IIS wird davon ausgegangen, dass ein Webadministrator mit einem Basissatz an Funktionalität starten und nur die zusätzliche Funktionalität hinzufügen möchte, die in seiner Umgebung benötigt wird. Sie kennen Ihre Umgebung am besten, und IIS 7.0 bietet Ihnen die Bausteine zur Erstellung Ihres eigenen benutzerdefinierten Webservers. Dadurch wird Ihr Verwaltungsaufwand durch Verringerung der Angriffsfläche Ihres Servers und Beseitigung des Bedarfs an Updates für Komponenten, die nicht verwendet werden, gesenkt. Der Schlüssel zu diesem neuen Ansatz ist die modulare Architektur von IIS 7.0.
IIS 7.0 hat ein neues Design, mit dem Sie die auf dem Server zu installierende Funktionalität, auch als Module bezeichnet, auswählen können. Diese Module werden direkt an die integrierte Anforderungspipeline angeschlossen. Dieses neue modulare Design bietet mehrere Vorteile, einschließlich der Verringerung sowohl der Angriffsfläche als auch des Platzbedarfs Ihres Webservers.
IIS verfügt derzeit über 40 Standardmodule – beispielsweise sind die Standardauthentifizierung, die anonyme Authentifizierung und die Windows®-Authentifizierung nun individuelle Module, die einzeln der Anforderungspipeline hinzugefügt werden können. Für eine einfache Klassifizierung sind die Module in acht Unterkategorien gruppiert (siehe Abbildung 1).
Abbildung 1 IIS 7.0-Module sind in acht Funktionsbereiche unterteilt
Abbildung 1 IIS 7.0-Module sind in acht Funktionsbereiche unterteilt
Dies bedeutet, dass Sie jetzt die Möglichkeit haben, einen benutzerdefinierten Webserver zu erstellen, der exakt auf Ihre Umgebung zugeschnitten ist. Was aber, wenn Sie eine Funktionalität benötigen, die von den 40 Standardmodulen nicht geboten wird, wie beispielsweise eine Art benutzerdefinierte Authentifizierung oder ein Inhaltsmodifizierer? Kein Problem. Sie können ein Modul in systemeigenem oder verwaltetem Code schreiben, um diese Anforderung zu erfüllen, und dieses direkt an die Pipeline anschließen. Dies ermöglicht Microsoft außerdem, neue Module einzeln zu schreiben und zu veröffentlichen, damit Sie nicht auf das nächste Service Pack oder die nächste große Produktversion warten müssen. IIS 7.0 bietet Ihnen auch die Möglichkeit, die 40 Standardmodule nach Belieben durch Ihren eigenen benutzerdefinierten Module zu ersetzen. Weitere Informationen zur Erstellung Ihrer eigenen Module finden Sie unter IIS.net.

Integrierte Anforderungspipeline
Sehen Sie die integrierte Anforderungspipeline als grundlegenden Satz linearer Schritte, die jedes Mal stattfinden müssen, wenn eine Seite erstellt wird (siehe Abbildung 2). Normalerweise muss eine Art Authentifizierung stattfinden, gefolgt von der Autorisierung, Inhalt abzurufen, der Bestimmung und Ausführung des für diesen Inhalt benötigten Handlers, der Durchführung erforderlicher Protokollierung und schließlich dem Senden einer Antwort. Die integrierte Anforderungspipeline bietet IIS 7.0 die Flexibilität, verschiedene Anwendungsframeworks gleichzeitig auszuführen. Sie können beispielsweise mit einem benutzerdefinierten Protokollierungsmodul Formularauthentifizierung über PHP-Inhalt ausführen, und das alles in derselben Pipeline.
Abbildung 2 Integrierte Pipeline und Module in IIS 7.0
Abbildung 2 Integrierte Pipeline und Module in IIS 7.0
Jede Website auf dem Server verfügt über eine integrierte Anforderungspipeline und kann in einem von zwei Modi, „Integriert“ und „Klassisch“, ausgeführt werden. Mit „Integriert“, dem Standardmodus, können bestimmte Funktionalitäten an die Pipeline angeschlossen werden, was Ihnen eine fein abgestimmte Steuerung des Anforderungsprozesses ermöglicht. Zum Zweck der Kompatibilität reproduziert der Modus „Klassisch“ IIS 6.0/ISAPI-Funktionalität über ein ISAPI-Modul für die Pipeline. Dies ist sehr hilfreich für die Migration Ihrer Anwendungen zu IIS 7.0.

Standardinstallation
Nun zur Einrichtung Ihres neuen modularen Webservers. Wenn Sie sich die Standardinstallation von IIS 7.0 anschauen, stellen Sie fest, dass nur 10 Module (wenn Sie den Windows-Prozessaktivierungsdienst einrechnen) enthalten sind. Das IIS 7.0-Setup bietet beim Installieren der Webserverrolle die Basisfunktionalität von IIS, und zwar nur die Module, die für das Bereitstellen von statischem Inhalt, wie einfachem HTML oder klassischem ASP, benötigt werden. Was danach auf dem Server installiert wird, ist ganz Ihnen überlassen. Dies ist die in einer Standardinstallation enthaltene Funktionalität:
  • häufige HTTP-Features einschließlich „Statischer Inhalt“, „Standarddokument“, „Verzeichnis durchsuchen“ und „HTTP-Fehler“
  • Features für Systemzustand und Diagnose wie z. B. HTTP-Protokollierung und Anforderungsüberwachung
  • Sicherheitsfeatures wie z. B. Anforderungsfilterung
  • Leistungsfeatures wie z. B. die Komprimierung statischer Inhalte
  • Verwaltungstools einschließlich der IIS-Verwaltungskonsole
  • Windows-Prozessaktivierungsdienst
Wie Sie sehen, ist dies ein Server mit Minimalfunktionalität, der weder ASP.NET oder noch sonstige neue IIS 7.0-Funktionalität wie die Diagnose- und Problembehandlungsfeatures enthält. Zusätzliche Funktionalität auf dem Server zu ermöglichen, wie z. B. die Möglichkeit, dynamischen Inhalt wie ASP.NET und FastCGI (PHP) zu bieten, ist kein Problem. Wählen Sie den Satz von Modulen aus, den Sie über die Option „Rollendienste hinzufügen“ der Webserverrolle innerhalb des Windows Server® 2008-Server-Managers installieren möchten.

Neuer Konfigurationsspeicher
Eine weitere wichtige Änderung von IIS 7.0 zur Erleichterung Ihrer Arbeit ist der neue Konfigurationsspeicher. Die Metabasis, jetzt eine optional installierte Komponente für Abwärtskompatibilität, wurde durch ein XML-Konfigurationssystem ersetzt. Ich kann Ihre Gedanken erraten: „Aber die Metabasis war XML!“ Ja, war sie. Sie war jedoch umständlich und nicht einfach zu lesen (zumindest für Menschen). Sie wurde durch ein flexibleres XML-System ersetzt. Wie ASP.NET verwendet IIS 7.0 .config-Dateien – leere, einfache, portable und leicht zu lesende .config-Dateien.
Ein Wechsel zu diesem Format bedeutet, dass das Konfigurationssystem nun computerunabhängig ist, im Unterschied zur Metabasis, die auf einen einzelnen Computer abgestimmt ist. Als Ergebnis können Sie das Konfigurationssystem nun einfach auf andere Server mit einem einfachen Drag und Drop oder xcopy übertragen.
Dieses neue Konfigurationssystem wirkt außerdem Wunder für Webfarmen durch Nutzung eines neuen IIS 7.0-Features namens „Freigegebene Konfiguration“. Da dieses neue Konfigurationssystem portabel ist, können Sie eine Master-.config-Datei für alle Knoten in der Farm freigeben. „Freigegebene Konfiguration“ ermöglicht Ihnen das Exportieren der Konfiguration eines bekannten guten Präproduktionsservers und das Freigeben dieses Servers in Ihrem Produktions- oder Ihrer Liveumgebung.
Beim Exportieren der .config-Datei müssen Sie diese mit einem Verschlüsselungsschlüssel-Kennwort versehen. Dieses schützt die .config-Datei vor einem nicht autorisierten Webserver, der versucht, Ihre Serverkonfiguration ohne Autorisierung nachzuahmen.
Das Aktivieren von „Freigegebene Konfiguration“ ist einfach. Wählen Sie im Serverknoten von IIS-Manager „Freigegebene Konfiguration“, das sich unter dem Verwaltungsabschnitt des Aufgabenbereichs befindet. Aktivieren Sie einfach „Freigegebene Konfiguration aktivieren“, geben Sie den physischen Pfad der Konfiguration an, die Sie freigeben möchten (in der Regel ist dies eine UNC-Freigabe), geben Sie die erforderlichen Anmeldeinformationen für den Zugriff auf den physischen Pfad ein, und klicken Sie auf „Anwenden“. Wenn die .config-Datei gefunden wurde, werden Sie zur Eingabe ihres Verschlüsselungskennworts aufgefordert. Nachdem dieser Prozess abgeschlossen ist, starten Sie IIS-Manager neu, damit er die neue .config-Datei abruft.
Die Struktur des neuen Konfigurationssystems unterscheidet sich von der, die Sie gewöhnt sind. Daher sollen hier die Grundlagen beschrieben werden. Wie in Abbildung 3 gezeigt, wurde die Konfiguration von IIS 7.0 in zwei Kategorien unterteilt, serverweite Einstellungen und websitespezifische Einstellungen. Alle serverweiten Einstellungen werden in applicationhost.config gespeichert, das sich unter %systemroot%\windows\system32\inetsrv\config befindet. Es enthält alle installierten Module, Websites auf dem Server usw. Websitespezifische Einstellungen werden in einzelnen web.config-Dateien gespeichert.
Abbildung 3 Es gibt eine .config-Datei für serverweite Einstellungen und einzelne, separate .config-Dateien für jede Website auf diesem Server
Abbildung 3 Es gibt eine .config-Datei für serverweite Einstellungen und einzelne, separate .config-Dateien für jede Website auf diesem Server
Wenn Sie ASP.NET verwendet haben, sind Sie wahrscheinlich mit web.config-Dateien vertraut. IIS 7.0 verwendet web.config-Dateien zum Speichern von Einstellungen, die für einzelne Websites spezifisch sind, wie beispielsweise das Standarddokument und die Anwendungseinstellungen einer Website sowie ASP.NET-Einstellungen. Dies bedeutet, dass Sie für jede Website auf Ihrem Server über eine web.config-Datei verfügen.
Die web.config-Datei einer Website befindet sich im physischen Pfad der Website, wie beispielsweise %systemroot%\inetpub\wwwroot. Dieses Design erzielt dieselben Portabilitätsvorteile wie zuvor erwähnt, jedoch auf Websiteebene. Sie können eine Website problemlos z. B. auf einem Testserver entwickeln und dann die web.config- und Anwendungsdateien der Website einfach per Drag und Drop oder mittels xcopy zu einem Produktionsserver kopieren.
Achten Sie beim Portieren oder Freigeben von .config-Dateien auf computerspezifische Informationen wie IP-Adressen und Laufwerkbuchstaben. IIS 7.0 bietet mit der Unterstützung für Betriebssystemumgebungsvariable (wie z. B. %systemroot%) eine Lösung für ein entsprechendes mögliches Versehen. Stellen Sie auch sicher, dass der gleiche Satz von Modulen auf Test- und Produktionsservern installiert ist. Dadurch werden unerwartete Anwendungsfehler vermieden. Fehler können auch auftreten, wenn web.config auf ein Modul verweist, das nicht installiert ist, oder wenn ein Standardmodul mit einem benutzerdefinierten Modul im Konflikt steht.

Verwalten Ihres Webservers
Sie verfügen nun über diesen großartigen, anpassbaren, flexiblen und portablen Webserver. Wie werden Sie ihn verwalten? Die Verwaltung war ein großer Bestandteil der Planung und Erstellung von IIS 7.0, und es gibt mehrere Möglichkeiten, administrative Aufgaben abzuwickeln.
Verwaltungseinstellungen fallen in der Regel in mindestens eine von drei Kategorien: Point-and-Click-Verwaltung von der Benutzeroberfläche aus, Eingabe von Befehlen in der Befehlszeile und das Schreiben von Skripts zur weitgehenden Automatisierung. Beginnen wir mit der Benutzeroberfläche.
In IIS 6.0 verfügte das Benutzeroberflächen-MMC-Snap-In (Microsoft® Management Console) über zwei grundlegende, vertraute Ansichten, die Strukturansicht und die Registerkartenansicht. Das Anzeigen von Einzelheiten einer Einstellung erforderte ein Klicken mit der rechten Maustaste und das Auswählen von „Eigenschaften“, und es wurden eine Reihe von Registerkarten sowie Optionsfelder und Kontrollkästchen angezeigt.
Die Benutzeroberfläche in IIS 7.0 wurde glücklicherweise komplett überarbeitet. Diese Benutzeroberfläche namens „IIS-Manager“ wurde entworfen, um einen aufgabenorientierten Ansatz, wie in Abbildung 4 gezeigt, zu ermöglichen. Es gibt außerdem einen Remote Manager für kompatible Clients, wie z. B. Windows XP und Windows Server 2003. Sie können ihn über IIS.net/downloads herunterladen.
Abbildung 4 Neue Benutzeroberfläche in IIS 7.0
Abbildung 4 Neue Benutzeroberfläche in IIS 7.0
Die neue Benutzeroberfläche besteht aus dem Fensterbereich für Verbindungen auf der linken Seite, dem Fensterbereich für Aktionen auf der rechten Seite und dem Aufgabenbereich oder Arbeitsbereich in der Mitte. Die Verbindungsmanagerstruktur auf der linken Seite ähnelt der IIS 6.0-Strukturansicht mit übergeordneten und untergeordneten Knoten. Neu in der Strukturansicht ist die Funktion zur Erstellung neuer Verbindungen, zum Speichern aktueller Verbindungen oder zum Löschen vorhandener Verbindungen. Der Aufgabenbereich ist die größte Verbesserung der Benutzeroberfläche, wobei zwei Ansichten zur Auswahl stehen. Die Featureansicht übernimmt alle konfigurierbaren Eigenschaften von IIS aus der alten Registerkartenansicht und gruppiert sie nach administrativem Bereich, wie z. B. IIS, Verwaltung und Sicherheit.
ASP.NET-Eigenschaften wurden ebenfalls in IIS-Manager integriert, was die Verwendung eines zusätzlichen MMC-Snap-Ins überflüssig macht. Jede konfigurierbare Eigenschaft verfügt über ihr eigenes Symbol, was die Suche erleichtert. Da IIS-Manager als eine Windows Forms-Anwendung erstellt wurde, können Sie problemlos Plug-In-Symbole für alle benutzerdefinierten Module oder von Ihnen programmierten Funktionen hinzufügen.
Die zweite Ansicht des Aufgabenbereichs ist die Inhaltsansicht, die der in IIS 6.0 darin ähnelt, dass Sie anzeigen können, was sich im Inhaltsverzeichnis einer Website befindet, und Aktionen basierend auf diesem Inhalt ausführen können. Neu ist die Möglichkeit, einen bestimmten Inhalt auszuwählen, beispielsweise eine bestimmte Website, und anschließend zur Featureansicht umzuschalten, um bestimmte Einstellungen für den ausgewählten Inhalt aufzurufen, was Ihnen eine präzise Steuerung bis hinunter zur Seitenebene ermöglicht.

Weitere Verwaltungsmöglichkeiten
Für diejenigen, die die Befehlszeile bevorzugen, gibt es ein leistungsfähiges neues Tool namens „APPCMD.exe“, mit dem Sie einfache Aufgaben wie das Beenden einer Website oder das Sichern der aktuellen .config-Datei sowie kompliziertere Aufgaben wie das Suchen nach dem Konfigurationsschema durchführen können. Die Syntax ist sehr einfach:
APPCMD (command) (object-type) <identifier> </parameter1:value1 ...>.
Geben Sie zur Auflistung aller verfügbaren Objekte für APPCMD Folgendes ein:
APPCMD /?
Oder geben Sie, wenn Sie die für einen bestimmten Objekttyp verfügbaren Befehle anzeigen möchten, Folgendes ein:
APPCMD (object-type) /?
Für alle Programmierer wurden IIS 7.0 eine API für verwalteten Code namens „Microsoft.Web.Administration“ und ein neuer WMI-Anbieter (Windows Management Instrumentation, Windows-Verwaltungsinstrumentation) hinzugefügt. Diese zwei Methoden erschließen eine Vielzahl von Optionen zur Skripterstellung, Automatisierung und zum Schreiben von Tools zur Verwaltung von IIS 7.0. Beide können mit Windows PowerShell® verwendet werden, und der WMI-Anbieter kann auch mit VBScript und KScript® verwendet werden. Zusätzliche Informationen finden Sie unter blogs.msdn.com/carlosag/archive/2006/04/17/MicrosoftWebAdministration.aspx.

Remoteverwaltung und delegierte Verwaltung
IIS 7.0 bietet neue Möglichkeiten zur Remoteverwaltung Ihres Servers, Websites, Webanwendungen und sicher delegierter Verwaltungsrechte für Nichtadministratoren. Zunächst sehen wir uns die neuen Remoteverwaltungsfunktionen an und untersuchen, wie diese Ihnen das Leben leichter machen können.
In der Vergangenheit gab es zwei Möglichkeiten für die Remoteverwaltung eines IIS-Servers: mithilfe der Remoteverwaltungswebsite oder mithilfe von Remotedesktop-/Terminaldiensten für den Zugriff auf die Benutzeroberfläche. Wenn Sie sich jedoch außerhalb Ihrer Firewall oder an einem anderen Standort befanden, waren diese Optionen nicht sehr hilfreich. IIS 7.0 löst dies durch Bereitstellung von Remoteverwaltungsfunktionen direkt in der Benutzeroberfläche, die mit firewallfreundlichem HTTPS arbeiten.
Die Remoteverwaltung in IIS 7.0 erleichtert die Arbeit auf mehrere Arten. Erstens erleben Sie dieselbe Benutzeroberflächenfunktionalität wie bei einer lokalen Anmeldung. Zweitens besteht keine Notwendigkeit, Ports Ihrer Firewall zu öffnen, da die Kommunikation über HTTPS erfolgt. Außerdem können Sie nun mehrere Server von einer einzelnen Benutzeroberfläche aus verwalten. Es besteht keine Notwendigkeit, mehrere Remotedesktop- oder Remotewebsitefenster gleichzeitig geöffnet zu haben.
Der eigentliche Remoteverwaltungsdienst innerhalb von IIS 7.0 ist im Grunde eine kleine Webanwendung, die als separater Dienst unter einem lokalen Windows NT®-Dienstkonto namens „NT Service\WMSVC“ ausgeführt wird. Dieses Design bewahrt die Remoteverwaltungsfunktionalität, selbst wenn der IIS-Server selbst nicht reagiert.
Wie die meisten Features innerhalb von IIS 7.0 ist die Remoteverwaltung aus Sicherheitsgründen nicht standardmäßig installiert. Um die Remoteverwaltungsfeatures zu installieren, fügen Sie Rollendienste für die Webserverrolle im Windows Server 2008-Server-Manager hinzu, der unter den Verwaltungstools gefunden werden kann. Sobald dieses Feature installiert ist, müssen Sie Remoteverbindungen aktivieren und den WMSVC-Dienst starten, da dieser standardmäßig beendet wurde.
Die Standardstarteinstellung des WMSVC-Diensts ist „Manuell“. Wenn der Dienst nach einem Neustart automatisch starten soll, müssen Sie die Einstellung in „Automatisch“ ändern. Dies können Sie über die Befehlszeile durch folgende Eingabe erreichen:
sc config WMSVC start=auto
Wenn Sie Remoteverbindungen über den Verwaltungsdienst aktivieren, wird eine Liste mit Einstellungen angezeigt, wie z. B. „Anmeldeinformationen für Identität“, „Verbindungen“ und „Einschränkungen für IPv4-Adressen“. Die einzige Entscheidung, die an dieser Stelle wichtig ist, ist die Festlegung, welchem Satz von Identitätsanmeldeinformationen die Berechtigung für eine Verbindung mit IIS 7.0 gewährt werden soll: Nur Windows-Anmeldeinformationen oder Windows- und IIS-Manager-Anmeldeinformationen.
Die erste Option gibt an, dass nur Windows-Benutzerkonten erlaubt sein sollen, unabhängig davon, ob es sich um lokale oder Domänenbenutzerkonten handelt. Die zweite Option beinhaltet sowohl Windows-Benutzer als auch eine Art von Konto, das ganz neu in IIS 7.0 ist und nicht mit Windows-Benutzerkonten in Verbindung steht: IIS-Manager-Benutzer. Mit „IIS-Manager-Benutzer“ können Administratoren Benutzerkonten erstellen, die nur im Kontext von IIS 7.0 bekannt sind und keinen Zugriff auf das Betriebssystem haben. Schließlich bietet IIS standardmäßig ein selbstsigniertes Zertifikat für den Einstieg, aber es empfiehlt sich, ein gültiges signiertes SSL-Zertifikat hinzuzufügen. Wenden Sie nun einfach Ihre Einstellung an, und starten Sie den Dienst.
Für zusätzliche Kontrolle und Sicherheit verfügen IT-Administratoren über die Möglichkeit, Verwaltungsaufgaben einzelner Websites oder Webanwendungen für Nichtadministratoren sicher zu delegieren.
Die delegierte Verwaltung ist im Grunde eine Remoteverwaltung, sie beschränkt jedoch den Zugriffsbereich auf einzelne Website oder Webanwendungen. Das Feature „IIS-Manager-Benutzer“ ist hier besonders nützlich. Sie können IIS-Benutzer für diese temporären Websitebesitzer erstellen und Berechtigungen delegieren, damit sie ihre eigene Website oder Anwendung verwalten können. Diese Benutzer haben keinen Zugriff auf serverweite Einstellungen und können nur Einstellungen für ihre spezifische Website oder Webanwendung einrichten.
Es kann auch festgelegt werden, welche Features und Einstellungen Benutzer ändern können und welche in der Benutzeroberfläche angezeigt werden. Wenn Sie beispielsweise nicht möchten, dass jemand den für seine Website verwendeten Authentifizierungstyp ändert, können Sie dieses Feature entweder auf „schreibgeschützt“ oder „nicht geerbt“ setzen. Wenn ein Feature schreibgeschützt ist, können Benutzer nach wie vor auf das Feature zugreifen und die Einstellung festlegen, jedoch keine Änderungen vornehmen. Bei der Einstellung „nicht geerbt“ wird das Featuresymbol nicht in der IIS-Manager-Ansicht des delegierten Benutzers angezeigt. Mit dieser Art der Featuredelegierung können Sie anderen Benutzern streng kontrollierten Zugriff bieten, ohne administrative Kontrolle über den Webserver zur Verfügung zu stellen.

Übergang zu IIS 7.0
Bei der Erstellung von IIS 7.0 wollte das Team sicherstellen, dass der Übergang so reibungslos wie möglich verläuft, und ermöglichte dazu die Verwendung einiger Ihrer vorhandenen Verwaltungstools und -skripts für IIS 6.0. Es wurde viel in die Abwärtskompatibilität von IIS 7.0 investiert, damit es mit Ihren IIS 6.0-Skripts funktioniert. Es gibt einen ganzen Satz von Tools – von IIS 6.0-Metabasiskompatibilität bis hin zur eigentlichen IIS 6.0-Verwaltungskonsole –, den Sie unter dem IIS 6.0-Verwaltungskompatibilitätsknoten beim Setup installieren können.
Die IIS 6.0-Metabasiskompatibilitäts-Infrastruktur verwendet eine Komponente namens „ADOMapper“. Sie ermöglicht Ihnen das Ausführen Ihrer ABO (Administratorbasisobjekt)- und ADSI (Active Directory Service Interfaces)-IIS 6.0-Metabasisskripts unter dem neuen Konfigurationssystem, mit einer Beschränkung auf die Funktionen von IIS 6.0. Daher ist es nicht möglich, neue IIS 7.0-Eigenschaften zu lesen oder zu schreiben, auf neue Laufzeitdaten zuzugreifen oder ASP.NET-Eigenschaften oder web.config-Dateien zu lesen oder zu schreiben.

Problembehandlung und Diagnose
Problembehandlung und Diagnose waren seit jeher zeitaufwändige Aufgaben. Das Durcharbeiten durch Protokolle und der Versuch, ein Problem in einer großen Webfarm oder auch nur auf einem einzelnen Server zu reproduzieren, können sehr schwierig sein. IIS 7.0 verfügt über ein Tool namens „Ablaufverfolgung für Anforderungsfehler“, um diese Arbeit zu erleichtern und Zeit zu sparen. Es kann in vielen Situationen nützlich sein, u. a. wenn eine Anforderung nicht reagiert oder Fehler erzeugt sowie für die Untersuchung von Authentifizierungs- und Autorisierungsproblemen.
„Ablaufverfolgung für Anforderungsfehler“ verwendet Ablaufverfolgungsregeln als Kriterium für die Suche nach Fehlern. Ablaufverfolgungsregeln können für die Suche nach Verhaltensweisen oder Fehlern erstellt werden, und zwar durch Angabe der Art des Inhalts, den Sie verfolgen möchten (wie z. B. der gesamte Inhalt auf dem Server, nur ASP.NET Inhalt oder benutzerdefinierter Inhalt wie z. B. PHP), sowie durch Angabe der Bedingungen, unter denen die Ablaufverfolgung beginnen soll (wie z. B. ein bestimmter zurückgegebener Statuscode, die benötigte Zeit für den Aufbau der Seite, der Ereignisschweregrad oder eine Kombination dieser Bedingungen).
Nehmen Sie zum Beispiel an, Benutzer berichten, dass es zu lange dauert, bis eine Website geladen ist. Es ist in jedem Fall sehr schwierig, dieses Szenario zu reproduzieren, v. a. wenn Sie tausende von Aufrufen pro Stunde haben. Mit „Ablaufverfolgung für Anforderungsfehler“ fügen Sie einfach eine Ablaufverfolgungsregel hinzu, um mit dem Protokollieren zu beginnen, wenn eine Seite für das Laden länger braucht als gewünscht – sagen wir zwei Sekunden in diesem Beispiel –, und warten darauf, dass der Server das Problem selbst reproduziert (siehe Abbildung 5).
Abbildung 5 Verwenden von „Ablaufverfolgung für Anforderungsfehler“ zur Problembehandlung
Abbildung 5 Verwenden von „Ablaufverfolgung für Anforderungsfehler“ zur Problembehandlung
Der Unterschied zwischen „Ablaufverfolgung für Anforderungsfehler“ und herkömmlicher Protokollierung besteht darin, dass ersteres nur dann protokolliert, wenn ein bestimmtes Anforderungsfehlerkriterium erfüllt ist. Bei der Protokolldatei selbst handelt es sich um XML mit einem XML-Stylesheet, wodurch sie übersichtlich und leicht zu lesen ist. Wie die meisten anderen IIS 7.0-Features ist dieses nicht standardmäßig installiert und kann beim Setup im Abschnitt zu Systemzustand und Diagnose gefunden werden. Sie müssen es auch innerhalb des IIS-Managers aktivieren.
IIS 7.0 stellt für alle Administratoren einen großen Fortschritt dar. Seine neue Architektur und seine neuen Funktionen bieten die Flexibilität, die zur Anpassung an Ihre sich ständig verändernde Umgebung erforderlich sind. Mit den Verwaltungsfeatures, den Abwärtskompatibilitätstools und den Problembehandlungsfunktionen kann es schon jetzt in Ihrer vorhandenen Umgebung bereitgestellt und eingesetzt werden.

Isaac Roybal ist ein Produktmanager für Windows Server bei Microsoft. Sein Verantwortungsbereich umfasst alle webbezogenen Themen mit Windows Server. Isaac arbeitet mit Windows Server seit Windows NT 3.51 und IIS 4.0. Davor war er Operations Program Manager für den Bereich „Office Internet Platform and Operations“. Er verfügt über eine MCSE-Zertifizierung in Windows NT 4.0, Windows 2000 und Windows Server 2003.


 Sonderbeitrag: Windows Server&#160;2008: Richtliniengesteuerter Netzwerkzugriff mit Windows Server&#160;2008
Sonderbeitrag: Windows Server 2008 Ian Hameroff and Amith Krishnan

Richtliniengesteuerter Netzwerkzugriff mit Windows Server 2008
Kurz zusammengefasst:
  • Abwägung zwischen Netzwerkzugriff und Sicherheit
  • Richtliniengesteuerter Ansatz für Netzwerkzugriff
  • Neue Sicherheitstechnologien in Windows Server 2008

Es wurde viel geschrieben über das Verschwinden herkömmlicher Netzwerkumkreise, verursacht durch ein zunehmend mobiles Personal und die wachsende Vielfalt von Benutzern und Geräten, die
Zugriff auf die IT-Ressourcen einer Organisation benötigen. Um die Produktivität zu erhöhen, treiben Benutzer und Branchenbesitzer die Nachfrage nach einer Verbindungsfunktionalität an, die sowohl fließend als auch frei von aufwändigen Verfahren ist. Zu dieser komplexen Situation kommen zunehmende Belastungen durch Einhaltung gesetzlicher Bestimmungen, die sich entwickelnde Bedrohungslage und die Risiken, die mit der Dezentralisierung von Daten in Verbindung stehen, hinzu.
Dadurch sind Windows®-Administratoren zu einer schwierigen Gratwanderung hinsichtlich der Sicherheit gezwungen: Wie kann einfacher Zugriff auf Ressourcen unter Berücksichtigung stetig wachsender Informations- und Netzwerksicherheitsanforderungen gewährt werden.
Es mag keine einzelne Lösung für alle diese Herausforderungen geben, als Windows-Administratoren steht Ihnen jedoch eine Reihe von Tools zur Verfügung, mit denen Sie die Sicherheitsvorkehrungen (wie Edgefirewalls), die Sie bereits getroffen haben, optimieren können. Eine großartige Möglichkeit, das angemessene Verhältnis zwischen Zugriff und Sicherheit zu finden, ist der Übergang von herkömmlichen Konnektivitätsmodellen zu einem Modell, das den Netzwerkzugriff auf logischere, richtliniengestützte Weise zu definieren sucht.

Richtliniengesteuerter Ansatz für Netzwerkzugriff
Netzwerkressourcen
  • IPsec
  • Windows-Firewall mit erweiterter Sicherheit
  • Server- und Domänenisolation
  • Netzwerkzugriffsschutz für Windows Server 2008

Richtliniengesteuerter Netzwerkzugriff versucht, die vorhandenen Einschränkungen, die bei einem alleinigen Verlassen auf Netzwerktopologieedges vorhanden sind, zu beseitigen. Können Sie zum Beispiel wirklich feststellen, dass ein Gerät vertrauenswürdig und für eine Verbindung mit den Servern autorisiert ist, die Ihre CRM-Anwendung (Customer Relationship Management) ausführen, nur weil es an einen Ihrer Ethernet-Switchports hinter der Unternehmensfirewall angeschlossen ist?
Stattdessen steuert das neue Modell Zugriffsentscheidungen durch Authentifizieren sowohl des Sicherheitsstatus des Geräts als auch der Identität des Benutzers, der den Zugriff anfordert, unabhängig vom Standort, an dem die Verbindung initiiert wird. Nach der Authentifizierung kann dann dasselbe Framework verwendet werden, um zu autorisieren, auf welche Informationen und Ressourcen zugegriffen werden kann.
Der Übergang von einem defensiven Ansatz zu einem verstärkt zugriffsgesteuerten Ansatz ist an eine Reihe von Voraussetzungen gebunden, unter anderem Mechanismen, die die Identität des verbindenden Hosts und Einhaltung von Richtlinien (Kompatibilität) überprüfen, eine vertrauenswürdige Benutzeridentität ausgeben und basierend auf diesen Attributen den Netzwerkzugriff dynamisch steuern können. Um die Verwaltung dieser Elemente zu vereinfachen, ist ein zentralisierter Richtlinienspeicher ebenfalls eine wichtige Komponente.
Die Annahme eines richtliniengesteuerten Ansatzes kann Ihnen helfen, eine Reihe potentiell verschiedenartige Netzwerkzugriffs- und Hostsicherheitssteuerungen in einer umfassenderen Lösung zusammenzuführen. Dies ermöglicht Ihnen wiederum das Festlegen von Grundregeln für den Netzwerkzugriff auf logischer Ebene oberhalb der Verbindungsstruktur, was herkömmliche bewährte Methoden für die Tiefenverteidigung weiterentwickelt.
Wenn ein Benutzer beispielsweise seinen Laptop mit dem Drahtlosnetzwerk der Organisation verbindet, kann das Gerät auf die Einhaltung der neuesten Sicherheitskonfigurationsanforderungen überprüft werden. Nachdem festgestellt wurde, dass der Laptop über alle aktuellen Antivirusupdates und wichtigen Sicherheitspatches verfügt und dass alle seine Endpunktsicherheitssteuerungen aktiviert sind – wie eine Hostfirewall – kann der Zugriff auf das Unternehmensnetzwerk gewährt werden. Wenn der Benutzer daraufhin versucht, auf eine Geschäftsanwendung zuzugreifen, kann die Kombination aus dem Integritätsstatus des Laptops und der Netzwerkidentität des Benutzers verwendet werden, um zu bestimmen, ob er autorisiert ist, auf die Ressourcen zuzugreifen, die die Anwendung hosten. Durch das Arbeiten auf dieser logischen Ebene oberhalb der physischen Netzwerkinfrastruktur können die Richtlinien fortlaufend durchgesetzt werden, selbst wenn der Benutzer von einer drahtlosen zu einer Kabelverbindung oder sogar einer Remotezugriffsverbindung wechselt.
Nach der Implementierung kann richtliniengesteuerter Netzwerkzugriff eine nahtlosere Verbindungsfunktionalität für Benutzer bieten, ohne die Sicherheit zu gefährden. Für Administratoren kann das Anheben der Netzwerkzugriffssteuerungen von Switchports oder Remotezugriffs-Gatewaykonfigurationen auf eine höhere Ebene eine einfachere Verwaltungsfunktionalität bieten. In beiden Fällen ist das Endergebnis erhöhte Produktivität und eine generelle Verbesserung der Integrität des Netzwerks der Organisation, selbst wenn die Netzwerke Hosts für Akteure mit unterschiedlichen Zugriffsrechten sind, wie z. B. Gäste, Hersteller, Partner und Mitarbeiter.
Wie bei jedem Sicherheitsprojekt besteht der erste Schritt bei der Implementierung von richtliniengesteuertem Netzwerkzugriff in der Entwicklung eines Satzes ganzheitlicher Betriebsrichtlinien. Dazu gehören normalerweise Richtlinien für Folgendes:
  • Wahrung der Gerätesicherheit – was bedeutet es für ein Gerät, in einwandfreiem Zustand zu sein?
  • Logische Netzwerkzoneneinteilung – wie trennen Sie nicht einwandfreie Geräte von autorisierten Geräten?
  • Informationsrisikoverwaltung – wie werden vertrauliche Daten klassifiziert und vor Angriffen geschützt?
Glücklicherweise ist eine Reihe von Richtlinienentwicklungsressourcen im Microsoft® TechNet-Sicherheitscenter (microsoft.com/technet/security) verfügbar.
Wenn Sie die Zugriffsrichtlinien entwickelt haben, müssen Sie Technologien auswählen, die diese problemlos verteilen und effektiv durchsetzen können. Für diesen Zweck benötigen Sie lediglich Windows Server® 2008. Das liegt daran, dass Windows Server 2008 nicht nur der bislang sicherste Windows Server ist. Er bietet Administratoren außerdem eine abgesicherte Sicherheitsplattform, die den Eckpfeiler einer richtliniengesteuerten Netzwerkzugriffslösung bilden kann. Die umfassende Liste neuer und verbesserter Features von Windows Server 2008 umfasst viele der Faktoren, die für die Implementierung von sicherem, richtliniengesteuertem Zugriff auf Ihr Netzwerk erforderlich sind und dabei helfen sicherzustellen, dass vertrauliche Informationen vor Angriffen geschützt sind.

Netzwerke der nächsten Generation
Den Kern der Netzwerksicherheitsverbesserungen in Windows Server 2008 bildet der TCP/IP-Stapel der nächsten Generation, eine wichtige Aktualisierung der Netzwerkfunktionälität und der damit verbundenen Dienste der Plattform. Neben der verbesserten Netzwerkleistung und der größeren Skalierbarkeit erhöht Windows Server 2008 die Sicherheit durch eine Reihe integrierter Netzwerkfeatures, die eine solide Grundlage für die richtliniengesteuerte Netzwerkzugriffslösung bieten.
Internetprotokollsicherheit (Internet Protocol security, IPsec) ist eines der Features, die in Windows Server 2008 erheblich aktualisiert wurden, damit es eine wichtige Rolle in einem richtliniengesteuerten Ansatz für den Netzwerkzugriff spielen kann. Es geht hier nicht um die Verwendung von IPsec als Tunneling- und Verschlüsselungsprotokoll, sondern um eine Nutzung seiner Host-zu-Host-Netzwerkauthentifizierungsfunktionen. Da IPsec in Schicht 3 arbeitet, kann es für die Durchsetzung von Netzwerkzugriffsrichtlinien für eine Reihe von Netzwerktypen genutzt werden.
Um die Implementierung IPsec-basierter Netzwerkzugriffssteuerungen zu vereinfachen, führt Windows Server 2008 eine Vielzahl von Verbesserungen und neuen Features ein, die auf eine Vereinfachung der Erstellung, Durchsetzung und Verwaltung von Richtlinien abzielen. Die Anzahl und die Typen verfügbarer IPsec-Authentifizierungsmethoden wurden beispielsweise erhöht. Dies wurde durch die Einführung des authentifizierten Internetprotokolls (Authenticated IP, AuthIP), einer Erweiterung des IKE-Protokolls (Internet Key Exchange, Internetschlüsselaustausch) erreicht. AuthIP bietet Ihnen die Möglichkeit, Verbindungssicherheitsregeln (ein anderer Name für IPsec-Richtlinien in Windows Server 2008) zu erstellen, für die sich kommunizierende Peers gegenseitig nicht nur mit Computeranmeldeinformationen erfolgreich authentifizieren müssen, sondern optional auch mit Benutzer- oder Integritätsanmeldeinformationen. Diese zusätzliche Flexibilität ermöglicht den Entwurf hochentwickelter logischer Netzwerke, ohne Ihre Switching- und Routinginfrastruktur aktualisieren zu müssen.

Windows-Firewall mit erweiterter Sicherheit
Die neue Windows-Firewall mit erweiterter Sicherheit baut auf den soeben beschriebenen IPsec-Features auf. Durch Kombination von IPsec-Verbindungssicherheitsregeln mit Firewallfiltern in einer einzigen Richtlinie fügt die neue Windows-Firewall eine weitere Dimension richtliniengesteuerten Netzwerkzugriffs hinzu: intelligentere authentifizierende Firewallaktionen.
Wie in Abbildung 1 gezeigt, stehen Ihnen drei Optionen für zur Verfügung, um zu definieren, welche Aktion ein eingehender oder ausgehender Firewallfilter ausführen soll: „Verbindung zulassen“, „Verbindung blocken“ und „Verbindung zulassen, wenn sie sicher ist“. Wenn „Verbindung zulassen, wenn sie sicher ist“ als Aktion ausgewählt wird, nutzt die Windows-Firewall die Host-zu-Host-Netzwerkauthentifizierungsfunktionen von IPsec, um zu bestimmen, ob ein Host oder ein Benutzer, der eine Verbindung anfordert, basierend auf der von Ihnen definierten Richtlinie zugelassen werden soll. Mit der Firewallregel können Sie festlegen, welche Benutzer, Computer und Gruppen die Verbindung herstellen dürfen. Es ist anzumerken, dass hierdurch eine zusätzliche Schutzschicht hinzugefügt wird, die vorhandene Zugriffssteuerungen auf Betriebssystem- und Anwendungsebene ergänzt.
Abbildung 1 Definieren authentifizierender Firewallregeln
Abbildung 1 Definieren authentifizierender Firewallregeln
Sie sollten inzwischen einen Einblick gewonnen haben, wie diese unterschiedlichen Netzwerksicherheitssteuerungen über eine zentralisierte Richtlinie zusammengeführt werden können, um den Netzwerkzugriff effizienter und skalierbarer zu verwalten.
Rückkehr zum CRM-Beispiel: Der Administrator könnte mit aktivierter Option „Verbindung zulassen, wenn sie sicher ist“ eine eingehende Regel für die Server entwerfen, die die CRM-Anwendung des Unternehmens ausführen (entweder über die ausführbare Datei des Programms oder Dienstports). Innerhalb derselben Firewallrichtlinie kann der Administrator angeben, dass nur Mitglieder der Gruppe „CRM Application Users“ eine Verbindung zu dieser Netzwerkanwendung herstellen können, wie in Abbildung 2 dargestellt. Wenn Sie dasselbe Konzept auf die gesamte Netzwerkkommunikation innerhalb aller verwalteten Computer auf Ihrem Netzwerk anwenden, haben Sie nun Ihrer richtliniengesteuerten Netzwerkzugriffsstrategie eine Server- und Domänenisolationsebene hinzugefügt.
Abbildung 2 Administratoren können basierend auf dieser Richtlinie angeben, wer eine Verbindung herstellen kann
Abbildung 2 Administratoren können basierend auf dieser Richtlinie angeben, wer eine Verbindung herstellen kann

Server- und Domänenisolation
Da es bei den meisten Organisationen eine zunehmende Anzahl von Gästen und anderen nicht verwalteten Geräten gibt, die eine Verbindung zu ihren Netzwerken herstellen, ist es umso wichtiger geworden, Ihre vertrauenswürdigen Hosts zu trennen und zu schützen. Die gute Nachricht ist, dass es viele Möglichkeiten gibt, vertrauenswürdige und verwaltete Computer von den anderen im Netzwerk zu isolieren. Sie sollten jedoch wissen, dass mit wachsenden Netzwerken viele dieser Optionen kostspielig (beispielsweise die Ausführung separater physischer Verkabelungssysteme) und schwer zu verwalten sind (wie switched-basierte VLANs).
Server- und Domänenisolation können eine kostengünstigere und besser verwaltbare Methode bieten, Ihre Umgebung in logisch isolierte und sichere Netzwerke zu unterteilen. Wie Abbildung 3 zeigt, verwenden Sie im Grunde die gleichen weiter oben erwähnten Verbindungssicherheitsregeln (d. h. die IPsec-Richtlinien), ordnen diese jedoch allen von Ihnen verwalteten Computern über Active Directory®-Gruppenrichtlinien zu. Dies hat eine Netzwerkzugriffsrichtlinie zum Ergebnis, die von allen Peers erfordert, sich untereinander erfolgreich zu authentifizieren, bevor die Kommunikation beginnt. Da diese Isolation in Schicht 3 stattfindet, beinhaltet die Durchsetzung dieser Zugriffssteuerungen Hubs, Switches und Router über physische und geografische Grenzen hinweg.
Abbildung 3 Definieren von Authentifizierungsanforderungen zur Anpassung an Ihre Netzwerkzugriffsanforderungen
Abbildung 3 Definieren von Authentifizierungsanforderungen zur Anpassung an Ihre Netzwerkzugriffsanforderungen
Um ein isoliertes Netzwerk zu erstellen, sollten die verschiedenen Computer im Netzwerk gemäß der Art des gewünschten Zugriffs getrennt werden. Richtlinien können so definiert werden, dass Computer in einem isolierten Netzwerk die Kommunikation mit allen Computern im Netzwerk initiieren können, einschließlich derer, die sich nicht im isolierten Netzwerk befinden. Umgekehrt können Computer, die sich nicht im isolierten Netzwerk befinden, keine Kommunikation mit Computern im isolierten Netzwerk initiieren. Tatsächlich ignorieren Computer im isolierten Netzwerk alle Kommunikationsanforderungen von Computern außerhalb des isolierten Netzwerks.
Eine Active Directory-Domäne und Domänenmitgliedschaft werden für die Durchsetzung der Netzwerkrichtlinie verwendet. Domänenmitgliedscomputer akzeptieren nur authentifizierte und sichere Kommunikation von anderen Domänenmitgliedscomputern. Optional kann auch gefordert werden, dass die gesamte Kommunikation innerhalb der isolierten Domäne verschlüsselt wird.
Server- und Domänenisolation bietet erhebliche Kostenvorteile, da an der vorhandenen Netzwerkinfrastruktur oder den Anwendungen keine wesentlichen Änderungen vorgenommen werden müssen. Diese Lösung bietet eine richtlinienbasierte Schutzschicht, der nicht nur die Abwehr kostspieliger Netzwerkangriffe und nicht autorisierter Zugriffe auf vertrauenswürdige Netzwerkressourcen unterstützt, sondern auch keine fortlaufende Wartung durch Änderungen in der Netzwerktopologie erfordert.

Netzwerkzugriffsschutz
Wie zuvor beschrieben, stellt die Server- und Domänenisolationslösung die logische Trennung der Computer und Server im Netzwerk sicher. Obwohl diese Lösung dabei hilft, nicht autorisierten Zugriff auf das Netzwerk zu verhindern, gibt es keine Garantie dafür, dass ein autorisierter Computer nicht die Ursache einer Sicherheitsbedrohung sein kann.
Netzwerkzugriffsschutz (Network Access Protection, NAP) ist eine integrierte Plattform in Windows Server 2008, die dabei hilft sicherzustellen, dass Computer, die eine Verbindung zu einem Netzwerk herstellen oder in einem Netzwerk kommunizieren, die von Ihnen festgelegten Systemintegritätsanforderungen (d. h. die Wahrung der Sicherheit und die Einhaltung von Richtlinien) erfüllen.
Selbst autorisierte Benutzer sind oft verantwortlich für die Verbreitung von Viren und Spyware im Netzwerk. Wenn ein Benutzer beispielsweise in Urlaub geht, könnte sein Computer den vom Administrator festgelegten Sicherheitsanforderungen nicht mehr entsprechen. Dies kann ernsthafte Folgen haben, wenn ein geforderter Patch oder eine Signatur, die während der Abwesenheit des Benutzers veröffentlicht wurden, nicht auf diesem Computer installiert werden.
Es geht weit über die verfügbaren Möglichkeiten eines Administrators hinaus, jeden Benutzer zu überwachen, der eine Verbindung zum Netzwerk herstellt. Hier wird ein automatisiertes Tool benötigt, das gemäß einer zentralen Richtlinie den Integritätsstatus jedes Computers, der eine Verbindung zum Netzwerk herstellt, überprüft, und diejenigen wartet, die gegen Richtlinien verstoßen. NAP tut genau dies, und fügt Ihrer richtliniengesteuerten Netzwerkzugriffslösung eine weitere Schicht hinzu.
Der NAP-Agent – entweder integriert in die Benutzeroberfläche des Clientcomputers (wie in Windows Vista®) oder separat installierbar (für ältere Versionen von Windows sowie Nicht-Windows-Betriebssysteme) – gibt alle Kompatibilitätsprobleme an den Netzwerkrichtlinienserver (Network Policy Server, NPS) weiter, bei dem es sich um das in Windows Server 2008 integrierte Richtlinienmodul handelt. Im NPS definieren Sie die Kompatibilitätsrichtlinien, die jedes Gerät erfüllen muss.
Obwohl es notwendig ist, Geräte einzuschränken, die Kompatibilitätsprüfungen nicht bestehen, ist es wichtig sicherzustellen, dass sie die Option haben, in Quarantäne gestellt oder gewartet zu werden. NAP bietet die Option, das Gerät in Fällen, in denen die Firewall oder Antiviruslösung eingeschaltet ist, entweder automatisch zu warten oder das Gerät manuell zu warten, indem es in eine Quarantänezone gezwungen wird. In diesem Fall hat das Gerät Zugriff auf einen Wartungsserver mit den neuesten Patches, Updates und Signaturen. Wenn der Benutzer das Gerät manuell aktualisiert hat, erhält es Zugriff auf das Netzwerk, vorausgesetzt, dass es die Kompatibilitätsüberprüfung besteht.
Mit der weiten Verbreitung wurde der Netzwerkzugriff sehr viel einfacher. Dies hat jedoch die zusätzliche Belastung zur Folge sicherzustellen, dass Geräte unabhängig von der Zugriffsmethode Integritäts- und Kompatibilitätsanforderungen erfüllen. Computer können auf das Netzwerk über einen regulären 802.1X-kompatiblen Switch oder Drahtloszugriffspunkt zugreifen, oder sie können eine Verbindung von einem Remotestandort aus mithilfe einer VPN- oder terminaldienstbasierten Remotezugriffsverbindung herstellen. NAP stellt nicht nur die Kompatibilität für Computer sicher, die über diese unterschiedlichen Methoden eine Verbindung herstellen, sondern bietet auch die Durchsetzung auf dem DHCP-Server, dem 802.1X-Switch, VPN-Gateway, Terminaldienstgateway oder 802.1X-kompatiblen Drahtloszugriffspunkt.
In Abbildung 4 wurde das Netzwerk bereits mithilfe der Server- und Domänenisolationslösung isoliert. Die Verwendung von NAP mit einem solchen isolierten Netzwerk bietet zusätzliche Vorteile, um eine Integritätskompatibililtät für Computer sicherzustellen, die eine Verbindung zum Netzwerk herstellen. Der Client sendet beim Start sein SoH (Statement of Health) an die Integritätsregistrierungsstelle (Health Registration Authority, HRA), bei der es sich um einen Zertifikatserver handelt. Die HRA gibt das SoH an den NPS zur Richtlinienüberprüfung weiter. Wenn das SoH gültig ist, stellt die HRA dem NAP-Client ein Integritätszertifikat aus, und der Client kann nun IPsec-basierte sichere Kommunikation mit sicheren Ressourcen initiieren. Wenn das SoH nicht gültig ist, teilt die HRA dem NAP-Client mit, wie der Integritätszustand korrigiert werden kann, und es wird kein Integritätszertifikat ausgestellt. Der NAP-Client kann keine Kommunikation mit anderen Computern initiieren, die ein Integritätszertifikat für IPsec-Authentifizierung erfordern. Der NAP-Client kann jedoch mit dem Wartungsserver kommunizieren, um wieder eine Kompatibilität zu erreichen.
Abbildung 4 Netzwerkzugriffsschutz mithilfe von IPsec-Durchsetzung
Abbildung 4 Netzwerkzugriffsschutz mithilfe von IPsec-Durchsetzung

Zusammenfassung
Obwohl diese neuen Features und Funktionen in Windows Server 2008 hier nur relativ oberflächlich behandelt wurden, ist es wichtig zu erkennen, wie jede Komponente auf der vorhergehenden aufbaut. Die Unterscheidung von der herkömmlichen Tiefenverteidigungsmethode ist auf das zugrunde liegende Richtlinienframework zurückzuführen, das Windows Server 2008 beispielsweise über die Active Directory-Gruppenrichtlinie bietet.
Dank dieser integrierten Funktionalität verfügen Sie über eine stabile Arbeitsgrundlage zur Definition und Bereitstellung einer richtliniengesteuerten Netzwerkzugriffslösung, ohne vorhandene Investitionen rückgängig machen zu müssen. Durch Anheben der Zugriffsentscheidung auf eine logischere, richtlinienbasierte Ebene können Sie den Balanceakt zwischen „einfachem Zugriff“ und „erhöhter Sicherheit“ meistern.
Microsoft hat eine Vielzahl von Leitfäden veröffentlicht, die sich mit den in diesem Artikel angesprochenen Technologiebereichen eingehend beschäftigen. Es wird empfohlen, zunächst diese Artikel und Schritt-für-Schritt-Anleitungen durchzusehen, um Erfahrung in Bezug auf den Einsatz der unterschiedlichen Features zu gewinnen. (Die Links in der Randleiste „Netzwerkressourcen“ können Ihnen bei den ersten Schritten helfen.) Erwägen Sie, jede Phase auf eine Art und Weise einzuführen, die eine stabile Grundlage für die nächste Phase bietet.
Erstellen Sie zum Beispiel einen Satz der authentifizierenden Firewallregeln für Ihre erfolgsentscheidenden Anwendungen, wie im Abschnitt „Windows-Firewall mit erweiterter Sicherheit“ dargestellt. Wenn Sie sich damit vertraut gemacht haben, erweitern Sie die Verbindungssicherheitsregeln zur Isolierung Ihrer Netzwerkdomäne, und fügen Sie NAP als weitere Schicht hinzu. Die Vorteile der Implementierung einer richtliniengesteuerten Netzwerkzugriffsstrategie können erheblich sein, denn sie helfen Ihnen unter anderem dabei, mit der sich ständig ändernden Welt unserer Unternehmensnetzwerke Schritt zu halten.

Ian Hameroff ist Senior Product Manager im Bereich „Security and Access Product Marketing“ bei Microsoft. Er ist verantwortlich für die Produktverwaltung und das Marketing der Windows Server-Plattform-Netzwerktechnologien. Ian Hameroff steht hinter der Markteinführungsstrategie für Windows Server-Netzwerkfunktionalität und -Lösungen mit dem Schwerpunkt auf wichtigen Sicherheits- und Netzwerkinitiativen wie z. B. Server- und Domänenisolation, skalierbaren Netzwerken und der Übernahme von IPv6.
Amith Krishnan ist Senior Product Manager im Bereich „Security and Access Product Marketing“ bei Microsoft und ist verantwortlich für Produktmanagement und Marketing für Windows Server-Netzwerkfunktionalität und Sicherheitsinitiativen wie z. B. Netzwerkzugriffsschutz und Sicherheit von Drahtlosverbindungen. Er entwickelt auch die Markteinführungsstrategie und treibt das Bewusstsein für diese Lösungen voran.


 Sonderbeitrag: Windows Server&#160;2008: Konfigurieren von Rollen mit Server-Manager
Sonderbeitrag: Windows Server 2008 Byron Hynes

Konfigurieren von Rollen mit Server-Manager
Kurz zusammengefasst:
  • Unterschied zwischen Rollen und Features
  • Möglichkeiten von Server-Manager
  • Arbeiten mit Assistenten
  • Verwalten von Rollen und Features über die Befehlszeile

Das Motto „weniger ist mehr" ist eines der Themen, das Windows Server 2008 offensichtlich beherrscht. Das soll nicht bedeuten, dass Features vollkommen unnötig entfernt werden. Stattdessen wird mit dieser Strategie angestrebt, Rollen und Tools zu vereinfachen und klarer zu gestalten, um Sie in die Lage zu versetzen, nur die Dienste und Tools zu installieren, die Sie benötigen, und nicht mehr. Server-Manager
ist ein wichtiger Teil dieses Konzepts in Windows Server® 2008.
Zwei wichtige Aspekte sind in dieser Hinsicht von Bedeutung: Erstens das äußerst wichtige Konzept der Serverrollen und Features, die die Bausteine von Windows Server 2008 darstellen, und zweitens das Server-Manager-Tool an sich. Dieses Tool ersetzt nicht nur verschiedene, in Windows Server 2003 verwendete Tools, sondern integriert auch eine größere Anzahl von Funktionen an einem Ort. Dadurch können Administratoren wie Sie, die sehr viel zu tun haben, mehr Aufgaben schneller und einfacher bewältigen.

Rollen und Features
Wenn Sie schon über Windows Server 2008 gelesen haben, sind Sie wahrscheinlich auf einige Begriffe gestoßen, die Sie im Kontext von Windows® noch nicht gehört haben, wie z. B. „Arbeitsauslastungen“ und „Rollen“. Zunächst soll erklärt werden, was diese Begriffe für IT-Experten bedeuten.
Am Anfang des Entwicklungszyklus für Windows Server 2008 haben wir viel Zeit damit verbracht herauszufinden, wie die Benutzer unsere Serverprodukte verwenden. (Diese Bemühungen werden natürlich fortgesetzt.) Dabei kam heraus, dass unsere Server für bestimmte Aufgaben bereitgestellt werden. Dies klingt nicht unbedingt wie ein bahnbrechendes Ergebnis. Für einige von uns war jedoch die Erkenntnis sehr aufschlussreich, dass unsere Kunden Server nicht unbedingt kaufen, weil sie einen Server haben möchten. Darüber hinaus stellen sie Server nicht zur Erledigung verschiedenster Aufgaben, sondern nur einer ganz bestimmten Aufgabe bereit. Selbstverständlich gibt es Ausnahmen. In den meisten Fällen wird jedoch ein Server bereitgestellt, um eine bestimmte Funktion auszuführen.
Als Reaktion auf diese Ergebnisse wurden die „bestimmten Aufgaben“ in groben Klassifizierungen mit der Bezeichnung „Arbeitsauslastungen“ zusammengefasst. Zum Beispiel gibt es eine Datenbank-Arbeitsauslastung sowie eine Anwendungsserver-Arbeitsauslastung. Da es sich bei Arbeitsauslastungen um eine sehr allgemeine und manchmal auch ein wenig unklare Kategorie handelt, wurden Unterkategorien innerhalb der Arbeitsauslastungen mit der Bezeichnung „Rollen“ erstellt. Eine Rolle ist eine einzelne, sehr spezifische Aktion, die ein Server durchführen soll. Überlegen Sie, wie Sie (und die Benutzer in Ihrer Organisation) Server in Ihrem Netzwerk bezeichnen. Sicherlich betrachten Sie sie, wie die meisten Benutzer, als Dateiserver, Domänencontroller, Druckserver, Webserver und so weiter. Da diese Betrachtungsweise der allgemeinen Vorstellung über Server entspricht, wurde sie in Windows Server 2008 für die Arbeit mit Rollen übernommen.
Allgemein gibt es drei Hauptkategorien von Rollen in Windows Server 2008: Identitäts- und Zugriffsverwaltung (die Rollen sind Teil von Active Directory®), Infrastruktur (dazu gehören Dateiserver, Druckserver, DNS usw.) und Anwendung (wie z. B. die Webserverrolle und Terminaldienste).
Mit Windows Server 2008 werden etwa 17 Serverrollen bereitgestellt (einschließlich Rollen wie Active Directory-Zertifikatdienste, Netzwerkrichtlinien- und Zugriffsdiensten und Windows Server-Virtualisierung). Zusätzliche Rollen, wie die Rolle für Streaming Media-Dienste, werden wahrscheinlich zum Herunterladen zur Verfügung stehen.
Jede einzelne Rolle ist einen eigenen Artikel wert. Einige werden eingehender in dieser Ausgabe des TechNet Magazins besprochen, andere wurden bereits behandelt, und weitere werden in Zukunft erläutert. Erkunden Sie alle, und beginnen Sie dabei mit den Informationen unter technet2.microsoft.com/windowsserver2008/en/servermanager/default.mspx.
Zu Beginn der Bereitstellung von Windows Server 2008 müssen Sie die zu installierenden Rollen auf jedem Server auswählen. Diese rollenbasierte Bereitstellung ist ein wichtiges Konzept für die effektive Verwendung von Windows Server 2008 und die Fähigkeit, beim Bereitstellen von Ressourcen flexibel zu sein.
In der Liste der Rollen sind keine Features wie die BitLockerTM-Laufwerksverschlüsselung und Netzwerklastenausgleich (Network Load Balancing, NLB) enthalten. Das liegt daran, dass es sich hierbei um Features handelt, die zwar wünschenswert sind, für die speziell Benutzer jedoch kein System erwerben würden. Rollen repräsentieren dagegen Aufgaben, für deren Durchführung Systeme speziell erworben werden. Zum Beispiel erwerben Benutzer keine Server, um einen Lastenausgleich zu implementieren. Dagegen werden Server zum Bereitstellen einer Website gekauft. Während NLB ein wichtiger Aspekt beispielsweise eines Webservers sein mag, existiert der Server nicht zu diesem Zweck.
Statt alle Features des Servers zu installieren und zu aktivieren, wählt ein Administrator die zu installierenden Features aus. (Die Liste der in Windows Server 2008 enthaltenen Features wird in Abbildung 1 gezeigt.) Durch das Hinzufügen nur tatsächlich benötigter Rollen und Features werden Stabilität und Sicherheit verbessert. Sie müssen sich keine Gedanken darüber machen, dass Ressourcen von nicht installierten Features oder Rollen verbraucht werden. Zudem müssen Sie sich nicht um die Problembehandlung von Features oder das Sichern von Rollen kümmern, die nicht installiert sind.
Figure 1 In Windows Server 2008 enthaltene Features (Close Figure 1)

Features in Microsoft .NET Framework 3.0
BitLocker-Laufwerkverschlüsselung
BITS-Servererweiterungen
Verbindungs-Manager-Verwaltungskit
Desktopdarstellung
Gruppenrichtlinienverwaltung
Internetdruckclient
iSNS (Internet Storage Name Server)
LPR-Anschlussmonitor
Message Queuing
Multipfad-E/A
Peer Name Resolution-Protokoll
Verbessertes Windows-Audio/Video-Streaming
Remoteunterstützung
Remoteserver-Verwaltungstools
Wechselmedien-Manager
RPC-über-HTTP-Proxy
Dienste für NFS
SMTP-Server
Speicher-Manager für SANs
Einfache TCP/IP-Dienste
SNMP-Dienste
Subsystem für UNIX-basierte Anwendungen
Telnet-Client
Telnet-Server
TFTP-Client
Failover-Clusterunterstützung
Netzwerklastenausgleich
Windows Server-Sicherung
Windows-Systemressourcen-Manager
WINS-Server
WLAN-Dienst
Interne Windows-Datenbank
Windows PowerShell
Windows-Prozessaktivierungsdienst
Dieses Konzept wird durch die Server Core-Installationsoption verkörpert. Es würde den Rahmen dieses Artikels sprengen, Server Core detailliert zu besprechen. Deutlich zu erkennen ist jedoch die logische Erweiterung, nicht verwendete Rollen und Features weder auf die Festplatte zu kopieren noch verfügbar zu machen. Ein Hauptunterschied zwischen einer normalen Installation und einer Server Core-Installation besteht darin, dass eine normale Installation die erforderlichen Ressourcen für die Installation zusätzlicher Rollen zu einem beliebigen Zeitpunkt enthält und dass sie alle Rollen unterstützt. Server Core besitzt noch nicht einmal eine grafische Benutzeroberfläche für die Shell und unterstützt nur eine begrenzte Anzahl von Rollen.

Server-Manager
Mithilfe der neuen Server-Manager-Konsole in Windows Server 2008 können Sie einfacher mehrere Serverrollen in einem Unternehmen verwalten und sichern. Server-Manager ist im Wesentlichen eine erweiterte Microsoft® Management Console (MMC), mit der Sie praktisch alle Informationen und Tools anzeigen können, die die Produktivität Ihres Servers beeinflussen. Er bietet eine einzelne Quelle zum Verwalten der Identität und der Systeminformationen eines Servers und zeigt den Serverstatus an, identifiziert Probleme bei der Serverrollenkonfiguration und verwaltet alle auf dem Server installierten Rollen. (Beachten Sie, dass dadurch mehrere Features ersetzt werden, die in Windows Server 2003 enthalten sind, wie die „Serververwaltung“, die „Konfiguration des Servers“ und „Windows-Komponenten hinzufügen oder entfernen“.)
In einigen Fällen braucht der Administrator dank der Verwendung von Server-Manager den Sicherheitskonfigurations-Assistenten (Security Configuration Wizard, SCW) nicht so häufig vor der Bereitstellung von Servern auszuführen. Server-Manager konfiguriert Ihren Server so, dass alle installierten Rollen funktionieren, indem zum Beispiel die Windows-Firewall automatisch konfiguriert wird. SCW stellt in einigen Situationen dennoch ein sehr nützliches Tool dar, wenn Rollen hinzugefügt und anschließend entfernt wurden oder die exakten Sicherheitseinstellungen stärker kontrolliert werden sollen. Weitere Informationen finden Sie in der Rubrik „Sicherheit auf dem Prüfstand“ von Jesper Johansson unter dem Titel „Verwenden des SCW unter Windows Server 2008“ in dieser Ausgabe (microsoft.com/technet/technetmag/issues/2008/03).
Bei der Arbeit an Windows Server 2008 haben wir die Art und Weise, wie Administratoren Aufgaben durchführen sollen, kritisch beleuchtet. Wir haben sowohl Methoden zur Arbeitserleichterung mithilfe von Tools und Assistenten ermittelt als auch Fälle gefunden, in denen zu viele Wechsel zwischen Tools stattfanden. Wir haben ein wichtiges Entwurfsziel allgemein für Windows Server 2008 und speziell für Server-Manager gesetzt. Danach soll die Serververwaltung effizienter gestaltet werden, indem Administratoren die Durchführung vieler Arten von Aufgaben an einem einzigen Ort ermöglicht wird. Demzufolge können Sie mit Server-Manager folgende Aufgaben durchführen:
  • Anzeigen und Vornehmen von Änderungen an Serverrollen und Features, die auf dem Server installiert sind.
  • Durchführen von Verwaltungsaufgaben, die den Server betreffen, wie z. B. das Starten oder Beenden von Diensten und Verwalten lokaler Benutzerkonten.
  • Durchführen von Verwaltungsaufgaben, die die auf dem Server installierten Rollen betreffen.
  • Überprüfen des Serverstatus, Identifizieren kritischer Ereignisse und Analysieren von Konfigurationsproblemen.
  • Installieren oder Entfernen von Rollen, Rollendiensten und Features mithilfe einer grafischen Benutzeroberfläche oder Befehlszeile.
Die Server-Manager-Konsole zeigt viele Informationen und Funktionen auf sehr kleinem Raum an. Abbildung 2 zeigt den Knoten für die Rolle „Dateidienste“ in der Server-Manager-Konsole. Das Hauptfenster der Konsole enthält vier reduzierbare Abschnitte: „Serverübersicht“, „Rollenübersicht“, „Featureübersicht“ sowie „Ressourcen und Support“.
Abbildung 2 Die Server-Manager-Konsole zeigt die Rolle „Dateidienste“ an
Abbildung 2 Die Server-Manager-Konsole zeigt die Rolle „Dateidienste“ an
Der Abschnitt „Serverübersicht“ enthält zwei Unterabschnitte: „Computerinformationen“ und „Sicherheitsinformationen“. Der Unterabschnitt „Computerinformationen“ zeigt den Computernamen, die Domäne, den Namen des lokalen Administratorkontos, Netzwerkverbindungen und die Produkt-ID des Betriebssystems an. Sie können diese Informationen hier auch mithilfe von Befehlen bearbeiten. Im Unterabschnitt „Sicherheitsinformationen“ wird angezeigt, ob die automatischen Updates für Windows, die Windows-Firewall sowie die verstärkte Sicherheitskonfiguration für Windows Internet Explorer® aktiviert sind (entweder für Administratoren oder andere Benutzer). Ebenso stehen Befehle zum Bearbeiten dieser Einstellungen sowie zum Anzeigen aller erweiterten Optionen zur Verfügung.
Der Abschnitt „Rollenübersicht“ enthält eine Tabelle, in der die auf dem Server installierten Rollen aufgeführt werden. Sie können mithilfe der Befehle in diesem Abschnitt Rollen hinzufügen bzw. entfernen oder zu einer detaillierteren Konsole zum Verwalten einer bestimmten Rolle wechseln.
Der Abschnitt „Featureübersicht“ enthält eine Tabelle, in der die auf dem Server installierten Features aufgelistet sind. Hier können Sie, wie erwartet, Features hinzufügen und entfernen.
Schließlich zeigt der Abschnitt „Ressourcen und Support“ an, ob der Server am Programm zur Verbesserung der Benutzerfreundlichkeit und an der Windows-Fehlerberichterstattung teilnimmt und Ihnen ermöglicht, die Teilnahme des Servers an Feedbackprogrammen zu konfigurieren. Sie können auch schnell weitere relevante, in den Windows Server-TechCentern und technischen Bibliotheken verfügbare Hilfe- und Recherchethemen suchen.

Rolleninformationen
Jede installierte Rolle hat innerhalb von Server-Manager eine eigene Homepage. Im Abschnitt „Ressourcen und Support“ wird für jede dieser Rollenhomepages ein Menü empfohlener Konfigurationen oder Szenarios angeboten, in denen die Rolle oder Teile der Rolle funktionieren. Jede empfohlene Konfiguration ist mit einer Hilfsprüfliste verknüpft, die Sie durch die Aufgaben zum Erstellen der am besten geeigneten Funktionalität für die gegebene Rolle führt.
Ein Vorteil von Server-Manager besteht darin, dass wichtige Informationen und Befehle genau an den relevanten Positionen angezeigt werden. Wenn Sie zum Beispiel die Rollenhomepage „Dateidienste“ anzeigen, sehen Sie sofort – ohne eine Ereignisanzeige zu starten und einen Filter zu erstellen – alle Ereignisse, die sich auf die Rolle beziehen.
Einige Rollen können jedoch Hunderte von Ereignissen generieren. Folglich ist es möglich, benutzerdefinierte Filter direkt von der Rollenhomepage aus zu erstellen. Sie können im Menü an der Seite „Ereignisse filtern“ auswählen und die angezeigten Ereignisse weiter eingrenzen. Dieses Dialogfeld bietet zwar nicht alle in der Ereignisprotokollanzeige verfügbaren Filteroptionen, es ermöglicht Ihnen jedoch, sich schnell auf die Ereignisse zu konzentrieren, die für diese bestimmte Rolle relevant sind. Dabei müssen Sie sich keine Gedanken über das Herausfiltern der anderen Ereignisse zu machen.
Ebenso können Sie den Status der Systemdienste (für diese Rolle erforderliche Dienste, die aber Teil des Gesamtsystems sind) und der Rollendienste (für diese Rolle spezifische Dienste) anzeigen. Bei einigen Rollen können Sie die verfügbaren Teile einer Rolle auswählen, sodass unterschiedliche Sätze an Rollendiensten installiert werden. Sie können direkt von der Rollenhomepage Dienste starten und beenden sowie angeben, welche Dienste als Systemdienste für die Rolle überwacht werden müssen.

Arbeiten mit Assistenten
Mit einem gut entworfenen Assistenten können Sie Zeit sparen und Fehler verhindern, insbesondere beim Durchführen von Aufgaben, die nicht regelmäßig anstehen. In früheren Versionen von Windows Server mussten Sie „Konfiguration des Servers“, „Serververwaltung“ und „Windows-Komponenten hinzufügen oder entfernen“ verwenden, um auf Ihrem Server installierte Komponenten zu ändern. Abhängigkeitsüberprüfungen waren begrenzt, und bei „Windows-Komponenten hinzufügen oder entfernen“ musste die Installation einer Rolle abgeschlossen sein, bevor eine andere Rolle hinzugefügt werden konnte.
Ab sofort können Sie mithilfe von Server-Manager-Assistenten mehrere Rollen, Rollendienste und Features in einer einzigen Sitzung installieren oder entfernen. Darüber hinaus werden während der Ausführung des Server-Manager-Assistenten Abhängigkeitsüberprüfungen durchgeführt, die sicherstellen, dass alle notwendigen Rollen und Rollendienste installiert sind. Rollen werden mit den empfohlenen Standardsicherheitseinstellungen konfiguriert, Sie können diese jedoch im Sicherheitskonfigurations-Assistenten ändern. Ihr Server kann tatsächlich bereits nach einer einzigen Sitzung eines Server-Manager-Assistenten vollständig auf die Bereitstellung vorbereitet sein.
Server-Manager enthält eine Anzahl von Assistenten, einschließlich des Assistenten für das Hinzufügen von Rollen, des Assistenten für das Hinzufügen von Rollendiensten, des Assistenten für das Hinzufügen von Features, des Assistenten für das Entfernen von Rollen, des Assistenten für das Entfernen von Rollendiensten und des Assistenten für das Entfernen von Features.
Der Assistent für das Hinzufügen von Rollen wird erwartungsgemäß zum Hinzufügen von Rollen zum Server verwendet. Er sucht automatisch nach Abhängigkeiten zwischen Rollen und überprüft, ob alle erforderlichen Rollen und Rollendienste für jede ausgewählte Rolle installiert sind. Für einige Rollen, wie die Terminaldienste und Active Directory-Zertifikatdienste, bietet der Assistent für das Hinzufügen von Rollen auch Konfigurationsseiten, auf denen der Benutzer angeben kann, wie die Rolle als Teil des Installationsvorgangs konfiguriert werden soll. Abbildung 3 zeigt die Seite „Serverrollen auswählen“ des Assistenten für das Hinzufügen von Rollen.
Abbildung 3 Verwenden des Assistenten für das Hinzufügen von Rollen zum Auswählen von Serverrollen
Abbildung 3 Verwenden des Assistenten für das Hinzufügen von Rollen zum Auswählen von Serverrollen
Die meisten Rollen bestehen aus mehreren Unterelementen, die in Server-Manager als „Rollendienste“ bezeichnet werden. Sobald eine komplexe Rolle installiert ist, können Sie mithilfe des Assistenten für das Hinzufügen von Rollendiensten der Rolle Rollendienste hinzufügen.
Auf ähnliche Weise wie mit dem Assistenten für das Hinzufügen von Rollen können Sie mit dem Assistenten für das Hinzufügen von Features Features installieren. Sie können dem System in einer einzigen Sitzung eines oder mehrere Features hinzufügen.
Der Assistent für das Entfernen von Rollen ermöglicht Ihnen, wie sein Name nahelegt, das Entfernen von Rollen von einem Server. Der Assistent sucht automatisch nach Abhängigkeiten, um sicherzustellen, dass alle Rollen oder Rollendienste, die für nicht entfernte Rollen benötigt werden, installiert bleiben. Sie können Rollendienste aus einer installierten Rolle ebenso mithilfe des Assistenten für das Entfernen von Rollendiensten entfernen. In der Zwischenzeit entfernt der Assistent für das Entfernen von Features für Sie Features aus dem System.

Befehlszeilen
Manchmal lerne ich einen IT-Experten kennen, der Assistenten einfach verabscheut. Während wenige IT-Experten ihre Meinung so vehement vertreten, gefällt vielen die Möglichkeit der Verwendung einer Befehlszeile. Dies kann praktischer sein und ermöglicht einfache Wiederholbarkeit und unkomplizierte Skripterstellung. Server-Manager bietet ein Befehlszeilentool, ServerManagerCmd.exe, das wesentlich einfacher als die früheren ocsetup- und pkgmgr-Tools ist. Sie können ServerManagerCmd.exe zum Installieren und Entfernen von Rollen, Rollendiensten und Features verwenden. Dazu verwenden Sie einfache Parameter, um eine Liste aller Rollen, Rollendienste und Features anzuzeigen. Dabei geben Sie an, welche bereits installiert sind und welche für die Installation zur Verfügung stehen.
Mithilfe dieser Befehlszeile können Sie praktisch unbeaufsichtigte Installationen durchführen und Rollen, Rollendienste sowie Features entfernen. Darüber hinaus können Sie die Befehlszeile verwenden, um eine einzelne Rolle, einen einzelnen Rollendienst oder ein einzelnes Feature in einer Befehlsinstanz zu installieren oder zu entfernen. Mithilfe einer XML-Antwortdatei und des Server-Manager-Befehls ist es auch möglich, mehrere Rollen, Rollendienste und Features in einer einzigen Befehlsinstanz hinzuzufügen oder zu entfernen. Zusätzlich können Sie Protokolle von Vorgängen anzeigen und Abfragen ausführen, um Listen der Rollen, Rollendienste und Features anzuzeigen, die bereits installiert sind oder die zur Installation zur Verfügung stehen.
Ein Höhepunkt dieses Befehlszeilentools ist der –whatif-Parameter, der genau die Änderungen anzeigt, die am Server vorgenommen werden würden, wenn die angegebene Rolle installiert würde. Zum Beispiel werden in Abbildung 4 die Ergebnisse der Ausführung des folgenden Befehls angezeigt:
ServerManagerCmd -install Web-Server
-allsubfeatures -whatif
Natürlich können Sie diese Ausgabe zur weiteren Analyse in einer Datei speichern.
Abbildung 4 Verwenden des –whatif-Parameters zum Anzeigen der am Server gegebenenfalls vorgenommenen Änderungen
Abbildung 4 Verwenden des –whatif-Parameters zum Anzeigen der am Server gegebenenfalls vorgenommenen Änderungen
Eine eingehendere Betrachtung der Details und der Syntax von ServerManagerCmd.exe finden Sie im Anhang zur technischen Übersicht über Server-Manager unter go.microsoft.com/fwlink/?LinkId=107113.
Ich möchte Gaby Kaplan für ihren Beitrag zu diesem Artikel danken.

Byron Hynes ist Enterprise Technology Strategist in der Enterprise and Partner Group bei Microsoft. Er hat vorher in der Windows Server-Abteilung sowie als Berater und Schulungsleiter gearbeitet. Er ist unter bhynes@microsoft.com zu erreichen.


 Sonderbeitrag: Windows Server&#160;2008: Bereitstellen von Windows Server&#160;2008 mit System Center
Sonderbeitrag: Windows Server 2008 Tim Mintner

Bereitstellen von Windows Server 2008 mit System Center
Kurz zusammengefasst:
  • Bereitstellungsfeatures von Configuration Manager
  • Erstellen und Anpassen einer Servertasksequenz
  • Hinzufügen von Serverrollen
  • Festlegen von computerspezifischen Variablen

Mit der Veröffentlichung von System Center Configuration Manager 2007 können Serveradministratoren jetzt die gleichen Bereitstellungstools für Betriebssysteme nutzen, die Clientadministratoren
schon seit mehreren Jahren zur Verfügung stehen. In der Vergangenheit haben Serveradministratoren Windows Server® oft mit einer CD oder DVD manuell installiert und dann Stunden mit der Konfiguration des Servers verbracht. Einige Administratoren sind einen Schritt weiter gegangen und haben durch die Erstellung einer unattend.txt-Datei und vielleicht mithilfe von Remoteinstallationsdiensten (Remote Installation Services, RIS) unbeaufsichtigte Setuproutinen erstellt, um den Installationsvorgang zu automatisieren und zu vermeiden, persönlich an der Serverkonsole anwesend sein zu müssen. Fortschrittlichere Administratoren haben die automatischen Bereitstellungsdienste (Automated Deployment Services, ADS) für Windows Server 2003 genutzt, um den gesamten Servererstellungsprozess vollständig zu automatisieren. Mit Windows Server 2008 hat sich der Installationsvorgang für Server zum ersten Mal seit Windows NT® 4.0 wesentlich geändert.
Bei der Bereitstellung von Windows Server 2008 werden die gleichen zugrunde liegenden Bereitstellungstools und -technologien verwendet wie bei Windows Vista®. Aufgrund dieser Änderung müssen die Tools, die Serveradministratoren in der Vergangenheit verwendet haben, aktualisiert oder ersetzt werden. RIS wurde durch die Windows®-Bereitstellungsdienste (Windows Deployment Services, WDS) ersetzt, und ADS unterstützt die Bereitstellung von Windows Server 2008 nicht. Weitere Informationen zu den Technologien und Tools, die sich bei der Server- und Clientbereitstellung geändert haben, finden Sie in „10 wissenswerte Punkte zur Bereitstellung von Windows Vista“ unter technetmagazine.com/ issues/2006/11/Deployment.
Da die zugrunde liegenden Technologien für die Bereitstellung von Windows Server 2008 und Windows Vista sich gleichen, wäre es da nicht großartig, wenn Sie die gleichen Tools und die gleichen Kenntnisse nutzen könnten, um beide bereitzustellen? System Center Configuration Manager und Microsoft® Deployment bieten jetzt dieses integrierte Toolset. In diesem Artikel wird beschreiben, wie Sie Configuration Manager zusammen mit Microsoft Deployment verwenden können, um mit der Veröffentlichung von Windows Server 2008 zu beginnen.

Betriebssystembereitstellung mit Configuration Manager
Bevor Sie mit der Bereitstellung von Windows Server 2008 beginnen, sehen Sie sich die Bereitstellungsfeatures für Betriebssysteme von Configuration Manager an. Wenn Sie die Configuration Manager-Konsole starten und die Computerverwaltung aufrufen, sehen Sie einen neuen Landebereich für die Betriebssystembereitstellung, wie in Abbildung 1 gezeigt.
Abbildung 1 Die Seite für die Betriebssystembereitstellung
Abbildung 1 Die Seite für die Betriebssystembereitstellung
Auf dieser Seite können Sie eine kurze Zusammenfassung von Betriebssystembereitstellungen anzeigen, die in Ihrer Umgebung stattgefunden haben. Sie können auch zu anderen Betriebssystembereitstellungs-Knoten wie „Manage Task Sequences“ (Tasksequenzen verwalten) und „Manage Boot Images“ (Startabbilder verwalten) navigieren. Sie finden eine Liste von Webberichten zum Anzeigen des Status von Bereitstellungen und der Integrität Ihrer Bereitstellungsumgebung. Es gibt auch einen Schnellhilfeverweis unter „Resources“ (Ressourcen), der Sie mit der Hilfedokumentation für die Betriebssystembereitstellung verknüpft.
Unterhalb der Knoten im Navigationsbereich können Sie alle Elemente sehen, die konfiguriert werden müssen, um eine Betriebssystembereitstellung durchzuführen. Hier eine Zusammenfassung dieser Elemente:
Boot Images (Startabbilder) Enthält eine Liste von Startabbildern, die auf Windows PE 2.0 basieren und während des Bereitstellungsprozesses verwendet werden.
Computer Associations (Computerzuordnungen) Wird hauptsächlich für Clientbereitstellungen verwendet, um einem neuen Computer einen vorhandenen Computer zuzuordnen, damit der Benutzerstatus sicher verwaltet werden kann. Enthält auch einen Assistenten, um unbekannte Computerkonten in die Datenbank von Configuration Manager zu importieren, damit Bare-Metal-Server bereitgestellt werden können.
Operating System Images (Betriebssystemabbilder) Enthält eine Liste der Pakete, in denen angepasste WIM-Abbilder (Windows Imaging) für die Server- und Clientbereitstellung gespeichert sind.
Operating System Install Packages (Installationspakete für Betriebssysteme) Hält Pakete bereit, die den vollständigen Satz an Quelldateien für eine Betriebssystembereitstellung enthalten, z. B. die Quelldateien für Windows Server 2008.
Task Sequences (Tasksequenzen) Enthält mehrere Schritte, von denen jeder die Befehlszeilenaktionen definiert, die ohne Benutzereingriff ausgeführt werden. Tasksequenzen sind der Motor des Bereitstellungsprozesses von Betriebssystemen und können alle Schritte zur Verfügung stellen, die für die Bereitstellung und Konfiguration eines Betriebssystems erforderlich sind.
Drivers (Treiber) Ein zentrales Repository zum Verwalten aller Treiber, die für die verschiedenen Modelle von Server- und Clientcomputern benötigt werden.
Driver Packages (Treiberpakete) Enthält einen oder mehrere Sätze von Treibern, die an Configuration Manager-Verteilungspunkte verteilt werden können und während der Bereitstellung von Server- oder Clientcomputern verwendet werden.
Nun, da Sie über grundlegende Kenntnisse der Bereitstellungsfeatures für Betriebssysteme von Configuration Manager verfügen, werden wir alles zusammentragen, was Sie benötigen, um eine Windows Server 2008-Bereitstellung durchführen zu können.

Vorbereitung auf die Bereitstellung von Windows Server 2008
Was ist Microsoft Deployment?
Microsoft Deployment ist die nächste Version von Business Desktop Deployment (BDD) 2007. Es vereint die Tools und Prozesse, die sowohl für die Desktop- als auch für die Serverbereitstellung erforderlich sind, in einer gemeinsamen Bereitstellungskonsole und einer Sammlung von Leitfäden. Das Produkt fügt mit System Center Configuration Manager 2007 neue Funktionen zur Bereitstellung und Tasksequenzierung für Desktops und Server hinzu.
Microsoft Deployment ist im Microsoft Download Center erhältlich, und Leitfäden können online in den TechCentern zur Desktopbereitstellung bzw. Serverbereitstellung auf Microsoft TechNet gelesen werden. Weitere Informationen und Links zu diesen Zielen und weitere verwandte Inhalte finden Sie unter Microsoft.com/deployment.

Zur Bereitstellung von Windows Server 2008 mit Configuration Manager benötigen Sie folgende Elemente:
Microsoft Deployment Toolkit (MDT) Bietet Dokumentation zu Tools und bewährten Methoden für die Bereitstellung von Server- und Clientbetriebssystemen. Wird direkt in die Configuration Manager-Konsole integriert, um den Bereitstellungsprozess zu optimieren. Sie können das Microsoft Deployment Toolkit unter Microsoft.com/deployment herunterladen.
Custom Boot Image (Benutzerdefiniertes Startabbild) Configuration Manager bietet 32-Bit- und 64-Bit-Startabbilder, die auf Windows PE 2.0 basieren und Unterstützung für VBScript, Windows-Verwaltungsinstrumentation (Windows Management Instrumentation, WMI) und HTML-Anwendungen (HTAs) umfassen. Wenn Sie jedoch möchten, dass Ihr Bereitstellungsprozess Informationen von einer separaten SQL Server®-Datenbank anfordert, benötigen Sie ein benutzerdefiniertes Startabbild mit ADO-Unterstützung.
Operating System Install Package (Installationspaket für Betriebssysteme) Enthält die Quelldateien von der Windows Server 2008-DVD.
MDT Package (MDT-Paket) Enthält alle Skripts und unterstützenden Dateien, die für das Microsoft Deployment Toolkit benötigt werden.
Configuration Manager Client Package (Configuration Manager-Clientpaket) Enthält die Installationsdateien für den Configuration Manager-Client.
Settings Package (Einstellungspaket) Enthält die Datei „unattend.xml“, die für eine automatisierte Installation von Windows Server 2008 verwendet wird, sowie die Datei „customsettings.ini“, die mit dem Microsoft Deployment Toolkit verwendet wird.
Sysprep Package (Sysprep-Paket) Wird nur bei der Bereitstellung von Windows Server 2003 oder Windows XP verwendet und bietet die Sysprep-Dateien, die erforderlich sind, um einen Computer auf die Erfassung eines Betriebssystemabbilds vorzubereiten.
Drivers (Treiber) Enthält alle Treiber, die für bestimmte Modelle von Servern benötigt werden.
Netzwerkfreigaben für Paketquellen und aufgezeichnete WIMs Die UNC-Speicherorte (Universal Naming Convention), unter denen die oben aufgelisteten Pakete zusammen mit dem angepassten WIM-Abbild gespeichert werden.
Es mag so aussehen, als ob viel Arbeit erforderlich ist, um alle diese Pakete zu erstellen. Die gute Nachricht ist, dass mithilfe des Microsoft Deployment Toolkit ein Assistent alle Pakete für Sie erstellt.
Um das Microsoft Deployment Toolkit mit Configuration Manager zu verwenden, müssen Sie es auf dem gleichen Computer installieren wie die Configuration Manager-Verwaltungskonsole. Nachdem Sie dies erledigt haben, rufen Sie „Start“ | „Alle Programme“ | „Microsoft Deployment Toolkit“ auf, und wählen Sie „Configure ConfigMgr Integration“ (ConfigMgr-Integration konfigurieren) aus. Geben Sie den Namen Ihres Configuration Manager-Standortservers und den Standortcode an, und klicken Sie auf „Next“ (Weiter). Dadurch werden der Configuration Manager-Konsole Erweiterungen hinzugefügt, die vom Microsoft Deployment Toolkit zur Verfügung gestellt werden. Wenn Sie jetzt die Configuration Manager-Konsole starten und mit der rechten Maustaste auf „Task Sequences“ (Tasksequenzen) klicken, sehen Sie eine neue Option, wie in Abbildung 2 gezeigt.
Abbildung 2 Importieren der Microsoft Deployment-Tasksequenz
Abbildung 2 Importieren der Microsoft Deployment-Tasksequenz
Wählen Sie „Import Microsoft Deployment Task Sequence“ (Microsoft Deployment-Tasksequenz importieren) aus, und befolgen Sie die unten stehenden Schritte, um die notwendigen Pakete und die Windows Server 2008-Tasksequenz zu erstellen:
  1. Wählen Sie im Fenster „Choose Template Screen“ (Vorlagenfenster wählen) die Option „Server Task Sequence“ (Servertasksequenz) aus, und klicken Sie dann auf „Next“.
  2. Geben Sie einen Tasksequenznamen und Kommentare zur Beschreibung der Tasksequenz an, und klicken Sie dann auf „Next“.
  3. Geben Sie die Details zum Beitreten zu einer Domäne oder einer Arbeitsgruppe an, einschließlich der Anmeldeinformationen des Benutzerkontos, um den Server in die Domäne aufzunehmen. Geben Sie die Informationen für Ihre Organisation und den Produktschlüssel ein, und geben Sie einen UNC-Pfad und einen Dateinamen für das benutzerdefinierte WIM-Abbild an, das aufgezeichnet wird. Geben Sie Anmeldeinformationen des Benutzers an, um eine Verbindung zur Netzwerkfreigabe herzustellen, auf der die WIM-Datei gespeichert wird, und klicken Sie dann auf „Next“.
  4. Wählen Sie im Fenster „Boot Image“ (Startabbild) die Option zum Erstellen eines neuen Startabbildpakets, und geben Sie einen Netzwerkspeicherort für das Paketquellverzeichnis des Startabbildpakets an. Klicken Sie dann auf „Next“.
  5. Geben Sie einen Paketnamen, Versionsinformation und Kommentare für das Startabbildpaket an, und klicken Sie auf „Next“.
  6. Wählen Sie eine Plattform (x86 oder x64) aus, ADO-Unterstützung, beliebige optionale Schriftarten, die Sie benötigen, ggf. einen benutzerdefinierten Hintergrund für das Startabbild und beliebige zusätzliche Ordner, die im Windows PE-Abbild enthalten sein sollen, und klicken Sie auf „Next“.
  7. Wählen Sie im Fenster „MDT Package“ (MDT-Paket) die Option „Create a new Microsoft Deployment Toolkit Files Package“ (Neues Microsoft Deployment Toolkit-Dateipaket erstellen) aus, geben Sie einen UNC-Pfad an, der als Paketquelle verwendet wird, und klicken Sie auf „Next“.
  8. Geben Sie Namen, Version, Sprache, Hersteller und Kommentare für das MDT-Paket an, und klicken Sie auf „Next“.
  9. Wählen Sie für das Betriebssystemabbild die Option „Create a new OS Install Package“ (Neues Betriebssystem-Installationspaket erstellen) aus, geben Sie den Pfad zu den Windows Server 2008-Quelldateien sowie einen UNC-Speicherort an, der als Paketquellverzeichnis verwendet wird, und klicken Sie auf „Next“.
  10. Wählen Sie für das Clientpaket die Option „Create a new Configuration Manager client package“ (Neues Configuration Manager-Clientpaket erstellen) aus, und klicken Sie auf „Next“.
  11. Wählen Sie für das „Settings Package“ (Einstellungspaket) die Option „Create a new Settings Package“ (Neues Einstellungspaket erstellen) aus. Geben Sie einen UNC-Speicherort an, der als Paketquelle für das Einstellungspaket verwendet wird, und klicken Sie auf „Next“.
  12. Wählen Sie für das Sysprep-Paket die Option „No Sysprep Files required“ (Keine Sysprep-Dateien erforderlich) aus, und klicken Sie auf „Next“.
Vom Assistenten werden jetzt das Startabbild und alle Pakete erstellt. Wenn Sie „Packages“ (Pakete), „Boot Images“ (Startabbilder), „Operating System Install Packages“ (Installationspakete für Betriebssysteme) und „Task Sequences“ (Tasksequenzen) erweitern, werden alle erstellten Pakete und die Tasksequenz angezeigt. Nachdem alle diese Pakete erstellt sind, sollten sie an Verteilungspunkten bereitgestellt werden.
Außer diesen Paketen müssen Sie oft auch Treiber für bestimmte Serverhardware hinzufügen. Dies erledigen Sie, indem Sie Treiber dem Configuration Manager-Treiberspeicher hinzufügen und ein Treiberpaket erstellen, das während der Bereitstellung verwendet wird.
Um Treiber in den Treiberkatalog zu importieren und ein Treiberpaket zu erstellen, gehen Sie zur Configuration Manager-Konsole, klicken Sie mit der rechten Maustaste auf „Drivers“ (Treiber) und dann auf „Import“ (Importieren). Importieren Sie alle Treiber in den angegebenen UNC-Pfad. Geben Sie dann einen UNC-Pfad ein, der alle Treiber enthält, die Sie für Ihre spezifischen Servermodelle gesammelt haben. Sobald dieser Schritt abgeschlossen ist, klicken Sie auf „Next“.
Wählen Sie auf der Seite „Drivers Details“ (Treiberdetails) aus, welche INF-Dateien Sie importieren möchten. Sie haben auch die Möglichkeit, die Treiber einer Kategorie zuzuweisen. (Eine Kategorie könnte auf einem bestimmten Servermodelltyp basieren.) Klicken Sie auf „Next“ und auf der Seite „Add Drivers to Package“ (Treiber dem Paket hinzufügen) auf „New Package“ (Neues Paket). Geben Sie einen Namen, einen Kommentar und einen UNC-Pfad an, die als Paketquelle für das Treiberpaket verwendet werden, und klicken Sie auf „OK“. Wählen Sie „Update distribution points when finished“ (Nach Fertigstellung Verteilungspunkte aktualisieren) aus, und klicken Sie auf „Next“.
Wählen Sie auf der Seite „Add Driver to Boot Images page“ (Treiber zu Startabbildern hinzufügen) das zuvor erstellte Startabbild aus, und aktivieren Sie das Kontrollkästchen „Update distribution points when finished“ (Nach Fertigstellung Verteilungspunkte aktualisieren). Klicken Sie auf „Next“ und auf der Zusammenfassungsseite erneut auf „Next“, um den Assistenten abzuschließen, die Treiber zu importieren und das Treiberpaket zu erstellen.

Bearbeiten der Tasksequenz
Nun, da Sie alle notwendigen Pakete und die Tasksequenz zum Installieren von Windows Server 2008 erstellt haben, möchten Sie wahrscheinlich mehrere der Aktionen in der Standardtasksequenz anpassen. Um die Tasksequenz zu ändern, klicken Sie mit der rechten Maustaste auf die Sequenz und dann auf „Edit“ (Bearbeiten). Daraufhin wird die Tasksequenzvorlage von Microsoft Deployment Server angezeigt, wie in Abbildung 3 zu sehen.
Abbildung 3 Sie können die Standardtasksequenz anpassen
Abbildung 3 Sie können die Standardtasksequenz anpassen
Allgemein ausgedrückt, ist eine Tasksequenz eine Reihe von Befehlszeilenelementen, die als Tasks bezeichnet werden, von denen jeder bestimmte Vorgänge durchführt. Jeder Task kann über bestimmte Eigenschaften verfügen, die konfiguriert werden können und für die auf der Registerkarte „Options“ (Optionen) Bedingungen festgelegt sein können, anhand derer bestimmt wird, ob bestimmte Aufgaben ausgeführt werden sollten. Für den ersten Task in der Tasksequenz sind z. B. Bedingungen wie in Abbildung 4 festgelegt.
Abbildung 4 Sie können einen Task oder dafür festgelegte Bedingungen auf der Registerkarte „Optionen“ deaktivieren.
Abbildung 4 Sie können einen Task oder dafür festgelegte Bedingungen auf der Registerkarte „Optionen“ deaktivieren.
In diesem Beispiel ist der Task standardmäßig deaktiviert, da das Kontrollkästchen „Disable this step“ (Diesen Schritt deaktivieren) aktiviert wurde. Wenn der Task aktiviert wäre, würde er nur auf Grundlage der aktuell angegebenen Bedingungen ausgeführt.
Einige der geläufigeren Aufgaben, die Sie u. U. vor der Bereitstellung von Windows Server 2008 ändern müssen, umfassen „Format and Partition Disk“ (Datenträger formatieren und partitionieren), „Validate“ (Überprüfen), „Apply Operating System Image“ (Betriebssystemabbild anwenden) und „Apply Network Settings“ (Netzwerkeinstellungen anwenden).
Anhand des Tasks „Format and Partition Disk“ (Datenträger formatieren und partitionieren) können Sie definieren, wie Sie die Partitionsstruktur der Datenträger für Ihre Serverbereitstellungen erstellen möchten. In der Standardeinstellung wird eine Partition erstellt, die den gesamten Speicherplatz auf dem ersten Datenträger beansprucht. Unter Umständen möchten Sie Ihre Server nicht mit dieser Konfiguration bereitstellen. Deshalb können Sie diese Einstellung ändern und das gewünschte Datenträgerlayout angeben.
Mithilfe des Tasks „Validate“ (Überprüfen) können Sie einige grundlegende Anforderungen wie Arbeitsspeicher und Prozessorgeschwindigkeit prüfen. Wenn in Ihrem Unternehmen beispielsweise ein Arbeitsspeicher von 2 GB Standard für Serverbereitstellungen ist, können Sie dies als Anforderung festlegen. Die Installation wird nicht fortgesetzt, wenn der Server diese Anforderung nicht erfüllt.
Mit dem Task „Apply Operating System Image“ (Betriebssystemabbild anwenden) können Sie das Abbild konfigurieren, das bereitgestellt werden soll. Wenn Sie z. B. Quelldateien für Windows Server 2008 verwenden, können Sie Server Standard, Server Enterprise, Server Datacenter, Server Standard Core, Server Enterprise Core und Server Datacenter Core bereitstellen. Sie müssen das geeignete Abbild auswählen, und dies hängt davon ab, welche Version von Windows Server 2008 bereitgestellt werden soll.
Mit dem Task „Apply Network Settings“ (Netzwerkeinstellungen anwenden) können Sie statische IP-Adressen für Ihre Netzwerkkarten konfigurieren und die Einstellungen für den Beitritt zu einer Domäne oder Arbeitsgruppe ändern. Es ist zwar möglich, mithilfe dieses Tasks eine statische IP-Adresse festzulegen, doch dadurch würde diese Tasksequenz nur für einen Server funktionieren. Später werden Sie erfahren, wie Sie statische IP-Adressen mit Variablen festlegen können, damit Sie eine einzige Tasksequenz für mehrere Server verwenden können.

Installieren und Konfigurieren von Serverrollen
Bisher haben Sie gesehen, wie Sie die Tasksequenz ändern können, um Elemente zu konfigurieren, die mit der Installation des Betriebssystems zusammenhängen. Mit dem Microsoft Deployment Toolkit ist Ihnen aber auch die Möglichkeit gegeben, Serverrollen zu installieren und zu konfigurieren. Sie können z. B. eine Tasksequenz konfigurieren, um Windows Server 2008 auf einem Zweigstellenserver bereitzustellen, auf dem ein schreibgeschützter Domänencontroller und ein Dateiserver ausgeführt werden.
Um dies erfolgreich durchzuführen, navigieren Sie im Tasksequenzeditor zum Task „Install Software“ (Software installieren), und wählen Sie „Add“ (Hinzufügen) | „MDT“ | „Install Roles and Features“ (Rollen und Features installieren). Aktivieren Sie dann im neu erstellten Task „Install Roles and Features“ (Rollen und Features installieren) sowohl „Active Directory Domain Controller“ (Active Directory-Domänencontroller) als auch „File Server“ (Dateiserver), wie in Abbildung 5 gezeigt.
Abbildung 5 Installieren von Rollen und Features
Abbildung 5 Installieren von Rollen und Features
Jetzt müssen Sie die Einstellungen für den schreibgeschützten Domänencontroller konfigurieren. Wählen Sie im Tasksequenzeditor „Add“ (Hinzufügen) | „MDT“ | „Configure ADDS“ (ADDS konfigurieren). Wählen Sie im neu erstellten Task „Configure ADDS“ (ADDS konfigurieren) die Option zum Erstellen eines neuen schreibgeschützten Domänencontrollerreplikats aus, und geben Sie Werte für die folgenden Eigenschaften an:
  • Existing domain DNS name (Vorhandener DNS-Name der Domäne)
  • Replication source domain controller (Replikationsquellen-Domänencontroller)
  • Account (Konto)
  • Recovery (safe mode) password (Wiederherstellungskennwort (abgesicherter Modus))

Arbeiten mit Variablen
Sie sollten unbedingt verstehen, dass eines der leistungsfähigsten Features von Tasksequenzen darin besteht, Benutzern die Möglichkeit zu bieten, nahezu jede Eigenschaft in der Tasksequenz während der Bereitstellung dynamisch als Variable festzulegen. Configuration Manager und Microsoft Deployment bieten beide mehrere Methoden zum Festlegen und Verwenden von Variablen.
Mit Configuration Manager können Sie die Variablen als Computervariable, Auflistungsvariable oder direkt innerhalb der Tasksequenz festlegen. Mit Microsoft Deployment können Sie Variable durch die Datei „customsettings.ini“, durch eine Back-End-Datenbank oder durch einen Webdienst festlegen. Unter technet.microsoft.com/bb632442.aspx finden Sie eine Liste von Variablen, die festgelegt werden können.
Nehmen wir das Festlegen einer statischen IP-Adresse auf einem bestimmten Server als Beispiel. Weiter oben in diesem Artikel haben Sie erfahren, dass Sie die statische IP-Adresse direkt innerhalb der Tasksequenz im Task „Apply Network Settings“ (Netzwerkeinstellungen anwenden) festlegen können. Dies ist nicht die beste Methode, da diese Tasksequenz dann nur für einen bestimmten Server verwendet werden kann.
Stattdessen möchten Sie die Tasksequenz unverändert lassen und die IP-Adresse durch eine Variable festlegen. Es folgt eine Schritt-für-Schritt-Anleitung zum Festlegen der statischen IP-Adresse als Computervariable:
  1. Navigieren Sie in der Configuration Manager-Konsole zu „System Center Configuration Manager“ | „Site Database“ (Standortdatenbank) | „Computer Management“ (Computerverwaltung) | „Collections“ (Sammlungen).
  2. Um einem Computer eine Variable pro Computer zuzuweisen, suchen und erweitern Sie die Sammlung, der der Computer angehört. Klicken Sie mit der rechten Maustaste auf den Computer, auf „Properties“ (Eigenschaften) und auf die Registerkarte „Variables“ (Variable).
  3. Um benutzerdefinierte Variablen und ihre zugeordneten Werte anzugeben, klicken Sie auf das Neu-Symbol, um das Dialogfeld für neue Variable zu öffnen.
  4. Im Dialogfeld für neue Variable müssen Sie einen Namen für die Variable angeben und festlegen, ob diese Variable in der Configuration Manager 2007-Konsole sichtbar sein wird. Für eine statische IP-Adresse würden Sie die folgenden Variablen hinzufügen:
  • OSDAdapter0IPAddressList
  • OSDAdapter0SubnetMask
  • OSDAdapter0Gateways
  • OSDAdapter0DNSServerList
Die konfigurierten Variablen sollten jenen in Abbildung 6 ähneln.
Abbildung 6 Verwenden von Computervariablen zum Festlegen einer statischen IP-Adresse
Abbildung 6 Verwenden von Computervariablen zum Festlegen einer statischen IP-Adresse

Bereitstellen der Tasksequenz
Nun, da Sie die Tasksequenz vollständig konfiguriert und Ihre Variablen eingerichtet haben, können Sie Windows Server 2008 bereitstellen. Configuration Manager bietet mehrere Methoden zum Bereitstellen eines Betriebssystems, z. B. Pre-Boot eXecution Environment (PXE), per Tasksequenz startbare Medien, eigenständige Medien und eine Standardankündigung für vorhandene Computer.
Der Einfachheit halber werde ich skizzieren, wie eine Tasksequenz für startbare Medien erstellt wird. Navigieren Sie in der Configuration Manager-Konsole zu „Task Sequences“ (Tasksequenzen), und wählen Sie im Menü „Actions“ (Aktionen) die Option „Create Task Sequence Media“ (Tasksequenzmedien erstellen) aus. Wählen Sie auf der Seite „Select Media Type“ (Medientyp auswählen) die Option „Bootable Media“ (Startbare Medien) aus, und klicken Sie auf „Next“ (Weiter). Geben Sie auf der Seite „Media Type“ (Medientyp) eine CD als Art des Mediums an, und geben Sie einen Namen für die Mediendatei an. Auf der Seite „Security“ (Sicherheit) können Sie ein Kennwort angeben, um die Medien zu schützen, oder aber ein selbst signiertes Zertifikat. Als Nächstes geben Sie das Startabbild an. Sobald dies abgeschlossen ist, navigieren Sie zur Bestätigungsseite, wo Sie auf „Fertig stellen“ klicken. Ausführliche Anweisungen zum Bereitstellen mit dieser und anderen Methoden finden Sie in der Dokumentation unter technet.microsoft.com/bb681029.aspx.

Zusammenfassung
In diesem Artikel haben Sie erfahren, wie Sie mit System Center Configuration Manager und Microsoft Deployment Windows Server 2008 bereitstellen, Rollen wie Dateiserver und Domänencontroller hinzufügen, computerspezifische Variable festlegen und das Betriebssystem mithilfe von „Task Sequence Bootable media“ (Per Tasksequenz startbare Medien) bereitstellen können. In Wirklichkeit können Serverbereitstellungen sehr viel komplexer sein, doch dieser Artikel sollte Ihnen dabei helfen, mit der Konsolidierung Ihrer Server- und Clientbereitstellungstools zu beginnen.

Tim Mintner ist leitender Softwareentwicklungsingenieur im Microsoft Solutions Accelerator-Team, das sich auf das Microsoft Deployment Toolkit konzentriert. Er hat mehr als 14 Jahre Erfahrung in der Arbeit mit Kunden bei der Bereitstellung von Microsoft-Betriebssystemen. Sie können Tim Mintner unter tmintner@microsoft.com erreichen.


 Sonderbeitrag: Windows Server&#160;2008: &#220;berwachung und Einhaltung gesetzlicher Bestimmungen in Windows Server&#160;2008
Sonderbeitrag: Windows Server 2008 Rob Campbell und Joel Yoker

Überwachung und Einhaltung gesetzlicher Bestimmungen in Windows Server 2008
Kurz zusammengefasst:
  • Die zunehmende Bedeutung der Einhaltung gesetzlicher Bestimmungen
  • Verstehen von Änderungen in Ihrer Umgebung
  • Herausforderungen bei der Überwachung von Sicherheitsereignissen
  • Technische Aspekte der Überwachung

Die Welt der Informationstechnologie ist kontinuierlichen Änderungen unterworfen. Wie es bei den meisten IT-Organisation der Fall ist, werden auch Sie unter zunehmendem Druck stehen, die in Ihrer Umgebung stattfindenden Änderungen zu verstehen. Mit zunehmender Komplexität und Größe von IT-Umgebungen erhöhen sich die Auswirkungen von
administrativen Fehlern und der unbeabsichtigten Offenlegung vertraulicher Daten. In der heutigen Gesellschaft muss Verantwortung für solche Ereignisse übernommen werden. Folglich sind Organisationen jetzt gesetzlich für den Schutz der von ihnen verwalteten Informationen verantwortlich.
Dabei ist die Überwachung von Änderungen in Ihrer Umgebung ein wichtiger Aspekt. Warum ist dies der Fall? Überwachung bietet die Mittel für das Verständnis sowie die Verwaltung von Änderungen in den großen, stark verteilten IT-Umgebungen von heute. In diesem Artikel geht es um häufige Herausforderungen, denen sich die meisten Organisationen gegenüber sehen, die Einhaltung von Richtlinien und Vorschriften im IT-Bereich, die Grundlagen der Überwachung in Windows® und darum, wie die Funktionalität von Windows Server® 2008 und Microsoft® System Center Operations Manager 2007-Überwachungssammeldienste (Audit Collection Services, ACS) als Ergänzung einer umfassenden Überwachungsstrategie dienen kann.

Herausforderungen bei der Überwachung
Ein kurzer Blick auf die Schlagzeilen der Nachrichten verdeutlicht, dass die Offenlegung vertraulicher Daten ein alltägliches Problem ist. Viele dieser Vorfälle bringen gerichtliche Schritte, finanzielle Verluste und Public Relations-Probleme für die betreffenden Organisationen mit sich. Die Auswirkungen einer Offenlegung vertraulicher Dateien können erheblich verringert werden, wenn Sie über die Fähigkeit verfügen, aufgetretene Änderungen zu erklären bzw. Probleme schnell zu identifizieren.
Angenommen Ihre Organisation ist für das Verwalten personenbezogener Informationen (Personally Identifiable Information, PII) für einen bestimmten Kundenkreis verantwortlich. Obwohl es eine Reihe von Möglichkeiten zum Schutz der in Ihren Systemen enthaltenen Informationen gibt, kann es dennoch zu Gefährdungen kommen. Bei richtiger Überwachung weiß die Organisation genau, welche Systeme gefährdet wurden, und vielleicht sogar, welche Daten verloren gegangen sind. Ohne Überwachung könnten die Auswirkungen von Datenverlusten erheblich größer sein, da es keine Möglichkeit gäbe, das Ausmaß der Gefährdung einzuschätzen.
Warum unternehmen die meisten IT-Organisationen in diesem Bereich also noch nichts? Tatsache ist, dass viele Organisationen die technischen Aspekte der Überwachung nicht vollständig verstehen. Obwohl leitende Mitarbeiter Konzepte wie Sicherung und Wiederherstellung im Allgemeinen verstehen, ist die Komplexität, die mit der Überwachung von Änderungen in der Umgebung verknüpft ist, schwer zu vermitteln. Demzufolge werden Fragen zur Überwachung erst dann gestellt, wenn es zu einem bedeutenden Vorfall gekommen ist. Die grundlegende Überwachung könnte beispielsweise aktiviert sein, aber wenn das System aufgrund mangelnder Planung nicht so konfiguriert ist, dass bestimmte Änderungen überwacht werden, können diese Informationen nicht gesammelt werden.
Zudem gibt es bei überwachten Sicherheitsereignissen eine Reihe von Problemen, die von IT-Experten behandelt werden müssen. Eine solche Schwierigkeit ist die Verteilung der Systeme innerhalb der großen Computerumgebungen von heute, wodurch bedeutende Herausforderungen beim Sammeln und Aggregieren von Informationen entstehen, da es auf jedem System oder Satz von Systemen jederzeit zu Änderungen kommen kann. Dies führt zu einer weiteren Herausforderung: der Korrelation. Oft ist das Übersetzen von Beziehungen zwischen Ereignissen auf einzelnen und mehreren Systemen erforderlich, um die wahre Bedeutung von Ereignissen zu ermitteln.
Ein weiteres Problem besteht darin, dass die Überwachung in der Regel die traditionellen Organisationsgrenzen übersteigt. Unterschiedliche Organisations- oder Teamstrukturen existieren aus verschiedenen Gründen und lassen sich möglicherweise nicht leicht überbrücken. Viele Organisationen verfügen über ein Verzeichnisdienstteam, ein Messaging-Infrastrukturteam und ein Desktopteam, aber wahrscheinlich gibt es nur ein Sicherheitsteam, das für alle diese Bereiche verantwortlich ist. Zudem ist das dedizierte Sicherheitspersonal für Ihre Organisation möglicherweise nicht an allen Standorten physisch anwesend. Zweigstellen beispielsweise verlassen sich oft auf eine einzige Person oder ein kleines Team für alle Aufgaben einschließlich der Verwaltung von Sicherheitsereignisprotokollen.
Schließlich bedeute die reine Quantität der Ereignisse bereits eine Herausforderung. Überwachte Sicherheitsereignisse treten in viel höherem Umfang als andere Arten der Ereignisprotokollierung auf. Die Anzahl der gesammelten Ereignisse erschwert ein wirksames Aufbewahren und Überprüfen von Protokollen. Die aktuelle und geplante Gesetzgebung enthält Anforderungen für die Datenaufbewahrung, was die Verwaltung heutiger Computinginfrastrukturen nicht einfacher macht.
In der Vergangenheit gründete die Überwachung des Zugriffs auf Informationen einerseits auf dem Wunsch, über Vorgänge informiert zu sein, andererseits auf dem Versuch, Systeme sicherer zu gestalten. Doch heute, da Organisationen (und die für sie verantwortlichen leitenden Mitarbeiter) gesetzlich für den Verlust von Informationen oder einen Mangel an angemessenen Schutzvorrichtungen zur Verantwortung gezogen werden, ist es für IT-Administratoren äußerst wichtig, sich mit den Regelungen vertraut zu machen, die für ihre Umgebungen gelten könnten. Für globale Unternehmen sind die Herausforderungen noch komplexer, da jedes Land eigene Regelungen in Bezug auf Informationen und Datenschutz hat. In Abbildung 1 sind einige Beispiele für die Gesetzgebung zur Einhaltung von Bestimmungen sowie die entsprechenden Anforderungen an IT-Organisationen aufgeführt.
Figure 1 Vorschriften und ihre Bedeutung für IT-Experten (Close Figure 1)

Vorschrift | Anforderungen
Sarbanes-Oxley Act von 2002 (SOX) | Abschnitt 404 erkennt die Rolle von Informationssystemen an und fordert von börsennotierten Unternehmen eine jährliche Prüfung ihrer internen Kontrollen bezüglich ihrer Finanzberichte.
Health Insurance Portability and Accountability Act (HIPPA) | Behandelt die Sicherheit und den Datenschutz innerhalb von Gesundheitsdiensten. Die „Sicherheitsregel“ deckt administrative, physische und technische Schutzvorrichtungen für diese Daten ab.
Electronic Discovery (eDiscovery) | Definiert Standards für die Aufbewahrung von Dokumenten und den Zugriff darauf, einschließlich Verantwortlichkeit dafür, wer auf Dokumente zugreift und auf welche Weise.
Federal Information Security Management Act von 2002 (FISMA) | Bundesmandat für die Bereitstellung eines umfassenden Informationssicherheitsrahmens (INFOSEC) für US-Regierungssysteme, Koordination mit verschiedenen Strafverfolgungsbehörden, Einrichtung von Kontrollen, Anerkennung von Handelsprodukten und Softwarefunktionen. Abschnitt 3544 befasst sich mit der Verantwortung von Dienststellen, einschließlich IT-Kontrollen.
Federal Information Processing Standards (FIPS) Veröffentlichung 200 | Gibt die Mindestsicherheitsanforderungen für Bundesinformationen und Informationssysteme an und skizziert die Verwendung von Empfehlungen in NIST Special Publication (SP) 800-53. NIST SP800-53, Abschnitt AU-2 (Überwachbare Ereignisse) legt fest, dass Informationssysteme die Funktion zum Kompilieren von Überwachungsaufzeichnungen aus verschiedenen Komponenten in einem systemweiten, zeitkorrelierten Überwachungsprotokoll bieten, überwachte Ereignisse gemäß individueller Komponenten verwalten sowie gewährleisten müssen, dass die Organisation überwachbare Ereignisse regelmäßig überprüft.
Welche Schritte sollten IT-Experten nun bei all diesem gesetzlichen Druck unternehmen? IT-Manager und Techniker müssen klare und präzise Vorgaben erstellen, die sie Personen innerhalb und außerhalb der Organisation präsentieren können. Diese umfassen die Entwicklung einer angemessenen Überwachungsstrategie, für die proaktive Maßnahmen und Investitionen erforderlich sind. Das wesentliche Konzept dabei besteht darin, dass Überwachung nicht erst nach dem Entwurf ins Spiel kommt, wie es allzu oft der Fall ist.
IT-Herausforderungen wie diese können in der Regel durch eine Kombination aus Personen, Prozessen und Technologie gelöst werden. Bei der Überwachung ist der Prozess von besonderer Bedeutung. Daher sollte der erste Schritt darin bestehen, die Grundlagen zu erlernen, damit Sie auf die Anforderungen Ihrer Organisation im Bereich der Einhaltung gesetzlicher Bestimmungen reagieren können. Im Folgenden werden einige der Grundlagen der Überwachung in Windows und anschließend die Änderungen in Windows Server 2008 und Windows Vista® erörtert.

Die Überwachung von Sicherheitsereignissen
Alle überwachten Ereignisse werden im Windows-Sicherheitsereignisprotokoll aufgezeichnet. Diese Ereignisse erfordern in der Regel nicht sofort eine Aktion und sind oft lediglich informativ. Jedes Ereignis zeichnet einen einfachen Überwachungserfolg oder Überwachungsfehler für eine bestimmte Art des Zugriffs auf, die stattgefunden hat. Dies unterscheidet sich von den Anwendungs- oder Systemereignisprotokollen, bei denen Probleme über eine Farbcodierung identifiziert werden können (Hinweis: suchen Sie nach den roten Ereignissen, um das Problem zu finden).
Das Sicherheitsereignisprotokoll unterscheidet sich dadurch, dass überwachte Ereignisse oft aufgrund ihres Umfangs verborgen sind, und, wie bereits angemerkt, die Korrelation von Sicherheitsdaten eine bedeutende Herausforderung darstellen kann. Selbst eine einfache Datenverletzung auf einem einzelnen System ist problematisch. Das Sicherheitsereignisprotokoll müsste analysiert werden, um festzustellen, welches Konto für den Zugriff auf die Daten verwendet wurde. Dazu müsste ein Administrator das Protokoll durchsuchen, um das Konto zu finden. Leider sind die heutigen hoch entwickelten Angriffe oft koordiniert und verteilt, sodass diese Art der Analyse für einen Administrator recht schwierig wird.
Dennoch ist es wichtig, die Hauptelemente zu verstehen, die die Aufzeichnung von Informationen im Sicherheitsereignisprotokoll in Windows ermöglichen. Überwachungsrichtlinie und Systemzugriffssteuerungslisten (System Access Control Lists, SACLs). Überwachungsrichtlinien sind konfigurierbare Einstellungen für einen lokalen Computer durch die Gruppenrichtlinie oder lokale Sicherheitsrichtlinie. Durch Überwachungsrichtlinien wird die Sammlung von Erfolgs- und Fehlerereignissen für bestimmte Zugriffsarten definiert. Die folgenden Hauptkategorien für Überwachungsrichtlinien gibt es in Windows bereits seit vielen Jahren (später mehr zur neuen präzisen Überwachungsrichtlinie in Windows Server 2008):
  • Überwachen von Kontoanmeldungsereignissen
  • Überwachen der Kontoverwaltung
  • Überwachen des Verzeichnisdienstzugriffs
  • Überwachen von Anmeldeereignissen
  • Überwachen des Objektzugriffs
  • Überwachen von Richtlinienänderungen
  • Überwachen der Rechteverwendung
  • Überwachen der Prozessverfolgung
  • Überwachen von Systemereignissen
Die meisten IT-Organisationen sind sich der Anforderung bewusst, eine Überwachungsrichtlinie sowie diese zugeordneten Kategorien zu definieren, doch die Überwachungsrichtlinie stellt lediglich einen Teil der Lösung dar. SACLs spielen bei der Implementierung eines ganzheitlichen Überwachungsplans ebenfalls eine bedeutende Rolle. Zwei bestimmte Überwachungsrichtlinienkategorien (Überwachen des Verzeichnisdienstzugriffs und Überwachen des Objektzugriffs) sind vollständig von SACLs abhängig, um Informationen im Sicherheitsereignisprotokoll zurückzugeben. Worum genau handelt es sich bei SACLs?
Jedes Objekt (Datei, Registrierung oder Verzeichnisdienst) verfügt über eine Zugriffssteuerungsliste (ACL) mit einem oder mehreren Zugriffssteuerungseinträgen (Access Control Entries, ACEs), die in zwei Typen unterteilt ist: eine besitzerverwaltete Zugriffssteuerungsliste (Discretionary Access Control List, DACL) und eine SACL (in der Einstellungen definiert sind, mit denen Zugriffsversuche auf gesicherte Objekte protokolliert werden). Jeder ACE in einer SACL gibt die Arten von Zugriffsversuchen durch einen angegebenen Vertrauensnehmer an, die im Sicherheitsereignisprotokoll protokolliert werden sollten. Durch ACEs wird die Protokollierung von erfolgreichen und/oder fehlgeschlagenen Zugriffsversuchen auf bestimmte Objekte definiert. Abbildung 2 zeigt die Anwendung einer SACL auf ein Objekt zum Generieren von Ereignissen für bestimmte Zugriffsarten.
Abbildung 2 Anwendung einer SACL auf ein Objekt
Abbildung 2 Anwendung einer SACL auf ein Objekt
Es ist äußerst wichtig, die Beziehung zwischen der Überwachungsrichtlinie und SACLs zu verstehen, da eine Konfiguration erforderlich ist, um die „richtigen“ überwachten Ereignisse in Bezug auf Änderungen in der Umgebung festzuhalten. Wie bereits erwähnt, ermöglichen die Überwachungsrichtlinien für die Überwachung des Verzeichnisdienstzugriffs und die Überwachung des Objektzugriffs nur die Generierung von Überwachungen im Sicherheitsereignisprotokoll für diese bestimmten Kategorien, doch Ereignisse werden nur generiert, wenn für ein Objekt ein Überwachungs-ACE in der jeweiligen SACL konfiguriert wurde. Wenn dies erfolgt ist, werden Sicherheitsereignisse von der lokalen Windows-Sicherheitsautorität (Local Security Authority, LSA) generiert und in das Sicherheitsereignisprotokoll geschrieben.
Ereignisse bestehen aus zwei unterschiedlichen Bereichen: dem Header, der statisch und für jeden Ereignisbezeichner (Ereignis-ID) vordefiniert ist, und dem Text, der dynamisch ist und verschiedene Details für verschiedene Ereignisse enthält. Abbildung 3 zeigt diese beiden Elemente in einem Beispiel eines Windows Server 2008-Sicherheitsereignisses. Für die Analysephase eines Überwachungsprojekts ist das Verständnis dieser Ereigniskomponenten sehr wichtig, und besonders interessant dabei ist, wie Informationen in Tools wie ACS zurückgegeben werden.
Abbildung 3 Header und Text eines überwachten Ereignisses
Abbildung 3 Header und Text eines überwachten Ereignisses

Windows Eventing 6.0
In welchen Bereichen hilft Windows Server 2008 Ihrer Organisation jetzt, da Sie das Problem verstehen, sich diesen Herausforderungen zu stellen? Windows Server 2008 ist die erste Serververöffentlichung, die das neue Windows Eventing 6.0-Ereignissubsystem enthält, das den Bereich der Sicherheitsereignisverwaltung erheblich verbessert. Der Schwerpunkt in diesem Artikel liegt zwar auf Windows Server 2008, doch 95 Prozent des neuen Featuresatzes sind in Windows Vista vorhanden.
Besonders auffällig bei Windows Eventing 6.0 ist die neue Benutzeroberfläche. Das neue Event Viewer Microsoft Management Console (MMC)-Snap-In bietet eine hervorragende Übersichts- und Zusammenfassungsseite, flexible benutzerdefinierte Ansichten und stark verbesserten erklärenden Text. Diese Schnittstellen können dem Endbenutzer oder Systemadministrator bei der Suche nach Ereignisinformationen und beim Konfigurieren wichtiger Ereignisprotokolloptionen direkt von der Ereignisanzeige aus helfen.
Ein Hauptproblem, das sich oft auf Sicherheitsdaten innerhalb des Ereignisprotokolls ausgewirkt hat, war das Aufbewahren von Daten. Früher gab es beim Ereignisprotokollsubsystem (einschließlich aller Protokolle) Beschränkungen im Hinblick auf die Skalierbarkeit. Wenn diese Beschränkungen überschritten wurden, stellte das gesamte Subsystem das Protokollieren von Ereignissen ein. Das ist bei Windows Eventing 6.0 jedoch nicht der Fall, und die einzige Einschränkung für Organisationen besteht heute in der Größe des verfügbaren Speicherplatzes. Sie sollten jedoch beachten, dass sehr große Ereignisprotokolle für die Analyse unhandlich sein können, da jeder einzelne Protokolleintrag beim Filtern bewertet werden muss. Aus diesem Grund sollte Ihr Protokoll eine überschaubare Größe haben.
Doch selbstverständlich bleibt es dem IT-Administrator überlassen, einen Archivierungsplan für die Ereignisprotokolle verschiedener Systeme zu entwickeln. Um dabei Unterstützung auf der lokalen Serverebene zu bieten, wird in Windows Eventing 6.0 das Feature „Volles Protokoll archivieren, Ereignisse nicht überschreiben“ verfügbar gemacht. In früheren Versionen von Windows konnte diese Option nur direkt über eine Änderung des AutoBackupLogFiles-Registrierungswerts festgelegt werden. Obwohl hierdurch ein Mechanismus für die lokale Archivierung von Protokollen verfügbar gemacht wird, stellt diese Option auf lange Sicht keine Lösung für das Verwalten dieser Dateien dar, und auch das Aggregationsproblem, das bei mehreren Systemen eintritt, wird nicht angesprochen. Überwachungssammeldienste bieten dafür eine vollständige Lösung, die im Anschluss näher erläutert wird.
Die neue Schnittstelle ist aber erst der Anfang. Die wahre Leistungsfähigkeit von Windows Eventing 6.0 zeigt sich im neuen Windows-Ereignisprotokolldienst und dem zugrunde liegenden Modul auf XML-Basis. Diese Komponenten liefern die erhöhte Skalierbarkeit sowie Eingabehilfen und Verwaltungsoptionen. Ereignisse werden jetzt in einem flexiblen XML-Format gespeichert, das benutzerdefinierte Lösungen ermöglicht, durch die diese Informationen systemintern abgefragt werden können.
Windows Eventing 6.0 bietet auch die Funktion, bestimmten Ereignissen Verwaltungsaktionen zuzuordnen. Dies geschieht durch Integration des Windows-Ereignissammlungsdiensts mit dem Taskplaner, um eine aufgabenbasierte Ereignisprotokollierung zur Verfügung zu stellen. Dies ist ein neues Paradigma für den Taskplaner, der vorher darauf beschränkt war, Ereignisse abhängig von der Uhrzeit auszulösen. Der Assistent „Aufgabe an dieses Ereignis anfügen“ (verfügbar im Kontextmenü jedes Ereignisses in der Windows Server 2008-Ereignisanzeige) bietet eine einfache Möglichkeit, ein Programm zu starten, eine E-Mail-Nachricht zu senden oder eine Nachricht immer dann anzuzeigen, wenn ein bestimmtes Ereignis protokolliert wird. Dies kann bei dem Versuch, bestimmte Aktionen in Ihrer Umgebung zu identifizieren, die mit einem bestimmten Sicherheitsereignis verbunden werden können, sehr nützlich sein. Wenn Sie beispielsweise Änderungen am Registrierungsschlüssel „Schema Update Allowed“ (Schemaaktualisierung zulässig) auf Ihren Domänencontrollern überwachen, können Sie einen Task erstellen, der eine E-Mail-Nachricht an bestimmte Sicherheitsadministratoren sendet, um sie zu benachrichtigen, wenn dieser Registrierungsschlüssel geändert wird.
Neben der neuen Möglichkeit zum Sammeln und Speichern einer großen Anzahl von Ereigniseinträgen können Sie jetzt auch besser steuern, welche Ereignisse im Ereignisprotokoll aufgezeichnet werden. Dies erfolgt mithilfe eines neuen Features mit der Bezeichnung präzise Überwachungsrichtlinie (Granular Audit Policy, GAP). In früheren Versionen von Windows führten die neun breit angelegten Überwachungskategorien oft zur Ereignisüberlastung. Die Kategorien auf oberster Ebene können jetzt über 50 präzise Unterkategorien gesteuert werden, von denen jede eine verwandte Teilmenge von Ereignissen darstellt.
Dies bietet Ihnen die Möglichkeit, weniger wichtige Informationen aus dem Ereignisprotokoll herauszufiltern, ohne dass die Sichtbarkeit auf Kategorienebene verloren geht. Wenn Sie beispielsweise auf einem bestimmten System nur Änderungen an der Registrierung überwachen wollen, nicht aber am Dateisystem, konnten Sie vorher nur auswählen, ob in der Objektzugriffskategorie ein Erfolg oder Fehler gemeldet werden sollte. Mit GAP können Sie jetzt Unterkategorien wie Dateisystem, Zertifizierungsdienste und Dateifreigabe herausfiltern und nur Ereignisse in der Unterkategorie „Registrierung“ melden. Um die GAP-Unterkategorien auf einem Windows Server 2008-System zu untersuchen, müssen Sie den Auditpol-Befehl in einer Eingabeaufforderung mit erweiterter Berechtigung ausführen. Geben Sie Folgendes ein, um die verfügbaren GAP-Unterkategorien aufzulisten:
auditpol /list /subcategory:*
Geben Sie Folgendes ein, um eine Liste von GAP-Unterkategorien abzurufen, die auf Ihrem System konfiguriert sind:
auditpol /get /category:*
Beachten Sie, dass GAP nicht über die standardmäßige Benutzeroberfläche für die Gruppenrichtlinie konfigurierbar ist und über auditpol.exe. verwaltet werden muss. Der Knowledge Base-Artikel unter support.microsoft.com/kb/921469 enthält Anweisungen, wie GAP-Einstellungen über die Gruppenrichtlinie für Windows Server 2008- und Windows Vista-Systeme bereitgestellt werden.
Windows Server 2008 kann sowohl alte als auch neue Werte der bestimmten Typen im Sicherheitsereignisprotokoll erfassen. In früheren Versionen von Windows protokollierte das Überwachungssubsystem nur den Namen des jeweils geänderten Active Directory®-Objektattributs oder -Registrierungswerts. Die vorherigen und aktuellen Werte des Attributs wurden nicht protokolliert. Diese neue Funktion gilt für Active Directory-Domänendienste, Active Directory Lightweight-Verzeichnisdienste und die Windows-Registrierung. Durch Aktivieren von „Überwachungserfolg“ oder „Überwachungsfehler“ auf den Unterkategorien von „Registrierung“ oder „Verzeichnisdienständerungen“ und Einstellen der zugeordneten SACLs werden ausführliche Ereignisse im Ereignisprotokoll für Aktionen auf diesen Objekten gemeldet. Dies kann mit folgenden auditpol-Befehlen durchgeführt werden:
auditpol /set /subcategory:"Registry" /success:enable
auditpol /set /subcategory:"Directory Service
    Changes" /success:enable
Registrierungsänderungen werden als Ereignisse mit der Ereignis-ID 4657 angezeigt, wie in Abbildung 4 dargestellt.
Abbildung 4 Vor und nach einer Registrierungsänderung
Abbildung 4 Vor und nach einer Registrierungsänderung
Dieses Feature ist besonders nützlich, wenn Änderungen an Active Directory-Objekten nachverfolgt werden sollen. Verzeichnisdienständerungen werden als Paar von Ereignissen mit der Ereignis-ID 5136 aufgeführt, wie in Abbildung 5 dargestellt. Beim jedem Ereignis sind das Verzeichnisdienstobjekt, Attribut und der Vorgang im Text des Ereignisses enthalten. Bei Änderungen an Attributen mit vorhandenen Daten sind zwei Vorgänge zu sehen: Der gelöschte Wert und der hinzugefügte Wert. Bei Attributen, die nicht aufgefüllt wurden, wäre der Vorgang für den hinzugefügten Wert nur ersichtlich, wenn Daten in dieses Attribut geschrieben werden. Wenn beispielsweise ein erfolgreicher Änderungsvorgang auf einem Attribut eines Benutzerobjekts, z. B. telephoneNumber, durchgeführt wird, protokolliert Active Directory die früheren und aktuellen Werte des Attributs in ausführlichen Ereignisprotokolleinträgen.
Abbildung 5 Vor und nach einem Verzeichnisdienständerungsereignis
Abbildung 5 Vor und nach einem Verzeichnisdienständerungsereignis
Beim Erstellen eines neuen Objekts werden Werte der Attribute, die zum Zeitpunkt der Objekterstellung aufgefüllt sind, protokolliert. Beim Verschieben eines Objekts innerhalb einer Domäne wird der frühere und neue Speicherort (in der Form des „Distinguished Name“) protokolliert. Dieses Feature zum Protokollieren von Alt und Neu wird standardmäßig ermöglicht, wenn die entsprechenden Überwachungsrichtlinieneinstellungen vorhanden sind. Wenn ein Attribut geheim gehalten werden soll, etwa die Nummernänderung einer Mitarbeiter-ID, können Sie bestimmte Attribute durch eine einfache Schemaänderung ausschließen. Durch Ändern der searchFlags-Eigenschaft des Attributs im Schema auf 0x100 (Wert 256 -NEVER_AUDIT_VALUE), wie in Abbildung 6 dargestellt, wird das Verzeichnisdienständerungsereignis nicht gemeldet, wenn Änderungen am Attribut eintreten.
Abbildung 6 Ausschließen eines Attributs aus Verzeichnisdienständerungen
Abbildung 6 Ausschließen eines Attributs aus Verzeichnisdienständerungen
Eines der wichtigen neuen Features in Windows Eventing 6.0 sind schließlich die Ereignisabonnements. Wie bereits erwähnt, ist der Zugriff auf das Ereignisprotokoll und seine Überprüfung eine Hauptaufgabe der Systemverwaltung. Die neue Ereignisabonnementfunktion bietet eine Möglichkeit, Ereignisse direkt zwischen Systemen weiterzuleiten. Ereignisabonnements bestehen aus einer Ereignissammlung, bei der Ereignisse gesammelt werden, und aus Ereignisquellen, die so konfiguriert sind, dass Ereignisse an angegebene Hosts weitergeleitet werden. Die Möglichkeit, Ereignisse zu untersuchen, wird vom Windows-Ereignissammlungsdienst (neu in Windows Eventing 6.0) bereitgestellt, und die Abonnentenfunktionalität ist im Windows-Ereignisprotokolldienst integriert. Ein Collector kann so konfiguriert werden, dass Ereignisse aus vielen Ereignisquellen gesammelt werden, bei denen es sich um Windows Server 2008- oder Windows Vista-Systeme handeln kann.
Alle in Ereignisquellen gesammelten Daten befinden sich in einem separaten Ereignisprotokoll namens „Weitergeleitete Ereignisse“ (ForwardedEvents.evtx) und werden vom Ereignisprotokolldienst auf dem Collector verwaltet. Eine Konfiguration beider Endpunkte (Collector und Quelle) ist erforderlich und kann automatisiert werden („winrm quickconfig -q“ in der Quelle und „wecutil qc /q“ im Collector). Es sollte beachtet werden, dass diese Ereignisabonnementfunktion nicht für Unternehmen entwickelt wurde und keine Systeme ersetzen soll, die Ereignisse an eine externe Datenbank liefern.
Ein Beispiel für den Einsatz dieser Funktion ist eine kleine Webfarm. Angenommen Sie verfügen über einen kleinen Satz von Systemen, die einer bestimmten Website (einschließlich Webservern und SQL Servern) zugeordnet sind. Mithilfe der neuen Ereignisabonnementfunktion können die Systeme ihre Sicherheitsereignisprotokollinformationen auf einem einzelnen System konsolidieren. Größere Umgebungen benötigen in der Regel ein erweitertes Toolset für die Ereignisprotokollkonsolidierung.

Überwachungssammeldienste
Angesichts aller neuen Funktionen von Windows Server 2008 besteht die wirkliche Lösung für die langfristige Verwaltung und Archivierung von Sicherheitsereignisprotokollinformationen in einer zentralisierten Datenbank von Überwachungsinformationen. Überwachungssammeldienste sind ein zentrales Feature von System Center Operations Manager 2007. ACS bietet einen Mechanismus für das Weiterleiten, Sammeln, Speichern und die Analyse von Sicherheitsereignisdaten. Sicherheitsereignisse werden annähernd in Echtzeit gesammelt und in einem zentralen SQL-Repository gespeichert. ACS bietet Organisationen zudem eine Methode zum Bereitstellen von Zugriff auf der niedrigsten Berechtigungsebene zum Überwachen von Informationen, da kein physischer Zugriff auf die überwachten Systeme erforderlich ist. Im Folgenden wird näher untersucht, wie ACS funktioniert.
ACS hat drei Hauptkomponenten. Die erste ist die Weiterleitung, die Teil des Operations Manager-Agent ist und Ereignisprotokolldaten vom Client an die ACS-Infrastruktur überträgt. Die Weiterleitung überträgt Daten an die zweite Komponente, den Collector, der auf der Serverseite abhört. ACS-Weiterleitungen stellen eine Verbindung über TCP-Port 51909 her, um mit ihrem zugewiesenen Collector sicher zu kommunizieren. Vor der Übertragung werden die Ereignisprotokolldaten in XML normalisiert, das heißt, überschüssige Informationen werden entfernt und die Ereignisinformationen werden in zugeordneten Feldern auf der Grundlage ereignisspezifischer Header- und Textinformationen zusammengefasst. Wenn die Informationen den Collector erreichen, werden sie an die dritte und letzte Komponente gesendet, die ACS-Datenbank. Diese wird zum Repository für die langfristige Speicherung von Sicherheitsereignisinformationen. Nach dem Speichern können die Informationen direkt mithilfe von SQL-Abfragen abgerufen oder mithilfe von HTML-Berichten über SQL Server® Reporting Services gerendert werden. ACS stellt drei Standardansichten bereit, wie in Abbildung 7 dargestellt.
Figure 7 ACS-Ansichten (Close Figure 7)

ACS-Ansichtenname | Zweck
AdtServer.dvHeader | Headerinformationen aus gesammelten Ereignissen.
AdtServer.dvAll | Header- und alle Textinformationen aus gesammelten Ereignissen.
AdtServer.dvAll 5 | Header und die ersten fünf Zeichenfolgen der Textinformationen aus gesammelten Ereignissen.
Leistungsmäßig kann ein einzelner ACS-Collector einen Spitzenwert von maximal 100.000 Ereignissen pro Sekunde und ein fortlaufendes Maximum von 2.500 Ereignissen pro Sekunde behandeln. Für Planungszwecke kann ein einzelner ACS-Collector bis zu 150 Domänencontroller, 3000 Mitgliedsserver oder 20.000 Arbeitsstationen basierend auf standardmäßigen Überwachungsrichtlinieneinstellungen unterstützen. In einem getesteten, realen Szenario zeigten 150 Domänencontroller ein Maximum von ungefähr 140 Ereignissen pro Sekunde mit einem Spitzenwertdurchschnitt von 500.000 Ereignissen pro Stunde an. In nur 14 Tagen (die ACS-Standardeinstellung für die Aufbewahrung) wurden 150 GB Sicherheitsereignisdaten in der SQL Server-Datenbank gespeichert. Mit einer aggressiveren Überwachungsrichtlinie und der entsprechenden SACL-Konfiguration würden offensichtlich noch mehr Daten (pro Stunde, pro Tag und insgesamt) generiert.
Bei diesem Datenvolumen sollten Sie sich vor Augen führen, dass niemand alle Ereignisse in einer typischen großen Unternehmensumgebung überprüfen könnte. Umgekehrt sollten Organisationen vor den hier aufgeführten Zahlen nicht zurückschrecken. Um die in Ihrer Umgebung eintretenden Änderungen zu verstehen, ist die Analyse großer Datenmengen erforderlich.
Genau hier spielt ASC seine ganze Stärke aus. Mithilfe von SQL Server Reporting Services und ACS können Sie Probleme, die normalerweise innerhalb des Sicherheitsereignisprotokolls verborgen sind, in Informationen verwandeln, die sich so einfach identifizieren lassen wie die farbcodierten Ereignisse im Anwendungsereignisprotokoll. ACS verfügt über einen Satz Standardberichte, die Sie einfach auf die bestimmten Anforderungen Ihrer Umgebung erweitern können.
Ziehen Sie das folgende Szenario in Betracht: Aufgrund der Vertraulichkeit externer Vertrauensstellungen in der Umgebung fordert Ihre Geschäftsleitung die Entwicklung eines Berichts, in dem die Erstellung von Active Directory-Vertrauensstellungen im Einzelnen aufgeführt wird. Nach einigen Untersuchungen wissen Sie, dass ein trustedDomain-Objekt im Container „cn = System“ innerhalb des spezifischen Domänennamenskontexts in Active Directory erstellt wird, wenn eine Vertrauensstellung erstellt wird. Nach dem Bearbeiten der SACL in diesem Container zur Überwachung der erfolgreichen Erstellung beliebiger vertrauenswürdiger Domänenobjekte können Sie bei jeder Erstellung eines Objekts dieses Typs Sicherheitsereignisse aufzeichnen. Dies wird in einem Ereignis mit der Ereignis-ID 566 im Sicherheitsereignisprotokoll auf dem DC gerendert, auf dem die Vertrauensstellung erstellt wurde. Sie können nun eine einfache SQL-Abfrage schreiben, um diese Informationen aus ACS abzurufen:
select * from AdtServer.dvAll
where EventID = '566' and
String05 like '%trustedDomain%'
order by CreationTime desc
Um diese Informationen in Berichtsform darzustellen, verwenden Sie die Version von Visual Studio® 2005, die in SQL Server 2005 Reporting Services enthalten ist, da dieses Programm speziell zur Berichtentwicklung dient. Nach Abschließen des Assistenten lassen sich Berichte, die dem Beispiel in Abbildung 8 ähneln, leicht erstellen. Zudem können Änderungen in der Umgebung, die sich im Sicherheitsereignisprotokoll darstellen lassen, in einem ähnlich anschaulichen Bericht zusammengefasst werden.
Abbildung 8 Beispiel eines ACS-Berichts
Abbildung 8 Beispiel eines ACS-Berichts

Entwickeln eines Überwachungsplans
Wie können IT-Administratoren jetzt, da die Herausforderungen sowie die gesetzlichen und technischen Aspekte der Überwachung verständlich sind, einen „Überwachungsplan“ für ihre Organisation entwickeln? Wie die meisten Aufgaben ist die Entwicklung einer umfassenden Überwachungsrichtlinie ein aus mehreren Schritten bestehender Prozess. Beim ersten Schritt wird festgelegt, was überwacht werden sollte. Dazu muss Ihre Umgebung analysiert und festgelegt werden, welche Arten von Ereignissen und Änderungen Überwachungen generieren sollen. Dies könnte einfache Elemente wie Kontosperrungen, vertrauliche Gruppenänderungen und Erstellen von Vertrauensstellungen umfassen, oder auch komplexe Änderungen, etwa Änderungen von Konfigurationselementen innerhalb von Anwendungen in Ihrer Umgebung. Wichtig ist, dass die Geschäftsleitung beim Festlegen des „Was“ in einem Überwachungsplan beteiligt wird. Dieser Schritt muss auf Papier durchgeführt werden und sollte in regelmäßigen Abständen und nicht nur nach bedeutenden Vorfällen wiederholt werden.
Beim zweiten Schritt muss identifiziert werden, wie Überwachungsinformationen für bestimmte Änderungen in Form von Sicherheitsereignissen zurückgegeben werden sollen. Überwachungsinformationen sind bisweilen relativ unverständlich und schwer lesbar. Vor der Implementierung müssen Korrelationen zwischen Sicherheitsereignissen und verschiedenen Aktionen hergestellt werden, um zu verstehen, was die Sicherheitsereignisse wirklich bedeuten. Die Zeit nach einem Vorfall ist nicht der richtige Zeitpunkt, um die Beziehungen zwischen Ereignissen und Aktionen zu ergründen.
Der dritte Schritt ist die technische Umsetzung, wenn Sie die Überwachungsrichtlinie und die SACLs implementieren. Wie bereits erörtert, müssen Überwachungsrichtlinieneinstellungen (zum Aktivieren der Generierung von Sicherheitsereignissen) und SACLs (zum Generieren von Überwachungsprotokollen für zugeordnete Aktionen) im Verzeichnis, Dateisystem und in der Registrierung definiert werden, um ein vollständiges Bild der Änderungen in diesen Bereichen zu erhalten.
Damit gelangen Sie zum vierten und letzten Schritt: Sammlung, Auslöser und Analyse. Abhängig von der Größe und den Anforderungen Ihrer Organisation können diese mit den systemeigenen Windows Server 2008-Funktionen oder mit erweiterten Lösungen wie beispielsweise der Überwachungssammeldienst-Funktion von System Center Operations Manager abgedeckt werden. Ein häufiger Fehler in den meisten Organisationen besteht darin, nur eine Überwachungsrichtlinie festzulegen, ohne SACLs zu definieren. Beim letzten Schritt geht es um das Implementieren einer Technologielösung für das Melden und Vermitteln von Daten an die Beteiligten in Ihrer Organisation. Wie bereits erwähnt, gibt es in den meisten Organisationen eine für die Sicherheit verantwortliche Entität, sodass ein Überwachungsplan im Hinblick auf vorhandene Organisationselemente strukturiert sein muss, um wirksam zu sein. Wichtig bei diesem letzten Schritt ist das Sammeln und sinnvolle Darstellen von Informationen für alle Personen, zu deren Aufgaben das Verstehen von Änderungen in der Umgebung gehört.
In den meisten IT-Organisationen muss es erst zu einem bedeutenden Ereignis kommen, bevor sie nicht nur über einen umfassenden Überwachungsplan nachdenken, sondern einen solchen tatsächlich umsetzen. Windows Server 2008 bietet im Vergleich zu früheren Plattformen verbesserte Methoden zum Sammeln und Analysieren von Sicherheitsereignisdaten. Erweiterte Sammlungs- und Berichttechnologien wie ACS enthüllen Probleme, die früher aufgrund des Ereignisumfangs und der Verteilung verborgen waren, und stellen diese Änderungen sofort offensichtlich dar.
Wie bei den meisten IT-Problemen besteht die primäre Herausforderung im Prozess. Zusätzliche Konfiguration und Analyse ist immer erforderlich, um genau das aufzuzeichnen, was Ihre IT-Manager von Ihnen erwarten. Wenn Sie die Anforderungen Ihrer Umgebung und die Funktionen der Windows-Plattform wirklich verstehen, werden Sie kein Problem haben, diese Herausforderung anzunehmen. Viel Erfolg.

Rob Campbell und Joel Yoker Rob Campbell ist Senior Technical Specialist und Joel Yoker ist Senior Consultant im Microsoft Federal Team. Rob Campbell und Joel Yoker befassen sich hauptsächlich mit der Entwicklung und Bereitstellung von Sicherheitslösungen für die Bundesregierung der USA.


 Mitteilung der Redaktion: Willkommen bei Windows&#160;Server&#160;2008
Mitteilung der Redaktion
Willkommen bei Windows Server 2008

Produktstarts gehören schon fast zum Alltag. Bei einem Portfolio von Hunderten von Produkten (oder gar Tausenden bei Einbeziehung des Webs) ruft der Gedanke an einen weiteren Produktstart keine besondere Aufregung hervor. Diesmal verhält es sich jedoch anders.
Microsoft startet in diesem Februar Windows Server 2008, und wir könnten nicht aufgeregter sein. Es besteht kein Zweifel daran, dass diese Veröffentlichung lange auf sich warten ließ. Sie werden aber sehen, dass sich die lange Wartezeit gelohnt hat. Die Anzahl bedeutender Verbesserungen und die zahlreichen neuen Funktionen sind einfach überwältigend. Wir könnten über IIS 7.0 sprechen (und das wird getan) oder über den Netzwerkzugriffsschutz (und auch das tun wir). Wir könnten Server-Manager oder neue Bereitstellungsverfahren oder neue Kompatibilitätsfeatures besprechen (das tun wir ebenfalls). Diese Liste könnten wir eine Weile weiterführen, aber was mich ehrlich gesagt am meisten an dieser neuen Veröffentlichung beeindruckt, ist der Aufwand, der zur Verbesserung der Verwaltbarkeit von Windows Server betrieben wurde.
Wir denken viel darüber nach, was wir tun können, um IT-Experten das Leben leichter zu machen. Deshalb freuen wir uns, dass im Mittelpunkt dieses Produkts die Unterstützung von IT-Experten in ihrem Job steht. Als Beispiel wird die neue Ereignisinfrastruktur in Windows Server 2008 herangezogen, die Rob Campbell und Joel Yoker in dieser Ausgabe besprechen. Ereignisfunktionalität sorgt selbst bei den größten Computerfreaks nicht mehr für so viel Aufregung, aber diese Veröffentlichung ist einfach unglaublich beeindruckend. Dafür sorgt die Fülle an Features wie XML-Daten, benutzerdefinierte Ansichten, ausführlichere Beschreibungen usw.
Diese Veröffentlichung enthält so viele wichtige Verbesserungen, mit denen wir unsere Arbeit optimieren können, dass wirklich jede Aufregung gerechtfertigt ist. Verbesserungen an Active Directory, IIS, Netzwerkfunktionalität, Sicherheit, Virtualisierung und mehr machen diesen Produktstart zu einem der wichtigsten Produktstarts unserer Geschichte. Aus diesem Grund konzentrieren wir uns in dieser Ausgabe auf die für Sie wichtigsten Informationen zu Windows Server 2008.
Wir freuen uns besonders, Mark Russinovich, Technical Fellow in der Platforms and Services Division und Ersteller der beliebten Sysinternals-Tools, wieder willkommen heißen zu können. Aus Mark Russinovichs Feder stammt ein Teil der gefragtesten Inhalte der TechNet Magazin-Geschichte, insbesondere seine Reihe „Einblick in den Windows Vista-Kernel“ (in den Ausgaben vom Februar, März und April 2007). Er lässt diese Reihe in diesem Monat wieder aufleben und bietet eine technische Betrachtung der Änderungen am Kernel von Windows Server 2008. Viel Spaß!
– Joshua Hoffman

Unser Dank gilt folgenden technischen Experten von Microsoft: Brandon Baker, Mai-lan Tomsen Bukovec, Bryce Cogswell, Nils Dussart, Gregoire Guetat, Brett Hill, Gaby Kaplan, Jason Leznek, Paul Mayfield, Nathan Muggli, Meg Muran, Michael Murgolo, Michael Niehaus, Raja Perumal, David Solomon, Eric Traut, Jim Truher und Landy Wang.


 Briefe: Leser sagen ihre Meinung
Briefe
Leser sagen ihre Meinung

Windows Vista Complete PC-Sicherung
Vielen Dank für Ihren großartigen Artikel im September 2007 zur Windows Vista® Complete PC-Sicherung („Windows Vista-Sicherungstechnologien“, technetmagazine.com/issues/2007/09/Backup). Leider kann ich die Anleitungen nicht ausprobieren, da ich aufgefordert werde, das Sicherungsabbild auf meiner externen Festplatte zu speichern (was ich auch gern tun würde). Ich erhalte jedoch nicht die Möglichkeit, auf der externen Festplatte einen bestimmten Ordner für das Ablegen der Datei anzugeben, weshalb ich fürchte, dass durch die Speicherung alle anderen, bereits auf dem Laufwerk befindlichen Dateien überschrieben werden. Ist meine Sorge berechtigt?
– Ben B.

Wir haben Ihre Frage an die Autorin, Christine Fok, weitergeleitet. In ihrer Antwort heißt es, dass die Complete PC-Sicherung auf dem Ziellaufwerk einen Ordner zum Speichern des Abbilds erstellt. Deshalb müssen Sie sich also keine Sorgen machen, dass Ihre Daten überschrieben werden.

Falscher Registrierungsschlüsselverweis
Der Artikel vom Dezember 2007 „Aufspüren schwer fassbarer Netzwerkprobleme“ (technetmagazine.com/issues/2007/12/Network) enthält einen kleinen Fehler beim Verweis auf einen Registrierungsschlüssel zum Anpassen des TCP/IP-Stapels in Windows®. Auf Seite 70 erwähnt der Autor, Christopher Stoneff, dass Werte im Schlüssel „HKLM\System\CurrentControlSet\Services\TCPIP“ angepasst werden können. Der richtige Schlüssel lautet aber „HKLM\System\CurrentControlSet\Services\TCPIP\Parameters“ („Parameters“ fehlte).
– Ingmar K.

Christopher Stoneff hat die Richtigkeit Ihrer Mitteilung bestätigt. Der Schlüssel enthält am Ende „\Parameters“. Wir entschuldigen uns dafür, dass dieser erforderliche Teil des Registrierungspfads vergessen wurde. Wir haben dies in der Onlineversion des Artikels korrigiert.

Verschlüsseln von Dateien
Ich möchte gern mehr über das verschlüsselnde Dateisystem (Encrypting File System, EFS) lernen und habe im März 2007 in Ihrer Rubrik „Sicherheit auf dem Prüfstand“ den Artikel „Bereitstellen von EFS: Teil 2“ gelesen. (technetmagazine.com/issues/2007/03/SecurityWatch). Ich habe eine Domänenumgebung, und einige Benutzer verschlüsseln bereits einige Dateien. Anschließend habe ich eine Zertifizierungsstelle (certificate authority, CA) und EFS-Vorlagen eingeführt. Ich habe folgende Frage: Wenn die Benutzer, die bereits Dateien mit ihren eigenen selbstsignierten Zertifikaten verschlüsselt haben, neue Dateien verschlüsseln müssen, sollten sie dafür das alte selbstsignierte Zertifikat verwenden oder ein neues Zertifikat von meiner Zertifizierungsstelle anfordern? Zusätzlich würde ich gern wissen, wo die privaten Schlüssel der Benutzer gespeichert werden, wenn alle Benutzer servergespeicherte Profile haben?
– Ammar H.

John Morello, der den Artikel zum Bereitstellen von EFS geschrieben hat, schreibt in seiner Antwort:
Sobald die Benutzer das neue EFS-Zertifikat angefordert haben, verwenden sie es für neue Vorgänge. Alle existierenden verschlüsselten Dateien werden jedoch mit dem alten Schlüsselpaar verschlüsselt bleiben, bis sie aktualisiert werden. Folglich können Sie nach der Registrierung der Benutzer „cipher /u“ ausführen und dadurch alle diese Dateien mit dem neuen Schlüsselpaar aktualisieren.
Wenn servergespeicherte Profile verwendet werden, wird für die Schlüsselpaare in den Profilen ein Roaming durchgeführt. Ich empfehle stattdessen die Verwendung von „Serverspeicherung von Anmeldeinformationen“, die einfacher als das Verwenden servergespeicherter Profile ist. Hier finden Sie weitere Informationen: go.microsoft.com/fwlink/?LinkId=107469.

Missverständlicher regulärer Ausdruck
Ich beziehe mich in der Ausgabe vom Januar 2008 auf den Artikel „Reguläre Ausdrücke sind unmissverständlich“ (technetmagazine.com/issues/2008/01/HeyScriptingGuy) der Rubrik „Hey, Scripting Guy!“. Möglicherweise hat sich in das Beispiel
objRegEx.Pattern = "[^A-Z][^a-z]"
ein Fehler eingeschlichen. Es sollten, alle Zeichen gefunden werden, die nicht Kleinbuchstaben oder Großbuchstaben waren. Dieses Muster ist jedoch für Großbuchstaben, auf den ein Kleinbuchstabe folgt. Es funktioniert z. B. nicht mit einer Zeichenfolge wie „aBcde“. Vielleicht sollte hier stattdessen Folgendes stehen:
objRegEx.Pattern = "[^A-Z^a-z]"
– Roger R.

Wir haben Ihre Frage an die Scripting Guys weitergeleitet, und hier ist ihre Antwort:
Lieber Roger, vielen Dank für diesen Hinweis. Es sieht so aus, als hätten wir an dem Artikel eine Änderung vorgenommen und sie nicht einheitlich umgesetzt. Im ursprünglichen Entwurf (der sich immer noch auf meinem Computer befindet) hieß es, dass ein Großbuchstabe, gefolgt von einem Kleinbuchstaben gefunden werden sollte. Wir müssen uns im Nachhinein entschieden haben, dass dies nicht so nützlich wie das Suchen von Zeichen war, die keine Buchstaben waren. Anschließend haben wir den Text geändert und versäumt, den Beispielcode entsprechend anzupassen. Wir werden dies in der Onlineversion korrigieren. Entschuldigung für die Unannehmlichkeit.


 Toolbox: Neue Produkte f&#252;r IT-Experten
Toolbox
Neue Produkte für IT-Experten
Greg Steen

Verwalten von SQL-Datenbanken
SQL Sentry Event Manager
sqlsentry.net/event-manager/standard-sql-server.asp
Je größer und komplexer Ihre Infrastruktur, desto mehr müssen Sie darüber in Sorge sein, dass Wartungs- und Betriebsaufgaben einander beeinträchtigen. Dies kann für Ihre Endbenutzer zu einem Chaos im Prozessfluss führen. Glücklicherweise gibt es einige Tools für den Datenbank- und Systemadministrator, die beim Koordinieren der Zeitpläne einer komplexen Umgebung helfen.
Ein solches Tool, das Sie u. U. für Ihre Serverumgebung mit mehreren Datenbanken in Betracht ziehen sollten, ist SQL Sentry Event Manager, eine Microsoft® .NET Framework-Serveranwendung, die am Back-End eine Instanz von SQL Server® 2000 oder SQL Server 2005 verwendet. Sie stellen über die Benutzeroberfläche der SQL Sentry Console eine Verbindung zu der Serveranwendung her, die Ihnen eine Gesamtansicht der verwalteten Server in Ihrer Umgebung bietet. Die Serveranwendung hat keine Agents, doch das impliziert wie gewöhnlich, dass sie im Kontext eines Benutzers ausgeführt werden muss, der über die Berechtigungen verfügt, Verbindungen zu den Computern und Diensten herzustellen, die Sie verwalten möchten.
Eines der am stärksten beworbenen Features der Anwendung besteht darin, dass die Benutzeroberfläche der Konsole Ihnen die Möglichkeit gibt, Ihre Serveraufgaben mithilfe von Drag und Drop neu zu planen. Dadurch können Wartungs- und Betriebsaktivitäten aufeinander abgestimmt werden, um Konflikte und Ausfallzeiten zu vermeiden. Die Benutzeroberfläche mag zunächst ein wenig kompliziert erscheinen, aber Sie können damit schnell potenzielle Probleme aufdecken und ein Zeitfenster finden, in das Sie eine in Konflikt stehende Aufgabe verschieben können. Sie bietet sogar eine Microsoft Outlook®-ähnliche Ansicht Ihrer SQL-Agentaufträge und der mit Windows® geplanten Aufgaben für die Server an, die Sie für die Überwachung ausgewählt haben. In der Kalenderansicht werden lang andauernde und fehlgeschlagene Aufgaben hervorgehoben, damit Sie nebenbei Probleme aufspüren und lösen können.
Zusätzlich zur Planungsfunktion verfügt SQL Sentry auch über ein stabiles Benachrichtigungssystem, das den Bedarf an SQL Mail, MAPI, xp_sendmail oder sp_send_dbmail ersetzt. Es leitet auch Ihre gesamten Ereignisbenachrichtigungen von verwalteten Servern durch sein Subsystem weiter. Dadurch erhalten Sie zentralisierte Kontrolle über die Art, Häufigkeit und Verteilung dieser Benachrichtigungen.
Benachrichtigungen können auf globaler Ebene, auf Server-, Aufgaben- oder Auftragsebene konfiguriert werden. Dabei wird die Genauigkeit angeboten, die die meisten Administratoren für diesen Ereignistyp erwarten. Sie können eine Reihe verschiedener Ereignisbedingungen einrichten, um eine Benachrichtigung auszulösen: z. B. wenn ein Auftrag zu lange oder nicht lange genug dauert, bis er abgeschlossen ist; wenn ein Leistungsindikator wie die CPU-Auslastung einen bestimmten Schwellenwert erreicht; oder wenn ein SQL-Agentauftrag aus irgendeinem Grund blockiert wird. Sie können SQL Sentry auch dafür konfigurieren, Sie zu benachrichtigen, wenn die Konfiguration geändert wird. Daran können Sie erkennen, wenn jemand einen Zeitplan anpasst, eine Überwachung anhält und so weiter.
Doch SQL Sentry verarbeitet mehr als nur SQL-Agentaufträge und Ereignisse der Windows-Aufgabenplanung. Die Anwendung unterstützt auch Ereignisse von Wartungsplänen, DTS-Paketen, SSIS-Aufgaben und dem SQL-Agentprotokoll.
Die da oben sehen in der Regel gern, wie gut Systeme funktionieren. Wenn Sie eine Betriebszeitquote haben, auf die Sie stolz sein können, möchten Sie das wahrscheinlich auch zeigen. SQL Sentry verfügt über eine Reihe integrierter Berichterstattungsoptionen für eben solche Aufgaben. Damit können Sie statistische Diagramme über Laufzeit und Leistung erstellen und drucken. Sie können die Berichtsdaten auch in XML, CSV oder HTML exportieren, um sie in Ihre eigenen Berichterstattungsdokumente und -tools einzubeziehen.
Beachten Sie, dass die Professional Edition außerdem über die Möglichkeit verfügt, Oracle-Server zu verwalten, außerdem über Features wie die Überwachung von Berichterstattungsdiensten, Einreihung von SQL-Agentaufträgen in Warteschlangen, Verkettung von Nicht-SQL Server-Ereignissen und das Eintragen gemeinsam genutzter Ressourcen in den Kalender.

Preis: Standard Edition ab 395 $.
Planen der Wartung mit SQL Sentry
Planen der Wartung mit SQL Sentry

Remoteverwaltung von Systemen
Mobile Admin
rovemobile.com/products/ma/features
Da Sie nicht an mehr als einem Ort gleichzeitig sein können, ist ein mobiles Remoteserververwaltungstool eine gute Idee für den überlasteten IT-Experten. Eines, das Sie sich ansehen sollten, ist Mobile Admin von Rove Mobile (ehemals Idokorro Mobile).
Mobile Admin ist ein Client-Server-Setup, bei dem ein Kommunikationsserver (der Zugriff auf die Server hat, die Sie verwalten möchten) mit einem Satz drahtloser, tragbarer Geräte interagiert. Der Serveranteil der Anwendung hat keine Agents. Das bedeutet, dass Sie auf den Servern, die Sie verwalten möchten, nichts installieren müssen. Sie müssen diesem Computer- und Anwendungskontext jedoch die entsprechenden Remoteverwaltungsrechte gewähren, damit Sie die Computer in Ihrer Infrastruktur verwalten können.
Auf den Server kann mit den meisten wichtigen mobilen Plattformen zugegriffen werden, einschließlich Windows Mobile®-Pocket PCs und -Smartphones sowie BlackBerry-Smartphones. Außerdem kann mit jedem beliebigen Computer, der über eine Internetverbindung und einen kompatiblen Browser verfügt, eine Verbindung zu Mobile Admin hergestellt werden (vorausgesetzt, Ihre Sicherheitsrichtlinie lässt dies zu).
Eine der vornehmlichsten Sorgen, die jeder System- oder Netzwerkexperte mit mobilen Verwaltungen hat, ist die Sicherheit. Jene unter Ihnen, die BlackBerry Enterprise Server bereitgestellt haben, können jegliche Kommunikation mit TDES (Triple Data Encryption Standard, Dreifach-DES) oder AES (Advanced Encryption Standard, erweiterter Verschlüsselungsstandard) verschlüsseln, die beide mit FIPS (Federal Information Processing Standard) kompatibel sind.
Mobile Admin erweitert auch die „Kill“-Funktionalität für ein verlorengegangenes BlackBerry-Gerät, indem Software und Daten von einem Remotestandort aus vom Telefon entfernt werden. Bei anderen tragbaren Geräten können Sie ein VPN implementieren, um Ihre Kommunikation zu sichern, und/oder Mobile Admin dafür konfigurieren, eine Windows-Anmeldung, LDAP, RSA SecurID, RADIUS-Authentifizierung oder eine Mobile Admin-spezifische Anmeldung zu verwenden.
Sobald Sie eine Verbindung hergestellt haben, können Sie Windows-Verwaltungsaufgaben durchführen wie das Anzeigen und Löschen von Ereignisprotokollen, das Neustarten von Computern, das Verwalten von Dateien und Verzeichnissen sowie das Anzeigen und Bearbeiten geplanter Aufgaben.
In Bezug auf die Active Directory®-Integration können Sie Benutzer, Gruppen und Computer anzeigen, erstellen, bearbeiten, deaktivieren oder löschen. In der Exchange-Verwaltung können Sie indessen die Einstellungen für Postfächer ändern, Nachrichtenwarteschlangen fixieren und die Fixierung wieder aufheben und mehr.
Mit IIS können Sie Anwendungspools oder Websites neu starten und die Einstellungen virtueller Verzeichnisse ändern. Für Ihre Server mit SQL Server können Sie T-SQL-Abfragen ausführen, Anmeldungen ändern und SQL-Agentaufträge starten und anhalten. Wenn Sie Clusterdienste ausführen, können Sie Gruppen verschieben, Ressourcen offline nehmen und zwischen anderen geläufigen Verwaltungsaufgaben ein Failover durchführen.
Außerdem bietet Mobile Admin auch Unterstützung zum Verwalten von Aspekten von Oracle, Novell LDAP, Lotus Domino, Citrix, HP iLO, Backup Exec und mehr.

Preis: Ab 245 $ pro Server.

Buchbesprechung
Mastering Windows Network Forensics and Investigation
sybex.com
Möglicherweise verfügen Sie über die Hardware und die Verfahren, um Bedrohungen für Ihre Netzwerke zu erkennen und zu verringern. Doch kennen Sie die Verfahren, oder verfügen Sie über die Protokolle, die Sie für die Untersuchung und vielleicht sogar strafrechtliche Verfolgung der Täter benötigen, nachdem ein sicherheitsrelevantes Ereignis stattgefunden hat?
Hier kommt das Buch „Mastering Windows Network Forensics and Investigation“ (Sybex, 2007) ins Spiel. Es lehrt Sie die Fähigkeiten, Eingriffe in Windows-Netzwerke vollständig zu untersuchen, von kleinen Vorfällen mit einzelnen Computern (z. B. unangemessene Verwendung von Unternehmensdiensten) bis hin zu größeren und weiter verbreiteten Angriffen gegen wichtige Systeme.
Das Buch leitet Sie durch den Prozess des Sammelns von Beweisen und deckt dabei alles ab: von der Durchführung von Befragungen bis hin zur Nachverfolgung kontrollierter Ereignisse und Protokolle. Es wird erörtert, wo und wie Sie Beweise von Windows-Computern und -Netzwerken sammeln können, indem Sie Tools wie WireShark, LogParser, EnCase und das Sysinternals-Toolset verwenden.
Außerdem wird in dem Buch auf die Informationen eingegangen, die Sie aus der Registrierung, der Dateisystemstruktur und deren Inhalten, aus textbasierten Protokollen, aus Ereignisprotokollen und aus Prozessen auf den in Frage kommenden Computern erhalten können. Des Weiteren erfahren Sie, wie Sie eine Liveanalyse-CD mit den Tools erstellen, die Sie zum Aufspüren der erforderlichen Beweise benötigen. Außerdem wird in dem Buch erläutert, wie Sie die Ergebnisse Ihrer Untersuchung präsentieren können. Dabei werden Richtlinien und Verfahren für die Aussage vor Gericht genau geschildert.

Preis: $59.99.

Sammeln von Systemdaten
MetaLAN
hammer-software.com/metalan.shtml
Zentralisierte Verwaltung ist eine der Hauptkomponenten für die erfolgreiche Systemverwaltung. Es erspart viel Gerenne und spart Ihnen wertvolle Zeit. Dadurch wird der Stress verringert, unter dem Sie bei der Arbeit stehen.
MetaLAN von Hammer Software ist ein Tool, mit dem Sie Benutzer und Server in Ihrem Windows-Netzwerk verwalten und unterstützen können. Diese Anwendung ohne Agent ermöglicht Ihnen, schnell Informationen bezüglich Ihrer Windows-Computer zu sammeln, Änderungen an deren Konfiguration vorzunehmen und die Rechner ganz allgemein zu verwalten. Dies erfordert selbstverständlich den notwendigen Benutzerkontext und entsprechende Berechtigungen.
MetaLAN hat zwei Betriebsmodi. Sie können die Anwendung entweder direkt im Administratormodus ausführen (der eine Verbindung zu den Computern herstellt, nach denen Sie sich erkundigen oder deren Eigenschaften Sie ändern möchten), oder Sie können den kostenlosen Add-On-Agent/-Dienst namens „ProbeServer“ auf dem Remotecomputer verwenden, zusammen mit MetaLAN im Servermodus, um Ihre Arbeitsstationen ununterbrochen zu überwachen.
Wenn Sie die Anwendung starten, gelangen Sie zur Benutzeroberfläche des MetaLAN Control Panel, mit dem Sie die Möglichkeit haben, Ihr aktuelles Netzwerk auf zu verwaltende Domänen zu sondieren. Hier können Sie auch die verschiedenen Toolkomponenten wie das Help Desk Tool, das Report Tool, das Software Tool und das RegCast Tool starten.
Das Help Desk Tool bietet Ihnen eine Ansicht zum Suchen und Durchsuchen der Computer in der Domäne, die Sie verwalten. Wenn Sie einen Computer auswählen, wird ein ganzes Paket nützlicher Informationen zu diesem Computer angezeigt, einschließlich Hersteller, IP-Adressen, Prozessoren, Laufwerken, MAC-Adressen und Serverrollen. Von hier aus können Sie WMI-Abfragen (Windows Management Instrumentation, Windows-Verwaltungsinstrumentation) ausführen, eine Verbindung zu Echtzeit-Systemmonitoren herstellen, installierte Software anzeigen und weitere nützliche Verwaltungsaufgaben durchführen.
Das Report Tool gibt Ihnen schnelle, exportierbare und anschauliche Ansichten von Ihren verwalteten Knoten. Zum Beispiel können Sie ein Kreisdiagramm der CPU-Geschwindigkeiten aller Computer in Ihrem Netzwerk erstellen oder überprüfen, auf welchen Computern Windows XP Service Pack 2 installiert ist.
Mit dem Software Tool können Sie schnell Listen der Software anzeigen und exportieren, die auf einer Gruppe von Computern in Ihrem Netzwerk installiert ist. Dies ist ein großartiges Tool für Überwachungen.
Mit dem RegCast Tool können Sie Registrierungsinformationen auf Remotecomputern in einer ausgewählten Gruppe von Computern anzeigen (und ändern, wenn Sie Domänen- oder Unternehmensadministrator sind).
MetaLAN enthält auch ein Tool zum Bereitstellen und Installieren von MSI-Paketen (Microsoft Installer) von einem Remotestandort aus (wenn sie automatische Installation unterstützen); eine Speicherübersicht, in der Ihnen jedes Laufwerk auf Ihren Computern und der verfügbare Speicherplatz angezeigt wird; und ein Service Admin Tool, mit dem Sie Dienste starten, anhalten und sogar entfernen können. Als ob das nicht genug wäre, gibt es sogar ein tolles VNC-Tool (Virtual Network Computing) für die Remotesteuerung, das eine kleine ausführbare VNC-Datei bereitstellt, die Ihnen, wenn sie ausgeführt wird, Remotesteuerung über einen Computer gewährt (ähnlich wie bei Remoteunterstützung).

Preis: Ab 75 $ für ein Lizenzpaket für 20 Knoten.
Help Desk Tool bietet eine Ansicht zum Suchen und Durchsuchen
Help Desk Tool bietet eine Ansicht zum Suchen und Durchsuchen

Automatisieren von Aufgaben
AutoHotkey
autohotkey.com
Automatisierung kann der beste Freund eines IT-Experten sein, da sie ihm hilft, die zeitaufwändigen, sich wiederholenden Aufgaben zu vermeiden. Zu den vielen Tools dort draußen, die uns in dieser Hinsicht helfen, gehört das Dienstprogramm „AutoHotkey“. Dieses kostenlose Open-Source-Tool hilft bei der Optimierung von Desktoproutinen, indem nahezu jede Aufgabe optimiert wird, die eine Eingabe über Tastatur, Maus oder gar Joystick erfordert. Es ist ein äußerst leistungsfähiges skriptbasiertes Hotkey- und Makrotool.
AutoHotkey wird in Ihrer Taskleiste ausgeführt und führt beim Start die von Ihnen erstellte Skriptdefinition aus. Das Programm führt einzelne Skriptbefehle aus, wie sie in der Skriptdatei erscheinen. Dies eignet sich hervorragend zum Starten Ihres bevorzugten Satzes an Anwendungen beim Hochfahren. Doch warten Sie, es gibt noch mehr: Sie können auch eine beliebige Anzahl an Hotkeys und Hotstrings definieren.
Hotkeys sind beliebige Tastenkombinationen, die Sie definieren, um eine Aktion auszulösen: z. B. um eine Anwendung zu starten, um Fenster in den Vordergrund zu bringen oder sogar um einen Bildlauf mithilfe des Mausrads zu simulieren.
Hotstrings hingegen sind Textabkürzungen für häufig eingegebene Befehle oder Wendungen. Außerdem können mit diesen Hotstrings Skriptaktionen gestartet werden, ähnlich wie bei einem Hotkey. Sie können z. B. einen Hotstring mit der einfachen Tastenkombination „hd“ erstellen, mit dem Microsoft Word geöffnet und das heutige Datum im gewünschten Format geschrieben wird. Oder wenn es eine bestimmte Antwort gibt, die Sie immer wieder an Ihre Benutzer zu senden scheinen, können Sie einen einfachen Hotstring erstellen, mit dem dieser Absatz automatisch in eine neue Outlook-Nachricht eingefügt wird.
Die Skriptsprache selbst unterstützt Variable, Ausdrücke für mathematische Operationen und Stringoperationen, integrierte globale Variable, Funktionen, Schleifen und bedingte Anweisungen. Sie sollten also ein Skript erstellen können, das Ihren Anforderungen an die Systemverwaltung entspricht. Insgesamt gibt es weit mehr als 100 Befehle und Sprachkonstrukte, die Ihnen weiterhelfen. Sie können z. B. ein Ziehen mit der Maus simulieren, Meldungsfelder anzeigen, asynchrone Vorgänge ausführen, E-Mail-Nachrichten senden, die Registrierung ändern, Zeitgeber innerhalb von Schleifen mit wiederkehrenden Überprüfungen festlegen, Anwendungen öffnen, Fenster schließen und Prozesse beenden, um nur einiges zu nennen.
Ein weiteres tolles Feature von AutoHotkey besteht darin, dass Sie Ihre Skripts für die Wiederverwendung und Verteilung kompilieren können, sobald Sie sie auf Ihre Bedürfnisse zugeschnitten haben. Auf diese Weise können Benutzer, die AutoHotkey nicht installiert haben, dennoch Ihre Tastenkombinationen und Skripts nutzen. Aufgrund der Lizenz des Open-Source-Projekts können Sie sie ohne Einschränkungen verteilen oder verkaufen.
In Ihrer internen Organisation können Sie problemlos ein ausführbares Skript an Ihre Endbenutzer verteilen, das einen Satz von Anpassungen durchführt, die Sie sonst manuell direkt an deren Desktops durchführen müssten. Weiterhin akzeptiert AutoHotkey auch Befehlszeilenschalter und -parameter, wenn Sie die Skripts auf jeden Benutzer zuschneiden müssen. Sie bekommen also wirklich etwas, das in Ihrer gesamten Domäne sowohl nützlich als auch wiederverwendbar ist.
Im Unterschied zu vielen Open-Source-Projekten, die oft nicht über ausführliche Dokumentation verfügen, ist die Dokumentation von AutoHotkey umfassend und gut strukturiert. Dort finden Sie anhand vieler guter und nützlicher Beispiele, was Sie wissen müssen, um Skripts für Ihre Automatisierungsaufgaben zu erstellen. Auf der Projektwebsite finden Sie außerdem ein aktives Benutzerforum, das bei Fragen weiterhilft, sowie ein Wiki, das Skripts, Lernprogramme und eine Befehlsübersicht enthält. Es gibt auch eine Showcaseseite für Skripts, die einen guten Satz brauchbarer Beispiele bietet, die von Benutzern bereitgestellt wurden.

Preis: Kostenlos.
AutoHotKey kann Skripts zur Wiederverwendung und Verteilung kompilieren
AutoHotKey kann Skripts zur Wiederverwendung und Verteilung kompilieren

Greg Steen ist Technologieexperte, Unternehmer und Enthusiast. Er ist immer auf der Suche nach neuen Tools, um IT-Experten die Betriebs-, Qualitätssicherungs- und Entwicklungsprozesse zu erleichtern.


 Schwerpunkt Dienstprogramme: Windows&#160;Server-Logozertifizierung
Schwerpunkt Dienstprogramme
Windows Server-Logozertifizierung
Venkat Krishnamachari
Laden Sie den Code für diesen Artikel herunter: Works with Windows Server 2008 (KB)

Ziel von Microsoft ist es, mit der Windows Server® 2008-Softwarezertifizierung Entwicklern bei der Anwendung bewährter Methoden zu helfen und IT-Experten zu ermöglichen, Anwendungen vor dem Erwerb zu evaluieren und so Zeit zu sparen und Ärger zu vermeiden. Microsoft hat das Programm „Works with Windows Server 2008“ entwickelt, um Kunden beim Beurteilen der Anwendungskompatibilität zu helfen. Es enthält kostenlose Testtools, die Ihnen dabei helfen sicherzustellen, dass Anwendungen eine verlässliche Funktionalität bieten.
Das „Works with“-Tool sammelt Daten über die Auswirkungen der Anwendung auf das Betriebssystem während ihres Lebenszyklus, indem der Status des Dateisystems, die Registrierung, Dienste und Treiber überwacht werden. Anschließend analysiert das Tool diese Daten und erstellt Berichte über bestimmte Testfallerfolge und -fehler. Das „Works with“-Testframework-Dokument und zusätzliche Tools sind unter windowsservercatalog.com/ready verfügbar und bieten weitere Details. Diese Tools unterstützen ISVs beim Integrieren von Anwendungskompatibilität und ermöglichen IT-Experten, die Bereitschaft einer Anwendung für die Bereitstellung unter Windows Server 2008 zu evaluieren.
Installieren Sie zum Verwenden dieser Tools zuerst die aktuelle Version von Windows Server 2008 auf einem Testcomputer, laden Sie das „Works with“-Tool über windowsservercatalog.com/ready herunter, und stellen Sie sicher, dass das Application Verifier-Tool enthalten ist. Die grafische Benutzeroberfläche des Tools besitzt vier einfache Funktionen: Erstellen eines Testdurchlaufs, Wiederaufnehmen eines existierenden Testdurchlaufs, Anzeigen der Testergebnisse und Erstellen eines Übermittlungspakets (für ISVs, die eine „Works with“-Überprüfung von einem autorisierten Testanbieter benötigen).
Testbericht mit Ergebnissen
Testbericht mit Ergebnissen
Sie erstellen einen Testdurchlauf, indem Sie eine Anwendung durch ihren Lebenszyklus führen: Installation, Konfiguration, Ausführung und Deinstallation. Das „Works with“-Tool wird hauptsächlich im Hintergrund ausgeführt. Dabei überprüft es die Stabilität des Betriebssystems und die Kompatibilität des Installationsprogramms sowie die ordnungsgemäße Ausführung der Features im Hinblick auf die neuen Sicherheitsanforderungen der Plattform und andere konfigurierbare Features. Es empfiehlt sich, den Testdurchlauf abzuschließen und den vollständigen Bericht zu generieren, was gewöhnlich zwei bis vier Stunden dauert. Sie können jedoch auch einen Testdurchlauf beenden, einen Kurzbericht generieren und den Test später wiederaufnehmen.
Nach Abschluss werden für jeden Testfall deutliche rote oder grüne Statusberichte mit ausführlichen Ergebnissen angezeigt, wie Sie dem Bildschirmfoto entnehmen können. Grün dargestellte Tests zeigen Kompatibilität an. Für rote Ergebnisse können Sie eine Protokolldatei einsehen, um die Fehlerbedingung zu verstehen. Speichern Sie generierte Protokolle auf einem anderen Computer, damit Sie sie auch nach der Bereinigung Ihres Testcomputers verwenden können. Das „Works with“-Tool kann mit allen Serveranwendungen ausgeführt werden. Darüber hinaus kann es für Windows Vista® entworfene Clientkomponenten und Verwaltungstools evaluieren.
Wenn Sie kommerzielle Software verwenden, hilft Ihnen das „Works with“-Tool bei der Migration in Bezug auf bekannte kompatible Anwendungen. Sie können die Testergebnisse heranziehen, um Anbieter nach Unterstützungsplänen zu fragen, während Entwickler beim Erkennen von Kompatibilitätsproblemen und Priorisieren von Lösungen Zeit sparen. Sie können Ihren Entwicklungsteams ein äußerst spezifisches Feedback in Bezug auf benutzerdefinierte Anwendungen bieten. Darüber hinaus können Sie kontinuierlich Kompatibilität bestätigen, wenn neue Patches veröffentlicht werden, und Anwendungskonfigurationsdaten für Ihre IT-Abteilung dokumentieren. Einige Kunden haben die Tools zum Dokumentieren von Dateien verwendet, die mit Systemanwendungen in Berührung kommen.
Wir würden gern Ihr Feedback dazu hören, wie wir die Testfälle oder die Tools zum Optimieren der Nutzbarkeit in Ihrer Umgebung verbessern können. Bitte teilen Sie uns Ihr Feedback unter folgender Adresse mit: wslogofb@microsoft.com.

Venkat Krishnamachariist seit 2005 technischer Leiter für die Windows Server-Softwarezertifizierung. Davor arbeitete er in dem Team, das SQL Server 2005 auslieferte.


 The Cable Guy: Migrieren des Intranets zu IPv6 mit ISATAP
The Cable Guy
Migrieren des Intranets zu IPv6 mit ISATAP
Joseph Davies
Dieser Artikel basiert auf einer Vorabversion von Windows Server 2008. Die in diesem Artikel enthaltenen Informationen können jederzeit geändert werden.

In Verbindung mit IPv6 (Internetprotokoll Version 6) gibt es einige fälschliche Annahmen. Eine davon besteht darin, dass zur Verwendung von IPv6 systemeigene IPv6-Adressierung und systemeigenes IPv6-Routing bereitgestellt werden müssen, was eine detaillierte Analyse von IPv6-Adressierungsschemas, Routerupdates, Konfiguration sowie einen Einführungsplan erfordert. Obwohl all dies letzten Endes für systemeigene
IPv6-Konnektivität erfolgen sollte, können Sie mit ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) problemlos getunnelte IPv6-Konnektivität bereitstellen. Getunnelte IPv6-Konnektivität ermöglicht Hosts, die ISATAP unterstützen, die Kommunikation mithilfe von IPv6-Datenverkehr, der mit einem IPv4-Header gekapselt ist (das IPv4-Protokollfeld ist auf 41 festgelegt). ISATAP-Datenverkehr kann ein reines IPv4-Intranet durchlaufen, sodass Sie sofort mit dem Testen IPv6-fähiger Anwendungen beginnen können, ohne auf eine systemeigene IPv6-Infrastruktur warten zu müssen.
ISATAP ist eine im Standard RFC 4214 definierte Technologie für Adresszuweisung und automatisches Tunneling, mit der IPv6-Unicastverbindungen zwischen IPv6/IPv4-Hosts über ein IPv4-Internet bereitgestellt werden. ISATAP-Hosts verwenden eine logische Tunnelschnittstelle, der ISATAP-Adressen in einem der folgenden Formate zugewiesen sind: entweder UnicastPrefix:0:5EFE:w.x.y.z (wenn w.x.y.z eine private IPv4-Adresse ist, die dem ISATAP-Host zugewiesen ist) oder UnicastPrefix:200:5EFE:w.x.y.z (wenn w.x.y.z eine öffentliche IPv4-Adresse ist, die dem ISATAP-Host zugewiesen ist). UnicastPrefix ist ein beliebiges 64-Bit-Unicastadresspräfix, einschließlich Link-Local-, globaler und eindeutiger lokaler Präfixe. Beispiele für ISATAP-Adressen sind 2001:DB8::98CA:200:131.107.28.9 und 2001:DB8::98CA:0:10.91.211.17.

Intranet-Migration zu IPv6 mit ISATAP
Eine ISATAP-Bereitstellung besteht aus einem oder mehreren logischen ISATAP-Subnetzen, die reine IPv4-Netzwerke sind, denen ein 64-Bit-IPv6-Subnetzpräfix zugewiesen ist. In einem logischen ISATAP-Subnetz gibt es ISATAP-Hosts und ISATAP-Router. Ein ISATAP-Host verwendet eine ISATAP-Tunnelschnittstelle, um IPv6-Datenverkehr zu kapseln. Dieser Datenverkehr kann direkt an andere ISATAP-Hosts in demselben logischen ISATAP-Subnetz gesendet werden. Um Ziele in anderen ISATAP-Subnetzen oder in systemeigenen IPv6-Subnetzen zu erreichen, wird der Datenverkehr an einen ISATAP-Router gesendet. Ein ISATAP-Router ist ein IPv6-Router, der ISATAP-Hosts Subnetzpräfixe ankündigt und IPv6-Datenverkehr zwischen ISATAP-Hosts und Hosts in anderen IPv6 Subnetzen weiterleitet. Abbildung 1 zeigt die Komponenten von ISATAP in einem vereinfachten Intranet.
Abbildung 1 Reine IPv4-Anteile und IPv6-fähige Anteile des Intranets
Abbildung 1 Reine IPv4-Anteile und IPv6-fähige Anteile des Intranets
ISATAP ermöglicht es Ihnen, systemeigene IPv6-Adressierungs- und Routingfunktionen in drei Phasen in Ihrem Intranet bereitzustellen.
Phase 1: Reines IPv4-Intranet In dieser Phase kann Ihr gesamtes Intranet ein einziges, logisches ISATAP-Subnetz sein. Abbildung 2 zeigt ein Beispiel für ein reines IPv4-Intranet mit einem ISATAP-Router, der ISATAP-Hosts nur ein globales oder eindeutiges lokales Adresspräfix ankündigt.
Abbildung 2 Ein reines IPv4-Intranet
Abbildung 2 Ein reines IPv4-Intranet
Phase 2: Reine IPv4-Anteile und IPv6-fähige Anteile des Intranets In dieser mittleren Phase besteht Ihr Intranet aus einem reinen IPv4-Anteil (dem logischen ISATAP-Subnetz) und einem IPv6-fähigen Anteil. Der IPv6-fähige Anteil des Intranets unterstützt IPv4 und wurde aktualisiert, sodass systemeigene IPv6-Adressierung und Routing unterstützt werden. Sie haben diese Konfiguration bereits in Abbildung 1 gesehen.
Phase 3: IPv6-fähiges Intranet In dieser Endphase unterstützt das gesamte Intranet sowohl IPv4 als auch systemeigene IPv6-Adressierung und Routing. Beachten Sie, dass ISATAP nicht länger erforderlich ist. Abbildung 3 zeigt ein Beispiel.
Abbildung 3 IPv6-fähiges Intranet
Abbildung 3 IPv6-fähiges Intranet
Mit ISATAP können Sie IPv6-Konnektivität zwischen Hosts und Anwendungen während der ersten beiden Phasen des Übergangs von einem reinen IPv4-Intranet zu einem IPv6-fähigen Intranet erreichen.

Windows Server 2008 und Windows Vista
Das IPv6-Protokoll für Windows Server® 2008 und Windows Vista® unterstützt ISATAP sowohl als ISATAP-Host als auch als ISATAP-Router. Es gibt eine separate ISATAP-Tunnelschnittstelle für jede im Computer installierte LAN-Schnittstelle, die ein anderes DNS-Suffix aufweist. Beispiel: Wenn ein Computer mit Windows Vista zwei LAN-Schnittstellen besitzt, die beide mit demselben Intranet verbunden sind und denen das gleiche DNS-Suffix zugewiesen ist, gibt es nur eine ISATAP-Tunnelschnittstelle. Sind diese beiden LAN-Schnittstellen jedoch mit zwei verschiedenen Netzwerken mit unterschiedlichen DNS-Suffixen verbunden, gibt es zwei ISATAP-Tunnelschnittstellen. Bei Computern mit Windows Server 2008 oder Windows Vista SP1 werden die ISATAP-Tunnelschnittstellen in einen Zustand versetzt, in dem keine Verbindung zu Medien besteht, es sei denn, der Name „ISATAP“ kann aufgelöst werden.
Standardmäßig konfiguriert das IPv6-Protokoll für Windows Vista ohne installierte Service Packs automatisch Link-Local-ISATAP-Adressen (FE80::5EFE: w.x.y.z oder FE80::200:5EFE:w.x.y.z) auf den ISATAP-Tunnelschnittstellen für die IPv4-Adressen, die den entsprechenden LAN-Schnittstellen zugewiesen sind.
Das IPv6-Protokoll für Windows Server 2008 und Windows Vista SP1 konfiguriert Link-Local-ISATAP-Adressen nur dann auf ISATAP-Tunnelschnittstellen, wenn der Name „ISATAP“ aufgelöst werden kann.
Um eine Routerankündigung vom ISATAP-Router zu empfangen, muss der ISATAP-Host dem ISATAP-Router eine Routeranfrage senden. In einem Ethernet-Subnetz sendet ein systemeigener IPv6-Host eine Multicastrouteranfrage, woraufhin die Router im Subnetz mit einer Routerankündigung antworten. Da ISATAP weder IPv4-Multicastverkehr verwendet noch eine multicastfähige IPv4-Infrastruktur erfordert, muss der ISATAP-Host die Routeranfrage per Unicast an den ISATAP-Router senden.
Um die Routeranfrage per Unicast an den ISATAP-Router senden zu können, muss der ISATAP-Host zuerst die IPv4-Unicastadresse der Schnittstelle des ISATAP-Routers im logischen ISATAP-Subnetz bestimmen. Für das IPv6-Protokoll für Windows Server 2008 und Windows Vista ruft ein ISATAP-Host die IPv4-Unicastadresse des ISATAP-Routers mithilfe der erfolgreichen Auflösung des Hostnamens „ISATAP“ in eine IPv4-Adresse oder mit dem Befehl „netsh interface isatap set router“ ab.

Migrieren des Intranets: Phase 1
Um ISATAP im Intranet für Phase 1 der Migration zu IPv6 bereitzustellen, müssen Sie die folgenden Schritte durchführen.
Festlegen des ISATAP-Subnetzpräfix Sie müssen das 64-Bit-Subnetzpräfix festlegen, das dem logischen ISATAP-Subnetz zugewiesen werden soll, das Ihrem Intranet entspricht. Sie können ein 48-Bit-Präfix von einem ISP oder einer Internet Registry beziehen oder ein eigenes eindeutiges lokales 48-Bit-Präfix ableiten (siehe RFC 4193 online unter tools.ietf.org/html/rfc4193).
Wählen Sie aus dem 48-Bit-Präfix eine 16-Bit-Subnetz-ID für das logische ISATAP-Subnetz aus. Die Kombination aus 48-Bit-Präfix und 16-Bit-Subnetz-ID ergibt das 64-Bit-ISATAP-Subnetzpräfix. Zum Beispiel bilden das eindeutige lokale 48-Bit-Präfix FD8A:219C:052A::/48 und die Subnetz-ID 1 das 64-Bit-Subnetzpräfix FD8A:219C:052A:1::/64.
Bestimmen eines ISATAP-Routercomputers Bestimmen Sie, welcher Computer als ISATAP-Router fungieren soll. Obwohl viele handelsübliche Router ISATAP-Routerfunktionen unterstützen, gelten die hier bereitgestellten Informationen speziell für Computer mit Windows Server 2008.
Der ISATAP-Routercomputer benötigt weder mehrere LAN-Schnittstellen noch muss er für Phase 1 mit einem IPv6-fähigen Anteil des Intranets verbunden sein. Der Computer sollte jedoch so ausgewählt werden, dass er später um eine zusätzliche LAN-Schnittstelle ergänzt werden kann, die mit dem IPv6-fähigen Anteil des Intranets verbunden ist.
Konfigurieren des ISATAP-Routercomputers Durch Eingabe des folgenden Befehls auf dem ISATAP-Routercomputer werden die ISATAP-Tunnelschnittstellen auf dem ISATAP-Routercomputer in einen mit Medien verbundenen Zustand platziert:
netsh interface isatap set router IPv4Address
IPv4Address ist die IPv4-Adresse, die der LAN-Schnittstelle des ISATAP-Routercomputers zugewiesen wird, der mit dem logischen ISATAP-Subnetz verbunden ist.
Bestimmen Sie als Nächstes mithilfe der Ausgabe des folgenden Befehls den Namen oder den Schnittstellenindex der ISATAP-Tunnelschnittstelle, die der LAN-Schnittstelle des ISATAP-Routercomputers entspricht, der mit dem logischen ISATAP-Subnetz verbunden ist:
netsh interface ipv6 show interfaces
Aktivieren Sie dann mithilfe dieses Befehls auf der ISATAP-Schnittstelle die Ankündigung:
netsh interface ipv6 set interface ISATAPInterfaceNameOrIndex advertise=enabled
ISATAPInterfaceNameOrIndex ist der Name oder der Schnittstellenindex der ISATAP-Tunnelschnittstelle.
Konfigurieren Sie anschließend mithilfe dieses Befehls den ISATAP-Routercomputer für die Ankündigung des ISATAP-Subnetzpräfixes an die ISATAP-Hosts:
netsh interface ipv6 add route ISATAPSubnetPrefix ISATAPInterfaceNameOrIndex publish=yes
ISATAPSubnetPrefix ist das bestimmte ISATAP-Subnetzpräfix
Konfigurieren des DNS Fügen Sie im DNS den entsprechenden Domänen einen Adresseintrag (A) für den Namen ISATAP hinzu, damit ISATAP-Hosts in Ihrem Intranet den Namen „ISATAP“ erfolgreich auflösen können. Beispiel: Wenn Ihre Intranet-Hosts das DNS-Suffix contoso.com verwenden, müssen Sie der Domäne contoso.com einen Adresseintrag für den Namen isatap.contoso.com mit der IPv4-Adresse hinzufügen, die der LAN-Schnittstelle des ISATAP-Routers im reinen IPv4- Intranet zugewiesen ist.
Wenn auf dem DNS-Server Windows Server 2008 ausgeführt wird, verwenden Sie den Registrierungs-Editor (regedit.exe) auf dem DNS-Server, um den ISATAP-Eintrag aus dem Registrierungswert „HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters\GlobalQueryBlockList“ zu entfernen.
Testen der ISATAP-Hosts Zeigen Sie mithilfe des Tools Ipconfig auf einem ISATAP-Host im Intranet die zugewiesenen Adressen an. ISATAP-Hosts sollten eine Adresse im Format ISATAPSubnetPrefix:: 5EFE:w.x.y.z oder ISATAPSubnetPrefix:: 200:5EFE:w.x.y.z aufweisen. Beispiel: Wenn Ihr ISATAP-Subnetzpräfix FD8A:219C: 052A:1::/64 lautet und ein ISATAP-Host die IPv4-Adresse 10.1.31.97 hat, sollte der ISATAP-Tunnelschnittstelle des ISATAP-Hosts die Adresse FD8A: 219C:052A:1::5FE:10.1.31.97 zugewiesen sein.
Wenn ein ISATAP-Host keine ISATAP-Adresse auf der Grundlage des ISATAP-Subnetzpräfixes besitzt, überprüfen Sie, ob der Host den Namen „ISATAP“ auflösen kann. Ist dies nicht der Fall, überprüfen Sie, ob die Adresseinträge in den entsprechenden Domänen erstellt wurden. Überprüfen Sie bei DNS-Servern mit Windows Server 2008, ob der Registrierungswert „GlobalQueryBlockList“ geändert wurde, um den ISATAP-Eintrag zu entfernen. Wenn der Name aufgelöst werden kann, überprüfen Sie, ob der ISATAP-Routercomputer richtig konfiguriert wurde. Wenn dies der Fall ist, überprüfen Sie, ob die Router im Intranet die Weiterleitung von Datenverkehr über das IPv4-Protokoll 41 erlauben.
Wenn sich ISATAP-Hosts erfolgreich mit Adressen auf Basis des ISATAP-Subnetzpräfixes konfigurieren können, registrieren sie diese ISATAP-Adressen als AAAA-Einträge im DNS und verwenden sie für IPv6-basierte Konnektivität.

Migrieren des Intranets: Phase 2
In Phase 2 der Migration zu IPv6 müssen Sie Ihre ISATAP-Routerkonfiguration ändern, um die Weiterleitung zwischen den reinen IPv4-Anteilen und den IPv6-fähigen Anteilen des Intranets durchzuführen.
Geben Sie auf dem ISATAP-Routercomputer den folgenden Befehl ein:
netsh interface ipv6 show interfaces
Bestimmen Sie anhand der Ausgabe des obigen Befehls den Namen oder den Schnittstellenindex der LAN-Schnittstelle, die mit dem IPv6-fähigen Anteil des Intranets und der ISATAP-Tunnelschnittstelle verbunden ist.
Aktivieren Sie mithilfe dieses Befehls die Weiterleitung auf der ISATAP-Schnittstelle:
netsh interface ipv6 set interface ISATAPInterfaceNameOrIndex forwarding=enabled
Aktivieren Sie mithilfe dieses Befehls die Weiterleitung auf der LAN-Schnittstelle:
netsh interface ipv6 set interface LANInterfaceNameOrIndex forwarding=enabled
LANInterfaceNameOrIndex ist der Name oder der Schnittstellenindex der LAN-Schnittstelle.
Fügen Sie dem ISATAP-Router mithilfe des folgenden Befehls eine Standardroute hinzu:
netsh interface ipv6 add route ::/0 LANInterfaceNameOrIndex NextHopAddress publish=yes
NextHopAddress ist die IPv6-Adresse eines benachbarten systemeigenen IPv6-Routers im IPv6-fähigen Anteil des Intranets.
Damit das logische ISATAP-Subnetz aus dem IPv6-fähigen Anteil des Intranets erreichbar ist, müssen Sie die systemeigenen IPv6-Router mit einer Route für das ISATAP-Subnetzpräfix konfigurieren, die auf den ISATAP-Routercomputer verweist.
Um ISATAP für Computer im IPv6-fähigen Anteil des Intranets selektiv zu deaktivieren, ändern Sie die Adresseinträge für den Namen „ISATAP“ in Ihrem DNS, damit Computer im IPv6-fähigen Anteil des Intranets den Namen „ISATAP“ nicht auflösen können.
Eine weitere Möglichkeit besteht darin, den Registrierungswert HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters\DisabledComponents zu erstellen und dafür 0x4 (DWORD-Typ) festzulegen.

Migrieren des Intranets: Phase 3
Wenn das gesamte Intranet IPv6-fähig ist, müssen Sie in Phase 3 die ISATAP-Bereitstellung über DNS entfernen und den ISATAP-Routercomputer erneut konfigurieren. Entfernen Sie im DNS alle Adresseinträge für den Namen „ISATAP“. Dadurch werden Hosts grundsätzlich daran gehindert, die IPv4-Adresse des ISATAP-Routers zu bestimmen.
Führen Sie für den ISATAP-Routercomputer den folgenden Befehl aus:
netsh interface isatap set router default
Mit diesem Befehl wird die ISATAP-Komponente wieder in den Standardzustand zurückversetzt.
Bestimmen Sie den Namen oder den Schnittstellenindex der ISATAP-Tunnelschnittstelle anhand der Ausgabe dieses Befehls:
netsh interface ipv6 show interfaces
Deaktivieren Sie mithilfe dieses Befehls die Weiterleitung und Ankündigung auf der ISATAP-Schnittstelle:
netsh interface ipv6 set interface ISATAPInterfaceNameOrIndex forwarding=disabled advertise=disabled
Entfernen Sie mithilfe dieses Befehls die ISATAP-Subnetzpräfixroute vom ISATAP-Routercomputer:
netsh interface ipv6 delete route ISATAPSubnetPrefix ISATAPInterfaceNameOrIndex
ISATAPSubnetPrefix ist das ISATAP-Subnetzpräfix.
Weitere Informationen zur ISATAP-Bereitstellung, darunter auch zu redundanten ISATAP-Routern und Firewallüberlegungen, finden Sie im Bereitstellungshandbuch für Intra-Site Automatic Tunnel Addressing Protocol unter go.microsoft.com/fwlink/?LinkId=106926.

Joseph Davies ist technischer Redakteur bei Microsoft und lehrt und schreibt seit 1992 über Themen im Bereich der Windows-Netzwerke. Er hat acht Bücher für Microsoft Press verfasst und ist Autor des monatlich erscheinenden TechNet-Artikels „The Cable Guy“. Weitere Informationen über „The Cable Guy“ finden Sie unter microsoft.com/technet/community/columns/cableguy/about.mspx.


 Windows PowerShell: Forschrittsbericht
Windows PowerShell
Forschrittsbericht
Don Jones

Ich habe vor Kurzem ein ziemlich langes und kompliziertes Windows PowerShell-Skript geschrieben, das während der Ausführung nur sehr langsam reagierte. Es sollte als geplanter Task ausgeführt werden, sodass nur eine geringe sichtbare Ausgabe erzeugt wurde. Bei der ersten großen Testausführung machte ich mir dennoch Sorgen, ob ich nicht
versehentlich eine Endlosschleife oder einen anderen Fehler in das Skript eingebaut hatte.
Angesichts der inaktiven Shell und des nervtötenden, kleinen blinkenden Zeigers fragte ich mich, ob das Skript möglicherweise zerstört war. Offensichtlich habe ich kein Vertrauen in meine eigenen Fähigkeiten. Ich gab in Windeseile Strg+C ein, um das Skript zu unterbrechen. Es ist an der Zeit, Fortschrittsberichterstellung hinzuzufügen.

Anweisungen über Anweisungen
Cmdlet des Monats: Tee-Object
In diesem Monat möchte ich eines meiner Lieblings-Cmdlets zur Fehlerbehebung vorstellen. Sehen Sie sich z. B. Folgendes an:
Get-WMIObject Win32_Service | Where { $_.State -ne "Running"
-and $_.StartMode -eq "Automatic" } | ForEach-Object { $_.Start() }
Auf den ersten Blick müssten dadurch alle Dienste gestartet werden, für die ein automatischer Start festgelegt wurde, die aber aus unterschiedlichen Gründen noch nicht gestartet wurden. Dies funktioniert aber nicht wirklich. Außerdem kann sich das Ermitteln der Gründe als sehr kompliziert erweisen, weil Sie die Mitte der Pipeline nicht einsehen können. Das heißt, Sie können die Mitte der Pipeline nur einsehen, wenn Sie Tee-Object verwenden.
Tee-Object leitet Objekte an eine Datei um (oder in eine Variable) und übergibt sie entlang der Pipeline. Beispiel:
Get-WMIObject Win32_Service | Tee-Object AllServices.csv | Where
{ $_.State -ne "Running" -and $_.StartMode -eq "Automatic" } |
Tee-Object FilteredServices.csv | ForEach-Object { $_.Start() }
Anhand dieser Änderung lässt sich erkennen, was nach jedem Pipelinebefehl geschieht. Es ist sofort ersichtlich, dass die FilteredServices.csv-Datei keinen Inhalt hat. Kein Wunder, dass dieses Skript nicht funktioniert hat! Weitere Nachforschungen weisen auf die Ursache des Problems hin: StartMode ist „Auto“ und nicht „Automatic“, und mithilfe von Tee-Object können Sie genau feststellen, an welcher Stelle das Problem auftrat.

Als Erstes sollte eine Reihe von Statusmeldungen hingefügt werden, mit denen die jeweiligen Aktivitäten des Skripts genau angezeigt werden. In der Shell lässt sich dies mit dem Write-Verbose-Cmdlet relativ einfach bewerkstelligen. Probieren Sie Folgendes in der Shell aus:
Write-Verbose "Test Message"
Sie werden nach dem Versuch festgestellt haben, dass nichts bewirkt wurde. Das liegt daran, dass Write-Verbose Objekte an die spezielle Verbose-Pipeline sendet, die standardmäßig keine Ausgabe anzeigt. Diese Pipeline wird durch eine integrierte Shellvariable, $VerbosePreference, kontrolliert. Der Standardwert für diese Variable ist SilentlyContinue und unterdrückt eine ausführliche Ausgabe. Durch Einstellen auf „Continue“ wird jedoch die Pipeline geöffnet:
$VerbosePreference = "Continue"
Jetzt können Sie dem Skript eine Vielzahl an Write-Verbose-Anweisungen hinzufügen und während der Ausführung eine detaillierte Ansicht erhalten. Der Vorteil an diesem Verfahren besteht darin, dass nach dem Testen und der Fehlerbehebung alle zusätzlichen Anweisungen durch Einstellen von $VerbosePreference am Anfang des Skripts zurück auf SilentlyContinue beendet werden können.
Es ist nicht erforderlich, alle Write-Verbose-Anweisungen manuell zu entfernen. Da sie im Skript verbleiben, kann die Verbose-Pipeline bei Bedarf für jede manuelle Skriptausführung problemlos wieder aktiviert werden.

Wo bleibt der wahre Fortschritt?
Nachdem ich mich vergewissert hatte, dass das Skript nicht in einer Endlosschleife aufgehalten wurde, sondern perfekt funktionierte, habe ich die Verbose-Pipeline deaktiviert und das Skript zur Überprüfung erneut ausgeführt.
Obwohl ich genau weiß, dass das Skript perfekt funktioniert, kann ich den Anblick des blinkenden Cursors allerdings immer noch nicht ertragen. (Anscheinend gibt es auch bei mir Konzentrationsprobleme, und ich fing schon an, mich verzweifelt nach einer sinnvolleren Tätigkeit umzusehen.)
Mir fehlte ganz einfach ein Hinweis auf den generellen Fortschritt des Skripts mit einer ungefähren Angabe des Abschlusses. Im Grunde brauchte ich so etwas wie eine Fortschrittsanzeige.
Glücklicherweise enthält Windows PowerShellTM das Write-Progress-Cmdlet. Dieses Cmdlet bietet zwar keine grafische Fortschrittsanzeige wie in Windows®, aber immerhin eine brauchbare Fortschrittsanzeige (siehe Abbildung 1). Sie gleicht ein wenig der Fortschrittsanzeige beim Kopieren von Dateien, die im textbasierten Teil der Installation in Windows Server® 2003 oder sogar Windows XP verwendet wird.
Abbildung 1 Wie weit ist Ihr Skript fortgeschritten?
Abbildung 1 Wie weit ist Ihr Skript fortgeschritten?
Die Verwendung von Write-Progress muss etwas näher erläutert werden. Sie lässt sich am besten anhand eines Beispiels veranschaulichen. Sehen Sie sich das folgende Skript an:
for ($a=1; $a -lt 100; $a++) {
  Write-Progress -Activity "Working..." `
   -PercentComplete $a -CurrentOperation
   "$a% complete" `
   -Status "Please wait."
  Start-Sleep 1
}
Es verwendet Write-Progress, um eine Fortschrittsanzeige anzuzeigen. Es wurde Start-Sleep verwendet, um das Skript nach jeder Schleife eine Sekunde lang anzuhalten. Auf diese Weise ist die Ausführung langsam genug, um den Fortschritt zu beobachten. Ohne die Pause zählt die Schleife so schnell von 0 bis 100, dass die Fortschrittsanzeige nur kurz auf dem Bildschirm aufleuchtet.
Wie Sie sehen, wird die ausgeführte Aktivität am oberen Rand der Fortschrittsanzeige aufgeführt. Der Status wird direkt darunter angezeigt, der aktuelle Vorgang am unteren Rand. Die Shell kann nicht mehrere Fortschrittsanzeigen gleichzeitig unterstützen. Bei jeder Verwendung von Write-Progress wird entweder eine neue Fortschrittsanzeige erstellt, falls zurzeit keine angezeigt wird, bzw. die aktuell angezeigte Fortschrittsanzeige wird aktualisiert.
In diesem Beispiel wurde die Fortschrittsanzeige allerdings nicht angewiesen, nach getaner Arbeit zu verschwinden. Hierfür müssen Sie am Ende des Skripts lediglich Folgendes hinzufügen:
Write-Progress -Activity "Working..." `
 -Completed -Status "All done."
In der Regel verschwindet die Fortschrittsanzeige direkt nach Abschluss des Skripts von allein. Wenn Ihr Skript jedoch weiterhin beschäftigt ist, soll die Fortschrittsanzeige anschließend ausgeblendet werden. Mit dem -Completed-Parameter können Sie die Fortschrittsanzeige aus der Anzeige entfernen.

Sekundenanzeige
Eine andere häufige Verwendung von Write-Progress besteht darin, eine Anzeige der verbleibenden Sekunden anstatt einer Fortschrittsanzeige zu erstellen. Hier ist ein Beispiel:
for ($a=100; $a -gt 1; $a--) {
  Write-Progress -Activity "Working..." `
   -SecondsRemaining $a -CurrentOperation
   "$a% complete" `
   -Status "Please wait."
  Start-Sleep 1
}
Es wurde einfach die Schleifenzählung in 100 bis 1 geändert und der SecondsRemaining-Parameter von Write-Progress anstatt PercentComplete verwendet. Das Ergebnis ist in Abbildung 2 dargestellt. Wie Sie sehen, wurde die Fortschrittszeitanzeige durch eine Countdownuhr ersetzt. Die Shell konvertiert automatisch die Gesamtanzahl der verbleibenden Sekunden in Stunden, Minuten und Sekunden und stellt so benutzerfreundlichere Informationen zur Verfügung. Die hier gezeigte prozentuale Fortschrittsanzeige zählt von 100 abwärts, da dies der zur Verfügung gestellte CurrentOperation-Parameter ist. Es gibt keine Berechnung der prozentualen Fertigstellung. Windows PowerShell zeigt einfach den aktuellen Wert von $a an, gefolgt von der Zeichenfolge „% complete“.
Abbildung 2 Wie lange dauert die Fertigstellung des Skripts?
Abbildung 2 Wie lange dauert die Fertigstellung des Skripts?

Skripts, die kommunizieren
Ich bin ein großer Anhänger des Schreibens von Skripts, die mich über ihre Aktivitäten informieren. Dies kann in Form einer ausführlichen Ausgabe oder lediglich über eine einfache Fortschrittsanzeige erfolgen und hilft mir hier und heute bei der Konzentration, zugleich aber auch anderen Benutzern, die das Skript in Zukunft ausführen müssen. Letzten Endes kann die Anzeige von Status- und Fortschrittsinformationen, in welcher Form auch immer, nur von Vorteil sein.

Don Jones schreibt redaktionelle Beiträge für das TechNet Magazin und ist Mitautor von Windows PowerShell: TFM (SAPIEN Press, 2007). Er hält Schulungen zu Windows PowerShell ab (siehe www.ScriptingTraining.com). Sie erreichen ihn über die Website ScriptingAnswers.com.


 Hey, Scripting Guy!: Spielen mit dem Shellobjekt
Hey, Scripting Guy!
Spielen mit dem Shellobjekt
Die Scripting Guys von Microsoft
Laden Sie den Code für diesen Artikel herunter: HeyScriptingGuy2008_03.exe (150KB)

Dem alten Sprichwort zufolge kann kein Spatz zur Erde fallen, ohne dass der Himmel davon weiß. Die Scripting Guys wollen keineswegs dazu ermutigen, Spatzen vom Himmel zu holen. (Wenn sich allerdings jemand um diese lästigen Krähen auf dem Dach kümmern würde, die am Samstagmorgen um 7:00 Uhr zu lärmen anfangen, dann wäre das etwas anderes. [Der Skriptingredakteur mag Krähen. Wenn der Verfasser dieses Beitrags „sich um die Krähen kümmern“ sagt, meint er ganz bestimmt „dafür sorgen, dass es ihnen gut geht“. -d. Red.]) Dennoch ist es tröstlich zu wissen, dass immer jemand da ist, wenn wirklich etwas schief geht. Wie klein und bedeutungslos man auch erscheinen mag, irgendwo gibt es jemanden, der über einen wacht. [Selbst wenn es nur ein Redakteur ist. -d. Red.]
Was für Spatzen gilt, lässt sich auf die Skriptprogrammierung für die Systemadministration übertragen. In der Skriptingwelt dreht sich fast alles um die Schwergewichte des Skripting: Windows PowerShellTM, VBScript, WMI, ADSI und sogar FileSystemObject. Dass um diese Technologien der größte Rummel veranstaltet wird, ist nachvollziehbar. Schließlich lassen sich damit etliche interessante und nützliche Dinge anstellen. Das bedeutet jedoch nicht, dass dies die einzigen Technologien sind, die Skriptprogrammierern zur Verfügung stehen. Weit gefehlt.
Nehmen Sie zum Beispiel das Shellobjekt. Das Shellobjekt ist vielleicht weniger gut bekannt als Windows PowerShell, es ist jedoch wichtig und nach wie vor nützlich.
Es ist durchaus nicht abwegig, dass Sie früher oder später darum gebeten werden, ein Skript für die Systemadministration zu schreiben, das mit dem Shellobjekt arbeitet. Daraus ergibt sich zwangsläufig folgende Frage: Was genau lässt sich mit dem Shellobjekt anfangen? Wie sich herausstellt, können Sie mit dem Shellobjekt eine ganze Menge anfangen. Einige der Möglichkeiten (z. B. die Verwaltung von Datenträgerkontingenten und das Anzeigen einer Fortschrittsanzeige beim Kopieren oder Verschieben von Dateien) werden im Skriptinghandbuch für Microsoft® Windows® 2000 behandelt (microsoft.com/technet/scriptcenter/guide). Im Artikel dieses Monats zeigen wir Ihnen einige andere nützliche Dinge, für die das Shellobjekt verwendet werden kann und die Sie wahrscheinlich nie für möglich gehalten hätten – schon gar nicht mit dem Shellobjekt.

Ändern des Datums der letzten Änderung einer Datei
Viele von Ihnen denken wahrscheinlich beim Blick auf die vorhergehende Überschrift „Moment mal. Es ist nicht möglich, das Datum der letzten Änderung einer Datei mit einem Skript zu ändern, zumindest nicht mit VBScript.“ Darauf können wir nur erwidern: Wer hat Sie nur auf eine solche Idee gebracht?
Ach ja, stimmt: Vermutlich sind wir Scripting Guys dafür verantwortlich. Allerdings wissen wir nun, dass wir uns geirrt haben. Unglaublich! Es ist möglich, das Datum der letzten Änderung einer Datei mithilfe von VBScript zu ändern. Sie müssen lediglich das Shellobjekt verwenden.
Hinweis: Fragen Sie bitte nicht, wie die Scripting Guys sich in dieser Sache irren konnten. Nach all diesen Jahren sollte das ziemlich klar sein. Eine weitaus interessantere Frage ist diese: Wie in aller Welt bringen wir es je fertig, etwas richtig zu machen?
Sie möchten also das Datum der letzten Änderung einer Datei ändern? Dann verwenden Sie einfach dieses Skript:
Set objShell = _
  CreateObject("Shell.Application")

Set objFolder = _
  objShell.NameSpace("C:\Scripts")
Set objFolderItem = _
  objFolder.ParseName("Dr_Scripto.jpg")

objFolderItem.ModifyDate = _
  "01/01/2008 8:00:00 AM"
Wie Sie sehen, ist das nicht furchtbar kompliziert. Als Erstes erstellen Sie eine Instanz des Shell.Application-Objekts. (Verwechseln Sie aber Shell.Application nicht mit Wscript.Shell, dem Windows Script Host-Shellobjekt. Das Shellobjekt, mit dem Sie an dieser Stelle arbeiten, ist das Windows-Shellobjekt.) Nach dem Einrichten der Instanz des Shellobjekts stellen Sie mithilfe der Namespace-Methode eine Bindung an den Ordner „C:\Scripts“ her. Dann stellen Sie mithilfe der ParseName-Methode eine Bindung an eine angegebene Datei in diesem Ordner her. In diesem Fall stellen Sie eine Bindung an ein JPEG-Bild mit dem Dateinamen „Dr_Scripto.jpg“ her:
Set objFolderItem = _
  objFolder.ParseName("Dr_Scripto.jpg")
Welcher Schritt ist der nächste, nachdem Sie die Bindung an die Datei selbst hergestellt haben? Ganz einfach: Sie weisen der ModifyDate-Eigenschaft ein neues Datum und einen neuen Zeitpunkt zu:
objFolderItem.ModifyDate = _
  "01/01/2008 8:00:00 AM"
Das wäre schon alles.
Wirklich. Das ist ziemlich beeindruckend, oder? Sobald Sie das Skript ausführen, wird das Datum der letzten Änderung für die Datei auf den 1. Januar 2008, 8:00 Uhr eingestellt. (Wenn Sie möchten, können Sie den Ordner „C:\Skripts“ in Windows-Explorer öffnen und sich selbst überzeugen.)
Mancher sagt sich jetzt vielleicht: „Interessant. Ich kann das Datum der letzten Änderung einer Datei ändern. Aber welchen Grund gibt es dafür, das Datum der letzten Änderung einer Datei zu ändern?“ Viele nutzen das Datum der letzten Änderung als eine Art Versionskontrollsystem. Wenn beispielsweise mehrere Kopien eines Skripts existieren, ist die Überprüfung des Datums der letzten Änderung eine Möglichkeit zum Nachverfolgen der offiziellen Version. Durch Überprüfen des Datums der letzten Änderung können Sie feststellen, ob es sich bei einer bestimmten Kopie des Skripts um eine unveränderte Version des ursprünglichen Skripts handelt.
Hinweis: Sicher, jemand könnte das soeben gezeigte Skript ausführen und das Datum der letzten Änderung ändern. Aber falls Sie nicht alles durch Codesignierung sichern, lässt sich immer eine Möglichkeit finden, das System zu überlisten. Vorausgesetzt, die Kollegen, mit denen Sie Skripts austauschen, haben ethische Grundsätze, ist diese Herangehensweise vernünftig.
Irgendwann entschließen Sie sich vielleicht dazu, das Datum der letzten Änderung für alle Skripts zu aktualisieren – und zu standardisieren. Wie erreichen Sie dies? Wenn sich alle Skripts im Ordner „C:\Scripts“ befinden, können Sie einfach den folgenden Codeabschnitt ausführen:
Set objShell = _
  CreateObject("Shell.Application")

Set objFolder = _
  objShell.NameSpace("C:\Scripts")
Set colItems = objFolder.Items

For Each objItem In colItems
    objItem.ModifyDate  = _
      "01/01/2008 8:00:00 AM"
Next
Wie Sie sehen, ähnelt der Anfang dieses Skripts dem des ersten Skripts, das hier aufgeführt wurde. In diesem Fall wird jedoch nach dem Binden an den Ordner „C:\Scripts“ nicht ParseName zum Binden an eine einzelne Datei in diesem Ordner verwendet. Stattdessen geben Sie mithilfe dieser Codezeile eine Auflistung aller in diesem Ordner enthaltenen Dateien zurück:
Set colItems = objFolder.Items
Wenn die Auflistung vorliegt, richten Sie eine „For Each“-Schleife ein, die alle Elemente in der Auflistung durchläuft. Innerhalb der „For Each“-Schleife ändern Sie mit der folgenden nützlichen Codezeile den Wert der ModifyDate-Eigenschaft der ersten Datei in der Auflistung in den 1. Januar 2008, 8:00 Uhr:
objItem.ModifyDate  = _
  "01/01/2008 8:00:00 AM"
Dann wird die Schleife einfach erneut durchlaufen, und Sie wiederholen den Prozess mit der nächsten Datei in der Auflistung. Schließlich besitzen alle Dateien im Ordner „C:\Scripts“ (mit Ausnahme versteckter Dateien) dasselbe Datum der letzten Änderung. Sehen Sie, wie einfach das ist? Wer hat also behauptet, Sie können das Datum der letzten Änderung einer Datei nicht mit VBScript ändern?
Ach ja, richtig.

Da wir beim Thema irrige Annahmen sind ...
Vor Urzeiten, als die Scripting Guys gerade mit der Skriptprogrammierung für die Systemadministration begannen, gab es keine Möglichkeit zum Zugriff auf alle erweiterten Dateiinformationen, die im NTFS-Dateisystem mit einer Datei verknüpft sind. Wenn Sie beispielsweise mit der rechten Maustaste auf eine .wav-Datei und dann auf „Eigenschaften“ klicken, werden ähnliche Informationen angezeigt wie in Abbildung 1.
Abbildung 1 Zusammenfassung der Dateieigenschaften
Abbildung 1 Zusammenfassung der Dateieigenschaften
Wie rufen Sie mithilfe eines Skripts Werte wie Bitrate oder Abtastgröße ab? Das ist nicht möglich. Es sei denn, Sie verwenden das Shellobjekt. (Oder Windows-Desktopsuche 3.0, wenn sie diese Software heruntergeladen und installiert haben.) An einem bestimmten Punkt erhielt das Shellobjekt die Fähigkeit, alle erweiterten Eigenschaftsinformationen für eine Datei abzurufen, die Scripting Guys haben dies jedoch übersehen. Daher haben wir immer behauptet: „Sie können die Bitrate einer .wav-Datei nicht mit einem Skript bestimmen“, obwohl dies tatsächlich möglich ist, wie der Code in Abbildung 2 zeigt.
Figure 2 Verwenden eines Skripts zum Ermitteln der Bitrate einer .wav-Datei (Close Figure 2)
Set objShell = CreateObject("Shell.Application")

Set objFolder = objShell.NameSpace("C:\Scripts")
Set objFolderItem = objFolder.ParseName("J0388563.wav")

For i = 0 to 33
    strHeader = objFolder.GetDetailsOf(objFolder.Items, i)
    strValue = objFolder.GetDetailsOf(objFolderItem, i)
    If strValue <> "" Then
        Wscript.Echo strHeader & vbTab & strValue
    End If
Next
Wie genau funktioniert dieses Skript? Der Anfang gleicht dem des ersten Skripts, das Sie oben gesehen haben: Sie erstellen eine Instanz des Shell.Application-Objekts und eine Bindung an den Ordner „C:\Script“. Dann verwenden Sie die ParseName-Methode, um eine Bindung an die fragliche Datei zu erstellen (in diesem Fall J0388563.wav).
An diesem Punkt wird es ein wenig kompliziert. Zunächst richten Sie eine „For Next“-Schleife ein, die von 0 bis 33 ausgeführt wird, da Dateien bis zu 31 verschiedene erweiterte Eigenschaften mit den Indexnummern von 0 bis 33 unterstützen. (Beachten Sie, dass einige Nummern wie 27 und 28 zwar gültige Indexnummern sind, jedoch keine Eigenschaftswerte enthalten.) Die Dateien unterstützen die Eigenschaften, die in Abbildung 3 gezeigt werden.
Figure 3 Dateieigenschaften (Close Figure 3)

Index | Eigenschaft
0 | Name
1 | Größe
2 | Typ
3 | Änderungsdatum
4 | Erstellungsdatum
5 | Zugriffsdatum
6 | Attribute
7 | Status
8 | Besitzer
9 | Autor
10 | Titel
11 | Subjekt
12 | Kategorie
13 | Seiten
14 | Bemerkungen
15 | Copyright
16 | Interpret
17 | Albumtitel
18 | Jahr
19 | Titelnummer
20 | Genre
21 | Dauer
22 | Bitrate
23 | Geschützt
24 | Kameramodell
25 | Bild aufgenommen am
26 | Abmessungen
29 | Folgenname
30 | Programmbeschreibung
32 | Abtastgröße
33 | Abtastrate
Was geschieht nun innerhalb der „For Next“-Schleife? Zunächst führen Sie die folgende Codezeile aus:
strHeader = _
  objFolder.GetDetailsOf(objFolder.Items, i)
Sie verwenden hier die GetDetailsOf-Methode, um den Namen der Eigenschaft 0 abzurufen (die Schleife durchläuft die Nummern 0 bis 33). Dann speichern Sie diesen Namen in einer Variablen namens strHeader und rufen mithilfe der folgenden Codezeile den Eigenschaftswert des Elements 0 ab, wobei die zurückgegebenen Informationen in einer Variablen namens strValue gespeichert werden:
strValue = _
  objFolder.GetDetailsOf(objFolderItem, i)
Sehen Sie nun, wie dies funktioniert? Element 0 ist zufälligerweise die Name-Eigenschaft. Beim ersten Durchlaufen der Schleife ist also strHeader gleich Name. Der eigentliche Name (das heißt, der Wert der Name-Eigenschaft) der ersten Datei lautet J0388563.wav. Daher ist beim ersten Durchlaufen der Schleife strValue gleich J0388563.wav. So gesehen scheint das Ganze gar nicht so kompliziert, oder?
Sicher ist Ihnen bekannt, dass nicht alle Dateitypen alle erweiterten Eigenschaften unterstützen. (Eine .jpg-Datei hat beispielsweise keinen Albumtitel und keine Abtastrate.) In der nächsten Codezeile überprüfen Sie daher, ob ein zurückgegebener Wert eine leere Zeichenfolge ist:
If strValue <> "" Then
Wenn der Wert eine leere Zeichenfolge ist, springen Sie einfach zurück an den Anfang der Schleife und wiederholen den Prozess mit der nächsten erweiterten Eigenschaft. Ist der Wert keine leere Zeichenfolge, geben Sie den Eigenschaftsnamen und den Wert wie folgt zurück:
Wscript.Echo strHeader & vbTab & strValue
Das Ergebnis? Das sieht in etwa so aus:
Name    j0388563.wav
Size    169 KB
Type    Wave Sound
Date Modified   1/19/2004 8:56 AM
Date Created    3/6/2006 2:02 PM
Date Accessed   12/3/2007 10:41 AM
Attributes      A
Status  Online
Owner   FABRIKAM\kenmyer
Bit Rate        90kbps
Audio Sample Size       4 bit
Audio Sample Rate       11 kHz
Super.
Wir sind hier ein wenig in Zeit- und Platznot, wenn Sie jedoch nach einer noch einfacheren Möglichkeit suchen, die wichtigsten Eigenschaftswerte zurückzugeben, probieren Sie das Skript in Abbildung 4 aus.
Figure 4 Eine einfache Möglichkeit zur Rückgabe von Eigenschaftswerten (Close Figure 4)
Const colInfoTip = -1

Set objShell = CreateObject("Shell.Application")

Set objFolder = objShell.NameSpace("C:\Scripts")
Set objFolderItem = _
  objFolder.ParseName("01. Out On The Weekend (Album Version).wma)")

Wscript.Echo objFolder.GetDetailsOf(objFolderItem, colInfoTip)
Was bewirkt dieses Skript? Wenn Sie in Windows-Explorer mit dem Mauszeiger auf eine Datei zeigen, wird eine QuickInfo mit einigen nützlichen Informationen zur Datei angezeigt (siehe Abbildung 5). Wie können Sie diese QuickInfo-Informationen mithilfe eines Skripts abrufen? Richtig. Verwenden Sie das Skript, das wir Ihnen soeben gezeigt haben:
Abbildung 5 Anzeige von Eigenschaften in einer QuickInfo
Abbildung 5 Anzeige von Eigenschaften in einer QuickInfo
Artist: Neil Young
Album Title: Harvest
Year: 1972
Track Number: 1
Duration: 0:04:35
Type: Windows Media Audio file
Bit Rate: 256kbps
Protected: Yes
Size: 5.31 MB
Das war schon alles für diesen Monat. Abgesehen von einer letzten Anmerkung zum Thema Spatzen. Es gibt einen guten Grund, warum Sie Spatzen nicht aus den Augen verlieren sollten: In manchen Regionen der Welt gilt es als schlechtes Omen, wenn ein Spatz in ein Haus fliegt. Warum? Weil es bedeutet, dass ein Hausbewohner sterben wird. (In einigen Fällen gilt dies nur, wenn sich der Spatz auf ein Klavier setzt. Aber das ist kein Aberglaube, sondern schlicht bizarr.) Interessant ist jedoch Folgendes: In anderen Teilen der Welt gilt ein Spatz im Haus als Zeichen dafür, dass ein Hausbewohner bald heiraten wird. Fragt sich worin der Fluch und worin der Segen liegt ...

Der Scripting Perplexer von Dr. Scripto
Die monatliche Herausforderung, die nicht nur Ihr Talent zum Rätsellösen testet, sondern auch Ihre Skriptingfähigkeiten.

März 2008: Rätselhaftes Skript
Das Rätsel dieses Monats ist ein Kryptogramm. Das heißt, jeder Buchstabe wurde durch einen anderen Buchstaben ersetzt. (Symbole und Zahlen wurden nicht verändert.) Ein Buchstabe wird immer durch denselben Buchstaben ersetzt. Beispiel: Alle Vorkommen des Buchstabens a könnten durch den Buchstaben b ersetzt worden sein, alle Vorkommen des Buchstabens b durch z, und so weiter. Hier ein einfaches Beispiel:
tdsjqu dfoufs
lässt sich wie folgt entschlüsseln:
script center
Die Entschlüsselung erfolgte in diesem Fall durch Ersetzen jedes Buchstabens durch den jeweils vorausgehenden Buchstaben im Alphabet. Das heißt, t wurde durch s ersetzt, d durch c, und so weiter.
Im Rätsel spielt der Zufall eine etwas größere Rolle. Durch Entschlüsseln dieses Skripts erhalten Sie ein Skript, das eine Instanz von Microsoft Excel® öffnet, eine neue Tabelle hinzufügt, der ersten Spalte in der Tabelle vier Werte zuordnet und diese Spalte dann in aufsteigender Reihenfolge sortiert.
Viel Spaß!

Das Rätsel
kqyjs edfjkzyrlyg = 1
kqyjs edyq = 2
kqyjs edjqtstqmj = 2

jzs quwzekzd = ktzfszquwzks("zekzd.faadlkfslqy")
quwzekzd.iljludz = stcz

jzs quwmqtxuqqx = quwzekzd.mqtxuqqxj.frr
jzs quwmqtxjozzs = quwmqtxuqqx.mqtxjozzsj(1)

quwmqtxjozzs.kzddj(1, 1) = "kfs"
quwmqtxjozzs.kzddj(1, 2) = "rqg"
quwmqtxjozzs.kzddj(1, 3) = "ufs"
quwmqtxjozzs.kzddj(1, 4) = "faz"

jzs quwtfygz = quwzekzd.fkslizkzdd.zysltztqm
quwtfygz.jqts quwtfygz, edfjkzyrlyg, , , , , , edyq, , , edjqtstqmj

Der Scripting Perplexer von Dr. Scripto
Antwort: Rätselhaftes Skript, März 2008
Hier ist der Schlüssel zum Decodieren des Skripts:
Actual Letter	a	b	c	d	e	f	g	h	i	j	k
Coded Letter	f	u	k	r	z	b	g	o	l	w	x

Actual Letter	l	m	n	o	p	q	r	s	t	u	v	w	x	y	z
Coded Letter	d	n	y	q	a	h	t	j	s	c	i	m	e	v	p
Und hier ist das eigentliche decodierte Skript:
Const xlAscending = 1
Const xlNo = 2
Const xlSortRows = 2

Set objExcel = CreateObject("Excel.Application")
objExcel.Visible = True

Set objWorkbook = objExcel.Workbooks.Add
Set objWorksheet = objWorkbook.Worksheets(1)

objWorksheet.Cells(1, 1) = "Cat"
objWorksheet.Cells(1, 2) = "Dog"
objWorksheet.Cells(1, 3) = "Bat"
objWorksheet.Cells(1, 4) = "Ape"

Set objRange = objExcel.ActiveCell.EntireRow
objRange.Sort objRange, xlAscending, , , , , , xlNo, , , xlSortRows

Die Scripting Guys von MicrosoftDie Scripting Guys von Microsoft arbeiten für Microsoft (oder sind zumindest dort angestellt). Wenn sie nicht gerade ihrem Hobby, dem Baseball (oder verschiedenen anderen Aktivitäten) nachgehen, betreiben sie das TechNet-Skriptcenter. Besuchen Sie es unter www.scriptingguys.com.


 Sicherheit auf dem Pr&#252;fstand: Verwenden des SCW unter Windows&#160;Server&#160;2008
Sicherheit auf dem Prüfstand
Verwenden des SCW unter Windows Server 2008
Jesper M. Johansson
Dieser Artikel basiert auf einer Vorabversion von Windows Server 2008. Die in diesem Artikel enthaltenen Informationen können jederzeit geändert werden.

2005 stellte Microsoft Windows Server 2003 SP1 zur Verfügung. Dieses Service Pack enthielt das erste rollenbasierte Sicherheitsverwaltungstool für Windows: den Sicherheitskonfigurations-Assistenten (SCW). Microsoft hat SCW in erster Linie als Tool zur Reduzierung der Angriffsfläche entwickelt. Der Zweck des Assistenten bestand darin, zu analysieren, welche Aufgaben Sie
auf Ihrem Computer durchführen, und die Unterstützung der erforderlichen Rollen automatisch zu konfigurieren, während nicht verwendete Rollen und Dienste deaktiviert wurden.
In Windows Server® 2008 ist SCW weiterhin enthalten, und der Assistent wurde mit neuen Rollen und durch die Integration in die neue Windows® Firewall aktualisiert. Es handelt sich jedoch nach wie vor um ein erweitertes Verwaltungstool.
Windows Server 2008 enthält außerdem das neue rollenbasierte Server-Manager-Tool sowie zugehörige Tools, nämlich die Assistenten zum Hinzufügen von Rollen und Features. Statt im alten Stil einzelne Komponenten über die Systemsteuerung „Windows-Komponenten hinzufügen/entfernen“ hinzuzufügen, verwenden Sie in Windows Server 2008 jetzt die Rollenverwaltungstools zum Konfigurieren des Servers. Byron Hynes erläutert diese Tools im Artikel „Konfigurieren von Rollen mit Server-Manager“, der ebenfalls in dieser Ausgabe des TechNet Magazins enthalten ist.
Die Assistenten zum Hinzufügen von Rollen und Features sind so ausgelegt, dass Ihr Server mit den richtigen Komponenten konfiguriert wird, um die von Ihnen ausgewählten Rollen zu unterstützen. Dazu wird die integrierte Firewall so konfiguriert, dass diese Rollen richtig funktionieren. Jetzt fragen Sie sich vielleicht, warum weiterhin Bedarf für SCW besteht. Es stimmt – viele Administratoren brauchen SCW wahrscheinlich nicht mehr. Es gibt jedoch zwei Personengruppen, für die SCW ein wertvolles Tool sein kann. Die erste Gruppe sind die äußerst Sicherheitsbewussten. Diese Personen wissen zu schätzen, auf welche Weise SCW eine höhere Ebene an Sicherheit bietet.
Sie können sich die Assistenten zum Hinzufügen von Rollen und Features als Tools vorstellen, die einen Standardserver so konfigurieren, dass er die von Ihnen gewünschten Rollen und Features sicher unterstützt. Andererseits wird Ihr Server mit SCW so konfiguriert, dass nur die von Ihnen gewünschten Rollen und Features unterstützt werden. SCW hat zudem einen pädagogischen Nutzen, da Sie im Endeffekt besser verstehen, wie der Server konfiguriert ist. Daher empfehle ich Ihnen das Ausführen von SCW, wenn der Server mit allen Rollen und Features konfiguriert ist.
Bei der zweiten Gruppe handelt es sich um Benutzer, die die Beziehungen zwischen den verschiedenen Komponenten verstehen möchten. SCW umfasst einen Satz XML-Dateien, die die Beziehungen zwischen Rollen und Features, Diensten und Netzwerkports dokumentieren. SCW ist ein sehr wertvolles Tool, wenn Sie einen Einblick erhalten möchten, was für verschiedene Komponenten erforderlich ist.
In diesem Artikel geht es darum, wie SCW funktioniert und wie Sie den Assistenten zum Schutz Ihres Servers einsetzen können. Es wird auch ein Vergleich zwischen SCW und den Server-Manager-Tools gezogen. Beachten Sie, dass dieser Artikel aus meinem Buch „Windows Server 2008 Security Resource Kit“ (Microsoft Press®, 2008) stammt.

Übersicht über den Sicherheitskonfigurations-Assistenten
Zu Anfang sollen einige Statistiken über die Angriffsfläche auf Windows Server 2008 vorgestellt werden. Noch bevor Sie einen Server durch Hinzufügen einer persönlichen Auswahl an Rollen und Features konfigurieren, verfügt er über ein relativ großes Dienstprofil. Standardmäßig verfügt Windows Server 2008 über 105 Dienste, von denen 42 automatisch gestartet werden, 55 auf manuellen Start festgelegt und 8 deaktiviert sind. Im Gegensatz dazu werden bei einer Neuinstallation von Windows Server 2003 R2 SP2 86 Dienste standardmäßig installiert. 34 dieser Dienste sind auf automatischen Start festgelegt, 32 werden bei Bedarf gestartet, und 20 sind deaktiviert.
Selbst wenn die Rollenmetapher und die Reduzierung von Standardrollen unterstützt wird, hat Windows Server 2008 nach wie vor einen größeren Speicherbedarf, und Sie müssen beim Absichern Ihrer Server besondere Sorgfalt walten lassen. SCW führt Sie durch das Erstellen einer benutzerdefinierten Sicherheitskonfiguration für Ihre jeweiligen Server.
SCW verfolgt bezüglich der Serverabsicherung einen völlig anderen Ansatz als vorhandene Tools. Der Assistent arbeitet mit einer Rollenmetapher zum Konfigurieren des Systems, um lediglich diese Rollen und so gut wie nichts anderes zu unterstützen. Obwohl SCW genau wie die Assistenten zum Hinzufügen von Rollen und Features beim Konfigurieren der Firewall hilft, deaktiviert dieser Assistent zudem unnötige Dienste und konfiguriert eine Reihe zusätzlicher Sicherheitseinstellungen. Während die Assistenten zum Hinzufügen von Rollen und Features nur in Windows integrierte Rollen installieren und konfigurieren können, ist SCW erweiterbar. Ein Entwickler oder Administrator kann eine benutzerdefinierte Rollen- oder Featurekonfigurationsdatei schreiben und SCW zum Konfigurieren jedes beliebigen Produkts einsetzen.
SCW ist so ausgelegt, dass der Assistent nach dem Installieren aller Rollen und Features verwendet wird, die auf dem Server gewünscht sind. Wenn zudem Anwendungen von Drittanbietern auf dem Server vorhanden sind, sollten diese ebenfalls vor dem Ausführen von SCW installiert werden.
Um aufzuzeigen, wie dies funktioniert, wurde ein Server mit drei Rollen (Anwendungsserver, DNS-Server und Webserver) und zwei Features (Microsoft ® .NET Framework 3.0 Features und Windows-Prozessaktivierungsdienst) konfiguriert. Dies ist kein besonders logischer Satz an Rollen und Features, aber ein gutes Beispiel für diese Erläuterung.
Um SCW zu starten, führen Sie den Assistenten vom Menü „Verwaltung“ aus. Sie sehen das Dialogfeld in Abbildung 1.
Abbildung 1 SCW stellt zunächst die Frage, was Sie tun möchten.
Abbildung 1 SCW stellt zunächst die Frage, was Sie tun möchten.
Im ersten Schritt wählen Sie aus, ob Sie eine neue Sicherheitsrichtlinie erstellen, eine vorhandene Richtlinie bearbeiten oder anwenden oder eine Richtlinie zurücksetzen möchten, damit wieder die ursprünglichen Einstellungen im System vorhanden sind. Die Auswahlmöglichkeiten erklären sich praktisch von selbst.
Wenn Sie sich für das Erstellen einer neuen Sicherheitsrichtlinie entscheiden, erstellt SCW die neue Richtlinie mithilfe eines Computers als Vorlage dafür, was die Richtlinie unterstützen muss. Der Assistent analysiert den Computer und stellt fest, welche Features und Rollen darauf unterstützt werden. Dadurch wird sichergestellt, dass sie funktionieren, aber auch, dass viele unnötige Features nicht aktiviert werden.
SCW kann auf einem Prototypmodell eingesetzt werden. Der Assistent verwendet XML-Dateien, um anzugeben, welche Dateien für die Rollen und Features installiert sind, welche Dienste konfiguriert sind und so weiter. Daher müssen auf dem Computer alle Komponenten installiert sein, für die Sie die Richtlinie entwickeln. Wenn Drittanbieterprogramme vorliegen, bei deren Installation SCW-Definitionen installiert werden, werden diese nahtlos integriert. Wenn die Drittanbieterprogramme jedoch keine SCW-Definitionen installieren, müssen diese manuell konfiguriert werden.
Wie Sie sehen, kann eine Richtlinie auf einem System erstellt und anschließend auf vielen Systemen angewendet werden. Wenn Sie ein Netzwerk mit vielen Systemen erstellen, sollten Sie zunächst Hostklassen definieren, die alle separat konfiguriert werden. Dann können Sie unter Verwendung einer dieser Klassen als Prototyp eine Richtlinie erstellen und die Richtlinie mit wenigen oder gar keinen Änderungen problemlos auf alle anderen Hostklassen anwenden.
Wenn Sie (im in Abbildung 1 dargestellten Dialogfeld) auf „Weiter“ klicken, fragt der Assistent, welchen Computer Sie als Baseline oder Prototyp für diese neue Richtlinie verwenden möchten. In der Regel wählen Sie den lokalen Computer aus, doch Sie können auch einen Remotecomputer als Prototyp verwenden.
Nach Angabe des zu verwendenden Systems beginnt die Analysephase. Dabei zählt SCW auf, welche Rollen und Features Sie installiert haben und gleicht diese anhand der Rollen- und Featuredatenbank ab. Die Datenbank enthält Informationen bezüglich der Dienste, die von der jeweiligen Rolle und dem jeweiligen Feature verwendet werden, welche Netzwerkports für sie erforderlich sind sowie andere wichtige Konfigurationsinformationen. Nach Abschluss der Analyse können Sie auf „Konfigurationsdatenbank anzeigen“ klicken, um die Ergebnisse des Sicherheitskonfigurations-Assistenten einzusehen. Beachten Sie, dass dies eine schreibgeschützte Ansicht ist, in der umfassende Informationen zur Konfiguration des Computers angezeigt werden. Wenn Sie wirklich verstehen möchten, was sich auf Ihrem Computer befindet, sollten Sie sich eingehend mit der Untersuchung dieser Informationen beschäftigen.

Konfigurieren Ihres Servers mit SCW
Wenn Sie auf „Weiter“ klicken, wird der erste von vier Abschnitten in SCW angezeigt: Rollenbasierte Dienstkonfiguration. Möglicherweise stellen Sie fest, dass es sich bei den in SCW vorhandenen Rollen, wie in Abbildung 2 dargestellt, nicht um denselben Rollensatz handelt, wie beim Assistenten „Rollen hinzufügen“. Die meisten Rollen, die im Assistenten „Rollen hinzufügen“ zur Verfügung stehen, sind hier ebenfalls vorhanden. SCW bietet darüber hinaus zusätzliche Rollen an, die nicht im Assistenten zum Hinzufügen von Rollen vorhanden sind. So ist beispielsweise die ausgewählte Anwendungsserverrolle nicht vorhanden. Dies liegt daran, dass SCW eine etwas andere Metapher für Rollen verwendet. Darauf wird gleich noch ausführlicher eingegangen.
Abbildung 2 Verwenden von SCW zum Auswählen der Rollen, die von Ihrem Server unterstützt werden sollen
Abbildung 2 Verwenden von SCW zum Auswählen der Rollen, die von Ihrem Server unterstützt werden sollen
Oft ist der richtige Rollensatz bereits im Dialogfeld ausgewählt. Überprüfen Sie einfach nur, ob die Analyse gefunden hat, was sie Ihrer Meinung nach hätte finden sollen. Wenn etwas nicht in Ordnung ist, überprüfen Sie, ob die Rolle installiert wurde, und installieren Sie sie ggf., bevor Sie SCW erneut ausführen. Wenn Sie einen Fehler machen, ist das kein Weltuntergang. Mit der Zurücksetzungsfunktion in SCW gelangen Sie wieder an den Ausgangspunkt, wobei von der Richtlinie vorgenommene Änderungen rückgängig gemacht werden.
Die Antworten, die Sie in diesem Abschnitt geben, sind sehr wichtig, da mit ihnen festgelegt wird, was Sie später im Netzwerkabschnitt sehen. Glücklicherweise ist die Erkennungslogik recht gut, und normalerweise wird der richtige Satz an Rollen ausgewählt.
Beachten Sie, dass Sie standardmäßig „Installierte Rollen“ sehen, bei denen es sich um die Rollen handelt, die der Server mit den auf dem Datenträger befindlichen Bits unterstützen kann. Bei den ausgewählten Rollen handelt es sich um die derzeit unterstützten Rollen. Sie können auch entscheiden, sich alle Rollen in der Datenbank anzeigen zu lassen. Dazu wählen Sie einfach „Alle Rollen“ in der Dropdownliste aus. Dies ist in erster Linie von Nutzen, wenn Sie eine Richtlinie mithilfe eines Prototypservers erstellen müssen, auf dem noch nicht alle erforderlichen Rollen installiert sind.
Nach der Rollenkonfiguration wählen Sie die Clientfeatures aus, die unterstützt werden sollen. Der Featuresatz ist ähnlich, aber nicht identisch mit dem Featuresatz im Assistenten zum Hinzufügen von Features, da weniger Features enthalten sind. Auch hier sind die Metaphern nicht genau gleich, und SCW kann erweitert werden, sodass sich die Anzeige vom Assistenten „Features hinzufügen“ unterscheidet.
Wenn Sie auf der Seite mit Clientfeatures in SCW auf „Weiter“ klicken, wird das Dialogfeld „Verwaltungs- und weitere Optionen auswählen“ angezeigt, wie in Abbildung 3 dargestellt. Eine Option in SCW steht für etwas, das nicht genau einer Rolle oder einem Feature zuzuordnen ist. Eine Option kann administrative Unterstützung bieten, oder es kann sich einfach um einen einzelnen Dienst handeln, beispielsweise um den Dienst zur Erkennung interaktiver Dienste. Auch hier sind die meisten von Ihnen benötigten Optionen wahrscheinlich bereits ausgewählt. Auf das Dropdownmenü sollte ebenfalls hingewiesen werden. Es ist mit Optionen aufgefüllt, die für die bereits von Ihnen ausgewählten Rollen und Features relevant sind, und ist somit auf verschiedenen Computern unterschiedlich.
Abbildung 3 Auswählen anderer Dienste und Features in SCW
Abbildung 3 Auswählen anderer Dienste und Features in SCW
Als Nächstes wird das Dialogfeld für das Auswählen zusätzlicher Dienste angezeigt. Obwohl SCW mit einer sehr großen Datenbank an Diensten ausgestattet ist, enthält sie nicht alle Dienstbeschreibungen. Die Dienste, die SCW auf einem Computer findet und die nicht in der Datenbank vorhanden sind, werden auf der Seite mit zusätzlichen Diensten angezeigt. Es sollte allerdings eine Dienstbeschreibung für alle integrierten Dienste vorhanden sein, und dieses Dialogfeld wird in der Regel nur angezeigt, wenn bei Ihnen ein Drittanbieterdienst installiert ist.
Mithilfe des Assistenten können Sie dann auswählen, was mit Diensten geschehen soll, die Sie nicht konfigurieren. Diese Option dient für den Fall, dass Sie planen, die Richtlinie, die gerade erstellt wird, auf einen anderen Computer anzuwenden. Wenn dieser Computer über andere Dienste verfügt als der, auf dem Sie die Richtlinie erstellt haben, muss SCW angewiesen werden, was mit diesen Diensten geschehen soll. Eine Option besteht darin, nichts zu unternehmen. Dies ist die Standardoption. Die andere Option besteht in ihrer Deaktivierung, was sicherer ist, aber zu Beschädigungen führen kann. Doch wenn Sie der Empfehlung folgen, nur Richtlinien auf Server anzuwenden, die identisch mit dem Server sind, auf dem sie erstellt wurden, ist eine Auswahl auf dieser Seite irrelevant.
Jetzt sind Sie mit der Rollenkonfiguration in SCW fertig, und der Assistent fasst die von Ihnen vorgenommenen Eingaben zusammen. Selbst wenn Sie sich nur durchklicken, wirkt sich dies wesentlich auf die Angriffsfläche des Computers aus, wie Sie in Abbildung 4 sehen können. Ein Beispiel: Da dieser Computer kein Druckserver ist und auf ihm keine Drucker installiert sind, gibt es keinen Grund, den Druckerwarteschlangendienst auszuführen. SCW deaktiviert alle Dienste, die nicht erforderlich sind. Auf dem Testserver für dieses Beispiel werden durch SCW 17 Dienste deaktiviert, die auf automatischen Start eingestellt waren, und 42 Dienste mit manuellem Start. Individuelle Ergebnisse hängen natürlich davon ab, wie der jeweilige Server konfiguriert ist, aber Sie können sehen, dass sich mithilfe von SCW eine Richtlinie leicht auf Ihre spezifischen Server zuschneiden lässt, wodurch die Angriffsfläche drastisch verringert wird.
Abbildung 4 SCW fasst die von Ihnen vorgenommenen Änderungen zusammen
Abbildung 4 SCW fasst die von Ihnen vorgenommenen Änderungen zusammen
Jetzt kommt der wohl wichtigste Abschnitt von SCW an die Reihe: das Netzwerk. Nach der Begrüßungsseite wird das Dialogfeld für Netzwerksicherheitsregeln angezeigt, das in Abbildung 5 dargestellt ist. Es enthält eine Liste aller Firewallregeln, die von SCW vorgeschlagen werden und auf der in den vorherigen Abschnitten ausgewählten Rollenunterstützung basieren.
Abbildung 5 SCW listet alle Regeln auf, die für Ihren Bedarf festgelegt wurden
Abbildung 5 SCW listet alle Regeln auf, die für Ihren Bedarf festgelegt wurden
Wenn im Netzwerkabschnitt keine weitere Konfiguration erfolgt, erstellt SCW Firewallregeln, die die Netzwerkschnittstellen sperren, sodass nur diese Rollen und Features unterstützt werden, aber alle Clients auf sie zugreifen können. Doch um die Sicherheit auf Ihren Servern wirklich zu optimieren, sollten Sie SCW als wesentlichen Bestandteil beim Erstellen einer Serverisolierungsstrategie einsetzen. Weitere Informationen zur Serverisolierung (und dem verwandten Prozess der Domänenisolierung) erhalten Sie unter technet.microsoft.com/network/bb545651.
Das Buch „Windows Server 2008 Security Resource Kit“ enthält ein Kapitel zum Sichern des Netzwerks durch Server- und Domänenisolierung. Hier wird auch erläutert, wie Sie die Netzwerkbedrohungsmodellierung zur Analyse Ihres Netzwerks verwenden können, um die Bereitstellung der Serverisolierung zu erleichtern. SCW ist bei diesem Prozess ein wertvolles Tool.
Sie können Einschränkungen für die vorgeschlagenen Regeln konfigurieren, indem Sie die Regel auswählen und auf „Bearbeiten“ klicken. Nun wird Ihnen das in Abbildung 6 dargestellte Dialogfeld angezeigt. Dies ist eine von vier Seiten, auf denen Sie weitere Einschränkungen der Netzwerkregeln festlegen können. So können Sie beispielsweise IPSec-Authentifizierung fordern. Auf Wunsch können Sie auch den Port nur mit bestimmten Endpunkten verknüpfen. Sie können ihn beispielsweise so konfigurieren, dass die Remoteverwaltung nur von bestimmten Hosts aus zulässig ist. Wie Sie sehen, ist dies ein wesentlicher Vorteil gegenüber den Assistenten zum Hinzufügen von Rollen und Features.
Abbildung 6 Mithilfe von SCW lassen sich eine Firewall und IPSec-Regeln erstellen
Abbildung 6 Mithilfe von SCW lassen sich eine Firewall und IPSec-Regeln erstellen
Die Möglichkeit, Regeln für die Verbindungssicherheit auf Grundlage der von Ihnen ausgewählten Rollen zu erstellen, erfüllt zwei wichtige Zwecke. Zum einen bietet sie eine hervorragende Gelegenheit, zu verstehen, was in Ihren Servern vor sich geht. Dazu ist es nicht einmal erforderlich, einen Server hinzuzufügen. Sie können einfach den Assistenten ausführen und verschiedene Auswahlmöglichkeiten treffen, um zu sehen, wie sie sich auf die Optionen auf späteren Seiten auswirken. Zum anderen können Sie das äußerst abstrakte Konzept eines Ports mit dem viel logischeren Konzept eines Dienst verknüpfen und Netzwerkeinschränkungen genau auf der Grundlage dessen konfigurieren, was das System tatsächlich vornimmt.
Wenn dies richtig durchgeführt wird, können Sie für Ihre Server eine äußerst knappe Konfiguration entwickeln. Beim Erstellen der Sicherheitsrichtlinie für Ihre Server sollten Sie dem Netzwerkabschnitt von SCW zweifellos den größten Teil Ihrer Zeit widmen.
Im restlichen Teil von SCW können Sie Überwachungs- sowie eine Reihe von Registrierungseinstellungen konfigurieren. Die Standardeinstellungen dieser Parameter sind für die meisten Organisationen angemessen, und wenn Sie keine besonderen Anforderungen haben, bleibt hier nicht viel zu tun.
Nach Erstellen der Richtlinie können Sie diese speichern und auf den Computer anwenden, an dem Sie arbeiten. Außerdem können Sie sie auf andere Computer anwenden. Sie können die Richtlinie auch mithilfe des scwcmd.exe /transform-Befehls in ein Gruppenrichtlinienobjekt (Group Policy Object, GPO) umwandeln.
Doch wenn die Richtlinie computerspezifische Einstellungen enthält, gelingt dies möglicherweise nicht, oder es könnte zu äußerst merkwürdigen Ergebnissen kommen. Wenn Sie beispielsweise Endpunkteinschränkungen erstellen, die lokale Adapter im Netzwerkabschnitt enthalten, gilt die Richtlinie als computerspezifisch. In diesem Fall lässt sie sich nicht erfolgreich umwandeln. Dies ist auf die Tatsache zurückzuführen, dass die Adapter mithilfe von GUIDs angegeben werden müssen. Die GUID für einen Adapter auf einem Computer ist auf einem anderen Computer bedeutungslos.
Daher ist es oft besser, SCW für jeden Server einzeln sowie als Lernwerkzeug zu verwenden. Für große Serverfarmen können Sie SCW einsetzen, um mehr über die Computer zu erfahren und eine grundlegende Richtlinie zu entwickeln. Dann können Sie die Richtlinie neu erstellen und mit jedem beliebigen Tool einführen, das Sie zum Konfigurieren der Server verwenden, beispielsweise die Gruppenrichtlinie oder ein Enterprise Management-System (z. B. Microsoft System Center).

SCW im Vergleich zu Server-Manager
Wie bisher verdeutlicht wurde, unterscheidet sich die für Rollen und Features verwendete Metapher. Mithilfe von „Features“ in SCW kann der Computer als Client fungieren. „Rollen“ dagegen ermöglichen dem Computer, als Server zu fungieren.
Dies unterscheidet sich von der in den Server-Manager-Tools verwendeten Metapher, bei der eine Rolle eine Sammlung von Diensten und Features ist, die Sie sich als eine Einheit vorstellen können, während ein Feature zur Unterstützung von Rollen dient. Im Wesentlichen gilt eine Rolle in Server-Manager als das, wofür Sie den Server erworben haben. Features sind wichtig, bilden aber nicht die grundlegende Funktion, für die Sie den Server erworben haben. Die beiden Metaphern und die unterschiedliche Verwendung derselben Begriffe dürften verwirrend sein. Machen Sie sich die Unterschiede bewusst, bevor Sie von einem auf das andere Tool wechseln.
Außerdem sind die Server-Manager-Tools nicht erweiterbar. Sie dienen nur zum Verwalten der in Windows enthaltenen Komponenten. Im Gegensatz dazu können von Ihnen installierte Drittanbieterprogramme SCW Rollen und Features hinzufügen. Sie können sogar Ihre eigenen Rollen und Features schreiben. Im Whitepaper „Erweitern des Sicherheitskonfigurations-Assistenten“ (verfügbar unter go.microsoft.com/fwlink/?LinkId=107397) wird dies näher erläutert.
SCW deaktiviert außerdem nicht erforderliche Komponenten. Die Server-Manager-Tools andererseits stellen lediglich von Ihnen gewünschte Komponenten bereit. Sie haben keinerlei weitere Auswirkungen auf dem Computer. Wenn Sie beim Festlegen der erforderlichen Komponenten Hilfe benötigen, sollten Sie SCW verwenden.
Sowohl die Server-Manager-Tools als auch SCW können zwar zum Konfigurieren des Netzwerks eingesetzt werden, SCW ist jedoch in dieser Hinsicht weitaus leistungsfähiger. Wenn Sie eine Serverisolierungsstrategie hinzufügen, kann SCW eine wahre Goldgrube an Informationen sein und Ihre Bereitstellung optimal unterstützen. Hierbei geht es natürlich um ein erweitertes Thema für die Sicherheitsverwaltung, aber bei SCW handelt es sich ja auch um ein erweitertes Sicherheitstool.
Schließlich lassen sich mit SCW einige weitere Sicherheitseinstellungen konfigurieren, die von den Server-Manager-Tools nicht konfiguriert werden. Diese wurden jedoch in Windows Server 2008 größtenteils durch effektivere Steuerungen ersetzt oder bereits als Standardeinstellungen festgelegt.

Jesper M. Johansson ist Security Engineer, der an Problemen mit der Softwaresicherheit arbeitet und redaktionelle Beiträge für das TechNet Magazin schreibt. Er verfügt über einen PhD in MIS und kann auf mehr als 20 Jahre Erfahrung im Bereich Computersicherheit zurückblicken.


 Die Desktopdateien: Man kann nie zu reich oder zu d&#252;nn sein
Die Desktopdateien
Man kann nie zu reich oder zu dünn sein
Wes Miller

Wenn Sie je eine Microsoft-Zentrale besucht haben, sind Ihnen vielleicht die gemeinsam genutzten Kiosksysteme in den Empfangsbereichen der meisten Gebäude aufgefallen. Diese Systeme wurden mit einem webbasierten Front-End erstellt, das mit Windows-Terminaldiensten verbunden ist, damit Mitarbeiter, die zwischen verschiedenen Gebäuden unterwegs sind, ihre E-Mail-Nachrichten abrufen können und über weitere
Konnektivitätsfunktionen verfügen. Ursprünglich wurden sie unter Verwendung älterer PCs eingerichtet, die außer Dienst genommen und wiederverwertet wurden. Die Hardware, die für andere Zwecke zu langsam war, nicht über genug Speicher verfügte und unzulängliche Festplatten enthielt, eignete sich perfekt für Thin Client-Anwendungen. Wenn Sie aus irgendeinem Grund ältere Hardware haben, können Sie diese gut als Arbeitsstationen in Konferenzräumen, als Schulungscomputer und so weiter verwenden. Statt sie auf die Mülldeponie zu bringen, können Sie umweltbewusster handeln und gleichzeitig mehr Nutzen aus Ihren Investitionen ziehen.
Wenn Ihre Organisation ein Windows Vista®-Upgrade in Betracht zieht, stellen Sie möglicherweise fest, dass Ihre Hardware älter ist, als Sie gedacht haben. Beispielsweise könnte keine Unterstützung für das Trusted Platform Module (TPM) oder Aero® vorhanden sein. Wenn Ihre Systeme lediglich eine größere Festplatte oder mehr RAM benötigen, sollten Sie einfach die Hardware aktualisieren. Doch einige der vorhandenen Systeme werden einfach nicht in der Lage sein, Windows Vista auszuführen, da die Leistung der Hardware unzulänglich ist bzw. wichtige Funktionen fehlen. Das ist die perfekte Hardware für eine Ausführung als Windows® Thin Client. Abbildung 1 führt Windows Vista-Hardwareanforderungen auf, damit Sie wissen, wo Ihre aktuelle Hardware einzuordnen ist.
Figure 1 Windows Vista-Hardwareanforderungen (Close Figure 1)

Hardware | Anforderungen
CPU | 1 GHz min. wird empfohlen. Die CPU-Geschwindigkeit entscheidet möglicherweise über die Nutzbarkeit von Windows Vista. Eine langsame CPU mit einem Kernspeicher reicht nicht aus, kann aber einen hervorragenden Thin Client abgeben. Wenn Sie x64 in Betracht ziehen, ist eine Windows Vista-Hardwareaktualisierung der beste Zeitpunkt dazu. Gehen Sie zu x64 über, wenn Sie Ihre Hardware insgesamt aktualisieren.
Speicher | 1 GB min. wird empfohlen. Oft kann ein System um Speicher erweitert werden, doch überlegen Sie, ob es kostengünstig ist, Speicher auf Dutzenden, Hunderten oder Tausenden von Systemen zu installieren.
GPU | 128 MB + Grafikspeicher, DirectX® 9.0-fähig mit einem WDDM-Treiber und Pixel Shader 2.0-Unterstützung. Dies ist möglicherweise kein Dealbreaker, da hauptsächlich die Aero-Unterstützung eingeschränkt wird.
HDD | 40 GB min. Festplattenspeicher. Wahrscheinlich eher ein Problem bei mobilen Systemen als bei Desktops.
Treiberprobleme | Stehen Windows Vista-Treiber für die gesamte Hardware auf Ihren Systemen zur Verfügung?
TPM | Wenn Sie BitLocker-Unterstützung ohne ein USB-Flashlaufwerk wünschen, braucht Ihr Computer TPM 1.2-Hardware.

Wozu eignet sich ein Thin Client?
Mithilfe von alter Hardware und kleineren Betriebssystemen können Sie Kioske für allgemeine Bereiche/den Empfang erstellen, sodass die Benutzer E-Mail-Nachrichten abrufen können, so wie es in den Büros von Microsoft üblich ist. Sie können Systeme einrichten, auf denen Remotedesktop oder eine sorgfältig verwaltete Instanz von Internet Explorer® ausgeführt wird. Sie können Systeme für die Wiedergabe von Präsentationen in Konferenzräumen installieren, auf denen Microsoft PowerPoint® und Remotedesktop, aber praktisch nichts anderes ausgeführt wird. Außerdem können Sie Kombinationen aus alter Hardware/Thin Client für Verkaufsterminalsysteme oder Kioske für die Stellensuche verwenden. Welchen Thin Client sollten Sie dazu verwenden?

Windows XP Embedded
In früheren Artikeln wurde bereits erwähnt, wie Windows XP Embedded als formbare, komponentenbasierte Version von Windows XP entwickelt wurde. Wie in Don Jones Artikel vom April 2007 erläutert wurde (siehe technetmagazine.com/issues/2007/04/XPe), gibt es mehrere Tools, mit denen Sie Windows XP Embedded-Abbilder erstellen können. Das wichtigste dieser Tools ist Target Designer (siehe Abbildung 2). Target Designer ermöglicht Ihnen das Erstellen Ihres eigenen benutzerdefinierten Windows XP Embedded-Abbilds.
Abbildung 2 Windows XP Embedded Target Designer-Abbild
Abbildung 2 Windows XP Embedded Target Designer-Abbild
Beachten Sie, dass Target Designer mit mehreren Entwurfsvorlagen geliefert wird, um Ihnen den Start zu erleichtern. Selbstverständlich können Sie auch eigene Entwürfe erstellen, aber die Verwendung einer Vorlage erleichtert vieles. In Abbildung 2 sehen Sie die Kiosk-/Spielekonsolen- sowie die Windows-basierte Terminalvorlage, die ein guter Ausgangspunkt sind. Windows XP Embedded bietet zudem vollständige Geräteunterstützung und systemeigene Energieverwaltung, wie dies auch bei einem vollständigen Betriebssystemabbild der Fall wäre (Sie müssen einfach nur die Unterstützung hierfür in das Abbild integrieren). Natürlich brauchen Sie umso mehr Hardware, je mehr Features Sie hinzufügen. Daher ist es wichtig, die richtige Auswahl zu treffen. Auf der Microsoft-Website stehen viele Informationen zu Windows XP Embedded zur Verfügung: microsoft.com/windows/embedded/eval/xpe/default.mspx.

Windows Embedded for Point of Service
Windows Embedded for Point of Service (WEPOS) bietet eine vollständig standardisierte Vorlage für Point-of-Service (POS)-Systeme, die auf Windows XP erstellt wurden. WEPOS bietet integrierte Unterstützung für zahlreiche POS-verwandte Peripheriegeräte und ist hauptsächlich für die Verwendung im Einzelhandel und Gastgewerbe gedacht. Im Gegensatz zu Windows XP Embedded wird ein feststehender Satz an Funktionen geboten, die nur für diese Rolle entwickelt wurden und nicht im selben Umfang angepasst werden können wie Windows XP Embedded.
Die WEPOS-Plattform ist für ein äußerst minimales System ausgelegt, denn sie benötigt lediglich einen 233 MHz Pentium II- oder schnelleren Prozessor, 64 MB RAM und nur 280 MB für das Abbild des Kernbetriebssystems. Ausführliche Informationen zu WEPOS und Links zum Bestellen einer Testversion finden Sie unter microsoft.com/windows/embedded/wepos.

Windows Fundamentals für ältere PCs
Im Gegensatz zu Windows XP Embedded und WEPOS, die hauptsächlich für die Integration in ein Gerät durch einen Gerätehersteller entwickelt wurden, ist Windows Fundamentals für ältere PCs (Windows Fundamentals for Legacy PCs, FLP) als Komponente von Software Assurance lizenziert und wurde hauptsächlich zur Verwendung für genau dieses Szenario entwickelt. Abbildung 3 zeigt den Installationsbildschirm für Windows FLP, der dem Benutzer vier Konfigurationsoptionen zur Auswahl anbietet: Minimum, Standard, Vollständig und Benutzerdefiniert.
Abbildung 3 Windows FLP-Installation
Abbildung 3 Windows FLP-Installation
Für Windows FLP sind 64 MB RAM, 500 MB oder mehr Festplattenspeicherplatz und eine Bildschirmauflösung von 800 x 600 oder besser erforderlich. Die tatsächlichen Systemanforderungen für den Festplattenspeicherplatz können abhängig von den Betriebssystemkomponenten, für deren Installation Sie sich entscheiden, variieren.
Wenn Sie ein relativ flexibles, minimales Betriebssystem zur Verwendung auf älterer Hardware wünschen und Sie bereits über Software Assurance verfügen, dann ist Windows FLP eine gute Wahl. Unter microsoft.com/licensing/sa/benefits/fundamentals.mspx finden Sie weitere Informationen dazu, wie Windows FLP Ihnen eine reibungslose Migration zur neuesten Hardware und zum neuesten Betriebssystem bieten kann.

Optimiertes Windows XP
Neben diesen kleineren Versionen könnte sogar die vorliegende Variante von Windows XP perfekt geeignet sein. Wenn Ihnen nicht viel Arbeitsspeicher zur Verfügung steht, kann das Deaktivieren von Diensten wie Windows-Designs und anderen genug Kapazität einsparen, sodass das System eine angemessene Leistung aufweist. Sie sollten sich jedoch bewusst sein, was genau Sie deaktivieren, und dafür sorgen, dass die Sicherheit (beispielsweise durch Deaktivieren der Windows-Firewall) nicht beeinträchtigt wird.

Was nicht funktioniert
Leider wird oft versucht, für einfache Systeme eine Reihe anderer Optionen für Windows zu verwenden. Hier erfahren Sie, welches die offensichtlichsten Auswahloptionen sind und warum sie nicht so funktionieren, wie Sie es erwarten.
Windows XP Starter Edition ist für die Verwendung auf eingeschränkten Systemen optimiert, aber die Version wurde hauptsächlich für die Verwendung in Technologiemärkten konzipiert, die sich noch in der Entwicklung befinden. Sie ist nur als lizenzierte Windows-Kopie von einem OEM erhältlich, wenn sie für diese Märkte in einen neuen PC integriert ist. Daher ist dies in der Regel keine Option. Wenn Sie neugierig sind, können Sie hier mehr erfahren: microsoft.com/presspass/newsroom/winxp/WinXPStarterFS.mspx.
Windows PE ist ebenfalls keine geeignete Option. Interessanterweise wurde bei Microsoft während der Entwicklung von Windows PE anfänglich überlegt, ob es als einfaches Betriebssystem verwendet werden könnte. Doch letzten Endes wurde es nicht als einfaches Betriebssystem entwickelt, sondern als minimale Vorinstallationsumgebung für Bereitstellungszwecke. Windows PE hat beispielsweise keine Shell außer der Eingabeaufforderung (und das Hinzufügen einer funktionellen Shell ist nicht einfach). Zudem ist kein definierter API-Satz vorhanden, keine Energieverwaltung und keine Audiounterstützung.
Eine reduzierte Version von Windows XP ist ebenfalls keine gute Lösung. Mir ist als Vorschlag zur Ohren gekommen, dass die Verwendung einer reduzierten Windows-Version eine geeignete Option sei. Damit ist nicht das einfache Ausschalten oder Deaktivieren von Diensten gemeint, sondern das Entfernen von Anwendungen, um eine einfachere Windows-Installation zu erreichen. Von dieser Option rate ich sehr ab. Wenn Sie zur Vereinfachung Binärdateien aus Windows entfernen, besteht das Risiko, dass das System instabil oder unsicher wird. Wenn Sie eine kleinere Windows-Version benötigen, verwenden Sie Windows XP Embedded. Es dauert ein wenig, sich einzuarbeiten und das Abbild perfekt zu gestalten, doch die Version ist sehr leistungsfähig und wird selbstverständlich von Microsoft unterstützt.
Ähnlich wie die Verwendung einer minimierten Version von Windows XP mag sich die Verwendung einer älteren Version von Windows anbieten, doch der Mangel an Unterstützung, Updates und Sicherheit sollte Sie davon abhalten. Halten Sie sich bei Ihren einfacheren IT-Anforderungen an die von Microsoft bereits unterstützten Lösungen, und nutzen Sie alte Hardware bestmöglich, ohne die entsprechenden Funktionen oder die Sicherheit aufs Spiel zu setzen.

Wes Miller ist Senior Technical Product Manager bei CoreTrace (www.CoreTrace.com) in Austin, Texas. Zuvor war er bei Winternals Software und als Programmmanager bei Microsoft tätig. Sie können Wes Miller unter technet@getwired.com erreichen.


 Berichte aus der Praxis: Vorbereitung auf IT&#160;2.0
Berichte aus der Praxis
Vorbereitung auf IT 2.0
Romi Mahajan

In The Life of Reason schrieb der großartige Philosoph und Essayist Georges Santayana: „Wer sich der Geschichte nicht erinnert, ist dazu verdammt, sie zu wiederholen.“ Damit zeigte er auf, wie unglaublich wichtig es ist, aus vergangenem Unrecht zu lernen, um aktiv eine bessere Zukunft zu gestalten. Die Anwendung dieser Gedanken in der Welt von Politik, Kultur, Geschichte und sogar Wissenschaft ist klar. Tatsächlich ist die Idee, „aus Fehlern zu lernen“ so gängig, dass es schon ein Klischee ist. Doch wie viele von uns IT-Fachleuten denken wirklich über die Vergangenheit nach und lernen daraus? Wenn wir dies nicht tun, sind wir überhaupt auf die IT-Welt der Zukunft vorbereitet? Wie sieht diese zukünftige Welt eigentlich aus?
Lassen Sie uns kraft unseres Erinnerungsvermögens Vermutungen anstellen. Im Laufe der letzten 30 Jahre gab es umfassende Änderungen. IT hat sich von großen Mainframes zu browserbasiertem Computing entwickelt, von Gerätebündelung zu Geräteausbreitung, von Unreife und Seltenheit zu extremer Spezialisierung und Gewöhnlichkeit, von relativer Einfachheit zu außerordentlicher Komplexität. Daraus können wir ableiten, dass IT noch komplexer, noch spezialisierter und noch stärker demokratisiert wird. IT wird auch immer mehr und unterschiedliche Geräte unterstützen müssen, ebenso wie immer mehr und unterschiedliche Plattformen. All dies wird eine ausführlichere Planung erfordern als je zuvor.
Wurden diese Einsichten gemeinhin verinnerlicht? Nicht annähernd.
Betrachten Sie zum Beispiel die Unterhaltungen in einem Ausschuss, den ich kürzlich bezüglich der „Verbraucherfreundlichen Gestaltung der IT“ bei einer Technologiekonferenz im November 2007 leitete. Die Prämisse des Ausschusses war einfach, dass die Linien zwischen Geschäfts- und Verbrauchertechnologien verwischt worden sind, dass Verbraucheranwendungen und -geräte die Entwicklung von IT anführen und dass IT-Abteilungen sich auf die Familie der Phänomene einstellen müssen, die von den Facebooks, iTunes und BlackBerrys dieser Welt repräsentiert werden. Einfacher Gedanke? Offensichtlich? Alter Hut?
Na ja, der Reaktion der Personen im Raum nach zu urteilen überhaupt nicht. Von etwa 100 Anwesenden haben nur 4 erwähnt, dass sie „auf Facebook“ seien. „Das ist was für junge Leute“, sagte ein Teilnehmer. „Sind die Mitarbeiter, die Ihre IT-Abteilung unterstützt, nicht jung und auf Facebook?“ fragte einer unserer Diskussionsteilnehmer. Verwirrung und Ablehnung folgten. Nicht mehr als eine Handvoll der IT-Manager im Raum erachtete es als notwendig, ihre Organisationen durch das Einstellen von Personen auszubauen, die wissen, wie Anwendungen und Geräte auf den neuen Plattformen erstellt und unterstützt werden, die den Großteil der „Technologiezeit“ der Menschen in Anspruch nehmen.
Bei der Frage nach der Erstellung wirksamer IT-Richtlinien zur Regulierung der Verwendung und Sicherheit von Cross-over-Technologien wie Mobiltelefonen und Laptops, die sowohl zu Hause als auch für das Unternehmen genutzt werden, wurde die Menge laut, hatte aber keine wirklich konkrete Meinung. Eine Person brachte auf drakonische Weise, die typisch ist für IT 1.0, eine weit verbreitete Empfindung auf den Punkt: „Wenn jemand aus meinem Büro einen MP3-Player an einen Arbeitslaptop anschlösse oder ein für die Arbeit ausgegebenes Handy in einer Bar liegen ließe, würde ich ihn feuern.“
Aha. Nur zu.
Ein weiterer Bereich, in dem Sie diese Gedankenarmut erkennen können, ist die Trockenheit der Konferenzen für führende IT-Leute. Wenn ich noch eine Konferenzreihe sehe, die den vagen Konzepten „IT-Geschäftsausrichtung“ oder „Allgemeines Scorecarding“ gewidmet ist, werde ich wohl aufhören, zu reisen. Warum fragen nicht mehr Personen, wie IT 2.0 aussieht und was wir tun müssen, um einen Schritt voraus zu sein? Weshalb fragen wir nicht, welche Fähigkeiten und Einstellungen die neue Generation von IT-Experten benötigt, um eine dynamische Zukunft zu gestalten? Warum beklagen wir nicht die Tatsache, dass kein einziges Unternehmen seine IT-Abteilung in dem gleichen Licht sieht wie innovative Unternehmen ihre F&E-Abteilungen? Statt über Zentralisierung vs. Dezentralisierung zu debattieren, warum setzen wir uns nicht mit den wirklichen Problemen wie IT-Totalitarismus vs. IT-Demokratisierung auseinander?
Wir müssen uns selbst ein wenig mehr lieben, indem wir zeigen, dass uns unsere Zukunft am Herzen liegt. Wir haben alle von Web 2.0 gehört. Es ist an der Zeit, über IT 2.0 nachzudenken, wenn wir etwas verwirklichen wollen, das dem Potenzial der Technologie auch nur nahe kommt.

Romi Mahajan ist Direktor für das Technical Audience und Platform Marketing Team bei Microsoft. Von Romi Mahajan sind bereits in vielen Bereichen zahlreiche Veröffentlichungen erschienen, darunter Politik, Umwelt, Technologie und Soziologie.


 Windows Confidential: Wie aus Betaversionen Release Candidates wurden
Windows Confidential
Wie aus Betaversionen Release Candidates wurden
Raymond Chen

In den frühen Tagen von Windows® folgten Vorabversionen des Produkts mehr oder weniger einem Standardablauf. Zunächst gab es die Alphaversionen, die intern verwendet und möglicherweise mit Softwareentwicklungspartnern außerhalb des Windows-Produktteams gemeinsam verwendet wurden.
Den Alphaversionen folgen natürlicherweise Betaversionen, die an ein etwas breiteres Publikum gesendet werden. Ein Hauptunterschied zwischen Alpha- und Betaversionsbenutzern besteht darin, dass Betaversionen Personen einbeziehen, die keine Softwareentwickler sind, wie Endbenutzer, die Vorabsoftware testen möchten, und Unternehmen, die einen Vorsprung bei der Bewertung des Betriebssystems wünschen, um die Kompatibilität des neuen Produkts nicht nur mit ihren wichtigen betriebsinternen Anwendungen zu testen, sondern auch mit ihrem Unternehmensnetzwerk, mit Standardhardwarekonfigurationen und Systemverwaltungstools.
Schließlich gab es Release Candidates. Dabei handelte es sich, wie der Name schon sagt, um Versionen des Codes, die Kandidaten für eine endgültige Veröffentlichung waren. Anders gesagt: „Wenn alles gut geht, liefern wir dieses Prachtstück.“ Falls ein schwerwiegender Fehler gefunden wurde, der diese Erwartung zunichte machte, wurde sofort nach Behebung dieses Fehlers ein neuer Release Candidate-Build erstellt, und der Testzyklus wurde neu gestartet. Windows 95 wurde in Form seines sechsten Release Candidate ausgeliefert.
Mir kam zu Ohren, dass die Leute von Windows NT® demselben Versionsbenennungsschema folgten, aber dabei auf ein Problem stießen: Unternehmen machten sich nicht die Mühe, ihre wichtigen Anwendungen mit den Betaversionen von Windows NT zu testen. Die Logik dahinter sah für gewöhnlich folgendermaßen aus: „Warum die Mühe machen? Es ist nur eine Betaversion. Betaversionen sind für Computerfreaks. Es wird sowieso alles anders sein in der endgültigen Version. Jegliche Tests, die wir jetzt durchführen, wären verschwendete Zeit.“
Ähnlich kümmerten sich Softwareunternehmen nicht um Probleme, die während der Betatests von Windows NT auftraten. „Wir unterstützen keine Betabetriebssysteme“, war die gängige Antwort.
Diese Unternehmen begannen mit ernsthaften Tests, nachdem die eigentlichen Release Candidate-Builds auf den Markt kamen, und sie fanden unvermeidlicherweise einen Haufen Probleme. Bei einigen handelte es sich um Probleme, die die Unternehmen selbst beheben konnten, während andere Probleme darauf zurückzuführen waren, dass Windows NT nicht „kompatibel genug“ mit der früheren Version des Betriebssystem war. Es gab kleinere Probleme mit der Art und Weise, in der ein bestimmtes Projektfeature funktionierte, und einige davon konnten manchmal innerhalb kurzer Zeit gelöst werden. Einige Probleme waren jedoch so schwerwiegend, dass die Veröffentlichung des Produkts verschoben werden musste, damit das Team das Problem lösen konnte.
Diese Release Candidate-Builds führten außerdem zu einer Reihe von Vorschlägen. Wir erhielten Feedback wie z. B. „Wir denken, die Benutzeroberfläche würde besser aussehen, wenn Sie die Schaltflächen so anordnen“ und „ein Neuformulieren dieser Nachricht würde unsere Mitarbeiter weniger verwirren“. Dies wären großartige Vorschläge gewesen, wenn sie während der Betaphase gemacht worden wären, jedoch zu dem Zeitpunkt, an dem der erste Release Candidate ausgeliefert wird, ist es viel zu spät, Änderungen am Design der Benutzeroberfläche vorzunehmen. Die Dokumentation und die Hilfedateien wurden bereits geschrieben, das Produkt wurde in dutzende von Sprachen übersetzt, und die Bildschirmfotos für das Handbuch und die Produktverpackung waren bereits entworfen, abgestimmt und gedruckt worden. All diese Arbeit wird nicht einfach über den Haufen geworfen und noch einmal durchgeführt, nur um eine Schaltfläche zu verschieben.
Ich erinnere mich an eine Besprechung während der Ära von Windows XP, während der eine dieser Last Minute-Änderungen debattiert wurde. Die vorgeschlagene Änderung hätte erfordert, dass eine 20 KB-Hilfedatei verändert würde, damit die Anweisungen der neuen Benutzeroberfläche entsprächen. Der Lokalisierungs- und Übersetzungsexperte informierte uns, dass ein Neuübersetzen der geänderten Hilfedatei in der extrem knappen zur Verfügung stehenden Zeit hunderttausende Dollar kosten würde.
Um der Auffassung entgegenzuwirken, dass Betaversionen nicht zählen, machte das Windows NT-Team Gebrauch von einer Bezeichnungsinflation. Es gibt nach wie vor Betaversionen, die späten Betaversionen jedoch – wenn noch Zeit ist (jedoch nicht viel), etwas Feinabstimmung durchzuführen – werden nun Release Candidates genannt, und was früher als Release Candidates galt, sind nun Escrowbuilds. Der Begriff „Escrow“ (Geld oder ein Objekt, das von einem Dritten treuhänderisch verwaltet und nur bei Erfüllung bestimmter Voraussetzungen freigegeben wird) ist gut geeignet, den wirklichen Status des Builds zu vermitteln: „Es ist abgeschlossen, und wir werden es nur anrühren, wenn es sich um einen echten Notfall handelt.“

Raymond Chen befasst sich auf seiner Website „The Old New Thing“ und in seinem gleichnamigen Buch (Addison-Wesley, 2007) mit der Geschichte von Windows und mit der Win32-Programmierung.