 TechNet Magazine April 2007

TechNet Magazine April 2007

Windows-Verwaltung: Einblick in den Windows Vista-Kernel: Teil 3

In dieser Ausgabe wird die ausführliche Besprechung der neuen Elemente im Windows Vista-Kernel fortgesetzt. In diesem letzten Teil geht es um Änderungen und neue Features in Bezug auf Zuverlässigkeit, Wiederherstellung und Sicherheit.

Mark Russinovich Windows-Verwaltung: Notfallwiederherstellung: Active Directory-Benutzer und -Gruppen

Die Datenwiederherstellung in Active Directory kann sehr komplex sein. Es ist jedoch wichtig, dass Sie über einen Wiederherstellungsplan verfügen. Hier erfahren Sie, wie Objekte in Active Directory gespeichert, gelöscht, wiederhergestellt und repliziert werden, damit Sie beim nächsten unbeabsichtigten Löschen eines Benutzers oder einer Gruppenmitgliedschaft gut vorbereitet sind.

Gil Kirkpatrick Windows-Verwaltung: Gute Gründe für Windows XP Embedded

Auch wenn Sie es vielleicht nicht wissen: Windows XP Embedded könnte sich ideal in den IT-Bestand Ihres Unternehmens eingliedern. Erfahren Sie, wie Sie mit Windows XP Embedded den Verwaltungsaufwand mindern, Einsparungen realisieren und die Sicherheit erhöhen.

Don Jones Verwaltung: Vorausplanen mit System Center Capacity Planner

Unzureichende Hardware führt zu langen Antwortzeiten, während zu viel Hardware eine Verschwendung von Budgets und Verwaltungsressourcen nach sich zieht. Erfahren Sie, wie Sie Ihr Netzwerk mit System Center Capacity Planner modellieren und Ihre Infrastrukturbedürfnisse präzise einschätzen.

John Savill Verwaltung: Erweiterte Clientinventuren mit SMS

Standardmäßig sammelt Microsoft Systems Management Server 2003 eine Menge an Informationen, jedoch nicht annähernd soviel, wie Sie möglicherweise benötigen. Finden Sie heraus, wie die richtige Kombination aus Skripting, WMI und SMS-Kenntnissen Ihnen bei der Erweiterung von SMS-Beständen für die Sammlung und Berichterstattung beliebiger Informationen behilflich sein kann.

Wes Dobry Verwaltung: Bereitstellen von benutzerdefinierten Softwareupdates mit SMS 2003 R2

Mit Systems Management Server 2003 R2 können Sie benutzerdefinierte Updates mithilfe von verwalteten Aktualisierungsfunktionen bereitstellen. Informieren Sie sich über zwei neue Tools (das Inventurtool und das Veröffentlichungstool für benutzerdefinierte Updates), mit denen Sie eigene Updates sowie Updates von Drittentwicklern bereitstellen können.

Steve Rachui Mitteilung der Redaktion: Stimmt da etwas nicht ...?

Joshua Trupin Toolbox: Neue Produkte für IT-Profis

Greg Steen SQL – Fragen & Antworten: Neuerstellen von Indexen, Warteschlangenlänge des Datenträgers und mehr

Edited by Nancy Michell Schwerpunkt Dienstprogramme: Autoruns

Die schier unüberschaubare Anzahl von Anwendungen, die automatisch beim Systemstart ausgeführt werden, kann zu erheblichen Kopfschmerzen führen. Mithilfe von Autoruns lassen sich alle automatisch ausgeführten Anwendungen untersuchen, sodass Sie Konflikte beheben, schädliche Programme (Malware) aufspüren und nicht zuletzt Systemressourcen freigeben können.

Lance Whitney The Cable Guy: Einstellungen der Drahtlosnetzwerk-Gruppenrichtlinie für Windows Vista

Hier erfahren Sie, wie drahtlose Netzwerkeinstellungen an allen Computern in Ihrem Active Directory-Netzwerk mithilfe von Gruppenrichtlinien zentral konfiguriert und verteilt werden können.

Joseph Davies Windows PowerShell: Filtern und Formatieren von Daten

Windows PowerShell ermöglicht den unkomplizierten Zugriff auf große Mengen von Daten. Im Rohzustand sind diese Daten allerdings nicht für typische Geschäftszwecke geeignet. Hier erfahren Sie, wie Sie die gesammelten Daten durch Filtern, Festlegen von Eigenschaften und Formatierung an Ihre individuellen Bedürfnisse anpassen.

Don Jones Hey, Scripting Guy!: Lokale Benutzer und Gruppen naiv übernehmen

Wie es scheint, hat schon eine Unmenge Leute danach gefragt. Jetzt zeigen Ihnen die Scripting Guys endlich, wie lokale Benutzer und Gruppen mithilfe von Skripts verwaltet werden können.

The Microsoft Scripting Guys Sicherheit auf dem Prüfstand: Der Sicherheitskonfigurations-Assistent

Der Sicherheitskonfigurations-Assistent bietet eine effiziente Möglichkeit zum Sichern Tausender von Servern über unterschiedliche geografische Standorte hinweg. In diesem Artikel finden Sie alle erforderlichen Informationen zum Absichern Ihrer Server sowie zum Reduzieren der Angriffsfläche auf Grundlage der jeweiligen Serverrollen.

John Morello Die Desktopdateien: Wenn ich x64 bin

Informieren Sie sich über die Implementierung von Windows XP und Windows Server 2003 auf x64-Systemen und über die Vorteile und Hindernisse, die bei der Bereitstellung zu erwarten sind. Machen Sie sich mit der Unterstützung, Migration und Bereitstellung von Windows Vista x64 vertraut.

Wes Miller Inside Microsoft.com: Verwenden von Active Directory Federation Services

Microsoft bietet ein Extranet für Geschäftspartner, bei dem jeder externe Benutzer über ein einmaliges Domänenkonto verfügt. Hier erfahren Sie, wie Microsoft mithilfe von Active Directory Federation Services erhöhte Benutzerfreundlichkeit bei gleichzeitiger Rationalisierung des Verwaltungsaufwands erzielen will.

Jim Guthrie Berichte aus der Praxis: Freud und Leid des Lernens

Wenn die Freude darüber nachlässt, dass Sie eine Technologie als Vorreiter eingesetzt haben, sollten Sie bedenken, dass sich diese Technologie mit erhöhtem Wissen leichter anwenden und unterstützen lässt. Als IT-Fachleute müssen wir beständig mit neuen Produkten weiterexperimentieren. Dabei kann man oft noch eine ganze Menge lernen.

Mark D. Scott Windows Confidential: Die Kraft des Fehlers

Warum sollte man einen Fehler aktivieren wollen? Bestimmte Anwendungen bauen tatsächlich auf einem Fehler im Betriebssystem auf. Wird der Fehler behoben, stürzt die Anwendung ab.

Raymond Chen


 Windows-Verwaltung: Einblick in den Windows&#160;Vista-Kernel: Teil&#160;3
Windows-Verwaltung Mark Russinovich

Einblick in den Windows Vista-Kernel: Teil 3
Kurz zusammengefasst:
  • Zuverlässigkeit
  • Wiederherstellung
  • Sicherheit

In dieser Serie wurden bisher Verbesserungen beim Windows Vista-Kernel im Zusammenhang mit Prozessen, E/A, Speicherverwaltung, Systemstart, Herunterfahren und Energieverwaltung behandelt. Dieser dritte und letzte
Teil dreht sich um Features und Verbesserungen in den Bereichen Zuverlässigkeit, Wiederherstellung und Sicherheit.
Ein Feature, das ich in dieser Serie nicht behandle, ist die Benutzerkontensteuerung (User Account Control, UAC), die verschiedene Technologien umfasst, unter anderem die Virtualisierung von Dateisystem und Registrierung bei Legacyanwendungen, Zustimmung für den Zugriff auf Administratorrechte sowie den Windows®-Integritätsebenenmechanismus zum Isolieren von Prozessen, die mit Administratorrechten von weniger privilegierten Prozessen im selben Konto ausgeführt werden. In einer zukünftigen Ausgabe des TechNet Magazins werde ich die UAC-Internals ausführlich behandeln.
Windows Vista™ verbessert die Zuverlässigkeit Ihres Systems und die Fähigkeit, System- und Anwendungsprobleme mithilfe einer Reihe neuer Features und Verbesserungen zu diagnostizieren. Die Kernelprotokollierung „Ereignisablaufverfolgung für Windows“ (Event Tracing for Windows, ETW) ist immer aktiv und generiert Ablaufverfolgungen für Datei, Registrierung, Interrupt und andere Arten von Aktivitäten in einem Umlaufpuffer. Beim Auftreten eines Problems kann die neue Windows-Diagnoseinfrastruktur (WDI) einen Snapshot des Puffers aufzeichnen und diesen lokal analysieren oder zur Problembehandlung zum Microsoft-Support hochladen.
Die neue Windows-Zuverlässigkeits- und Leistungsüberwachung hilft Benutzern, Fehler wie z. B. Abstürze mit Änderungen an der Systemkonfiguration in Verbindung zu bringen. Das leistungsfähige System Repair Tool (SRT) ersetzt die Wiederherstellungskonsole bei der Offlinewiederherstellung von nicht startbaren Systemen.
Es gibt drei Bereiche, die Änderungen am System auf Kernelebene erfordern und daher in diesem Artikel näher betrachtet werden sollten: Kerneltransaktions-Manager (KTM), verbesserte Absturzbehandlung und das Feature „Vorherige Versionen“.

Kerneltransaktions-Manager
Einer der aufwändigeren Aspekte der Softwareentwicklung ist die Behandlung von Fehlern. Dies gilt besonders dann, wenn beim Durchführen eines Vorgangs auf höchster Ebene eine Anwendung eine oder mehrere Teilvorgänge abgeschlossen hat, die zu Änderungen im Dateisystem oder in der Registrierung führen. Der Softwareaktualisierungsdienst einer Anwendung könnte beispielsweise mehrere Registrierungsaktualisierungen vornehmen, die ausführbaren Dateien der Anwendung ersetzen und dann beim Aktualisierungsversuch für eine zweite ausführbare Datei keinen Zugriff mehr erhalten. Wenn der Dienst die Anwendung nicht im daraus resultierenden inkonsistenten Zustand belassen will, muss er alle bereits durchgeführten Änderungen nachverfolgen und rückgängig machen. Das Testen des Wiederherstellungscodes nach Fehlern ist schwierig und wird daher oft ausgelassen. Mögliche Fehler im Wiederherstellungscode machen daher jeden Wiederherstellungsversuch zunichte.
Für Anwendungen, die für Windows Vista geschrieben wurden, können bei sehr geringem Aufwand mithilfe der neuen Transaktionsunterstützung in NTFS und der Registrierung mit dem Kerneltransaktions-Manager automatische Funktionen zur Wiederherstellung nach Fehlern hinzugefügt werden. Wenn eine Anwendung eine Reihe von aufeinander bezogenen Änderungen vornehmen will, kann sie entweder eine DTC-Transaktion (Distributed Transaction Coordinator) und ein KTM-Transaktionshandle erstellen oder direkt ein KTM-Handle erstellen und die Änderungen der Dateien und Registrierungsschlüssel der Transaktion zuordnen. Wenn alle Änderungen erfolgreich sind, übergibt die Anwendung die Transaktion, und die Änderungen werden angewendet. Bis zu diesem Punkt kann die Anwendung die Transaktion jedoch jederzeit zurücksetzen, sodass die Änderungen zurückgewiesen werden.
Ein weiterer Vorteil besteht darin, dass andere Anwendungen die in einer Transaktion vorgenommenen Änderungen erst sehen, wenn die Transaktion übergeben wird. Anwendungen, die den DTC in Windows Vista und die zukünftige Windows Server®-Version mit dem Codenamen „Longhorn“ verwenden, können ihre Transaktionen mit SQL Server™, Microsoft® Message Queue Server (MSMQ) und anderen Datenbanken koordinieren. Ein Anwendungsaktualisierungsdienst, der KTM-Transaktionen verwendet, wird die Anwendung daher nie in einem inkonsistenten Zustand belassen. Aus diesem Grund verwenden sowohl Windows Update als auch die Systemwiederherstellung Transaktionen.
Als Kern der Transaktionsunterstützung ermöglicht KTM Transaktionsressourcenmanagern wie z. B. NTFS und der Registrierung, die Aktualisierungen für einen bestimmten Satz an von einer Anwendung durchgeführten Änderungen zu koordinieren. In Windows Vista verwendet NTFS eine Erweiterung zur Unterstützung von Transaktionen, die als TxF bezeichnet wird. Die Registrierung verwendet eine ähnliche Erweiterung mit der Bezeichnung TxR. Diese Kernelmodus-Ressourcen-Manager arbeiten mit dem KTM zusammen, um den Transaktionszustand zu koordinieren, ähnlich wie Benutzermodus-Ressourcen-Manager den DTC zum Koordinieren des Transaktionszustands über mehrere Benutzermodus-Ressourcen-Manager hinweg verwenden. Dritte können den KTM ebenfalls zum Implementieren ihrer eigenen Ressourcen-Manager verwenden.
Sowohl TxF als auch TxR definieren einen neuen Satz an Dateisystem- und Registrierungs-APIs, die vorhandenen ähnlich sind, aber zusätzlich einen Transaktionsparameter enthalten. Wenn eine Anwendung eine Datei innerhalb einer Transaktion erstellen will, verwendet sie zunächst KTM zum Erstellen der Transaktion und übergibt dann das resultierende Transaktionshandle an die zum Erstellen einer neuen Datei vorgesehene API.
TxF und TxR basieren auf der Funktion zur Hochgeschwindigkeitsdateisystemprotokollierung des gemeinsamen Protokolldateisystems oder CLFS (%SystemRoot%\System32\Clfs.sys), das in Windows Server 2003 R2 eingeführt wurde. TxR und TxF verwenden CLFS, um Änderungen am Transaktionszustand dauerhaft zu speichern, bevor sie eine Transaktion übergeben. So können sie Transaktionswiederherstellung und Zusicherungen selbst bei einem Stromausfall bereitstellen. Zusätzlich zum CLFS-Protokoll erstellt TxR einen Satz zugehöriger Protokolldateien zum Verfolgen von Transaktionsänderungen an der Registrierungsdatei des Systems in %Systemroot%\System32\Config\Txr, wie in Abbildung 1 dargestellt, sowie separate Sätze an Protokolldateien für jede Benutzerregistrierungsstruktur. TxF speichert Transaktionsdaten für jedes Volume in einem ausgeblendeten Verzeichnis in dem als $Extend\$RmMetadata bezeichneten Volume.
Abbildung 1 TxR-Protokolldateien der Systemregistrierungsstruktur
Abbildung 1 TxR-Protokolldateien der Systemregistrierungsstruktur

Verbesserter Support bei Abstürzen
Wenn in Windows ein nicht behebbarer Kernelmodusfehler auftritt (egal, ob dieser auf einen fehlerhaften Gerätetreiber, fehlerhafte Hardware oder das Betriebssystem zurückzuführen ist), wird versucht, die Beschädigung von Daten auf Datenträgern zu verhindern, indem das System nach Anzeige des berüchtigten blauen Absturzbildschirms angehalten wird. Bei entsprechender Konfigurierung wird der Inhalt eines Teils oder des gesamten physischen Speichers in eine Absturzsicherungsdatei geschrieben. Sicherungsdateien sind nützlich, da der OCA-Dienst (Microsoft Online Crash Analysis) bei einem Neustart nach einem Absturz eine Analyse dieser Dateien anbietet, um die Ursache zu ermitteln. Wenn Sie möchten, können Sie die Dateien auch selbst mithilfe der Microsoft-Debuggingtools für Windows analysieren.
In früheren Versionen von Windows wurde der Support für Absturzsicherungsdateien erst aktiviert, wenn der Sitzungs-Manager-Prozess (%Systemroot%\System32\Smss.exe) die Auslagerungsdateien initialisiert hatte. Dies bedeutete, dass kritische Fehler bis zu diesem Zeitpunkt zu einem blauen Bildschirm führten, ohne dass eine Sicherungsdatei erstellt wurde. Da der Hauptteil der Gerätetreiberinitialisierung vor dem Start von Smss.exe erfolgt, resultierten frühe Abstürze nie in Absturzsicherungsdateien, was die Diagnose der Ursache äußerst schwierig gestaltete.
Windows Vista verkürzt den Zeitraum, in dem keine Sicherungsdatei generiert wird, durch Initialisierung der Unterstützung für Sicherungsdateien, nachdem alle Systemstartgerätetreiber initialisiert wurden, jedoch vor dem Laden der Systemstarttreiber. Wenn es nun zu Beginn des Startprozesses zu einem Absturz kommt, kann das System aufgrund dieser Änderung eine Absturzsicherungsdatei erstellen, sodass OCA Ihnen beim Lösen des Problems helfen kann. Des Weiteren speichert Windows Vista Daten in einer Sicherungsdatei in Blöcken von 64 KB, während es bei früheren Windows-Versionen Blöcke von 4 KB waren. Diese Änderung führt zu größeren Sicherungsdateien, die bis zu zehnmal schneller geschrieben werden.
Das Behandeln von Anwendungsabstürzen wurde in Windows Vista ebenfalls verbessert. Bei früheren Windows-Versionen führte der Absturz einer Anwendung einen unbehandelten Ausnahmehandler aus. Der Handler startete den AER-Prozess (Microsoft Application Error Reporting) (%Systemroot%\System32\Dwwin.exe) und zeigte einen Dialog an, dass das Programm abgestürzt ist und ob Sie einen Fehlerbericht an Microsoft senden wollen. Doch wenn der Stapel des Hauptthreads des Prozesses während des Absturzes beschädigt wurde, stürzte der unbehandelte Ausnahmehandler während der Ausführung ab, was zur Beendigung des Prozesses durch den Kernel, das sofortige Verschwinden der Programmfenster und zur Nichtanzeige des Dialogs zur Fehlerberichterstattung führte.
Windows Vista verschiebt die Fehlerbehandlung aus dem Kontext des Absturzprozesse in einen neuen Dienst, die Windows-Fehlerberichterstattung (Windows Error Reporting, WER). Dieser Dienst wird von einer DLL (%Systemroot%\System32\Wersvc.dll) innerhalb eines Dienstshostprozesses implementiert. Wenn eine Anwendung abstürzt, führt sie immer noch einen unbehandelten Ausnahmehandler aus, doch dieser Handler sendet eine Nachricht an den WER-Dienst, und dieser Dienst startet dann den WER Fault Reporting-Prozess (%Systemroot%\System32\Werfault.exe) und zeigt den Dialog zur Fehlerberichterstattung an. Wenn der Stapel beschädigt ist und der unbehandelte Ausnahmehandler abstürzt, wird der Handler erneut ausgeführt und stürzt erneut ab, bis er schließlich den gesamten Stack des Threads (Scratchspeicherbereich) verwendet hat. Zu diesem Zeitpunkt greift der Kernel ein und sendet die Absturzbenachrichtigung an den Dienst.
Der Unterschied zwischen diesen beiden Ansätzen ist in Abbildung 2 und 3 dargestellt. Die Abbildungen zeigen die Prozessbeziehung von Accvio.exe, einem Testprogramm, das abstürzt, und die in Grün hervorgehobenen Fehlerberichterstattungsprozesse unter Windows XP und Windows Vista. Die neue Fehlerbehandlungsarchitektur von Windows Vista bedeutet, dass Programme nicht mehr ohne Warnung beendet werden, ohne dass die Möglichkeit besteht, einen Fehlerbericht an Microsoft zu senden, sodass Softwareentwickler ihre Anwendungen verbessern können.
Abbildung 2a Fehlerbehandlung bei Anwendungen unter Windows XP
Abbildung 2a Fehlerbehandlung bei Anwendungen unter Windows XP
Abbildung 2b
Abbildung 3a Fehlerbehandlung bei Anwendungen unter Windows Vista
Abbildung 3a Fehlerbehandlung bei Anwendungen unter Windows Vista
Abbildung 3b

Volumeschattenkopie
Unter Windows XP wurde eine Technologie mit der Bezeichnung Volumeschattenkopie eingeführt, um zu einem bestimmten Zeitpunkt Snapshots von Datenträgervolumes zu erstellen. Sicherungsanwendungen können diese Snapshots verwenden, um konsistente Sicherungsabbilder zu erstellen, doch ansonsten sind die Snapshots ausgeblendet und werden nur für die Dauer des Sicherungsprozesses beibehalten.
Die Snapshots sind nicht wirklich umfassende Kopien der Volumes. Sie sind vielmehr Ansichten eines Volumes zu einem früheren Zeitpunkt, die die mit Kopien von Volumesektoren überlagerten Livevolumedaten umfassen, die sich seit Erstellen des Snapshot geändert haben. Der Volume Snapshot Provider-Treiber (%Systemroot\%System32\Drivers\Volsnap.sys) überwacht Volumevorgänge und erstellt Sicherungskopien von Sektoren, bevor Änderungen an diesen zugelassen werden. Die ursprünglichen Daten werden in einer Datei gespeichert, die dem Snapshot im Verzeichnis „System Volume Information“ des Volumes zugeordnet ist.
Windows Server 2003 stellte Administratoren auf dem Server und Benutzern auf Clientsystemen die Snapshotverwaltung mit Schattenkopien von freigegebenen Ordnern zur Verfügung. Dieses Feature ermöglichte permanente Snapshots von Ordnern und Dateien in den Dateifreigaben des Servers, auf die die Benutzer über die Registerkarte „Vorherige Versionen“ in den Dialogfeldern für Explorer-Eigenschaften zugreifen konnten.
Das Feature „Vorherige Versionen“ bei Windows Vista stellt diesen Support für alle Clientsysteme zur Verfügung und erstellt automatisch Volumesnapshots (normalerweise einmal pro Tag), auf die Sie über die Explorer-Eigenschaftendialogfelder über dieselbe Schnittstelle zugreifen können, die von Schattenkopien für freigegebene Ordner verwendet wird. Dies ermöglicht Ihnen das Anzeigen, Wiederherstellen oder Kopieren alter Versionen von Dateien und Verzeichnissen, die Sie möglicherweise unbeabsichtigt geändert oder gelöscht haben. Während es sich aus technischer Sicht nicht um eine neue Technologie handelt, optimiert die Implementierung der Volumeschattenkopie unter Windows Vista mittels „Vorherige Versionen“ die Technologie von Windows Server 2003 bei Verwendung in Clientdesktopumgebungen.
Windows Vista nutzt Volumesnapshots außerdem, um Benutzer- und Systemdatenschutzmechanismen zu vereinheitlichen und das Speichern redundanter Sicherungsdaten zu vermeiden. Wenn eine Anwendungsinstallation oder Konfigurationsänderung falsche oder unerwünschte Verhaltensweisen verursacht, können Sie die Systemwiederherstellung verwenden, ein Feature, das in der Windows NT®-Reihe von Windows XP-Betriebssystemen eingeführt wurde, um den Zustand von Systemdateien und Daten wiederherzustellen, der beim Erstellen eines Wiederherstellungspunkts vorhanden war.
In Windows XP verwendet die Systemwiederherstellung einen Dateisystemfiltertreiber (ein Treibertyp, der Änderungen auf Dateiebene sehen kann), um Sicherungskopien von Systemdateien zum Zeitpunkt der Änderung zu erstellen. Bei Windows Vista verwendet die Systemwiederherstellung Volumesnapshots. Wenn Sie die Benutzeroberfläche für die Systemwiederherstellung in Windows Vista verwenden, um zu einem Wiederherstellungspunkt zurückzukehren, kopieren Sie im Grunde frühere Versionen der geänderten Systemdateien aus dem Snapshot, der dem Wiederherstellungspunkt zugeordnet ist, in das Livevolume.

BitLocker
Windows Vista ist die bisher sicherste Version von Windows. Neben dem Windows Defender-Antispywaremodul führt Windows Vista zahlreiche Sicherheits- und Tiefenverteidigungsfeatures ein wie beispielsweise die vollständige BitLocker™-Volumeverschlüsselung, die Codesignierung für Kernelmoduscode, geschützte Prozesse, Address Space Load Randomization und Verbesserungen bei der Windows-Dienstsicherheit und Benutzerkontensteuerung.
Ein Betriebssystem kann seine Sicherheitsrichtlinien nur durchsetzen, während es aktiv ist. Daher müssen Sie zusätzliche Maßnahmen ergreifen, um Daten zu schützen, wenn die physische Sicherheit eines Systems gefährdet ist und von außerhalb des Betriebssystems auf die Daten zugegriffen werden kann. Hardwarebasierte Mechanismen wie z. B. BIOS-Kennwörter und Verschlüsselung sind zwei häufig verwendete Technologien, um nicht autorisierten Zugriff besonders auf Laptops zu verhindern, bei denen die Wahrscheinlichkeit am größten ist, dass sie verloren gehen oder gestohlen werden.
Windows 2000 hat die Dateiverschlüsselung mit EFS (Encrypting File System) eingeführt. In der Windows Vista-Version umfasst EFS eine Reihe von Verbesserungen gegenüber früheren Implementierungen, einschließlich Leistungsverbesserungen, Support für das Verschlüsseln der Auslagerungsdatei und das Speichern von EFS-Schlüsseln von Benutzern auf Smartcards. Sie können EFS jedoch nicht verwenden, um den Zugriff auf vertrauliche Systembereiche wie z. B. die Registrierungsstrukturdateien zu schützen. Wenn Ihnen die Gruppenrichtlinie beispielsweise das Anmelden bei Ihrem Laptop selbst dann ermöglicht, wenn Sie nicht mit einer Domäne verbunden sind, wird die Überprüfung Ihrer Domänenanmeldeinformationen in der Registrierung zwischengespeichert, sodass Angreifer Tools verwenden könnten, um Ihr Kennworthash für das Domänenkonto zu erhalten, mithilfe dessen sie dann versuchen könnten, das Kennwort zu knacken. Mit dem Kennwort könnten Angreifer dann auf Ihr Konto und Ihre EFS-Dateien zugreifen (vorausgesetzt, Sie haben den EFS-Schlüssel nicht auf einer Smartcard gespeichert).
Um das Verschlüsseln des gesamten Startvolumes (das Volume mit dem Windows-Verzeichnis) einschließlich aller Systemdateien und Daten zu erleichtern, führt Windows Vista eine Feature für vollständige Volumeverschlüsselung mit der Bezeichnung Windows BitLocker-Laufwerkverschlüsselung ein. Im Unterschied zum EFS, das vom NTFS-Dateisystemtreiber implementiert wird und auf Dateiebene arbeitet, verschlüsselt BitLocker auf der Volumeebene mithilfe des FVE-Treibers (Full Volume Encryption, vollständige Volumeverschlüsselung) (%Systemroot%\System32\Drivers\Fvevol.sys) wie in Abbildung 4 dargestellt.
Abbildung 4 BitLocker FVE-Filtertreiber
Abbildung 4 BitLocker FVE-Filtertreiber
FVE ist ein Filtertreiber, d. h., er sieht automatisch alle E/A-Anforderungen, die vom NTFS an das Volume gesendet werden, wobei Blöcke mithilfe des Schlüssels zur vollständigen Volumeverschlüsselung (Full Volume Encryption Key, FVEK), der dem Volume bei der anfänglichen Konfiguration zur Verwendung von BitLocker zugewiesen wird, beim Schreiben verschlüsselt und beim Lesen entschlüsselt werden. Standardmäßig werden Volumes mit einem 128-Bit-AES-Schlüssel und einem 128-Bit-Diffusorschlüssel verschlüsselt. Da die Verschlüsselung und die Entschlüsselung unter dem NTFS im E/A-System erfolgt, scheint das Volume für NTFS unverschlüsselt zu sein, und NTFS muss nicht einmal wissen, dass BitLocker aktiviert ist. Wenn Sie versuchen, außerhalb von Windows Daten aus dem Volume zu lesen, scheint es sich um zufällige Daten zu handeln.
Der FVEK wird mit einem Volumehauptschlüssel (Volume Master Key, VMK) verschlüsselt und in einem speziellen Metadatenbereich des Volumes gespeichert. Bei der Konfigurierung von BitLocker stehen Ihnen je nach Hardwarefunktionen des Systems eine Reihe von Optionen zum Schutz des VMK zur Verfügung. Wenn das System über ein Trusted Platform Module (TPM) verfügt, das Version 1.2 der TPM-Spezifikation entspricht und über entsprechenden BIOS-Support verfügt, können Sie den VMK entweder mit dem TPM verschlüsseln, die Verschlüsselung des VMK über das System mithilfe eines im TPM und eines auf einem USB-Flashlaufwerk gespeicherten Schlüssels vornehmen oder den Schlüssel mithilfe eines im TPM gespeicherten Schlüssels und einer PIN verschlüsseln, die Sie beim Systemstart eingeben. Für Systeme, die nicht über ein TPM verfügen, bietet BitLocker die Option, den VMK mithilfe eines Schlüssels zu verschlüsseln, der auf einem externen USB-Flashlaufwerk gespeichert wird. Auf jeden Fall brauchen Sie ein unverschlüsseltes NTFS-Systemvolume von 1,5 GB Größe, bei dem es sich um das Volume handelt, in dem der Startmanager und die Startkonfigurationsdatenbank (Boot Configuration Database, BCD) gespeichert sind.
Der Vorteil bei Verwendung eines TPM besteht darin, dass BitLocker TPM-Funktionen verwendet, um sicherzustellen, dass der VMK nicht entschlüsselt und das Startvolume nicht entsperrt wird, wenn sich das BIOS oder die Systemstartdateien seit der Aktivierung von BitLocker geändert haben. Beim erstmaligen Verschlüsseln des Systemvolumes und jedes Mal, wenn Sie an einer der erwähnten Komponenten Aktualisierungen durchführen, berechnet BitLocker SHA-1-Hashes dieser Komponenten und speichert jeden Hash, der als Messung bezeichnet wird, in verschiedenen Plattformkonfigurationsregistern (PCR) des TPM mithilfe des TPM-Gerätetreibers (%Systemroot%\System32\Drivers\Tpm.sys). Er verwendet dann den TPM zum Versiegeln des VMK, ein Vorgang, bei dem ein privater, im TPM gespeicherter Schlüssel zum Verschlüsseln des VMK und der Werte verwendet wird, die in den PCRs zusammen mit anderen, von BitLocker an das TPM übergebenen Daten gespeichert sind. BitLocker speichert dann den versiegelten VMK und den verschlüsselten FVEK im Metadatenbereich des Volumes.
Wenn das System startet, misst es sein eigenes Hashing und den PCR-Code zum Laden und schreibt den Hash für das erste PCR des TPM. Es erstellt dann Hashwerte für das BIOS und speichert diese Messung im entsprechenden PCR. Das BIOS wiederum erstellt Hashwerte für die nächste Komponente in der Startsequenz, den Master Boot Record (MBR) des Startvolumes. Dieser Prozess wird fortgesetzt, bis der Betriebssystem-Lader gemessen ist. Jedes nachfolgende Codestück, das ausgeführt wird, ist für das Messen des Codes, das es lädt, und für das Speichern der Messungen im entsprechenden Register im TPM verantwortlich. Wenn der Benutzer schließlich entscheidet, welches Betriebssystem gestartet werden soll, liest der Startmanager (Bootmgr) den verschlüsselten VMK aus dem Volume und fordert das TPM auf, ihn zu entsiegeln. Nur wenn alle Messungen identisch mit den Messungen beim Versiegeln des VMK einschließlich der optionalen PIN sind, entschlüsselt das TPM den VMK erfolgreich.
Sie können sich dieses Schema als eine Überprüfungskette vorstellen, in der jede Komponente in der Startsequenz dem TPM die nächste Komponente beschreibt. Nur wenn alle Beschreibungen den ursprünglichen entsprechen, gibt das TPM sein Geheimnis preis. BitLocker schützt daher die verschlüsselten Daten, selbst wenn der Datenträger entfernt und in ein anderes System eingesetzt wird, das System mit einem anderen Betriebssystem gestartet wird oder die unverschlüsselten Dateien im Startvolume offen gelegt werden.

Überprüfen der Codeintegrität
Malware, die als Kernelmodusgerätetreiber implementiert wird, einschließlich Rootkits, wird auf derselben Berechtigungsstufe wie der Kernel ausgeführt, sodass sie besonders schwierig zu identifizieren und zu entfernen ist. Derartige Malware kann das Verhalten des Kernels und anderer Treiber so ändern, dass sie praktisch unsichtbar wird. Die Windows Vista-Codeintegrität für die Kernelmoduscodefunktion, die auch als Kernelmoduscodesignierung (KMCS) bezeichnet wird, lässt nur das Laden veröffentlichter und von Entwicklern digital signierter Gerätetreiber zu, wobei diese Entwickler von einigen wenigen Zertifizierungsstellen gründlich geprüft wurden. KMCS wird standardmäßig auf Windows Vista für 64-Bit-Systeme durchgesetzt.
Da Zertifizierungsstellen eine Gebühr für ihre Dienste erheben und grundlegende, eingehende Überprüfungen wie z. B. die Überprüfung der Identität eines Unternehmens durchführen, ist es schwieriger, anonyme Kernelmodusmalware herzustellen, die auf einem 64-Bit-Windows Vista-System ausgeführt wird. Wenn es Malware gelingt, den Überprüfungsprozess zu überwinden, hinterlässt sie potenziell Anhaltspunkte, die beim Entdecken der Malware auf einem gefährdeten System zum Autor zurückführen. KMCS bietet auch sekundäre Vorteile, beispielsweise die Bereitstellung der Kontaktinformationen für das Windows Online Crash Analysis-Team, wenn bei einem Treiber, der bei Kundensystemen zu Abstürzen führt, der Verdacht auf einen Fehler besteht, und das Entsperren von High Definition-Multimediainhalten, worauf im Folgenden näher eingegangen wird.
KMCS verwendet Kryptografietechnologien für öffentliche Schlüssel, die von Windows seit mehr als zehn Jahren eingesetzt werden, wobei der entsprechende Kernelmoduscode eine digitale Signatur umfassen muss, die von einer der vertrauenswürdigen Zertifizierungsstellen generiert wurde. Wenn ein Herausgeber dem Microsoft Windows Hardware Quality Laboratory (WHQL) einen Treiber sendet und der Treiber die Zuverlässigkeitstests besteht, ist Microsoft die Zertifizierungsstelle, die den Code signiert. Die meisten Herausgeber erhalten Signaturen über das WHQL, doch wenn ein Treiber nicht über ein WHQL-Testprogramm verfügt, der Herausgeber den Treiber nicht an das WHQL zu Testzwecken senden will oder der Treiber ein Systemstarttreiber ist, der jedes Mal beim Starten des Systems geladen wird, müssen die Herausgeber den Code selbst signieren. Dazu müssen sie zunächst ein codesigniertes Zertifikat von einer der Zertifizierungsstellen erhalten, die von Microsoft in Bezug auf die Kernelmoduscodesignierung als vertrauenswürdig identifiziert wurden. Der Autor versieht den Code dann digital mit einem Hashwert, signiert den Hash mit einem privaten Schlüssel und fügt das Zertifikat und den verschlüsselten Hash in den Code ein.
Beim Ladeversuch eines Treibers entschlüsselt Windows den im Code enthaltenen Hash mithilfe des im Zertifikat gespeicherten öffentlichen Schlüssels und überprüft dann, ob der Hash dem im Code enthaltenen entspricht. Die Echtheit des Zertifikats wird auf dieselbe Weise, aber mithilfe des öffentlichen Schlüssels der Zertifizierungsstelle geprüft, der in Windows enthalten ist.
Windows prüft auch, ob das zugeordnete Zertifikat mit einer der im Windows-Ladeprogramm und Betriebssystemkernel eingebetteten Stammzertifizierungsstellen verkettet ist. Versuche, einen nicht signierten 64-Bit-Treiber zu laden, sollten auf einem Produktionssystem nie stattfinden. Im Gegensatz zum Plug & Play-Manager, der einen Warndialog anzeigt, wenn er einen Treiber laden soll, der nicht über eine Signatur mit WQHL-Tests verfügt, schreibt ein 64-Bit-Windows Vista-System daher jedes Mal, wenn das Laden eines unsignierten Treibers gesperrt wird, im Hintergrund ein Ereignis in ein Anwendungsereignisprotokoll für Codeintegrität, ähnlich wie dem in Abbildung 5 dargestellten. 32-Bit-Windows Vista-Systeme prüfen die Treibersignaturen ebenfalls, lassen das Laden unsignierter Treiber jedoch zu. Bei einer Sperrung solcher Treiber würden aktualisierte Windows XP-Systeme beschädigt, bei denen auf Windows XP geladene Treiber erforderlich sind. Gleichzeitig wird der Support für Hardware ermöglicht, für die es nur Windows XP-Treiber gibt. Doch ein 32-Bit-Windows Vista-System schreibt Ereignisse ebenfalls in das Ereignisprotokoll für Codeintegrität, wenn es einen unsignierten Treiber lädt.
Abbildung 5 Ereignisse bei Ladeversuchen unsignierter Treiber
Abbildung 5 Ereignisse bei Ladeversuchen unsignierter Treiber
Da die Codesignatur häufig dazu dient, Code als streng getestete offizielle Veröffentlichung auszuweisen, wollen Herausgeber Code in der Regel keinen Signaturtests unterwerfen. Windows Vista verfügt daher über einen Testsignaturmodus, den Sie mit dem Bcdedit-Tool (das in meinem TechNet Magazin-Artikel im März 2007 beschrieben wurde) aktivieren bzw. deaktivieren können, wobei Kernelmodustreiber geladen werden, die digital mit einem Testzertifikat signiert werden, das von einer betriebsinternen Zertifizierungsstelle generiert ist. Dieser Modus ist für Programmierer während der Codeentwicklung gedacht. Wenn sich Windows in diesem Modus befindet, werden auf dem Desktop Markierungen wie jene in Abbildung 6 angezeigt.
Abbildung 6 Windows Vista-Testsignierungsmodus
Abbildung 6 Windows Vista-Testsignierungsmodus

Geschützte Prozesse
Multimediainhalte der nächsten Generation wie HD-DVD, BluRay und andere Formate, die unter dem AACS (Advanced Access Content System) lizenziert sind, werden sich in den nächsten Jahren immer mehr durchsetzen. Windows Vista verfügt über eine Reihe von Technologien, die zusammen als Protected Media Path (PMP) bezeichnet werden und die gemäß AACS-Standard zur Wiedergabe solcher Inhalte erforderlich sind. PMP umfasst Protected User-Mode Audio (PUMA) und Protected Video Path (PVP), die zusammen Mechanismen für Audio- und Videotreiber sowie für Anwendungen zur Medienwiedergabe bieten, um zu verhindern, dass nicht genehmigte Software oder Hardware Inhalte im High Definition-Format aufzeichnet.
PUMA und PVP definieren Schnittstellen und Support speziell für Audio- und Videoplayer, Gerätetreiber und Hardware, doch PMP benötigt auch einen allgemeinen Kernelmechanismus, der in Windows Vista eingeführt wurde und als geschützter Prozess bezeichnet wird. Geschützte Prozesse basieren auf dem Standard-Windows-Prozesskonstrukt, das ein ausführbares Abbild während der Ausführung, seine DLLs, den Sicherheitskontext (das Konto, unter dem der Prozess und seine Sicherheitsberechtigungen ausgeführt werden) sowie die Threads kapselt, die Code innerhalb des Prozesses ausführen, aber bestimmte Zugriffsarten verhindern.
Standardprozesse implementieren ein Zugriffssteuerungsmodell, das mit der Berechtigung „Debuggen von Programmen“ vollständigen Zugriff des Besitzers auf den Prozess und die Administratorkonten ermöglicht. Vollständiger Zugriff ermöglicht es einem Benutzer, den Adressraum des Prozesses einschließlich des Codes und der im Prozess abgebildeten Daten anzuzeigen und zu ändern. Benutzer können auch Threads in den Prozess einfügen. Diese Zugriffsarten stimmen nicht mit Anforderungen von PMP überein, da sie es nicht autorisiertem Code ermöglichen würden, Zugriff auf High Definition-Inhalte und DRM-Schlüssel (Digital Rights Management, digitale Rechteverwaltung) zu erhalten, die in einem Prozess gespeichert sind, der den Inhalt wiedergibt.
Geschützte Prozesse schränken den Zugriff auf einen begrenzten Satz von Informations- und Prozessverwaltungsschnittstellen ein, zu denen das Abfragen des Abbildnamens des Prozesses und das Beenden oder Anhalten des Prozesses gehören. Der Kernel stellt jedoch Diagnoseinformationen für geschützte Prozesse über allgemeine Prozessabfragefunktionen zur Verfügung, die Daten in Bezug auf alle Prozesse auf einem System zurückgeben und daher keinen Direktzugriff auf den Prozess brauchen. Zugriffe, die Medien gefährden könnten, werden nur von anderen geschützten Prozessen zugelassen.
Um interne Gefährdungen zu verhindern muss der gesamte ausführbare Code, der in einen geschützten Prozess geladen wird, einschließlich seines ausführbaren Abbilds und seiner DLLs entweder von Microsoft (WHQL) mit einem PE-Kennzeichen (Protected Environment) oder, wenn es sich um einen Audiocodec handelt, vom Entwickler mit einem DRM-signierten Zertifikat von Microsoft signiert werden. Da der Kernelmoduscode vollständigen Zugriff auf alle Prozesse, einschließlich geschützter Prozesse, erhalten kann und ein 32-Bit-Windows-System das Laden von unsigniertem Kernelmoduscode zulässt, stellt der Kernel eine API für geschützte Prozesse bereit, um die „Reinheit“ der Kernelmodusumgebung abzufragen und das Ergebnis nur dann zum Entsperren von hochwertigen Inhalten zu verwenden, wenn kein unsignierter Code geladen wurde.
Identifizieren eines geschützten Prozesses
Es gibt keine speziellen APIs, die geschützte Prozesse identifizieren, doch Sie können solche Prozesse indirekt über die wenigen für sie vorhandenen Informationen und aufgrund der Tatsache identifizieren, dass diese Prozesse selbst von einem Administratorkonto aus nicht debuggt werden können. Der Audio Device Graph Isolation-Prozess (%Systemroot%\System32\Audiodg.exe) dient zur Wiedergabe von CSS (Content Scramble System)-codierten DVDs und ist im Bereich „Task-Manager“ als geschützter Prozess aufgrund der Tatsache erkenntlich, dass der Task-Manager die Status für Befehlszeilen, Virtualisierung und Datenausführungsverhinderung selbst dann nicht beschaffen kann, wenn er mit Administratorrechten ausgeführt wird.
Task-Manager bei der Anzeige des geschützten audiodg-Prozesses
Task-Manager bei der Anzeige des geschützten audiodg-Prozesses

Address Space Load Randomization (Zufällige Anordnung beim Laden des Adressbereichs)
Trotz Maßnahmen wie der Datenausführungsverhinderung und verbesserter Überprüfung von Kompilierfehlern finden Autoren von Malware weiterhin Schwachstellen beim Pufferüberlauf, die es ihnen ermöglichen, Prozesse wie Internet Explorer®, Windows-Dienste und Drittanbieteranwendungen zu infizieren, um in einem System Fuß zu fassen. Doch selbst wenn es ihnen gelungen ist, einen Prozess zu infizieren, müssen sie Windows-APIs verwenden, um letztendlich ihr Ziel zu erreichen, d. h., um Benutzerdaten zu lesen oder eine permanente Präsenz durch Ändern von Benutzer- oder Systemkonfigurationseinstellungen herzustellen.
Das Verbinden einer Anwendung mit API-Einstiegspunkten, die von DLLs exportiert wurden, wird gewöhnlich vom Betriebssystem-Lader übernommen, doch diese Arten von Malwareinfektionen können die Vorteile der Laderdienste nicht nutzen. Dies war für Malware bei früheren Versionen von Windows kein Problem, weil bei jeder Windows-Veröffentlichung systemausführbare Abbilder und DLLs immer am gleichen Ort geladen wurden, sodass Malware annehmen konnte, dass sich die APIs an feststehenden Adressen befanden.
Mithilfe der Windows Vista-ASLR-Funktion (Address Space Load Randomization) ist es für Malware unmöglich zu wissen, wo sich die APIs befinden, da System-DLLs und ausführbare Dateien jedes Mal bei einem Systemstart an einem anderen Ort geladen werden. Zu Beginn des Startvorgangs wählt der Speicher-Manager einen zufälligen DLL-Bias zum Laden eines Abbilds unter einer von 256 an 64 KB ausgerichteten Adressen im oberen 16-MB-Bereich des Benutzermodusadressraums aus. Während DLLs, die das neue Kennzeichen für dynamisches Verschieben in ihrem Abbildheader enthalten haben, in den Prozess geladen werden, verpackt der Speicher-Manager sie in einem Speicher, wobei er mit der Biasadresse des Abbildladevorgangs beginnt und sich weiter nach unten vorarbeitet.
Ausführbare Dateien, bei denen das Kennzeichen gesetzt wurde, werden ähnlich behandelt und werden an einem zufälligen, an 64 KB ausgerichteten Punkt innerhalb von 16 MB der Adresse des Basisladevorgangs geladen, die in ihrem Abbildheader gespeichert ist. Wenn eine bestimmte DLL oder ausführbare Datei nach dem Entladen aus allen Prozessen, von denen sie verwendet wird, erneut geladen wird, wählt der Speicher-Manager erneut einen zufälligen Ort aus, an dem sie geladen wird. Abbildung 7 zeigt ein Beispiel für das Layout eines Adressbereichs für ein 32-Bit-Windows Vista-System einschließlich der Bereiche, in denen die ASLR die Bias- und ausführbare Ladeadresse des Abbildladevorgangs auswählt.
Abbildung 7 Die Wirkung von ASLR auf die ausführbare Datei und DLL-Ladeadressen
Abbildung 7 Die Wirkung von ASLR auf die ausführbare Datei und DLL-Ladeadressen
Nur Abbilder, bei denen das Kennzeichen für dynamische Verschiebung gesetzt wurde (dazu zählen alle Windows Vista-DLLs und ausführbaren Dateien), werden verlagert, da das Verschieben von Legacyabbildern bei internen Annahmen, von denen Entwickler bezüglich des Ladeorts ihrer Abbilder ausgegangen sind, zu Problemen führen könnte. Visual Studio® 2005 SP1 stellt Support zum Setzen des Kennzeichens zur Verfügung, sodass die Entwickler von Drittanbieteranwendungen ASLR umfassend nutzen können.
Die zufällige Anordnung von DLL-Ladeadressen an einem von 256 Orten macht es für Malware nicht unmöglich, den richtigen Ort einer API zu erraten, doch es hemmt die Geschwindigkeit, mit der sich ein Netzwerkwurm fortpflanzen kann, und hindert Malware daran, ihre einzige Chance zum Infizieren eines Systems wahrzunehmen. Zudem hat die Verschiebungsstrategie von ASLR den zusätzlichen Vorteil, dass Adressbereiche dichter gepackt sind als bei früheren Windows-Versionen, sodass größere Bereiche von freiem Speicher für zusammenhängende Speicherzuweisungen geschaffen werden. Dabei wird die Anzahl an Seitentabellen reduziert, die der Speicher-Manager zuweist, um das Layout des Adressbereichs verfolgen zu können und Fehlversuche des Übersetzungsnachschlagepuffers (Translation Lookaside Buffer, TBL) zu minimieren.

Verbesserungen bei der Dienstsicherheit
Windows-Dienste sind ideale Ziele für Malware. Viele bieten Netzwerkzugriff auf ihre Funktionen und legen möglicherweise den Zugriff auf ein System offen, was von einem Remotestandort ausgenutzt werden könnte. Zudem werden die meisten mit einer höheren Berechtigung als Standardbenutzerkonten ausgeführt, was bei einer Gefährdung durch Malware die Chance bietet, höhere Berechtigungen auf einem lokalen System zu gewähren. Aus diesem Grund begann Windows mit der Entwicklung von Änderungen, die bei Windows XP SP2 vorgenommen wurden. Berechtigungen und Zugriffe für Dienste werden nun ausschließlich auf Rollenbasis gewährt. So führte Windows XP SP2 beispielsweise die Konten „Lokaler Dienst“ und „Netzwerkdienst“ ein, die nur eine Teilmenge der Berechtigungen für das Konto umfassen, auf denen die Dienste bisher ausgeführt wurden – das lokale Systemkonto. Dies minimiert den Zugriff bei Angriffen auf einen Dienst.
ASLR in Aktion
Die Auswirkungen von ASLR werden offensichtlich, wenn Sie die DLL-Ladeadressen für einen Prozess in zwei verschiedenen Startsitzungen mithilfe eines Tools wie Process Explorer von Sysinternals vergleichen. In diesen beiden Screenshots aus zwei verschiedenen Sitzungen wurde Ntdll.dll im Explorer zuerst unter der Adresse 0x77A30000 und dann unter der Adresse 0x77750000 geladen.
Verschiedene Basisadressen für ntdll.dll
Verschiedene Basisadressen für ntdll.dll
Verschiedene Basisadressen für ntdll.dll
Verschiedene Basisadressen für ntdll.dll

Im vorherigen Artikel wurde beschrieben, wie Dienste isoliert von Benutzerkonten in ihrer eigenen Sitzung ausgeführt werden, doch Windows Vista erweitert die Nutzung des Prinzips der niedrigsten Berechtigungsebene noch, indem Berechtigungen und der Zugriff auf die Dateien, Registrierungsschlüssel und Firewallports, die den meisten Diensten zugewiesen werden, weiter reduziert werden. In Windows Vista ist ein neues Gruppenkonto definiert, das als Dienstsicherheits-ID (Security Identifier, SID) bezeichnet wird und für jeden Dienst eindeutig ist. Der Dienst kann Berechtigungen für seine Ressourcen festlegen, sodass nur seine Dienstsicherheits-ID Zugriff hat und andere Dienste, die unter demselben Benutzerkonto ausgeführt werden, am Datenzugriff gehindert werden, wenn ein Dienst offen gelegt wird. Sie können sich die SID eines Diensts mithilfe des sc showsid-Befehls, gefolgt vom Dienstnamen, anzeigen lassen, wie in Abbildung 8 dargestellt.
Abbildung 8: Anzeigen einer Dienstsicherheits-ID
Abbildung 8: Anzeigen einer Dienstsicherheits-ID
Dienstsicherheits-IDs schützen den Zugriff auf Ressourcen, die im Besitz eines bestimmten Diensts sind, doch standardmäßig haben Dienste immer noch Zugriff auf alle Objekte, auf die das Benutzerkonto zugreifen kann, unter dem sie ausgeführt werden. Ein Dienst, der beispielsweise als lokales Dienstkonto ausgeführt wird, kann möglicherweise nicht auf Ressourcen zugreifen, die von einem anderen, als lokaler Dienst in einem anderen Prozess ausgeführten Dienst erstellt wurden, der seine Objekte mit Berechtigungen geschützt hat, die auf eine Dienstsicherheits-ID verweisen. Er kann jedoch immer noch alle Objekte lesen und schreiben, für die der lokale Dienst (und alle Gruppen, denen der lokale Dienst angehört wie z. B. die Dienstgruppe) Berechtigungen hat.
Windows Vista führt daher einen neuen eingeschränkten Diensttyp ein, der als Dienst mit eingeschränktem Schreiben bezeichnet wird und für einen Dienst nur den Schreibzugriff auf Objekte zulässt, die für seine Dienstsicherheits-ID, die Benutzergruppe „Alle“ und die SID zugänglich sind, die der Anmeldesitzung zugewiesen wurden. Dazu werden eingeschränkte SIDs verwendet, bei denen es sich um einen in Windows 2000 eingeführten SID-Typ handelt. Wenn der Prozess, der ein Objekt öffnet, ein Dienst mit eingeschränktem Schreiben ist, ändert sich der Algorithmus zur Zugriffsüberprüfung, sodass eine SID, die einem Prozess weder in eingeschränkter noch uneingeschränkter Form zugewiesen wurde, nicht verwendet werden kann, um dem Prozess Schreibzugriff für ein Objekt zu gewähren. Mit dem folgenden Befehl können Sie feststellen, ob ein Dienst eingeschränkt ist:
sc qsidtype [service]
Eine weitere Änderung erleichtert es einem Dienst, andere Dienste, die unter demselben Konto ausgeführt werden, daran zu hindern, auf erstellte Objekte zuzugreifen. In früheren Windows-Versionen war der Ersteller eines Objekts auch sein Besitzer, und Besitzer können die Berechtigungen ihrer Objekte lesen und ändern, sodass sie vollständigen Zugriff auf ihre eigenen Objekte haben. Windows Vista führt die neue Sicherheits-ID für Eigentümerrechte ein, die bei Vorhandensein in den Berechtigungen eines Objekts den Zugriff eines Besitzers auf sein eigenes Objekt einschränken kann – sogar das Recht, die Berechtigungen festzulegen und abzufragen.
Eine weitere Verbesserung des Dienstsicherheitsmodells in Windows Vista ermöglicht einem Dienstentwickler die genaue Angabe der Sicherheitsberechtigungen für die Ausführung eines Diensts, wenn der Dienst sich im System anmeldet. Wenn der Dienst beispielsweise Überwachungsereignisse generieren muss, könnte der Entwickler eine Überwachungsberechtigung aufführen.
Wenn der Dienststeuerungs-Manager einen Prozess startet, der einen oder mehrere Windows-Dienste hostet, erstellt er ein Sicherheitstoken (das Kernelobjekt, das ein Prozessbenutzerkonto, Gruppenmitgliedschaften und Sicherheitsberechtigungen aufführt) für den Prozess, das nur die Berechtigungen enthält, die für die Dienste im Prozess erforderlich sind. Wenn ein Dienst eine Berechtigung angibt, die für das Konto, unter dem er ausgeführt wird, nicht verfügbar ist, wird der Dienst nicht gestartet. Wenn beispielsweise keiner der Dienste, die in einem lokalen Dienstkontoprozess ausgeführt werden, die Berechtigung „Debuggen von Programmen“ benötigt, entfernt der Dienststeuerungs-Manager diese Berechtigung aus dem Sicherheitstoken des Prozesses. Wenn der Dienstprozess offen gelegt wird, kann bösartiger Code folglich keine Berechtigungen nutzen, die nicht ausdrücklich für die in diesem Prozess ausgeführten Dienste angefordert wurden. Der sc qprivs-Befehl meldet die Berechtigungen, die von einem Dienst angefordert wurden.

Schlussbemerkung
Damit ist mein dreiteiliger Einblick in die Änderungen beim Windows Vista-Kernel beendet. Es gibt Features und Verbesserungen, die ich nicht angesprochen habe, beispielsweise den neuen Arbeitsthreadpool für Anwendungsentwickler, neue Synchronisierungsmechanismen wie z. B. freigegebene Lese-/Schreibsperren, Dienstthreadtagging, Unterstützung für Online-NTFS-Datenträgerüberprüfung und Volumegrößenänderung sowie einen neuen Kernel-IPC-Mechanismus namens ALPC (Advanced Local Procedure Call). Weitere Informationen zu diesen und anderen Features finden Sie in der nächsten Ausgabe von Windows Internals, deren Veröffentlichung Ende 2007 geplant ist.
Anzeigen eines Diensts mit eingeschränktem Schreiben
Nur ein Diensthostingprozess in Windows Vista hostet eingeschränkte Dienste. Sie können ihn mit einem Tool zum Anzeigen von Prozessen wie dem Process Explorer als den Prozess mit der folgenden Befehlszeile identifizieren:
svchost -k LocalServiceNoNetwork
Zu den Diensten, die zur Ausführung in diesem Prozess konfiguriert sind, gehören: Basisfiltermodul, Diagnoserichtliniendienst, Windows-Firewall, Leistungsprotokolle und -Warnungen und das Startdienstprogramm für Windows Media® Center.
Dieser Bildschirm zeigt das Textformat der Dienstsicherheits-ID des Basisfiltermoduls, NT SERVICE\BFE, die einmal mit dem eingeschränkten Kennzeichen und einmal ohne aufgeführt ist, sodass der Prozess auf Ressourcen zugreifen kann, die für dieses Konto zugänglich sind. Der Prozess hat jedoch nicht unbedingt Zugriff auf andere Objekte, die normalerweise für das lokale Dienstkonto zugänglich sind. Da beispielsweise das NT AUTHORITY\SERVICE-Konto nicht im Prozesstoken mit dem eingeschränkten Kennzeichen enthalten ist, kann der Prozess keine Objekte ändern, die nur diesem Konto, aber keinen anderen Konten in dem Token, bei denen das eingeschränkte Kennzeichen gesetzt ist, Schreibzugriff gewähren.
Für die in diesem Prozess ausgeführten Dienste werden die Berechtigungen ebenfalls eingeschränkt, weil die am unteren Ende des Eigenschaftendialogs aufgeführten Berechtigungen lediglich eine Teilmenge der Berechtigungen sind, die dem lokalen Dienstkonto zur Verfügung stehen.
SID-Kennzeichen in einem Dienst
SID-Kennzeichen in einem Dienst

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 Tech•Ed und PDC. Er 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.


 Windows-Verwaltung: Notfallwiederherstellung: Active&#160;Directory-Benutzer und -Gruppen
Windows-Verwaltung Gil Kirkpatrick

Notfallwiederherstellung: Active Directory-Benutzer und -Gruppen
Kurz zusammengefasst:
  • Funktionsweise der Replikation und Objektverknüpfung
  • Verwenden von NTDSUTIL zum Sichern und Wiederherstellen
  • Autorisierende und nicht autorisierende Wiederherstellungen

Active Directory ist einer der wichtigsten Dienste in einem Windows-Netzwerk. Um Ausfälle und Produktivitätsverluste zu vermeiden, benötigen Sie effektive Notfallwiederherstellungspläne für Probleme, die mit Active Directory auftreten können. Dies scheint ganz offensichtlich zu sein, allerdings ist es
erstaunlich, wie viele Administratoren nicht über einen Plan für eines der am häufigsten vorkommenden Fehlerszenarien bei Active Directory® verfügen: das versehentliche Löschen von Daten.
Das versehentliche Löschen von Objekten ist eine der Hauptursachen für den Ausfall von Diensten. Ich frage bei Seminaren und Konferenzen oft, wer schon einmal einen Active Directory-Fehler aufgrund eines versehentlichen Löschens von Daten hatte. Immer wieder ist das bei fast allen Anwesenden der Fall.
Um zu verstehen, warum die Datenwiederherstellung so komplex ist, müssen Sie zunächst Folgendes wissen: Wie werden Objekte in Active Directory gespeichert, repliziert und gelöscht, und wie funktionieren autorisierende und nicht autorisierende Wiederherstellungen?

Speichern von Objekten
Active Directory ist eine spezialisierte Objektdatenbank, die das Datenmodell X.500/LDAP implementiert. Der Datenspeicher (Directory Information Tree, DIT) basiert auf der Extensible Storage Engine (ESE), einem ISAM (Indexed Sequential Access Method)-Datenbankmodul. Active Directory speichert die DIT-Datenbank in zwei Tabellen: In der Datentabelle (die die Active Directory-Objekte und -Attribute enthält) und in der Verknüpfungstabelle (die die Beziehungen zwischen Objekten enthält).
Jedes Active Directory-Objekt wird in einer einzelnen Zeile in der Datentabelle mit einer Spalte pro Attribut gespeichert. Die Datentabelle enthält alle Einträge für alle auf dem Domänencontroller (DC) gespeicherten Replikate. Bei einem regulären DC enthält die Datentabelle Einträge zum Domänennamenskontext, Konfigurationsnamenskontext und zum Schemanamenskontext. Bei einem normalen Katalog enthält die Datentabelle Einträge für jedes Objekt in der Gesamtstruktur.
Active Directory verwendet das Distinguished Name Tag (DNT), eine 32-Bit-Ganzzahl, um jede Zeile in der Datentabelle eindeutig zu identifizieren. Das DNT wird zum internen Verweis auf Objekte verwendet und ist viel kleiner als andere Bezeichner wie z. B. Distinguished Name (DN) oder objectGUID (eine 16-Byte-Binärstruktur). Aber im Unterschied zur objectGUID ist das DNT eine lokale Kennung, die bei jedem DC anders ist.

So verknüpft Active Directory Objekte
Active Directory verwaltet zwei Arten von Beziehungen zwischen Objekten in der DIT-Datenbank: Die Beziehung zwischen über- und untergeordneten Elementen (auch als Containerbeziehung bezeichnet) und die Verweisbeziehung (auch als Verknüpfungsbeziehung bezeichnet). Zur Implementierung der Beziehung zwischen über- und untergeordneten Elementen speichert Active Directory eine zusätzliche Spalte in der Datentabelle, die als Parent Distinguished Name Tag oder PDNT bezeichnet wird. Diese Spalte enthält immer das DNT des dem Objekt übergeordneten Elements.
Jedes Attribut in Active Directory wird von einem attributeSchema-Objekt im Schemacontainer von Active Directory definiert. Bestimmte Attribute in Active Directory werden als Verknüpfungsattribute definiert. Sie werden durch einen geraden Wert ungleich Null im linkID-Attribut des attributeSchema-Objekts bestimmt. Durch Verknüpfungsattribute wird eine Beziehung zwischen Objekten im Verzeichnis eingerichtet. Sie können einen oder mehrere Werte haben. Das Mitgliedsattribut eines Gruppenobjekts ist ein Beispiel für ein Verknüpfungsattribut mit mehreren Werten – es stellt eine Verknüpfung zwischen dem Gruppenobjekt und seinen Mitgliedsobjekten her.
Das Mitgliedsattribut einer Gruppe scheint zwar die DNs der Mitglieder zu enthalten (wie beispielsweise im Active Directory-Benutzer- und -Computer-Snap-In aufgeführt), aber in Wirklichkeit werden die DNs von Active Directory anders gespeichert. Wenn Sie den DN eines Mitgliedsobjekts dem Mitgliedsattribut einer Gruppe hinzufügen, speichert Active Directory das DNT des Objekts, nicht den DN. Da sich das DNT selbst bei Neubenennung eines Objekts nicht ändert, können Sie ein Benutzerobjekt umbenennen, ohne dass Active Directory alle Gruppen im System durchsuchen muss, um den DN in jedem der Mitgliedsattribute zu aktualisieren. Auf diese Weise behält Active Directory die referenzielle Integrität innerhalb der DIT bei. Abbildung 1 enthält eine stark vereinfachte Darstellung der Beziehungen zwischen der Datentabelle und der Verknüpfungstabelle. Diese Tabellen zeigen, dass die drei Benutzerobjekte – Molly Clark, Alexander Tumanov und Makoto Yamagishi – alle Mitglieder der Gruppe Senior Engineers sind.
Figure 1 Beziehungen zwischen Daten und Verknüpfungstabellen (Close Figure 1)

Datentabelle |  |  |
DNT | PDNT | Objektklasse | Cn
14529 | 14401 | Organisationseinheit | Engineers
14530 | 14529 | Gruppe | Senior Engineers
14531 | 14529 | Benutzer | Molly Clark
14532 | 14529 | Benutzer | Alexander Tumanov
14533 | 14529 | Benutzer | Makoto Yamagishi
Verknüpfungstabelle |  |  |
Attribut | DNT | Forwardlink |
Mitglied | 14530 | 14531 |
Mitglied | 14530 | 14532 |
Mitglied | 14530 | 14533 |
Diese Verknüpfungen werden als Forwardlinks bezeichnet. Dementsprechend stellt Active Directory auch Backwardlink-Attribute zur Verfügung. Die Backwardlink-Attribute liefern einen Bezug vom verknüpften Objekt zurück zu dem damit verbundenen Objekt, also zu dem Objekt mit dem Forwardlink. Das memberOf-Attribut für Benutzer und Gruppen ist ein Beispiel für ein Backwardlink-Attribut. Das attributeSchema-Objekt, das ein Backwardlink-Attribut beschreibt, hat einen linkID-Wert, der um 1 größer ist als der geradzahlige linkID-Wert des dazugehörigen Forwardlink-Attributs. Beispiel: Das Mitgliedsattribut im Windows Server® 2003 R2-Schema hat den linkID-Wert 2, das memberOf-Attribut, das als Backwardlink fungiert, hat dann den Wert 3. In Abbildung 2 finden Sie zur weiteren Information eine Liste der verlinkten Attribute, die standardmäßig im Windows Server 2003 R2-Schema definiert sind.
Figure 2 Verknüpfungsattribute im Windows Server 2003 R2-Schema (Close Figure 2)

Forwardlink-Attribut | linkID | Backwardlink-Attribut | Verknüpftes
Mitglied | 2 | memberOf | 3
manager | 42 | directReports | 43
owner | 44 | ownerBL | 45
siteObject | 46 | siteObjectBL | 47
nonSecurityMember | 50 | nonSecurityMemberBL | 51
queryPolicyObject | 68 | queryPolicyBL | 69
privilegeHolder | 70 | isPrivilegeHolder | 71
managedBy | 72 | managedObjects | 73
hasPartialReplicaNCs | 74 |  |
hasMasterNCs | 76 | masteredBy | 77
syncMembership | 78 |  |
serverReference | 94 | serverReferenceBL | 95
bridgeheadTransportList | 98 | bridgeheadServerListBL | 99
netbootServer | 100 | netbootSCPBL | 101
frsComputerReference | 102 | frsComputerReferenceBL | 103
fRSMemberReference | 104 | fRSMemberReferenceBL | 105
fRSPrimaryMember | 106 |  |
siteLinkList | 142 |  |
siteList | 144 |  |
msCOM-PartitionLink | 1040 | msCOM-PartitionSetLink | 1041
msDS-NC-Replica-Locations | 1044 |  |
msFRS-Hub-Member | 1046 |  |
msCOM-UserPartitionSetLink | 1048 | msCOM-UserLink | 1049
msDS-SDReferenceDomain | 2000 |  |
msDS-HasInstantiatedNCs | 2002 |  |
msDS-NonMembers | 2014 | msDS-NonMembersBL | 2015
msDS-MembersForAzRole | 2016 | msDS-MembersForAzRoleBL | 2017
msDS-OperationsForAzTask | 2018 | msDS-OperationsForAzTaskBL | 2019
msDS-TasksForAzTask | 2020 | msDS-TasksForAzTaskBL | 2021
msDS-OperationsForAzRole | 2022 | msDS-OperationsForAzRoleBL | 2023
msDS-TasksForAzRole | 2024 | msDS-TasksForAzRoleBL | 2025
msDS-HasDomainNCs | 2026 |  |
msSFU30PosixMember | 2030 | msSFU30PosixMemberOf | 2031
msDS-hasMasterNCs | 2036 | msDs-masteredBy | 2037
msDS-ObjectReference | 2038 | msDS-ObjectReferenceBL | 2039
msDFSR-ComputerReference | 2050 | msDFSR-ComputerReferenceBL | 2051
msDFSR-MemberReference | 2052 | msDFSR-MemberReferenceBL | 2053
Backwardlink-Attribute haben immer mehrere Werte und werden automatisch von Active Directory verwaltet. Sie können ein Backwardlink-Attribut nicht direkt ändern. Zwar scheint es, als könnten Sie das memberOf-Attribut eines Benutzers oder einer Gruppe über das MMC-Snap-In des Active Directory-Benutzers und -Computers ändern, allerdings ändert das Snap-In nur das Mitgliedsattribut der entsprechenden Gruppe, und Active Directory aktualisiert das memberOf-Attribut im Hintergrund. Darum benötigen Sie keine Berechtigungen für das Benutzerobjekt, um den Benutzer zu einer Gruppe hinzuzufügen. Sie ändern eigentlich nur das Mitgliedsattribut des Gruppenobjekts. Da jeder DC seine Backwardlink-Attribute lokal verwaltet, werden Änderungen an Backwardlinks nie repliziert. Nur die Änderung am Forwardlink-Attribut, z. B. dem Mitgliedsattribut einer Gruppe, werden repliziert.
Auf einem normalen DC enthält die Datentabelle Einträge für Domänenobjekte und für Objekte aus den Konfigurations- und Schemacontainern. Einige Gruppentypen können jedoch Bezüge auf Objekte enthalten, die sich in einer anderen Domäne befinden. Wie speichert Active Directory ein DNT für ein Objekt, das sich nicht in seiner Datentabelle befindet? Die Antwort liegt beim Besitzer der Rolle Infrastrukturmaster FSMO (Flexible Single Master Operations) und bei einem so genannten Phantomobjekt.

Phantomobjekte
Wenn Sie ein Mitglied einer Domäne einer Gruppe in einer anderen Domäne hinzufügen, erstellt Active Directory automatisch ein spezielles Objekt in der Datentabelle, das als Phantom bezeichnet wird. Dieses Phantom enthält die objectGUID, objectSid, und den DN des neuen Mitglieds. Dadurch wird ein DNT bereitgestellt, das im Mitgliedsattribut der Gruppe gespeichert werden kann. Wenn es sich bei einem Domänencontroller um einen globalen Katalog handelt, muss kein Phantom erstellt werden, da sich bereits ein Eintrag in der Datentabelle für jedes Objekt in der Gesamtstruktur befindet.
Der DC mit der Rolle Infrastruktur FSMO vergleicht die Einträge in seiner Datentabelle regelmäßig mit einem globalen Katalog. Wenn er feststellt, dass ein Objekt verschoben, umbenannt oder gelöscht wurde, aktualisiert er die Phantome in der Datentabelle und repliziert die Änderung für die anderen DCs in der Domäne. In Folge einer Verweiszählung kann der Infrastrukturmaster auch Phantome entfernen, auf die sich keine Forwardlink-Attribute in der Domäne mehr beziehen.
Mit Phantomen können DCs Verweise auf Objekte in anderen Domänen innerhalb der Gesamtstruktur verwalten. Allerdings können Forwardlink-Attribute auch auf Objekte verweisen, die sich außerhalb der Gesamtstruktur befinden – z. B. in einer vertrauenswürdigen Domäne. In diesem Fall erstellt Active Directory im CN=ForeignSecurityPrincipals-Container im Domänennamenskontext ein Objekt, das als Foreign Security Principal (FSP) bezeichnet wird. Der FSP enthält die Sicherheits-ID (SID) und weitere Attribute, die das Objekt in der fremden Domäne identifizieren. Es gibt jedoch keinen Prozess, der sicherstellt, dass der FSP aktuell bleibt. Zur Datenwiederherstellung werden FSPs wie jedes andere Active Directory-Objekt behandelt.

Löschen von Objekten
An dieser Stelle befasse ich mich hauptsächlich mit der Wiederherstellung von Benutzern und ihren Gruppenmitgliedschaften. Allerdings gelten dieselben Prinzipien für die Wiederherstellung anderer verknüpfter Attribute.
Wenn Active Directory ein Objekt löscht, löscht es das Objekt nicht physisch aus der DIT. Stattdessen wird das Objekt als gelöscht markiert, indem das isDeleted-Attribut auf True (Wahr) gesetzt wird. Dadurch wird das Objekt für normale Verzeichnisvorgänge unsichtbar. Active Directory entfernt alle Attribute, die nach Definition im Schema nicht gespeichert werden sollen, und ändert den Relative Distinguished Name (RDN) des Objekts auf <alter RDN>\0aDEL:<objectGUID>. Danach wird das Objekt in den CN=Deleted Objects-Container für das Namenskonzept verschoben. (Es gibt einige Objektklassen im Konfigurationsnamenskontext, die Active Directory nicht in den Container für gelöschte Objekte verschiebt.) Active Directory entfernt alle Forwardlinks des gelöschten Objekts auf andere Objekte. Dadurch wird die Verweisanzahl in der Verknüpfungstabelle reduziert. Wenn es andere Objekte gibt, die Forwardlinks auf das gelöschte Objekt enthalten, entfernt Active Directory diese Verknüpfungen ebenfalls.
Das entstehende Objekt wird als Tombstone (Grabstein) bezeichnet. Active Directory repliziert diesen Tombstone für andere DCs, bei denen dieselben Änderungen durchgeführt werden. Beachten Sie, dass Active Directory nicht die Änderungen an Forwardlinks repliziert, die auf das gelöschte Objekt verweisen. Jeder DC führt die entsprechende Änderung lokal aus, sodass das Replizieren nicht notwendig ist. Dies wirkt sich auf das Wiederherstellen von Gruppenmitgliedschaften aus, worauf ich später in diesem Artikel noch eingehen werde.
Active Directory behält Tombstone-Objekte in der DIT wie durch das tombstoneLifetime-Attribut des CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<Stammdomänen>-Objekt festgelegt. Durch den Sammlungsprozess für veraltete Objekte auf jedem DC werden Tombstones entfernt, die älter als die konfigurierte Gültigkeitsdauer für Tombstones sind. Standardmäßig liegt die Gültigkeitsdauer für Tombstones bei Windows® 2000, Windows Server 2003 und Windows Server 2003 R2 bei 60 Tagen. Bei Windows Server 2003 SP1 liegt sie bei 180 Tagen.
Die Gültigkeitsdauer von Tombstones hat bedeutende Auswirkungen auf den Wiederherstellungsprozess. Sie können mit einer Sicherung, die älter als die Gültigkeitsdauer der Tombstones ist, keine Wiederherstellung durchführen. Da es für Objekte, die von der Domäne gelöscht und gesammelt wurden, keine Tombstones mehr gibt, kann der Löschvorgang für den wiederhergestellten DC nicht nochmals repliziert werden. Die gelöschten Objekte verbleiben als veraltete Objekte auf dem wiederhergestellten DC, weshalb keine ordnungsgemäße Abstimmung mit anderen DCs in der Domäne durchgeführt werden kann.

Replizieren von Objekten
Wenn ein Domänencontroller eine Aktualisierung durchführt – z. B. ein Objekt hinzufügt oder ein Attribut ändert – weist der DC dem Aktualisierungsvorgang eine eindeutige 64-Bit-Nummer zu. Diese Nummer wird als Update Sequence Number (USN) bezeichnet. Active Directory kennzeichnet die aktualisierten Objekte und Attribute mit der USN, um festzustellen, ob sie repliziert werden müssen.
Active Directory repliziert Objekte Attribut für Attribut. Wenn Sie also das Attribut eines Objekts ändern, repliziert Active Directory nur dieses Attribut, und nicht das ganze Objekt. Hierfür verfolgt Active Directory die Änderungen, die es an jedem Attribut vornimmt, mithilfe von Replikationsmetadaten zurück. Die Replikationsmetadaten für ein Attribut umfassen:
  • Die lokale USN, die den Änderungsvorgang auf dem lokalen DC identifiziert.
  • Die Aufrufkennung des DC, der die Änderung vorgenommen hat (speziell das invocationID-Attribut des entsprechenden nTDSSettings-Objekts des DC). Diese Kennung identifiziert eine bestimmte Generierung der DIT auf einem Domänencontroller.
  • Die USN des ursprünglichen Vorgangs, die auf dem Ursprungs-DC vorhanden ist.
  • Ein Zeitstempel, der die Systemzeit des DC für den Zeitpunkt enthält, an dem die ursprüngliche Änderung durchgeführt wurde.
  • Eine sequenzielle Versionsnummer mit 32 Bit, die bei jeder Änderung des Werts erhöht wird.
Wenn ein Ziel-DC Änderungen von seinem Quell-DC-Partner anfordert, sendet er die USN der letzten erfolgreich replizierten Änderung zusammen mit einem Aktualitätsvektor an die Quell-DC. Der Aktualitätsvektor enthält die größte Ursprungs-USN, die dem Ziel-DC von jedem DC vorliegt, der ein Replikat des replizierten Namenskontexts enthält. Der Quell-DC verwendet diese Information, um nur die Aktualisierungen zu senden, die dem Ziel-DC noch nicht vorliegen.
Während der Ziel-DC die eingehenden Attributsaktualisierungen verarbeitet, prüft er die Versionsnummer jedes Attributs. Wenn die Versionsnummer eines eingehenden Attributs größer ist als die Version, die dem DC für dieses Attribut bereits vorliegt, speichert der DC den eingehenden Wert. Wenn die eingehende Versionsnummer mit der Version übereinstimmt, die dem DC bereits vorliegt, vergleicht der DC die Zeitstempel und verwendet das Attribut mit dem aktuellen Stempel. Wenn die Zeitstempel gleich sind, wählt der Ziel-DC den Wert mit der größten Aufrufkennung. Dadurch wird sichergestellt, dass alle DCs nach und nach denselben Wert für jedes replizierte Attribut haben.

Replizieren von verknüpften Werten
Unter Windows 2000 hat Active Directory Attribute mit mehreren Werten auf dieselbe Weise wie Attribute mit einem Wert repliziert. Dies führte zu Problemen bei großen dynamischen Gruppenobjekten, deren Mitgliedsattribute mit mehreren Werten regelmäßig auf verschiedenen DCs geändert werden konnten. Wenn ein Administrator einer Gruppe auf einem DC einen Benutzer hinzufügt und ein anderer Administrator einer Gruppe auf einem anderen DC innerhalb des Replikationswartezeit-Fensters einen anderen Benutzer hinzufügt, wählt Active Directory immer den zweiten (späteren) Wert und ignoriert den früheren Wert. Microsoft hat sich mit diesem Problem unter Windows Server 2003 mit einem Vorgang, der als Linked Value Replication (LVR) bezeichnet wird, befasst.
Auf der Funktionsebene bzw. der vorläufigen Funktionsebene der Gesamtstruktur von Windows Server 2003 repliziert Active Directory die individuellen Werte von Forwardlink-Attributen mit mehreren Werten separat. Dabei hat jeder Wert seine eigenen Replikationsmetadaten. Dadurch wird das unter Windows 2000 gefundene Problem, bei dem beinahe gleichzeitige Aktualisierungen von Gruppenmitgliedschaften auf verschiedenen DCs zu Datenverlusten führen konnten, effektiv gelöst.
Allerdings sollte man einen Punkt beachten. Durch Anheben der Funktionsebene der Gesamtstruktur werden bereits bestehende Verknüpfungsattribute mit mehreren Werten nicht automatisch mit den neuen Replikationsmetadaten ausgestattet. Nur Werte, die nach dem Anheben der Gesamtstrukturfunktionsebene hinzugefügt wurden, verfügen über die neuen Metadaten. Dies hat erhebliche Auswirkungen auf die Wiederherstellung von Gruppenmitgliedschaften, wie Sie im Folgenden feststellen werden.

Erstellen von Sicherungen
Zu Windows gehört das sehr einfache NT-BACK-UP-Dienstprogramm, das zum Durchführen der Systemstatussicherung eines DC verwendet werden kann. Der Systemstatus eines Domänencontrollers beinhaltet seine Registrierung, SYSVOL, Active Directory-DIT-Dateien und wichtige Systemdateien. Die meisten Sicherungsdienstprogramme von Drittanbietern können ebenfalls Sicherungen und Wiederherstellungen des Systemstatus eines DC vornehmen.
Mit dem folgenden Befehl führen Sie eine Systemstatussicherung in eine Datenträgerdatei durch:
NTBACKUP backup systemstate /F “<filename>”
Hierbei ist <filename> der Name der zu erstellenden Sicherungsdatei. Die Datei sollte die Erweiterung .bkf erhalten.

Durchführen einer nicht autorisierenden Wiederherstellung.
Das Wiederherstellen gelöschter Active Directory-Objekte aus einer Sicherung erfolgt in zwei Schritten. Starten Sie zunächst den DC im Wiederherstellungsmodus für Verzeichnisdienste (Directory Services Restore Mode, DSRM) neu. Stellen Sie danach die gesamte Active Directory-DIT aus der Systemstatussicherung wieder her, indem Sie das Windows-Dienstprogramm NTBACKUP oder ein ähnliches Produkt eines Drittanbieters verwenden. Durch diesen Prozess wird die gesamte DIT überschrieben.
Es gibt zwei Möglichkeiten, einen DC im DSRM zu starten. Wenn Sie Zugriff auf die Systemkonsole des DC haben, fahren Sie den DC herunter, und starten Sie ihn neu. Drücken Sie bei Aufforderung F8, um das Windows-Startmenü anzuzeigen. Wählen Sie aus dem Menü „Verzeichnisdienste wiederherstellen“ aus, und geben Sie das DSRM-Kennwort ein.
Wenn Sie den Server von einem Remotestandort aus verwalten, haben Sie keinen Zugriff auf das Windows-Startmenü. Stattdessen können Sie die Startoptionen für das System ändern, indem Sie vom Arbeitsplatz „Eigenschaften“ auswählen, auf die Registerkarte „Erweitert“ klicken und dann unter „Starten und Wiederherstellen“ auf die Schaltfläche „Einstellungen“ klicken. Klicken Sie im Bereich „Systemstart“ auf die Schaltfläche „Bearbeiten“, um die Datei „boot.ini“ zu bearbeiten, und fügen Sie den Switch „/SAFEBOOT:DSREPAIR“ am Ende der Zeile hinzu, wie in Abbildung 3 gezeigt. (Weitere Informationen zu boot.ini-Switches finden Sie unter microsoft.com/technet/ sysinternals/information/bootini.mspx.)
Abbildung 3 Einstellen von Startoptionen für DSRM
Abbildung 3 Einstellen von Startoptionen für DSRM
Der Server startet bei einem Neustart im DSRM. Denken Sie daran, den /SAFEBOOT-Switch aus der Datei „boot.ini“ zu entfernen, wenn Sie den DC im normalen Modus neu starten möchten.
Stellen Sie nach dem Anmelden mit dem DSRM-Kennwort die Systemstatussicherung mit dem Befehl NTBACKUP wieder her, geben Sie dabei jedoch keine Parameter an. (Sie können keine Wiederherstellung durchführen, indem Sie den Befehl NTBACKUP von der Befehlszeile ausführen.) Wenn sich der Assistent öffnet, wählen Sie „Dateien und Einstellungen wiederherstellen“, und klicken Sie auf „Weiter“. Wählen Sie dann die Sicherungsdatei aus, und aktivieren Sie das Feld „Systemstatus“, wie in Abbildung 4 gezeigt.
Abbildung 4 Verwenden des Sicherungs- oder Wiederherstellungs-Assistenten zur Wiederherstellung des Systemstatus
Abbildung 4 Verwenden des Sicherungs- oder Wiederherstellungs-Assistenten zur Wiederherstellung des Systemstatus
Wenn Sie an dieser Stelle den DC wieder im normalen Modus starten würden, würde der Active Directory-Replikationsvorgang den wiederhergestellten Domänencontroller mit den anderen DCs in der Domäne synchronisieren, und alle wiederhergestellten Daten würden mit aktuellen Daten überschrieben. Das soll jedoch keinesfalls passieren. Stattdessen müssen Sie eine Möglichkeit finden, die wiederhergestellten Objekte dazu zu bringen, sich auf die anderen Domänencontroller in der Domäne zu replizieren.

Durchführen einer autorisierenden Wiederherstellung
NTDSUTIL erhöht außerdem die Versionsnummer jedes Attributs um 100.000 für jeden Tag zwischen dem Datum der Sicherung und dem Datum der Wiederherstellung. Die Versionsnummer der wiederhergestellten Attribute ist daher sehr viel größer als die Versionsnummern der anderen DCs (es sei denn, es gibt Attribute, die über 100.000 mal täglich aktualisiert werden, was ziemlich unwahrscheinlich ist), wodurch sich das autorisierend wiederhergestellte Objekt auf die anderen DCs repliziert. Die anderen, nicht autorisierend wiederhergestellten Objekte aus der Sicherung werden letztendlich durch vorhandene Daten von den anderen Domänencontrollern überschrieben.
Verwenden Sie nach Beenden der nicht autorisierenden Wiederherstellung und vor dem Neustart im normalen Modus das Programm NTDSUTIL, um eine autorisierende Wiederherstellung der Objekte durchzuführen, die Sie wiederherstellen möchten. Bei der autorisierenden Wiederherstellung wird das Objekt nicht wiederhergestellt, sondern einfach sichergestellt, dass Active Directory das Objekt auf die anderen DCs repliziert. Hierfür weist NTDSUTIL der lokalen USN der Attribute des Objekts die nächste verfügbare USN zu. Dadurch wird das Objekt bei der nächsten Synchronisierung an Replikationspartner gesendet. Stellen Sie zum Wiederherstellen eines einzelnen Objekts sicher, dass der DC im DSRM gestartet wurde, und führen Sie die folgenden Schritte aus:
  1. Öffnen Sie ein Befehlsfenster, und geben Sie Folgendes ein:
    ntdsutil
  2. Geben Sie in der ntdsutil-Eingabeaufforderung Folgendes ein:
    authoritative restore
  3. Geben Sie in der Eingabeaufforderung für die autorisierende Wiederherstellung Folgendes ein:
    restore object “<DN of object to be restored>”
    Beispiel: Wenn Sie das Konto „Molly Clark“ aus der Organisationseinheit „Eng“ in der Domäne DRNET wiederherstellen möchten, geben Sie Folgendes ein:
    restore object “CN=Molly Clark,OU=Eng,DC=DRNET,DC=com”
    Wenn Sie eine komplette Unterstruktur eines Verzeichnisses autorisierend wiederherstellen möchten, z. B. eine Organisationseinheit, geben Sie stattdessen Folgendes ein:
    restore subtree “OU=Eng,DC=DRNET,DC=com”
    NTDSUTIL stellt auch einen Befehl zur Wiederherstellung einer Datenbank zur Verfügung, mit dem die gesamte Domäne und die Konfigurations- und Schemanamenskontexte autorisierend wiederhergestellt werden. Das Wiederherstellen der gesamten Domäne birgt einige Gefahren. Ich empfehle die Verwendung dieser Option nicht. Wenn Sie eine gesamte Domäne wiederherstellen müssen, sollten Sie einen Domänencontroller wiederherstellen und die anderen DCs in der Domäne wieder höher stufen, wie unter Planung der Wiederherstellung einer Active Directory-Gesamtstruktur beschrieben.
  4. Bestätigen Sie bei der entsprechenden Aufforderung, dass durch die autorisierende Wiederherstellung die Versionsnummern der entsprechenden Objekte und ihrer Attribute erhöht werden sollen.
  5. Beenden Sie ntdsutil (Sie müssen zweimal „quit“ eingeben).
  6. Starten Sie den DC im normalen Active Directory-Modus neu.
Das nächste Mal, wenn der DC mit seinen Partnern repliziert, wird der von Ihnen wiederhergestellte Benutzer repliziert. Aber das Wiederherstellen des Benutzerobjekts ist nur die eine Hälfte des Problems. Wenn Sie Objektverknüpfungen einführen, wie die zwischen einer Gruppe und deren Mitgliedern, wird die Situation ein wenig komplizierter. Es können während und nach der Wiederherstellung einige grundlegende Probleme auftreten, auf die ich im Folgenden eingehen möchte.
Überprüfen wir zunächst, was geschieht, wenn Sie ein Objekt löschen, das über Backwardlinks verfügt. Angenommen, Sie löschen ein Benutzerobjekt, das Mitglied einer oder mehrerer Gruppen ist. Jeder Domänencontroller, der eine Kopie des Benutzerobjekts hat, konvertiert dieses in einen Tombstone und entfernt alle Verweise aus der Verknüpfungstabelle. Dabei wird das Benutzerobjekt aus allen Gruppenmitgliedschaften in der Domäne des Benutzers entfernt. (Denken Sie daran, dass das Entfernen des Benutzers aus Gruppenmitgliedschaften keine replizierte Änderung ist, da jeder DC die Gruppenmitgliedschaft lokal repliziert. Die Versionsnummer und die lokale USN des Mitgliedsattributs der Gruppe bleiben unverändert). Kurz darauf werden die Phantomobjekte aus den Verknüpfungstabellen in anderen Domänen entfernt. Auch hier kommt es nicht zu einer Aktualisierung der Replikationsmetadaten der Mitgliedsattribute der Gruppe.
Wenn Sie die DIT auf einem Domänencontroller in der Domäne des Benutzers nicht autorisierend wiederherstellen, stellen Sie das Benutzerobjekt zusammen mit allen Gruppenmitgliedschaften in Gruppen in der Domäne wieder her, sodass der wiederhergestellte DC in sich konsistent ist. Nach Einsatz des Dienstprogramms NTDSUTIL für eine autorisierende Wiederherstellung des Benutzers repliziert sich das Benutzerobjekt in alle anderen DCs der Domäne.
Da jedoch die Replikationsmetadaten der aktuellen Gruppen in der Domäne unverändert bleiben, sind die Mitgliedsattribute der Gruppen auf dem wiederhergestellten DC inkonsistent mit denen auf den anderen DCs. Es gibt keine Möglichkeit, diese Inkonsistenz aufzuheben. Folglich werden die Mitgliedschaften des Benutzers auf den anderen DCs in der Domäne nicht wiederhergestellt.

Problem: Gruppenmitgliedschaften innerhalb der Domäne können nicht wiederhergestellt werden
Durch die autorisierende Wiederherstellung des Benutzerobjekts werden die Gruppenmitgliedschaften des Benutzers nicht wiederhergestellt. Warum nicht? Weil die Mitgliedschaftsbeziehung unter Verwendung des Mitgliedsattributs des Gruppenobjekts (Forwardlinks) gespeichert und repliziert wird, und nicht unter Verwendung des memberOf-Attributs des Benutzers (Backwardlink). Das Problem liegt darin, die alten Gruppenmitgliedschaften des Benutzers zu finden und diese ordnungsgemäß wiederherzustellen.
Microsoft hat schrittweise Verbesserungen für den Vorgang der Wiederherstellung einer Gruppenmitgliedschaft eines Benutzers eingeführt. Die zu verwendende Methode hängt also von Ihrer Version von Active Directory ab. Der folgende Abschnitt trifft in erster Linie auf Windows 2000 Active Directory zu.
Die Bestimmung der alten Gruppenmitgliedschaften des Benutzers ist relativ unkompliziert: Prüfen Sie einfach das Backwardlink-Attribut auf dem wiederhergestellten DC, in diesem Fall das memberOf-Attribut des Benutzerobjekts. Das memberOf-Attribut enthält alle Mitgliedschaften in lokalen und globalen Gruppen in der Domäne des Benutzers. Sie können das MMC-Snap-In „Active Directory-Benutzer und -Computer“ (ADUC) oder das in Windows Server enthaltene Dienstprogramm LDIFDE verwenden, um die wiederhergestellten Gruppenmitgliedschaften des Benutzers aufzuführen.
Die folgende LDIFDE-Befehlszeile führt die Gruppen in der Domäne DRNET auf, bei denen Molly Clark Mitglied ist. Die Ergebnisse werden in der Datei „output.ldf“ gespeichert.
C:\> ldifde –r “(distinguishedName=CN=Molly Clark,
OU=Engineering,DC=DRNET,DC=Local)” –l memberOf –p Base –f output.ldf
Beachten Sie, dass Sie den DC im normalen Modus starten müssen, um LDAP-Werkzeuge zu verwenden. Außerdem müssen Sie die eingehende Replikation deaktivieren, da sonst die wiederhergestellten Daten überschrieben werden. Am einfachsten können Sie die eingehende Replikation mit dem Befehl REPADMIN deaktivieren:
REPADMIN /options <dcname>+DISABLE_INBOUND_REPL
Hier ist <dcname> der Name des DC, auf dem die Wiederherstellung stattfindet. Vergessen Sie nicht, die Replikation wieder zu aktivieren, indem Sie –DISABLE_INBOUND_REPL verwenden, wenn Sie fertig sind.
Wenn Sie nur ein paar Benutzer wiederherstellen, ist das einfache manuelle Hinzufügen der Benutzer zu den Gruppen mit ADUC recht einfach. Wenn Sie eine größere Anzahl Benutzer wiederherstellen, gibt es ein paar Tools, mit denen der Vorgang teilweise automatisiert werden kann. Das Microsoft-Dienstprogramm GROUPADD (erhältlich beim Microsoft-Produktsupport) akzeptiert die von Ihnen zum Auflisten der alten Gruppenmitgliedschaften des Benutzers erstellte LDIF-Datei und erstellt eine LDIF-Datei, die diese Mitgliedschaften wiederherstellt. Sie können den Befehl GROUPADD beispielsweise dazu verwenden, die LDIF-Datei, die wir im früheren Beispiel für Molly Clark erstellt haben, zu verarbeiten:
C:\> groupadd /after_restore output.ldf
Der Befehl erstellt eine neue LDIF-Datei mit dem Namen „groupadd_<domain>.ldf“ für jede Domäne, in der Molly Clark Gruppenmitgliedschaften hatte (wobei <domain> der vollqualifizierte Domänenname der Domäne ist, deren Gruppen aktualisiert werden). Mit dem folgenden Befehl können Sie die so erstellte LDIF-Datei importieren:
C:\> ldifde –i –k –f groupadd_child.drnet.net.ldf
Unter Windows Server 2003 hat Microsoft NTDSUTIL verbessert, sodass die zusätzlichen Metadaten aus dem Mitgliedsattribut verwendet werden können, um die Linked Value Replication (LVR) zu unterstützen. Wenn das wiederhergestellte Benutzerobjekt ein Mitglied einer Gruppe in der Domäne war und die Gruppenmitgliedschaft des Benutzers mit LVR-Metadaten gespeichert wurde, erhöht NTDSUTIL die Versionsnummer des entsprechenden Werts des Mitgliedsattributs. Dadurch repliziert sich die wiederhergestellte Mitgliedschaft.
Bei der Windows Server 2003 SP1-Version von NTDSUTIL sind die GROUPADD-Funktionen integriert. Dadurch werden während der autorisierenden Wiederherstellung des Benutzerobjekts automatisch LDIF-Dateien erstellt. In Abbildung 5 ist die neue Version von NTDSUTIL dargestellt, in Abbildung 6 der Inhalt der automatisch erstellten LDIF-Datei.
Figure 6 Inhalt der von NTDSUTIL erstellten LDIF-Datei (Close Figure 6)
dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
Abbildung 5 Neue NTDSUTIL-Version mit integrierten GROUPADD-Funktionen
Abbildung 5 Neue NTDSUTIL-Version mit integrierten GROUPADD-Funktionen
Wenn Sie eine ganze Organisationseinheit wiederherstellen, die eine Reihe von Benutzern und Gruppen enthält, ist das Hinzufügen von Benutzern zu ihren Gruppen eine recht langwierige Angelegenheit. Eine andere Möglichkeit, die wiederhergestellten Gruppenmitgliedschaften wieder hinzuzufügen, ist das autorisierende Wiederherstellen der Gruppen selbst.
Allerdings gibt es beim autorisierenden Wiederherstellen von Gruppen zwei Probleme. Das erste Problem ist ziemlich offensichtlich: Wenn Sie eine Gruppe wiederherstellen, wird die Mitgliedschaft in dieser Gruppe im Zustand zum Zeitpunkt der Sicherung wiederhergestellt. Das bedeutet, dass alle Änderungen, die Sie seit der letzten Sicherung an der Gruppe durchgeführt haben, erneut auf die Gruppe angewendet werden müssen. Das zweite Problem ist nicht ganz so offensichtlich und hat mit der Funktionsweise der Active Directory-Replikation zu tun. Nach einer autorisierenden Wiederherstellung von Benutzern und Gruppen kann nicht bestimmt werden, in welcher Reihenfolge diese repliziert werden. Wenn sich ein Gruppenobjekt auf einem DC vor dem wiederhergestellten Benutzerobjekt repliziert, entfernt der replizierende Domänencontroller automatisch den Benutzerverweis aus der Gruppe, da das Benutzerobjekt auf diesem DC noch nicht existiert. Wenn sich das Benutzerobjekt später repliziert, wird es der Gruppe nicht hinzugefügt.
Das Problem lässt sich am einfachsten durch nochmaliges Durchführen der autorisierenden Wiederherstellung der Gruppen beheben. Starten Sie nach der Durchführung der ersten autorisierenden Wiederherstellung im normalen Modus, und stellen Sie sicher, dass die Replikation korrekt durchgeführt wird. Starten Sie dann nochmals im DSRM, und führen Sie NTDSUTIL aus, um eine autorisierende Wiederherstellung der Gruppen durchzuführen, in denen der Benutzer Mitglied war. Wenn Sie jetzt wieder im normalen Modus starten, hat sich das Benutzerobjekt repliziert, bevor sich die entsprechenden Gruppenobjekte replizieren.

Problem: Gruppenmitgliedschaften in anderen Domänen lassen sich nicht wiederherstellen
Das Problem, in welcher Gruppe dieser Benutzer Mitglied war, ist eigentlich etwas komplizierter als oben beschrieben. Der Benutzer, den Sie wiederherstellen, war eventuell Mitglied in lokalen und universellen Gruppen in anderen Domänen. Diese Gruppenmitgliedschaften werden nicht wiederhergestellt, wenn Sie eine nicht autorisierende Wiederherstellung durchführen. Wie können Sie also herausfinden, zu welchen Gruppen der Benutzer in anderen Domänen gehörte? Die Antwort finden Sie im globalen Katalog. Zusammen mit den Daten seiner eigenen Domäne enthält der globale Katalog eine schreibgeschützte Kopie der Daten der anderen Domänen in der Gesamtstruktur.
Um die Gesamtstrukturdaten des globalen Katalogs nutzen zu können, müssen Sie eine nicht autorisierende Wiederherstellung auf einem globalen Katalog durchführen. Das bedeutet, dass Sie eine Sicherung eines globalen Katalogs haben müssen. Wenn Sie LDIFDE ausführen, um die Gruppenmitgliedschaften des Benutzers zu identifizieren, können Sie auch die universellen Gruppenmitgliedschaften in anderen Domänen feststellen.
Verbinden Sie sich, wenn Sie die Gruppenmitgliedschaften des wiederherzustellenden Benutzers auflisten, mit dem globalen Katalogport 3268 anstelle des Standardports 389, und geben Sie die Stammdomäne der Gesamtstruktur als Grundlage für die Suche an. LDIFDE zeigt die wiederhergestellten Gruppenmitgliedschaften des Benutzers an, inklusive der Mitgliedschaft in universellen Gruppen in allen Domänen der Gesamtstruktur. So gehen Sie vor:
C:\> ldifde –r “(distinguishedName=CN=Don Clark,
OU=Engineering,DC=DRNET,DC=Local)” -t 3268 –l memberOf –p Base –f output.ldf
Wenn Sie GROUPADD oder die neue NTDSUTIL-Version auf einem globalen Katalog ausführen, wird eine LDIF-Datei für die Domäne des Benutzers und eine LDIF-Datei für jede Domäne erstellt, in der der wiederhergestellte Benutzer Mitglied einer universellen Gruppe war. Wenn Sie diese LDIF-Dateien importieren, stellen Sie alle Gruppenmitgliedschaften des Benutzers wieder her. Jedenfalls fast alle, was uns zum nächsten Problem führt.

Problem: Wiederherstellen von Mitgliedschaften in lokalen Domänengruppen anderer Domänen
In einer Windows Active Directory-Umgebung gibt es drei Arten von Gruppen. Globale Gruppen können nur Mitglieder in derselben Domäne enthalten, sie können jedoch als Mitglied in lokalen Domänengruppen in der eigenen Domäne und anderen Domänen in der Gesamtstruktur verwendet werden. Das Mitgliedsattribut globaler Gruppen wird im globalen Katalog nicht angezeigt, das ist jedoch kein Problem, da globale Gruppen nur Mitglieder ihrer eigenen Domäne enthalten. Universelle Gruppen können Mitglieder jeder Domäne enthalten. Außerdem können sie als Mitglieder in anderen universellen Gruppen in der Gesamtstruktur und in lokalen Domänengruppen in ihrer eigenen und anderen Domänen in der Gesamtstruktur verwendet werden. Das Mitgliedsattribut universeller Gruppen wird in globalen Katalogen repliziert. Lokale Domänengruppen können Mitglieder aus jeder Domäne der Gesamtstruktur enthalten. Sie können jedoch nicht als Mitglieder in Gruppen in anderen Domänen verwendet werden. Außerdem wird das Mitgliedsattribut von lokalen Domänengruppen, wie das globaler Gruppen, nicht im globalen Katalog angezeigt. Daher gibt es keine einfache Möglichkeit, die Mitgliedschaft des Benutzers in lokalen Domänengruppen in anderen Domänen wiederherzustellen.
Vor Windows Server 2003 SP1 war die einzige Möglichkeit, Mitgliedschaften in lokalen Domänengruppen in fremden Domänen wiederherzustellen, einen DC in jeder Domäne wiederherzustellen, die Domänendaten für jede lokale Domänengruppe, die den wiederhergestellten Benutzer enthielt, manuell zu suchen, und dann den Benutzer den identifizierten Gruppen wieder hinzuzufügen. In einer großen Umgebung mit vielen Domänen ist diese Vorgehensweise viel zu zeitaufwändig.
Mit der Windows Server 2003 SP1-Version von NTDSUTIL geht das einfacher. Wenn Sie NTDSUTIL auf einem Domänencontroller ausführen, erstellt das Dienstprogramm eine Textdatei, die den DN und die GUID der wiederhergestellten Benutzerobjekte enthält. Sie können dann für jede fremde Domäne einen einzelnen DC nicht autorisierend wiederherstellen, die Textdatei auf den DC kopieren und NTDSUTIL ausführen, um eine neue, domänenspezifische LDIF-Datei zu erstellen, die den wiederhergestellten Benutzer wieder zu den lokalen Domänengruppen hinzufügt, bei denen er Mitglied war.
Führen Sie hierfür die folgenden Schritte auf einem DC in jeder fremden Domäne durch:
  1. Starten Sie den DC in der fremden Domäne im DSRM.
  2. Verwenden Sie NTBACKUP, um eine Kopie der DIT wiederherzustellen, die die wiederhergestellten Gruppenmitgliedschaften des Benutzers enthält.
  3. Kopieren Sie die von NTDSUTIL erstellte .txt-Datei auf den aktuellen DC.
  4. Öffnen Sie ein Befehlsfenster, und geben Sie „ntdsutil“ ein.
  5. Geben Sie „authoritative restore“ ein.
  6. Geben Sie „create LDIF file(s) from <Dateiname>“ ein (wobei <Dateiname> der Name der Textdatei ist).
  7. Geben Sie zweimal „quit“ ein, um „ntdsutil“ zu beenden.
  8. Starten Sie den DC neu im normalen Active Directory-Modus.
  9. Geben Sie „ldifde –i –f <ldif-Dateiname>“ ein (wobei <ldif-Dateiname> der Name der soeben erstellten LDIF-Datei ist).
Jetzt haben Sie alle gelöschten Gruppenmitgliedschaften des Benutzers wiederhergestellt.

Schritt für Schritt
Das Wiederherstellen von Active Directory-Benutzern und ihren Gruppenmitgliedschaften ist kompliziert, besonders in einer Umgebung mit mehreren Domänen. Die zur korrekten Wiederherstellung von Gruppenmitgliedschaften erforderlichen speziellen Schritte hängen von Ihrer Windows-Version ab.
Unter Windows 2003 SP1 gehen Sie wie folgt vor:
  1. Starten Sie einen globalen Katalog im DSRM, und führen Sie eine Wiederherstellung des Systemstatus mit einer Sicherung durch, die den gelöschten Benutzer enthält.
  2. Verwenden Sie NTDSUTIL, um eine autorisierende Wiederherstellung des gelöschten Benutzers durchzuführen. NTDSUTIL erstellt eine Textdatei mit den DNs und GUIDs des wiederhergestellten Objekts sowie mindestens eine LDIF-Datei, um die Gruppenmitgliedschaften des Benutzers wiederherzustellen.
  3. Verwenden Sie „LDIFDE –i –f <LDIF-Dateiname>“ (wobei <LDIF-Dateiname> der Name der in Schritt 2 erstellten LDIF-Datei ist), um die Gruppenmitgliedschaften in die aktuelle und andere Domänen zu importieren.
  4. Starten Sie den globalen Katalog im normalen Modus neu.
  5. Starten Sie einen DC in jeder Domäne im DSRM, und führen Sie eine Wiederherstellung des Systemstatus mit einer Sicherung durch, die die Gruppenmitgliedschaften des wiederhergestellten Benutzers enthält.
  6. Führen Sie NTDSUTIL aus, indem Sie den Befehl „create ldif files“ verwenden.
  7. Starten Sie den DC im normalen Modus neu.
  8. Verwenden Sie „LDIFDE –i –f <Dateiname>“ (wobei <Dateiname> der Name der von Ihnen in Schritt 6 erstellten LDIF-Datei ist), um die Gruppenmitgliedschaften in der fremden Domäne wiederherzustellen.
  9. An dieser Stelle können Sie optional die Replikation mit „REPADMIN /syncall“ erzwingen.
Wenn Sie eine Version von Windows Server 2003 ohne SP1 bzw. Windows 2000 verwenden, müssen Sie einige zusätzliche Schritte ausführen. Da die ältere Version von NTDSUTIL keine LDIF-Dateien erstellt, verwenden Sie das Dienstprogramm GROUPADD für deren Erstellung. So gehen Sie vor:
  1. Starten Sie einen globalen Katalog im DSRM, und führen Sie eine Wiederherstellung des Systemstatus mit einer Sicherung durch, die den gelöschten Benutzer enthält.
  2. Deaktivieren Sie den NIC, oder ziehen Sie das Kabel heraus, um die eingehende Replikation zu verhindern.
  3. Starten Sie den globalen Katalog im normalen Modus neu.
  4. Verwenden Sie „LDIFDE –r "(distinguishedName=<dn>)" -t 3268 -l memberOf –p Base -f membership.ldf“, um die Mitgliedschaft des Benutzers mit dem eindeutigen Namen <dn> zu sichern.
  5. Verwenden Sie „GROUPADD /after_restore membership.ldf“, um LDIF-Dateien zu erstellen.
  6. Verwenden Sie „LDIFDE –i –f <Dateiname>“ (wobei <LDIF-Dateiname> der Name der von GROUPADD in Schritt 5 erstellten LDIF-Datei ist), um die Gruppenmitgliedschaften in die aktuelle Domäne und andere Domänen zu importieren.
  7. Verwenden Sie „REPADMIN /options <dcname> -DISABLE_INBOUND_REPL“, um die eingehende Replikation wieder zu aktivieren.
  8. Starten Sie einen DC in jeder Domäne im DSRM, und führen Sie eine Wiederherstellung des Systemstatus mit einer Sicherung durch, die die Gruppenmitgliedschaften des wiederhergestellten Benutzers enthält.
  9. Starten Sie den DC im normalen Modus neu.
  10. Verwenden Sie „LDIFDE –i –f <Dateiname>“ (wobei <Dateiname> der Name der von GROUPADD in Schritt 5 erstellten LDIF-Datei ist), um die Gruppenmitgliedschaften in der fremden Domäne wiederherzustellen.
  11. An dieser Stelle können Sie optional die Replikation mit „REPADMIN /syncall“ erzwingen.
Jetzt müssen Sie in einer Vorumgebung von Windows Server 2003 SP1 nur noch die lokalen Gruppenmitgliedschaften fremder Domänen für den wiederhergestellten Benutzer wiederherstellen. Sie können die lokalen Gruppenmitgliedschaften der Domänen entweder manuell wiederherstellen oder einen DC aus einer Sicherung wiederherstellen und die lokalen Domänengruppen autorisierend wiederherstellen.

Zusammenfassung
Es kann leicht passieren, dass versehentlich Benutzer oder sogar Organisationseinheiten in Active Directory gelöscht werden. Die richtige Wiederherstellung der gelöschten Benutzer und ihrer Gruppenmitgliedschaften ist jedoch überraschend komplex, zeitaufwändig und fehleranfällig. Um nach diesen Notfällen Daten so schnell wie möglich wiederherstellen zu können, müssen Sie die Funktionsweise von Objektverknüpfung, Replikation, Löschen und autorisierender Wiederherstellung verstehen.
Meinen Sie wirklich, dass Sie das heute Gelernte bei einem Notfall ohne Weiteres in Ihrer Produktionsumgebung anwenden können? Sind Sie wirklich gut darauf vorbereitet, das Benutzerobjekt des Geschäftsführers schnell wiederherzustellen? Verfassen Sie einen schriftlichen Plan zur Wiederherstellung gelöschter Objekte. Führen Sie diesen Plan vor dem Ernstfall mindestens ein- oder zweimal zur Probe durch. Ihr Chef (und der Geschäftsführer) wird dies zu schätzen wissen.
Weitere Ressourcen
  • Wiederherstellen gelöschter Benutzerkonten und ihrer Gruppenmitgliedschaften in Active Directory
  • Microsoft-Produktsupport
  • Schritt-für-Schritt-Anleitung für Active Directory

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 ist darüber hinaus Gründer der Directory Experts Conference (www.dec2007.com).


 Windows-Verwaltung: Gute Gr&#252;nde f&#252;r Windows&#160;XP&#160;Embedded
Windows-Verwaltung Don Jones

Gute Gründe für Windows XP Embedded
Kurz zusammengefasst:
  • Einblick in Windows XP Embedded
  • Besondere Hardwareoptionen
  • Anpassen von Windows XP Embedded

Windows XP Embedded ist die in Komponenten gegliederte Version von Windows, die Sie in der Regel mit Elektronik- und Unterhaltungselektronikgeräten in Verbindung bringen, beispielsweise Digitalempfänger oder Haushaltsgeräte. Aber Windows XP Embedded kann sich auch in der IT-Landschaft Ihres Unternehmens einen festen Platz erobern. Auch wenn dies nicht immer die beste
Lösung für alle Benutzer ist, gibt es einige Szenarien, in denen dieses System einen niedrigeren Verwaltungsaufwand, ggf. kostengünstigere und kleinere Hardwaregeräte und auch größere Sicherheit ermöglicht.

Was ist Windows XP Embedded?
Neben Windows Embedded CE und Windows Embedded for Point of Service ist Windows® XP Embedded eine von drei ressourcenschonenden Windows-Versionen. Von diesen eingebetteten Windows-Betriebssystemen bietet nur Windows XP Embedded den vollen Funktionsumfang eines Clientcomputers mit Windows XP Professional (oder zumindest die Voraussetzungen für dafür). Dieses Betriebssystem beruht auf Windows XP Professional Service Pack 2 (SP2), unterscheidet sich jedoch vom „normalen“ Windows XP durch die äußerst weit gehende Modularisierung. Windows XP Embedded bietet kein Standard-Installationsimage. Stattdessen erstellen Sie mit dem Toolkit Windows Embedded Studio eine benutzerdefinierte Windows XP Embedded-Arbeitsumgebung für das aufzubauende Gerät, und diese Umgebung bietet nur genau den Funktionsumfang, den das Gerät wirklich braucht. Wenn Sie auf DirectX® oder Windows Explorer verzichten können, dann installieren Sie diese Komponenten einfach nicht. Dieser Modularisierung bedeutet, dass jedes aufgebaute und bereitgestellte Windows XP Embedded-Image aus weniger „Bauteilen“ besteht, was einen niedrigeren Verwaltungsaufwand, erhöhte Sicherheit und kostengünstigere Hardware zur Folge hat. In Abbildung 1 wird ein Teil der verfügbaren Optionen in Target Designer dargestellt, einem Bestandteil von Windows Embedded Studio.
Abbildung 1 Auswählen von Komponenten in Target Designer
Abbildung 1 Auswählen von Komponenten in Target Designer

Ein Platz im Unternehmen
Mehr und mehr Benutzerszenarien sind ideal für Windows XP Embedded-Geräte geeignet. Denken Sie beispielsweise an ein Unternehmen, das ein großes Kundendienst-Call Center unterhält. In vielen Fällen kommen die Mitarbeiter im Call Center mit einer oder zwei intern entwickelten Anwendungen und vielleicht einem Webbrowser aus. Die Mitarbeiter nutzen in der Regel nur einen Bruchteil der Funktionen ihres Computers. Mit Windows XP Embedded können Sie daher genau die Funktionen herauspicken, die Sie auch wirklich brauchen. Ein kleinerer Funktionsumfang bedeutet, dass weniger Angriffsfläche für Fehler oder mögliche Sicherheitsangriffe besteht.
Und eben weil diese Windows XP Embedded-Geräte weniger Funktionen besitzen, können sie auf kostengünstiger Hardware ausgeführt werden. Viele Hersteller produzieren Hauptplatinen mit Intel-kompatiblen Niederspannungsprozessoren. Diese Hauptplatinen sind äußerst klein, verbrauchen sehr wenig Strom und müssen oft nicht einmal mit einem Lüfter ausgestattet werden, weil sie nicht heiß laufen. Für kleine, eingebettete Geräte, die nur wenige Anwendungen bewältigen müssen, sind diese Platinen optimal.

Die Leistungsstärke von Windows XP Embedded
Windows XP Embedded bietet einige sehr nützliche Optionen, die in der Vollversion von Windows XP nicht zur Verfügung stehen. Mit EWF (Enhanced Write Filter) und HORM (Hibernate Once, Resume Many) lassen sich Windows-Verwaltungsaufgaben deutlich vereinfachen. EWF ist eine optionale Komponente für Windows XP Embedded-Umgebungen, mit der Sie den Schreibschutz für ein bestimmtes Datenträgervolume aktivieren. Alle Schreibaktivitäten auf den Datenträger werden an eine Überlagerung umgeleitet, die sich auf einem anderen Datenträger oder sogar im Arbeitsspeicher befinden kann. Für das Betriebssystem selbst wirkt die EWF-Überlagerung und das übergeordnete Volume wie eine geschlossene Einheit, also wie ein normales Datenträgervolume. Hinter den Kulissen bleibt das übergeordnete Volume jedoch unverändert: die Änderungen werden ausschließlich an der EWF-Überlagerung vorgenommen. Dies kann in verschiedenen Situationen von Nutzen sein. Stellen Sie beispielsweise ein Windows XP Embedded-Image auf einer CF-Karte (Compact Flash) bereit. Windows XP Embedded-Images belegen im günstigsten Fall gerade einmal 5 MB, der Normalwert liegt bei 200 MB. Eine CF-Karte bietet daher mehr als genug Platz. Legen Sie diese CF-Karte in einen Adapter ein, und verbinden Sie diesen mit dem IDE-Anschluss der Hauptplatine. Damit wird die CF-Karte wie ein normaler, fest eingebauter Datenträger behandelt. Moderne CF-Karten sind nur begrenzt beschreibbar (etwa 100.000 Schreibvorgänge), sodass die CF-Karte mit EWF schreibgeschützt wird. Bringen Sie die EWF-Überlagerung im Arbeitsspeicher unter: Wenn der Benutzer einen Fehler macht, schalten Sie einfach den Computer aus. Die EWF-Überlagerung und sämtliche Änderungen am Computer gehen hierbei sofort verloren. Beim Neustart gelangen Sie wieder zurück zum Ausgangspunkt, der auf der CF-Karte gespeichert ist. Diese Konstellation lässt sich auch für Images auf CD oder DVD einsetzen. Diese Medientypen sind schon an sich schreibgeschützt, sodass EWF sämtliche Aktivitäten in eine Überlagerung schreibt. Selbst wenn die Überlagerung auf einer kleinen internen Festplatte gespeichert ist, besteht keine Gefahr, dass das ursprüngliche Startvolume (auf CD oder DVD) geändert würde. Wenn Sie den Computer auf die ursprüngliche Konfiguration zurücksetzen müssen, löschen Sie einfach die EWF-Überlagerung.
Mit HORM können Sie einen Computer an einem bestimmten Punkt in den Ruhezustand versetzen und dann beliebig oft von diesem Punkt aus wiederherstellen. Der Computer schaltet sich fast sofort ein. Konfigurieren Sie einfach den Computer, starten Sie alle erforderlichen Anwendungen, und versetzen Sie den Computer dann in den Ruhezustand. Von nun an müssen Sie bei jedem Einschalten des Computers nur wenige Sekunden warten, und schon sind alle Anwendungen wieder an Ort und Stelle.

Aufbauen eines Windows XP Embedded-Image
Microsoft unterhält ein Embedded-Partnerprogramm mit Unternehmen, die sich auf das Arbeiten mit Windows XP Embedded spezialisiert haben. Eine Liste dieser Unternehmen finden Sie auf der Windows XP Embedded-Startseite unter microsoft.com/embedded. Viele Unternehmen übergeben vorgefertigte Images an ihren normalen Computerhersteller, die beispielsweise unternehmensinterne Anwendungen und spezielle Konfigurationen enthalten. Unter Umständen sollten Sie daher den Aufbau eigener Windows XP Embedded-Images in Erwägung ziehen und diese Images dann an einen Embedded-Partner weitergeben, der Ihnen fertige kleine Systeme liefert. Mit Windows Embedded Studio unter Windows XP Professional können Sie Windows XP Embedded-Images aufbauen und verwalten.
Um das Toolkit nutzen zu können, installieren Sie zunächst die Vollversion von Windows XP Professional auf der Hardware, die für das Windows XP Embedded-System verwendet werden soll. Auf diese Weise durchlaufen Sie die gesamte Setuproutine von Windows XP, sodass Sie alle erforderlichen Hardwarekomponenten ordnungsgemäß in Betrieb nehmen können. Installieren Sie anschließend Windows Embedded Studio. In der Regel wird hiermit eine Datenbank installiert, mit der Sie die eingebetteten Images verwalten. Die Datenbank lässt sich jedoch auch an einer anderen Position installieren und bildet so ein zentrales Repository. Als Nächstes führen Sie das Befehlszeilenprogramm „Tap.exe“ aus. Hiermit wird eine spezielle neue Komponente erstellt, die von Windows XP Embedded verwendet werden kann. Eine Komponente umfasst normalerweise Funktionen wie einen Medienplayer, ein Dateisystem oder andere benutzerdefinierte Anwendungen. In diesem Fall erstellen Sie eine Komponente mit den notwendigen Hardwaregerätetreibern für Ihr individuelles System. Dieser Schritt muss auf der Zielhardware ausgeführt werden, damit das Tool die passenden Hardwaretreiber erkennt und berücksichtigt.
Im nächsten Schritt starten Sie Windows XP Embedded Component Designer und importieren das Komponentenpaket aus dem Dienstprogramm „Tap.exe“. Component Designer liest die Geräteinformationen aus und bildet eine vollständige Windows XP Embedded -Komponente, die die Grundlage für ein neues Windows XP Embedded-Image darstellt (siehe Abbildung 2). Damit lassen sich die für eine bestimmte Plattform erforderlichen Gerätetreiber deutlich leichter ermitteln. Importieren Sie dann die fertige neue Komponente mit Component Database Manager in die Windows XP Embedded-Komponentendatenbank. In diesem Repository sind alle bekannten Windows XP Embedded-Komponenten gespeichert. Die in der Datenbank gespeicherte Komponente steht dann für die Verwendung in Windows XP Embedded-Images zur Verfügung.
Abbildung 2 Component Designer
Abbildung 2 Component Designer
Nun können Sie eine neue Zielkonfiguration mit Windows XP Embedded Target Designer erstellen. In diesem Tool läuft der Großteil Ihrer eigentlichen Arbeit ab. Wie aus Abbildung 1 hervorgeht, stellen Sie alle notwendigen Komponenten zusammen, um so den gewünschten Funktionsumfang für das Gerät zu erstellen. Hierbei sind auch einige Windows-Kernkomponenten erforderlich, beispielsweise Windows Explorer (wenn das Gerät eine grafische Shell erfordert), das NTFS-Dateisystem (oder FAT32), NT Loader, Support für eine Sprache und der Kern für die Benutzeroberfläche. Mehr als zehntausend Komponenten sind standardmäßig verfügbar.
Die Einstellungen aller Komponenten lassen sich vorkonfigurieren. Die Komponente für den Kern der Benutzeroberfläche kann beispielsweise so angepasst werden, dass bestimmte Elemente im Windows-Startmenü, auf dem Desktop und an anderen Positionen angezeigt werden. Durch das Anpassen der Einstellungen für die einzelnen Komponenten stellen Sie sicher, dass alle Geräte entsprechend Ihren Anforderungen vorkonfiguriert werden (siehe Abbildung 3).
Abbildung 3 Anpassen der Einstellungen
Abbildung 3 Anpassen der Einstellungen
Der schwierigste Teil beim Erstellen eines Windows XP Embedded-Image sind die Abhängigkeiten. Es ist beispielsweise nicht möglich, eine DirectX-Komponente in das Image aufzunehmen, ohne auch mehrere Komponenten hinzuzufügen, über die Windows grundlegende Grafikfunktionen erhält. Die Verfolgung aller Abhängigkeiten kann recht schwierig werden, insbesondere bei größeren, komplexeren Bildern, die buchstäblich Tausenden von Abhängigkeiten unterliegen. Dies ist die Aufgabe von Component Database. Drücken Sie einfach die Taste F5 in Target Designer. Die Anwendung durchsucht alle hinzugefügten Anwendungen und bildet automatisch alle Abhängigkeiten, die für die aufgelisteten Komponenten erforderlich sind. Abbildung 4 zeigt diesen Suchvorgang in Aktion. Dies ist ein äußerst wichtiger Schritt, und genau deshalb kann Windows XP Embedded so stark modularisiert arbeiten. Ohne diese Funktionen in Target Designer wäre die Erstellung von Images mit allen richtigen Abhängigkeiten äußerst kompliziert.
Abbildung 4 Abhängigkeitsprüfung
Abbildung 4 Abhängigkeitsprüfung
Wenn alle Komponenten mit den zugehörigen Abhängigkeiten hinzugefügt wurden, können Sie das Windows XP Embedded-Image erstellen. Die Images umfassen einfach die Dateien, die auf das Startvolume des Windows XP Embedded-Geräts kopiert werden müssen. Für die Bereitstellung sind keine besonderen Tools erforderlich. Das Windows XP Embedded-Toolset enthält aber einen Remotestartserver, der ähnliche Funktionen aufweist wie die Remoteinstallationsdienste. Hiermit wird die Bereitstellung von Windows XP Embedded-Images direkt auf der Hardware ermöglicht. Im Anschluss an diese Schritte wird ersichtlich, welche Größe das Image tatsächlich erreicht hat. Ein äußerst einfaches Image mit der Explorer-Shell und einigen wenigen Anwendungen, z. B. Editor und Paint, belegt weniger als 90 Megabyte. Natürlich werden nur wenige Benutzer an einem Gerät interessiert sein, auf dem gerade einmal Editor und Paint ausgeführt werden, aber dieses Beispiel verdeutlicht, wie klein ein aufgabenspezifisches Image sein kann.

Windows XP Embedded im Vergleich zu Windows XP
Windows XP Embedded ist auf keinen Fall eine gekürzte Betriebssystemversion. Microsoft stellt vordefinierte Komponenten bereit, mit denen ein Computer, auf dem Windows XP Embedded ausgeführt wird, nahezu denselben Funktionsumfang erhält wie die Vollversion von Windows XP. Hierzu gehören beispielsweise Optionen zum Installieren von DirectX 9.0c, Microsoft® .NET Framework, Windows Media® Player 10 und vieles mehr. Auch eine umfangreiche Entwicklerdokumentation steht bereit, in der die Erstellung benutzerdefinierter Komponenten beschrieben wird (z. B. eine benutzerdefinierte Shell als Ersatz für Explorer), mit der Sie eine individuelle Umgebung für Ihr spezielles eingebettetes Gerät aufbauen.
Windows XP Embedded bietet jedoch nicht jede einzelne Funktion aus der Vollversion von Windows XP Professional. Windows XP Embedded enthält beispielsweise weder WFP (Windows File Protection) noch benutzerfreundliche Funktionen wie die Windows XP-Tour, die Begrüßungsbildschirme, die Assistenten als Konfigurationshilfe für den Benutzer oder das Windows-Setup. Bei Windows XP Embedded kommt die Windows-Produktaktivierung nicht zum Einsatz. Windows XP Embedded-Images werden mithilfe eines Laufzeit-Produktschlüssels aus den Windows Embedded Studio-Tools heraus aktiviert. Darüber hinaus wurde bei Windows XP Embedded ganz auf Windows Update verzichtet, auch wenn diese Lösung einen Microsoft Software Update Services-Server in Ihrer Umgebung nutzen kann. Und schließlich fehlt auch MSN® Explorer in Windows XP Embedded. Dieses Dienstprogramm ist in Windows XP Professional enthalten.
Windows XP Embedded wird in zukünftigen Versionen weiter entwickelt: Das jetzt erhältliche Feature Pack 2007 umfasst verschiedene neue Funktionen, beispielsweise USB-basiertes Starten, eine Verbesserung von EWF, mit der neue Dateien an das übergeordnete Volume übermittelt werden können, ohne gleich die gesamte Überlagerung weiterleiten zu müssen, Unterstützung für die NTFS-Komprimierung und vieles mehr. Diese Verbesserungen erhöhen die Flexibilität und ergänzen die verfügbaren Optionen im Betriebssystem Windows XP Embedded, wodurch sich das System noch stärker dem Funktionsumfang von Windows XP Professional annähert.

In Zukunft Embedded
Eingebettete Systeme erfordern einen etwas höheren Arbeitsaufwand bei der Erstellung als herkömmliche Windows XP-Systeme, bieten jedoch in bestimmten Situationen beträchtliche Vorteile. Trotz des verminderten Funktionsumfangs sind Systeme mit Windows XP Embedded durchaus in der Lage, kleinere Niederspannungs-Hardwaregeräte zu unterstützen, deren Wartung und Reparatur leichter ist und die zudem deutlich weniger kosten. Der reduzierte Energieverbrauch trägt außerdem zu niedrigeren Stromkosten und verminderter Wärmeerzeugung bei, sodass Sie beim Entwerfen kompakter Arbeitsbereiche noch mehr Flexibilität erhalten. Neben den vorgesehenen Einsatzgebieten für Windows XP Embedded (Unterhaltungselektronik, Gesundheitswesen, Kiosks und andere Szenarien, bei denen Windows XP Embedded hinter den Kulissen arbeitet) findet dieses eingebettete Betriebssystem vielleicht auch in Ihrem Unternehmen einen Platz.

Don Jones ist Direktor für Projekte und Dienste bei SAPIEN Technologies und Mitautor von Windows PowerShell: TFM (SAPIEN Presse). Sie erreichen Don Jones über seine Website unter www.ScriptingAnswers.com.


 Verwaltung: Vorausplanen mit System Center Capacity Planner
Verwaltung John Savill

Vorausplanen mit System Center Capacity Planner
Kurz zusammengefasst:
  • SCCP-Grundlagen
  • Erstellen eines neuen Modells
  • Feinabstimmung des Modells
  • Simulieren der tatsächlichen Auslastung

Die Komponenten der modernen Infrastrukturen sind für die Unternehmen, in denen sie eingesetzt werden, von größter Bedeutung. Mit einer wachsenden Anzahl an Benutzern und zunehmend vielseitigen Aktivitäten innerhalb von Unternehmen wird es jedoch immer schwieriger, die Größe und
Anzahl der Server für die Ausführung von Komponenten richtig einzuschätzen. Unzureichende Hardware führt zu langen Antwortzeiten für die Endbenutzer, während zu viel Hardware schlichtweg eine Budgetverschwendung ist und zusätzliche Verwaltungsarbeiten erfordert. Aus diesem Grund hat Microsoft die Anwendung System Center Capacity Planner (SCCP) 2006 entwickelt.
Mit SCCP sind Sie in der Lage, umfassende Angaben zur Netzwerktopologie (Standorte, Linkgeschwindigkeiten, Wartezeiten), zur verwendeten Software und Hardware sowie zu den Nutzungsprofilen einzutragen (beispielsweise die Anzahl der gesendeten Nachrichten). Anschließend werden verschiedene Auslastungsstufen in SCCP simuliert und die Auslastung der Hardware und der Netzwerkkomponenten ausführlich beleuchtet. Diese Modellierung verdeutlicht, ob die vorgeschlagene Konfiguration Ihre Anforderungen an die Dienste angemessen erfüllt.
SCCP muss nicht auf einem bestimmten Server ausgeführt werden und ist nicht auf reine Netzwerktests beschränkt. Dieses Simulationstool kann vielmehr die unterschiedlichsten Testszenarien in einer modellierten Umgebung umsetzen. SCCP stellt nur minimale Systemanforderungen: Windows® XP mit Service Pack 2 (SP2), Windows Server® 2003 oder Windows 2000 mit SP4 und dazu Microsoft® .NET Framework 2.0. Die nächste SCCP-Generation lässt eine noch stärkere Verzahnung mit Systems Management Server (SMS) und Microsoft Operations Manager (MOM) erwarten. Die Informationssammlung wird teilweise automatisiert, da MOM bereits bestimmte Informationen zur Serverauslastung erfasst und SMS die Angaben zur Hardwarekonfiguration enthält.
Die Installation von SCCP 2006 ist denkbar einfach. In einem normalen Installations-Assistenten werden Sie lediglich dazu aufgefordert, den Lizenzvertrag zu akzeptieren und den Installationsordner zu bestätigen. Nach erfolgter Installation des Produkts wird eine Verknüpfung in das Menü „Alle Programme“ eingefügt. Beim ersten Starten von SCCP wird der Begrüßungsbildschirm von Microsoft Capacity Planner angezeigt, über den Sie auf drei der vier Komponenten des Kapazitätsplaners zugreifen (siehe Abbildung 1).
Abbildung 1 Starten des Kapazitätsplanertools
Abbildung 1 Starten des Kapazitätsplanertools
Der Modell-Assistent stellt Fragen zur gewünschten Arbeitsumgebung, auf deren Grundlage ein Systemarchitekturmodell (System Architecture Model, SAM) erstellt wird. Das SAM umfasst ausführliche Angaben zu Standorten, Benutzern, Netzwerk, Nutzungsmustern und Hardware.
Der Modelleditor ermöglicht die Feinabstimmung und Überarbeitung von SAMs, die zuvor über den Assistenten oder den Editor erstellt wurden. Hier können Sie Modelle überprüfen, die simulierte Auslastung abrufen und andere Szenarien testen, beispielsweise eine zusätzliche Last für Mailserver oder die Einbindung von Remotebenutzern.
Der Kapazitätsplaner enthält eine Reihe von vordefinierten Hardwaretypen, die in SAMs verwendet werden können. Wenn Ihre Anforderungen mit den vordefinierten Typen nicht erfüllt werden, unterstützt der Hardwareeditor auch die benutzerdefinierte Definition von Hardwarekonfigurationen.
Sobald Sie ein Modell auswählen, ermöglicht die Kapazitätsplanersimulation verschiedene Tests für das ausgewählte Modell, mit denen die Brauchbarkeit des Modells für die eigentliche Implementierung unter realen Bedingungen ermittelt wird.
Dieses Tool ist die beste Möglichkeit, die Komponenten und ihre Zusammenarbeit untereinander zu betrachten. Im Folgenden soll der Assistent gestartet, eine Simulation durchgeführt und die Feinabstimmung des Architekturmodells mithilfe von benutzerdefinierter Hardware vorgenommen werden. Diese exemplarische Anleitung ist auf eine Exchange-Umgebung abgestimmt, lässt sich jedoch problemlos auf MOM übertragen.

Erstellen eines neuen Modells
Bevor Sie die Validierung oder ein „Was-wäre-wenn“-Szenario auf einer geplanten Infrastruktur vornehmen können, muss die Umgebung in SCCP beschrieben werden. Dies gilt selbst dann, wenn lediglich Szenarien im Zusammenhang mit Ihrer aktuell vorhandenen Infrastruktur durchgeführt werden sollen. In der aktuellen Version ist es leider nicht möglich, das Netzwerk einfach zu scannen. Stattdessen müssen Sie Ihre Infrastruktur anhand einer Vielzahl von Aspekten beschreiben: physische Standorte und die Arten der Konnektivität untereinander, Position von Servern, Postfächern und Benutzern, Angaben zur Nutzung der Umgebung durch die Benutzer.
Für das Tool gelten einige wenige Einschränkungen, die im Benutzerhandbuch ausführlich erläutert werden. Bei Exchange-Modellen wird beispielsweise nur eine einzige Gesamtstruktur unterstützt. Dies bedeutet, dass Domänen in externen Gesamtstrukturen nicht modelliert werden, und für sämtliche Front-End-Server wird angenommen, dass sie sowohl über einen globalen Katalog als auch einen Postfachspeicher auf derselben Site verfügen. Es können nur maximal 100 Sites entworfen werden (davon bis zu 10 Hubsites) und maximal 300 Servercomputer, und es werden nur Outlook® 2003-Clients unterstützt (Internet oder lokal). Die gute Nachricht: SCCP unterstützt bis zu 49.999 Clients an zentralen Standorten und Hubpositionen sowie bis zu 10.000 Clients in Niederlassungen. Exchange-Funktionen wie ActiveSync® oder Outlook Mobile Access-Verbindungen sowie ältere Konnektivitätsoptionen wie POP oder IMAP werden nicht unterstützt. Die Auslastung durch Sicherungs- und Wiederherstellungsvorgänge wird nicht berücksichtigt, und auch Clusterkonfigurationen fallen unter den Tisch. Der Kapazitätsplaner bietet jedoch die erforderlichen Optionen, mit denen die typische tägliche Mailauslastung präzise modelliert werden kann.
Arbeiten Sie nun die Anleitung durch. Wählen Sie im Begrüßungsbildschirm die Option zum Erstellen eines Modells mit dem Modell-Assistenten, und beschreiben Sie die zu modellierende Infrastruktur. Im Folgenden werden Sie ein Unternehmen mit drei Standorten erstellen (zentraler Standort in Dallas, Niederlassungen in Houston und Austin), wobei an jedem Standort eine bestimmte Anzahl lokaler E-Mail-Benutzer tätig ist. Die einzelnen Standorte verfügen nicht unbedingt über eigene Server. Geben Sie daher die Anzahl und die Art der E-Mail-Benutzer an. SCCP berechnet dann die Standorte, an denen lokale Exchange-Server eingerichtet werden sollten und die Benutzer im Remoteverfahren auf einen Exchange-Server zugreifen.
Der Assistent erstellt ein grundlegendes Modell der Infrastruktur im Unternehmen. Anschließend werden Sie aufgefordert, die Anzahl der zentralen Standorte und Niederlassungen anzugeben, die Konnektivität zwischen den Standorten sowie den prozentualen Anteil der Bandbreite, der für Messagingzwecke verwendet werden kann. Der Assistent ist relativ allgemein gehalten. Später können Sie dann die Feinabstimmung des erstellten Modells durch eingehendere Konfiguration der einzelnen Links vornehmen. In diesem Beispiel können Sie den dargestellten zentralen Standort und die beiden Niederlassungen angeben (siehe Abbildung 2). Es gibt T1-Verbindungen zwischen den Niederlassungen und dem zentralen Standort, und für das Messaging steht die Hälfte der Bandbreite zur Verfügung. Die Geschwindigkeit zwischen den zentralen Standorten muss nicht konfiguriert werden, weil nur ein zentraler Standort vorhanden ist.
Abbildung 2 Konfigurieren der WAN-Topologie und der Verbindungsbandbreite
Abbildung 2 Konfigurieren der WAN-Topologie und der Verbindungsbandbreite
Im nächsten Bildschirm des Assistenten werden Sie dazu aufgefordert, die durchschnittliche Anzahl der Benutzer in den Niederlassungen, den E-Mail-Client (Outlook 2003 im zwischengespeicherten Modus oder Outlook Web Access) sowie die Anzahl der Benutzer am zentralen Standort anzugeben. Wieder werden hier nur allgemeine Informationen abgefragt, die später mit dem Modelleditor näher bestimmt werden können. In diesem Fall sollen 200 Benutzer in jeder Niederlassung arbeiten und 500 Benutzer am zentralen Standort. Alle Benutzer verwenden Outlook im zwischengespeicherten Modus.
Der Assistent bietet drei Standard-Mailauslastungsstufen: hoch, mittel, niedrig. Jede Stufe zeichnet sich durch bestimmte Werte aus: durchschnittliche Postfachgröße, Anzahl der gesendeten und empfangenen Nachrichten, durchschnittliche Größe der E-Mail-Nachrichten. Wenn keiner der integrierten Typen dem Nutzungsmuster in Ihrem Unternehmen entspricht, können Sie individuelle Werte für die Nutzungsmerkmale festlegen.
Im nächsten Schritt konfigurieren Sie die Hardwarevoreinstellungen (siehe Abbildung 3). Bei SCCP können bis zu drei mögliche CPU-Konfigurationen angegeben werden, die dann für die Modellierung der Hardware für die verschiedenen Serverrollen zum Einsatz kommen. Die CPU-Konfigurationen reichen von einem einzelnen Pentium III-Xeon-Prozessor mit 1 GHz bis hin zu einem Xeon-MP-Quad-Prozessor mit 3,66 GHz. Exchange 2003 umfasst eine Reihe von Rollen (Postfachspeicher, Bridgehead, Front-End) und dazu die zusätzliche Rolle als globaler Active Directory®-Katalog. Je nach Auslastung ist außerdem eine Option verfügbar, mit der Sie Rollen auf weniger Servern konsolidieren können. Falls die Serverkonsolidierung nicht zugelassen ist, werden selbst dann separate Server für die einzelnen Rollen konfiguriert, wenn der Auslastungsgrad dies noch nicht erfordert. Die automatische Konsolidierung mit SCCP liefert die besten Ergebnisse.
Abbildung 3 Konfigurieren der Hardwareprofile für Server
Abbildung 3 Konfigurieren der Hardwareprofile für Server
Schließlich kann der Typ der verfügbaren Datenträger nach der Schnittstelle, der Größe und der Geschwindigkeit ausgewählt werden. Die Anzahl der Datenträger muss nicht angegeben werden, sondern wird vom Kapazitätsplaner berechnet. Der Kapazitätsplaner kann außerdem ein SAN (Storage Area Network) angeben. Cluster können derzeit allerdings noch nicht erstellt werden.
Im nächsten Schritt des Assistenten wird eine Zusammenfassung des berechneten Modells angezeigt. Diese Zusammenfassung enthält die von SCCP berechnete optimale Anzahl der Server, die Rollen der einzelnen Server sowie weitere Details (z. B. Prozessor, Speicher, Datenträgerkonfigurationen). Falls ein SAN ausgewählt wurde, wird es ebenfalls aufgeführt.
In diesem Beispiel wurden mehrere Standorte ausgewählt. Es ist daher durchaus möglich, dass Server nur für eine Teilmenge der Standorte angezeigt werden. Wenn dieser Fall eintritt, hat SCCP festgestellt, dass der Einsatz lokaler Exchange-Server an einigen Standorten nicht ideal wäre. Stattdessen sollen die Postfächer über einen Exchange-Remotepostfachserver betreut werden, so wie in diesem Beispiel (siehe Abbildung 4). Die 400 Benutzer in den Niederlassungen besitzen somit keinen lokalen Exchange-Postfachspeicher, sondern wurden auf den einzigen Exchange-Postfachspeicherserver am Standort Dallas konsolidiert, für den nunmehr 500 Benutzer angezeigt werden.
Abbildung 4 Zusammenfassung der anfänglichen Kapazitätsplanungsevaluierung
Abbildung 4 Zusammenfassung der anfänglichen Kapazitätsplanungsevaluierung
Bis zu diesem Punkt können Sie mit den Schaltflächen „Zurück“ und „Weiter“ zu den einzelnen Bildschirmen im Assistenten springen und dort die Antworten überarbeiten und die Feinabstimmung der Modellzusammenfassung vornehmen. (Alternativ klicken Sie im linken Navigationsbereich direkt auf die gewünschten Bildschirme des Assistenten.) Wenn Sie mit der Konfiguration zufrieden sind, klicken Sie im Bildschirm mit der Modellzusammenfassung auf die Schaltfläche zum Fertig stellen. Das Modell wird im Modelleditor geöffnet, in dem Sie die Konfiguration detailliert ausarbeiten können.

Feinabstimmung des Modells
Der Modell-Assistent ist ein fantastisches Tool für das Erstellen eines grundlegenden Modells. Sofern die verschiedenen Standorte nicht alle gleich aufgebaut und die Ressourcen gleichmäßig auf alle Standorte verteilt sind, sollten Sie das Modell weiter anpassen, sodass es eine solide Basis für die Berechnung der Auslastung bilden kann. Es ist völlig normal, dass an den verschiedenen Standorten unterschiedlich viele Benutzer tätig sind. Auch eine Kombination der verschiedenen Messaging-Clients, beispielsweise Outlook 2003 mit Zwischenspeicherung und Outlook Web Access (OWA), ist nichts Ungewöhnliches. Im Modell-Assistenten ist diese Detailtiefe bei der Konfiguration nicht zu erreichen, wohl aber im Modelleditor. Dieses Tool zeigt außerdem die Auswirkungen, die sich aus einer Änderung verschiedener Elemente der Umgebung ergeben, beispielsweise aus dem Hinzufügen zusätzlicher Standorte oder zusätzlicher Benutzertypen.
Mit dem Modelleditor (siehe Abbildung 5) können Sie Modelle in SAM-Dateien speichern und Daten aus ihnen abrufen. (Das SAM-Format ist das proprietäre Format des Tools.) Wie bei allen Arbeiten sollten Sie die Modelle in einer Datei speichern, bevor Sie umfangreiche Änderungen vornehmen. Geben Sie der Datei einen beschreibenden Namen, damit keine funktionsfähigen Modelle verloren gehen. Das Dateimenü enthält ein Exportmenü, mit dem sich eine detaillierte Modellzusammenfassung im Excel®-Format sowie als Visio®-Topologiediagramm darstellen lässt.
Abbildung 5 Anpassen einer SAM.Konfiguration im Modelleditor
Abbildung 5 Anpassen einer SAM.Konfiguration im Modelleditor
Im linken Bereich des Modelleditors finden Sie einen einfachen Navigationsbereich mit verschiedenen Optionen, über die Sie die globale Topologie, die Standorttopologie oder eine Modellzusammenfassung abrufen. Die globale Topologie zeigt das Architekturmodell aus Sicht eines Standorts mit zusätzlichen Netzwerken, z. B. dem Internet. Die Standorttopologie liefert Informationen zu einem ausgewählten Standort oder Netzwerk. Die Modellzusammenfassung enthält eine Textzusammenfassung der Umgebung, und zwar im selben Format wie die Angaben am Schluss des Modell-Assistenten.
Bei allen Optionen werden die Details jeweils im mittleren Bereich des Modelleditors angezeigt. Der rechte Fensterbereich ist ganz nach der neuen Version der Microsoft Management Console (MMC) in Windows Server 2003 R2 gestaltet. Hier finden Sie einen „Aktionsbereich“, der wiederum in zwei Teilbereiche gegliedert ist: Der obere Teil enthält kontextabhängige Aktionen, die je nach der aktuellen Ansicht oder dem ausgewählten Objekt wechseln, während der untere Teil die immer anwendbaren, allgemeinen Aktionen umfasst. Mit diesen Aktionen können Sie einen neuen Standort hinzufügen, die Nutzungsprofile der Benutzer bearbeiten und eine Simulation starten.
Im mittleren Bereich des Modelleditors sind alle Elemente auswählbar. Bei Auswahl eines Elements werden die zugehörigen Aktionen eingeblendet, und Sie können weitere Details zum Objekt aufrufen. Wenn Sie beispielsweise auf einen Standort doppelklicken, gelangen Sie zur Standorttopologie mit Details zu den Objekten, die für diesen Standort modelliert wurden. Bei einem lokal betreuten Standort würden entsprechend ein oder mehrere Server, Netzwerke und die Benutzer am Standort aufgeführt. Damit können Sie wiederum auf das ausgewählte Objekt doppelklicken, um detaillierte Eigenschaften abzurufen und nach Bedarf zu bearbeiten.
Die Linien zwischen den Standorten stellen die jeweiligen Netzwerke dar und können bearbeitet werden, um so das Netzwerk eingehend zu konfigurieren. Sie können beispielsweise verschiedene Bandbreitengeschwindigkeiten für Aufwärts- und Abwärtsstrecken sowie den verfügbaren Bandbreitenprozentsatz angeben. Darüber hinaus können Sie die Verbindungslatenz konfigurieren, die ein sehr wichtiger Faktor für eine stabile Kommunikation sein kann. Häufig werden auch zusätzliche Benutzertypen eingefügt. In diesem Beispiel wird angenommen, dass mehrere Clients mit Outlook Web Access bzw. mit Outlook 2003 vorliegen, die vom zentralen Standort aus betreut werden. Öffnen Sie die Standorttopologie für den Standort Dallas. Wählen Sie nun die Option zum Hinzufügen eines Clientprofils, und geben Sie die erforderlichen Informationen für die OWA-Benutzer ein, unter anderem den Server, auf den die OWA-Clients zugreifen, das Netzwerk, über das die Verbindung erfolgt, sowie die verfügbare Bandbreite (siehe Abbildung 6).
Abbildung 6 Unkompliziertes Hinzufügen und Bearbeiten von Elementen in einem Modell
Abbildung 6 Unkompliziertes Hinzufügen und Bearbeiten von Elementen in einem Modell
Wenn die vorhandene bzw. geplante Infrastruktur so genau wie möglich im SAM dargestellt ist, speichern Sie das SAM unter einem aussagekräftigen Namen, sodass Sie es mühelos wieder auffinden und als Ausgangspunkt für künftige Änderungen heranziehen können. An dieser Stelle soll eine Simulation als Benchmark ausgeführt werden, um die Leistung des Modells mit den konfigurierten Einstellungen festzustellen. Auf Grundlage dieses Benchmarktests können Sie das Modell anpassen und verschiedene „Was-wäre-wenn“-Szenarien testen (z. B. Hinzufügen eines weiteren Standorts und weiterer Benutzer, Hinzufügen oder Entfernen von Servern, Hinzufügen weiterer Benutzer zu vorhandenen Standorten, Ändern des Verbindungstyps oder des E-Mail-Clients). Nach Aktualisieren des Modells mit diesen neuen Elementen können Sie eine weitere Simulation ausführen, um die Auswirkungen der neuen Konfiguration zu ermitteln.

Simulieren der tatsächlichen Auslastung
Zum Starten der Simulation klicken Sie einfach auf die allgemeine Aktion für das Ausführen einer Simulation oder auf die entsprechende Schaltfläche in der Symbolleiste. Als Erstes wird eine Zustandsprüfung des Modells vorgenommen: Vor dem Ausführen der Simulation werden sämtliche Fehler im Modell aufgeführt. Wenn Sie beispielsweise eine Reihe von OWA-Clients in ein Modell aufnehmen, in dem bislang keine OWA-Clients vorlagen und kein Front-End-Server konfiguriert war, erhalten Sie eine Fehlermeldung, dass kein Front-End-Server vorhanden ist. Liegen keine Fehler vor, wird der Fortschritt der Simulation angezeigt.
Nach Abschluss der Simulation wird ein Ergebnisbericht mit ausführlichen Informationen zur Auslastung aller Komponenten erstellt und geöffnet. Zu Beginn sehen Sie eine Zusammenfassung mit allgemeinen Angaben zur Auslastung der CPU, des Speichers und der Verbindungslinks (häufige Ursachen für Engpässe) sowie zu den längsten Transaktions- und Latenzzeiten, die sich möglicherweise auf den Endbenutzer auswirken. Über die Links im linken Bereich der Simulation können Sie ausführliche Angaben zur Auslastung der Server, des SAN sowie der lokalen und externen Verbindungen abrufen (siehe Abbildung 7).
Abbildung 7 Zusammenfassung der Simulationsergebnisse für ein einfaches Modell
Abbildung 7 Zusammenfassung der Simulationsergebnisse für ein einfaches Modell
Wenn Sie mit der Maus auf die verschiedenen Diagramme zeigen, beispielsweise auf die Engpass-Analyse, sehen Sie den Server und das Attribut des Servers, der diesen Engpass verursacht. Beachten Sie die Einstellungen für die Grenzwerte im linken Bereich. In dieser Kategorie können Sie individuelle Werte für die Auslastung festlegen, bei deren Überschreiten eine Warnung ausgegeben werden soll – eine äußerst nützliche Funktion.
Die ausführlichen Simulationsberichte helfen nicht nur bei der Hardware-Kaufentscheidung, sondern zeigen auch die Menge der Netzwerkressourcen, die von den Messaging-Anwendungen genutzt werden. Bei Benutzern, die eine Verbindung über langsamere WAN-Links herstellen, zeigt der Bericht beispielsweise, ob der Link schnell genug ist. Ist dies nicht der Fall, können Sie überprüfen, ob die Geschwindigkeit der Verbindung zwischen den Standorten erhöht oder ob ein lokaler Postfachspeicherserver hinzugefügt werden sollte. Ändern Sie hierzu das Modell einfach entsprechend ab, und führen Sie die Simulation erneut durch, bis Sie die richtigen Ergebnisse für Ihre Kriterien erhalten. Noch ein Beispiel: Laufen alle Server mit einer CPU-Auslastung von 5 Prozent, können Sie Spezifikation der Server senken. Dank der unkomplizierten Möglichkeiten, das Modell zu ändern und die Simulation zu wiederholen, können Sie ganz nach Belieben mit den verschiedensten Lösungsoptionen experimentieren. Wenn Sie dann genaue Metriken aus allen getesteten Szenarien ermittelt haben, braucht Ihnen die nächste Budget- und Planungsbesprechung keine Sorgen mehr zu machen.

Zusammenfassung
Dieser Artikel bietet nur einen kurzen Überblick, wie Sie mit SCCP die Exchange-Bereitstellung simulieren und analysieren können. Beachten Sie, dass die Modellierungs- und Simulationsfunktionen von SCCP auch ideal für MOM geeignet sind. SCCP steht derzeit in den MSDN® Premium-Downloads und im TechNet Plus zum Herunterladen bereit. ¦

John Savill ist Direktor für technische Infrastruktur bei Geniant. Savill ist zertifizierter Sicherheitsexperte für Informationssysteme (Certified Information Systems Security Professional, CISSP), Microsoft Certified Systems Engineer (MCSE) für Sicherheit und Messaging unter Windows Server 2003, achtfacher MVP sowie Krav Maga-Dozent. Außerdem hat Savill das Buch Windows Server 2003 Active Directory Design and Implementation (Herausgeber: Packt Publishing) verfasst.


 Verwaltung: Erweiterte Clientinventuren mit SMS
Verwaltung Wes Dobry

Erweiterte Clientinventuren mit SMS
Kurz zusammengefasst:
  • Verwenden des SMS 2003 Hardwareinventur-Agent
  • Erweitern der Bestandserfassung mit MIF-Dateien
  • Dynamische und statische MOF-Dateien
Laden Sie den Code für diesen Artikel herunter: DobrySMSInventory2007_04.exe (152KB)

Jedem Administrator wird es irgendwann passieren, dass sein Chef nach Informationen fragt, die nur mit enormem Arbeitsaufwand zusammengestellt werden können. Was wäre aber, wenn Sie als Administrator schon proaktiv gehandelt
und die Informationen bereits gesammelt hätten? Sie könnten Ihrem Chef die Informationen unverzüglich liefern, dabei unnötige Ausfallzeiten und Überstunden vermeiden und dem Unternehmen möglicherweise viel Geld sparen. Sie wären der Held der Stunde!
Standardmäßig sammelt Microsoft® Systems Management Server (SMS) 2003 eine Unmenge an Informationen. Aber eben nicht alles. Zum Beispiel berichtet SMS 2003 nicht standardmäßig über lokale Gruppen und ihre Mitglieder oder lokale Benutzer und ihre Attribute. Das Nichtvorhandensein dieser Informationen kann zu einem Problem führen, wenn ein Techniker beispielsweise Domänenbenutzer oder, noch schlimmer, jeden zur lokalen Administratorengruppe auf jedem System zuweist, an dem sie arbeiten. Oder angenommen, ein Unternehmen hat keine Möglichkeit, Informationen zur lokalen Datei und zu Ordnerausschlusslisten für unternehmerische Antivirus-/Antispyware-Lösungen zu erhalten. Dies mag als kein großes Problem erscheinen, bis jemand in der IT-Abteilung feststellt, dass Benutzer c:\*.* in die Ausschlussliste stellen.
Mit der richtigen Kombination aus Skripting, Windows® Management Instrumentation (WMI) und SMS-Kenntnissen können Sie SMS-Bestände so erweitern, dass sie nahezu jegliche Informationen enthalten. Dies wird durch die Verwendung von MIF (Management Information Format) und MOF (Management Object Format)-Dateien ermöglicht.

Bestand erfassen
Mit SMS können Organisationen individuelle Bereitstellungen durchführen, Ziele überwachen und die Bereitstellungssysteme verwalten. Durch Erweiterung von SMS-Beständen können Sie ein sehr viel angepassteres Ziel erstellen und verwalten. Sie können beispielsweise lokale Unternehmenssicherheitsrichtlinien durch Bereitstellung Ihrer Sicherheitsrichtlinien für Systeme durchsetzen, deren Richtlinien von einem Benutzer verändert wurden. Sie können auch nicht genehmigte lokale Benutzerkonten deaktivieren und überflüssige lokale Administratoren entfernen.
Selbstverständlich verlassen sich Unternehmen auch auf SMS, um rechtzeitige, detaillierte Informationen zu Clientsystemen zu erhalten. Eine Erweiterung der Bestände ermöglicht Ihnen die Erstellung von Berichten, die vollständige benutzerdefinierte Informationen enthalten, die bei Verlass auf die Standardinventare nicht sofort zur Verfügung stehen. Die Informationen können außerdem sehr fein abgestimmt werden. Sie können beispielsweise einen Bericht über die Zahl der Systeme erstellen, die über einen bestimmten Registrierungsschlüssel verfügen, der auf eine bestimmte Serverfarm verweist. Dies würde den Administratoren eine ungefähre Einschätzung ermöglichen, wie viele Clients zu einem bestimmten Zeitpunkt auf jede Farm verweisen. Ähnlich kann das Sicherheitsteam prüfen, welche Systeme auf dem Netzwerk einen bestimmten Prozess ausführen, der als Spyware bekannt ist.
Der Wert von MIF- und MOF-Dateien liegt in der Fähigkeit, Informationen aus nahezu beliebigen Quellen mit minimaler Übersetzung einzugeben. Solange die Informationen textbasiert sind, können sie geändert und in eine WMI- oder MOF-Datei gestellt werden, oder in Form einer MIF-Datei gesammelt und im nächsten Hardwarebestandszyklus gesendet werden. Das Implementieren einer Bestandserweiterung erfordert VBScript- oder JScript®-Kenntnisse, sowie Kenntnisse darüber, was erfasst werden soll. Wenn man bedenkt, dass fast alles gesammelt werden, kann, rangieren die erforderlichen Kenntnisse von WMI bis hin zu erweiterter SQL. Selbstverständlich ist das Verständnis von SQL ganz unabhängig vom zu erfassenden Informationstyp ein Muss, da Sie dieses Wissen für die Berichterstattung über die gesammelten Informationen benötigen.

So funktionieren Bestände
SMS beinhaltet zwei Arten von Bestandserfassungen: Hardware und Software. Softwarebestände verfügen nur über Informationen zu Dateien, beispielsweise, wo sie gespeichert sind, um welche Versionen es sich handelt, ihre Größe, und sonstige Dateiattribute. Die Softwarebestandserfassung ermöglicht Ihnen jedoch auch die Erfassung von Dateien und deren Speicherung auf dem Standortserver.
Eine Erweiterung der Hardware-Bestandserfassung ist einfach, da Hardwarebestände die größte Menge an Informationen zu einem System enthalten. Die in Hardwarebeständen enthaltenen Informationen stammen vor allem aus WMI, der Registrierung und dem System-BIOS.
Hardwarebestände werden nach einem Zeitplan erfasst, der in den Hardwareinventur-Agent-Siteeinstellungen auf SMS 2003 festgelegt wird. Sammlungen können auf Wunsch im Minutentakt oder lediglich alle paar Monate stattfinden. Am besten ist es, einen Mittelweg zu finden, nach dem diese Informationen so schnell wie vom Management gefordert erfasst werden, jedoch ohne das Netzwerk, Siteserver, Verwaltungspunkte oder Clients zu belasten.
Wenn der Hardwareinventur-Agent zum ersten Mal installiert wird, kompiliert er die sms_def.mof-Datei. Diese enthält alle Informationen, die SMS anfänglich sammelt. Wenn diese Datei kompiliert wird, werden alle SMS-Namespaces und verbundenen Klassen, die für den Hardwareinventur-Agent erforderlich sind, in WMI erstellt. Die meisten befinden sich im Namespace \\.\root\CIMv2\SMS. Nach der Installation durchsucht der Hardwareinventur-Agent die meisten dieser Klassen, um die Informationen zusammenzustellen, die daraufhin an den Verwaltungspunkt und schließlich die Sitedatenbank gesendet werden.

MIF-Dateien
Zusätzlich zum Abrufen von Informationen aus diesen WMI-Klassen sucht der Hardwareinventur-Agent nach MIF-Dateien in den NOIDMIF- und IDMIF-Sammlungsordnern. Alle MIF-Dateien aus diesen Speicherorten werden im nächsten Hardwarebestand verarbeitet.
MIF-Dateien bieten die einfachste Möglichkeit, den SMS-Hardwarebestand zu erweitern. Es gibt zwei Arten von MIF-Dateien: NOIDMIF- und IDMIF-Dateien. Diese Dateien sind statische, XML-artige Dateien, die nahezu jegliche Informationen enthalten können, die ein Benutzer möglicherweise zur SMS-Datenbank hinzufügen möchte. Sie können mit denselben Methoden wie herkömmliche Textdateien erstellt werden. Die Dateien können also mit den meisten Skriptsprachen oder manuell erstellt werden.
Normalerweise werden MIF-Dateien in Situationen verwendet, in denen die Informationen nicht in der Registrierung oder in WMI enthalten sind, oder wenn die Informationen manuell eingegeben werden müssen. Diese Dateien können beispielsweise erstellt werden, wenn das Hardwarebereitstellungssystem ein neues System liefert. Der Bereitstellungstechniker navigiert zu einer HTML-Anwendung auf dem System und gibt alle Bestandsinformationen ein, die für die Aktualisierung einer Bestandsverwaltungsdatenbank verwendet werden sollen. Diese Anwendung erstellt daraufhin dynamisch eine NOIDMIF-Datei und ermöglicht dem Techniker, die Datei zum NOIDMIF-Dateisammlungsordner herunterzuladen. Diese NOIDMIF-Datei enthält alle vom Techniker eingegebenen Informationen und wird in die SMS-Datenbank integriert.
NOIDMIF- und IDMIF-Dateien unterscheiden sich nur geringfügig. Eine IDMIF-Datei enthält einen einmaligen Header, der Architekturinformationen und eine einmalige ID bereitstellt. IDMIF-Dateien können verwendet werden, um systemfremde Geräte als ihre eigenen Entitäten in SMS zu integrieren. Ein Skript kann beispielsweise verwendet werden, um Systeme in SMS zu erstellen, bei denen es sich tatsächlich um Drucker handelt, und um Informationen über sie in die SMS-Datenbank zu schreiben.
NOIDMIF- und IDMIF-Dateien werden in Standardspeicherorten gespeichert, die durch die Registrierungsschlüssel vorgegeben werden. Meistens handelt es sich dabei um %SYSTEMROOT%\system32\ccm\Inventory\NOIDMIF und ...\IDMIF, vorausgesetzt, dass der SMS-Agent im Standardspeicherort installiert wurde. Wenn der Agent in einem benutzerdefinierten Speicherort installiert wurde, sollten sich die MIF-Verzeichnisse in %CCMAGENTINSTALLDIR%\Inventory\NOIDMIF und ...\IDMIF befinden. Wenn Zweifel hinsichtlich der Speicherorte dieser Verzeichnisse besteht, finden Sie die Speicherorte in den folgenden Registrierungsschlüsseln aufgelistet:
HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\
Client\Configuration\Client Properties\NOIDMIF Directory

HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\
Client\Configuration\Client Properties\IDMIF Directory
MIF-Dateien verfügen immer über dasselbe Format, unabhängig von den erfassten Informationen. Die MIF-Datei in Abbildung 1 besteht aus einer einzelnen Komponente, die mehrere Gruppen und ein einzelnes Attribut in jeder Gruppe enthält. Alle Abschnitte sind erforderlich, obwohl nicht mehr als ein Gruppen- oder Attributeintrag notwendig ist. Sie könnten es so sehen, dass jede Gruppe in der MIF-Datei eine Zeile der Daten des benannten Abschnitts im Hardwarebestand ist, und jedes Attribut in der Gruppe eine Spalte dieser Zeile.
Figure 1 LocalAdmins.mif (Close Figure 1)
Start Component
  Name = “WORKSTATION”
    Start Group
        Name = “Local Admins”
        ID = 1
        Class = “Microsoft|LocalAdminsMIF|1.0”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Contoso’,Name=’Domain Admins’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 2
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Contoso’,Name=’Technicians’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 3
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Example-PC’,Name=’Administrator’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 4
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Example-PC’,Name=’RandomUser’”
        End Attribute
    End Group
End Component
Das Beispiel LocalAdmin.vbs, das in Abbildung 2 gezeigt wird, ist ein relativ einfaches VBScript. Es sucht nach dem NOIDMIF-Verzeichnis, löscht die temporäre MIF-Datei, sofern vorhanden, erstellt die temporäre MIF-Datei, schreibt erfasste Informationen über eine einfache WMI-Abfrage rekursiv in die Datei, löscht die im NOIDMIF-Sammlungsordner enthaltene MIF-Datei und verschiebt die temporäre NOIDMIF daraufhin in den NOIDMIF-Sammlungsordner.
Figure 2 LocalAdmin.vbs (Close Figure 2)
On Error Resume Next

Const ForAppending = 8

Set objWshShell = CreateObject(“WScript.Shell”)
Set objFSO = CreateObject(“Scripting.FileSystemObject”)

strTempDir = objWshShell.ExpandEnvironmentStrings(“%TEMP%”)
strWinDir = objWshShell.ExpandEnvironmentStrings(“%WINDIR%”)
strComputerName = objWshShell.ExpandEnvironmentStrings(“%COMPUTERNAME%”)
strNoIDMifRegLocation = “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Client\Configuration\Client “ _
   & “Properties\NOIDMIF Directory”
strNoIDMifDirectory = objWshShell.RegRead(strNoIDMifRegLocation)
strMifFileName = “\LocalAdmins.mif”
strClassID = “Microsoft|LocalAdminsMIF|1.0”

If objFSO.FileExists(strTempDir & strMifFile) Then
   objFSO.DeleteFile(strTempDir & strMifFile)
End If

Set objMifFile = objFSO.OpenTextFile(strTempDir & strMifFileName, ForAppending, True)

objMifFile.Writeline “Start Component”
objMifFile.Writeline “ Name = “ & Chr(34) & “WORKSTATION” & Chr(34)

strWBEMQuery = “SELECT partcomponent FROM win32_groupuser WHERE groupcomponent = “ & Chr(34) _
   & “\\\\” & strComputerName & “\\root\\cimv2:Win32_Group.Domain=\” & Chr(34) & strComputerName _
   & “\” & Chr(34) & “,Name=\” & Chr(34) & “Administrators\” & Chr(34) & Chr(34)

Set objWBEM = CreateObject(“WbemScripting.SWbemLocator”)
Set objWBEMServer = objWBEM.ConnectServer(, “root\cimv2”)
Set colResults = objWBEMServer.ExecQuery(strWBEMQuery)

i = 1
For Each objItem in colResults
         objMifFile.Writeline “ Start Group”
         objMifFile.Writeline “ Name = “ & Chr(34) & “Local Admins” & Chr(34)
         objMifFile.Writeline “ ID = “ & i
         objMifFile.Writeline “ Class = “ & Chr(34) & strClassID & Chr(34)
         objMifFile.Writeline “ Start Attribute”
         objMifFile.Writeline “ Name = “ & Chr(34) & “Account” & Chr(34)
         objMifFile.Writeline “ ID = 1”
         objMifFile.Writeline “ ACCESS = READ-ONLY”
         objMifFile.Writeline “ Storage = Specific”
         objMifFile.Writeline “ Type = String(100)”
         strUserName = objItem.PartComponent
         strUserName = mid(strUserName, instr(1, strUserName, chr(58)) + 1)
         If Instr(1, strUserName, Chr(92), 1) > 0 Then
                  strUserName = Replace(strUserName, Chr(92), Chr(92) & Chr(92), 1, -1, 1)
         End If
         If Instr(1, strUserName, Chr(34), 1) > 0 Then
                  strUserName = Replace(strUserName, Chr(34), Chr(39), 1, -1, 1)
         End If

         objMifFile.Writeline “ Value = “ & Chr(34) & strUserName & Chr(34)
         objMifFile.Writeline “ End Attribute”
         objMifFile.Writeline “ End Group”
         i = i + 1
Next

objMifFile.Writeline “End Component”
objMifFile.Close

If objFSO.FileExists(strNoIDMifDir & strMifFileName) Then
   objFSO.DeleteFile(strNoIDMifDir & strMifFileName)
End If

objFSO.MoveFile strTempDir & strMifFileName, strNoIDMifDir & strMifFileName
MIF-Dateien stellen zwar eine einfache Möglichkeit dar, den SMS-Hardwarebestand zu erweitern, aber es müssen bestimmte Punkte bei der Verwendung berücksichtigt werden. MIFs werden in jedem Hardwarebestandszyklus verarbeitet. Da diese Dateien jedoch erstellt, erfasst, analysiert und schließlich zum Bestand hinzugefügt werden, werden die in einer MIF enthaltenen Informationen u. U. um bis zu einen Hardwarebestandszyklus verspätet angezeigt. Wenn ein Unternehmen also über eintägige Hardwarebestandszyklen verfügt, könnten die Daten in der Sitedatenbank bis zu zwei Tage verspätet angezeigt werden. Sie müssen daher gut überlegen, wann die Programme, die MIF-Dateien erstellen, angekündigt werden, und wann der Hardwarebestandszyklus ausgeführt wird.
Angenommen, ein Unternehmen namens Contoso verfügt über eintägige Bestandszyklen, die um Mitternacht ausgeführt werden. Am Montag um 1 Uhr morgens wird ein VBScript ausgeführt und erstellt eine NOIDMIF-Datei, die die Ausgabe eines Rootkitscanners enthält. Diese Ausgabe wird um Mitternacht erfasst und dem Verwaltungspunkt gemeldet. Der Contoso SMS-Administrator sieht sich daraufhin die Informationen am Mittwoch Abend gegen 22.00 Uhr an und stellt fest, dass sie bereits 45 Stunden alt sind. Dies liegt daran, dass der SMS-Administrator nicht richtig überlegt hat, wann das Programm, das für die Erstellung der NOIDMIF-Datei verwendet wird, angekündigt wird.

MOF-Dateien
MOF-Dateien sind komplizierter als MIF-Dateien. MOF-Dateien verfügen im Gegensatz zu MIFs über den Vorteil, dass sie Informationen direkt in WMI eingeben und dem Standarddatensammlungsprozess des Hardwareinventur-Agent hinzugefügt werden. Folglich müssen Sie ein VBScript nicht immer wieder neu ankündigen, um Informationen zu erhalten, was Zeit und Aufwand erspart. Sie können das MOF stattdessen einmal pro Computer ankündigen, und daraufhin wird es kompiliert.
MOF-Dateien haben außerdem den Vorteil, dass die Informationen genauso aktuell sind wie der Rest der Informationen im Hardwarebestand. Jedes Mal, wenn der Hardwareinventur-Agent den Zyklus durchläuft, werden die in der MOF-Datei angegebenen Klassen und Anbieter abgefragt und die Informationen schnell zurückgegeben. Für eine schnelle Informationssammlung führen Sie ein Paket aus, das die MOF-Datei und ein VBScript enthält und starten eine Hardwareinventur. Die gewünschten Informationen werden daraufhin in nur einem angekündigten Programmrichtlinienzyklus erfasst.
Es gibt drei Klassifizierungen für MOF Dateien: MOF-Dateien für eine vorhandene WMI-Klasse und Namespace, MOF-Dateien für eine zusätzliche Klasse mit einem vorhandenen WMI-Anbieter, und MOF-Dateien für eine zusätzliche Klasse, die über keinen WMI-Anbieter verfügt.
MOF-Dateien bestehen aus zwei Teilen. Der erste Teil ist der Namespace-Definitionsabschnitt. Hier werden die WMI-Anbieterinformationen identifiziert. Der zweite Abschnitt enthält SMS-Berichtserstellungsattribute. Dieser Abschnitt weist den Hardwareinventur-Agent an, wo nach den in den erwähnten WMI-Klassen enthaltenen Informationen gesucht werden soll und wie die Informationen verarbeitet werden sollen. Da MOF-Dateien direkt mit WMI arbeiten, sollten Sie sich meiner Meinung das Microsoft WMI Software Development Kit (SDK) genauer ansehen, wenn Sie mit diesen Dateien arbeiten wollen (weitere Informationen finden Sie unter go.microsoft.com/fwlink/?LinkID=83121).
Jede der oben erwähnten Klassifikationen von MOF-Dateien kann entweder statisch oder dynamisch sein. Sie verfügen beispielsweise über eine statische MOF-Datei, wenn Sie das Build-Verfahren des Unternehmens anweisen, eine MOF-Datei zu kompilieren, die Informationen darüber enthält, wer das System erstellt hat, welche Serverbuilds verwendet wurden, was die ursprünglichen Build-Versionen waren, das Datum, an dem der Computer erstellt wurde usw. Diese Informationen müssen nie aktualisiert werden, daher können sie direkt zur MOF-Datei hinzugefügt und in WMI mithilfe von mofcomp.exe. kompiliert werden. Nach diesem Vorgang muss der Bereich, den der Hardwareinventur-Agent durchsucht, durch Hinzufügen der Gruppen- und Klasseninformationen zur sms_def.mof-Datei auf dem Standortserver erweitert werden.
Eine dynamische MOF-Datei ähnelt einer statischen MOF-Datei, mit dem Unterschied, dass Daten über einen WMI-Anbieter erfasst werden, statt direkt in WMI geschrieben zu werden. Ein WMI-Anbieter ist ein Plug-In, das einer Anwendung oder einem Dienst die direkte Eingabe von Informationen in WMI ermöglicht. Dieser Anbieter erlaubt dynamischen Zugriff auf andere Bereiche von WMI und des Systems, wie die Registrierung, Dateispeicherorte und Windows Installer-Informationen
In Bezug auf ein Arbeiten mit MOF-Dateien ist die einfachste Möglichkeit für eine Verbesserung des Hardwarebestands, wenn der Bestandskatalog mehr als die bereits in WMI aufgeführten Informationen enthält. Dies erfolgt durch Erweiterung der sms_def.mof oder Aktivieren zusätzlicher Berichtsklassen, die zurzeit deaktiviert sind. Die sms_def.mof-Datei befindet sich im Ordner \\siteserver\SMS_<sitecode>\inboxes\clifiles.src\hinv. Alle Geräte im Unternehmen rufen die neue sms_def.mof auf ihrem nächsten Computerrichtlinienzyklus ab und beginnen mit der Informationssammlung und Berichterstellung.
Die nächste Schwierigkeit besteht darin, einen vorhandenen WMI-Anbieter unter Erstellung einer neuen Klasse zu verwenden. Ein Beispiel dieses Ansatzes wird in Abbildung 3 dargestellt. In diesem Beispiel wird die Klasse CU_Desktop mithilfe des integrierten Registrierungsanbieters mit einer dynamischen Eigenschaft erstellt, die HKEY_CURRENT_USER\Control Panel\Desktop\Wallpaper auf dem lokalen Gerät abruft. Wenn diese MOF-Datei auf dem Client kompiliert wurde, müssen die in SMS_Def_Extension.mof (siehe Abbildung 4) enthaltenen Informationen an sms_def.mof angehängt werden. Die Datei enthält Informationen dazu, ob SMS darüber Bericht erstatten soll, den Gruppennamen, die Klassenkennung, nach welcher Klasse der Hardwareinventur-Agent in WMI suchen soll, um die Informationen für den Bericht zu finden, und schließlich die eigentlichen Werte.
Figure 4 SMS_Def_Extentions.mof (Close Figure 4)
#pragma namespace ("\\\\.\\root\\CIMv2\\sms")
 [ SMS_Report    (TRUE),
  SMS_Group_Name ("Current User Desktop"),
  SMS_Class_ID   ("MICROSOFT|CU_Desktop|1.0") ]
class Power_Mgmt : SMS_Class_Template
{
    [SMS_Report(TRUE),key]
        string  index;
    [SMS_Report(TRUE)]
    sint32   CurrentUserDesktop;
};
Figure 3 CurrentUserDesktop.mof (Close Figure 3)
#pragma namespace(“\\\\.\\root\\CIMv2”)
// Registry property provider
instance of __Win32Provider as $PropProv
{
    Name    =”RegPropProv” ;
    ClsID   = “{72967901-68EC-11d0-B729-00AA0062CBB7}”;
    ImpersonationLevel = 1;
    PerUserInitialization = “FALSE”;
};
instance of __PropertyProviderRegistration
{
    Provider       =$PropProv;
    SupportsPut    =TRUE;
    SupportsGet    =TRUE;
};
[DYNPROPS]
class CU_Desktop
{
    [key]
    string  index = “current”;
    sint32 CurrentUserDesktop;
};
[DYNPROPS]
instance of CU_Desktop
{
     [PropertyContext(“local|HKEY_CURRENT_USER\\Control Panel\\Desktop|Wallpaper”),
        Dynamic, Provider(“RegPropProv”)]
        CurrentUserDesktop;
};
MOF-Dateien verfügen außerdem über die Möglichkeit, auf die von WMI-Anbietern gebotenen Informationen zuzugreifen, die nicht standardmäßig auf Systemen enthalten sind. Um diese Anbieter zu verwenden, muss der WMI-Anbieter zunächst verteilt und installiert werden, bevor die MOF-Datei auf dem Client kompiliert und sms_def.mof erweitert wird.

Zusammenfassung
MIF- und MOF-Dateien sind leistungsfähige Tools für ein schnelles und relevantes Sammeln von Informationen. Diese Dateiformate bieten den Rahmen für eine einfache Bereitstellung von Informationen in der SMS-Datenbank ohne direkte Änderung der Tabellen. Mit etwas Phantasie kann für nahezu alles eine Inventur und die entsprechende Berichterstattung durchgeführt werden. Noch besser aber ist, dass Problemsituationen vermieden werden, da Administratoren durch proaktives Handeln wichtige Informationen sammeln können.
Das Verständnis von MIF- und MOF-Dateien geht nicht von heute auf morgen vor sich. Es stehen jedoch nützliche Ressourcen zur Verfügung, die Ihnen bei der Verwendung dieser Dateien behilflich sein können. Sehen Sie sich zunächst einmal die WMI-Dokumentation und SDK an, sowie das Systems Management Server 2003 Betriebshandbuch. Wenn Sie sich die Mühe machen, diese Konzepte zu verstehen, überwiegen die Vorteile einer erweiterten SMS-Bestandserfassung bei weitem den anfänglich erforderlichen Aufwand.

Wes Dobry lebt in den USA in Orlando, Florida und arbeitet als Berater und Netzwerkadministrator für ein großes Gesundheitsunternehmen. Sie erreichen ihn unter: wesdobry@desktopstandard.com.


 Verwaltung: Bereitstellen von benutzerdefinierten Softwareupdates mit SMS&#160;2003&#160;R2
Verwaltung Steve Rachui

Bereitstellen von benutzerdefinierten Softwareupdates mit SMS 2003 R2
Kurz zusammengefasst:
  • Neue Updateverwaltungsfunktionen in SMS 2003 R2
  • Das Veröffentlichungstool für benutzerdefinierte Updates
  • Das Inventurtool für benutzerdefinierte Updates

Wenn Sie benutzerdefinierte Updates für Ihre Systeme bereitstellen müssen, beispielsweise für spezielle Hardware oder für Branchenanwendungen, profitieren Sie nicht von den Vorteilen eines verwalteten, automatisierten Prozesses wie bei Windows-Updates. Aber das ändert sich jetzt. Dank Systems Management
Server (SMS) 2003 R2 sind Sie nunmehr in der Lage, Ihre eigenen benutzerdefinierten Updates mit genau den Funktionen für verwaltete Updates bereitzustellen. SMS 2003 R2 umfasst eine Reihe neuer Funktionen, beispielsweise ein Update für das Device Management Feature Pack, Links zum Operating System Deployment (OSD) Feature Pack und viele weitere Funktionen, durch die die Sicherheitsüberwachung optimiert wird. Das Produkt enthält ein Scantool zur Bewertung von Sicherheitsanfälligkeiten, mit dem sich potenzielle System- und Netzwerksicherheitsrisiken erkennen lassen, z. B. Schwächen bei Betriebssystemkonfiguration, Benutzerkennwörtern sowie bei IIS- und SQL Server™-Konfigurationen. Auch ein Inventurtool für benutzerdefinierte Updates (Inventory Tool for Custom Updates, ITCU) und ein Veröffentlichungstool für benutzerdefinierte Updates (Custom Updates Publishing Tool, CUPT) stehen zur Verfügung. Diese beiden Tools bilden den Schwerpunkt des vorliegenden Artikels, sodass Sie Ihre eigenen benutzerdefinierten Updates unkompliziert und effizient bereitstellen können.

Veröffentlichungstool für benutzerdefinierte Updates (CUPT)
Bevor Sie SMS 2003 R2 installieren und verwenden können, muss die gesamte Hierarchie (auch die Clients) auf SMS 2003 Service Pack 2 (SP2) aktualisiert werden. Für CUPT ist die Aktualisierung auf Microsoft® Management Console (MMC) 3.0 erforderlich. CUPT muss nicht unbedingt auf dem SMS-Standortserver installiert werden, die Installation erfordert jedoch Windows® XP (oder höher), wobei die Datenbank unter SQL Server 2005 gehostet werden muss. Darüber hinaus muss SQL Server Express Edition installiert werden, sofern nicht SQL Server 2005 verfügbar ist. CUPT ist der Schlüssel für die Einführung und Verwaltung benutzerdefinierter Updates im SMS-System. Dieses Tool umfasst auch verschiedene Funktionen, mit denen Sie die erstellten Kataloge vor dem Veröffentlichen in SMS zunächst testen können.
Die benutzerdefinierten Updates sind entweder Updates von Drittanbietern für die von ihnen produzierte Software oder aber intern erstellte Updates, die auf eine bestimmte Umgebung ausgerichtet sind. Mit CUPT lassen sich beide Updatetypen mühelos verwalten. Die Verwendung benutzerdefinierter Updates von Drittanbietern ist einfacher und wird daher hier als Erstes beschrieben. Zum Zeitpunkt der Veröffentlichung dieses Dokuments beschäftigen sich drei Unternehmen mit der Herstellung von Updatekatalogen, mit denen Sie geeignete Patches in SMS suchen und verteilen können: Adobe, 1e und Citrix. Die teilnehmenden Unternehmen finden Sie über die Kataloge der Partner für benutzerdefinierte Updates (siehe Abbildung 1).
Abbildung 1 CUPT in Aktion
Abbildung 1 CUPT in Aktion
Wenn Sie Updates von Partnern verwenden, laden Sie einfach die Kataloge herunter, und fügen Sie diese in SMS ein. Laden Sie zunächst die erforderlichen Updates herunter, und wählen Sie dann im Aktionsmenü die Option zum Importieren der Updates aus. Ein Assistent fordert Sie auf, den Pfad zu den soeben heruntergeladenen CAB-Dateien einzugeben. Nach Abschluss des Assistenten werden die neuen Updates in CUPT angezeigt und können nun weiter konfiguriert und auf dem SMS-Standortserver veröffentlicht werden. Beachten Sie dabei, dass alle Updates zur Veröffentlichung gekennzeichnet werden müssen. Ist ein Update nicht gekennzeichnet, wird es bei der Veröffentlichungsanforderung nicht berücksichtigt. Dieser Vorgang lässt sich auch als Massenverfahren ausführen (siehe Abbildung 2). Achten Sie darauf, dass das Kennzeichen in der äußerst rechten Spalte aktiviert sein muss, damit das Update veröffentlicht wird.
Abbildung 2 Aktivieren des Veröffentlichungskennzeichens
Abbildung 2 Aktivieren des Veröffentlichungskennzeichens
Je nach Bedarf können Sie die einzelnen heruntergeladenen Updates weiter anpassen. Markieren Sie hierzu das gewünschte Update, und wählen Sie die Option „Bearbeiten“. Gehen Sie sorgfältig vor, wenn Sie ein Update individuell anpassen. Eine fehlerhafte Konfiguration kann zu unerwarteten und unbefriedigenden Ergebnissen führen.
Sobald die Updates gekennzeichnet sind, können Sie sie veröffentlichen. Hierbei stehen zwei Verfahren zur Auswahl: Veröffentlichen Sie die Updates in eine externe CAB-Datei für die spätere Verwendung, oder synchronisieren Sie die Updates mit der SMS-Standortdatenbank, wenn die Updates sofort umgesetzt werden sollen. Zur Synchronisierung mit der SMS-Standortdatenbank müssen bestimmte Konfigurationsdaten angegeben werden, beispielsweise der Name des Standortservers und der Pfad der Paketquelldateien (siehe Abbildung 3).
Abbildung 3 Synchronisierungsinformationen
Abbildung 3 Synchronisierungsinformationen
Zum Öffnen dieses Bildschirms markieren Sie den Knoten der benutzerdefinierten Updates und wählen dann im Aktionsmenü die Option „Einstellungen“. Geben Sie den Namen eines verfügbaren Standortservers sowie den Pfad des Quellverzeichnisses für das ITCU ein. Standortcode und Status werden automatisch aktualisiert.
Wenn Sie die Synchronisierungsoptionen festgelegt haben, können Sie CUPT mit dem SMS-Standortserver synchronisieren. Um die Synchronisierung durchzuführen, wählen Sie im Aktionsmenü die Option zum Veröffentlichen der Updates aus. Der Veröffentlichungs-Assistent wird gestartet. Sollen die Updates in der SMS-Datenbank veröffentlicht und sofort umgesetzt werden, dann aktivieren Sie die Option für die Synchronisierung mit der Standortdatenbank von Systems Management Server. Bei diesem Schritt erhalten Sie optische Unterstützung: Falls die Synchronisierungseinstellungen noch nicht konfiguriert wurden, ist die Option grau dargestellt.
Nach Abschluss des Assistenten stehen die benutzerdefinierten Updates in der SMS-Verwaltungskonsole zur Verfügung. Beim Starten des Assistenten für die Verteilung von Softwareupdates erhalten Sie die Option, alle verfügbaren benutzerdefinierten Updates zu nutzen.
Sie wissen nun, wie Sie herstellereigene Updates für Produkte von Drittanbietern verwenden. Was ist mit benutzerdefinierten Updates für Software von Drittanbietern, für die es keine fertigen Updates gibt? Genau hier spielt CUPT seine ganze Stärke aus. Mit CUPT können Sie benutzerdefinierte Updates komplett mit vollständigen Zielkriterien für nahezu alle Situationen erstellen.
Das Erstellen eines benutzerdefinierten Updates ist nicht sonderlich schwierig, der Administrator muss jedoch die Verfahren zum Patchen der Software, die Kriterien, mit denen die Verfügbarkeit eines Patches ermittelt wird sowie die Zielregeln zur Durchsetzung des Updates kennen. Die Zielregeln werden getrennt von der Updateerstellung definiert. Mit dem Befehl „Regeln verwalten“ im Aktionsmenü können Sie diese Regeln abrufen.
Zum Erstellen eines benutzerdefinierten Updates wählen Sie zunächst im Aktionsmenü den Befehl zum Erstellen eines Updates. Ein Assistent wird gestartet, in dem Sie die Angaben zum benutzerdefinierten Update eintragen können. Eine ausführliche Erläuterung über das Erstellen von benutzerdefinierten Updates würde den Rahmen dieses Artikels sprengen. Als ersten Anhaltspunkt sollten Sie verschiedene Eigenschaften in einem der importierten benutzerdefinierten Updates eines Drittanbieters auswählen. So erhalten Sie einen Einblick in die erforderlichen Werte für die verschiedenen Fehler, wenn Sie ein eigenes Update erstellen. Abbildung 4 zeigt die Eigenschaften eines konfigurierten Updates eines Drittanbieters.
Abbildung 4 Eigenschaften für ein Update eines Drittanbieters
Abbildung 4 Eigenschaften für ein Update eines Drittanbieters
Das Verfahren zur Erstellung benutzerdefinierter Updates bietet noch viel mehr als nur Updates: Hier können Sie auch Software konfigurieren, die an Clientsysteme verteilt werden soll. Diese Vorgehensweise führt zwar zum gewünschten Erfolg, wird jedoch nicht empfohlen und fällt auch nicht in die vorgesehenen Einsatzgebiete von CUPT.

Inventurtool für benutzerdefinierte Updates (ITCU)
ITCU ist ein neues Inventurtool für Kataloge mit benutzerdefinierten Updates. Wie bei den früheren Scantools sind Sie mit ITCU in der Lage, benutzerdefinierte Sammlungen, Pakete und Ankündigungen zu erstellen, mit denen die Scantools auf SMS-Clients im Unternehmen bereitgestellt werden. Die Vorgehensweise ist ebenfalls mit den früheren Scantools identisch: ITCU ruft den Katalog, in diesem Fall also den Katalog mit benutzerdefinierten Updates, von einem verfügbaren SMS-Verteilungspunkt ab, führt die Überprüfung anhand der Katalogdaten durch, fügt die Ergebnisse dieser Überprüfung in die Windows-Verwaltungsinstrumentation (WMI) ein und stellt die Ergebnisse per Hardwareinventur zu Berichten zusammen. Der wichtigste Unterschied im Überprüfungsverfahren liegt im verwendeten Katalog.
Mit der Einführung von SMS 2003 R2 wird der SMS-Sicherheitsbestand um ein leistungsfähiges Tool ergänzt. Nie zuvor war es Administratoren möglich, Drittanbieter- und benutzerdefinierte Anwendungen über die vorhandene SMS-Infrastruktur zu patchen. SMS R2 ist ein willkommenes Hilfsmittel für Patchverwaltungsadministratoren.
Damit besitzen Sie nun zwei Tools, mit denen Sie Softwareupdates aus Quellen außerhalb von Microsoft mühelos bewältigen. Dank der Verwaltbarkeit und Benutzerfreundlichkeit von ITCU und CUPT gehen Ihre benutzerdefinierten Updates ebenso reibungslos vonstatten wie Ihre Windows-Updates.
Updateverwaltungsressource
  • TechNet: Updateverwaltung
  • Webcast: Los geht’s: SMS 2003 R2
  • Zehn Leitlinien für die Microsoft-Patchverwaltung

Steve Rachui ist Support Escalation Engineer für den Bereich Verwaltbarkeit in der Produktsupport-Gruppe von Microsoft. Rachui unterstützt SMS schon seit der Version 1.2. Sie erreichen ihn unter steverac@microsoft.com.


 Mitteilung der Redaktion: Stimmt da etwas nicht&#160;...?
Mitteilung der Redaktion
Stimmt da etwas nicht ...?

EINER DER WICHTIGSTEN UNTERSCHIEDE zwischen Drucklegung und Internet: Gedruckte Inhalte bleiben ewig erhalten. Wenn Sie Informationen ins Internet stellen und diese Angaben später aktualisieren müssen, nehmen Sie einfach die notwendigen Änderungen vor. Und damit hat es sich.
Bei der Drucklegung sieht die Sache schon anders aus. Sobald ein Text an die Druckerei geht, gibt es kein Zurück mehr. Mehr als einhunderttausend Exemplare werden ausgeliefert, und jeder Buchstabe bleibt bis ans Ende aller Tage (oder zumindest bis zum nächsten Umzug) in Ihrem Bücherregal. Bei der Drucklegung findet außerdem von Monat zu Monat eine natürliche Progression statt. Sie wissen genau, dass Sie in der neuesten Ausgabe die aktuellsten Nachrichten und die neuesten Artikel finden.
Jetzt stellen wir das Magazin nach der Herausgabe auch als Ganzes ins Internet. Damit entsteht ein neues Problem. Aus Sicht eines Benutzers, der eine Onlinesuche durchführt, sind alle Inhalte auf der Website gleichzeitig aktuell. Wie lässt sich also herausfinden, ob es sich bei dem Text auf dem Bildschirm wirklich um die neueste Anleitung handelt?
Um dieses Problem zu lösen, haben wir vor einigen Jahren eine Korrekturrichtlinie formuliert, in der wir unser Printprodukt um die Möglichkeit erweitern, unsere Leser auch online anzusprechen. Auf der Korrekturseite zum TechNet Magazin werden sämtliche Nachbesserungen an allen veröffentlichten Beiträgen aufgeführt. Hierbei wird einer von fünf möglichen Gründen für die Aktualisierung eines Artikels angegeben: technische Gründe, redaktionelle Gründe, neue Informationen, veraltetes Material, Sicherheit.
Im Artikel über die Vereinfachung der Erstellung von Desktopabbildern vom Mai 2006 wurde beispielsweise das Tool CNIC erwähnt, das zu diesem Zeitpunkt noch gar nicht verfügbar war. Als CNIC dann auf den Markt kam, schrieben wir einen entsprechenden Vermerk für die Korrekturseite und einen Nachtrag der Redaktion zum Artikel, der online bereitgestellt wurde. Wenn Sie auf den Link für den Nachtrag der Redaktion klicken, gelangen Sie direkt zu den neuen Informationen.
Jede Printausgabe des TechNet Magazins wird monatlich durch eine neue Ausgabe abgelöst, und doch sind wir dank unserer Korrekturrichtlinie in der Lage, die Artikel auch über längere Zeit auf dem neuesten Stand zu halten. -JOSHUA TRUPIN

Unser Dank gilt folgenden technischen Experten von Microsoft: Luis Botero, Derek Del Conte, John Doyle, David Feldman, Scott Hinsley, Jesper Johansson, Brian Mohr, Michael Murgolo, John Orefice, Mark Russinovich, Matt Steele, Fergus Stewart, Jason Stolarczyk, Jim Truher und Alan von Weltin.


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

Datei- und Verzeichnissynchronisierung
Allway Sync
allwaysync.com

Unabhängig von Ihren eigentlichen Aufgaben in der IT-Abteilung verbringen Sie wahrscheinlich viel Zeit damit, Dateien und Verzeichnisse von einem Speicherort zu einem anderem zu verschieben, z. B. vom Desktop auf einen USB-Stick oder von Server zu Server über das Netzwerk. Häufig müssen diese Verzeichnisse synchron gehalten werden, damit Sie nicht unnötige Duplikate erstellen und vor allem stets mit der neuesten Version der Dateien arbeiten. In manchen Fällen müssen die Dateien und Verzeichnisse über mehrere Computer hinweg synchronisiert werden, beispielsweise beim Bereitstellen statischer XML- oder HTML-Dateien über eine Reihe von Webservern. Allway Sync von Usov Lab ist für diese Aufgaben äußerst nützlich.
Mit Allway Sync erzielen Sie eine echte n-Wege-Synchronisierung, von der unidirektionalen Replikation von Dateien und Verzeichnissen bis hin zu einer bidirektionalen Option für mehrere Verzeichnisse. Die Anwendung hält nicht nur lokale Laufwerke und Netzwerkressourcen synchron, sondern unterstützt auch die automatische Synchronisierung von Wechselmediengeräten, beispielsweise USB-Sticks und wiederbeschreibbare optische Datenträger. Je nach Bedarf kann Allway Sync automatisch gestartet werden, wenn das das Speichermedium an den Computer angeschlossen wird.
Darüber hinaus stehen weitere Optionen für den automatischen Start der Synchronisierung bereit, z. B. Starten beim Erkennen von Dateiänderungen, beim An- oder Abmelden, beim Starten von Allway Sync oder auch in bestimmten Zeitabständen. Über die grafische Benutzeroberfläche der Anwendung lässt sich die Synchronisierung sogar mit einer geplanten Aufgabe verknüpfen.
Synchronisieren von Dateien und Ordnern mit Allway Sync
Synchronisieren von Dateien und Ordnern mit Allway Sync
Alle Dateiänderungen und Löschungen werden in der lokalen Datenbank der Anwendung festgehalten, und Allway Sync bietet unzählige Optionen, mit denen Sie die Versionskontrolle für geänderte Dateien durchführen und Dateien mit Konflikten löschen, beispielsweise dauerhaftes Entfernen von Elementen, Verschieben dieser Elemente in den Papierkorb oder Verschieben in einen bestimmten Ordner.
Für jeden Auftrag können Sie mehrere Einschluss- oder Ausschlussfilter festlegen, damit genau die gewünschten Dateien abgerufen und alle nicht erforderlichen Dateien ignoriert werden. Sie können die Aktionen anpassen, die Allway Sync beim Auftreten von Warnungen oder Fehlern durchführen soll, und Sie können verschiedene Aktionen für die einzelnen Warnungs- und Fehlertypen konfigurieren. Legen Sie beispielsweise fest, dass ein Kopiervorgang bei einem Fehler automatisch wiederholt werden soll. Hierbei können Sie nicht nur die Anzahl der Wiederholungen konfigurieren, sondern auch die Zeitabstände zwischen diesen Wiederholungen, um so mögliche Netzwerklatenzen oder kurzfristige Konnektivitätsprobleme zu berücksichtigen.
Sie können den Umfang der mit der Protokollierungsfunktion festgehaltenen Daten konfigurieren und so ausführliche Informationen zu allen Aufträgen erhalten. Die Anwendungseinstellungen lassen sich per XML importieren und exportieren. Damit können Sie die Einstellungen mühelos sichern oder auf einen anderen Computer übertragen. Außerdem bietet die Anwendung für besonders Wissbegierige ein einfaches Nutzungsstatistikfenster (im Hilfemenü). Mit diesem praktischen Tool synchronisieren Sie Ihre Dateien im Handumdrehen.
Preis: Für den privaten Gebrauch kostenlos Bei gewerblicher Nutzung: 29,99 €

Zuordnung und Überwachung des Netzwerks
LANState Pro
10-strike.com/lanstate

Ein schneller Zugriff auf den Status und die Verfügbarkeit von Netzwerkressourcen ist eine unerlässliche Voraussetzung für eine proaktive IT-Arbeitsumgebung. Sie müssen sich eines auftretenden Problems bewusst sein, bevor andere Benutzer etwas bemerken. Die praktische Anwendung LANState Pro zur Zuordnung und Überwachung des Netzwerks von 10-Strike Software sorgt für rasche Visualisierungs- und LAN-Verwaltungsfunktionen für Windows®-basierte Netzwerke.
Nach dem Starten der Anwendung zur Überwachung des Netzwerks können Sie den Netzwerkzuordnungs-Assistenten ausführen, mit dem sich die Netzwerkumgebung oder ein IP-Adressbereich nach geeigneten Hosts durchsuchen lässt. Je nach Wunsch können Sie auch manuell Hosts hinzufügen. Wenn die Netzwerkzuordnung komplett ist, beginnt LANState automatisch mit den konfigurierten Statusüberprüfungen, beispielsweise mit der TCP-Portüberprüfung oder der ICMP-Pingüberprüfung. Reagierende Hosts sind farbig gekennzeichnet, nicht reagierende Hosts werden abgeblendet dargestellt. Anschließend können Sie die Zuordnung gemäß Ihrer Konfiguration nach logischen Gruppen einteilen, die optischen Kennzeichnungen bearbeiten und auch Beschreibungen hinzufügen.
Erstellen logischer Netzwerkgruppen mit LANState Pro
Erstellen logischer Netzwerkgruppen mit LANState Pro
Die Zeichnungs- und Bearbeitungstools sind etwas grob gehalten, aber Sie können die fertige Zuordnung in eine Datei speichern und müssen sie nicht immer wieder neu erstellen. Neben den TCP-Portüberprüfungen und den ICMP-Pingüberprüfungen können Sie LANState Pro so konfigurieren, dass das Vorhandensein eines bestimmten Ordners oder einer Datei, die Größe einer Datei oder der freie Speicherplatz auf einem Remotehost in konfigurierbaren Zeitabständen und mit frei wählbarer Zeitüberschreitung geprüft werden. Wenn Sie mit der rechten Maustaste auf einen Host klicken, wird ein Kontextmenü eingeblendet, über das Sie weitere Systeminformationen über den Remotehost erhalten und auch die Route verfolgen, ein Pingsignal senden, eine Standardüberprüfung durchführen oder eine Netzwerknachricht senden können.
Die Systeminformationsansicht enthält sämtliche Angaben, von den NIC-MAC-Adressen und den gebundenen IP-Adressen über Netzwerkfreigaben bis hin zu Diensten und lokalen Konten. Für die meisten Informationen auf Betriebssystemebene sind bestimmte Berechtigungen und offene Ports auf dem Remotesystem erforderlich. Allerdings liefern die RPC- Aufrufe schon eine beträchtliche Menge aussagekräftiger Daten. Wenn Sie über die erforderlichen Berechtigungen verfügen, können Sie sogar Signale zum Einschalten und Herunterfahren im Remoteverfahren an die Remotehosts senden.
Preis:249,95 € für eine Einzelbenutzerlizenz

Befehlszeilenscripting
Buchbesprechung
www.syngress.com

Interaktive Assistenten und grafische Konfigurations-Benutzeroberflächen können komplexe Aufgaben deutlich erleichtern. Als IT-Experte werden Sie durch diese Benutzeroberflächen jedoch unter Umständen ausgebremst, und sie bieten nicht die nötige Detailtiefe oder die erforderlichen Steuerungsmöglichkeiten für die anstehenden Aufgaben. Diese Steuerungsebene lässt sich allerdings in nahezu allen Fällen über die Befehlszeilenschnittstelle (Command-Line Interface, CLI) erreichen. Wenn Sie sich mit Tools in Windows vertraut machen und auch die benutzerdefinierte Anpassung der Eingabeaufforderung erlernen, um so die Verwaltungsaufgaben zu rationalisieren, können Sie Zeit sparen, Ihre Produktivität steigern und eine erhöhte Kontrolle erzielen. Das Buch How to Cheat at Windows System Administration Using Command Line Scripts (Syngress Publishing, 2006) von Pawan K. Bhardwaj hilft Ihnen beim Einsatz von CLI- und Betriebssystem-Dienstprogrammen.
Dieses Buch führt Sie durch die Anpassung der Befehlshell, wobei Batchdateien für Automatisierung und Batchverarbeitung sowie die CLI-Verwaltung geplanter Aufgaben zum Einsatz kommen. Im Anschluss an diese Kapitel werden die Dienstprogramme im Windows-Betriebssystem vorgestellt, mit denen Datenträger, Dateien und Verzeichnisse verwaltet werden. Darüber hinaus erhalten Sie einen nützlichen Überblick über die Verzeichnisdienstbefehle (z. B. DSQuery oder DSMod), die in Kombination mit den Batchverarbeitungsverfahren aus den ersten Kapiteln den Zeitaufwand für die Verwaltung umfangreicher Verzeichnisstrukturen erheblich senken können.
Außerdem lernen Sie die verfügbaren Windows-Netzwerkbefehle von Netstat bis Pathping kennen, und Sie erhalten einen Überblick über die Remoteverbindungstools wie TFTP, RSH oder RCP. Und wieder gilt: Wenn Sie diese Tools mit den erlernten Fähigkeiten aus den ersten Kapiteln des Buchs über Automatisierung und Aufgabenplanung kombinieren, können Sie Ihre Produktivität in jedem Fall deutlich steigern. Dieses Buch ist zwar kein umfassendes Referenzwerk für die Windows-Dienstprogramme, bietet jedoch eine Menge nützlicher Informationen.
Preis: 39,95 € im Direktversand

Hardwarezuverlässigkeitstest
BurnInTest
passmark.com/products/bit.htm

Die Produktion kundenspezifischer Computer, die Aktualisierung von Hardwarekomponenten für Ihre Kunden oder auch die Entwicklung eines neuen Superadministrator-Desktops haben einen wichtigen Punkt gemeinsam: Neue Komponenten müssen zuverlässig arbeiten, bevor Sie sie dem Benutzer zur Verfügung stellen. Mit BurnInTest von PassMark Software werden die Komponenten einer Reihe verschiedener Belastungstests unterzogen, mit denen Sie sicherstellen, dass die Komponenten nicht schon bei der Auslieferung defekt sind.
Wie bei allen BurnIn-Softwaretests bringt die Anwendung die Hardware tüchtig „ins Schwitzen“. Ausgewählte Systemkomponenten werden einer schweren Belastung ausgesetzt, um so in kurzer Zeit einen langen Aktivitätszyklus zu simulieren. Hiermit sollen alle verborgenen Fehler eines Systems oder Geräts noch vor der Inbetriebnahme offen gelegt werden. Mit BurnIn Test können Sie sämtliche Komponenten testen, von den Prozessoren über den Grafikkartenspeicher bis hin zu Festplatten und CD-Brennern.
Die Anwendung lässt sich sehr leicht bedienen und konfigurieren, und Sie können die Arbeitszyklen und die Voreinstellungen für jeden Komponententest in einer bestimmten Konfiguration individuell ändern. Sobald die Testkonfiguration steht, können Sie die Voreinstellungen für die spätere Verwendung speichern und so die nachfolgenden Testläufe beschleunigen, die möglicherweise wenige Monate später anstehen.
Der Arbeitszyklus der Tests kann einzeln konfiguriert werden, wobei Sie jeweils einen Belastungswert zwischen 1 und 100 für die zu testenden Komponenten festlegen können. Lassen Sie beispielsweise die Prozessor-Rechenvorgänge mit einer Belastung von 75 Prozent testen und den Systemspeicher gleichzeitig mit einer Belastung von 90 Prozent. Darüber hinaus können Sie in BurnInTest angeben, dass die Tests nach einem bestimmten Zeitraum in Minuten oder nach einer bestimmten Anzahl von Arbeitszyklen beendet werden sollen.
Mit der Anwendung können bis zu 20 Festplatten, Diskettenlaufwerke und/oder optische Laufwerke gleichzeitig getestet werden. Auf diese Weise können Sie Laufwerke vor ihrer Eingliederung in die Clientumgebung im Batchverfahren testen. Beim Aktualisieren einer Systemkomponente kann dies zu erheblichen Zeiteinsparungen führen, weil Sie die neuen Komponenten direkt testen können, ohne jedes System einzeln testen zu müssen. Das Programm ermöglicht außerdem eine intelligente Parameterprüfung.
Die Professional Edition unterstützt eine Reihe von Loopbacktests für USB-2.0-Anschlüsse sowie für parallele und serielle Schnittstellen. (Die Hardwareloopbackgeräte sind bei PassMark erhältlich.) Diese Version von BurnInTest kann wahlweise von CD oder über einen USB-Stick ausgeführt werden, sodass die Tests noch aussagekräftiger sind, da die Auswirkungen der Anwendung auf das zu testende System vermindert werden.
Preis: 49 € für die Professional Edition, 24 € für die Standard Edition

Greg Steen ist Technologieexperte, Unternehmer und Enthusiast. Er ist immer auf der Suche nach neuen Hilfsmitteln und Methoden, die die Arbeitsprozesse und Entwicklung von IT-Profis erleichtern.


 SQL&#160;– Fragen &amp; Antworten: Neuerstellen von Indexen, Warteschlangenl&#228;nge des Datentr&#228;gers und mehr
SQL – Fragen & Antworten
Neuerstellen von Indexen, Warteschlangenlänge des Datenträgers und mehr
Herausgegeben von Nancy Michell

F: Wie werden SQL Server-Indexe neu erstellt? Ich möchte wissen, warum DBCC DBREINDEX meinen ganzen Speicherplatz in Anspruch nimmt und der Platz nicht freigegeben wird, wenn der Befehl fehlschlägt. Meine Datenbank hat 90 GB, und die größte Tabelle ist 70 GB groß.
Wenn ich DBCC DBREINDEX ausführe und dabei 10 Prozent Speicherplatz frei lasse, beansprucht das Programm den gesamten verfügbaren Speicherplatz, und der Befehl schlägt fehl. Wenn bei einer anfänglichen Größe der Datenbankdatei von 90 GB der DBCC-Befehl fehlschlägt, wächst die Datenbankdatei auf 160 GB, und diese zusätzlichen 70 GB werden nie wieder freigegeben. Ich muss die Datenbank mehrmals manuell verkleinern, um den Speicher freizugeben.
Wenn der Befehl funktioniert, ist die Datenbankdatei ebenfalls 160 GB groß, aber der Speicherplatz wird automatisch nach ein paar Stunden durch die automatische Verkleinerung freigegeben. Wäre es akzeptabel, anstelle von DBREINDEX eine Defragmentierung durchzuführen, um weniger Speicherplatz in Anspruch zu nehmen? Ich habe keine gebündelten Indexe und verwende den einfachen Wiederherstellungsmodus.
A: Im einfachsten Fall werden Indexe neu erstellt, indem eine neue Kopie des Index erstellt und dann die alte gelöscht wird. Für eine kurze Zeitspanne gibt es also praktisch zwei Kopien des Index. Die Erstellung des neuen Index erfordert möglicherweise genauso viel Platz in der Datenbankdatei wie der ursprüngliche Index, und wenn die Neuerstellung einen Sortiervorgang erfordert, sind zusätzliche 20 Prozent der Indexgröße allein für die Sortierung erforderlich.
Deshalb erfordert die Neuerstellung eines Index im schlimmsten Fall den 1,2fachen Speicherplatz des alten Index. Hat die Datenbankdatei nicht genug freien Speicherplatz, muss sie sich entsprechend dem Fortschritt des Vorgangs vergrößern. Wenn die automatische Vergrößerung nicht aktiviert ist oder es auf dem Datenträgervolume nicht genug Speicherplatz gibt, schlägt der Neuerstellungsvorgang möglicherweise wegen unzureichendem Speicher fehl.
Unabhängig davon, ob der Vorgang fehlschlägt oder nicht, wird der zusätzliche Speicherplatz, der der Datenbankdatei zugeordnet worden ist, nach Abschluss des Neuerstellungsvorgangs nicht wieder freigegeben. Es wird davon ausgegangen, dass der Speicherplatz für reguläre Datenbankvorgänge verwendet wird.
Ausführen von Verkleinern (entweder manuell oder automatisch) führt durch die Art, wie der Algorithmus funktioniert, so gut wie sicher zu Indexfragmentierung. Weitere Informationen finden Sie unter: SQL Server-Speichermodul. Automatische Verkleinerung kann sich besonders nachteilig auf die Leistung auswirken, wenn die Datenbank freien Speicherplatz für reguläre Vorgänge benötigt, denn Sie können in einen Kreislauf von fortwährender automatischer Vergrößerung und anschließender automatischer Verkleinerung hineingeraten, der sich verheerend auf Fragmentierung und Leistung auswirken kann.
Die Verwendung von DBCC INDEXDEFRAG (oder ALTER INDEX ... REORGANIZE in SQL Server™ 2005) hat den Vorteil, dass fast kein zusätzlicher Speicherplatz in der Datenbankdatei belegt wird, aber dieser Vorgang dauert u. U. länger und erstellt eine viel größere Menge an Protokolleinträgen als eine Indexneuerstellung. DBCC INDEXDEFRAG wird unabhängig vom verwendeten Wiederherstellungsmodus immer vollständig protokolliert, während die Neuerstellung eines Index im einfachen Wiederherstellungsmodus massenprotokolliert wird. Beide Methoden haben verschiedene Vor- und Nachteile. Ausführlichere Erläuterungen dazu finden Sie im Whitepaper Bewährte Methoden zur Indexdefragmentierung in SQL Server.
Bevor Sie sich für eine Methode zur Indexdefragmentierung entscheiden, sollten Sie sich zunächst fragen, ob dieser Prozess überhaupt erforderlich ist. Je nach Art der Vorgänge, für die der Index verwendet wird, hat die Fragmentierung möglicherweise keine Auswirkung auf die Leistung, sodass deren Behebung eine Verschwendung von Ressourcen darstellt. Das Whitepaper stellt hierzu sehr ausführliche Informationen bereit.
Fazit: Stellen Sie sicher, dass Sie die für Ihre Umgebung am besten geeignete Methode zur Defragmentierung wählen und hierdurch die Abfrageleistung wirklich erhöht wird.

F: Ich habe zwischen zwei Instanzen von SQL Server 2005 erfolgreich die Datenbankspiegelung konfiguriert. Meine Anwendung stellt mithilfe einer SQL Server-Anmeldung eine Verbindung zu SQL Server her und wird mithilfe von ADO und SQL Native Client erstellt. Verbindungszeichenfolge und Verbindungseinstellungen geben die richtigen Informationen an, einschließlich des passenden Failoverpartners. Ich habe auch auf dem Spiegelserver durchgängig dieselben Anmeldungen erstellt, wie sie auf dem Prinzipalserver vorhanden sind. Bei Prüfung eines Datenbankfehlers übernimmt der Spiegel erfolgreich die Hauptrolle, und alles erscheint auf der SQL Server-Instanz korrekt. (Ich kann sogar mithilfe meiner Windows®-Anmeldung eine Verbindung zum Spiegel herstellen.) Die Wiederherstellung der Verbindung schlägt jedoch mit folgendem Fehler fehl:
Cannot open database "<db name>" requested by the login. The login failed.
Es wird angezeigt, dass die Anmeldung keinem Benutzer in der neuen Prinzipaldatenbank (dem ursprünglichen Spiegel) zugeordnet ist. Ich führe sp_change_users_login aus, um die Benutzer und die Anmeldungen für die Datenbank zu synchronisieren, und ich erhalte eine Nachricht, dass das Problem mit mehreren verwaisten Benutzern behoben wurde. Meine Anwendung stellt dann erneut erfolgreich eine Verbindung zum neuen Prinzipalserver her. Ich habe mehrere Failovers versucht, und jedes Mal erlebe ich dasselbe Verhalten, nämlich, dass die Zuordnung zwischen der Anmeldung und dem Benutzer verloren geht.
Gibt es eine Möglichkeit, das Spiegelsetup so zu konfigurieren, dass dieses Problem nicht auftritt?
A: Ja. Das Problem liegt in der Tatsache, dass die Sicherheits-IDs (SIDs) für die SQL Server-Anmeldungen auf den einzelnen Servern nicht übereinstimmen, auch wenn die Namen für die Anmeldungen gleich sind. Dieses Problem besteht nicht bei Windows/Domänenbenutzer/Gruppenanmeldungen, da die SIDs für diese Anmeldungen aufgrund der Domänen-SID für den Benutzer/die Gruppe erstellt werden und deshalb für denselben bestimmten Benutzer/dieselbe bestimmte Gruppe gleich sind, unabhängig davon, welchem SQL-Server der Benutzer/die Gruppe hinzugefügt wird.
Um den Synchronisierungsschritt sp_change_users_login unnötig zu machen, müssen Sie die SQL Server-Anmeldungen auf dem Spiegelserver nicht nur mit demselben Namen, sondern auch mit derselben SID wie auf dem Prinzipalserver erstellen. Dies erreichen Sie mithilfe der SID-Spezifikation in der Anweisung CREATE LOGIN (ANMELDUNG ERSTELLEN), wenn Sie die Anmeldungen auf dem Spiegelserver erstellen, und zwar folgendermaßen:
CREATE LOGIN <loginname> WITH PASSWORD = <password>,
SID = <sid for
same login on principal server>,...
Sie können die SID für jede Anmeldung vom Prinzipalserver abrufen, indem Sie die Katalogansicht sys.sql_logins abfragen. Ein Beispiel für eine Abfrage, die eine tatsächliche CREATE LOGIN-Anweisung für jede SQL Server-/Windows-Anmeldung auf einem bestimmten Server generiert, ist in Abbildung 1 dargestellt.
Figure 1 Erstellen einer CREATE LOGIN-Anweisung (Close Figure 1)
select 'create login [' + p.name + '] ' +
case when p.type in('U','G') then 'from windows ' else '' end +
'with ' +
case when p.type = 'S' then 'password = ' + master.sys.fn_varbintohexstr(l.password_hash) +
' hashed, ' + 'sid = ' + master.sys.fn_varbintohexstr(l.sid) + ', check_expiration = ' +
case when l.is_policy_checked > 0 then 'ON, ' else 'OFF, ' end + 'check_policy = ' +
case when l.is_expiration_checked > 0 then 'ON, ' else 'OFF, ' end +
case when l.credential_id > 0 then 'credential = ' + c.name + ', ' else '' end
else '' end +
'default_database = ' + p.default_database_name +
case when len(p.default_language_name) > 0 then ', default_language = ' + p.default_language_name else '' end
from sys.server_principals p
left join sys.sql_logins l
on p.principal_id = l.principal_id
left join sys.credentials c
on l.credential_id = c.credential_id
where p.type in('S','U','G')
and p.name <> 'sa'

F: Wie groß sollte die durchschnittliche Warteschlangenlänge meines Datenträgers sein? Wenn ich z B. 20 separate physische Spindles außerhalb des SAN (Storage Area Network) mit RAID 01-Konfiguration habe, wie berechne ich dann die durchschnittliche Warteschlangenlänge des Datenträgers? Ist es die durchschnittliche Warteschlangenlänge des Datenträgers/20 oder die durchschnittliche Warteschlangenlänge des Datenträgers/2?
A: Bevor Sie Zeit auf die durchschnittliche Warteschlangenlänge in einer SAN-Umgebung aufwenden, sollten Sie zunächst die Datenträgerwartezeit überprüfen. Aber eigentlich hängt es davon ab, was Sie herausfinden möchten. Warum, werden Sie gleich sehen.
Die Erklärung dieses Indikators (von Perfmon) ist: „Die durchschnittliche Warteschlangenlänge des Datenträgers ist die durchschnittliche Anzahl der Lese- und der Schreibanforderungen, die sich für den ausgewählten Datenträger während des Samplingintervalls in der Warteschlange befanden.“ Dies ist ein Leistungsindikator entweder für physische oder logische Datenträger, sodass die resultierende Länge davon abhängt, wie der zugrunde liegende Speicher dem Betriebssystem vorgelegt wird.
Schauen wir uns Ihren Fall an. Sie haben 20 Spindles in einer RAID 01-Konfiguration, was bedeutet, dass sie gestriped und gespiegelt sind (oder gespiegelt und gestriped, je nachdem, ob Sie 01 oder 10 lesen). Das Entscheidende an diesem Speicherarray ist, dass es 10 Spindles im Stripeset gibt.
Aber mir fehlen jetzt wichtige Informationen, wie z. B. die Stripegröße, wie groß die Schreibvorgänge sind und welche Art von E/A Sie veranlassen (lesen, schreiben, sequenziell oder zufällig).
Wenn man die fehlenden Informationen vorläufig ignoriert, bedeutet eine durchschnittliche Warteschlangenlänge des Datenträgers von 10, dass das Betriebssystem 10 E/A für das Festplattenarray in die Warteschlange gestellt hat. Theoretisch könnte das eine E/A zu jedem der 10 gespiegelten Sätze im Stripe sein, oder es könnten 10 E/A sein, die alle zu einem Datenträger gehören. Es kann nicht festgestellt werden, welche der beiden Möglichkeiten vorliegt.
An dieser Stelle kommen die fehlenden Informationen ins Spiel. Angenommen, die Stripegröße beträgt 64 KB, die Größe der Schreibvorgänge 8 KB, und Sie wollen ein ganzes Segment von sequenziellen Schreibvorgängen durchführen. Dies ist ein typisches Szenario für SQL Server-Speicheraktivität. In diesem Fall besteht eine hohe Wahrscheinlichkeit, dass acht der E/A auf dem ersten Datenträger und die nächsten zwei E/A auf dem nächsten Datenträger gespeichert wurden. Wenn Sie also für dieses Szenario die Warteschlangenlänge pro Datenträger herausfinden wollen, so beträgt diese 8 für den ersten Datenträger, 2 für den zweiten Datenträger und 0 für die übrigen acht Datenträger im Array.
Wechseln wir jetzt zu einem Szenario mit einer theoretischen Stripegröße von 8 KB und einer Blockgröße der Schreibvorgänge von 64 KB, bei einer gleichbleibenden Warteschlangenlänge des Datenträgers von 10. In diesem Fall wird jeder 64 KB-Block auf 8 Datenträger verteilt, sodass eine einzige E/A auf 8 Datenträger geschrieben wird und die 10 in der Warteschlange befindlichen E/A auf 80 Schreibvorgänge über alle 10 Datenträger im Array verteilt werden. Bei einer Berechnung der Warteschlangenlänge pro Datenträger im Array erhalten Sie 8 für jeden Datenträger im Array.
Seien wir realistisch, und gehen wir von einem höheren Grad an Unsicherheit aus. In den meisten Fällen stellt der SAN-Speicher eine Verbindung zum Server her, und zwar mithilfe eines oder mehrerer Hostbusadapter (HBA) im Server, einer Reihe von Glasfasern, um den HBA mit dem SAN zu verbinden, einer Reihe von Ports auf dem Front-End des SAN und vielleicht eines Fiber-Switch in der Struktur zwischen dem Server und dem SAN. Dann gelangen wir in die interne Architektur der Busse innerhalb des SAN und sehen, wie die Verbindung der Datenträger zu den Ports auf der Vorderseite des SAN hergestellt ist.
Jede in Perfmon gemeldete Warteschlange kann ein Symptom für hohe Wartezeit oder für Warteschlangen an irgendeinem dieser Punkte sein, zwischen denen das Betriebssystem die Warteschlangenlänge seiner Datenträger und die Oberfläche der Datenträger misst. Daher sollten Sie auf die Wartezeit achten und eventuelle Entscheidungen eher aufgrund dieses Indikators fällen als aufgrund von durchschnittlichen Warteschlangenlängen des Datenträgers.

F: Ich verwende Transaktionsreplikation, und ich weiß, dass viele Zeilen in einer Tabelle beim Abonnenten manuell geändert wurden. Deshalb erhalte ich Fehler, wenn der Herausgeber versucht, eine Zeile zu aktualisieren, die beim Abonnenten nicht mehr existiert.
Ich will wissen, ob es durch Replikation eine Möglichkeit gibt, nur diese eine Tabelle vom Herausgeber neu zu initialisieren, anstatt einen ganzen Snapshot erneut auszuführen. Ich habe mir die Funktion TableDiff angeschaut, die so aussieht, als ob sie diese Funktion erfüllen könnte, aber ich frage mich, wie sie mit der Replikation interagiert.
Erstellt z. B. TableDiff zu einem bestimmten Zeitpunkt einen Snapshot von der Tabelle des Herausgebers und vergleicht ihn mit der Entsprechung des Abonnements? Muss ich die Replikation beenden, wenn ich das Dienstprogramm TableDiff anwende, damit die Konsistenz der Daten sichergestellt ist? Was muss ich sonst noch wissen?
A: Erstens erstellt TableDiff weder von der Tabelle des Herausgebers noch der des Abonnements einen wirklichen Snapshot. Hinsichtlich Ihres speziellen Szenarios gibt es verschiedene Optionen.
Die erste wäre eine vorübergehende Unterbrechung der Replikation, um das Dienstprogramm auszuführen. Wenn Sie sich Sorgen machen, das Benutzer Daten ändern könnten, verwenden Sie die Parameter -sourcelocked und -destinationlocked, die beide Tabellen während der Ausführung des Dienstprogramms exklusiv sperren. Wenn dies unannehmbar ist, bestände eine andere Option in der Verwendung der Parameter -rc und -ri, während Sie die Replikation weiterlaufen lassen. Hierdurch wird TableDiff zunächst einmal ausgeführt und anschließend erneut nach jedem Fehler, der erkannt wird. Dabei werden Fehler beseitigt, die möglicherweise aufgrund von Verzögerungen bei der Weitergabe der Replikation entstanden sind. Beachten Sie jedoch, dass Sie je nach Replikationsverzögerung mit dieser Option nicht unbedingt alle Zeilen erfassen, die sich beim Abonnenten geändert haben.

Unser Dank gilt den folgenden Microsoft-IT-Experten für ihre fachliche Unterstützung: Sunil Agarwal, Chad Boyd, David Browne, Gilles Comeau, Emmanuel Dreux, Amanda Foote, Matt Hollingsworth, Paul Mestemaker, Uttam Parui, Paul Randal, Dennis Tighe und Steven Wort.


 Schwerpunkt Dienstprogramme: Autoruns
Schwerpunkt Dienstprogramme
Autoruns
Lance Whitney
Laden Sie den Code für diesen Artikel herunter: Autoruns (490KB)

Bei einem typischen Computer mit Windows® wird beim Starten ein ganzes Arsenal an Elementen geladen: Dateien, Treiber, Aufgaben, Dienste. Irgendwann einmal wird der Fall eintreten, dass Sie bestimmte Startelemente abrufen und ggf. deaktivieren müssen, um so einen Konflikt beim Starten zu beheben, ein schädliches Programm in der Autostart-Sequenz zu ermitteln, die Zeit für das Starten von Windows zu verkürzen oder Speicher und Systemressourcen freizugeben.
Mit dem Dienstprogramm für die Systemkonfiguration (msconfig.exe) können Sie zwar eine Reihe von Startdateien und Diensten anzeigen und deaktivieren, aber längst nicht alle, beispielsweise Symbolleisten, Browserhilfsobjekte oder auch Erweiterungen für die Windows Explorer-Shell. Darüber hinaus liefert msconfig nicht gerade viele Details zu diesen Elementen. Autoruns von Sysinternals bietet da schon bessere Möglichkeiten zum Abrufen und Verwalten aller Elemente, die beim Starten geladen werden.
Autoruns von Mark Russinovich und Bryce Cogswell ist ein kostenloses Dienstprogramm, das sämtliche Startelemente (auch als Image bezeichnet) auf Windows-basierten Computern offen legt. Sie können alle Images in den Startordnern, der Registrierung und anderen Bereichen abrufen, in denen solche Elemente sich gern „verstecken“ (siehe Abbildung 1).
Abbildung 1 Abrufen von Startelementen mit Autoruns
Abbildung 1 Abrufen von Startelementen mit Autoruns
Autoruns zeigt den Namen und den Speicherort der einzelnen Images an. Bei Dateien wird der Verzeichnispfad aufgeführt, bei Registrierungseinträgen der genaue Schlüssel. Darüber hinaus liefert Autoruns den Namen des Herstellers sowie eine kurze Beschreibung auf Grundlage der Versionsdaten des jeweiligen Elements. Wenn Sie auf einen Eintrag doppelklicken, gelangen Sie direkt zum zugehörigen Verzeichnis oder Registrierungsschlüssel. Durch Klicken mit der rechten Maustaste wird ein Popupmenü mit weiteren Optionen eingeblendet, darunter die Option „Properites“, die das normale Dateieigenschaftenfenster mit sämtlichen Versionsinformationen öffnet. Die Option „Include Empty Locations“ zeigt alle Startbereiche des Computers an, unabhängig davon, ob dort derzeit Einträge vorhanden sind oder nicht. Zudem können Sie weitere Benutzerkonten auf dem Computer auswählen und die zugehörigen Startumgebungen abrufen.
Mit dem Befehl „Verify“ können Sie die digitale Signatur eines Eintrags überprüfen. Dieser Befehl fragt Websites mit Zertifikatssperrlisten (CRLs) ab und ermittelt so, ob ein Image digital signiert wurde und ob die Signatur gültig ist. Die Option „Hide Signed Microsoft Entries“ schließt sämtliche Einträge aus, die bereits von Microsoft signiert wurden, sodass Sie sich ganz auf die Drittanbieter-Images konzentrieren können.
Die gesamte Liste der Startelemente lässt sich in eine Textdatei exportieren. Das ist insbesondere dann praktisch, wenn Elemente deaktiviert werden sollen und Sie vor der Optimierung einen Snapshot der Startumgebung anfertigen möchten. Anschließend können Sie die exportierte Textdatei mit der überarbeiteten Startkonfiguration vergleichen und so die Änderungen überprüfen.
Beispiele für die Startkategorien in Autoruns:
Anmeldung: Der Benutzer selbst, die Startordner aller Benutzer sowie die Ausführungsschlüssel in der Registrierung.
Explorer: Liste der Erweiterungen für die Explorer-Shell, der Symbolleisten und der aktiven Setupausführungen.
Internet Explorer: Browserhilfsobjekte sowie Symbolleisten und Erweiterungen für Internet Explorer®.
LSA-Anbieter: Authentifizierungs-, Benachrichtigungs- und Sicherheitspakete der lokalen Sicherheitsinstanz (Local Security Authority, LSA).
In Autoruns können Sie ein Startelement wahlweise dauerhaft löschen oder nur deaktivieren. Mit der Option „Online Search“ ermitteln Sie die Elemente, die problemlos deaktiviert werden können. Mit dieser Option starten Sie eine Internetsuche nach Webseiten, auf denen ein Element oder dessen Kategorie beschrieben wird. Weiterhin werden Sie beraten, ob das betreffende Element beim Starten besser nicht automatisch ausgeführt werden sollte. Wenn Sie ein Element deaktivieren, verschiebt Autoruns dieses Element an einen Sicherungsspeicherort in der Registrierung oder auf der Festplatte.
Autoruns ist unter allen Versionen von Windows funktionsfähig, auch unter Windows XP 64-Bit Edition und Windows Server® 2003 64-Bit Edition. Unter microsoft.com/technet/technetmag/code07.aspx steht diese Anwendung zum Herunterladen bereit.

Lance Whitney ist IT-Berater, Schulungsleiter und Autor technischer Artikel. Whitney hat sich intensiv mit dem Optimieren von Windows-Arbeitsstationen und -Servern beschäftigt. Von Hause aus Journalist, hat er vor etwa 15 Jahren den Sprung in das kalte Wasser der IT-Welt getan.


 The Cable Guy: Einstellungen der Drahtlosnetzwerk-Gruppenrichtlinie f&#252;r Windows Vista
The Cable Guy
Einstellungen der Drahtlosnetzwerk-Gruppenrichtlinie für Windows Vista
Joseph Davies
Dieser Artikel enthält vorläufige Informationen zum Windows Server „Longhorn“, die bis zur endgültigen Version des Produkts Änderungen unterliegen.

Ihre Arbeit als Administrator wäre wahrscheinlich erheblich einfacher, wenn Sie Einstellungen für drahtlose Netzwerke zentral konfigurieren und auf alle Computer in Ihrem Active Directory-Netzwerk verteilen könnten. Sie haben Glück: Windows unterstützt eine spezielle Gruppenrichtlinienerweiterung zur Computerkonfiguration, mit der Sie genau dies tun können. Es handelt sich um die
Erweiterung „Drahtlosnetzwerkrichtlinien (IEEE 802.11)“, die von Computern mit Windows Vista™, Windows® XP, Windows Server® 2003 und der nächsten Version von Windows Server mit dem Codenamen „Longhorn“ unterstützt wird.
Dieses Verfahren funktioniert folgendermaßen. Beim Beitreten zur Domäne oder beim Starten (und danach auf kontinuierlicher Basis) laden diese Betriebssysteme automatisch die Drahtloseinstellungen in dieser Gruppenrichtlinienerweiterung herunter und wenden sie an. Sie können Drahtlosrichtlinien für ein domänenbasiertes Gruppenrichtlinienobjekt in folgendem Knoten im Snap-In „Gruppenrichtlinienobjekt-Editor“ konfigurieren: Computerkonfiguration | Windows-Einstellungen | Sicherheitseinstellungen | Drahtlosnetzwerkrichtlinien (IEEE 802.11).
In Abbildung 1 wird der Knoten „Drahtlosnetzwerkrichtlinien (IEEE 802.11)“ für eine Domäne eines Windows Servers mit dem Codenamen „Longhorn“ oder für eine Windows Server 2003-Domäne gezeigt, deren Schema mit den Schemaerweiterungsdateien „802.11Schema.ldf“ und „802.3Schema.ldf“ erweitert wurde (beschrieben unter microsoft.com/technet/network/wifi/vista_ad_ext.mspx).
Abbildung 1 Knoten „Drahtlosnetzwerkrichtlinien (IEEE 802.11)“
Abbildung 1 Knoten „Drahtlosnetzwerkrichtlinien (IEEE 802.11)“
Standardmäßig sind keine Drahtlosnetzwerkrichtlinien (IEEE 802.11) vorhanden. Um eine neue Richtlinie zu erstellen, klicken Sie mit der rechten Maustaste auf „Drahtlosnetzwerkrichtlinien (IEEE 802.11)“ in der Konsolenstruktur. Klicken Sie anschließend auf „Eine neue Windows XP-Richtlinie erstellen“ oder „Eine neue Windows Vista-Richtlinie erstellen“. Es kann pro Richtlinie nur eine Richtlinienart erstellt werden, aber jede Richtlinie kann Einstellungen für mehrere drahtlose Netzwerke enthalten.
Die Einstellungen der Windows XP-Richtlinie ähneln den von mir im Juli 2003 beschriebenen Einstellungen. Es gibt jedoch neue Optionen für drahtlose Nicht-Broadcast-Netzwerke, Authentifizierungsmethoden für Wi-Fi Protected Access 2 (WPA2) und für die schnelle Serverspeicherung bei der WPA2-Authentifizierung. Um diese neuen Einstellungen nutzen zu können, muss auf Computern mit Windows XP Service Pack 2 (SP2) das Drahtlosnetzwerkclient-Update für Windows XP SP2 installiert werden. Sie finden dieses Update unter support.microsoft.com/kb/917021.
Die Windows Vista-Drahtlosrichtlinie enthält spezifische Richtlinieneinstellungen für die drahtlosen Clients von Windows Vista und dem Windows Server „Longhorn“. Wenn beide Drahtlosrichtlinien konfiguriert sind, verwenden drahtlose Clients unter Windows XP und Windows Vista jeweils nur ihre eigenen Richtlinieneinstellungen. Wenn keine Windows Vista-Richtlinieneinstellungen vorhanden sind, verwenden die drahtlosen Clients unter Windows Vista die Windows XP-Einstellungen. In diesem Artikel werden die Einstellungen zur Konfiguration der Windows Vista-Drahtlosrichtlinie beschrieben.
Auf der Registerkarte „Allgemein“ für eine Windows Vista-Drahtlosnetzwerkrichtlinie können Sie einen Namen und eine Beschreibung für die Richtlinie konfigurieren, angeben, ob der WLAN-Autokonfigurationsdienst aktiviert ist und die Liste der Profile drahtloser Netzwerke sowie ihre Einstellungen in bevorzugter Reihenfolge konfigurieren (siehe Abbildung 2). Sie können ein Profil in eine XML-Datei exportieren, indem Sie das Profil auswählen und auf „Exportieren“ klicken. Um eine XML-Datei mit einem Drahtlosprofil zu importieren, klicken Sie auf „Importieren“ und geben den Speicherort der Datei an.
Abbildung 2 Eigenschaften von Drahtlosnetzwerkrichtlinien
Abbildung 2 Eigenschaften von Drahtlosnetzwerkrichtlinien
In Abbildung 3 ist die Registerkarte „Netzwerkberechtigungen“ für eine Drahtlosnetzwerkrichtlinie unter Windows Vista mit den Standardeinstellungen dargestellt. Diese Registerkarte ist neu in Windows Vista und ermöglicht Ihnen, drahtlose Netzwerke mit Namen anzugeben und den Zugriff darauf zuzulassen oder zu verweigern. Sie können z. B. eine Liste „Zulassen“ erstellen, die die Namen drahtloser Netzwerke enthält, auch bekannt als SSID (Service Set Identifier), zu denen ein drahtloser Client unter Windows Vista eine Verbindung herstellen kann. Dies ist sinnvoll, wenn Netzwerkadministratoren erreichen möchten, dass Laptopcomputer in einem Unternehmen Verbindungen mit bestimmten Drahtlosnetzwerken herstellen, z. B. dem Drahtlosnetzwerk des Unternehmens und drahtlosen Netzwerken von Internetdienstanbietern.
Abbildung 3 Registerkarte „Netzwerkberechtigungen“
Abbildung 3 Registerkarte „Netzwerkberechtigungen“
In der Liste „Verweigern“ können Sie die Namen von Drahtlosnetzwerken angeben, mit denen der Client keine Verbindung herstellen darf. Hiermit kann verhindert werden, dass verwaltete Laptops eine Verbindung zu anderen drahtlosen Netzwerken herstellen, die sich in Reichweite befinden, z. B., wenn ein Unternehmen sich in einem Stockwerk eines Gebäudes befindet und drahtlose Netzwerke anderer Unternehmen auf angrenzenden Stockwerken vorhanden sind. Sie können mithilfe der Liste „Verweigern“ auch verhindern, dass verwaltete Laptops sich mit bekannten, ungesicherten Drahtlosnetzwerken verbinden. Um eine Liste zu erstellen oder einzelne drahtlose Netzwerke anzugeben, für die der Zugriff zugelassen oder verweigert werden soll, klicken Sie auf „Hinzufügen“ und geben ein drahtloses Netzwerk mit Namen und Zugriffsrechten an.
Auf der Registerkarte „Netzwerkberechtigungen“ gibt es auch Einstellungen, mit denen Verbindungen zu Ad-Hoc- und Infrastrukturnetzwerken verhindert werden können. Sie können es Benutzern ermöglichen, drahtlose Netzwerke anzuzeigen, für die eine Verweigerung festgelegt wurde, und ein Profil für alle Benutzer anzulegen. Ein Benutzerprofil für alle Benutzer kann verwendet werden, um allen Benutzern mit einem Konto auf dem Computer eine Verbindung zu einem bestimmten drahtlosen Netzwerk zu ermöglichen. Wenn diese Einstellung deaktiviert ist, können nur Benutzer der Netzwerkadministratoren- oder Netzwerkoperatorengruppe Profile für alle Benutzer eines Computers erstellen.

Eigenschaften von Drahtlosnetzwerkprofilen
Um ein Drahtlosnetzwerkprofil auf der Registerkarte „Allgemein“ der Windows Vista-Drahtlosrichtlinie zu verwalten, wählen Sie ein vorhandenes Profil aus und klicken auf „Bearbeiten“. Alternativ klicken Sie auf „Hinzufügen“ und geben anschließend an, ob das neue drahtlose Profil für ein drahtloses Ad-Hoc- oder für ein Infrastrukturnetzwerk gedacht ist.
Um ein neues drahtloses Profil zu erstellen, beginnen Sie auf der Registerkarte „Verbindung“ durch Benennen des Profils und Erstellen einer Liste mit den Namen der drahtlosen Netzwerke, für die das Profil gelten soll (siehe Abbildung 4). Sie können neue Namen hinzufügen, indem Sie sie in das Feld „Netzwerkname (SSID)“ eingeben und auf „Hinzufügen“ klicken. Sie können auch angeben, ob der drahtlose Client, der dieses Profil verwendet, automatisch versuchen soll, eine Verbindung zu den im Profil genannten drahtlosen Netzwerken herzustellen, wenn sie sich in Reichweite befinden (je nach Reihenfolge der Drahtlosprofile auf der Registerkarte „Allgemein“ der Windows Vista-Richtlinie). Zusätzlich können Sie festlegen, ob die Verbindung zu diesem drahtlosen Netzwerk automatisch getrennt werden soll, wenn sich ein bevorzugtes drahtloses Netzwerk innerhalb der Reichweite befindet, und angeben, ob es sich bei den Drahlosnetzwerken in diesem Profil um Nicht-Broadcast-Netzwerke (auch bekannt als versteckte Netzwerke) handelt.
Abbildung 4 Registerkarte „Verbindung“
Abbildung 4 Registerkarte „Verbindung“
Auf der Registerkarte „Sicherheit“, die in Abbildung 5 dargestellt ist, können Sie die Authentifizierungs- und Verschlüsselungsmethoden für die drahtlosen Netzwerke im Profil konfigurieren. Die Verschlüsselungsmethode hängt von der gewählten Authentifizierungsmethode ab. Die jeweiligen Optionen werden in Abbildung 6 gezeigt.
Figure 6 Sicherheitsmethoden (Close Figure 6)

Authentifizierungsmethoden
Offen
Freigegeben
Wi-Fi Protected Access (WPA)-Personal
WPA-Enterprise
WPA2-Personal
WPA2-Enterprise
Mit 802.1X öffnen
Verschlüsselungsmethoden
Wired Equivalent Privacy (WEP)
Temporal Key Integrity Protocol (TKIP)
Erweiterter Verschlüsselungsstandard (AES)
Abbildung 5 Registerkarte „Sicherheit“
Abbildung 5 Registerkarte „Sicherheit“
Wenn Sie „WPA-Enterprise“, „WPA2-Enterprise“ oder „Mit 802.1X öffnen“ als Authentifizierungsmethode auswählen, können Sie auch die Netzwerkauthentifizierungsmethode (den Typ des Extensible Authentication-Protokolls [EAP]), den Authentifizierungsmodus (erneute Benutzerauthentifizierung, Computerauthentifizierung, Benutzerauthentifizierung oder Gastauthentifizierung) sowie die Anzahl von Authentifizierungsversuchen bis zum Abbruch des Authentifizierungsvorgangs konfigurieren und angeben, ob Benutzerinformationen für spätere Verbindungen zwischengespeichert werden sollen. Diese letzte Einstellung gibt an, ob die Benutzeranmeldedaten beim Abmelden des Benutzers aus der Registrierung gelöscht werden sollen. In diesem Fall wird der nächste Benutzer, der sich anmeldet, zur Eingabe seiner Anmeldeinformationen (wie z. B. Benutzername und Kennwort) aufgefordert.
Um erweiterte Sicherheitseinstellungen für die Authentifizierungsmethoden „WPA-Enterprise“, „WPA2-Enterprise“ oder „Mit 802.1X öffnen“ zu konfigurieren, klicken Sie auf „Erweitert“. In Abbildung 7 ist das Dialogfeld „Erweiterte Sicherheitseinstellungen“ abgebildet.
Abbildung 7 Dialogfeld „Erweiterte Sicherheitseinstellungen“
Abbildung 7 Dialogfeld „Erweiterte Sicherheitseinstellungen“
Im Abschnitt „IEEE 802.1X“ können Sie die Anzahl aufeinander folgender EAPOL-Startmeldungen (EAP over LAN) angeben, die geschickt werden, wenn keine Antwort auf die anfänglichen EAPOL-Startmeldungen empfangen werden, sowie das Zeitintervall für die Neusendung der EAPOL-Startmeldungen, wenn keine Antwort auf die vorher gesendete EAPOL-Startmeldung empfangen wurde. Sie können auch den Zeitraum festlegen, für den der authentifizierende Client keine 802.1X-Authentifizierungsaktivität durchführen soll, nachdem er eine Authentifizierungsfehlermeldung vom Authentifikator erhalten hat, sowie den Zeitraum, den der authentifizierende Client warten soll, bevor er 802.1X-Anforderungen nach der Initiierung der End-to-End-802.1X-Authentifizierung erneut übermittelt.
Mithilfe der einmaligen Anmeldung (Single sign-on, SSO) kann konfiguriert werden, wie die 802.1X-Authentifizierung relativ zur Benutzeranmeldung stattfinden soll. Außerdem können die Benutzeranmeldeinformationen und 802.1X-Authentifizierungsinformationen auf dem Windows-Anmeldeserver integriert werden. Im Abschnitt „SSO“ stehen Einstellungen für die drahtlose Authentifizierung vor oder nach dem Benutzeranmeldeprozess und für das Festlegen der Verbindungsverzögerung in Sekunden zur Verfügung. Sie können auch angeben, ob der Benutzer zu zusätzlichen Eingaben aufgefordert werden soll, wenn die Authentifizierungsmethode zusätzliche Anmeldeinformationen erfordert, wie lange diese zusätzlichen Felder angezeigt werden sollen und ob die drahtlosen Netzwerke für dieses Profil ein anderes virtuelles LAN (VLAN) für Computer oder die Benutzerauthentifizierung verwenden sollen.
Im Abschnitt „Schnelle Serverspeicherung“ können Sie die PMK-Zwischenspeicherung und Vorauthentifizierungsoptionen konfigurieren. Der Abschnitt „Schnelle Serverspeicherung“ wird nur angezeigt, wenn Sie WPA2-Enterprise als Authentifizierungsmethode auswählen. Bei der PMK-Zwischenspeicherung werden die Ergebnisse der 802.1X-Authentifizierungen von den drahtlosen Clients und Drahtloszugriffspunkten zwischengespeichert. Der Zugriff auf einen Drahtloszugriffspunkt, den der Client bereits vorher authentifiziert hat, ist wesentlich schneller. Sie können eine maximale Zeit konfigurieren, die ein Eintrag im PMK-Zwischenspeicher beibehalten werden soll, sowie die maximale Anzahl der Einträge. Dank der Vorauthentifizierung kann ein drahtloser Client eine 802.1X-Authentifizierung mit anderen Drahtloszugriffspunkten in seiner Reichweite durchführen, während er noch mit einem anderen Drahtloszugriffspunkt verbunden ist. Wenn der drahtlose Client auf einen Drahtloszugriffspunkt zugreift, den er bereits zuvor authentifiziert hat, wird die Zugriffszeit erheblich verkürzt. Sie können konfigurieren, wie oft die Vorauthentifizierung eines Drahtloszugriffspunkts maximal versucht werden soll.
Weitere Informationen zum Support für Drahtlosnetzwerke in Windows finden Sie unter Microsoft.com/wifi. Weitere Informationen zu Windows-Gruppenrichtlinien finden Sie unter Microsoft.com/gp.

Joseph Daviesist technischer Redakteur bei Microsoft und lehrt und schreibt seit 1992 zu Themen aus dem Bereich der Windows-Netzwerke. Er hat fünf Bücher für Microsoft Press verfasst und ist der Autor der monatlich erscheinenden TechNet-Rubrik „The Cable Guy“.


 Windows PowerShell: Filtern und Formatieren von Daten
Windows PowerShell
Filtern und Formatieren von Daten
Don Jones

Es besteht kein Zweifel daran, dass Windows PowerShell ohne großen Arbeitsaufwand Ihrerseits viele wertvolle Informationen liefern kann. Betrachten Sie beispielsweise das einfache Cmdlet „Get-WMIObject“. Mit diesem Cmdlet können Sie eine Liste der Dienste auf dem lokalen Computer abrufen. Die Standardansicht, die den Status, den Namen und den Startmodus
der ausgeführten Dienste enthält, ist im Prinzip eine Befehlszeilenansicht der Dienste. Mit Windows PowerShell™ gelangen Sie jedoch leichter an diese Daten.
Es gibt aber neben den Angaben in der Standardansicht noch viel nützlichere Informationen zu Diensten. Probieren Sie einmal den folgenden Befehl aus:
$s = get-wmiobject win32_service
$s[0] | gm
Die erste Zeile des Befehls gibt eine Sammlung aller Dienste zurück (oder eher aller Instanzen der Win32_Service-Klasse aus Windows® Management Instrumentation oder WMI) und speichert sie in der Variable $s. Die zweite Zeile leitet den ersten Dienst aus dieser Sammlung (Ordnungszahl Null, in eckigen Klammern) zum Cmdlet „Get-Member“ weiter, abgekürzt mit dem Alias „gm“. Die resultierende Datenausgabe zeigt alle für diesen Datentyp verfügbaren Eigenschaften und Methoden. Hier soll die Win32_Service-Klasse in WMI anstelle des integrierten Cmdlet „Get-Service“ in Windows PowerShell verwendet werden, weil WMI mehr Daten offen legt als das Microsoft® .NET-Objekt „Service-Controller“, beispielsweise die Eigenschaft „StartName“. Diese Eigenschaft gibt den Namen des Benutzerkontos zurück, unter dem der Dienst ausgeführt wird. So können Sie den Namen einer einzelnen Instanz prüfen (z. B. der ersten Instanz):
PS C:\> $s[0].StartName
LocalSystem
Die Referenzierung der Dienste über ihre Ordnungszahl innerhalb der Sammlung ist allerdings nicht sehr sinnvoll, weil die Dienste in keiner besonderen Reihenfolge aufgeführt sind. (In der Regel sind sie alphabetisch sortiert, jedoch nicht immer.) Mit Blick auf die Verwaltung wäre wohl eine Liste aller Dienste mit dem zugehörigen Benutzerkonto für die Anmeldung am interessantesten. Dies wäre beispielsweise für eine Konformitätsprüfung von Nutzen. Betrachten wir also als Erstes die standardmäßige Datenausgabe von WMI. In diesem Beispiel soll der kürzere Alias von „Get-WMIObject“ verwendet werden, also „gwmi“ (siehe Abbildung 1).
Figure 1 Verwenden von „gwmi“ (Close Figure 1)
PS C:\> gwmi win32_service

ExitCode  : 0
Name      : AcrSch2Svc
ProcessId : 1712
StartMode : Auto
State     : Running
Status    : OK

ExitCode  : 1077
Name      : Adobe LM Service
ProcessId : 0
StartMode : Manual
State     : Stopped
Status    : OK
Schon an diesem Beispiel sehen Sie, dass die Ausgabe nicht sonderlich als Verwaltungsbericht geeignet ist. Sie möchten den Namen des Diensts erfahren und auch den „StartName“, also das Benutzerkonto, unter dem der Dienst ausgeführt wird. Weiterhin soll der Bericht übersichtlicher als in dieser etwas umständlichen Liste dargestellt werden. Genau hier kommen die beachtlichen Formatierungs- und Datenfilterungs-Cmdlets von Windows PowerShell ins Spiel.

Alle Daten, die Sie brauchen
Als Erstes sollen die Daten aus „Get-WMIObject“ so gefiltert werden, dass nur die für Sie interessanten Eigenschaften angezeigt werden. Dies lässt sich am besten mit dem Windows PowerShell-Cmdlet „Select-Object“ oder dessen einfachem Alias „select“ erreichen. „Select“ übernimmt eine Sammlung von Objekten (beispielsweise die von „Get-WMIObject“ zurückgegebene Sammlung) und zeigt dann nur die gewünschten Eigenschaften dieser Objekte an. Sie können also die Ausgabe von „gwmi“ an „select“ weiterleiten und dann die beiden gesuchten Eigenschaften auswählen. Abbildung 2 zeigt die Ergebnisse: Die Eigenschaften „Name“ und „StartName“ sind ordentlich in einer Tabelle dargestellt.
Abbildung 2 Abrufen der Eigenschaften „Name“ und „StartName“ in einer Tabelle
Abbildung 2 Abrufen der Eigenschaften „Name“ und „StartName“ in einer Tabelle
Zum Zweck einer Konformitätsprüfung enthält dieser Bericht aber immer noch zu viele Informationen. Da ein Teil der Dienste deaktiviert ist, ist es für den Bericht belanglos, welches Benutzerkonto diese deaktivierten Dienste theoretisch verwenden. Daher sollen alle Dienste herausgefiltert werden, die den Starttyp „Deaktiviert“ aufweisen. Dies ist die Eigenschaft „StartMode“ der Win32_Service-Klasse.
Bei Windows PowerShell erfolgt die Objektfilterung über das Cmdlet „Where-Object“ bzw. über den kürzeren Alias „where“. Das Cmdlet „where“ übernimmt eine Sammlung von Eingabeobjekten und führt für jedes Objekt einen Skriptblock aus, mit dem ermittelt wird, ob das jeweilige Objekt gemäß der definierten Kriterien in der Ausgabe des Cmdlet aufgeführt werden soll oder nicht. Alle Objekte, die die Kriterien erfüllen, geben den Vergleichswert „Wahr“ zurück und werden in die Ausgabe aufgenommen; Objekte mit dem Wert „Falsch“ fallen entsprechend heraus.
Damit haben Sie festgelegt, dass nur solche Objekte berücksichtigt werden sollen, bei denen die Eigenschaft „StartMode“ den Wert „Deaktiviert“ aufweist. In Windows PowerShell ergibt sich der folgende Ausdruck:
$object.StartMode –eq “Disabled”
„$object“ ist dabei nur ein Beispiel. An dieser Stelle wird kein Skript verfasst, sodass auch keine Variable mit der Bezeichnung „$object“ vorliegt. Innerhalb des Skriptblocks, der durch das Cmdlet „where“ verwendet wird, kommt allerdings eine besonderen Variable mit der Bezeichnung „$_“ zum Einsatz. Diese Variable steht für das Objekt, das derzeit durch das Cmdlet ausgewertet wird. Der „where“-Skriptblock könnte daher wie folgt aufgebaut sein:
$_.StartMode –eq “Disabled”
Dies lässt sich mühelos testen:
PS C:\> gwmi win32_service | where
{$_.StartMode -eq “Disabled”}

ExitCode  : 1077
Name      : Alerter
ProcessId : 0
StartMode : Disabled
State     : Stopped
Status    : OK
Bei diesem Schnelltest erfolgt die Ausgabe natürlich wieder im normalen Listenstil. Aus Platzgründen wird der Skriptblock für unsere Zwecke auf einen einzigen Dienst beschränkt. Dennoch ist erkennbar, dass die Ausgabe umgekehrt gestaltet ist. Hier sind die deaktivierten Dienste nicht ausgeschlossen, sondern eingeschlossen. Der Grund dafür liegt darin, dass der Skriptblock umgekehrt formuliert ist: Es sollen alle Dienste berücksichtigt werden, die nicht über den Wert „Deaktiviert“ für „StartMode“ verfügen. Dies zeigt die folgende Änderung am Beispiel:
PS C:\> gwmi win32_service | where
{$_.StartMode -ne “Disabled”}

ExitCode  : 0
Name      : AcrSch2Svc
ProcessId : 1712
StartMode : Auto
State     : Running
Status    : OK
Schon besser! Nun enthält die Ausgabe nur noch die für Sie interessanten Dienste. Leiten Sie die Ausgabe also erneut an „select“ weiter und geben Sie nur die gewünschten Eigenschaften an:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} | select name,startname
Diese Weiterleitung der Daten von einem Cmdlet zu einem anderen und dann noch zu einem dritten veranschaulicht die Leistung von Windows PowerShell. Sie haben immer noch kein Skript geschrieben, und doch haben Sie eine umfangreiche Datenmenge so gefiltert, dass Sie genau die gewünschte Ausgabe erhalten.

Das richtige Aussehen
Denken Sie daran, dass „select“ nach wie vor eine bunte Anhäufung von Objekten zurückgibt. Wenn Sie eine ordentlich formatierte Tabelle mit Windows PowerShell abrufen, ist diese Tabelle im Grunde genommen nur die PowerShell.exe-Darstellung dieser Objekte. Anders gesagt: Windows PowerShell „weiß“, dass ich als Mensch die Objekte nicht sehen kann, weshalb die Objekte als Text wiedergegeben werden. In diesem Fall werden die Objekte in Form einer Tabelle mit je einer Spalte für de einzelnen Eigenschaften wiedergegeben (siehe Abbildung 2).
Für Prüfzwecke könnte dies durchaus reichen. Das hängt ganz von den Umständen ab. Jeder Benutzer hat ganz eigene Bedürfnisse, und Windows PowerShell kann Ihre speziellen Anforderungen nicht ohne weiteres vorhersehen. Stattdessen erhalten Sie geeignete Tools, mit denen Sie die Ausgabe ganz nach Wunsch formatieren können. Die vier integrierten Cmdlets („Format-List“, „Format-Custom“, „Format-Table“ und „Format-Wide“) übernehmen eine Sammlung von Objekten (z. B. die von „select“ zurückgegebene Sammlung) und formatieren die Objekte auf unterschiedliche Weise. „Format-Table“ entspricht dabei der Formatierung, die bereits für die Ausgabe von „select“ zum Einsatz kam. Probieren Sie nun „Format-List“ aus:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | format-list
Das Ergebnis dürfte ähnlich wie dieses Beispiel aufgebaut sein:
name      : AcrSch2Svc
startname : LocalSystem

name      : Adobe LM Service
startname : LocalSystem
Mit dem Cmdlet „Format-Wide“ erhalten Sie eine mehrspaltige Liste, in der (standardmäßig) die erste Eigenschaft der einzelnen Objekte aufgeführt wird. Sehen Sie sich z. B. diese Zeile an:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
 select name,startname | format-wide
Es wird eine Liste der Dienstnamen zurückgegeben, die für Ihre Zwecke nicht geeignet ist. In der Ausgabe fehlt die Angabe für „StartName“ (siehe Abbildung 3), eine wichtige Information, die für einen Prüfbericht benötigt wird.
Abbildung 3 „StartName“ fehlt in der Ausgabe des Cmdlet „Format-Wide“
Abbildung 3 „StartName“ fehlt in der Ausgabe des Cmdlet „Format-Wide“
Dieses Beispiel beschränkt sich lediglich auf zwei Eigenschaften, sodass die Option „Format-Table“ oder „Format-List“ zu annehmbaren Ergebnissen führen müsste. Die meisten Wirtschaftsprüfer würden diese Informationen allerdings nicht gern am Bildschirm lesen. Die Ausgabe in einer Datei wäre wohl besser.

Exportieren von Daten
Wie sollten die Daten also für den Wirtschaftsprüfer dargestellt werden? Im Normalfall reicht die Ausgabe einer Liste der Dienste und Anmeldenamen in eine CSV-Datei (mit Trennzeichen zwischen den Daten), weil diese Datei problemlos in Microsoft Excel® geöffnet werden kann. Zum Erstellen einer CSV-Datei leiten Sie einfach die Ausgabe an das Windows PowerShell-Cmdlet „Export-CSV“ weiter:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | export-csv c:\services.csv
Heutzutage erscheinen CSV-Dateien oft ein wenig antiquiert. Alternativ ließen sich die Daten für den Wirtschaftsprüfer als Webseite auf einem Intranetserver darstellen. Konvertieren Sie hierzu die Ausgabe als Erstes mit dem Cmdlet „ConvertTo-HTML“ in das HTML-Format:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | convertto-html
HTML-Rohdaten sind nur schwer lesbar. Die Ausgabe muss also in eine Datei geschrieben werden:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | convertto-html | out-file c:\services.html
Das Ergebnis (siehe Abbildung 4) ist eine gut formatierte HTML-Seite, die Sie ohne weitere Änderungen auf einem Webserver bereitstellen können.
Abbildung 4 Ausgabe als gut formatierte HTML-Seite
Abbildung 4 Ausgabe als gut formatierte HTML-Seite

Nur die (relevanten) Tatsachen
Windows PowerShell eröffnet den raschen Zugriff auf umfangreiche Verwaltungsdaten. Im Rohzustand sind diese Daten jedoch geschäftlich nicht nutzbar.
Wenn Sie die Daten filtern (mit „where“), die gewünschten Objekteigenschaften auswählen (mit „select“) und dann eine geeignete Formatierungsoption anwenden (z. B. „Format-Table“ oder „Format-List“), verwandeln Sie diese Verwaltungsdaten im Handumdrehen in aussagekräftige Informationen. Durch anschließendes Exportieren in ein leicht weiterzugebendes Dateiformat können Sie diese nützlichen Daten dann anderen Mitarbeitern in Ihrem Unternehmen zur Verfügung stellen.

Don Jones ist Direktor für Projekte und Dienste bei SAPIEN Technologies und Mitautor von Windows PowerShell: TFM (SAPIEN Presse). Sie erreichen Don Jones über seine Website unter www.ScriptingAnswers.com.


 Hey, Scripting Guy!: Lokale Benutzer und Gruppen naiv &#252;bernehmen
Hey, Scripting Guy!
Lokale Benutzer und Gruppen naiv übernehmen
Die Microsoft Scripting Guys
Laden Sie den Code für diesen Artikel herunter: HeyScriptingGuy2007_04.exe (151KB)

Wie kann ich Sicherheitsdeskriptoren in Dateien und Ordnern verwalten?

Ob Sie es glauben oder nicht, es gab eine Zeit – lang, lang ist's her –, in der die Scripting Guys wirklich nicht ganz so schlau waren. Wirklich kaum zu glauben. Ach, Sie meinen, vielleicht doch nicht ganz so unglaublich? Und noch gar nicht so lange her? Na, da will ich Ihnen aber sagen ... Ok, ok, ich geb' auf. Offensichtlich haben Sie mitgekriegt, wie einer der Autoren von den Scripting Guys neulich versuchte, ein neues Fernsehgerät anzuschließen.
Zu seiner Verteidigung würde dieser Scripting Guy allerdings vorbringen, dass das Anschließen eines neuen Fernsehgeräts nicht einfache Intelligenz erfordert, sondern eher ein Genie. Allein um das Fernsehgerät anzuschließen, sind drei Videokabel und ein paar Audiokabel nötig. Darüber hinaus müssen Sie dann noch einen Videorecorder, einen DVD-Player und eine Xbox® anschließen, ganz zu schweigen vom Eintippen zufälliger Zahlenfolgen in die „universelle“ Fernbedienung, damit diese den ganzen Gerätesalat erkennt. Im Vergleich dazu ist es ein Kinderspiel, einen Satelliten in eine Umlaufbahn um den Mars zu bringen.
Bemerkenswerterweise brachte es der Scripting Guy tatsächlich fertig, alle diese Verbindungen richtig herzustellen. Als er dann aber die Geräte einschaltete, geschah nichts. Pflichtbewusst überprüfte er jede Verbindung doppelt und dreifach. Er las alle Benutzerhandbücher durch und prüfte sogar online, ob es Informationen geben könnte, die ihm entgangen waren. Nichts. Er war schon drauf und dran, dem Elektronikgott einen MP3-Player zu opfern, als er bemerkte, dass er einen kleinen, aber wichtigen Schritt vergessen hatte: das Einstecken des Kabels in die Steckdose.
Anmerkung: Vielleicht hat Ihrer Meinung nach die Scripting-Familie einfach zuviel Elektronikzeug, wenn das Ganze denn so schwierig ist. Dem würde dieser Scripting Guy tatsächlich zustimmen. Wenn jedoch die Familie über den Erwerb von noch mehr Geräten abstimmt, wird der Scripting Guy regelmäßig mit 2:0 überstimmt. Nicht etwa 2:1, sondern 2:0. Aus irgendwelchen Gründen scheint die Stimme des Vaters bei Familienwahlen der Scriptings nie mitzuzählen, und Stimmzettel gibt es ja nicht.
Um Ihre nächste Frage zu beantworten: ja, er hat schon alles versucht. Aber bisher haben die Vereinten Nationen es abgelehnt, Wahlbeobachter in sein Haus zu entsenden.
Wenn man es sich richtig überlegt, waren die Scripting Guys (na ja, vor allem der mit dem neuen Fernsehgerät) eher naiv als dumm. Als sie z. B. das Microsoft ®Windows ® 2000 Scripting-Handbuch entwarfen, baten sie einige so genannte ... Fachleute ... um Hilfe beim Schreiben der verschiedenen Kapitel. Eines der Kapitel, das unter den Tisch fiel, war ein Kapitel über die Verwaltung lokaler Benutzer und Gruppen. „Verwaltung lokaler Benutzer und Gruppen?!?” fragten die Fachleute. „Warum wird darüber überhaupt nachgedacht? Wen interessiert schon die Verwaltung lokaler Benutzer und Gruppen?“
Zu unserem großen Leidwesen haben wir seither feststellen müssen, dass sich jeder (mit Ausnahme unserer innerbetrieblichen „Fachleute“) für lokale Benutzer und Gruppen interessiert. Jede Woche erhalten wir Unmengen von E-Mails mit der Frage, wie man beispielsweise einer lokalen Gruppe einen Benutzer hinzufügt, einen Benutzer aus einer lokalen Gruppe löscht oder auf einem Computer das Kennwort des lokalen Administrators ändert.
Klar gibt es im Script Center Script Repository einige Beispielskripts für das Durchführen dieser Aufgaben, aber die meisten dieser Skripts funktionieren jeweils nur für einen Computer. Das reicht aber nicht: Die Leute wollen wissen, wie sie dies auf mehreren Computern bewerkstelligen können, und zwar gleichzeitig. Das Kennwort des lokalen Administrators auf einem einzigen lausigen Computer ändern? Jetzt aber mal im Ernst, Scripting Guys, wir wollen das auf allen unseren Computern durchführen, oder auf allen Computern in einer Organisationseinheit, oder auf allen unseren Mailservern oder ... na ja, Sie verstehen schon.
Wenn man bedenkt, dass das Scripting-Handbuch bereits 2003 veröffentlicht wurde, so werden wir seit beinahe vier Jahren von diesen immer gleichen E-Mails überschwemmt. „Hier ist noch ein Leser, der wissen will, wie er Computernamen aus einer Excel®-Tabelle lesen und dann das Kennwort des lokalen Administrators auf jedem dieser Computer ändern kann“, bemerkte kürzlich einer der Scripting Guys. „Wie schaffen wir dieses Problem denn endlich aus der Welt?“
Wir haben zwar vier Jahre gebraucht, aber jetzt haben wir die Lösung. Abbildung 1 zeigt genau, wie sich dieses Problem aus der Welt schaffen lässt.
Figure 1 Endlich haben wir das Problem gelöst (Close Figure 1)
On Error Resume Next

Set objExcel = CreateObject(“Excel.Application”)
Set objWorkbook = objExcel.Workbooks.Open(“C:\Scripts\Test.xls”)
objExcel.Visible = True

i = 2

Do Until objExcel.Cells(i, 1).Value = “”
    strComputer = objExcel.Cells(i, 1).Value
    Set objUser = GetObject(“WinNT://” & strComputer & “/Administrator”)
    If Err = 0 Then
         objUser.SetPassword “egTY634!alK2”
         objExcel.Cells(i, 2).Value = Now
    End If
    Err.Clear
    i = i + 1
Loop
Anmerkung: Sie haben wahrscheinlich schon gemerkt, dass wir nicht deshalb vier Jahre für das Skript gebraucht haben, weil es so kompliziert war, sondern weil wir einfach für alles so lange brauchen. Deshalb sollten Sie sich die alljährliche Sylvesterparty der Scripting Guys nicht entgehen lassen, denn schließlich weiß man bei ihnen nie, wann oder ob überhaupt wieder eine Party stattfindet.
Wir haben hier ein Skript, das Computernamen aus einer Tabelle entnimmt und dann das Kennwort des lokalen Administrators auf jedem dieser Computer ändert. Für diesen Zaubertrick nehmen wir einmal an, dass Ihnen eine sehr einfache kleine Tabelle vorliegt, die in etwa so aussieht wie Abbildung 2. (Wenn nicht, erstellen Sie schnell eine.)
Abbildung 2 Obligatorische Computerliste
Abbildung 2 Obligatorische Computerliste
So weit, so gut. In Spalte 1 (Spalte A) listen wir die Namen aller Computer auf, deren Kennwörter zu ändern sind. In Spalte 2 (Spalte B) verfolgen wir einfach Datum und Uhrzeit, zu denen das Administratorkennwort auf jedem Computer zuletzt geändert wurde. Auf diese Weise können Sie leicht verfolgen, ob die Administratorkennwörter alle übereinstimmen.
Was das Skript selbst betrifft, starten wir mit der Anweisung „On Error Resume Next“. Gewöhnlich machen wir uns nicht die Mühe, Fehlerbehandlung in unseren Skripts einzubeziehen. Nicht, weil wir gegen Fehlerbehandlung wären, sondern weil wir die Skripts so kurz und einfach wie möglich halten wollen. In diesem Fall aber ist die Anweisung „On Error Resume Next“ entscheidend. Schließlich soll unser Skript versuchen, eine Verbindung zu Dutzenden von verschiedenen Computern herzustellen. Was geschieht, wenn einer der Computer ausgeschaltet ist? Nun ja, mit Fehlerbehandlung wird nichts geschehen. Es wird sicher ein Fehler auftreten, aber das Skript kann ihn ignorieren und fortfahren. Ohne Fehlerbehandlung wird Ihnen so ziemlich das Gleiche passieren wie dem Scripting Guy, als er den neuen Fernseher zum ersten Mal einschaltete: Nichts.
Als Nächstes verwenden wir den folgenden Codeblock, um eine Instanz des Excel.Application-Objekts zu erstellen, machen diese Excel-Instanz auf dem Bildschirm sichtbar und öffnen die Tabelle C:\Scripts\Test.xls:
Set objExcel = CreateObject _
    (“Excel.Application”)
Set objWorkbook = objExcel.Workbooks.Open _
    (“C:\Scripts\Test.xls”)
objExcel.Visible = True
Last not least weisen wir einer i genannten Zählervariablen den Wert 2 zu. Diese Variable wird verwendet, um die aktuelle Zeile in der Tabelle zu verfolgen.
Anmerkung: Aber warum wird i der Wert 2 zugewiesen? Ganz einfach: Die Daten in der Tabelle beginnen nämlich in Zeile 2. Zeile 1 ist nur eine Kopfzeile.
Alles klar? Das Anschließen von YPbPr1-Kabeln liegt uns vielleicht nicht so, aber wir verstehen etwas von Skriptprogrammierung.
Jedenfalls ab und an.
Jetzt kann es losgehen. Zuerst richten wir eine „Do Until“-Schleife ein, die solange ausgeführt wird, bis in Spalte 1 eine leere Zelle auftaucht. Sie dürfen also auf keinen Fall Zeilen in Spalte 1 leer lassen. Wenn das Skript auf eine leere Zeile stößt, nimmt es nämlich an, dass das Ende der Daten erreicht wurde, sodass die Schleife (und das Skript) beendet werden. Obwohl es Möglichkeiten gibt, dieses Problem zu umgehen, ist es leichter, einfach leere Zeilen in der Tabelle zu vermeiden.
Innerhalb der Schleife weisen wir zunächst den in der Zeile i von Spalte 1 gefundenen Wert einer „strComputer“ genannten Variablen zu. Denken Sie daran, dass beim ersten Durchlaufen der Schleife i gleich 2 ist. Folglich arbeiten wir mit dem Wert in Zeile 2, Spalte 1. Mithilfe der folgenden Codezeile wird dann ein Objektverweis (objUser) zum lokalen Administratorkonto auf dem Computer erstellt, der durch die Variable „strComputer“ dargestellt wird:
Set objUser = GetObject(“WinNT://” & _
    strComputer & “/Administrator”)
Wenn mit diesem Skript irgendetwas schief geht, passiert es genau an dieser Stelle. Nehmen Sie z. B. an, dass Netzwerkprobleme vorliegen, dass der Computer ausgeschaltet wurde, dass einer der Scripting Guys seinen DVD-Player falsch angeschlossen und im halben Land einen Stromausfall verursacht hat. Wenn irgendeines dieser Ereignisse eintritt, kann keine Verbindung zu diesem Computer hergestellt werden. Daher muss der Wert des VBScript Err-Objekts sofort überprüft werden:
If Err = 0 Then
Wenn das Err-Objekt gleich 0 ist, konnte problemlos eine Verbindung zum Computer (und zum Administratorkonto) hergestellt werden. Wenn Err einen anderen Wert als 0 hat, kann dies nur eines bedeuten: Der Verbindungsversuch ist fehlgeschlagen. Im diesem Fall lohnt sich die Mühe natürlich nicht, das Kennwort auf dem Computer zu ändern. Wenn keine Verbindung vorliegt, kann auch das Kennwort nicht geändert werden.
Wenn alles gut geht und kein Fehler auftritt, werden die folgenden zwei Codezeilen ausgeführt:
objUser.SetPassword “egTY634!alK2”
objExcel.Cells(i, 2).Value = Now
In Zeile 1 verwenden wir die SetPassword-Methode, um dem lokalen Administratorkonto ein neues Kennwort (z. B. TY634!alK2) zuzuweisen. (Uns ist nämlich hinlänglich bekannt, dass man den Namen seines Kindes nicht als Kennwort verwenden sollte ...) In Zeile 2 schreiben wir dann das aktuelle Datum und die Uhrzeit (mithilfe der VBScript Now-Funktion) in Zeile i, Spalte 2. Beachten Sie, dass die Spalte „Password Changed“ (Kennwort geändert) nur dann aktualisiert wird, wenn tatsächlich eine Verbindung zum Remotecomputer hergestellt und das Kennwort geändert wurde. Wenn keine Verbindung möglich ist, wird das entsprechende Feld „Password Changed“ nicht aktualisiert. So kann man auf einen Blick feststellen, welche Vorgänge erfolgreich waren und welche nicht.
Und was bedeutet das nun alles? Das bedeutet, dass unsere Tabelle nach dem ersten Durchlaufen der Schleife etwa so aussieht wie Abbildung 3.
Abbildung 3 Computerliste nach dem Zurücksetzen des ersten Kennworts
Abbildung 3 Computerliste nach dem Zurücksetzen des ersten Kennworts
Soweit zu Computer 1. Jetzt müssen wir nur ein wenig Organisationsarbeit leisten, bevor es weiter geht:
Err.Clear
i = i + 1
So kurz sie auch sein mögen, diese beiden Codezeilen sind sehr wichtig. (Als ob die Scripting Guys irgendwelche Codezeilen schreiben würden, die nicht sehr wichtig sind!) Die erste Zeile setzt das Err-Objekt auf 0 zurück. Wenn kein Fehler aufgetreten ist, ist dies redundant. Schließlich ist in diesem Fall Err bereits 0. Wenn jedoch ein Fehler aufgetreten ist, hat Err einen anderen Wert als 0. In diesem Fall ist es wichtig, dass das Err-Objekt manuell zurückgesetzt wird. Warum? Weil dies die Eigenschaft des Fehlerobjekts ist: Es verfolgt nur die Fehler, nicht die Erfolge. Nehmen wir z. B. an, dass ein Problem mit Computer 1 aufgetreten ist und keine Verbindung hergestellt werden konnte. Nehmen wir weiterhin rein theoretisch an, dass dadurch das Fehlerobjekt auf 99 gesetzt wurde.
Wir fahren mit der Ausführung der Schleife fort und stellen erfolgreich eine Verbindung zu Computer 2 her. Was glauben Sie, welchen Wert Err jetzt hat? Genau: Sie können sich auf den Kopf stellen, aber Err lautet nach wie vor 99. Der Err-Objektwert ändert sich nämlich nur, wenn ein Fehler auftritt. Wenn kein Fehler auftritt, behält das Err-Objekt seinen aktuellen Wert bei.
Ist das wirklich von Bedeutung? Ja, ist es. Schließlich ändern wir technisch gesehen das Kennwort auf einem Computer nicht, wenn wir erfolgreich eine Verbindung herstellen, sondern wir ändern das Kennwort nur, wenn Err gleich 0 ist. Moment mal, was sagt der Rechner – ja, stimmt genau: 99 ist nicht gleich 0 (außer natürlich bei Wahlen in der Scripting-Familie, wo sich 99 Stimmen des Vaters auf 0 summieren.) Obwohl eine Verbindung zu Computer 2 hergestellt wurde, ist Err nicht gleich 0. Und da Err nicht gleich 0 ist, wird erst gar nicht versucht, das Kennwort des lokalen Administrators zu ändern.
Anders gesagt: wann immer der Wert von Err sich ändert, müssen Sie ihn auf 0 zurücksetzen, damit das Skript nicht glaubt, dass von dem Zeitpunkt an ein Fehler aufgetreten ist. Und wie wird das Err-Objekt auf 0 zurückgesetzt? Ganz genau: Sie rufen einfach Err.Clear auf.
Als Nächstes erhöhen wir den Wert von i um 1. Warum? Nun, beim ersten Durchlaufen der Schleife war die Variable i gleich 2, denn wir wollten ja eine Verbindung herstellen zu dem in Zeile 2 der Spalte 1 aufgelisteten Computer. Beim zweiten Durchlaufen der Schleife wollen wir eine Verbindung zu dem in Zeile 3 der Spalte 1 aufgelisteten Computer herstellen. Da i die Variable ist, die die gewünschte Zeile anzeigt, müssen wir folglich i auf 3 setzen. Wie jeder weiß, ist 2 + 1 = 3. (Wie gut, dass der Rechner noch läuft ...) Erst dann wird die Schleife erneut durchlaufen und der Prozess mit dem nächsten Computer in der Tabelle wiederholt.
Das ist schon cool, aber da wir nicht mehr so naiv wie früher sind, ist uns bewusst, dass unser Posteingang durch dieses Skript allein nur wenig schrumpfen wird. „Die Sache mit Excel war ja ganz nett,“ werden die Leute sagen, „aber ich muss immer noch das Kennwort des lokalen Administrators für alle Computer in einer Organisationseinheit oder für alle in einer Textdatei aufgelisteten Computer ändern. Eine Liste von Computern wäre auch prima, damit ich einen aus einem Listenfeld auswählen kann. Das Allerbeste wäre allerdings ... “
Immer mit der Ruhe. Ihr Wunsch ist den Scripting Guys Befehl. (Dabei gehen wir allerdings davon aus, dass Sie ohne weiteres vier Jahre auf die Erfüllung Ihrer Wünsche warten.) Wie sich herausstellt, liegen im Script Center Dutzende von Computervorlagen bereit, die es äußerst leicht machen, ein Skript für mehrere Computer auszuführen. Nehmen Sie z. B. an, dass Sie das Kennwort des lokalen Administrators für alle Computer in einer Organisationseinheit ändern wollen. Überhaupt kein Problem. Die Vorlage zum Ausführen eines Skripts für alle Computer in einer Organisationseinheit sieht aus wie Abbildung 4.
Figure 4 Ausführen eines Skripts für eine Organisationseinheit (Close Figure 4)
On Error Resume Next

Set objOU = GetObject(“LDAP://OU=Finance,dc=fabrikam,dc=com”)
objOU.Filter = Array(“Computer”)

For Each objComputer in objOU
    strComputer = objComputer.CN

    ‘
=====================================================================
    ‘ Insert your code here
    ‘
=====================================================================

    Set objComputer = GetObject(“WinNT://” & strComputer & “”)
    objComputer.Filter = Array(“User”)
    For Each objUser in objComputer
        Wscript.Echo objUser.Name
    Next

    ‘
=====================================================================
    ‘ End
    ‘
=====================================================================

Next
Sehen Sie in der Vorlage den Abschnitt mit der Aufschrift „Insert your code here“ („Geben Sie hier Ihren Code ein“)? Sie müssen nur noch den Beispielcode in diesem Abschnitt löschen und ihn durch den Code ersetzen, der das Kennwort des lokalen Administrators ändert (und den Sie aus dieser Spalte kopieren können). Ersetzen Sie, anders gesagt, den Beispielcode durch folgenden Code:
Set objUser = GetObject(“WinNT://” & _
    strComputer & “/Administrator”)
If Err = 0 Then
    objUser.SetPassword “egTY634!alK2”
End If
Err.Clear
Dieses besondere Beispiel protokolliert zwar nicht die Ergebnisse für Sie, aber Sie können den dafür erforderlichen Code leicht selbst hinzufügen. Ersetzen Sie den Beispielcode, ändern Sie die Verbindungszeichenfolge LDAP: //OU=Finance,dc=fabrikam,dc=com so, dass sie auf eine Ihrer Organisationseinheiten zeigt, und fertig.
Um die Wahrheit zu sagen, haben wir diese Vorlagen bereits vor über einem Jahr bereitgestellt und rechneten damit, dass sie zu einer der beliebtesten Komponenten im Script Center würden. Doch damit lagen wir falsch: Sie werden fast nie verwendet, obwohl uns jeden Tag eine Menge Leute schreiben und fragen, wie sie Skripts für mehrere Computer ausführen können. Wahrscheinlich wusste niemand, dass diese Vorlagen überhaupt zur Verfügung standen. Aber jetzt wissen Sie es. Zumindest dann, wenn wir Ihnen sagen, wo sie zu finden sind: microsoft.com/technet/scriptcenter/scripts/templates. Hmmm, vielleicht hat deswegen nie jemand diese Vorlagen verwendet ...
Die Scripting Guys sind zwar nicht mehr so naiv wie früher, aber sind sie immer noch so ungeschickt? Sagen wir es mal so: Vor nicht allzu langer Zeit beschloss einer der Scripting Guys, am Wochenende ein paar Dinge im Haus zu reparieren. Als er montags zur Arbeit zurückkam, hatte er einen blutigen Daumen und eine Fleischwunde am Bein.
Also eigentlich gar nicht so schlimm. Wenigstens nicht für einen Scripting Guy.

Die Microsoft Scripting Guys 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 Script Center. Besuchen Sie es unter www.scriptingguys.com.


 Sicherheit auf dem Pr&#252;fstand: Der Sicherheitskonfigurations-Assistent
Sicherheit auf dem Prüfstand
Der Sicherheitskonfigurations-Assistent
John Morello
Dieser Artikel enthält vorläufige Informationen zum Windows Server „Longhorn“, die bis zur endgültigen Version des Produkts Änderungen unterliegen.

Das effiziente und beständige Sichern von Servern ist eine Herausforderung für viele IT-Organisationen, besonders für jene mit einer großen Anzahl an Computern, die über zahlreiche geografische und organisatorische Grenzen hinweg verstreut sind. Obwohl das Absichern eines einzelnen Servers für einen qualifizierten Administrator eine verhältnismäßig einfache Aufgabe sein kann, ist das Absichern von zehn, Hunderten oder
sogar Tausenden von Servern weitaus schwieriger. Im Verlauf der Jahre haben viele Unternehmen eigene interne Prüflisten oder Standards für die Serversicherheit entwickelt bzw. die Richtlinien von Microsoft, dem National Institute of Standards and Technology oder anderen externen Parteien übernommen. Eine solche Dokumentation kann zwar äußerst wertvoll sein, reicht aber allein nicht aus, Unternehmen die Implementierung dieser empfohlenen Vorgehensweisen auf ihren Netzwerken zu ermöglichen. Folglich haben viele Unternehmen einfach die Standardinstallationseinstellungen beibehalten, oder sie haben viel Zeit und Mühe in die Erstellung eigener Skripts oder Richtlinien zum Absichern von Systemen investiert.
Mit der Einführung des Sicherheitskonfigurations-Assistenten (Security Configuration Wizard, SCW) im Windows Server® 2003 Service Pack 1 (SP1) stellt Microsoft jetzt eine einfache und unterstützte Methode zum Absichern von Servern und zum Reduzieren der Angriffsfläche auf Grundlage der jeweiligen Serverrollen bereit. Durch Kombination der Vorteile des SCW mit den zentralisierten Bereitstellungs- und Verwaltungsfunktionen der Gruppenrichtlinien lässt sich der SCW selbst auf die größten IT-Unternehmen skalieren. Dieser Artikel bietet einen Überblick darüber, wie IT-Organisationen den SCW und die Gruppenrichtlinien zum Verwalten ihrer Server auf sicherere und konsistentere Weise und bei gleichzeitiger Senkung von Bereitstellungs- und Betriebskosten einsetzen können.

Was ist der SCW?
Der SCW ist eine optionale Komponente und wird mithilfe der Systemsteuerung für Windows®-Komponenten zum Hinzufügen/Entfernen installiert, die bei allen Mitgliedern der Windows Server 2003 SP1-Produktfamilie einschließlich Windows Servers 2003 R2 zur Verfügung steht. Normalerweise führt ein Administrator den SCW zunächst auf einem Zielserver aus, um die von diesem Server erfüllten Rollen zu identifizieren. Der SCW unterstützt den Administrator dann beim Erstellen einer Sicherheitsrichtlinie, die den Computer mithilfe eines Schemas mit geringsten Rechten absichert. Der SCW stellt also sicher, dass nur die für die Serverrolle erforderlichen Dienste, Anwendungsfunktionen und Ports zur Verfügung stehen. Alle anderen Elemente werden deaktiviert. Dieser Ansatz hilft beim Reduzieren der Angriffsfläche des Zielservers. Wenn Sie Dienste ausführen, die für die vom Server durchgeführte Rolle nicht erforderlich sind, erhöhen Sie letztendlich das Risiko für den Server, ohne dass ein Gewinn an Funktionalität vorliegt. Das Deaktivieren dieser Dienste senkt das Risiko und kann zudem die Serverleistung verbessern.
Obwohl Microsoft mit Windows Server 2003 viele Sicherheitsfortschritte erzielt hat und die Gesamtangriffsfläche im Vergleich zu vorherigen Versionen von Windows Server stark reduziert wurde, basiert dieser Server nicht auf einem in Komponenten gegliederten Kern wie in Windows Vista™ und der bevorstehenden Version von Windows Server mit dem Codenamen „Longhorn“. Folglich können bei einer Standardinstallation von Windows Server 2003 Dienste aktiviert sein und ausgeführt werden, die nicht für alle Serverrollenkonfigurationen erforderlich sind. So ist beispielsweise standardmäßig ein Druckerwarteschlangendienst aktiviert, der für einen nur als Datenbankserver dienenden Computer nicht erforderlich ist.

Rollenbasierte Sicherheit wird jetzt Realität
In den letzten Jahren hat Microsoft umfangreiche sicherheitsorientierte Dokumentationen veröffentlicht, die Administratoren beim Bestimmen von für verschiedene Serverrollen erforderlichen Diensten unterstützt. Dazu wurden vorkonfigurierte Vorlagen für bekannte Rollen wie Webserver bereitgestellt. Doch Richtlinien wie im Sicherheitshandbuch für Windows Server 2003 können beim Implementieren in großen Umgebungen eine Herausforderung darstellen, da die in diesen Umgebungen verwendeten Anwendungen oft komplexer sind als grundlegende IIS- oder SQL Server-Installationen. Das Ganze wird noch durch eine Unzahl von in Unternehmen eingesetzten Drittanbieteranwendungen erschwert, die vielfach von mehreren Serverrollen abhängen und deren Anwendungs- und Dienstanforderungen in manchen Fällen unzureichend definiert sind.
SCW löst diese Probleme durch Einkapseln aller Informationen zu Abhängigkeiten und empfohlenen Vorgehensweisen aus den Handbüchern in einem administratorgesteuerten Assistenten. Wenn ein Administrator z. B. eine neue Branchenanwendung bereitstellt, für die sowohl SQL Server™ als auch IIS erforderlich ist, muss er keine Zeit mehr darauf verwenden, das Sicherheitshandbuch durchzusehen und eine eigene Liste benutzerdefinierter Abhängigkeiten zu entwickeln. Stattdessen kann er die Anwendung einfach auf dem Server installieren und den SCW starten. Der SCW erkennt, welche Dienste derzeit ausgeführt werden, und stellt dem Administrator eine Liste von Rollen zur Auswahl zur Verfügung. Abhängig von der Auswahl generiert der SCW eine Richtlinie, durch die alle Dienste deaktiviert werden, die laut Abhängigkeitsmatrix für die Rollen nicht erforderlich sind. SCW stellt auch Optionen zum Absichern der Registrierung, zum Sperren nicht benötigter Netzwerkkommunikation und zum Anwenden einer wirksamen Überwachungsrichtlinie bereit. Nach dem Ausführen des SCW kann der Administrator die SCW-Richtlinie als XML-Datei speichern und sie auf andere Server anwenden, auf denen dieselbe Branchenanwendung ausgeführt wird.
Der Einsatz des SCW bietet somit drei leistungsstarke Vorteile gegenüber traditionellen, stärker manuell orientierten Ansätzen zum Sichern von Windows Server. Erstens wird dadurch der Zeitaufwand für den Administrator verringert (und möglicherweise sogar eliminiert), ständig in der Produktdokumentation nachlesen zu müssen, um die für eine bestimmte Arbeitsauslastung erforderlichen Dienste und Einstellungen festzulegen. Dieses Wissen ist in den SCW integriert, und die fragengesteuerte Oberfläche erleichtert es dem Administrator, die erforderlichen Details bereitzustellen. Zweitens werden im SCW die Anleitungen für eine Reihe von Bereichen konsolidiert, darunter Dienstabsicherung, Reduzierung der Netzwerkangriffsfläche, Absichern der LDAP- und SMB-Dienste und Sperren von IIS. Bislang waren zum Durchführen dieser Konfigurationsaufgaben separate Dienstprogramme erforderlich, die jeweils über ihre eigene Oberfläche und einen eigenen Ansatz verfügten. Drittens werden die SCW-Einstellungen in einer XML-Richtliniendatei ausgegeben, die nach einmaliger Erstellung auf eine Vielzahl von Servern angewendet werden kann. Egal, ob Sie einen oder hundert Server zum Unterstützen einer bestimmten Branchenanwendung bereitstellen, kann dieselbe SCW-Richtlinie leicht auf alle angewendet werden. Dies führt zu einer konsistenteren Anwendung von Sicherheitseinstellungen sowie einer Senkung der Betriebskosten. Auch das Zurücksetzen von SCW-Richtlinien wird dadurch vereinfacht.

SCW-Komponenten
Trotz aller Funktionen und Vorteile ist der SCW im Grunde ein recht einfaches Tool mit drei Hauptbestandteilen. Dies sind die Assistentenschnittstelle, die Befehlszeilenschnittstelle und die Sicherheitskonfigurationsdatenbank (Security Configuration Database, SCD). Administratoren in kleinen oder mittelständischen Unternehmen interagieren möglicherweise nur mit der Assistentenschnittstelle. In größeren oder komplexeren Umgebungen können Administratoren die Befehlszeilenschnittstelle verwenden, um SCW-Aufgaben wie z. B. die Umwandlung einer SCW-Richtlinie in ein Gruppenrichtlinienobjekt (GPO) zu automatisieren. In der Regel ändern nur erfahrene Administratoren, die eigene benutzerdefinierte SCW-Rollen erstellen wollen, die SCD.
Die in Abbildung 1 dargestellte Assistentenschnittstelle ermöglicht es Administratoren, Sicherheitseinstellungen für einen Zielserver zu erstellen, zu bearbeiten, anzuwenden und zurückzusetzen. Sie bietet Administratoren Wahlmöglichkeiten in einem konsistenten Workflow, in dem nacheinander Dienste und Einstellungen, Netzwerkkonnektivität, Richtlinien zur Sicherheitsüberprüfung und schließlich IIS-Einstellungen untersucht werden.
Abbildung 1 SCW-Schnittstelle
Abbildung 1 SCW-Schnittstelle
Die SCW-Befehlszeilenschnittstelle bietet drei grundlegende Funktionen. Sie ermöglicht es Administratoren, mehrere Server (sowohl lokal als auch extern) zu analysieren und zu konfigurieren sowie Richtlinien zurückzusetzen. Sie kann verwendet werden, um eine XML-basierte SCW-Richtlinie automatisch in ein GPO zu konvertieren, das systemeigen in GPO-Standardverwaltungstools wie beispielsweise in der Gruppenrichtlinien-Verwaltungskonsole eingesetzt werden kann. Schließlich wird das in Abbildung 2 dargestellte SCW-Befehlszeilentool zum Registrieren neuer Erweiterungen der Sicherheitskonfigurationsdatenbank verwendet.
Abbildung 2 SCW-Befehlszeilentool
Abbildung 2 SCW-Befehlszeilentool
Die SCD ist lediglich eine Sammlung von XML-Dateien, in denen die für die jeweilige SCW-Rolle erforderlichen Dienste und Einstellungen ausführlich beschrieben werden. Diese Dateien befinden sich im Verzeichnis %windir%\security\msscw\kbs. Standardmäßig enthält der SCW eine Reihe von zentralen Windows Serverrollen sowie 12 vordefinierte Anwendungsrollen, einschließlich: BizTalk®, Commerce Server, Exchange Server, Host Integration Server, Internet Internet Security and Acceleration Server, Microsoft Identity Integration Server, Microsoft Operations Manager, Small Business Server, SharePoint® Portal Server, SharePoint Team Services, SQL Server und Systems Management Server. Jede Rolle hat ihre eigene XML-Datei (siehe Abbildung 3). Jedes Mal, wenn eine neue Rollendefinition erstellt wird, wird die entsprechende XML-Datei in dieses Verzeichnis gestellt. Bei den Dateien handelt es sich um Standard-XML-Dateien, die mit jedem beliebigen Text-Viewer oder einer anderen Anwendung gelesen werden können, die XML unterstützt (siehe Abbildung 4).
Abbildung 3 Vordefinierte Rollen
Abbildung 3 Vordefinierte Rollen
Abbildung 4 Rollenkonfigurationsdatei
Abbildung 4 Rollenkonfigurationsdatei

Kombinieren des SCW und der Gruppenrichtlinien
Für sich ist der SCW schon ein hervorragendes Tool, doch seine wahre Leistung wird erst bei der Kombination mit den Gruppenrichtlinien ersichtlich. Seit der Veröffentlichung von Windows® 2000 stand bei den Microsoft-Empfehlungen zum Sichern von Windows-Servern die Verwendung der Gruppenrichtlinien zum Bereitstellen einer konsistenten, permanenten, zentral verwalteten Richtlinienanwendung im Mittelpunkt. Durch das Gruppieren von Servern in Organisationseinheiten (Organizational Units, OUs) auf der Grundlage von Rollen können Administratoren Standardsicherheitskonfigurationen im ganzen Unternehmen und nicht nur für einzelne Computer bereitstellen. Auf Grundlage der Standardgruppenrichtlinien und der Anwendungslogik können Unternehmen eine mehrstufige Serverrollenhierarchie entwerfen, in der Hunderte oder Tausende einzelner Server durch einige wenige Hauptrichtlinien gesichert werden. Wenn eindeutige Serverrollen eine Abweichung von den Hauptrichtlinien verlangen, können in der Hierarchie der Organisationseinheiten „näher“ an den Servern kleinere, rollenfokussierte Deltarichtlinien erstellt werden. So kann eine rollenspezifische Funktion lediglich über kleine Änderungen aktiviert werden, ohne dass die gesamte Hauptrichtlinie dupliziert werden muss – ein Ansatz, der großen Unternehmen einerseits die Vorteile zentral verwalteter Richtlinien bietet, andererseits die Flexibilität, bei Bedarf bestimmte Anwendungen anpassen zu können.
Die eigentliche Herausforderung bei diesem Ansatz besteht darin, ihn in die Realität umzusetzen. In großen Organisationen mit vielen verschiedenen Anwendungen und Serverrollen war es bisher schwierig und zeitaufwändig, den richtigen Satz an Richtlinien zu erstellen – aber jetzt gibt es dazu den SCW. Wenn Sie mithilfe des SCW Richtlinien erstellen und diese Richtlinien dann an die richtige Organisationseinheit anfügen, können Sie verzeichnisgehostete, rollenbasierte Sicherheit sowohl für die aktuelle als auch für die zukünftige Arbeitsauslastung erheblich reduzieren. Zur Veranschaulichung dieses Prozesses soll die Implementierung des SCW und rollenbasierter GPOs in einem großen Unternehmen erläutert werden.

SCW im Unternehmen
Für dieses Beispiel verwende ich das fiktive Netzwerk bei Contoso. Der IT-Bereich bei Contoso ist umfangreich und komplex und befindet sich an verschiedenen geografischen Standorten. Contoso will die Betriebskosten senken und gleichzeitig die Serversicherheit erhöhen. Dazu befolgt das Unternehmen die Empfehlungen von Microsoft zum Erstellen einer rollenbasierten Hierarchie der Organisationseinheiten, bei der die Server je nach Arbeitsauslastung getrennt und organisiert werden. Um die Richtlinien für die Organisationseinheiten zu erstellen, verwendet Contoso den SCW.
Da der SCW nicht standardmäßig installiert ist, muss die SCW-Komponente im Abbild der unbeaufsichtigten Installation aktiviert werden. Dazu wird eine neue Zeile, SCW=On, dem Abschnitt [Components] von Unattend.txt hinzugefügt. Danach wird bei allen neuen Systemen, die mit diesem Abbild erstellt werden, die SCW-Komponente beim Setup installiert. Beachten Sie, dass beim Einrichten von Computern keine Richtlinien angewendet werden, wenn der SCW einfach nur zur Installation konfiguriert wird.
Um eine Standardrichtlinie während des Installationsvorgangs anzuwenden, bearbeitet Contoso den Abschnitt [Commands] der cmdlines.txt-Datei im Abbild, um scwcmd mit den folgenden Optionen aufzurufen:
scwcmd configure /p:ContosoBaselinePolicy.xml
Sowohl die Textdatei als auch die XML-Datei muss im $OEM$-Verzeichnis des Abbilds vorhanden sein: Warum wendet Contoso beim Erstellen eine Basisrichtlinie an, statt sich einfach auf die Richtlinie zu verlassen, die der Organisationseinheit auf oberster Ebene im Verzeichnis angefügt ist? Durch Anwenden einer Richtlinie beim Erstellen kann Contoso eine konsistente Basisrichtlinie gewährleisten, unabhängig davon, ob ein Computer mit Active Directory® verbunden ist. Wenn z. B. ein Server für Testzwecke erstellt wird, stellt das Anwenden der Basisrichtlinie während des Buildprozesses sicher, dass zumindest die Standardsicherheitsrichtlinie des Unternehmens befolgt wird, selbst wenn der Server nie mit dem Active Directory-Produktionsserver verbunden wird. Bei einer späteren Verbindung des Servers mit dem Active Directory überschreiben die Gruppenrichtlinienanwendung und der Rangfolgenalgorithmus die lokalen Einstellungen mit denen der Domänen- oder Organisationseinheitsebene (die Richtlinienanwendung erfolgt in dieser Rangfolge: lokaler Computer, Standort, Domäne, Organisationseinheit).
Nach Installation des SCW kann Contoso mit dem Erstellen der Basisrichtlinie beginnen. Bei der Basisrichtlinie handelt es sich um die auf der obersten Ebene der rollenbasierten Sicherheitshierarchie der Organisationseinheit bereitgestellte Richtlinie. In der Regel handelt es sich zudem um die Richtlinie mit der am stärksten eingeschränkten Hierarchie. Dadurch wird eine möglichst sichere Standardrichtlinie erstellt, bei der dann je nach Arbeitsauslastung nur die Dienste und Ports geöffnet werden, die für die jeweiligen Serverrollen erforderlich sind. Die Basisrichtlinie sollte daher auf einem neuen, leeren Server erstellt werden, dem die Standardverwaltungstools und -dienstprogramme von Contoso hinzugefügt werden, bevor der SCW darauf ausgeführt wird. Nach Abschluss der Windows-Standardinstallation installiert Contoso beispielsweise (entweder manuell oder mithilfe der cmdlines.txt-Datei) seine standardmäßigen Antivirus-, Sicherungs-, Verwaltungs- und Überwachungstools auf dem Server. Da all diese Tools wahrscheinlich ihre eigenen Windows-Dienste erstellen, kann sich der SCW während der Dienstsperrungsphase auf sie einstellen, wenn sie vor Erstellen der Basisrichtlinie auf dem Server vorhanden sind.
Nach dem Erstellen des Servers führt Contoso den SCW darauf aus. Der SCW kann lokal oder von einem Remotestandort aus und nur von einem Mitglied der lokalen Administratorengruppe des Computers ausgeführt werden. Wenn der SCW von einem Remotestandort aus ausgeführt wird, bietet er eine Option zur Angabe des Benutzerkontos, unter dem er auf dem Remotehost ausgeführt werden soll. Wenn der SCW lokal ausgeführt wird, können Sie dazu runas.exe verwenden. Die erste Aufgabe von SCW besteht in der Bewertung der auf dem lokalen Computer ausgeführten Dienste und der Anzeige der derzeit installierten Rollen (siehe Abbildung 5).
Abbildung 5 Auswählen und Anzeigen der Serverrollen
Abbildung 5 Auswählen und Anzeigen der Serverrollen
Auf dem Basisserver von Contoso sollen keine Rollen ausgewählt werden, da der Computer für einen sehr eingeschränkten Zustand ausgelegt ist. Nachdem die vom Server durchgeführten Rollen ausgewählt wurden, besteht der nächste Schritt in der Identifizierung der erforderlichen Clientfeatures, um Funktionen wie z. B. automatische Aktualisierungen, Active Directory oder den FTP-Client zu aktivieren. Für die meisten Unternehmen bietet das Akzeptieren des SCW-Standards (wie in Abbildung 6 dargestellt) wichtige Funktionen, beispielsweise die Möglichkeit, eine Domäne anzuschließen, während weniger kritische Features, wie etwa der FTP-Client, nicht zugelassen werden.
Abbildung 6 Installierte Features
Abbildung 6 Installierte Features
Der SCW bietet Ihnen dann die Möglichkeit, weitere spezifische Verwaltungstools und Dienste außerhalb der Standarddienste zuzulassen. Wegen dieser nicht standardmäßigen Dienste sollte der SCW nach der Installation der Standardserververwaltungstools von Contoso ausgeführt werden. Nach Installation der Antivirus-, Sicherungs- und verwandten Anwendungen ist der SCW dann in der Lage, diese Dienste zu erkennen und sie in die resultierenden Richtlinieneinstellungen einzubeziehen.
Bei der letzten Frage zum Thema Diensthärtung geht es darum, wie nicht aufgeführte Dienste behandelt werden. Dies sind Dienste auf anderen Computern, auf denen die SCW-Richtlinie angewendet wird, die aber nicht auf dem Computer ausgeführt werden, auf dem die Richtlinie ursprünglich erstellt wurde. Wenn die Basisrichtlinie beispielsweise für einen neuen Server angewendet wird, auf dem eine Anwendung von einem Drittanbieter vorhanden ist, werden alle von dieser Anwendung installierten Dienste entsprechend der hier vom Administrator getroffenen Wahl behandelt. Der SCW ermöglicht es dem Administrator, den Startmodus des Diensts entweder nicht zu ändern oder ihn zu deaktivieren. Die Deaktivierung ist die sicherere Option, aber sie sollte mit Vorsicht verwendet werden, da Dienste, die nicht explizit ausgeführt werden dürfen, an der Ausführung gehindert werden. Aus diesem Grund ist diese Option am besten für effektiv verwaltete Hochsicherheitsumgebungen geeignet. Für andere Teile einer Organisation wird empfohlen, den Startmodus nicht zu ändern. Daher ist dies die für das Contoso-Beispiel gewählte Option. Vor dem Abschließen der Aufgaben im Bereich Diensthärtung erstellt der SCW einen Bericht über alle Dienste, die geändert werden.
Nach Abschluss der Diensthärtung bietet der SCW Optionen, mit denen eingehender Netzwerkzugriff beschränkt werden kann. Genau wie die Liste der für eine bestimmte Rolle erforderlichen Dienste ist die Liste der für eine bestimmte Arbeitsauslastung erforderlichen Ports in der XML-Datenbank des SCW enthalten.
Administratoren können bei Bedarf zusätzliche Ports konfigurieren und außerdem Portregeln für jeden Dienst erstellen, wie in Abbildung 7 dargestellt. Für den Basisserver von Contoso sollten nur die grundlegendsten Dienste wie z. B. Remotedesktop zugelassen werden. Alle anderen Ausnahmen werden in den rollenbasierten Richtlinien konfiguriert, die sich auf einer niedrigeren Ebene in der Hierarchie der Organisationseinheiten befinden.
Abbildung 7 Anzeigen und Zulassen von Ports
Abbildung 7 Anzeigen und Zulassen von Ports
Der SCW ermöglicht es dem Administrator dann, Registrierungsoptionen wie z. B. das Signieren von Datei- und Druckdatenverkehr auszuwählen. Auch hier ist die Wahl der sichersten Standardwerte in der Basiskonfiguration wieder die empfohlene Vorgehensweise.
Bei den nächsten Auswahlmöglichkeiten geht es um die Systemüberwachungsrichtlinie. Auf den meisten Systemen ist die Wahl der Option „Erfolgreiche Aktivitäten überwachen“ am besten. Die Überwachung aller Aktivitäten ist prozessorintensiv und erzeugt eine beachtliche Datenmenge im Überwachungsprotokoll. Wenn der Verdacht eines Angriffs besteht oder eine ausführlichere Analyse erforderlich ist, kann die Fehlerüberwachung auf dem betreffenden Computer aktiviert werden.
Schließlich werden dem Administrator im SCW Optionen zur IIS-Absicherung angezeigt. Diese Optionen ähneln jenen im IIS-Sperrprogramm und sind nun direkt in der SCW-Richtlinie integriert.
Nach Abschluss aller Schritte wird der Administrator zum Speichern der XML-Datei aufgefordert. Die gespeicherte Datei muss dann in ein Format konvertiert werden, das systemeigen von den Gruppenrichtlinien verstanden wird. Scwcmd.exe dient zum Umwandeln der gespeicherten XML-Datei in ein GPO. Dazu geben Sie diesen Befehl ein:
scwcmd transform /p:ContosoPolicy.xml /g:ContosoBaselineSecurityPolicy
Diese Richtlinie wird automatisch in Active Directory erstellt und kann oben in der rollenbasierten Absicherungshierarchie der Organisationseinheiten von Contoso angefügt werden.
Nach Anwenden dieser Richtlinie auf der obersten Ebene der Hierarchie erben alle Computer, die der Hierarchie der Organisationseinheiten hinzugefügt werden, ihre Einstellungen. Wenn ein Computer hinzugefügt wird, bei dem Änderungen dieser Richtlinie erforderlich sind (wie z. B. ein IIS-Server, auf dem der W3SVC-Dienst ausgeführt werden muss), führen die Administratoren von Contoso den SCW erneut für diese neue Serverrolle aus, wandeln die neue Richtlinie in ein GPO um und fügen dieses GPO einer neuen untergeordneten Organisationseinheit hinzu, die die Server enthält. Da das dem Server nächste GPO Vorrang hat, sind am Ende alle grundlegenden Einstellungen an der richtigen Stelle, mit Ausnahme derjenigen, die zum Aktivieren der gewünschten Rollenfunktion für diese Organisationseinheit geändert werden müssen (siehe Abbildung 8).
Abbildung 8 Richtlinienanwendung bei Contoso
Abbildung 8 Richtlinienanwendung bei Contoso
Die wirkliche Stärke dieses Ansatzes wird in größeren Unternehmen oder bei der Bereitstellung vieler Server klar. Nach Erstellen der anfänglichen SCW-Richtlinie und ihrer Anfügung an eine Organisationseinheit brauchen nachfolgende Server einfach nur dieser Organisationseinheit hinzugefügt werden. Sie erben dann automatisch die richtige Sicherheitsrichtlinie. Wenn der anfängliche Satz an Richtlinien erst einmal erstellt und Active Directory hinzugefügt wurde, ist das Bereitstellen neuer Server oder das Ersetzen vorhandener ein einfacher und schneller Prozess.

Blick in die Zukunft
Die nächste Veröffentlichung von Windows Server „Longhorn“ enthält ein in viele Komponenten gegliedertes Betriebssystem, was zu einer standardmäßig rationalisierten und begrenzten Angriffsfläche führt. Administratoren sperren somit nicht lediglich die minimale Standardinstallation, sondern verwenden das Server-Manager-Tool, um die für den jeweiligen Server erforderlichen Rollen und die Arbeitsauslastung hinzuzufügen. Server-Manager ist dem SCW sehr ähnlich, da ebenfalls eine interne Datenbank von Abhängigkeiten vorliegt, die es dem Installationsprogramm ermöglichen, nur jene Teile von Funktionen hinzuzufügen, die zum Bereitstellen des gewünschten Rollendiensts erforderlich sind. Außerdem wird die zentral verwaltete rollenbasierte Sicherheit unter Verwendung von Gruppenrichtlinien – wie in diesem Artikel erörtert – durch einen stark erweiteten Satz an GPO-gesteuerten Features noch verbessert. Kurz gesagt, Windows Server „Longhorn“ setzt durch erhöhte Flexibilität und noch stärkere integrierte Sicherheit beim SCW-Konzept neue Maßstäbe.
SCW-Ressourcen
Die folgenden Webseiten werden Ihnen den Start bei der Verwendung des SCW erleichtern:
  • Dokumentation zum Sicherheitskonfigurations-Assistenten
  • Sicherheitskonfigurations-Assistent für Windows Server 2003
  • Windows Server „Longhorn“

John Morello hat sein Studium an der Louisiana State University absolviert und ist seit sechs Jahren in verschiedenen Funktionen für Microsoft tätig. Als leitender Berater hat er Sicherheitslösungen für Fortune 100-Firmen sowie für US-amerikanische Kunden aus dem zivilen Bereich und dem Verteidigungswesen entworfen. Derzeit arbeitet er als leitender Programm-Manager in der Windows Server Group an Sicherheits- und Remotezugriffstechnologien.


 Die Desktopdateien: Wenn ich x64 bin
Die Desktopdateien
Wenn ich x64 bin
Wes Miller

Windows XP ist seit mehr als fünf Jahren systemintern für 64-Bit-Architekturen verfügbar. Aber wenn Sie nicht einer der frühen Anwender des Intel Itanium-Prozessors waren (Windows XP für den Itanium wurde zur selben Zeit wie Windows XP geliefert), haben Sie davon wahrscheinlich erst vor kurzem durch die Verfügbarkeit der Windows XP und Windows
Server 2003-Versionen für x64-Systeme gehört. x64, in der Branche auch als x86-64 bezeichnet, ist der generische Name für die AMD64-Architektur von AMD und EM64T von Intel. Wenn Sie innerhalb des letzten Jahres einen neuen PC gekauft haben, ist es durchaus möglich, dass er 64-Bit-fähig ist, auch wenn er gegenwärtig mit 32-Bit läuft (was wahrscheinlich ist).
Zurzeit arbeite ich für ein kleines, neu gegründetes Unternehmen in Austin, Texas, USA. Aufgrund der Architektur eines unserer Produkte sind wir daran interessiert, bestimmte Vorteile der x64-Architektur zu nutzen, ähnlich wie das Microsoft® Exchange 2007-Team, das den Maßstab gesetzt hat und jetzt alle Produkte für die x64-Architektur ausliefert. Außerdem ist das von mir verwaltete Entwicklungs- und Testteam ausschließlich auf x64-Versionen von Windows® XP und Windows Server® 2003 für Entwicklungsarbeitsstationen, Laptops, Server und Produktionsserver bereitgestellt. Weiterhin führe ich Windows XP Professional x64 Edition auf meinem persönlichen Laptop aus, um unser Produkt zu testen und zu debuggen.
Interessanterweise reagieren die meisten Leute anfangs ziemlich unsicher, wenn ich die Ausführung von 64-Bit Windows – dazu auf einem mobilen System – erwähne. Wenn sie sich mit 64-Bit-Computern auskennen, ist es oft eine Mischung aus Ungläubigkeit und Erstaunen, begründet durch die verbreitete Annahme, dass Gerätetreiber für 64-Bit-Systeme kaum aufzutreiben sind. Im Artikel dieses Monats wird erläutert, wie und warum ich Windows XP und Windows Server 2003 auf x64-Systemen im 64-Bit-Modus verwende. Zudem werden Vorteile und mögliche Hindernisse bei der Bereitstellung aufgezeigt. Außerdem behandle ich Aspekte zur Unterstützung, Migration und Bereitstellung von Windows Vista x64.

Ein kurzer Rückblick
Wie bereits erwähnt, beginnt die Geschichte der 64-Bit-Unterstützung in Windows eigentlich mit der Unterstützung für den Intel Itanium-Prozessor. Obwohl Windows für den 64-Bit-Alphaprozessor verfügbar war, war Windows beim Ausführen auf dem Alpha in der Praxis nie wirklich 64-Bit. Da es keine Unterstützung für Itanium in Windows XP und Windows Vista gibt, obliegt es der x64-Architektur, 64-Bit-Windows-Clientcomputer zu unterstützen. Zurzeit ist eine größere Auswahl an Windows Server 2003 Editions für x64 verfügbar als für Itanium (das mehr oder weniger für ultrahohe Datencenterarbeitslasten abgestellt wurde), ein Trend, der sich meiner Ansicht nach mit der nächsten Version von Windows Server mit dem Codenamen „Longhorn“ fortsetzen wird.
Unterstützung für Windows auf der x64-Plattform stand ab Lieferung des Windows Server 2003 Service Pack 1 (SP1) zur Verfügung. Verwirrend war, dass die x64-Version von Windows XP zum selben Zeitpunkt verfügbar wurde, was bedeutet, dass Windows XP 32-Bit-Produkte und 64-Bit-Produkte aus unterschiedlichen Codestrukturen innerhalb von Windows abgeleitet wurden. Für 32-Bit-Produkte steht zwar zurzeit ein zweites Service Pack zur Verfügung, aber die 64-Bit-Version von Windows XP verfügt praktisch über gar keine Service Pack-Version (man könnte es so sehen, dass bereits SP1 für Windows Server 2003 integriert ist).
Für die Ausführung von 64-Bit-Windows – Windows XP, Windows Server 2003, Windows Vista oder Windows Server „Longhorn“ – sind die Anforderungen im Prinzip die gleichen. Zunächst ist natürlich ein 64-Bit-fähiger Prozessor erforderlich. Im Fall von AMD bedeutet dies ein einzelnes, doppeltes oder Vierkernsystem, das AMD64-Kompatibilität verspricht (siehe amd.com/us-en/Processors/ProductInformation/0,,30_118,00.html). Für Intel bedeutet dies die Suche nach einem einzelnen, doppelten oder Vierkernsystem, das entweder EM64T-Unterstützung oder die Intel 64-Architektur bietet (siehe intel.com/technology/intel64). Hierbei kommt es aufs Detail an. Ein Intel Core Duo-System ist beispielsweise nicht 64-Bit-fähig. Ein Intel Core 2 Duo-System ist 64-Bit-fähig, auch wenn es oft einfach als ein Centrino Duo (wie im Falle meines Laptops) bezeichnet wird.

Arbeiten mit x64
Wenn Sie ermittelt haben, ob Ihr System eine 64-Bit-Version von Windows systemeigen unterstützt, müssen Sie sich als Nächstes um den Gerätesupport kümmern. Obwohl Microsoft Anbieter und OEMs in WinHEC-Sitzungen über mehr als 2 Jahre hinweg ermutigt hat, 64-Bit-Treiber für ihre Geräte und Systeme zu erstellen und zu zertifizieren, ist die größte Herausforderung bei der Verwendung von Windows x64 das Auffinden von Treibern für Hardwaregeräte oder Software. Meiner Erfahrung nach funktioniert das Ausführen von x64 auf einem Server am besten, wenn die erforderliche Geräteunterstützung eingeschränkt und der Einsatz von x64 daher logisch ist.
Am schwierigsten ist es, Treiber für Desktop- und mobile Systeme zu finden. In der Regel liegen Sie bei einem großen OEM-Anbieter oder einem aus Unternehmenskomponenten aufgebauten System eher richtig, da die Wahrscheinlichkeit eines geschäftlichen Einsatzes den Anbieter oder OEM oft dazu veranlasst, x64-fähige Treiber zu erstellen und zu signieren.
Für Windows Vista sieht es allerdings schon viel besser aus. Statt einer Welt, in der x86 die bevorzugte Architektur und x64 die ignorierte Architektur mit eingeschränkt verfügbaren Treibern für die Mehrzahl der Hardware ist, ist nun das Gegenteil der Fall. Für Windows Vista muss ein Geräteanbieter x64 Treiber für Kompatibilitätsprüfungen zur Verfügung stellen. x86-Treiber müssen dabei nicht unbedingt vorliegen. Bestimmte Hardware, insbesondere Geräte, die die Vorteile der neuen Windows Vista-Funktionen nutzen, verfügt also im Grunde nur über x64-Windows-Unterstützung und nicht über x86-Unterstützung.
Treiber sind allerdings in der Praxis nur eins der Probleme, denen Sie sich beim Versuch der systemeigenen Ausführung von 64-Bit-Windows gegenüber sehen. Das größere Problem ist, überhaupt so weit zu kommen (mit anderen Worten, die Migration). Mehr dazu weiter unten im Artikel.

Gründe für 64-Bit
AMD, Intel und Microsoft sind natürlich nicht nur zum Spaß zu einer 64-Bit-Architektur übergegangen. Die Umstellung auf 64-Bit bietet mehrere wichtige Vorteile. Wie in Abbildung 1 verdeutlicht, ist die wichtigste Verbesserung innerhalb der x64-Architektur die Möglichkeit, erheblich mehr Speicher zu verarbeiten: bis zu 16 Terabyte (TB) im Gegensatz zu den 4 GB in 32-Bit-Windows. 64-Bit-Zeiger können zwar bis zu 16 TB verarbeiten, Anwendungen haben aber nur Zugriff auf bis zu 8 TB.
Figure 1 Adressenspeicherplatzbeschränkungen (Close Figure 1)

Adressbereich | 64-Bit-Windows | 32-Bit-Windows
Virtueller Arbeitsspeicher | 16 TB | 4 GB
Auslagerungsdatei | 512 TB | 16 TB
Ausgelagerter Pool | 128 GB | 470 MB
Nicht ausgelagerter Pool | 128 GB | 256 MB
Systemcache | 1 TB | 1 GB
Zusätzlich bieten x64-Versionen von Windows Hardware-basierte Datenausführungsverhinderung (DEP). Diese ist ebenfalls auf x86-Systemen mit NX (No Execute)-Unterstützung verfügbar. Dies ermöglicht eine hardwaregesteuerte Lösung, die Windows für eine Verhinderung von Pufferüberläufen einsetzt. So wird die Codeausführung von Datenseiten im Speicher verhindert. Unter support.microsoft.com/kb/875352 finden Sie weitere Informationen zu diesem Thema.
X64-Versionen von Windows ermöglichen systemeigene Unterstützung von Multiprozessor- oder Multicore-CPUs, ebenso wie x86-Versionen von Windows. Eine der größten Komplexitäten der Bilderstellung eines Windows XP-Systems wird durch Verwendung einer einzelnen Hardware-Abstraktionsschicht (HAL) über alle Windows x64-Installationen hinweg beseitigt: Es gibt also keine weiteren Probleme bei der Erkennung der auf nicht-ACPI- oder Einzel-CPU-Systemen verwendeten HAL.
Im Grunde ermöglicht Ihnen Windows x64 als Architektur die Verwendung Ihrer vorhandenen Verwaltungsinfrastruktur und vorhandener 32-Bit-Software (durch Emulation) plus 64-Bit-Software mit der Möglichkeit, auf einen erheblich erweiterten Speicher zuzugreifen. Die einzigen unangenehmen Nebenwirkungen eines Wechsels zu Windows x64 sind die folgenden: Die fehlende Unterstützung für 16-Bit-Anwendungen (einschließlich 32-Bit-Anwendungen mit 16-Bit-Installer), Probleme mit Anwendungen, die nicht zuverlässig ausgeführt werden können, wenn Hardware-DEP aktiviert ist (obwohl DEP für einzelne Prozesse nacheinander deaktiviert werden kann und das Windows-Anwendungskompatibilitätsteam einen Shim für bestimmte Anwendungen einfügt, die nicht korrekt mit aktiviertem DEP ausgeführt werden) und schließlich die Tatsache, dass alle Treiber in 64-Bit Windows Vista digital signiert sein müssen.
Dieses letzte Element wurde hinzugefügt, um eine Manipulation des Windows-Kernels im Speicher zu verhindern, ein Verfahren, das häufig von Rootkits verwendet wird. Da x64 für Microsoft die Architektur ist, für die Anbieter vorranging Treiber entwickeln sollen (um diese Treiber dann durch die Windows-Hardwarequalitätsprüfung zu bringen), ist diese Anforderung wohl nicht so abschreckend wie in der Vergangenheit.
Bei der Berücksichtigung von Windows für x64-Systeme sind noch ein paar andere Punkte in Betracht zu ziehen. Es gibt keine Versionen von Windows XP für x64-Systeme, die die Funktionalität Windows Media® Center Edition oder Windows Tablet PC Edition bereitstellen. Dies ändert sich jedoch in Windows Vista, in dem die x64-Versionen von Windows über dieselbe Funktionalität wie x86-Versionen verfügen.

Virtualisierung
Noch nicht erwähnt habe ich die Virtualisierung. Damit meine ich nicht die Virtualisierungsprodukte für Microsoft Virtual PC oder VMWare PC, sondern die Betriebssystemvirtualisierung für ausführbare 32-Bit-Dateien. In 32-Bit-Versionen von Windows werden 16-Bit-Anwendungen alle innerhalb des Kontexts des NTVDM, eines virtuellen MS-DOS®-Computers ausgeführt. Wie ich bereits erwähnt habe, gibt es keine Unterstützung für 16-Bit-Anwendungen in den 64-Bit-Versionen von Windows. Die meisten integrierten Komponenten von Windows werden zwar systemeigen als 64-Bit-Binärdateien ausgeführt, aber manche Komponenten und zahlreiche Programme von Drittanbietern als 32-Bit-Anwendungen.
Windows bietet daher eine komplett neue Emulationsschicht namens Windows On Windows (WOW), um diesen 32-Bit-Anwendungen eine andere Ansicht des Betriebssystems zu bieten, das effektiv auf einer 32-Bit-Version von Windows läuft. Unter WOW erkennen x86-Anwendungen Programmdateien (X86) einfach als Programmdateien. Ebenso sehen x86-Anwendungen %WINDIR%\SysWOW64 als %WINDIR%\System32. x86-Anwendungen sehen den Registrierungsschlüssel HKLM\SOFTWARE\Wow6432Node genauso, wie sie den HKLM\SOFT-WARE-Knoten selbst sehen würden.
Mithilfe des Process Explorer-Tools erhalten Sie eine andere Perspektive der Virtualisierung. Da viele 32-Bit-Anwendungen normalerweise mit integrierten 32-Bit-Windows-Binärdateien interagieren, werden zahlreiche dieser Binärdateien sowohl in 64- als auch 32-Bitversionen bereitgestellt. Durch Hinzufügen einer zusätzlichen Spalte zum Process Explorer wird dies sichtbar. In Abbildung 2 sind zwei Instanzen von cmd.exe dargestellt, eine 32-Bit-Version und eine 64-Bit-Version. Beachten Sie, dass die markierte 32-Bit-Instanz mehrere wow64*-DLLs enthält, die im 32-Bit-Prozess geladen werden. Diese zeigen den Virtualisierungsvorgang, der 32-Bit-Anwendungen ein Funktionieren unter 64-Bit Windows ermöglichen. Beachten Sie außerdem das Arbeitsverzeichnis (Pfad), das von den 64- und 32-Bit-Versionen von cmd.exe verwendet wird.
Abbildung 2 Process Explorer zeigt die 32-Bit- und 64-Bit-Versionen von cmd.exe
Abbildung 2 Process Explorer zeigt die 32-Bit- und 64-Bit-Versionen von cmd.exe
Noch eine letzte Bemerkung zum Thema Virtualisierung: Windows führt explorer.exe als systemeigene 64-Bit-Anwendung aus, was Vor- und Nachteile hat. Der größte Nachteil ist, dass jede Explorer-Shellerweiterung für x64 erneut kompiliert werden muss, um zu funktionieren.
Das Gegenteil gilt für Internet Explorer® – dieser wird systemeigen mit der 32-Bit-Version als Standard ausgeführt. Der Grund hierfür ist, dass die Vielzahl an ActiveX®-Steuerelementen, die bereits im Internet verwendet werden, dann ohne Änderungen weiter funktionieren. Da 64-Bit-Anwendungen 32-Bit DLLs oder Treiber nicht prozessintern laden können, besteht effektiv ohne diese Funktion keine Möglichkeit, 32-Bit-ActiveX-Steuerelemente zu laden. Dabei handelt es sich um fast alle aktuell verfügbaren ActiveX-Steuerelemente auf einem 64-Bit-Browser, was bedeutet, dass ein Großteil an Internetinhalt unzugänglich würde. Um dies in der Praxis zu sehen, laden Sie C:\Program Files\Internet Explorer\iexplore.exe auf einem 64-Bit-Windows-System und rufen eine beliebige Site auf, die ActiveX-Steuerelemente (selbst Windows Update) lädt. Sie erhalten auf jeden Fall einen Fehler. In Windows Update (siehe Abbildung 3) wurde nun die Funktion aktualisiert, eine 32-Bit-Instanz von Internet Explorer in dieser Situation zu öffnen. In Zukunft wird das ActiveX-Steuerelement sicherlich aktualisiert werden, um die Vorteile des 64-Bit Internet Explorer zu nutzen. Da die Mehrzahl der Windows-Systeme heutzutage jedoch ausschließlich 32-Bit Windows ausführt, ist eine Aktualisierung des ActiveX-Steuerelementinhalts nicht unbedingt notwendig. Dies wird sich meiner Meinung nach auch so bald nicht ändern.
Abbildung 3 32-Bit ActiveX-Steuerelemente schlagen in 64-Bit Internet Explorer fehl
Abbildung 3 32-Bit ActiveX-Steuerelemente schlagen in 64-Bit Internet Explorer fehl

Windows x64 bei Pluck
Ich habe am Anfang dieses Artikels angemerkt, dass wir bei Pluck mit dem Übergang zu Windows x64 begonnen haben. Drei verschiedene Versionen von Windows wurden migriert: Windows XP Professional x64 Edition, Windows Server 2003 Enterprise Edition x64 und Windows Vista x64.
Das Unternehmen ist so klein, dass wir zu Beginn der Entwicklung unseres neuesten Produkts mit der Migration zu Windows für x64 beginnen konnten, um dessen Vorteile zu nutzen. Dazu musste die von uns bestellte neue Hardware natürlich x64-fähig sein. Tatsächlich ermöglichen uns die erweiterten Speicherfunktionen von x64 gemeinsam mit der Virtualisierung eine Ausführung unserer Produkte, bei der alle physischen Server als 64-Bit-Server auf einem 64-Bit-Hostserver ausgeführt werden. Für jeden Hostserver sind 16 GB Arbeitsspeicher auf die darauf gehosteten virtuellen Server aufgeteilt (normalerweise 2 GB für jeden virtuellen Bereitstellungscomputer oder VM und 3 GB für jeden Produktions-VM).
Durch Einsatz von Tier 1-Systemen und virtualisierter Hardware erreichen wir nahezu 100 Prozent Geräteunterstützung. Mein Laptop verfügt beispielsweise über drei Geräte, für die keine x64-Treiber zur Verfügung stehen. Dabei handelt es sich zumeist um weniger wichtige Geräte der Rückwandplatine, und das System kommt gut ohne ihr Vorhandensein aus. Interessanterweise führte eine Installation von Windows Vista RC1 x64 zu genau derselben Geräteunterstützung. Da mein System jedoch das Windows Vista Capable-Logo trägt, werden diese fehlenden Treiber hoffentlich bald vom Anbieter geliefert.
Da unsere Verwendung des Systems hauptsächlich auf Microsoft Office, Visual Studio® und einige weitere Tools für unseren Entwicklungs- und Buildprozess beschränkt ist, verfügen wir nicht über viele Legacyanwendungen, die zu Kompatibilitätsproblemen in unserer Migration führen könnten. Ein beträchtlicher Teil unseres Unternehmens verwendet zwar noch 32-Bit-Versionen von Windows, aber für neue Hardware haben wir mit der Migration zu 64-Bit begonnen. Bisher war dies relativ problemlos.

Bereitstellung und Migration von x64
Es müssen einige Überlegungen hinsichtlich der Bereitstellung angestellt werden. Microsoft bietet eine Version der Windows-Vorinstallationsumgebung (Windows PE) speziell für die x64-Architektur. Da jedoch eine x86-Parität für x64-Systeme vorhanden ist, möchten Sie möglicherweise x86 Windows PE für die Bereitstellung verwenden, insbesondere, wenn Sie eine Imaging-Lösung einsetzen. Wenn Sie Windows XP mithilfe einer unbeaufsichtigten Installation bereitstellen, muss Windows PE architekturspezifisch sein, da winnt32.exe unter derselben Architektur ausgeführt werden muss, die es bereitstellt. Da bei Windows PE keine 32-Bit-Kompatibilitätsschicht vorliegt und winnt32.exe unter x64 eine 64-Bit-Anwendung ist, erfordert 32-Bit-Windows eine 32-Bit Windows PE. Das gleiche gilt für 64-Bit-Versionen von Windows, die eine 64-Bit Windows PE erfordern.
Remoteinstallationsdienste (RIS) arbeiten in diesem Zusammenhang anders, daher verwendet Pluck RIS. Ab Windows Server 2003 SP1 kann RIS x64- sowie x86- oder Itanium-Architekturen von Windows bereitstellen. Wenn ein x64-System eine Verbindung zu einem RIS-Server herstellt, bietet der Server (in der Standardkonfiguration) x86 und x64 RISetup- oder RIPrep-Bilder. RIS kann auch so konfiguriert werden, dass x64-Clients ausschließlich x86-Bilder oder ausschließlich x64-Bilder erhalten. Die Auswahl wurde standardmäßig angeboten, um die beste Funktion mit der x64 Hardware zu bieten.
Beachten Sie, dass ich bisher noch nicht über die Aktualisierung gesprochen habe. Dies aus gutem Grund. Leider ist der Prozess einer Aktualisierung eines gesamten Betriebssystems von x86 zu x64 mit enorm viel Arbeit verbunden. Aus diesem Grund, und hinsichtlich der eingeschränkten Bereitstellung von Windows XP Pro x64 Edition, können sie nicht von einer beliebigen x86-Version auf Windows XP aktualisieren, noch können Sie von einer beliebigen Windows XP-Version (x86 oder x64) auf Windows Vista x64 aktualisieren. Windows Vista auf x64-Systemen ist ebenso wie Windows XP Pro x64 Edition ein komplett neues Installationsprodukt. Aus diesem Grund ziehen viele Unternehmen die Migration zu x64 nur dann in Betracht, wenn eine Hardwareaktualisierung ansteht. Es wird erwartet, dass zahlreiche Unternehmen für Windows Vista selbst eine ähnliche Strategie verfolgen (eine Doppelaktualisierung zur gleichen Zeit scheint logisch).
Dies bedeutet jedoch in keinster Weise, dass Personen oder Unternehmen, die von x86 Windows zu x64 Windows übergehen, keine Tools zur Verfügung stehen. Versionen des User State Migration Tool (USMT) für Windows XP und für Windows Vista wurden erweitert, um die Migration von einer Installation von Windows zur nächsten zu unterstützen (gegenüber einer integrierten Aktualisierung des Betriebssystems). Diese Methode (deinstallieren und auf demselben PC neu laden) wird heutzutage von den meisten Unternehmen für die Bereitstellung von Windows in allen Situationen verwendet. Der Einsatz derselben Methode für den Wechsel zu Windows auf einer komplett neuen Architektur dürfte daher kein größeres Hindernis darstellen.

Schlussbemerkung
Obwohl die schrittweise Migration in unserem kleinen Unternehmen zu x64 erheblich einfacher sein mag als der umfangreiche Migrationsprozess, dem sich größere Unternehmen gegenüber sehen, muss jeder IT-Experte den Wechsel zur x64-Architektur früher oder später berücksichtigen. Die x86-Architektur und systemeigenene x86-Versionen von Windows werden zwar auch noch im nächsten Jahrzehnt zur Verfügung stehen werden, aber die Zukunft des Computereinsatzes in Unternehmen liegt in der x64-Architektur. Angesichts des vollständigen Wechsels von Microsoft zu x64-Funktionen mit Exchange Server und anderen Produkten sollten Sie darüber nachdenken, wo in Ihrer Architektur x64-Systeme zunächst eingesetzt werden könnten, und wo sie in Ihrem Windows Vista-Migrationsplan sinnvoll sind. Dabei spielt es keine Rolle, ob Sie Windows XP oder Windows Server 2003 zurzeit systemeigen auf einem x64-System einsetzen.

Wes Miller ist Entwicklungsmanager bei Pluck (www.pluck.com) in Austin, Texas. Davor arbeitete er bei Winternals Software und bei Microsoft als Programm-Manager und Produktmanager für Windows. Sie können ihn unter technet@getwired.com erreichen.


 Inside Microsoft.com: Verwenden von Active Directory Federation Services
Inside Microsoft.com
Verwenden von Active Directory Federation Services
Jim Guthrie

Microsoft bietet ein Extranet, damit Geschäftspartner Zugriff auf wichtige interne Ressourcen erhalten. Die Architektur des Extranet erfordert, dass jeder Teilnehmer außerhalb des Unternehmens über ein einmaliges Domänenkonto für diesen Bereich verfügt. Dieses Konto wird nicht von den Partnern selbst, sondern von Microsoft-Mitarbeitern erstellt und verwaltet.
Die Gründe dafür liegen auf der Hand. Dies ist zwar praktisch, aber u. U. nicht sonderlich benutzerfreundlich. Außerdem ist die Verwaltung all dieser Partnerkonten für Microsoft ziemlich ressourcenintensiv.
So funktioniert das aktuelle Extranet: Wenn ein Kunde oder Partner sich für eine Sitzung anmeldet, muss er seine Anmeldeinformationen angeben. Wenn ein Benutzer während derselben Sitzung entscheidet, auf eine andere Ressource zuzugreifen, wird er erneut nach seinen Anmeldeinformationen gefragt. Dies setzt sich beim Wechsel von einer Ressource zur nächsten fort. Wenn der Benutzer sich bei einer einzelnen Anwendung anmeldet, die mehrere Ressourcen verwendet, z. B. eine Buchhaltungsdatenbank, muss er sich für jede Ressource gesondert authentifizieren. Für den Benutzer ist dies mühsam und lästig.
Glücklicherweise kann das Problem mehrfacher Authentifizierungen mithilfe der Active Directory® Federation Services (ADFS) relativ einfach gelöst werden. ADFS ist eine Windows Server® 2003 R2-Komponente, die Vertrauen zwischen zwei oder mehr Unternehmen schafft, um die gemeinsame Verwendung mehrerer Ressourcen zu ermöglichen. Dabei verwaltet jedes Unternehmen weiterhin seinen eigenen Satz an Benutzern. Dieser Artikel soll veranschaulichen, wie Microsoft in Zukunft ADFS zur Lösung des Problems mehrerer Ressourcen im Extranet einsetzt. Gleichzeitig erhalten Sie die für die Implementierung einer ähnlichen Lösung notwendigen Informationen. Bevor ich jedoch ins Detail gehe, sollten Sie sich mithilfe von Abbildung 1 mit der grundlegenden ADFS-Terminologie vertraut machen.
Figure 1 ADFS-Terminologie (Close Figure 1)

Begriff | Definition
Verbund | Ein Bereichs- oder Domänenpaar, das im Verbund Active Directory-Vertrauensrichtlinien eingerichtet hat.
Federation Service Resource (FS-R | )Leitet eingehende Authentifizierungsanforderungen an die FS-A und gewünschte Ressourcen weiter.
Federation Service Accounts (FS-A) | Bietet einen zu authentifizierenden Kontotoken auf der FS-R.
Federation Service Proxy (FS-P) | Stellt eine Trennungsschicht zwischen den FS-Servern und eingehendem Internetdatenverkehr zur Verfügung.
Anspruch | Eine von einem Server gegebene Anweisung (beispielsweise Name, Identität, Schlüssel, Gruppe, Berechtigung oder Funktion) zu einem Client.
Bereichserkennung | Jedes FS-A verfügt über eine Domäne oder einen Bereich, in dem die Anmeldeinformationen gespeichert sind. Über die Bereichserkennung wird bestimmt, welches FS-A für die ADFS-Sitzung verwendet wird.

Eine Lösung mit ADFS
Wenn ein Benutzer auf eine ADFS-fähige Anwendung zugreift, wird der Browser zur Bereichserkennung an Federation Service Resource (FS-R) geleitet. Hier wählt der Benutzer aus, welcher Satz Anmeldeinformationen für die Dauer der Sitzung verwendet werden soll. Basierend auf dem vom Kunden gewählten Bereich erfolgt eine Weiterleitung zum Federation Service Accounts (FS-A)-Server. Auf diesem Server wird ein gültiger Token (in Form eines Cookies) für das Konto ausgegeben, und zwar auf Grundlage der Anmeldeinformationen, die der Benutzer in Form einer Windows Live™ ID (zuvor ein Passport-Konto), einer Windows-integrierten Authentifizierung oder einer SSL-Authentifizierung eingegeben hat (siehe Abbildung 2). In diesem Modell müssen die einzelnen Unternehmen ihren eigenen Kontenverbundserver verwalten. Im Fall der Microsoft-Partnerserver ist Microsoft.com somit von der Aufgabe befreit, jedes Konto in der Umgebung zu verwalten. Wenn Sie diesen Grad an Verantwortung implementieren, müssen Sie die Verbundpartner natürlich sorgfältig aussuchen und sicherstellen, dass diese alle Kontoinformationen aktiv verwalten.
Abbildung 2 ADFS-Fluss
Abbildung 2 ADFS-Fluss
Der nächste Stopp auf der Route ist wieder der FS-R-Server, wo der Kontotoken gegen einen Ressourcentoken ausgetauscht wird. In unserer Konfiguration enthält dieser Token eine vollständige Liste der Berechtigungen, die dem Benutzer über einen auf dem FS-R durchgeführten Anspruchszuordnungsprozess gewährt wurden. Nach Empfang des Tokens erhält der Benutzer die einmalige Anmeldefunktion (SSO) auf ADFS-fähigen Anwendungen für die Dauer der Sitzung oder standardmäßig bis zu 24 Stunden (dieses Fenster ist konfigurierbar). Auf diese Weise aktivieren Sie SSO für diese ADFS-fähigen Anwendungen, was Benutzerfreundlichkeit und Sicherheit erhöht. Eine vollständige Beschreibung des ADFS-Authentifizierungsprozesses finden Sie in Matt Steeles Artikel der Juliausgabe 2006 des TechNet Magazins mit dem Titel Einfacheres einmaliges Anmelden mittels ADFS.
Um die Sicherheit von Microsoft-Unternehmensressourcen zu gewährleisten, haben wir den über das Internet bereitgestellten Bereich des Extranets von der Unternehmensseite getrennt, was bedeutet, dass jeder Server potenziell doppelt verwaltet wird. Wir gewähren internen Unternehmensbenutzern eine unidirektionale Vertrauensstellung und bieten über unsere Server den notwendigen Schutz. Außerdem verfügen wir über eine separate Domäne für den Extranetbereich, in dem wir externen Benutzern Zugriff auf die erforderlichen Ressourcen bieten.
Zwei wichtige Bereiche, die es während der Implementierung zu berücksichtigen galt, waren der Lastenausgleich und die ADFS-Richtliniendateiänderungen. Der Lastenausgleich war eine Herausforderung sowohl auf globaler als auch auf lokaler Ebene. Zunächst wird in der Produktion für zwei Bereiche der Front-End-Webservercluster der globale Lastenausgleich von unseren Content Delivery Network (CDN)-Partnern Akamai oder Savvis verwendet. Dies stellt die Verfügbarkeit des Systems für Endbenutzer selbst für den unwahrscheinlichen Fall sicher, dass ein regionales Serverpaar offline geht. Erreicht wird dies über Failover-Automatisierung basierend auf Server-Systemdiagnosediensten des CDN. Weiterhin können wir in Zukunft auf einfache Weise mehr Cluster hinzufügen. Aus Kostengründen haben sich unsere Präproduktions-Bereitstellungsteams gegen eine Verwendung des CDN-Diensts entschieden.
Auf regionaler Ebene haben wir die Server für lokales Failover über Netzwerklastenausgleich (NLB)-Clustering paarweise zusammengestellt. Dabei werden keine besonderen Lastenausgleichsfunktionen eingesetzt, also hätte dies ebenso gut mit Hardware erreicht werden können. Zur Kostenersparnis wird jedoch wiederum NLB verwendet. Diese Konfiguration bietet die Stabilität, um eine Betriebszeit von mehr als 99,9 Prozent in allen unterstützten Umgebungen sicherzustellen.
Als weitere Herausforderung musste sichergestellt werden, dass die ADFS-Richtliniendatei, das Rückgrat von ADFS, korrekt über die Umgebung hinweg verteilt war und dass Änderungen daran ebenso repliziert wurden. Zu diesem Zweck wurde eine weitere integrierte Funktion von Windows Server 2003 R2 eingesetzt, nämlich die Verteilte Dateisystemreplikation (Distributed File System Replication, DFS-R), ein neues statusbasiertes Multimasterreplikationsmodul. Auf jedem der Back-End-Server wurde eine DFS-R-Gruppenmitgliedschaft mit einer vollständigen 24-Stunden-Replikation aktiviert. Eine Änderung an der Richtliniendatei wird nun an alle Server verteilt, unhängig davon, wo sie vorgenommen wird. Solange überwacht wird, wer die Datei ändern kann, liegt jetzt ein stabiler, hochgradig verfügbarer Dienst vor.
Alle Änderungen sollten über das ADFS-Snap-In vorgenommen werden. In der Praxis haben wir jedoch festgestellt, dass diese Datei gelegentlich manuell aktualisiert werden muss. Bei der manuellen Aktualisierung muss beachtet werden, dass ADFS die Version dieser Datei nachverfolgt. Daher müssen Sie der Datei eine erhöhte Priorität zuweisen, sodass die Änderungen in der Umgebung berücksichtigt werden:
<TrustPolicyEntryUri>urn:federation:parttestint</TrustPolicyEntryUri>
<TrustPolicyVersion>127
</TrustPolicyVersion>
Außerdem muss beachtet werden, dass die Richtlinien-XML-Datei (wie alle XMLs) zwischen Groß- und Kleinschreibung unterscheidet. In der Richtlinien-XML-Datei gibt es zahlreiche Verweise auf Anwendungen oder sonstige ADFS-Server, und diese müssen alle genau von Server zu Server kopiert werden. Bei den folgenden allgemeinen Beispielen wurde das erste, RevocationCheckFlags, manuell eingegeben. Das zweite ist eine vertrauenswürdige, aus der Benutzeroberfläche geänderte Anwendungs-URL:
<RevocationCheckFlags>None
</RevocationCheckFlags>
<TrustPolicyEntryUri>https://adfstest.parttest.extranettest.microsoft.com/NTApp/
</TrustPolicyEntryUri>
Zur zusätzlichen Sicherheit wird eine weitere Komponente von ADFS, der Verbunddienstproxy (Federation Service Proxy, FS-P) eingesetzt, der sicherstellt, dass die FS-Rs eine Ebene vom direkten Zugriff eingehender Internetanforderungen entfernt bleiben. Eine einmalige Methode, mit der Proxys bei Microsoft.com bereitgestellt wurden, ist die Verwendung eines einzelnen Satzes von Proxys zum Hosten mehrerer ADFS-Umgebungen im Präproduktionsbereich. Interessanterweise haben wir während der anfänglichen Technologieauswahl festgestellt, dass hierfür eine einfache Registrierungsschlüsseländerung durchgeführt werden musste. Der Schlüssel befindet sich unter HKLM\Software\Microsoft\WebSSO. Eine einfache Änderung des Werts des anfänglichen Verzeichnisses in diesem Schlüssel ermöglicht die Verwendung des Proxys für mehrere Umgebungen. Der Standard war:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttestint”
Zum Wechseln von Umgebungen änderte sich der Schlüssel folgendermaßen:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttest”
Die Erstellung einer Batchdatei kann die Verwaltung dieses Prozesses vereinfachen. Leider unterstützt die aktuelle Version des MMC-Snap-In für ADFS nicht das Umschalten zwischen Umgebungen, da eine Eins-zu-Eins-Beziehung zwischen dem Proxy und der Ressource oder dem Kontoserver vorhanden ist. Dies ist die einzige Möglichkeit, die Verwendung der Proxyserver zu maximieren. Das Endergebnis ist eine erhebliche Kosteneinsparung, da die Anzahl erforderlicher physischer Server eingeschränkt wird, und zwar unabhängig davon, wie viele unterschiedliche Umgebungen gehostet werden sollen.
Im Hinblick auf die Architektur wird die Präproduktionsumgebung mit virtuellen Computern ausgeführt, eine weitere Kostenersparnis. Es besteht also keine Notwendigkeit mehr, sechs zusätzliche Server zu erwerben und zu unterhalten. Bis heute waren dabei keinerlei Leistungsprobleme zu verzeichnen. Um jedoch der erheblich höheren Nachfrage in einer Produktionsumgebung gerecht zu werden, haben wir uns entschlossen, leistungsstärkere physische Computer einzusetzen.

Nicht nur für Active Directory
Microsoft.com verwendet nicht nur Active Directory-Konten für die Authentifizierung, sondern hat auch Windows Live ID-Konten erfolgreich integriert. Durch den Einsatz von Windows Live ID (WLID) 4.5 wurde offensichtlich, dass das Windows Live ID-Konto eines Benutzers für eine Zugriffsdelegation auf Microsoft-Ressourcen verwendet werden kann. Dies erfolgt mithilfe einer benutzerdefinierten Anspruchstransformation. So wird die SSO-Authentifizierung entscheidend vereinfacht, da kein Domänenkonto mehr erforderlich ist.

Weitere Herausforderungen
Die derzeit größte Herausforderung für Microsoft ist die Verwaltung von ADFS für die gemeinsame Nutzung von Tokensignaturzertifikaten. Wir verwenden Standardzertifikate, die normalerweise ein Jahr gültig sind und dann erneuert werden müssen. Zum Zeitpunkt der Erneuerung müssen die jeweiligen Server entsprechend aktualisiert werden, was sich erheblich auf die FS-Rs auswirkt. Eine begrenzte Verwaltung mit 15 oder 20 Verbundpartnern liegt zwar im Rahmen des Möglichen, aber Microsoft hat potenziell Hunderte, wenn nicht Tausende von Partnern. Für die Verwaltung von SSL-Zertifikaten für eine einzelne Umgebung müsste also Vollzeitpersonal abgestellt werden. Zurzeit beschäftigen sich mehrere Teams mit den besten Methoden zur Automatisierung dieser Lösung. Wir haben uns jedoch noch nicht für eine bestimmte Vorgehensweise entschieden.
Eine weitere Herausforderung ist, dass nicht alle Anwendungen automatisch ADFS-fähig sind. Um ADFS richtig zu nutzen, werden daher Programmierarbeiten für die Sites erforderlich sein. Wir arbeiten eng mit dem Microsoft® Office SharePoint® Services-Team zusammen, damit die nächste Generation von SharePoint eine Implementierung für ADFS unterstützt.

Schlussbemerkung
Es gibt eine Reihe von Faktoren, die bei einer Entscheidung für ein ADFS-Modell berücksichtigt werden müssen. Ein Faktor dabei ist die Anzahl der Ressourcen, auf die Kunden zugreifen werden. Das Aufstellen, Überprüfen und Ausführen akzeptabler Vertrauensrichtlinien innerhalb eines Unternehmensverbunds kann eine banale Aufgabe sein, nimmt jedoch Zeit und Energie in Anspruch. Wenn Ihre Kunden also nur auf eine Ressource zugreifen, lohnt sich der Aufwand u. U. nicht. Mit steigender Anzahl von Ressourcen erhöhen sich jedoch die Vorteile.
Weitere Informationen finden Sie in der ADFS-Übersicht und unter Active Directory Federation Services: Möglichkeiten für Verbundidentität und Zugriffsverwaltung.

Jim Guthriearbeitet im Microsoft.com Operations-Team. Zusätzlich zu seiner Arbeit für ADFS ist er Systems Engineer beim Enterprise Portal Platform Support-Team.


 Berichte aus der Praxis: Freud und Leid des Lernens
Berichte aus der Praxis
Freud und Leid des Lernens
Mark D. Scott

Ich kann mich noch erinnern, wie es mir ging, wenn etwas Neues herauskam: es reizte mich, die neueste Technik vor den meisten anderen Leuten in die Hand zu bekommen, und ich untersuchte das Produkt intensiv, um genau zu lernen, wie es funktionierte. Ich entwickelte mich zu einem Erstanwender, dem einzig Eingeweihten, einem Zauberer, der anderen geheimes Wissen vermitteln konnte.
Aber irgendwie nahm im Laufe der Zeit die Freude daran ab. Ich weiß selbst nicht genau, wie es dazu kam. Vielleicht nahm die Frustration, wichtige Anwendungen um 3 Uhr morgens zum Laufen zu bringen, ja überhand. Vielleicht habe ich meinen Enthusiasmus zusammen mit einer falsch verstandenen Produktdokumentation auf dem Boden liegen lassen, als sich der Mailserver des Unternehmens verabschiedete (das war damals, als noch ein Server ausreichte). Vielleicht bin ich auch einfach nur alt und zynisch geworden. Was soll's. Es ist einfach nicht mehr so aufregend wie noch vor zehn Jahren, bis spät in die Nacht zu arbeiten. Aber das bedeutet nicht, dass man aufhören sollte zu lernen. Diese Erfahrung hat sich mir vor kurzem erneut bestätigt.
Ich habe kürzlich auf Microsoft® Outlook® 2007 aktualisiert und finde das Programm erstklassig. Aber ich bin auch Abonnent von MSN® Premium. Das Abonnement gehört bei meinem ISP zum Dienst dazu. Bei der bisherigen Version von Outlook brauchte ich eine besondere Softwarekomponente, Konnektor genannt, um auf meine MSN-E-Mail-Adresse zuzugreifen. Dieser Softwarekonnektor lief nicht mit Outlook 2007, weshalb ich mich an MSN wandte. MSN verwies mich an meinen ISP, der mir schließlich sagte, dass er den MSN-Outlook-Konnektor auf Outlook 2007 nicht unterstützt. Der Austausch per E-Mail, Chat und Telefon nahm eine halbe Ewigkeit in Anspruch.
Dann kam mir plötzlich der Gedanke, dass ich vielleicht gar keinen Konnektor mehr brauchte. Ich startete Outlook 2007 und konfigurierte eine neue Verbindung zu MSN, ohne die Konnektorsoftware zu verwenden. Outlook ging ins Internet, fand den Server und konfigurierte das Konto problemlos. Für mehrere andere meiner POP3-Konten funktionierte es genauso. So erhielt ich Zugriff auf meine E-Mails und lernte eine wichtige neue Eigenschaft des Produkts kennen.
Und die Moral von der Geschichte: Wenn sich beim Support irgendjemand die Mühe gemacht hätte, mit dem neuen Produkt zu spielen, hätte er mir höchstwahrscheinlich sagen können, dass ich den Konnektor gar nicht brauchte, und das hätte uns beiden viel Zeit gespart.
Oder genauer: Wenn ich selbst mit dem Produkt herumexperimentiert hätte, hätte ich die Lösung wahrscheinlich selbst gefunden. Aber stattdessen erwartete ich, dass mir einfach jemand anders die richtige Antwort gab. Da sich aber niemand die Zeit genommen hatte, diesen kleinen, aber wichtigen Punkt näher zu beleuchten, ging so mehr Zeit verloren, als wenn sich jeder von uns einfach mit der Materie beschäftigt und das Problem selbst gelöst hätte – also genau das, was ich am Ende ohnehin tat.
Unsere Annahmen werden oft durch technische Änderungen zunichte gemacht. Um als IT-Fachleute zu arbeiten, müssen wir uns daher von Vorurteilen befreien. Das Wissen, um das wir uns so quälen, wird unvermeidlich durch neue Technologie ersetzt, denn die neue Technologie ist gerade deshalb leichter anzuwenden, weil sie unser Wissen ersetzt. Spezialwissen auf einem Gebiet bleibt uns eben nicht für immer als Wettbewerbsvorteil erhalten. Wirklich wichtig ist es, sich nicht auf bereits erworbenes Wissen über womöglich veraltete Technologien zu verlassen, sondern beständig neue Konzepte und Verfahren zu erlernen. Dies erzielen wir durch fortlaufenden Wissenserwerb in unserem alltäglichen Leben. Angesichts des großen Angebots an neuen Produkten, die ständig auf dem Markt erscheinen, muss Lernen zu unserem Alltag gehören.
Sollten Sie mich also erreichen wollen, schicken Sie mir einfach eine E-Mail, entweder an mein Microsoft-Konto oder an mein MSN-Konto: In Outlook 2007 kann ich Mails von beiden abrufen.

Mark D. Scott ist als Senior Consultant für Microsoft Consulting Services tätig. Er arbeitet eng mit Kunden zusammen, um sie bei Entwicklung und Erstellung umfangreicher datenorientierter Anwendungen zu unterstützen. Mark D. Scott ist unter granddaddy2002@msn.com oder mascott@microsoft.com


 Windows Confidential: Die Kraft des Fehlers
Windows Confidential
Die Kraft des Fehlers
Raymond Chens

Bei Windows 95 könnten Sie beispielsweise auf der Seite „Problembehandlung“ die Option „Synchrone Pufferzuweisungen deaktivieren“ auswählen. Aber wissen Sie, was dieses Kontrollkästchen bewirkte? Oder warum es überhaupt vorhanden war?
Die Funktion „Commit“ in MS-DOS® leerte normalerweise alle Datenpuffer mit nicht geschriebenen Daten für eine bestimmte Datei, schrieb diese Daten auf den Datenträger und wartete dann eine Bestätigung ab, dass alle Daten geschrieben waren. Erst dann kehrte die Funktion zurück. Wenn Sie die Option „Synchrone Pufferzuweisungen deaktivieren“ auswählen, würde der Aufruf sofort zurückkehren, anstatt das Schreiben der Daten abzuwarten. Dies verstieß natürlich gegen die Funktionsbeschreibung, nach der der Aufruf erst dann zurückkehren sollte, wenn die Daten geschrieben wurden. Damit stieg das Risiko so genannter „Dateiintegritätsprobleme“, wie diese Probleme leicht beschönigend im Knowledge Base-Artikel 139669 bezeichnet wurden: Das Programm, das das Leeren der Datenpuffer veranlasste, erhielt die Rückmeldung, dass die Daten sicher auf den Datenträger geschrieben waren, obwohl dies nicht der Fall war.
Ein Datenbankprogramm kann mit der Funktion „Commit“ bestimmte Punkte festlegen, an denen der Status der Datei auf dem Datenträger mit den erwarteten Daten auf dem Datenträger übereinstimmt. Bei einem Stromausfall des Computers während einer Aktualisierung ist das Datenbankprogramm anhand der am letzten Commit-Punkt aufgezeichneten Informationen in der Lage, die Integrität der Datenbank wiederherzustellen. Wenn die Funktion „Commit“ sofort zurückgekehrt wäre, ohne dass die Zuweisung abgeschlossen war, wäre dieser Integritätsprüfpunkt verloren gegangen. Und damit war die Datenbank beschädigt.
Warum stand diese Option überhaupt zur Verfügung, wenn so schlimme Folgen zu erwarten waren? Der Grund: ein Fehler in Windows® 3.11.
Abbildung 1 Ursache für fehlerhaftes Verhalten in Windows Server 2003
Abbildung 1 Ursache für fehlerhaftes Verhalten in Windows Server 2003
Mit Windows 3.11 wurde der „32-Bit-Dateizugriff“eingeführt, eine 32-Bit-Implementierung der detaillierten Datei-E/A-Schnittstelle. Die Implementierung der Funktion „Commit“ enthielt jedoch einen Fehler, mit dem Anforderungen zum Leeren der Dateipuffer schlichtweg ignoriert wurden. Wenn Sie ein Programm unter Windows 3.11 ausführten, bei dem die Dateipuffer geleert wurden, blieb dieser Aufruf zum Leeren wirkungslos. Und wenn der besagte Stromausfall genau zu einem ungünstigen Zeitpunkt auftrat, war die Datenbank stark beschädigt.
Bei der Programmierung des Dateisystems in Windows 95 wurde dieser Fehler behoben, aber es gingen trotzdem immer neue Fehlerberichte ein. Das Buchhaltungsprogramm eines Benutzers beispielsweise arbeitete plötzlich extrem langsam. Das Datenbankprogramm eines anderen Benutzers verhielt sich dann genauso. Was ging da vor?
Es stellte sich heraus, dass diese Programme ständig Aufrufe zum Leeren der Puffer ausgaben. Die Programmierer bemerkten, dass die Aufrufe zum Leeren unter Windows 3.11 sehr schnell erledigt wurden, und verteilten diese Aufrufe darum großzügig im gesamten Betriebssystem. Ein Byte schreiben, Puffer leeren. Eine Zeichenfolge schreiben, Puffer leeren. Die Leervorgänge liefen so schnell ab, dass die Anwendung die Daten nach jedem Vorgang auf den Datenträger übertragen konnte, ohne dass nennenswerte Leistungseinbußen zu verzeichnen waren. Mit der Behebung des Fehlers in Windows 95 wurden diese Programme jedoch sehr langsam, weil diese Aufrufe plötzlich richtig arbeiten mussten.
Hätten die Programmierer des Dateisystems nicht eingegriffen, dann wären diese Programme weiter langsam ausgeführt worden, und die Benutzer wären zum Schluss gekommen, dass Windows 95 das Problem war. „Windows 95 läuft im Schneckentempo“, hätte es geheißen. Wenn dagegen das bisherige Verhalten aus Windows 3.11 wiederhergestellt würde, würde der Fehler wieder eingeführt, der zu diesen lästigen „Dateiintegritätsproblemen“ führen kann.
Das Team kam zum Schluss, dass der Fehler nicht wieder aufleben sollte. Stattdessen wurde ein Kontrollkästchen eingeführt (wenn auch tief auf der Seite „Problembehandlung“ vergraben), mit dem alle Benutzer zum Verhalten aus Windows 3.11 zurückkehren konnten, bei denen aufgrund des Fehlers Probleme mit den Programmen aufgetreten waren.
Später wiederholte sich die ganze Geschichte. In Windows Server® 2003 fand das E/A-Team einen Fehler, bei dem alle Anforderungen, die als FUA (Forced Unit Access) gekennzeichnet sind, das FUA-Tag verlieren und stattdessen als normale E/A-Vorgänge durchgeführt werden. Die Neuauflage für das Ignorieren der Leerungsanforderungen! Das Team hat den Fehler behoben und eine Option bereitgestellt, mit der die Benutzer das bisherige, fehlerhafte Verhalten wiederherstellen können. In Windows Server 2003 trägt dieses Kontrollkästchen die Bezeichnung „Erhöhte Leistung aktivieren“, doch wie Sie nun wissen, bedeutet dies tatsächlich nur „Rückkehr zum bisherigen, fehlerhaften Verhalten“.

Raymond ChensWebsite, The Old New Thing, und sein gleichnamiges Buch (Addison-Wesley, 2007) beschäftigen sich mit der Windows-Geschichte und der Win32-Programmierung. Lieber nicht den Ast absägen, auf dem man sitzt.