 TechNet Magazine February 2007
TechNet Magazine February 2007
FEBRUARY 2007
Windows-Verwaltung

In diesem Monat beschäftigt sich Mark Russinovich mit dem Windows Vista-Kernel, um die neuen Algorithmen zur Messung der Leistung von Threads und Prozessen zu erklären, durch die Sie einen genaueren Überblick darüber erhalten, wofür Ihre CPU-Zeit aufgewendet wird. Er geht zudem auf den Multimediaklassen-Planungsdienst ein, der Benutzern durch die bessere Verwaltung von Hintergrundtasks wie Virenprüfung und Inhaltsindizierung eine nahtlosere Wiedergabeerfahrung ermöglicht.

In diesem Monat befassen wir uns darüber hinaus mit den Delegierungsfunktionen in Active Directory und mit Gruppenrichtlinienvorlagen in Windows Vista, damit Sie das Potenzial von Gruppenrichtlinien besser als je zuvor ausschöpfen können. Natürlich finden Sie in diesem Monat auch alle regulären Rubriken im Magazin, einschließlich „The Cable Guy“, „Die Scripting Guys“ und „Windows Confidential“.
FUNKTIONEN
Windows-Verwaltung Einblick in den Windows Vista-Kernel: Teil 1

Bei Windows Vista bringen Änderungen am Betriebssystemkernel Fortschritte in vielen Bereichen mit sich, von der Speicherverwaltung über die Zuverlässigkeit bis hin zur Sicherheit. Wir beginnen diese Reihe mit einer Betrachtung der Verbesserungen, die der Kernel im Bereich der Prozesse, Threads und E/A-Vorgänge bietet.

Mark Russinovich Delegieren von Befugnissen in Active Directory

Durch das Implementieren einer Delegierung in Active Directory können die Sicherheit erhöht und die Verwaltung von Aufgaben vereinfacht werden. Außerdem sind die ersten Schritte einfacher als Sie denken. In diesem Artikel werden einige einfache Delegierungsmodelle erläutert, die (mit geringfügigen Änderungen) in den meisten IT-Infrastrukturen funktionieren.

Joel Yoker und Rob Campbell Neue Gruppenrichtlinienvorlagen in Windows Vista

Durch Windows Vista werden erhebliche Änderungen an Gruppenrichtlinienvorlagen eingeführt. Hier erfahren Sie alles über das neue Format ADMX und darüber, wie diese Änderungen die Verwaltung der Systemkonfigurationen verbessern.

Darren Mar-Elia Ihre Anleitung zur Problembehandlung von Gruppenrichtlinien

Das Lösen von Problemen im Zusammenhang mit Gruppenrichtlinien kann ein schwieriger Prozess sein. Wenn Sie jedoch verstehen, wie Gruppenrichtlinien funktionieren und wo Probleme auftreten können, wird dieses Verfahren vereinfacht. Diese Übersicht soll Ihnen helfen, Gruppenrichtlinienprobleme im Handumdrehen zu beheben.

Derek Melber Überwachen von Active Directory mittels MOM

Management Packs für Microsoft Operations Manager 2005 ermöglichen Ihnen ein effektiveres Überwachen der IT-Infrastruktur. In diesem Artikel erfahren Sie, wie Ihnen diese fünf Management Packs helfen können, um Zustand, Sicherheit und Zuverlässigkeit Ihrer Active Directory-Umgebung immer im Auge zu behalten.

John Hann Spielen in einer sicheren Umgebung

Unabhängig davon, ob Sie im Büro sind oder sich zu Hause die Zeit mit Computerspielen vertreiben, bietet die Ausführung mit eingeschränkten Rechten viele Sicherheitsvorteile. Leider funktionieren einige Spiele nicht, wenn sie nicht mit Administratorrechten ausgeführt werden. Im Folgenden werden einige häufig auftretende Probleme und ihre Lösung beschrieben.

Matt Clapham
SPALTEN
Mitteilung der Redaktion

Aus dem Nähkästchen

Joshua Trupin Toolbox

Neue Produkte für IT-Profis

Greg Steen SQL – Fragen und Antworten

Datenbankgröße, Spiegelung, markierte Transaktionen und mehr

Herausgegeben von Nancy Michell Schwerpunkt Dienstprogramme

Group Policy Inventory

Greg Steen The Cable Guy

QoS-Support in Windows

Joseph Davies 		Windows PowerShell

Zeilenweise Skripterstellung

Don Jones Hey, Scripting Guy!

Autos nachjagen ... und XML

Die Scripting Guys von Microsoft Sicherheit auf dem Prüfstand

Bereitstellen von EFS: Teil 1

John Morello Die Desktopdateien

Erweitern von Windows PE

Wes Miller Berichte aus der Praxis

Die Verbindung wird einfach unterbrochen

R'ykandar Korra'ti Windows Confidential

Ein zweischneidiges Schwert

Raymond Chen


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

Einblick in den Windows Vista-Kernel: Teil 1
Kurz zusammengefasst:
  • Threadpriorität und -planung
  • Dateibasierte symbolische Verknüpfungen
  • Abbrechen von E/A-Vorgängen

Dies ist der erste Teil einer Reihe, die sich mit den Neuerungen im Windows Vista-Kernel beschäftigt. In dieser Ausgabe gehe ich auf Änderungen im Bereich der Prozesse, Threads und E/A-Vorgänge ein. In zukünftigen Ausgaben werden die Themen Speicherverwaltung, Starten und Herunterfahren, Zuverlässigkeit und Wiederherstellung sowie Sicherheit behandelt.
Im Blickpunkt dieses Artikels stehen ausschließlich Änderungen am Windows Vista™-Kernel, insbesondere Ntoskrnl.exe und den damit eng in Verbindung stehenden Komponenten. Es sollte jedoch nicht vergessen werden, dass es in Windows Vista viele andere wichtige Änderungen gibt, die nicht in den Bereich des eigentlichen Kernels fallen und daher nicht behandelt werden. Hierzu gehören Verbesserungen an der Shell (z. B. integrierte Desktopsuche), an Netzwerkfunktionen (wie der neue IPv6-Stapel und die bidirektionale Firewall) und am Grafikmodell der nächsten Generation (wie die Aero™ Glass, Windows® Presentation Foundation, dem Desktopfenster-Manager und dem neuen Grafiktreibermodell). Ebenfalls nicht behandelt werden die neuen Windows-Benutzermodus- und Windows-Kernelmodus-Treiberframeworks (UMDF und KMDF), da diese auf früheren Versionen von Windows installiert werden können.

CPU-Zykluszählung
Windows Vista enthält eine Reihe von Verbesserungen im Bereich der Prozesse und Threads, zu denen die Verwendung des CPU-Zykluszählers für eine gerechtere CPU-Zuweisung und des neuen Multimediaklassen-Planungsdiensts (MMCSS) gehören, der Medienanwendungen bei der fehlerfreien Wiedergabe unterstützt.
Bei allen Versionen von Windows NT® bis einschließlich Windows Vista wird eine Intervallzeitgeber-Interruptroutine programmiert, die in Abhängigkeit von der Hardwareplattform ca. alle 10 oder 15 ms (Millisekunden) ausgeführt wird. Die Routine prüft, welchen Thread sie unterbrochen hat und aktualisiert die CPU-Nutzungsstatistik des Threads so, als ob dieser Thread während des gesamten Intervalls ausgeführt worden wäre, auch wenn die Ausführung des Threads in Wirklichkeit möglicherweise erst kurz vor dem Ende des Intervalls gestartet wurde. Darüber hinaus wurde der Thread möglicherweise technisch der CPU zugewiesen, erhielt jedoch keine Chance zur Ausführung, weil stattdessen Hardware- und Softwareinterruptroutinen ausgeführt wurden.
Obwohl die taktbasierte Zeitabrechnung für Diagnosetools, die die CPU-Nutzung durch Threads und Prozesse melden, möglicherweise in Ordnung ist, kann die Verwendung dieser Methode durch den Threadplaner zu einer ungerechten CPU-Zuweisung führen. Standardmäßig dürfen Threads auf Clientversionen von Windows bis zum Ablauf von 2 Zeiteinheiten des CPU-Takts ausgeführt werden (6 bei Ausführung im Vordergrund). Der Thread kann jedoch in Abhängigkeit von seinem Verhalten oder anderen Aktivitäten im System praktisch keine CPU-Zeit oder bis zu 6 Zeiteinheiten erhalten (18 bei Ausführung im Vordergrund).
Abbildung 1 zeigt die ungerechte Verteilung, die auftreten kann, wenn zwei Threads mit gleicher Priorität zum selben Zeitpunkt zur Ausführung bereit sind. Thread A wird bis zum Ablauf des nächsten Zeitintervalls ausgeführt. Dabei geht der Planer davon aus, dass der Thread während des gesamten Intervalls ausgeführt wurde, und entscheidet daher, dass die Ausführungszeit von Thread A beendet ist. Darüber hinaus geht der Interrupt, der während der Ausführung von Thread A aufgetreten ist, ungerechterweise zu dessen Lasten. Beim nächsten Intervall wählt der Planer Thread B aus, und dieser wird bis zum Ablauf des vollen Intervalls ausgeführt.
Abbildung 1 Ungerechte Threadplanung
Abbildung 1 Ungerechte Threadplanung
In Windows Vista verwendet der Planer das Zykluszählerregister moderner Prozessoren, um genau zu verfolgen, über wie viele CPU-Zyklen ein Thread ausgeführt wird. Durch Schätzung der Anzahl der Zyklen, die die CPU in einem Taktintervall ausführen kann, kann er die CPU-Zeit exakter verteilen. Darüber hinaus zählt der Windows Vista-Planer die Interruptausführung nicht in Bezug auf die Ausführungszeit eines Threads. Das bedeutet, dass ein Thread unter Windows Vista immer mindestens die ihm zugewiesene CPU-Zeit und nie mehr als ein zusätzliches Taktintervall zur Ausführung erhält, was zu einer größeren Gerechtigkeit und einem besser vorhersehbaren Anwendungsverhalten führt. Abbildung 2 zeigt, wie Windows Vista auf das in Abbildung 1 dargestellte Szenario reagiert, indem beiden Threads mindestens ein Zeitintervall zur Ausführung eingeräumt wird.
Abbildung 2 Zyklusbasierte Planung in Windows Vista
Abbildung 2 Zyklusbasierte Planung in Windows Vista
In der Randleiste „Überwachen der CPU-Nutzung durch Prozesse“ wird beschrieben, wie Sie die CPU-Zyklusnutzung durch Prozesse mithilfe des Dienstprogramms „Process Explorer“ selbst überwachen können.

Multimediaklassen-Planungsdienst
Benutzer erwarten, dass Multimediaanwendungen, einschließlich Musik- und Videoplayern, eine nahtlose Wiedergabeerfahrung bieten. Der CPU-Bedarf von anderen, gleichzeitig ausgeführten Anwendungen wie Antivirusprogrammen, Inhaltsindizierung oder sogar des E-Mail-Clients kann jedoch zu unangenehmen Unterbrechungen führen. Um eine bessere Wiedergabeerfahrung zu gewährleisten, wird in Windows Vista der Multimediaklassen-Planungsdienst MMCSS zur Verwaltung der CPU-Prioritäten von Multimediathreads eingeführt.
Eine Multimediaanwendung wie Windows Media® Player 11 registriert sich bei MMCSS mithilfe neuer APIs, die ihre Multimediamerkmale angeben. Diese müssen einem der unter dem folgenden Registrierungsschlüssel namentlich aufgeführten Merkmale entsprechen:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\Tasks

Abbildung A Anzeigen von CPU-Zeit und Zyklenunterschied in Process Explorer (Klicken Sie zum Verkleinern auf das Bild)
Abbildung A Anzeigen von CPU-Zeit und Zyklenunterschied in Process Explorer
Abbildung A Anzeigen von CPU-Zeit und Zyklenunterschied in Process Explorer (Klicken Sie zum Vergrößern auf das Bild)

Abbildung 3 Audio-Taskdefinition durch den Multimediaklassen-Planungsdienst
Abbildung 3 Audio-Taskdefinition durch den Multimediaklassen-Planungsdienst (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 3 Audio-Taskdefinition durch den Multimediaklassen-Planungsdienst
Abbildung 3 Audio-Taskdefinition durch den Multimediaklassen-Planungsdienst (Klicken Sie zum Vergrößern auf das Bild)
Der MMCSS-Dienst, der in %SystemRoot%\System32\Mmcss.dll implementiert ist und in einem Service Host-Prozess (Svchost.exe) ausgeführt wird, verfügt über einen Thread zur Prioritätsverwaltung, der mit der Priorität 27 ausgeführt wird. (Die Threadprioritäten unter Windows reichen von 0 bis 31.) Dieser Thread erhöht die Priorität registrierter Multimediathreads auf den Bereich, der dem in Abbildung 4 aufgeführten Scheduling Category-Wert des Registrierungsschlüssels ihres Tasks zugeordnet ist. In Windows liegen Threadprioritäten von 16 und höher im Echtzeitprioritätsbereich und über allen anderen Threads in einem System (mit Ausnahme der Memory Manager-Arbeitsthreads des Kernels, die mit der Priorität 28 und 29 ausgeführt werden). Nur Administratorkonten wie das lokale Systemkonto, in dem MMCSS ausgeführt wird, verfügen über das Recht zur Prioritätserhöhung, das zur Festlegung von Echtzeit-Threadprioritäten erforderlich ist.
Figure 4 MMCSS-Threadprioritäten (Close Figure 4)

Scheduling Category | Erhöhte Threadpriorität
Hoch | 23-26
Mittel | 16-23
Bei der Wiedergabe einer Audiodatei registriert Windows Media Player Audio-Taskthreads und bei der Wiedergabe eines Videos Playback-Taskthreads. Der MMCSS-Dienst erhöht die Priorität aller Threads, die angegeben haben, dass sie einen Datenstrom liefern, wenn sie in dem Prozess ausgeführt werden, dem das Vordergrundfenster gehört, und wenn für sie der BackgroundOnly-Wert im Definitionsschlüssel ihres Tasks auf „True“ festgelegt wurde.
Obgleich MMCSS darauf abzielt, Multimediathreads zur erforderlichen CPU-Zeit zu verhelfen, muss der Dienst gleichzeitig sicherstellen, dass andere Threads zumindest etwas CPU-Zeit erhalten, damit das System und andere Anwendungen reaktionsfähig bleiben. MMCSS reserviert daher einen bestimmten Prozentsatz der CPU-Zeit für andere Aktivitäten, der im folgenden Registrierungswert angegeben wird:
HKLM\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\SystemResponsiveness
Standardmäßig beträgt dieser Wert 20 Prozent. MMCSS überwacht die CPU-Nutzung, um sicherzustellen, dass die Priorität von Multimediathreads über einen Zeitraum von 10 ms nicht mehr als 8 ms lang erhöht wird, wenn andere Threads CPU-Ressourcen benötigen. Um die Multimediathreads für die verbleibenden 2 ms aus dem Weg zu räumen, verringert der Planungsdienst ihre Priorität auf den Bereich 1 bis 7.
Sie können erfahren, wie MMCSS die Threadpriorität erhöht, indem Sie die Randleiste „Überwachen der Prioritätserhöhung durch MMCSS“ lesen.

Dateibasierte symbolische Verknüpfungen
Zu den mit E/A-Vorgängen verbundenen Änderungen in Windows Vista gehören dateibasierte symbolische Verknüpfungen, effizientere Verarbeitung des Abschlusses von E/A-Vorgängen, umfassende Unterstützung für den Abbruch von E/A-Vorgängen und nach Priorität geordnete E/A-Vorgänge.
Ein Dateisystemfeature, das von vielen Benutzern in NTFS vermisst wurde – die symbolische Dateiverknüpfung (oder der Softlink, wie er in UNIX genannt wird) – wird nun mit Windows Vista eingeführt. In der Windows 2000-Version von NTFS wurden als Verzeichnisverbindungen bezeichnete symbolische Verzeichnisverknüpfungen eingeführt, mit denen Sie ein Verzeichnis erstellen können, das auf ein anderes Verzeichnis verweist. Vor Windows Vista unterstützte NTFS jedoch nur feste Verknüpfungen für Dateien.
Ein Hauptunterschied bei der Art und Weise, in der Windows symbolische Verknüpfungen und Verzeichnisverbindungen auflöst, liegt darin, wo die Verarbeitung stattfindet. Windows verarbeitet symbolische Verknüpfungen auf dem lokalen System, selbst wenn sie auf einen Speicherort auf einem Remotedateiserver verweisen. Verzeichnisverbindungen, die auf einen Remotedateiserver verweisen, werden von Windows auf dem Server selbst verarbeitet. Symbolische Verknüpfungen auf einem Server können daher auf Speicherorte verweisen, auf die nur von einem Client zugegriffen werden kann (beispielsweise auf andere Clientvolumes), während dies bei Verzeichnisverbindungen nicht möglich ist. Zur Lösung dieses Problems unterstützt Windows Vista den neuen symbolischen Verknüpfungstyp sowohl für Dateien als auch für Verzeichnisse.
Viele Dateisystembefehle wurden aktualisiert, um das Verständnis der Auswirkungen symbolischer Verknüpfungen zu gewährleisten. Der Delete-Befehl z. B. folgt Verknüpfungen nicht, da dies zur Löschung des Ziels führen würde, sondern löscht stattdessen die Verknüpfung. Da jedoch möglicherweise nicht alle Anwendungen symbolische Verknüpfungen richtig verarbeiten, wird zum Erstellen einer symbolischen Verknüpfung das neue Recht zum Erstellen symbolischer Verknüpfungen benötigt, über das standardmäßig nur Administratoren verfügen.
Sie können mit dem Mklink-Befehl eine symbolische Verknüpfung über eine Eingabeaufforderung erstellen. Der integrierte Verzeichnisbefehl der Eingabeaufforderung identifiziert eine symbolische Verknüpfung, indem er sie mit <SYMLINK> kennzeichnet und Ihnen das Ziel in Klammern anzeigt, wie in Abbildung 5 dargestellt. Windows-Explorer erkennt ebenfalls symbolische Verknüpfungen und zeigt sie mit dem Verknüpfungspfeil an. Sie können das Ziel einer Verknüpfung im Explorer anzeigen, indem Sie dem Browserfenster die Spalte „Linkziel“ hinzufügen.Überwachen der Prioritätserhöhung durch MMCSS
Sie können die Erhöhung der Threadpriorität verfolgen, die der MMCSS-Dienst auf Windows Media Player-Threads anwendet, indem Sie einen Video- oder Audioclip abspielen, den Systemmonitor ausführen, die Diagrammskala auf 31 festlegen (die höchste Threadpriorität in Windows) und den Zähler „Aktuelle Priorität“ für alle Instanzen der Threadobjekte von Windows Media Player (Wmplayer.exe) der Anzeige hinzufügen. Ein oder mehrere Threads werden mit der Priorität 21 ausgeführt.
Abbildung B Erhöhung der Threadpriorität für Windows Media Player
Abbildung B Erhöhung der Threadpriorität für Windows Media Player (Klicken Sie zum Verkleinern auf das Bild)
Abbildung B Erhöhung der Threadpriorität für Windows Media Player
Abbildung B Erhöhung der Threadpriorität für Windows Media Player (Klicken Sie zum Vergrößern auf das Bild)

Abbildung 5 Erstellen einer symbolischen Verknüpfung mit Mklink
Abbildung 5 Erstellen einer symbolischen Verknüpfung mit Mklink (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 5 Erstellen einer symbolischen Verknüpfung mit Mklink
Abbildung 5 Erstellen einer symbolischen Verknüpfung mit Mklink (Klicken Sie zum Vergrößern auf das Bild)

Abschluss und Abbruch von E/A-Vorgängen
Es gibt eine Reihe von internen Änderungen am E/A-System, die die Leistung von Serveranwendungen verbessern können. Diese Anwendungen verwenden in der Regel ein als Abschlussport bezeichnetes Synchronisierungsobjekt, um auf den Abschluss von asynchronen E/A-Anforderungen zu warten. Vor Windows Vista führte bei Abschluss eines solchen E/A-Vorgangs der Thread, der die E/A-Anforderung gesendet hatte, die Aufgaben zum Abschluss des E/A-Vorgangs aus, wodurch ein Wechsel zu dem Prozess bewirkt wurde, zu dem der Thread gehörte, und alle anderen Vorgänge unterbrochen wurden. Dann aktualisierte das E/A-System den Status des Abschlussports, um einen Thread zu aktivieren, der auf die Änderung des Status wartete.
Bei Windows Vista wird der Abschluss von E/A-Vorgängen nicht unbedingt von dem Thread verarbeitet, der die E/A-Anforderung gesendet hat, sondern von dem Thread, der auf seine Aktivierung durch den Abschlussport wartet. Durch diese relativ kleine Änderung werden unnötige Threadplanung und überflüssige Kontextwechsel vermieden, die die Gesamtleistung der Anwendung und des Systems beeinträchtigen können. Zur weiteren Verbesserung der Leistung kann ein Server die Ergebnisse mehrerer E/A-Vorgänge beim Abschluss in einer Anforderung abrufen, wodurch Übergänge in den Kernelmodus vermieden werden.
Die wahrscheinlich offensichtlichste Änderung im E/A-System aus der Endbenutzerperspektive besteht in der Unterstützung des Abbruchs synchroner E/A-Vorgänge in Windows Vista. Falls Sie jemals mit Windows XP oder Windows Server® 2003 einen Net View-Befehl ausgeführt haben oder versucht haben, auf eine Freigabe auf einem im Offlinemodus befindlichen Remotesystem zuzugreifen, kennen Sie die Probleme mit E/A-Vorgängen, die nicht abgebrochen werden können: Der Befehls- oder Dateibrowser reagiert erst nach Ablauf eines Netzwerktimeouts. Eine Anwendung kann nur warten, bis der Vorgang fehlschlägt, da sie dem Gerätetreiber, der den E/A-Vorgang ausführt, nicht mitteilen kann, dass der E/A-Vorgang nicht mehr erforderlich ist.
In Windows Vista können die meisten E/A-Vorgänge abgebrochen werden, einschließlich des E/A-Vorgangs zum Öffnen von Dateien, der von Net View und Explorer verwendet wird. Anwendungen müssen jedoch aktualisiert werden, damit sie auf Endbenutzeranforderungen zum Abbruch von E/A-Vorgängen reagieren. Viele Dienstprogramme von Windows Vista, die mit Geräten interagieren, für die Timeouts festgelegt sind, verfügen über die erforderliche Unterstützung. In den Dialogfeldern zum Öffnen und Speichern von Dateien, die in nahezu jeder Windows-Anwendung verwendet werden, einschließlich Anwendungen von Drittanbietern, ist jetzt die Schaltfläche „Abbrechen“ aktiviert, wenn versucht wird, den Inhalt eines Ordners anzuzeigen. Beim Net-Befehl werden ebenfalls die zugehörigen synchronen E/A-Vorgänge abgebrochen, wenn Sie STRG+C drücken.
Sie können sich von den Vorteilen des Abbruchs von E/A-Vorgängen überzeugen, indem Sie in Windows Vista eine Eingabeaufforderung öffnen und Folgendes eingeben:
net view (\\nonexistentmachine)
Der Befehl bleibt hängen, während Windows versucht, Kontakt zu dem nicht vorhandenen System aufzunehmen. Sie können ihn jedoch mit STRG+C beenden. In Windows XP hat STRG+C keine Wirkung, und der Befehl wird erst zurückgegeben, wenn beim Netzwerkvorgang ein Timeout auftritt.
Eine andere Art von E/A-Vorgängen, die Benutzer in früheren Versionen von Windows vor Probleme stellte, waren E/A-Vorgänge, die von Gerätetreibern nicht ordnungsgemäß abgebrochen wurden. Dies beruhte darauf, dass die Treiber nicht ohne weiteres feststellen konnten, ob der Vorgang abgebrochen werden sollte. Wenn Sie je einen Prozess beendet haben und dieser anschließend in Tools zum Anzeigen von Prozessen weiterhin aufgeführt wurde, haben Sie erlebt, dass ein Gerätetreiber nicht auf eine Beendigung eines Prozesses reagiert und vom Prozess gesendete E/A-Anforderungen abgebrochen hat, die noch nicht abgeschlossen worden waren. Windows kann die endgültige Prozessbereinigung erst dann durchführen, wenn alle E/A-Vorgänge des Prozesses beendet oder abgebrochen wurden. In Windows Vista können sich Gerätetreiber auf einfache Weise für die Benachrichtigung über die Beendigung von Prozessen registrieren. Daher entfallen die meisten Probleme mit Prozessen, die sich nicht beenden lassen.

E/A-Priorität
Obwohl Windows schon immer die Priorisierung der CPU-Nutzung unterstützt hat, fand das Konzept der E/A-Priorität keine Anwendung. Ohne E/A-Priorität können Hintergrundaktivitäten wie Suchindexerstellung, Virensuche und Datenträgerdefragmentierung das Reaktionsvermögen von Vordergrundvorgängen stark beeinträchtigen. Wenn ein Benutzer eine Anwendung startet oder ein Dokument öffnet, während ein anderer Prozess z. B. Datenträger-E/A-Vorgänge ausführt, treten Verzögerungen auf, da der Vordergrundtask auf den Datenträgerzugriff wartet. Die gleiche Beeinträchtigung betrifft die Streamingwiedergabe von Multimediainhalten wie Musiktiteln von einer Festplatte.
Mit Windows Vista werden zwei neue Arten der E/A-Priorisierung eingeführt, damit E/A-Vordergrundvorgänge den Vorzug erhalten: Priorität für einzelne E/A-Vorgänge und für E/A-Bandbreitenreservierungen. Das E/A-System von Windows Vista umfasst interne Unterstützung für fünf E/A-Prioritäten, wie in Abbildung 6 dargestellt. Es werden jedoch nur vier Prioritäten verwendet (zukünftige Versionen von Windows könnten „Hoch“ unterstützen).
Figure 6 E/A-Prioritäten von Windows Vista (Close Figure 6)

E/A-Priorität | Nutzung
Kritisch | Memory Manager
Hoch | Nicht verwendet
Normal | Standardpriorität
Niedrig | Standardtaskpriorität
Sehr niedrig | Hintergrundaktivität
E/A-Vorgänge haben standardmäßig die Priorität „Mittel“. Der Memory Manager verwendet „Kritisch“, wenn er in Situationen mit niedriger Arbeitsspeicherkapazität geänderte Speicherdaten auf die Festplatte schreiben muss, um im Arbeitsspeicher Platz für andere Daten und Code zu schaffen. Der Windows-Taskplaner legt die E/A-Priorität für Tasks mit der Standardtaskpriorität auf „Niedrig“ fest. Die Priorität, die von für Windows Vista entwickelten Anwendungen vorgegeben wird, die die Hintergrundverarbeitung durchführen, ist „Sehr niedrig“. Für alle Hintergrundvorgänge von Windows Vista, einschließlich Windows Defender-Scanvorgängen und Desktopsuchindexerstellung, wird die E/A-Priorität „Sehr niedrig“ verwendet.Anzeigen sehr niedriger E/A-Priorität
Process Monitor, ein Dienstprogramm von Sysinternals zur Dateisystem- und Registrierungsüberwachung in Echtzeit, sammelt ausführliche Informationen für Lese-und Schreibvorgänge im Dateisystem, einschließlich ihrer E/A-Prioritäten unter Windows Vista. Die hervorgehobene Zeile zeigt ein Beispiel für eine E/A-Anforderung mit sehr niedriger Priorität, die von SuperFetch gesendet wurde (worauf ich in meinem nächsten Artikel eingehen werde).
Abbildung C Anzeigen sehr niedriger E/A-Priorität in Process Monitor
Abbildung C Anzeigen sehr niedriger E/A-Priorität in Process Monitor (Klicken Sie zum Verkleinern auf das Bild)
Abbildung C Anzeigen sehr niedriger E/A-Priorität in Process Monitor
Abbildung C Anzeigen sehr niedriger E/A-Priorität in Process Monitor (Klicken Sie zum Vergrößern auf das Bild)

Der Systemspeicherklassen-Gerätetreiber (%SystemRoot%\System32\Classpnp.sys) erzwingt die E/A-Prioritäten, sodass sie automatisch für an die meisten Speichergeräte gesendete E/A-Anforderungen gelten. Die Klassentreiber und anderen Speichertreiber fügen E/A-Anforderungen mit der Priorität „Mittel“ vor denen mit der Priorität „Niedrig“ und „Sehr niedrig“ in ihre Warteschlangen ein. Sie senden jedoch pro Sekunde mindestens eine wartende E/A-Anforderungen mit der Priorität „Niedrig“ oder „Sehr niedrig“, damit die Hintergrundprozesse Fortschritte machen können. Das Lesen von Daten mit sehr niedriger E/A-Priorität führt zudem dazu, dass der Cache-Manager Änderungen sofort auf die Festplatte schreibt, statt diesen Vorgang auf später zu verschieben. Darüber hinaus wird seine Vorausleselogik für Lesevorgänge umgangen, die andernfalls vorausschauend aus der Datei lesen würde, auf die gerade zugegriffen wird. Ein Beispiel für sehr niedrige E/A-Priorität unter Verwendung des Dienstprogramms „Process Monitor“ finden Sie in der Randleiste „Anzeigen sehr niedriger E/A-Priorität“.
Die Unterstützung der Reservierung von Bandbreite in Windows Vista ist für Anwendungen zur Medienwiedergabe nützlich. Die Bandbreitenreservierung wird von Windows Media Player in Verbindung mit der Prioritätserhöhung durch MMCSS zur Gewährleistung der nahezu fehlerfreien Wiedergabe lokaler Inhalte verwendet. Eine Anwendung zur Medienwiedergabe fordert das E/A-System auf, ihr zu garantieren, dass sie Daten mit einer bestimmten Geschwindigkeit lesen kann. Wenn das Gerät Daten mit der angeforderten Geschwindigkeit liefern kann und die vorhandenen Reservierungen es gestatten, teilt es der Anwendung mit, wie schnell sie E/A-Anforderungen senden sollte und wie groß diese sein sollten. Das E/A-System bearbeitet andere E/A-Anforderungen nur dann, wenn es die Anforderungen von Anwendungen erfüllen kann, die Reservierungen für das Zielspeichergerät vorgenommen haben.
Die letzte erwähnenswerte Änderung im E/A-System bezieht sich auf die Größe von E/A-Vorgängen. Seit der ersten Version von Windows NT wurde die Menge der von einer einzelnen Speicher-E/A-Anforderung verarbeiteten Daten vom Memory Manager und E/A-System auf 64 KB begrenzt. Selbst wenn eine Anwendung eine viel größere E/A-Anforderung sendet, wird diese in einzelne Anforderungen mit einer maximalen Größe von 64 KB aufgeteilt. Bei jedem E/A-Vorgang entsteht ein Mehraufwand für Übergänge in den Kernelmodus und das Einleiten einer E/A-Übertragung auf dem Speichergerät. Daher wird in Windows Vista die Größe von Speicher-E/A-Anforderungen nicht mehr begrenzt. Mehrere Benutzermoduskomponenten von Windows Vista wurden geändert, um die Unterstützung für größere E/A-Anforderungen zu nutzen, einschließlich der Kopierfunktionalität von Explorer und des Copy-Befehls der Eingabeaufforderung, die jetzt E/A-Anforderungen mit einer Größe von 1 MB senden.

Ausblick
Sie haben jetzt zwei Bereiche kennen gelernt, in denen der Windows Vista-Kernel verbessert wurde. Sie können weitere detaillierte Informationen in der nächsten Ausgabe meines Buchs Windows Internals erwarten (gemeinsam mit David Solomon verfasst), dessen Veröffentlichung für den gleichen Zeitpunkt wie die nächste Version von Windows Server mit dem Codenamen „Longhorn“ geplant ist. In meinem nächsten Artikel werde ich Ihnen weitere Einblicke in den neuen Kernel geben, indem ich auf die Speicherverwaltung und das Starten und Herunterfahren des Systems eingehe.

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. Er wechselte bei der kürzlichen Übernahme des von ihm mitgegründeten Unternehmens Winternals Software zu Microsoft. Darüber hinaus gründete er Sysinternals, wo er die Dienstprogramme „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: Delegieren von Befugnissen in Active Directory
Windows-Verwaltung Joel Yoker and Rob Campbell

Delegieren von Befugnissen in Active Directory
Kurz zusammengefasst:
  • Definieren von Administratorrollen
  • Entwickeln eines Modells der Organisationseinheit und Sicherheitsgruppen
  • Verwenden sekundärer Konten
  • Tools für das Delegieren von Rechten

Die Delegierungsfunktionen in Active Directory sind ausgesprochen leistungsstark und können eine Anzahl von Sicherheitsproblemen lösen und Verwaltungsaufgaben vereinfachen. Durch das ordnungsgemäße Delegieren von Rechten in Active
Directory® können Sie festgelegte Rollen in der Umgebung durchsetzen, die Wahrscheinlichkeit von Administratorfehlern und die Folgen derartiger Fehler verringern und das Prinzip der geringsten Rechte innerhalb der Infrastruktur realisieren. Viele Organisationen, die sich auf Active Directory verlassen, schöpfen die Leistungsstärke der Delegierung nicht aus. Dies liegt zum Teil daran, dass das Entwickeln eines Active Directory-Delegierungsmodells für ein Unternehmen auf den ersten Blick als eine recht komplizierte Aufgabe erscheint. Die größte Hürde besteht im Entwickeln eines Delegierungsmodells, das den jeweiligen Anforderungen der Organisation entspricht. Es gibt jedoch sehr einfache Modelle, die mit geringfügigen Änderungen in fast allen IT-Infrastrukturen verwendet werden können.
Obwohl jede Umgebung ihre Besonderheiten aufweist, ähneln sich die meisten großen Unternehmen in vieler Hinsicht und stehen im Bereich IT vor den gleichen Herausforderungen. So sind z. B. viele Organisationen in geografische Regionen unterteilt, aus separaten Teams von IT-Technikern oder Support-Experten hervorgegangen und verfügen über unabhängige Geschäftsbereiche. Viele große Organisationen müssen sich mit Problemen wie der Rechteerweiterung, dem Missbrauch von Dienstkonten und mit „Vertrauen“ befassen.
Das Wort „Vertrauen“ ist ein interessanter Begriff und wird oft als Rechtfertigung für das Vorhandensein mehrerer Active Directory-Gesamtstrukturen verwendet. Probleme mit dem Vertrauen entstehen oftmals durch die Fähigkeit eines Geschäftsbereichs oder einer Region, die Systemverfügbarkeit für einen anderen Geschäftsbereich oder eine andere Region negativ zu beeinflussen. Normalerweise bestehen über die Grenzen innerhalb einer Organisation hinweg Unterschiede bei den Fähigkeiten und Fertigkeiten. Daraus ergibt sich ein Wissensdefizit bezüglich der Besonderheiten der Systeme, die für die Unterstützung einer bestimmten Region oder eines bestimmten Geschäftsbereichs erforderlich sind. Folglich möchten die Bereiche in den meisten Fällen ihre Administratorrechte nicht an eine zentralisierte Gruppe abtreten.
Mittlerweile ist es bei jeder Implementierung von Active Directory notwendig, dass die Administratoren die Regeln für das Aktivieren von Anwendungen definieren, welche die Infrastruktur von Active Directory nutzen. Leider besteht eine allgemein verbreitete Lösung (eine Lösung, die oftmals in Installationshandbüchern angegeben wird) darin, dass ein Dienstkonto als Mitglied der Gruppe der Domänenadministratoren eingerichtet wird. Das Problem bei dieser Vorgehensweise besteht darin, dass Dienstkonten ihrem Wesen nach allgemeine Konten sind. Durch das Gewähren von Rechten eines Domänenadministrators für diese Konten sorgen Sie für eine ernste Bedrohung für die IT-Umgebung. Dienstkonten können leicht durch böswillige oder unvorsichtige Administratoren einer unsachgemäßen Verwendung ausgesetzt werden, oder diese Konten werden von Angreifern ausgenutzt, die sich grundlegende Sicherheitsprobleme in einer Anwendung zunutze machen.
Obwohl diese Hürden möglicherweise unüberwindlich scheinen, stellen sie ein wichtigstes Szenario zum Implementieren eines Delegierungsmodells in Active Directory zur Verfügung. Das Entwickeln eines Delegierungsmodells ist ein iterativer Entwurfsprozess, und es empfiehlt sich, dass Sie dazu die folgenden Schritte ausführen:
  1. Definieren Sie die Rollen für die IT-Administratoren innerhalb der Organisation.
  2. Entwickeln Sie ein Modell für Organisationseinheit und Sicherheitsgruppe.
  3. Richten Sie sekundäre Konten für IT-Administratoren ein.
  4. Delegieren Sie Rechte.
Im Folgenden werden diese Schritte näher betrachtet.

Definieren von Rollen
Der Prozess für die Rollendefinition baut auf einem eingehenden Verständnis der Dienstverwaltung und der Datenverwaltung auf. Diese Begriffe sind die Säulen eines jeden Delegierungsmodells für Active Directory.
Seinem Wesen nach besteht die Dienstverwaltung in der Verwaltung der Infrastrukturkomponenten kritischer Verzeichnisdienste wie Exchange-Server und Domänencontroller. Die Datenverwaltung ist die Verwaltung von Objekten wie Postfächer und Benutzerkonten, die innerhalb dieser Dienste bestehen. Innerhalb des Wirkungsbereichs von Active Directory sind Dienstadministratoren letzten Endes für die Bereitstellung und die Verfügbarkeit der Verzeichnisdienste verantwortlich. Datenadministratoren verwalten demgegenüber Benutzer- und Serverkonten, Gruppen und andere Domänenressourcen.
Active Directory unterstützt über Organisationseinheiten (Organizational Units, OUs) die exakt umgrenzte Delegierung von Verantwortlichkeiten. Organisationseinheiten können oftmals so gestaltet werden, dass sie die gleiche Befugnisebene bieten, über die Administratoren innerhalb des vorhandenen Verzeichnisdienstes oder der vorhandenen Domänenmodelle verfügen. Es ist jedoch wichtig zu verstehen, dass einige Funktionen einfach nicht delegiert werden können und von einer einzelnen, höchst vertrauenswürdigen Gruppe oder Einheit verwaltet werden müssen.
Auch die Analyse der Aufgaben ist von entscheidender Bedeutung. Sie müssen wissen, welche Aufgaben in Active Directory von Administratoren ausgeführt werden und wie diese Aufgaben Rollen zugeordnet sind. So ist z. B. das Anlegen eines Active Directory-Standorts eine Dienstverwaltungsaufgabe, während Änderungen an der Mitgliedschaft in Sicherheitsgruppen gewöhnlich unter die Aufgaben der Datenverwaltung fallen. Jede Aufgabe sollte hinsichtlich Häufigkeit, Wichtigkeit und Schwierigkeit bewertet werden. Dies sind wichtige Aspekte der Aufgabendefinition, da sie bestimmen, ob ein Recht delegiert werden sollte. Aufgaben, die routinemäßig ausgeführt werden, nur ein begrenztes Risiko darstellen und einfach auszuführen sind, sind ausgezeichnete Kandidaten für eine Delegierung. Aufgaben, die selten ausgeführt werden, bedeutende Auswirkungen auf die Organisation haben und ein hohes Niveau an Fähigkeiten und Fertigkeiten erfordern, eignen sich dagegen nicht für eine Delegierung. Für diese Aufgaben ist stattdessen die Rechteerweiterung (das vorübergehende Heraufsetzen eines Kontos auf die erforderliche Rolle bzw. die Neuzuweisung der Aufgabe) die richtige Lösung.
Da sich viele Merkmale großer Organisationen ähneln, kann davon ausgegangen werden, dass ein allgemeines Delegierungsmodell implementiert werden kann. Für diesen Artikel werden wir einen Beispielsatz von Rollen bereitstellen, die Verwaltungsfunktionen ermöglichen und dabei Organisationsgrenzen respektieren und darauf abzielen, Vertrauensprobleme (wie z. B. die Verfügbarkeit von unternehmensweiten Ressourcen wie Domänencontroller) einzuschränken. Beachten Sie, dass dieses Modell lediglich ein Beispiel ist. Es bietet einen hervorragenden Ausgangspunkt für eine Diskussion über die Rollen in einer Organisation, sollte jedoch nicht buchstabengetreu umgesetzt werden.
Einige Rollen werden bereits von Active Directory festgelegt, und einige müssen von Grund auf neu festgelegt werden, um das Delegierungsmodell abzurunden. Ein Beispielsatz der Rollen, der für viele große Active Directory-Umgebungen geeignet wäre, enthält möglicherweise die Rollen „Organisations-Admins“, „Domänen-Admins“ und „Tier4-Admins“ für die Dienstverwaltung und „Tier3-Admins“, „Regional-Admins“, „Tier2-Admins“ und „Tier1-Admins“ für die Datenverwaltung. Eine Liste dieser Rollen und der zugehörigen Verantwortlichkeiten finden Sie in Abbildung 1.
Figure 1 Definieren von Rollen und Verantwortlichkeiten (Close Figure 1)

Dienstadministratoren | Beschreibung
Organisations-Admins | Verantwortlich für das Verwalten von Diensten auf höchster Ebene über das gesamte Unternehmen hinweg. Sollte keine ständigen Mitglieder enthalten.
Domänen-Admins | Verantwortlich für das Verwalten von Diensten auf höchster Ebene über die gesamte Domäne hinweg. Sollte nur aus einer kleinen, überschaubaren Anzahl vertrauenswürdiger Administratoren bestehen.
Tier4-Admins | Verantwortlich für Dienstverwaltung in der Domäne. Erhalten nur die notwendigen Rechte für das Verwalten notwendiger Dienste. Dient als Punkt für die Rechteausweitung von Datenadministratoren.
Datenadministratoren | Beschreibung
Tier1-Admins | Verantwortlich für das allgemeine Verwalten der Verzeichnisobjekte, das Ausführen von Aufgaben wie z. B. das Zurücksetzen von Kennwörtern, das Ändern der Eigenschaften von Benutzerkonten usw.
Tier2-Admins | Verantwortlich für das Anlegen und/oder das Löschen ausgewählter Benutzer- und Computerkonten für ihr Gebietsschema oder ihre Organisation.
Regional-Admins | Verantwortlich für das Verwalten der Struktur ihrer Organisationseinheit am Standort. Erhalten Berechtigungen zum Anlegen fast aller Objekte in ihrer Organisationseinheit.
Tier3-Admins | Verantwortlich für das Verwalten aller Datenadministratoren. Dienen als Helpdesk der obersten Schicht und Punkt für die Rechteausweitung für alle Regionaladministratoren.

Dienstadministratoren
Im Folgenden werden die Dienstadministratorrollen näher betrachtet. Dienstadministratoren verwalten kritische Infrastrukturkomponenten, und alle Administratoren in dieser Kategorie verfügen über umfangreiche Rechte. Daher ist in diesem Falle eine Strategie der geringsten Rechte äußerst angebracht. Dies bedeutet, dass lediglich der für die Ausführung der notwendigen Aufgaben benötigte minimale Satz an Berechtigungen vergeben wird.
Für Organisations- und Domänenadministratoren definiert Active Directory zwei Gruppen von speziellen Administratoren, deren Sicherheitskontext für kritische Funktionen innerhalb des Verzeichnisses erforderlich ist. Diese Gruppen (Organisations-Admins und Domänen-Admins) sind für die Dienstverwaltung auf höchster Ebene verantwortlich. Um die Risiken zu verringern, die mit solchen mit umfangreichen Rechten ausgestatteten Gruppen verknüpft sind, wird dringend angeraten, die Gruppenmitgliedschaft streng einzugrenzen. Genau gesagt, sollte die Gruppe der Organisations-Admins keine ständigen Mitglieder haben und die Gruppen der Domänen-Admins nur eine geringe, überschaubare Anzahl vertrauenswürdiger Personen enthalten, die auf Vollzeitbasis für die Organisation tätig sind.
Wenn unternehmensweite Verwaltungsaufgaben wie die DHCP-Serverautorisierung oder das Anlegen von Active Directory-Standorten ausgeführt werden müssen, können die Domänen-Admins in der Stammdomäne der Active Directory-Gesamtstruktur Berechtigungen durch Verwalten der Mitgliedschaft in der Gruppe der Organisations-Admins erweitern. Diese Berechtigungen sollten nur für kurze Zeit gewährt werden, um das Einrichten permanenter Mitglieder in der Gruppe der Organisations-Admins zu vermeiden. Selbstverständlich müssen alle Mitglieder der Gruppe „Domänen-Admins“ in einer gegebenen Active Directory-Gesamtstruktur das gleiche Vertrauen genießen.
Ein allgemein bekannter Fehler, den die meisten Organisationen beim Entwickeln eines Delegierungsmodells begehen, besteht im Deaktivieren oder Schwächen dieser Standardrollen. Änderungen an den Standardrollen können zu nicht vorhersagbaren Ergebnissen führen, und es gibt keine Garantie, dass Service Pack-Revisionen oder Produktupgrades diese Einstellungen übernehmen. Außerdem entsteht durch diese Art von Änderungen eine nicht unterstützte Umgebung außerhalb der Organisation. Eine praktikable Lösung besteht darin, die Standardgruppen und die Standardrollen zu nutzen, die Mitgliedschaft in diesen Gruppen jedoch einzuschränken. Um dies umzusetzen, müssen Sie wahrscheinlich neue Rollen für Administratoren erstellen, die sich bisher auf ihre Mitgliedschaft in Gruppen wie Domänen-Admins verlassen haben.
Tier4-Admins: Die Gruppe der Tier4-Administratoren sollte aus zentralisierten Dienstadministratoren bestehen, die Support für alle Unternehmensdienste bereitstellen. Da es sich um eine erstellte Rolle handelt, können Verzeichnisdienst und Berechtigungen für den Systemzugriff an die spezifischen Anforderungen der Organisation angepasst werden. Obwohl die Mitglieder dieser Gruppe Dienstadministratoren sind, können sie gelegentlich auch gesamtstrukturübergreifende Datenverwaltungsaufgaben durchführen. Da es viele Klassen von Systemen und verschiedene Verantwortungsbereiche gibt, werden Tier4-Rollen in verschiedene Untergruppen innerhalb des Verzeichnisses aufgeteilt. So sollten z. B. separateTier4-Gruppen erstellt werden, um eine eigenständige Verwaltung für bestimmte Systeme (z. B. Exchange Server) bereitzustellen. Diese Gruppe dient auch als Ansatzpunkt für die Rechteerweiterung für Datenadministratoren.
Ein Grund, warum Benutzer gern die Mitgliedschaft in der Gruppe der Domänenadministratoren erlangen möchten, besteht darin, dass sie über Administratorrechte für alle Systeme in einer Domäne verfügen möchten. Der Trick, diese Dienstadministratoren in einem Modus mit den geringsten Rechten arbeiten zu lassen, besteht darin, ihnen die Rechte eines Tier4-Administrators für die Unternehmensserver zu gewähren, ohne sie als Domänenadministratoren einzurichten. Um die Erweiterung von Rechten zu verhindern, sollten Tier4-Administratoren nicht als Mitglieder der Gruppe „BUILTIN\Administratoren“ auf Domänencontrollern eingerichtet werden, da diese Gruppe über eine Vielzahl an grundlegenden Rechten im Verzeichnisdienst verfügt, die untrennbar sind. Beispielsweise kann ein Mitglied der Gruppe „BUILTIN\Administratoren“ einer Domäne die Mitgliedschaft in der Gruppe „Domänen-Admins“ verwalten und somit Mitgliedern das Erweitern von Rechten ohne jegliche Überprüfungen und Abgleiche ermöglichen.
Wenn Sie sich an die Regel über das Nichteinschränken von Standardberechtigungen erinnern, kann dieses Risiko verringert werden, indem die Tier4-Gruppen als verschachtelte Mitglieder in den Standardgruppen der Server-Operatoren und der DNS-Administratoren eingerichtet werden. Dies ermöglicht die lokale Verwaltung der Domänencontroller und schränkt gleichzeitig die Möglichkeiten von Tier4-Administratoren zum Erweitern von Rechten ein. Für die meisten Systeme (die keine Domänencontroller, Zertifikatserver usw. sind) sollten Sie die Gruppe der Tier4-Administratoren als Mitglied der lokalen Administratorengruppe einrichten. Eine Automatisierung der Mitgliedschaft in verschachtelten lokalen Gruppen kann mit der Funktion „Eingeschränkte Gruppen“ in der Gruppenrichtlinie erreicht werden.

Datenadministratoren
Im Folgenden werden die Datenadministratorrollen näher betrachtet. Diese sollten mit kumulativen Rechten gestaltet werden. Das bedeutet, dass ein Tier2-Administrator über alle Rechte eines Tier1-Administrators und über einige zusätzliche Berechtigungen verfügen sollte usw. Aus diesem Grund sind die Gruppen in aufsteigender Reihenfolge angegeben.
Tier1-Admins: Die Gruppe der Tier1-Administratoren sollte allgemeine Verwaltungsaufgaben für bereits erstellte Verzeichnisobjekte ausführen. Diese Gruppe ist für Administratoren mit dem kleinsten Verantwortungsbereich oder für solche Administratoren vorgesehen, die isolierte Aufgaben wie das Zurücksetzen von Kennwörtern ausführen. Gewähren Sie dieser Gruppe die Rechte innerhalb ihrer Organisationseinheit zum Ändern der Eigenschaften von Benutzerkonten, zum Zurücksetzen der Kennwörter von Benutzerkonten, zum Entsperren von Konten, zum Aktivieren bzw. Deaktivieren von Benutzerkonten, zum Hinzufügen und Zurücksetzen von Konten auf Arbeitsstationen und zum Ändern der Mitgliedschaft in Gruppenobjekten für Gruppen ohne Administratorstatus.
Tier2-Admins: Diese Gruppe sollte das selektiven Verwalten und Erstellen von Objekten ermöglichen. Dabei sollten Objekte nur dort erstellt werden, wo sie von Tier1-Administratoren verwaltet werden können. (So können z. B. Sicherheitsgruppen nur in der Gruppen-Organisationseinheit erstellt werden). Tier2-Administratoren können Konten für Tier1-Administratoren hinzufügen und ändern, Benutzerkonten für eine Organisationseinheit hinzufügen, ändern und löschen, Computerobjekte des Typs „Arbeitsstation“ löschen und Objekte des Typs „Server“, „Kontakt“ und „Freigegebener Ordner“ hinzufügen, ändern und löschen.
Regional-Admins: Dieser Gruppe werden exklusive Rechte über die Struktur ihrer regionalen Organisationseinheit gewährt. Diese Administratoren können jedoch keine anderen Strukturen regionaler Organisationseinheiten innerhalb des Verzeichnisses verwalten. Regionaladministratorkonten sollten als mit umfangreichen Rechten ausgestattete Konten behandelt werden. Demzufolge werden diese Konten in einer separaten Hierarchie der Organisationseinheit gespeichert und durch die Dienstadministratoren der Gruppe „Tier4-Admins“ verwaltet. Regionaladministratoren können ohne Einschränkungen fast alle Objekte innerhalb der Struktur ihrer Organisationseinheit erstellen (ausgenommen hiervon ist jedoch das Erstellen anderer Organisationseinheiten). Dabei besteht das zusätzliche Risiko, dass Objekte erstellt werden, die von Benutzern auf niedrigeren Berechtigungsebenen nicht verwaltet werden können.
Tier3-Admins: Viele Organisationen verfügen über einen zentralisierten Helpdesk oder einen Helpdesk auf höherer Berechtigungsebene. Diese Rolle erstellt die Liste der Datenadministratoren und bildet somit eine Datenadministratorgruppe, die über allen Regionaladminstratoren angeordnet ist. Rechte werden an diese Gruppen nicht speziell innerhalb des Verzeichnisses delegiert. Stattdessen werden die Rechte über verschachtelte Mitgliedschaft in den einzelnen Regionaladministratorgruppen vergeben. Dies stellt einen Punkt auf höchster Ebene für die Rechteerweiterung für alle Datenadministratoren sowie einen Grenzübergang für Belange dar, die auf die Gruppen der Dienstverwaltung ausgeweitet werden müssen.

Erstellen eines Modells der Organisationseinheit und Sicherheitsgruppen
Nachdem die Rollen in der Organisation festgelegt sind, muss ein Modell der Organisationseinheit und Sicherheitsgruppen definiert werden. Es gibt zwei wichtige Gründe, eine Organisationseinheit in Active Directory zu erstellen: Zum Delegieren von Rechten und zum Einrichten eines Punkts, an dem Gruppenrichtlinienobjekte verknüpft werden können. Organisationseinheiten definieren einen Verwaltungsbereich (Scope of Management, SOM) innerhalb des Verzeichnisses, und dieser kann zum Einschränken von Rechten über Objekte auf verschiedenen Ebenen genutzt werden. Demzufolge sollte die Art und Weise der Delegierung von Befugnissen einer der wichtigsten Faktoren bei der der Implementierung der Struktur der Organisationseinheit sein.
Auf der Grundlage dessen sollte eine Organisationseinheit (oder eine Reihe von Organisationseinheiten) auf der obersten Ebene direkt unter der Domäne erstellt werden, um alle Objekte aufzunehmen. Diese Organisationseinheit dient dem speziellen Zweck der Definition des Verwaltungsbereichs für die Tier4-Administratoren. Durch das Erstellen einer Organisationseinheit auf höchster Ebene können Rechte über den Verzeichnisdienst explizit erst ab der Ebene der Organisationseinheit vergeben werden, anstatt bereits auf Domänenebene. Das Delegieren von einer Organisationseinheit der höchsten Ebene aus anstatt von der Domäne verringert das Risiko, das besteht, wenn Benutzer Berechtigungen durch Ändern der bereits erwähnten Standarddomänengruppen erweitern können.
Unter den Organisationseinheiten der höchsten Ebene sollten Sie separate Organisationseinheiten erstellen, um jede einzelne Region bzw. jeden einzelnen Geschäftsbereich darzustellen, die bzw. der über eigene Teams für die Datenverwaltung verfügt. Jede regionale untergeordnete Organisationseinheit sollte über eine gemeinsame, nicht erweiterbare Hierarchie der Organisationseinheiten für die Verwaltung der Verzeichnisobjekte verfügen. Einheitlichkeit ist für die alltägliche Verwaltung wichtig, da ein großer Umfang der Delegierung von Rechten automatisiert wird. Dies ist unter Umständen nicht einfach zu verwirklichen, da jede Region möglicherweise über eindeutige Organisationseinheiten verfügen möchte. IT-Administratoren sollten sich jedoch an die Vorgabe halten, und wenn eine Erweiterung für eine einzelne Region erforderlich ist, sollte die Struktur der untergeordneten Organisationseinheiten für alle Regionen erweitert werden. Dies mag anfänglich recht mühsam erscheinen, aber wenn die Organisation einen allgemeinen Speicherort für Objekte bereitstellt, werden die Ausnahmesituationen im Laufe der Zeit immer seltener auftreten.
Erstellen Sie zum Abschluss separate Gruppen und Konten für untergeordnete Administratoren, um Administratoren die Möglichkeit zum Erweitern ihrer Rechte zu nehmen: jeweils eine Gruppe von Tier1-Administratoren, Tier2-Administratoren und Regionaladministratoren für jede Hierarchie einer untergeordneten Organisationseinheiten. Das Platzieren dieser Konten in separate Organisationseinheiten ermöglicht die Einschränkung der Verwaltungsrechte auf die jeweilige Ebene oder die darunter liegende Ebene. Wenn alle Konten für Tier1-Administratoren und die zugeordnete Sicherheitsgruppe in einer Organisationseinheit untergebracht sind, in der sie über keine Rechte verfügen, sind Administratoren daher nicht in der Lage, die Kontrolle über andere Administratorkonten zu übernehmen oder die Berechtigungen anderer Administratoren auf ihre Ebene zu erweitern. Jedes Mitglied der Gruppe „Domänen-Admins“ kann z. B. jedes andere Benutzerkonto in der Domäne als Domänenadministrator einrichten. Mit dem vorliegenden Modell der Organisationseinheiten verringert sich dieses Risiko. Ein Beispiel für eine Organisationseinheitsstruktur mit zugeordneten Sicherheitsgruppen ist in Abbildung 2 dargestellt.
Abbildung 2 Organisationseinheitsstruktur mit zugeordneten Sicherheitsgruppen
Abbildung 2 Organisationseinheitsstruktur mit zugeordneten Sicherheitsgruppen

Einrichten sekundärer Konten
Der Schlüssel zu einem erfolgreichen Delegierungsmodell besteht im Durchsetzen des Prinzips der geringsten Rechte. In der Praxis bedeutet dies, dass ein Sicherheitsprinzipal ausschließlich die Möglichkeit zum Ausführen von Aufgaben haben sollte, die für die ihm zugewiesene Rolle erforderlich sind. Leider verwenden viele IT-Administratoren den gleichen Sicherheitsprinzipal für die Verzeichnisverwaltung und für alltägliche Aufgaben wie Webbrowsing und das Lesen von E-Mails. Durch das Einrichten separater Konten verringert sich die Wahrscheinlichkeit, dass ein Administrator einer niedrigeren Schicht versehentlich den Verzeichnisdienst beschädigt oder Opfer eines Angriffs wird, der über alltägliche Anwendungen erfolgt, jedoch auf den Verzeichnisadministrator abzielt.
Um dies zu erreichen, ohne dass sich der Benutzer abmelden und erneut anmelden muss, verwenden Sie den Dienst „Sekundäre Anmeldung“ (Runas.exe). Dies ermöglicht Benutzern, ihre Berechtigungen durch Bereitstellen eines anderen Satzes an Anmeldeinformationen beim Ausführen von Skripts oder EXE-Dateien auf Servern und Arbeitsstationen heraufzusetzen.
Obwohl das Konzept der Konten mit geringsten Rechten verhältnismäßig einfach ist, finden Organisationen die Durchsetzung in manchen Fällen schwierig, da bestimmte Gewohnheiten möglicherweise schwer zu ändern sind. Eine einfache Lösung zu verhindern, dass Konten mit hohen Berechtigungen für alltägliche Aufgaben verwendet werden, besteht darin, diesen Konten keinen Mailzugriff in Exchange Server zur Verfügung zu stellen. Dies kann durch administrative Richtlinien innerhalb der Organisation erreicht werden. Diese verhältnismäßig einfache Lösung verringert die Wahrscheinlichkeit, dass die Konten für alltägliche, nichtadministrative Aufgaben verwendet werden, erheblich.

Delegieren von Rechten
Der letzte Schritt bei der Entwicklung eines Delegierungsmodells besteht in der Delegierung von Rechten in Active Directory. Hierzu ist das Bearbeiten von Zugriffssteuerungseinträgen (Access Control Entries, ACEs) und Zugriffssteuerungslisten (Access Control Lists, ACLs) von Daten erforderlich, die innerhalb des Verzeichnisses gespeichert sind. ACLs für Active Directory-Container definieren, welche Objekte erstellt werden können und wie die Objekte verwaltet werden. Die Delegierung von Rechten beinhaltet grundlegende Bearbeitungsvorgänge für Objekte, wie z. B. die Möglichkeit, ein Objekt anzuzeigen, ein untergeordnetes Objekt einer Klasse zu erzeugen oder Attribut- und Sicherheitsinformationen über Objekte einer Klasse zu lesen. Neben diesen grundlegenden Vorgängen definiert Active Directory „Erweiterte Rechte“, die Vorgänge wie z. B. „Senden als“ und „Replikationstopologie verwalten“ ermöglichen.
In den vorherigen Schritten wurde das Erstellen von Sicherheitsgruppen behandelt, die definierten organisatorischen Rollen zugeordnet sind. Dies bedeutet, dass durch die Struktur der untergeordneten Organisationseinheiten eine zugeordnete Sicherheitsgruppe für jede Rolle vorhanden ist. Um das Delegierungsmodell zu implementieren, müssen diesen Gruppen Berechtigungen für die Objekte im Verzeichnis zugewiesen werden. An dieser Stelle geht es nicht darum, ein komplett neues Verfahren anzuwenden und eine hochspezielle Umgebung einzurichten. Versuchen Sie stattdessen, Standardgruppen und -rechte nach Möglichkeit wirksam einzusetzen. Angenommen, eine spezielle Rolle muss DNS-Einträge für die Gesamtstruktur verwalten. Versuchen Sie nicht, Rechte für die Container und die Namenskontexte bezüglich des in Active Directory integrierten DNS zu delegieren. Setzen Sie stattdessen einfach die Gruppe „BUILTIN\DNS-Admins“ wirksam in der Domäne ein. Außerdem können Benutzerrechte und andere Berechtigungen über die Funktion „Gruppenrichtlinie“ erweitert werden, um zusätzliche Rechte bereitzustellen, die zum Verwalten einer bestimmten Klasse des Systems durch eine vorgegebene Rolle benötigt werden.
Wenn Sie Berechtigungen mithilfe der Delegierung zuweisen, sollten Sie die Verwendung von Verweigern-ACEs innerhalb des Verzeichnisses einschränken oder komplett ausschließen. Dies könnte schwierig werden, wenn eine Problembehandlung notwendig wird. Eine bessere Lösung besteht darin, mithilfe von expliziten Zulassen-ACEs den speziellen Gruppen, die Ihre Rollen darstellen, Rechte zu gewähren. Denken Sie daran, dass benutzerdefinierte Rollen wie z. B. Tier4-Administratoren nur über die expliziten Rechte verfügen, die durch diese Rolle definiert sind.
Die Vererbung ist für die Active Directory-Sicherheit von entscheidender Bedeutung und definiert, wie eine bestimmte ACL für untergeordnete Objekte in einem Container oder untergeordneten Container angewendet wird. Geben Sie die Reichweite der Vererbung immer genau vor, indem Sie sicherstellen, dass vererbbare ACEs so genau wie möglich auf die Zielobjekte angewendet werden. Vererbbare Verweigerungsberechtigungen, die für das übergeordnete Objekt gelten, haben Vorrang vor allen vererbbaren Verweigerungsberechtigungen, die auf das dem übergeordneten Objekt übergeordnete Objekt angewendet werden. Dies ist einer der Hauptgründe, warum Verweigern-ACEs für eine brauchbare Delegierung nicht empfohlen werden. Darüber hinaus können vererbbare Berechtigungen keinen expliziten ACE für ein Objekt überschreiben. Aus diesem Grund wird empfohlen, dass Sie die Möglichkeit für untergeordnete Administratoren, Änderungen an der DACL (Discretionary Access Control List, freigegebene Zugriffssteuerungsliste) (durch Entfernen der Berechtigung „Write DACL“) für Verzeichnisobjekte vorzunehmen, einschränken oder ganz ausschließen. (Beachten Sie, dass der Ersteller des Objekts implizit über diese Rechte verfügt.) Grundsätzlich gilt, dass Administratoren, welche die Möglichkeit haben, die DACL für ein Objekt zu ändern, dies wahrscheinlich auch ausführen werden. Sorgen Sie dafür, dass die Arbeit und Mühe, die Ihre Organisation auf das Delegierungsmodell verwendet hat, nicht zunichte gemacht wird, indem Sie Raum für Beliebigkeiten und potenzielle administrative Fehler lassen.
Es gibt eine Anzahl an Tools, die Sie für das ordnungsgemäße Implementieren eines Active Directory-Delegierungsmodells benötigen werden. Für die meisten großen Organisationen ist die Verwendung des integrierten Delegierungsassistenten zum Zuweisen von Berechtigungen im Verzeichnis eine schwierige Aufgabe, die viele Möglichkeiten für administrative Fehler bietet. Stattdessen sollte immer durch Automatisierung sichergestellt werden, dass das Delegierungsmodell gut dokumentiert ist, dass es supportfähig ist und dass es eine Wiederherstellungsoption bietet, falls Einstellungen verloren gehen oder versehentlich geändert werden.
Das wichtigste Tool, das für das Implementieren der Delegierung benötigt wird, ist DSACLS.EXE, ein Befehlszeilenprogramm zum Bearbeiten von Verzeichnisdienst-ACLs für Objekte. Dieses Tool ermöglicht auch das Vorgeben von Vererbungskennzeichen für eine DACL, die im übergeordneten Objekt angegeben wird. (Zu den Vererbungskennzeichen gehören „this object and sub-objects“ (dieses Objekt und untergeordnete Objekte), „sub-objects only“ (nur untergeordnete Objekte) und „propagate inheritable permissions one level only“ (vererbbare Berechtigungen nur an eine Ebene übermitteln).) DSACLS-Befehle schlagen fehl, wenn ein Vererbungskennzeichen nicht richtig festgelegt ist. Deshalb ist ein Test beim Verwenden dieses Tools unumgänglich. Im Folgenden ist Beispiel der DSACLS-Syntax zum Delegieren der Möglichkeit, Computerobjekte in der Ziel-Beispielorganisationseinheit zu erstellen:
dsacls.exe ou=demo,dc=contoso,dc=com /I:T /G contoso\dataadmin:CC;computer
DSACLS unterscheidet zwischen Groß- und Kleinschreibung bei Objekttypen. Das bedeutet, dass der Versuch, Berechtigungen für die Objektklasse „cn=Computer“ durch Eingabe von „cn=computer“ zu delegieren, nicht fehlschlagen wird (siehe Abbildung 3).
Abbildung 3 Fehler aufgrund der Groß-/Kleinschreibung
Abbildung 3 Fehler aufgrund der Groß-/Kleinschreibung (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 3 Fehler aufgrund der Groß-/Kleinschreibung
Abbildung 3 Fehler aufgrund der Groß-/Kleinschreibung (Klicken Sie zum Vergrößern auf das Bild)
Für das Erstellen einiger Objekte ist ein bestimmter Satz an Rechten erforderlich. Dies ist auf die Attribute „muss enthalten“ und „kann enthalten“ von Objekten zurückzuführen. Die beste Metapher, die ich zur Verdeutlichung dieses Konzepts gehört habe, ist das Hamburgermodell. Hamburger müssen eine Frikadelle und ein Brötchen haben, um als Hamburger zu gelten. Dies sind die Attribute „muss enthalten der Objektklasse „Hamburger“. Elemente wie z. B. Pickles, Ketchup, Salat usw.sind Attribute „kann enthalten“. Wenn wir die Objektklasse erweitern, um einen Cheeseburger zu definieren, würden wir Käse in die Liste der Attribute „muss enthalten“ einfügen.
Benutzerobjekte funktionieren auf gleiche Weise. Nehmen wir an, dass wir uns an dieses Modell halten müssen, um mithilfe der folgenden DSACLS-Syntax Benutzerobjekte zu erstellen:
dsacls ou=demo,dc=contoso,dc=com /I:T /G contoso\demodata:CC;user
Der Administrator würde während des Anlegens des Benutzerobjekts mit mehreren Fehlern konfrontiert werden. Wir müssen die notwendigen Berechtigungen gewähren, um erforderliche Attribute für das Benutzerobjekt festzulegen, einschließlich Festlegen des Kennworts. Dies wird in der folgenden zusätzlichen DSACLS-Syntax realisiert.
Im ersten Schritt gewähren Sie die Berechtigung, „muss enthalten“-Attribute zu schreiben, indem Sie „Generic Read/Generic Write“ für alle Attribute der Benutzerklasse zulassen:
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:GRGW;;user
Im nächsten Schritt gewähren Sie das erweiterte Recht, das Kennwort zu ändern:
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:CA;"Reset Password";user
Im letzten Schritt gewähren Sie die Berechtigungen „Read Property“ und „Write Property“ für das Attribut „Password Last Set“:
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;pwdLastSet;user
Nachdem die entsprechenden Rechte delegiert wurden, werden die definierten Rollen auf das Verwalten von Objektklassen, die in der DACL des Containers definiert sind, eingeschränkt. Wenn wir bei dem oben erwähnten Beispiel eines Computerobjekts bleiben, schränkt das Kontextmenü in Active Directory-Benutzer und -Computer die Liste neuer Objekte ein, die von einem Benutzer erzeugt werden können, an den derartige Rechte delegiert wurden (siehe die eingeschränkte Liste in Abbildung 4).
Abbildung 4 Eingeschränkte Liste neuer Objekte
Abbildung 4 Eingeschränkte Liste neuer Objekte
DSACLS kann auch so eingerichtet werden, dass eine komplexe Bereitstellung von Rechten automatisch erfolgen kann. Hier sind einige der DSACLS-Befehle, mit denen Sie Rechte delegieren können, um gemeinsame Adressattribute von Benutzerobjekten in einem gegebenen Container zu ändern:
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;c;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;co;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;l;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postalCode;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postOfficeBox;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;st;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;streetAddress;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;telephoneNumber;user
Beispiele wie diese treten bei den meisten Delegierungsmodellen auf und können in Verbindung mit den zuvor definierten Rollen verwendet werden.
Ein anderes Tool, das für das Implementieren von Delegierung verwendet wird, ist DSREVOKE.EXE. Mit diesem Tool können Administratoren delegierte Rechte für bestimmte Sicherheitsprinzipale von Objekten innerhalb des Verzeichnisses ermitteln und entfernen. Obwohl es sich um ein sehr hilfreiches Tool handelt, bezieht es sich auf einen Sicherheitsprinzipal und bewertet nicht geschachtelte Mitgliedschaften innerhalb von Sicherheitsgruppen.
Außer diesen Befehlszeilenprogrammen empfehlen wir unbedingt auch die Verwendung von „Zuweisen von Benutzerrechten“ und „Eingeschränkte Gruppen“ mit Gruppenrichtlinien. Wie bereits weiter oben besprochen, ermöglicht „Zuweisen von Benutzerrechten“ IT-Administratoren untergeordnete Rechte (wie z. B. das Recht, auf ein System von einem Remotestandort aus zuzugreifen und es neu zu starten) für verschiedene Gruppen von Benutzern auf vorgegebenen Zielsystemen auszudehnen oder zu entfernen. Mithilfe eingeschränkter Gruppen können Mitgliedschaften in lokalen Gruppen und Domänengruppen innerhalb der Gesamtstruktur vorgegeben und durchgesetzt werden. In Kombination stellen diese Tools alles bereit, was Sie für die Automatisierung und das Implementieren eines Delegierungsmodells für Active Directory benötigen.

Zusammenfassung
Obwohl die Aufgabe, ein Active Directory-Delegierungsmodell zu entwickeln, komplex erscheinen mag, können in Wahrheit für die meisten IT-Infrastrukturen sehr einfache Modelle verwendet werden. Einer der wichtigsten Schritte beim Bereitstellen eines funktionierenden Delegierungsmodells besteht im Definieren klarer Rollen. Sie sollten die definierten Rollen auf eine kleine, überschaubare Anzahl beschränken. Es ist nicht einfach, die optimale Anzahl zu finden. Zu viele Rollen führen zu Rollen, die nie genutzt werden, zu wenige Rollen hingegen ergeben keine ausreichende Trennung von Rollen.
Denken Sie beim Definieren von Aufgaben daran, diese nach Häufigkeit, Wichtigkeit und Schwierigkeitsgrad zu klassifizieren. Nachdem Sie die Rollen definiert haben, entwickeln Sie einen Satz von Anwendungsfällen. Dadurch können Sie besser erkennen, was jede Rolle kann oder nicht kann, und der Prüfungsprozess kann einfacher automatisiert werden. Gut vorbereitete Anwendungsfälle werden Ihnen helfen, diese Rollen den Interessengruppen in der Organisation zu erklären und das Auftreten von Überraschungen aufgrund von Fehlern bei der Automatisierung zu vermeiden.
Schließlich ist beim Entwickeln eines Delegierungsmodells ein praktischer Ansatz immer eine gute Idee. Denken Sie daran: Einfachheit ist gleichbedeutend mit Unterstützbarkeit, und ein tragfähiges Delegierungsmodell wird sich beim Kontrollieren von Administratorrechten innerhalb Ihrer Active Directory-Umgebung durch gewaltige Nutzeffekte auszahlen.
Weitere Ressourcen
  • Design Considerations for Delegation of Administration in Active Directory (auf Englisch)
  • Best Practices for Delegating Active Directory Administration (auf Englisch)

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


 Windows-Verwaltung: Neue Gruppenrichtlinienvorlagen in Windows Vista
Windows-Verwaltung Darren Mar-Elia

Neue Gruppenrichtlinienvorlagen in Windows Vista
Kurz zusammengefasst:
  • Einblicke in ADMX-Dateien
  • Bearbeiten von ADMX-Dateien
  • Unterschied zwischen ADM- und ADMX-Dateien
  • Erstellen eines zentralen Speichers

Vor Windows Vista wurden die Registrierungswerte, die Sie innerhalb der Gruppenrichtlinien festlegen konnten, von ADM-Dateien mit einer komplizierten und proprietären Syntax gesteuert. Wenn Sie andere als die von Microsoft mit den standardmäßigen ADM-Dateien bereitgestellten Registrierungswerte steuern wollten, mussten Sie sich diese
Syntax aneignen und eine benutzerdefinierte ADM-Datei erstellen. Außerdem wurden diese ADM-Dateien mit jedem Gruppenrichtlinienobjekt (GPO) in Ihrer Active Directory®-Umgebung gespeichert, und jedes dieser GPOs wurde mit den zugehörigen ADM-Dateien in allen Domänencontrollern in der Domäne repliziert.
Mit der Veröffentlichung von Windows Vista™ hat Microsoft im Bereich gruppenrichtlinienbasierter Registrierungsvorlagen einen großen Schritt nach vorn gemacht. Windows Vista führt bedeutende Änderungen am Format der ADM-Datei (jetzt: ADMX) und an der Speichermethode dieser Dateien ein. In diesem Artikel werden wir uns das neue ADMX-Format genauer ansehen und herausarbeiten, wie sich diese Dateien vom ADM-Format unterscheiden. Darüber hinaus werde ich Ihnen zeigen, wie diese Dateien in einer Windows Vista-Umgebung gespeichert werden.

Unterschiede bei ADMX
Der größte Unterschied zwischen dem neuen ADMX-Dateiformat und dem alten ADM-Format, das es schon seit Windows NT® 4.0 gibt, ist, dass ADMX den XML-Standard für das Beschreiben der Einstellungen von Registrierungsrichtlinien übernommen hat. Das hat mehrere Vorteile. Der erste ist, dass es viel mehr Tools zum Bearbeiten von XML als für die ADM-Syntax gibt. Der zweite: Durch den schematisierten Aufbau von XML wird später die Programmierung von Tools erleichtert, die Ihnen dabei helfen, die richtigen Tags an den richtigen Positionen zu platzieren, um eine strukturierte ADMX-Datei zu erstellen. „Schematisiert“ bedeutet in diesem Zusammenhang, dass es für eine gegebene XML-Anwendung, wie z. B. das ADMX-Format, ein dokumentiertes Schema existiert, das mögliche Elemente und Attribute und deren Organisation beschreibt. Wir werden uns später in diesem Artikel ein Beispiel dazu anschauen.
Der andere wichtige Unterschied zwischen ADMX und ADM ist die Abtrennung des Zeichenfolgenabschnitts aus der Haupt-ADMX-Datei in eine sprachspezifische ADML-Datei. Wer sich mit ADM-Dateien auskennt, weiß, dass es am Ende jeder Datei einen Abschnitt gibt, der durch ein „[strings]“-Tag abgegrenzt wird, in dem Sie Textzeichenfolgen Werte zuweisen können, die angezeigt werden, wenn der Gruppenrichtlinien-Editor und administrative Vorlagen zum Einsatz kommen. Der Text z. B., der nach dem Klicken auf die Registerkarte „Erklärung“ für eine bestimmte Richtlinie angezeigt wurde, ist in diesem Zeichenfolgenabschnitt gespeichert. Das Problem dabei ist, dass die Zeichenfolgen in der ADM-Datei gespeichert wurden. Wenn Sie also ADM auf einem Windows®-System verwenden wollen, auf dem eine andere Sprache ausgeführt wird, müssen Sie eine neue ADM-Datei mit einem Zeichenfolgenabschnitt für diese Sprache erstellen.
Noch kompliziert wird es, wenn jemand, der beispielsweise die französische Version von Windows benutzt, ein vorhandenes GPO bearbeiten möchte, bei dem englische ADM-Dateien verwendet wurden. Der französische Administrator würde nur Englisch im Gruppenrichtlinien-Editor sehen. Windows Vista umgeht dieses Problem durch die Abtrennung des [Strings]-Abschnitts in eine XML-basierten ADM Language- (oder ADML-) Datei. Die ADML-Datei kann in einer beliebigen unterstützten Sprache geliefert werden. Diese Sprache lässt sich jederzeit ändern, ohne die Haupt-ADMX-Datei zu ändern, die die Richtlinien speichert. Was noch wichtiger ist: Wenn der französische Administrator ein GPO auf seiner Windows Vista-Arbeitsstation bearbeitet, erkennt der Gruppenrichtlinien-Editor, dass die französische Version von Windows verwendet wird, und lädt automatisch die französischen ADML-Dateien für das GPO.
Sie können sich alle ADMX- und ADML-Dateien ansehen, die mit Ihrer Installation von Windows Vista geliefert werden, indem Sie den Ordner „c:\Windows\policydefinitions“ öffnen (siehe Abbildung 1).
Abbildung 1 ADMX-Dateien in Windows Vista
Abbildung 1 ADMX-Dateien in Windows Vista (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 1 ADMX-Dateien in Windows Vista
Abbildung 1 ADMX-Dateien in Windows Vista (Klicken Sie zum Vergrößern auf das Bild)
Hinweis: Oben in der Dateiliste in Abbildung 1 befindet sich ein Ordner namens „en-us“. Dies ist der sprachspezifische Ordner, der die ADML-Dateien für die ADMX-Dateien enthält, die Sie in diesem Ordner mit den Richtliniendefinitionen sehen – in diesem Fall für Englisch (USA). Es gibt eine ADML-Datei für jede ADMX-Datei. Bei der Veröffentlichung dieses Artikels enthielt Windows Vista standardmäßig 132 ADMX/ADML-Dateien. Dies ist ein weiterer wichtiger Unterschied zwischen Windows Vista und früheren Versionen: Unter Windows XP erstellte GPOs enthielten normalerweise fünf ADM-Dateien, von denen die größte die Datei „System.adm“ war, und in der sich die Richtlinienelemente für die meisten Windows-Komponenten unter Richtlinienkontrolle befanden. Bei Windows Vista hat Microsoft entschieden, die ADMX-Dateien nach Funktion zu trennen. Daher rührt die viel größere Anzahl der ADMX-Dateien. Jede ADMX-Datei deckt in der Regel eine Windows-Komponente (wie z. B. Systemsteuerung, DNS-Client, Windows-Explorer usw.) ab.

Einblick in ADMX-Dateien
Dass ADMX-Dateien in XML geschrieben werden, ist, wie ich bereits anmerkte, eine bedeutende Verbesserung. Leider beherrschen viele Administratoren XML jedoch nicht, geschweige denn, dass sie das Schema verstünden, das von ADMX für das Erstellen von Richtlinienerweiterungen verwendet wird. Eine Einführung in die Erstellung benutzerdefinierter ADMX-Dateien würde den Rahmen dieses Artikels sprengen. Wir wollen uns stattdessen darauf konzentrieren, wie ADMX-Dateien gebildet werden.
Sie können eine ADMX- oder ADML-Datei in einem beliebigen Texteditor (sogar in Editor) öffnen, aber er muss die XML-Syntax verstehen, sonst ergibt das Ganze nicht viel Sinn. Ich verwende Visual Studio®, da das darin enthaltene IntelliSense®-Feature mir beim Vervollständigen bestimmter Elemente hilft. Abbildung 2 stellt die ersten Zeilen einer der ADMX-Dateien dar, die mit Windows Vista ausgeliefert werden.
Figure 2 Ein wenig XML in einer ADMX-Datei (Close Figure 2)
<?xml version="1.0" encoding="utf-8"?>
<policyDefinitions xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" revision="0.9" schemaVersion="0.9"
  xmlns="http://www.microsoft.com/GroupPolicy/PolicyDefinitions">
  <policyNamespaces>
    <target prefix="AxInstSv" namespace="Microsoft.Policies.ActiveXInstallService" />
    <using prefix="windows" namespace="Microsoft.Policies.Windows" />
  </policyNamespaces>
Wenn Sie mit XML nicht vertraut sind, mag das komisch aussehen, aber viele dieser XML-Elemente sind in jeder ADMX-Datei enthalten. Das policyNamespaces-Element versieht z. B. diese ADMX-Datei innerhalb der Menge aller ADMX-Dateien mit einer individuellen Kennung.
Wenn Sie benutzerdefinierte ADM-Dateien in früheren Windows-Versionen erstellt haben, wissen Sie, dass es dort einen Tag-Satz gab, wie z. B. „Category“, „Policy“, „ListBox“ und „ActionList“, mit dem die Richtlinieneinstellungen definiert wurden, die im Gruppenrichtlinien-Editor erscheinen sollten. Viele dieser Tags sind immer noch dieselben, oder es wurde nur etwas an ihrem ADMX-Format geändert, aber sie sehen jetzt ganz anders aus, weil sie in XML dargestellt werden. Ich habe z. B. eine benutzerdefinierte ADM-Datei geschrieben, die es mir ermöglichte, verschiedene Protokollierungstypen unter Windows zur Fehlerbehebung bei Gruppenrichtlinien einzusetzen. Einen Abschnitt dieser benutzerdefinierten ADM-Datei sehen Sie in Abbildung 3. Ich habe diese Datei in das neue ADMX-Format überführt (siehe Abbildung 4).
Figure 4 Die in eine ADMX-Datei konvertierte ADM-Datei (Close Figure 4)
<policy name="Folder Redirection Logging" class="Machine" displayName="$(string.FolderRedirLogging)" explainText="$(string.FolderRedirLogging_Help)" key="Software\Microsoft\Windows NT\CurrentVersion\Diagnostics" valueName="FDeployDebugLevel">
      <parentCategory ref="PolicyLogging" />
      <supportedOn ref="windows:SUPPORTED_Win2K"/>
      <enabledValue>
        <decimal value="15"/>
      </enabledValue>
      <disabledValue>
        <decimal value="0" />
      </disabledValue>
    </policy>
Figure 3 Eine benutzerdefinierte ADM-Datei (Close Figure 3)
CLASS MACHINE
  CATEGORY !!System
    CATEGORY !!GroupPolicy
    CATEGORY !!Logging
POLICY !!FolderRedir
EXPLAIN !!FolderRedir_HELP
KEYNAME "Software\Microsoft\Windows NT\CurrentVersion\Diagnostics"
VALUENAME "FDeployDebugLevel"
VALUEON NUMERIC 15
VALUEOFF NUMERIC 0
END POLICY ;FolderRedir
      END CATEGORY ;Logging
   END CATEGORY ;GroupPolicy
 END CATEGORY ;SYSTEM
In vielerlei Hinsicht ist dieser ADMX-Abschnitt viel einfacher zu verstehen als die ADM-Version, weil er kurz und bündig ist. Das Richtlinienelement gibt an, was diese Richtlinie zu tun hat (Protokollierung von Ordnerumleitungen). Die Attribute, denen „$(string.“ vorangeht, sind Verweise zum entsprechenden ADML-Zeichenfolgenelement. Die Attribute „key“ und „valuename“ geben an, welcher Registrierungsschlüssel und welcher Wert von dieser Richtlinie betroffen sind. Das parentCategory-Element legt fest, an welcher Stelle die Richtlinie in der Hierarchie der administrativen Vorlage des Gruppenrichtlinien-Editors erscheint. Das supportedOn-Element gibt an, von welcher Betriebssystemversion diese Richtlinie zu beachten ist. Die Elemente „enabledvalue“ und „disabledvalue“ legen fest, welche Werte in die Registrierung geschrieben werden, sobald diese Richtlinie aktiv bzw. inaktiv ist.
Dies ist eine ziemlich einfache Richtlinie mit Ein/Aus-Schalter. Wie bei der ADM-Syntax ist es auch hier möglich, komplexere UI-Elemente innerhalb des Gruppenrichtlinien-Editors zu erstellen. Wenn man das in ADMX machen möchte, wird die Syntax etwas komplizierter und enthält ein Präsentationsattribut, das auf einen Teil der ADML-Datei verweist, in dem sich die Beschriftungen der UI befinden. Ansonsten ist die ADMX-Syntax nicht wesentlich komplizierter. Man sollte allerdings stets bedenken, dass einige ADM-Tagnamen in ADMX anders heißen. In ADM heißt es z. B. „edittext“ und „listbox“. In ADMX werden diese Tags in der ADMX-Datei als „text“ und „list“ bezeichnet. Für diese Elemente werden entsprechende Einträge in der ADML-Datei vorgenommen, die den Text angeben, der neben ihnen angezeigt wird.
Wie Sie vielleicht bereits wissen, können Administratoren eine benutzerdefinierte (Legacy-)ADM-Datei in den Gruppenrichtlinienobjekt-Editor von Windows Vista laden. Ich werde oft gefragt, ob Microsoft ein Dienstprogramm zum Konvertieren benutzerdefinierter ADM-Dateien in die ADMX-Syntax bereitstellen wird. Tatsächlich wird Microsoft zusammen mit FullArmor Corp. ein kostenloses Tool (ADMX Migrator) auf den Markt bringen. Dieses Tool kann zweierlei. Zuerst einmal konvertiert es Ihre alten benutzerdefinierten ADM-Dateien in das ADMX-Format (siehe Abbildung 5 für ein Beispiel für den Einsatz des Tools, wobei meine Datei „gpolog.adm“ entsprechend bearbeitet wird).
Abbildung 5 ADMX Migrator
Abbildung 5 ADMX Migrator (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 5 ADMX Migrator
Abbildung 5 ADMX Migrator (Klicken Sie zum Vergrößern auf das Bild)
Zum anderen enthält es einen ADMX-Editor, mit dem Sie ganz neue ADMX-Dateien erstellen können. Dieses Tool steht Ihnen unter go.microsoft.com/fwlink/?LinkID=77409 zum Download zur Verfügung.

ADMX-Speicherung
Die andere wichtige Änderung, die ich hier besprechen möchte, ist die Methode, nach der ADMX- und ADML-Dateien für ihren Einsatz gespeichert werden. In Windows-Versionen vor Windows Vista wurden die ADM-Dateien beim Bearbeiten eines GPOs automatisch von der lokalen Arbeitsstation kopiert, auf der der SYSVOL-Abschnitt des GPOs auf einem Domänencontroller innerhalb Ihrer Active Directory-Domäne bearbeitet wurde. Diese ADM-Dateien wurden dann für jedes erstellte GPO an alle Domänencontroller einer Domäne repliziert. Dadurch wurden jede Menge Netzwerkbandbreite und Festplattenspeicher verschwendet, insbesondere in großen Umgebungen mit dutzenden oder hunderten von GPOs. Windows Vista kehrt diesen Prozess um. Wenn Sie ein Active Directory-basiertes GPO auf einer Windows Vista-Arbeitsstation erstellen, werden die Richtlinien für administrative Vorlagen, die im Gruppenrichtlinien-Editor zu sehen sind, standardmäßig auf dem Computer aus dem Verzeichnis „c:\Windows\policydefinitions“ geladen, auf dem Sie das GPO bearbeiten.
Die ADMX- und ADML-Dateien werden nicht auf SYSVOL kopiert. Auf sie wird nur lokal verwiesen. Die Anforderungen an Speicher- und Netzwerkkapazitäten, die ADM-Dateien an die Umgebung der Gruppenrichtlinie stellen, lassen sich auf diese Weise beseitigen. Es wird noch besser. Windows Vista unterstützt außerdem einen zentralen Speicher, der als Repository für administrative Vorlagen dient. Damit wird eine wirksame Kontrolle der ADMX-Dateien für die Bearbeitung der GPOs ermöglicht, und zwar unabhängig davon, wer das Bearbeiten durchführt. Das erreichen Sie, indem Sie alle offiziellen ADMX- und ADML-Dateien (und alle benutzerdefinierten Dateien dieser Typen, die Sie erstellt haben) an einen Netzwerkspeicherort kopieren. Das sich daran anschließende Bearbeiten der Gruppenrichtlinien von Windows Vista-Arbeitsstationen verweist auf diese netzwerkbasierten Versionen statt auf die jeweiligen lokalen Versionen. Das Einrichten eines zentralen Speichers ist recht einfach und wird nacheinander auf den einzelnen Domänen durchgeführt. Befolgen Sie dazu die Schritte in der Randleiste „Erstellen eines zentralen Speichers“.

Zusammenfassung
Das neue ADMX-Format von Windows Vista ist eine klare Verbesserung gegenüber ADM-Dateien, die mit früheren Betriebssystemversionen verwendet wurden. Der Einsatz von XML bietet einen besseren Rahmen für das Bearbeiten und Durchsuchen dieser Dateien. Das Verschieben sprachspezifischer Zeichenfolgen in getrennte Dateien ermöglicht das nahtlose Bearbeiten von Gruppenrichtlinien. Der zentrale Speicher macht das Speichern und Aktualisieren aller GPOs mit Kopien von ADM-Dateien überflüssig. All das macht das Erlernen von ADMX empfehlenswert.
Erstellen eines zentralen Speichers
Das Erstellen eines zentralen Speichers ist recht einfach. Folgen Sie diesen einfachen Schritten, um einen Speicher in Ihrer Active Directory-Domäne zu erstellen:
Schritt 1: Öffnen Sie den Explorer, und navigieren Sie zur SYSVOL-Freigabe auf dem PDC-Emulator-DC in Ihrer Umgebung. Sie können einen beliebigen DC verwenden, aber der Besitzer der PDC-Rolle befindet sich normalerweise dort, wo die Änderungen der Gruppenrichtlinie konzentriert sind.
Schritt 2: Öffnen Sie den Ordner mit den Richtlinien unter SYSVOL, und legen Sie ein neues Verzeichnis mit der Bezeichnung „PolicyDefinitions“ an.
Schritt 3: Kopieren Sie den Inhalt des Ordners „c:\Windows\policydefinitions“ auf Ihrer Windows Vista-Arbeitsstation in den neuen Ordner „PolicyDefinitions“, und vergessen Sie dabei nicht den sprachabhängigen ADML-Ordner (z. B. „en-us“ auf US-englischen Computern).
Nachdem die ADMX- und die ADML-Dateien in den zentralen Speicherordner kopiert worden sind, beginnt der Gruppenrichtlinienobjekt-Editor von Windows Vista damit, Verweise auf die dort befindlichen Dateien zu erstellen, und ignoriert solche, die lokal gespeichert sind.

Darren Mar-Elia ist Gruppenrichtlinien-MVP bei Microsoft, Entwickler der beliebten Gruppenrichtlinienwebsite www.gpoguy.com und Mitverfasser von „Microsoft Windows Group Policy Guide“ (Microsoft Press, 2005). Er ist auch CTO und Gründer von SDM Software, Inc. Sie erreichen ihn unter Darren@gpoguy.com.


 Windows-Verwaltung: Ihre Anleitung zur Problembehandlung von Gruppenrichtlinien
Windows-Verwaltung Derek Melber

Ihre Anleitung zur Problembehandlung von Gruppenrichtlinien
Kurz zusammengefasst:
  • Allgemeine GPO-Fragen
  • Gruppenrichtlinien
  • Problembehandlung von GPO-Problemen
  • Tools zur Problembehandlung

Microsoft Active Directory hat sich zu einer wichtigen Komponente vieler IT-Infrastrukturen entwickelt. Eines der wichtigsten Features von Active Directory sind Gruppenrichtlinien, die Administratoren ermöglichen, die Verwaltung der Domänencontroller, Mitgliedsserver und Desktops zu zentralisieren.
Obwohl Gruppenrichtlinien viele Vorteile bieten, haben sie einen kleinen Haken. In einer großen Organisation kann ihr Entwurf und ihre Implementierung zu einer komplexen Angelegenheit werden. Darüber hinaus gestaltet sich die Fehlerbehebung unter Umständen ausgesprochen problematisch. In diesem Artikel wird untersucht, wie Gruppenrichtlinien strukturiert sind und wie die Problembehandlung erfolgt. Das Ziel ist, Ihnen das Lösen von fast allen Problemen mit Gruppenrichtlinien zu ermöglichen.

Lästige Einstellungen
Es gibt viele bewegliche Teile innerhalb von Gruppenrichtlinien, besonders in Bezug auf die Weise, in der sie sich mit dem allgemeinen Design und der Implementierung von Active Directory® überschneiden. Beim Beheben verschiedener Arten von Zugriffs- und Netzwerkfehlern müssen Sie stets Active Directory und die Grundlagen der Gruppenrichtlinienimplementierung in Ihre Suche nach einer Lösung einschließen. Als Einstieg in die Problembehandlung werden zunächst die Gruppenrichtlinieneinstellungen untersucht, die falsch konfiguriert werden können. Anschließend werden kompliziertere Probleme behandelt, die eine Fehlfunktion der Gruppenrichtlinien verursachen können.
Gruppenrichtlinieneinstellungen werden von Active Directory-Administratoren mithilfe der Administrativvorlagendateien (ADM- oder ADMX-Dateien) und des Gruppenrichtlinienobjekt-Editors, auch GPEdit genannt (der beim Ausführen von gpedit.msc gestartet wird), angezeigt. Mithilfe von GPEdit erstellt der Administrator Gruppenrichtlinienobjekt-Dateien bzw. GPOs (Group Policy Objects, Gruppenrichtlinienobjekte). Die GPOs werden so konfiguriert, dass sie auf Computer und Benutzer innerhalb der Active Directory-Struktur angewendet werden können (oder auch nicht). Damit GPOs richtig funktionieren, gibt es eine Reihe von Regeln. Diese Regeln werden im Folgenden behandelt.
GPOs müssen verknüpft sein Wenn ein neues GPO erstellt wird, ist es unter Umständen nicht mit einem Knoten innerhalb von Active Directory verknüpft. Obwohl das GPO bearbeitet und geändert werden kann, hat es keine Auswirkung auf Objekte, bis es mit einem Knoten verknüpft ist. Um sicherzustellen, dass das GPO ordnungsgemäß verknüpft ist, können Sie das Informationsfenster in der Gruppenrichtlinien-Verwaltungskonsole (Group Policy Management Console, GPMC) anzeigen, die in Abbildung 1 dargestellt ist.
Abbildung 1 GPO-Links werden deutlich angezeigt
Abbildung 1 GPO-Links werden deutlich angezeigt (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 1 GPO-Links werden deutlich angezeigt
Abbildung 1 GPO-Links werden deutlich angezeigt (Klicken Sie zum Vergrößern auf das Bild)
GPOs müssen auf das korrekte Objekt abzielen Wie Sie wissen, müssen Gruppenrichtlinien auf die richtigen Objekte in Active Directory abzielen. Dies wird jedoch manchmal bei einer Übung zur Problembehandlung übersehen. Innerhalb eines GPO gibt es zwei Hauptkategorien: Computer und Benutzer. Merken Sie sich beim Konfigurieren eines GPO, ob es für ein Computer- oder Benutzerobjekt gedacht ist. Dann können Sie überprüfen, ob die richtigen Objekttypen in die Organisationseinheit (Organizational Unit, OU) gestellt werden, in der das GPO verknüpft ist.
GPOs werden nicht auf Gruppen angewendet Auch wenn es wünschenswert wäre, kann ein GPO nicht auf ein Active Directory-Sicherheitsgruppenobjekt angewendet werden. Die einzigen beiden Objekte, die durch eine GPO-Einstellung konfiguriert werden können, sind Computer und Benutzer. GPOs können Objekte nicht über eine Gruppenmitgliedschaft konfigurieren. Wenn zum Beispiel ein GPO vorhanden ist, das mit der Finanzorganisationseinheit verknüpft ist (wie in Abbildung 2 dargestellt), sind Derek und Frank die einzigen Objekte, die von dieser Einstellung betroffen werden. Die Einstellungen im GPO haben keine Auswirkung auf die Mitglieder der Marketinggruppe, unabhängig davon, wer zu dieser Gruppe gehört.
Abbildung 2 Finanzorganisationseinheit und die Objekte innerhalb dieser Einheit
Abbildung 2 Finanzorganisationseinheit und die Objekte innerhalb dieser Einheit (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 2 Finanzorganisationseinheit und die Objekte innerhalb dieser Einheit
Abbildung 2 Finanzorganisationseinheit und die Objekte innerhalb dieser Einheit (Klicken Sie zum Vergrößern auf das Bild)
Das Zielobjekt muss sich im Pfad des GPO befinden Wenn Sie feststellen, dass eine GPO-Einstellung nicht die erwarteten Auswirkungen auf ein Objekt hat, empfiehlt es sich, eine weitere wichtige Einstellung zu überprüfen: Das Objekt muss sich im Verwaltungsbereich (Scope of Management, SOM) des GPO befinden. Das heißt, dass sich das Objekt unter dem Knoten befinden muss, an dem das GPO verknüpft ist (auch ein untergeordneter Knoten ist ausreichend). Beispielsweise sind keine der Objekte in der Marketingorganisationseinheit von einem GPO betroffen, das mit der Finanzorganisationseinheit verknüpft ist, wie in Abbildung 3 dargestellt. Der Verwaltungsbereich eines GPO reicht vom Knoten, an dem es verknüpft ist, bis durch die unteren Ebenen der Active Directory-Struktur.
Abbildung 3 Wenn sich Organisationseinheiten auf derselben Ebene befinden, gelten GPOs nur für die Organisationseinheit, an der sie verknüpft sind
Abbildung 3 Wenn sich Organisationseinheiten auf derselben Ebene befinden, gelten GPOs nur für die Organisationseinheit, an der sie verknüpft sind (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 3 Wenn sich Organisationseinheiten auf derselben Ebene befinden, gelten GPOs nur für die Organisationseinheit, an der sie verknüpft sind
Abbildung 3 Wenn sich Organisationseinheiten auf derselben Ebene befinden, gelten GPOs nur für die Organisationseinheit, an der sie verknüpft sind (Klicken Sie zum Vergrößern auf das Bild)
GPOs müssen aktiviert sein Bei der Erstellung wird ein GPO nicht zum Ändern von Zielobjekten konfiguriert. Es wird jedoch sowohl für die Computer- als auch die Benutzeranteile aktiviert. Falls einer dieser Anteile deaktiviert ist, kann es schwierig sein, dies nachzuverfolgen. Daher empfiehlt sich die Überprüfung, ob einige oder alle GPOs deaktiviert sind, falls Sie ein Problem mit einem GPO beheben müssen, dessen Anwendung fehlschlägt. Wählen Sie hierzu in der GPMC „Gruppenrichtlinienobjekte“ | „Kontorichtlinie“ aus, und überprüfen Sie den GPO-Status.
Für einige Einstellungen ist ein Neustart erforderlich Wenn eine GPO-Einstellung nicht ordnungsgemäß funktioniert, kann es an der damit verbundenen Verarbeitung von GPOs liegen. Wenn die periodische Hintergrundaktualisierung von GPOs ausgelöst wird, können nicht alle, sondern nur einige der GPO-Einstellungen verarbeitet werden. Eine Einstellung wurde daher zwar erstellt, ist möglicherweise aber noch nicht wirksam. Einige Einstellungen werden als Vordergrundrichtlinien kategorisiert und nur angewendet, wenn der Computer neu gestartet wird oder der Benutzer sich abmeldet und anschließend neu anmeldet. Zu diesen Einstellungen zählen Softwareinstallationen, Ordnerumleitungen und Skriptanwendungen.

Synchrone und asynchrone Anwendung von Einstellungen
Innerhalb eines GPO können Sie konfigurieren, wie die Richtlinien bei Neustarts und Anmeldungen angewendet werden sollen. Die Änderungen, die Sie vornehmen können, bieten entweder sofortigen Zugriff auf den Desktop, während die Richtlinien angewendet werden, oder sie gewährleisten, dass alle Richtlinien angewendet werden, bevor der Benutzer Zugriff auf den Desktop erhält. Abbildung 4 zeigt das standardmäßige Verhalten der einzelnen Betriebssysteme. Wenn Sie dieses Verhalten anpassen möchten, können Sie die folgende Richtlinieneinstellung ändern:
Computer Configuration | Administrative Templates |
System | Logon | Always wait for the network at computer startup and logon
Figure 4 Standardverarbeitung auf dem Client (Close Figure 4)

Betriebssystem | Start | Anmeldung | Richtlinienaktualisierung
Windows 2000 | Synchron | Synchron | Asynchron
Windows XP Professional | Asynchron | Asynchron | Asynchron
Windows Server 2003 | Synchron | Synchron | Asynchron
Die meisten Administratoren bevorzugen eine synchrone Anwendung der Richtlinie, um sicherzustellen, dass alle Richtlinien angewendet werden, bevor der Benutzer auf den Desktop zugreifen kann. Dadurch wird gewährleistet, dass alle Sicherheits- und Konfigurationseinstellungen angewendet werden, bevor die Benutzer mit ihrer Arbeit beginnen. Beachten Sie, dass dies nicht der Standardmodus in Windows® XP Professional ist, da diese Version für eine erhöhte Anmeldegeschwindigkeit optimiert wurde.

Ändern der Standardvererbung
Es gibt vier verschiedene Methoden zum Ändern der Standardvererbung der GPO-Verarbeitung. Diese Optionen sind leistungsstark und sollten sparsam eingesetzt werden, da sie zu beachtlichen Veränderungen am Verhalten der Gruppenrichtlinienverarbeitung führen können. Außerdem kann die Problembehandlung für diese Optionen sehr schwierig sein. Die Optionen zum Ändern der Standardvererbung umfassen die folgenden vier Einstellungen und Konfigurationen:
  • Blockieren der Richtlinienvererbung
  • GPO-Durchsetzung
  • GPO-Filterung der Zugriffssteuerungsliste (ACL)
  • Filter der Windows-Verwaltungsinstrumentation (WMI)
Da diese sparsam eingesetzt werden sollten, ist es relativ einfach, ihre Verwendung zu dokumentieren. Mithilfe der GPMC können Sie herausfinden, ob diese Optionen verwendet werden. Die Blockvererbung wird an der Domäne oder dem Organisationseinheitsknoten in der GPMC durchgeführt. Die GPO-Durchsetzung, das Filtern der ACL und die WMI-Filterung werden auf jedem GPO festgelegt.
Alternativ dazu können Sie den Gpresult-Befehl vom Zielcomputer aus ausführen, um zu erfahren, ob eine dieser Einstellungen die Anwendung der Richtlinien verhindert. Wenn Sie eine detailliertere Ansicht des angewendeten Satzes von Richtlinien abrufen möchten, können Sie dem Gpresult-Befehl den /v-Schalter hinzufügen, um eine ausführliche Ausgabe zu erhalten.

ADM-Vorlagenprobleme
Wenn Sie versuchen, Einstellungen in einem GPO im Abschnitt „Administrative Vorlagen“ zu konfigurieren, arbeiten Sie mit ADM-Vorlagen. Zusätzlich zu ADM-Vorlagen, die mit dem Betriebssystem geliefert werden, können Sie Ihre eigene Vorlage für die Verwendung in einem GPO anpassen. Durch den Code in der ADM-Vorlage werden die Ordner und Richtlinien im Gruppenrichtlinien-Editor unter dem Knoten „Administrative Vorlagen“ erstellt. Falls die ADM-Vorlage jedoch fehlerhaft ist, fehlt oder nicht ordnungsgemäß konfiguriert wurde, werden wahrscheinlich nur einige oder keine der Einstellungen im Editor angezeigt. Beim Verwenden von ADM-Vorlagen können gegebenenfalls die im Folgenden beschriebenen Probleme auftreten.
Fehlende ADM-Vorlagen Wenn Sie ein GPO bearbeiten und feststellen, dass in einer benutzerdefinierten ADM-Vorlage Einstellungen vorhanden sind, die nicht im Editor angezeigt werden, müssen Sie die ADM-Vorlage in das GPO importieren. Klicken Sie dazu einfach mit der rechten Maustaste auf den Knoten „Administrative Vorlagen“ im Editor, und wählen Sie „Vorlagen hinzufügen/entfernen“ aus.
Fehlende Einstellungen Es gibt zwei Arten von Einstellungen, die in einem benutzerdefinierten GPO erstellt werden können: Einstellungen und Richtlinien. Richtlinien sind die Microsoft-Standardeinstellungen, die jeweils einem von vier Unterschlüsseln in der Registrierung zugeordnet sind und mit dem Text „Policies“ (Richtlinien) enden. Einstellungen sind Registrierungsänderungen im „alten Stil“, die nicht unter einen der vier Unterschlüssel fallen und nach ihrer Konfigurierung nur schwer rückgängig gemacht werden können. Standardmäßig werden diese Einstellungen im Editor nicht angezeigt. Sie müssen deren Anzeige über das Menü „Ansicht“ in der Symbolleiste aktivieren. Wählen Sie die Option „Filtern“ aus, und aktivieren Sie das Kontrollkästchen „Nur vollständig verwaltbare Richtlinieneinstellungen anzeigen“. Dadurch werden sofort die Einstellungen angezeigt, die in den von Ihnen importierten benutzerdefinierten ADM-Vorlagen konfiguriert sind.

Praktische Tools
Es gibt viele verschiedene Tools, die Ihnen beim Nachverfolgen von Gruppenrichtlinienproblemen behilflich sind. Einige sind im Betriebssystem integriert, andere können heruntergeladen und installiert werden. Als Nächstes werden die jeweiligen Tools erläutert, damit Sie für Ihre Aufgabe die richtigen Tools auswählen können.
Dcgpofix Möglicherweise tritt in bestimmten Fällen ein Problem mit einem der zwei Standard-GPOs auf: der Standarddomänenrichtlinie oder der Standard-Domänencontrollerrichtlinie. Wenn eines der beiden oder beide GPOs beschädigt sind, sich zu weit außerhalb der Konfiguration befinden, um den Fehler zu beheben, oder wenn ein anderes unbekanntes Problem vorliegt, können Sie mit dem Dcgpofix-Tool den Standardzustand wiederherstellen. Dieses Tool ist in Windows Server® 2003 enthalten. Sie sollten dieses Tool nicht auf einem Windows 2000-Domänencontroller ausführen. Verwenden Sie dort stattdessen Recreatedefpol. Beachten Sie, dass beim Verwenden dieses Tools alle benutzerdefinierten Einstellungen verloren gehen.
Recreatedefpol Dieses Tool ähnelt dem Dcgpofix-Tool, ist jedoch für Windows 2000-Server gedacht. Es kann die zwei Standard-GPOs in ihren ursprünglichen Installationszustand zurücksetzen. Dieses Tool sollte nur im Falle einer Notfallwiederherstellung und nicht zur routinemäßigen Wartung von GPOs verwendet werden. Sie können dieses Tool herunterladen.
Ereignisanzeige Die Ereignisanzeige enthält vielfältige Informationen zu Gruppenrichtlinien. Leider müssen Sie die verschiedenen Protokolldateien durchsuchen, um Gruppenrichtlinieneinträge zu finden. In den Protokolldateien finden Sie Einträge in Bezug auf die Richtlinienanwendung, -replikation und -aktualisierung, die beim Nachverfolgen eines Problems nützlich sein können. Die Ereignisprotokolle enthalten nicht immer genügend Informationen zu bestimmten Gruppenrichtlinienfehlern. Wenn Fehler auftreten, die Sie nicht identifizieren können, suchen Sie auf der TechNet-Website nach dem entsprechenden Problem.
Gpresult Dieses Tool kann nur lokal auf dem Zielcomputer ausgeführt werden. Es stellt jedoch Informationen zum Richtlinienergebnissatz (Resultant Set of Policies, RSoP), zu blockierten GPOs, Berechtigungen für GPOs und vieles mehr bereit. Durch die Verwendung des Befehls zusammen mit dem /v-Schalter werden zahlreiche Informationen über die GPOs, die Auswirkungen auf den Computer haben, angezeigt sowie über Benutzerkonten, die mit der aktuellen Anmeldesitzung verknüpft sind.
Gpupdate Wenn Sie neue GPO-Einstellungen implementieren oder sicherstellen möchten, dass die GPO-Verarbeitung stattgefunden hat, verwenden Sie das Gpupdate-Tool. Es handelt sich dabei um ein Befehlszeilenprogramm, das mit dem Betriebssystem (Windows XP und höhere Versionen) geliefert wird. Wenn Sie es ausführen, wird eine Hintergrundaktualisierung ausgelöst, bei der alle GPO-Einstellungen angewendet werden, die dieser Art der Aktualisierung entsprechen. Wenn Sie den /force-Schalter hinzufügen, werden alle GPO-Einstellungen erneut angewendet, selbst wenn seit der letzten Aktualisierung keine Änderungen am GPO vorgenommen wurden. Das Ausführen dieses Befehls noch vor dem Ausführen des Gpresult-Befehls stellt eine leistungsstarke Methode zum Nachverfolgen von GPO-Problemen dar.
Gpotool Da GPOs vom Domänencontroller, an dem die GPO-Änderungen anfänglich erfolgen, auf alle anderen Domänencontroller repliziert werden, besteht die Möglichkeit, dass die Replikation fehlschlägt oder nicht wirksam konvergiert. Dies führt zu einer Inkonsistenz bzw. einer inkorrekten Anwendung der Änderungen auf die Zielcomputer. Tools, wie z. B. Gpresult und RSOP, können dabei behilflich sein zu bestimmen, welche Änderungen durch die GPOs angewendet wurden. Mithilfe des Gpotool-Tools können Sie jedoch darüber hinaus prüfen, ob die GPOs auf den einzelnen Domänencontrollern konsistent sind. Das Tool gehört zum Windows Server 2003 Resource Kit, der unter go.microsoft.com/fwlink/?LinkId=77613 zur Verfügung steht.
Replmon Wenn Sie Probleme bei der Replikation von GPOs von einem Domänencontroller auf einen anderen beheben möchten, müssen Sie wissen, welche Tools zur Unterstützung des Replikationsvorgangs verwendet werden können. Da ein GPO aus zwei Teilen besteht, die repliziert werden müssen, gibt es zwei Dinge, die Sie beachten müssen. Der erste Teil, bei dem es sich um den Inhalt von SYSVOL auf den einzelnen Domänencontrollern handelt, wird vom Dateireplikationsdienst gesteuert. Diese Replikation kann nur bedingt gesteuert werden, indem Sie den Dienst deaktivieren und aktivieren, damit er ein Replikationsintervall auslöst. Der andere in Active Directory gespeicherte Teil des GPO wird von der Active Directory-Replikation gesteuert. Diese Replikation kann zwischen Domänencontrollern am selben Active Directory-Standort mithilfe der Active Directory-Standorte und -Dienste kontrolliert werden. Wenn Sie jedoch eine Replikation zwischen Domänencontrollern an verschiedenen Active Directory-Standorten auslösen müssen, ist ein Tool wie Replmon erforderlich. Replmon kann im Gegensatz zu Active Directory-Standorten und -Diensten die Replikation der Active Directory-Datenbank über verschiedene Standorte hinweg erzwingen. Wenn eine fehlende Übereinstimmung bei in Active Directory gespeicherten Gruppenrichtlinieninformationen vorliegt, können Sie mit Replmon einen Replikationsvorgang auslösen, um die Informationen auf den einzelnen Domänencontrollern aufeinander abzustimmen. Replmon gehört zu den Supporttools von Resource Kit und Windows XP. Sie können das Tool unter go.microsoft.com/fwlink/?LinkId=77614 herunterladen.
RSOP Ähnlich wie das Befehlszeilenprogramm Gpresult bietet RSOP eine grafische Schnittstelle, um die Einstellungen anzuzeigen, die von den GPOs angewendet wurden. RSOP.MSC ist ein integriertes Tool für Windows XP Professional und Windows Server 2003. Mithilfe dieses Tools werden alle angewendeten Richtlinieneinstellungen in einem ähnlich Format wie im Gruppenrichtlinienobjekt-Editor angezeigt (siehe Abbildung 5).
Abbildung 5 RSOP-Tool
Abbildung 5 RSOP-Tool

Schlussbemerkung
Die Problembehandlung von Gruppenrichtlinien gehört mit Sicherheit nicht zu den leichtesten Aufgaben. Wie in diesem Artikel erläutert, können Gruppenrichtlinien in der Tat recht kompliziert sein. Zur Problembehandlung von Gruppenrichtlinien müssen Sie die Kernarchitektur und die übergreifende Verarbeitung, die für Gruppenrichtlinien typisch ist, verstehen. Darüber hinaus müssen Sie wissen, wie ein GPO aktualisiert, repliziert, verarbeitet und angewendet wird. Wenn Sie mit den entsprechenden Konzepten vertraut sind, vereinfacht dies die Problembehandlung von Gruppenrichtlinien. Indem Sie den Anleitungen in diesem Artikel folgen und Ihre Tools dementsprechend verwenden, sind Sie für alle möglichen Gruppenrichtlinienprobleme gewappnet.

Derek Melber ist der Leiter des Bereichs Bildung, Zertifizierung und Kompatibilitätslösungen bei DesktopStandard, einer Niederlassung von Microsoft. Er ist der Mitverfasser des Microsoft Windows Group Policy Guide (Microsoft Press, 2005). Derek Melber hat außerdem eine Reihe von Büchern zur Überwachung der Windows-Sicherheit geschrieben (www.theiia.org). Sie erreichen ihn unter: derekm@desktopstandard.com.


 Windows-Verwaltung: &#220;berwachen von Active Directory mittels MOM
Windows-Verwaltung John Hann

Überwachen von Active Directory mittels MOM
Kurz zusammengefasst:
  • Management Packs für Active Directory
  • Tipps zum Anpassen von MOM
  • Alert Tuning

Management Packs sind zentraler Bestandteil des Microsoft Operations Managers (MOM) 2005 und machen den Unterschied zu anderen Verwaltungsprodukten aus. Mithilfe von Management Packs fügt MOM Regeln, Berichte, Aufgaben und Ansichten zu einem Ganzen zusammen. Mit diesen Packs kann der Anwendungsbereich von MOM auf eine bestimmte Anwendung
oder einen bestimmten Dienst wie z. B. Active Directory begrenzt werden. Die Management Packs werden von Microsoft-Produktteams für die von ihnen entwickelten Anwendungen erstellt. Dadurch wird sichergestellt, dass das detaillierte Wissen dieser Teams über das Produkt auch in MOM enthalten ist. Außerdem können Management Packs angepasst werden, damit die Packs exakt in Ihre IT-Umgebung integrierbar sind. Sie verfügen dadurch über Regeln, die das Produkt auf der Basis Ihrer konkreten Server- und Anwendungsumgebung überwachen und verwalten.
Es gibt nicht nur ein bestimmtes Management Pack für Active Directory®, sondern es gibt eine unüberschaubare Zahl von Management Packs für das Messen des Zustands von Verzeichnisdiensten, angefangen vom Basisbetriebssystem Windows Server® bis zu DHCP (Dynamic Host Configuration Protocol), DNS und zum Dateireplikationsdienst (File Replication Service, FRS). Schauen wir uns diese Management Packs genauer an, um Ihnen ein besseres Verständnis über die End-to-End-Verwaltung von Active Directory zu vermitteln, die durch MOM möglich ist.

DHCP-Management Pack
Das Management Pack für den DHCP-Dienst überwacht den DHCP-Dienst unter Windows NT®, Windows® 2000 und Windows Server 2003. Das Überwachen von DHCP ist eine gute Sache. Dadurch erkennen Sie, wenn Clients Probleme beim Aufbau einer Verbindung zum Netzwerk haben. Sie werden außerdem auf nicht autorisierte DHCP-Server aufmerksam gemacht, die in Ihrer Umgebung ausgeführt werden. Das Downloadpaket für dieses Management Pack enthält ein Handbuch, in dem die Regeln und die Berichte sowie Überwachungsszenarios und die Bereitstellung dokumentiert sind. Eine Fundgrube zusätzlicher Dokumentationen und Anleitungen finden Sie auf der TechNet-Website zu MOM 2005 (auf Englisch) (microsoft.com/technet/prodtechnol/mom/mom2005).
Je aktueller die Version von Windows ist, unter der Sie den DHCP-Dienst ausführen, desto mehr Ausstattung und Funktionalität bietet MOM 2005 für die Verwaltung dieser Umgebung. Daher werden Sie über einen DHCP-Server unter Windows Server 2003 mehr Informationen erhalten als über einen DHCP-Server unter Windows NT. So können z. B. bei einem DHCP-Server unter Windows Server 2003 die Bereichsgruppierungen dieses Servers überwacht werden, bei einem DHCP-Server unter Windows 2000 hingegen werden lediglich die normalen Bereiche überwacht. Sie können Bereiche von der Überwachung ausschließen, indem Sie diese Bereiche mithilfe eines Parameters im Überwachungsskript als „ausgeschlossen“ markieren.
Wie bereits weiter oben erwähnt, unterstützt das DHCP-Management Pack DHCP-Server, die unter Windows NT, Windows 2000 Server und Windows Server 2003 ausgeführt werden. Die Computergruppen werden durch Formeln aufgefüllt. In diesen Formeln wird beachtet, welche Version das Betriebssystem hat und ob der Server den Dienst „DHCP-Server“ hostet.
Das DHCP-Management Pack unterstützt keine Konfigurationen mit niedrigen Berechtigungen. Das Agentaktionskonto muss Mitglied der lokalen Administratorgruppe sein. Eine Überwachung ohne Agent wird unterstützt, in einer Konfiguration ohne Agent werden jedoch keine Aufgaben unterstützt. Abbildung 1 zeigt die im DHCP-Management Pack verfügbaren Berichte.
Figure 1 DHCP-Dienstberichte (Close Figure 1)

All DHCP Servers (Alle DHCP-Server)
All Authorized DHCP Servers (Alle autorisierten DHCP-Server)
Performance History-Active Queue Length (Leistungsverlauf – Länge der aktiven Warteschlange)
Performance History-Conflict Check Queue Length (Leistungsverlauf – Länge der Konfliktprüfungswarteschlange)
Performance History-Declines per Second (Leistungsverlauf – Ablehnungen pro Sekunde)
Performance History-Discovers per Second (Leistungsverlauf – Erkennungen pro Sekunde)
Performance History-Milliseconds per Packet (Avg) (Leistungsverlauf – Millisekunden je Paket (Durchschnitt))
Performance History-NACKs per Second (Leistungsverlauf – NACKs pro Sekunde)
Performance History-Scope Free Addresses (Leistungsverlauf – Bereichsfreie Adressen)
Performance History-Scope Addresses in Use (Leistungsverlauf – Verwendete Bereichsadressen)
Performance History-Superscope Free Addresses (Leistungsverlauf – Adressen ohne Bereichsgruppierung)
(Leistungsverlauf – Verwendete Adressen mit Bereichsgruppierung)
Sie können das DHCP-Management Pack unter go.microsoft.com/fwlink/?LinkId=79527 herunterladen.

DNS-Management Pack
Das Domain Name Service-Management Pack überwacht den DNS-Dienst, der unter Windows 2000 Server und Windows Server 2003 ausgeführt wird. Da dieser Dienst von entscheidender Bedeutung für den Gesamtzustand einer Active Directory-Implementierung ist, ist das Überwachen des DNS mithilfe von MOM 2005 unerlässlich. Das DNS-Management Pack überwacht Probleme mit der Namensauflösung, Datenbankprobleme, Probleme mit der Registrierung, Laufzeitereignisse und -fehler sowie zugehörige Leistungsindikatoren.
Für Windows 2000 Server muss ein Windows Management Instrumentation (WMI)-DNS-Anbieter installiert werden. Dies ermöglicht dem DNS-Management Pack insbesondere, den WMI-DNS-Namespace nach Informationen sowie für das Testen abzufragen.
Die Computergruppen werden anhand von Formeln aufgefüllt. Bei der Festlegung der Gruppenmitgliedschaft wird in diesen Formeln beachtet, welche Version das Betriebssystems hat, und ob der Server den DNS-Serverdienst hostet. Niedrige Berechtigungen werden vom DNS-Management Pack ausschließlich unter Windows Server 2003 unterstützt. Unter Windows 2000 muss das Aktionskonto Mitglied der lokalen Administratorgruppe sein. Unter Windows Server 2003 muss das Aktionskonto Mitglied der lokalen Gruppen „Benutzer“ und „Systemmonitorbenutzer“ sein. Außerdem muss das Aktionskonto über Berechtigungen die „Verwalten von Überwachungs- und Sicherheitsprotokollen“ (SeSecurityPrivilege) und „Lokal anmelden zulassen“ (SeInteractiveLogonRight) verfügen. Abbildung 2 zeigt die im DNS-Management Pack verfügbaren Berichte.
Figure 2 DNS-Dienstberichte (Close Figure 2)

All Windows DNS Servers (Alle Windows-DNS-Server)
All Windows DNS Servers by Zone (Alle Windows-DNS-Server, nach Zone)
All Windows DNS Zones by Server (Alle Windows-DNS-Server, nach Server)
Marcus Oh, ein MVP für Microsoft® Systems Management Server (SMS), hat ein Skript entwickelt, das einen DNS-Server durch Aufrufen von „nslookup“ testet, um die Fähigkeiten des DNS-Servers zum Auflösen von Namen zu überprüfen. Nehmen Sie sich die Zeit, seinen Blogbeitrag unter marcusoh.blogspot.com/2006/05/mom-monitoring-dns-synthetically.html zu lesen. Sie werden dieses Skript sicherlich in Ihr DNS-Management Pack integrieren wollen.
Sie können das DNS-Management Pack von go.microsoft.com/fwlink/?LinkId=79528 herunterladen.

FRS-Management Pack
Das Windows-Dateireplikationsdienst-Management Pack überwacht den Dateireplikationsdienst (File Replication Service, FRS) unter Windows 2000 und Windows Server 2003. FRS wird von den Domänencontrollern verwendet, um Anmeldeskripts und Informationen zu Gruppenrichtlinien zu replizieren. Das FRS-Management Pack liefert detaillierte Informationen zum Zustand des Dateireplikationsdiensts jedes einzelnen Domänencontrollers.
Das FRS-Management Pack verwendet das Ultrasound-Tool. Dieses Tool ist unter go.microsoft.com/fwlink/?LinkId=79529 verfügbar. Ultrasound erstellt auf jedem einzelnen Domänencontroller einen WMI-Namespace für den Dateireplikationsdienst. Beachten Sie, dass Ultrasound eine Datenbank benötigt und auf jedem einzelnen Domänencontroller die Informationen vom WMI-Namespace zwecks Zustandsüberwachung speichert. Mithilfe der Informationen von Ultrasound sorgt das FRS-Management Pack für die Überwachung von Replikatsätzen, von Mitgliedern, von Verbindungen, des Dateireplikationsdiensts selbst und des Ultrasound-Controllerdiensts.
Es wird empfohlen, dass Sie Ultrasound auf einem vom Verwaltungsserver getrennten Server installieren. Ultrasound-Regeln erzeugen Ereignisse und Warnungen im Namen anderer Computer. Damit die Regeln die Ultrasound-Daten ordnungsgemäß verarbeiten, müssen Sie auf jedem Server, der Ultrasound ausführt, in der MOM-Administratorkonsole das Agentproxying aktivieren. Abbildung 3 zeigt die 4 im FRS-Management Pack verfügbaren Berichte über Dienste.
Figure 3 FRS-Dienstberichte (Close Figure 3)

Ultrasound-Frequently Detected Issues-Most Problematic Connections (Ultrasound – Häufig erkannte Probleme – Problematischste Verbindungen)
Ultrasound-Frequently Detected Issues-Most Problematic Members (Ultrasound – Häufig erkannte Probleme – Problematischste Mitglieder)
Ultrasound-Frequently Detected Issues-Most Problematic Replica Set (Ultrasound – Häufig erkannte Probleme – Problematischster Replikatsatz)
Ultrasound-Frequently Detected Issues-Summary (Ultrasound – Häufig erkannte Probleme – Zusammenfassung)
Zu den Computergruppen, die mit diesem Management Pack verknüpft sind, gehören Microsoft Ultrasound 1.0-Server und FRS-Server, die unter Windows 2000 Server und Windows Server 2003 ausgeführt werden. Die Computergruppen werden alle durch Formeln aufgefüllt. In den Formeln wird bei der Festlegung der Gruppenmitgliedschaft beachtet, welche Version das Betriebssystem hat und ob der Server den Dateireplikationsdienst hostet. Die Gruppe der Ultrasound-Server wird aufgefüllt, wenn Ultrasound auf einem Server installiert ist.
Wenn Sie das FRS-Management Pack für niedrige Berechtigung konfigurieren, funktionieren zwar Aufgaben nicht, die übrigen Funktionen des Management Packs werden jedoch unterstützt. Das Aktionskonto muss über Lesezugriff auf die Datenbank von Ultrasound und über die Berechtigung zum Ausführen der gespeicherten Prozedur „GetControllerStatusForMOM001“ verfügen. Das FRS-Management Pack beinhaltet Unterstützung für das Überwachen sowohl von agentlosen als auch von agentverwalteten Computern.
Sie können das FRS-Management Pack von go.microsoft.com/fwlink/?LinkId=79530 herunterladen.

Windows Server-Management Pack
Das Windows-Basisbetriebssystem-Management Pack überwacht Windows NT 4.0 Server, Windows 2000 Server und Windows Server 2003. Das Basisbetriebssystem-Management Pack erstellt Berichte über den Zustand des Betriebssystems der Domänencontroller und überwacht außerdem die Stammdienste des Systems. Das Management Pack liefert Informationen zum Status von Kerndiensten von Windows, zur Speicher- und Prozessorleistung sowie zu freiem Speicherplatz auf Datenträgern und zu Datenträgerwartezeiten. Es gibt eine gewisse Überlappung zwischen den Überwachungsregeln dieses Management Packs und den anderen in diesem Artikel behandelten Packs. Dieses Pack bietet jedoch einen wertvollen Einblick von Grund auf in den Zustand des Domänencontrollers.
Abbildung 4 zeigt die im Basisbetriebssystem-Management Pack verfügbaren Berichte. Wie bei den anderen Management Packs werden die Computergruppen anhand von Formeln aufgefüllt. In diese Formeln geht die Version des Betriebssystems ein.
Figure 4 Basisbetriebssystemberichte (Close Figure 4)

Disk Performance Analysis (Analyse der Datenträgerleistung)
Operating System Configuration (Betriebssystemkonfiguration)
Operating System Performance (Betriebssystemleistung)
Operating System Shutdown by Event (Herunterfahren des Betriebssystems, nach Ereignis)
Operating System Shutdown by Server (Herunterfahren des Betriebssystems, nach Server)
Operating System Storage Configuration (Betriebssystem-Speicherkonfiguration)
Software and Applications Installations by Application (Software- und Anwendungsinstallationen, nach Anwendung)
Software and Applications Installations by Instance (Software- und Anwendungsinstallationen, nach Instanz)
Software and Applications Installations by Server (Software- und Anwendungsinstallationen, nach Server)
Reliability-Application Failures by Application (Zuverlässigkeit – Anwendungsfehler, nach Anwendung)
Reliability-Application Failures by Computer (Zuverlässigkeit – Anwendungsfehler, nach Computer)
Reliability-Application Failures by Event (Zuverlässigkeit – Anwendungsfehler, nach Ereignis)
Reliability-Operating System Failures by Computer (Zuverlässigkeit – Betriebssystemfehler, nach Computer)
Reliability-Operating System Failures by Event (Zuverlässigkeit – Betriebssystemfehler, nach Ereignis)
Reliability-Operating System Failures by Stop Code (Zuverlässigkeit – Betriebssystemfehler, nach Stoppcode)
Performance History-Performance History (Leistungsverlauf – Leistungsverlauf)
Performance History-Additional Reports (Leistungsverlauf – Zusätzliche Berichte)
Wenn Sie das Basisbetriebssystem-Management Pack für den Betrieb mit niedrigen Berechtigungen konfigurieren, erfordert Windows 2000, dass das Aktionskonto Mitglied der lokalen Administratorgruppe ist. Windows Server 2003 erfordert, dass das Aktionskonto Mitglied der lokalen Gruppen „Benutzer“ und „Systemmonitorbenutzer“ ist und über die Berechtigungen „Verwalten des Überwachungs- und Sicherheitsprotokolls“ (SeSecurityPrivilege) und „Lokal anmelden zulassen“ (SeInteractiveLog-onRight) verfügt. Auf agentlos überwachten Computern werden fast alle Features des Basisbetriebssystem-Management Packs, außer Aufgaben, unterstützt.
Sie können das Basisbetriebssystem-Management Pack unter go.microsoft.com/fwlink/?LinkId=79531 herunterladen.

Active Directory-Management Pack
Das Active Directory-Management Pack ist sehr vielseitig und seine Regeln eignen sich sowohl für Windows 2000 Server als auch für Windows Server 2003. Das Active Directory-Management Pack umfasst fünf Regelbereiche: Clientseitige Überwachung, Vertrauensstellungsüberwachung, Replikationsüberwachung und Topologieerkennung sowie Regeln für die Betriebssysteme Windows 2000 Server und Windows Server 2003. Wie bereits erwähnt, ermöglichen neuere Versionen von Windows eine umfassendere Instrumentierung und daher zusätzliche Überwachungen. So unterstützt das Management Pack z. B. Vertrauensstellungsüberwachung für Windows Server 2003, nicht jedoch für Windows 2000.
Das Active Directory-Management Pack erstellt eine Anzahl von Gruppen, mit deren Hilfe es Regeln auf bestimmte Computer anwendet. Die clientseitigen Überwachungsregeln verwenden eine Gruppe mit der Bezeichnung „Active Directory Client Side Monitoring“ (Clientseitige Active Directory-Überwachung). Sie würden Computer, auf denen der MOM-Agent installiert ist, in diese Gruppe einordnen, um diese Regeln zu überwachen und zu verwalten. Ich habe ein paar Desktopcomputer, die über eine Lizenz für diesen Agent verfügen, sowie einige Exchange-Server in diese Gruppe eingetragen. Exchange Server verwendet Active Directory extensiv und wäre ein erster Indikator bei einem sich anbahnenden Problem. Desktopcomputer in der Gruppe können Sie bei der Bewertung der Benutzerfunktionalität unterstützen. Die Regeln für die clientseitige Überwachung verwenden Skripts, um Konnektivität zu Domänencontrollern zu testen, diese Controller über LDAP abzufragen und Fehlerberichte zu erstellen. Es ist wichtig zu beachten, dass die Regeln für die clientseitige Überwachung nur auf agentverwaltete Computer angewendet werden können, für die Proxying aktiviert ist, die jedoch keine Domänencontroller sind.
Die Regeln zur Vertrauensstellungsüberwachung verwenden eine Gruppe mit dem Namen „Active Directory Trust Monitoring“ (Active Directory-Vertrauensstellungsüberwachung). In diese Gruppe werden Computer mit Windows Server 2003 eingeordnet, um Vertrauensstellungen zu überwachen. Windows Server 2003 verfügt über einen WMI-Namespace zur Überwachung von Vertrauensstellungen. Diese Regeln nutzen ein Skript für die Abfrage des WMI-Namespace. Wenn Fehler bei Vertrauensstellungen zu anderen Domänen erkannt werden, werden Sie über diese Regeln gewarnt.
Es gibt viele Regeln im Active Directory-Management Pack, die entweder für Windows 2000 Server oder Windows Server 2003 gelten. Diese Regeln beschreiben die Unterschiede bei der Implementierung von Active Directory unter den beiden Betriebssystemen. Der größte Teil des Active Directory-Management Packs besteht jedoch aus den kombinierten Regeln für beide Betriebssysteme. Einige dieser Regeln umfassen Skripts zum Testen der Konnektivität zwischen Domänencontrollern sowie zum Überprüfen der FSMO-Rollenhalter (Flexible Single-Master Operations), der Größe der DIT-Datenbank (Directory Information Tree, Verzeichnisinformationsstruktur), der Gruppenrichtlinienverarbeitung, der KCC-Inspektion (Knowledge Consistency Checker, Kenntniskonsistenzkontrolleur) und der Tests bezüglich des standortübergreifenden Messagingdiensts.
Kernstück des Active Directory-Management Packs ist die Replikationsüberwachung. Es gibt zwei Gruppen, „Active Directory Replication Latency Data Collection Sources“ (Datensammlung zur Active Directory-Replikationswartezeit – Quellen) und „Active Directory Replication Latency Data Collection Targets“ (Datensammlung zur Active Directory-Replikationswartezeit – Ziele), mit denen Sie die Domänencontroller konfigurieren können, die ausschließlich für Berichte der Replikationsüberwachung verwendet werden. Die Replikationswartezeit wird für jedes einzelne Mitglied der Datensammlungsgruppen berechnet. In den Leistungsindikatoren werden die Zeiten eingetragen, die für den Aktualisierungsvorgang zum Replizieren jedes einzelnen Gruppenmitglieds benötigt werden. Es wird die unternehmensweite Replikationswartezeit berechnet und berichtet (und es werden Warnungen generiert), wenn festgelegte Schwellenwerte überschritten werden. Beachten Sie, dass unter Windows 2000 Server ein WMI-Namespace für die Replikationsüberwachung installiert werden muss.
Mithilfe der Topologieerkennung im Active Directory-Management Pack werden Diagramme Ihrer Implementierung erstellt. Diese hilfreichen Diagramme können in Microsoft Office Visio® exportiert werden. Die Diagramme werden von MOM in Echtzeit erstellt, damit Sie in nur wenigen Sekunden eine aktuelle Version erstellen können.
Unter den Diagrammansichten in der Betriebskonsole von MOM 2005 befinden sich drei Active Directory-Management Pack-Diagramme. Im Diagramm „Broken Connection Objects“ (Objekte mit unterbrochener Verbindung) (siehe Abbildung 5) werden alle Verbindungen dargestellt, die sich in einem Fehlerzustand befinden. Dieses Diagramm kann leer sein, wenn keine Verbindungsfehler vorhanden sind.
Abbildung 5 Unterbrochene Verbindungen sind in der Diagrammansicht hervorgehoben
Abbildung 5 Unterbrochene Verbindungen sind in der Diagrammansicht hervorgehoben
Im Diagramm „Connection Objects“ (Verbindungsobjekte) werden die Verbindungen zwischen Domänencontrollern hervorgehoben. Das Diagramm „Site Links“ (Standortverknüpfungen) zeigt jeden Active Directory-Standort, wobei die entsprechenden Domänencontroller an diesem Standort und die verbindenden Standortverknüpfungen eingekapselt sind.
Da die von MOM für diese Ansichten erstellten Diagramme dynamisch sind, können Sie die Diagramme in Visio exportieren und dort problemlos bearbeiten und anpassen. So zeigt z. B. Abbildung 6 das Diagramm „Site Links“ (Standortverknüpfungen) bei der Bearbeitung in Visio an.
Abbildung 6 Bearbeiten des Diagramms „Site Links“ (Standortverknüpfungen) in Visio
Abbildung 6 Bearbeiten des Diagramms „Site Links“ (Standortverknüpfungen) in Visio (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 6 Bearbeiten des Diagramms „Site Links“ (Standortverknüpfungen) in Visio
Abbildung 6 Bearbeiten des Diagramms „Site Links“ (Standortverknüpfungen) in Visio (Klicken Sie zum Vergrößern auf das Bild)
Abbildung 7 zeigt die im Active Directory-Management Pack verfügbaren Berichte. In Abbildung 8 sind Computergruppen dargestellt, die mit diesem Management Pack verknüpft sind. Wie Sie sehen, werden die Computergruppen von Active Directory nach expliziter Mitgliedschaft aufgefüllt. Die Computergruppen von Windows werden entsprechend der Version des Betriebssystems und anhand der Tatsache, ob der Computer ein Domänencontroller ist, aufgefüllt.
Figure 8 Computer Groups (Computergruppen) (Close Figure 8)

Active Directory Client-Side Monitoring (Clientseitige Active Directory-Überwachung)
Active Directory Replication Latency Data
Collection-Sources (Datensammlung zur Active Directory-Replikationswartezeit – Quellen)
Active Directory Replication Latency Data
Collection-Targets (Datensammlung zur Active Directory-Replikationswartezeit – Ziele)
Active Directory Trust Monitoring (Active Directory – Vertrauensstellungsüberwachung)
Windows 2000 Server Domain Controllers (Windows 2000 Server-Domänencontroller)
Windows Server 2003 Domain Controllers (Windows Server 2003-Domänencontroller)
Figure 7 Active Directory Reports (Active Directory-Berichte) (Close Figure 7)

AD Domain Controller (AD-Domänencontroller)
AD Role Holders (AD-Rollenhalter)
AD Replication Connection Objects (AD-Replikationsverbindungsobjekte)
AD Replication Site Links (AD-Replikationsstandortverknüpfungen)
AD DC Disk Space (AD-DC-Speicherplatz)
AD Domain Changes (AD-Domänenänderungen)
AD Machine Account Authentication Failures (AD-Computerkonto-Authentifizierungsfehler)
AD Replication Bandwidth (AD-Replikationsbandbreite)
AD Replication Latency (AD-Replikationswartezeit)
Das Active Directory-Management Pack kann für niedrige Berechtigungen auf Windows Server 2003-Domänencontrollern konfiguriert werden. Das Management Pack unterstützt keine agentlose Überwachung. Unter Windows 2000 Server muss das Agentaktionskonto der Gruppe der Domänenadministratoren oder der lokalen Administratoren angehören. Das Agentaktionskonto auf Windows Server 2003-Domänencontrollern muss über zusätzliche Berechtigungen verfügen, um für niedrige Berechtigungen konfiguriert werden zu können. Diese Berechtigungen sind: Mitgliedschaft in den Gruppen „Benutzer“ und „Systemüberwachungsbenutzer“, Zugriff auf Ereignisprotokolle sowie die Berechtigungen „SeSecurityPrivilege“, „SeAuditPrivilege“ und „SeInteractiveLogonRight“. Darüber hinaus sind folgende Zugriffe erforderlich: voller Zugriff auf den CN=MomLatencyMonitors-Container in Active Directory zur Replikationsüberwachung, Lesezugriff auf die Verzeichnisse, in denen sich die Datenbank „NTDS.dit“ und die Protokolldateien befinden, und Lesezugriff auf den folgenden Registrierungsschlüssel:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Service\NTDS\Parameters
Wenn Sie Vertrauensstellungen unter Windows Server 2003 überwachen, beachten Sie, dass das Skript „AD Monitor Trusts“ erfordert, dass das Agentaktionskonto Mitglied in der Gruppe der Domänenadministratoren oder der Administratorgruppe ist.
Sie können das Active Directory-Management Pack unter go.microsoft.com/fwlink/?LinkId=79540 herunterladen.

Anpassen von MOM für Active Directory
Das Active Directory-Management Pack muss konfiguriert werden. Andernfalls würde Ihre Konsole mit Warnungen überschwemmt. Die härteste Zeit für das Active Directory-Management Pack bricht an, wenn ein Domänencontroller neu gestartet wird – scheinbar wird jede nur mögliche Warnung ausgelöst. Die schlechte Nachricht ist, dass dies nicht leicht unterbunden werden kann. Die besten Chancen haben Sie, wenn Sie den Wartungsmodus in MOM verwenden, um die Warnungen in den zu erwartenden Wartungsfenstern in den Griff zu bekommen. Der Sinn des Wartungsmodus besteht darin, Warnungen bezüglich der Domänencontroller automatisch abzuhandeln. Auf diese Weise wird die Konsole nicht mit Warnungen überschüttet.
Konfigurieren Sie unbedingt die Gruppe „Active Directory Client Side Monitoring“ (Clientseitige Active Directory-Überwachung), indem Sie Clientcomputer und entsprechende Server in diese Gruppe einordnen. Die dieser Gruppe zugeordneten Regeln unterstützen Sie beim Ermitteln des Zustands der FSMOs und der Konnektivität zu diesen.
Es gibt Leistungsregeln, die mithilfe von Schwellenwerten für die Bindung zu FSMOs sorgen und mit LDAP, PING und DNS die Konnektivität überprüfen. Diese Regeln befinden sich in den Active Directory Availability-Leistungsregeln. Sie sollten die von diesen Regeln verwendeten Schwellenwerte durch Einstellen des Warnungsschweregrads anpassen. So verwenden z. B. die FSMO-Bindungen Attributwerte, die in Sekunden gemessen werden. Die Leistungsregeln für die einzelnen FSMO-Rollen verwenden diese Warnungserzeugungsmethode.
Es ist wichtig zu verstehen, wie die Berechnung des Schweregrads für Statusregeleinstellungen funktioniert. Das Dialogfeld verwendet If-Else-Bedingungen für den Attributwert und legt den Schweregrad entsprechend fest (siehe Abbildung 9). Wenn die Regel den vom Skript „AD Op Master Response“ erzeugten Leistungsindikator „Last Bind“ (Letzte Bindung) erfasst, wird der Indikator mit den durch diese Regeln festgelegten Schwellenwerten verglichen. Sie müssen diese verschiedenen Warnungsebenen für Ihre Umgebung konfigurieren.
Abbildung 9 Festlegen von Schweregradregeln
Abbildung 9 Festlegen von Schweregradregeln (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 9 Festlegen von Schweregradregeln
Abbildung 9 Festlegen von Schweregradregeln (Klicken Sie zum Vergrößern auf das Bild)
Beachten Sie den Replikationszeitplan für die einzelnen Domänencontroller. Wenn ein bestimmter Domänencontroller einen von anderen Controllern abweichenden Zeitplan hat, wird er die Ergebnisse für die Replikationswartezeiten verfälschen und Sie veranlassen, die Schwellenwerte höher festzulegen. Sie müssen die Parameter für die Replikationsskripts festlegen, um den Anforderungen der konkreten Umgebung zu entsprechen. Es ist wichtig zu beachten, dass, wenn ein Domänencontroller außer Betrieb ist oder Probleme bei der Replikation aufweist, jeder andere Domänencontroller in diesen Gruppen einen Replikationsfehler für diesen Domänencontroller melden kann, auch wenn der Controller kein direkter Replikationspartner ist. Daher können die anderen Domänencontroller auch dann Replikationsfehler berichten, wenn Sie den fehlerhaften Domänencontroller in den Wartungsmodus versetzen.
Beim Feinabstimmen des Active Directory-Management Packs sollten Sie sich besonders auf die Replikationsüberwachung konzentrieren. Sie werden das Management Pack in Ihrer Umgebung einige Wochen lang ausführen müssen, um das Warnungsverhalten zu beobachten. Wenn Sie sehen, dass sich einige Trends entwickeln, können Sie anhand der Berichte Wartezeiten erkennen und die Schwellenwerte entsprechend abstimmen.
Letztendlich sollen Sie die unter Alert Tuning Solution Accelerator (auf Englisch) aufgeführten Anleitungen nutzen.

Vorschau
Mit MOM 2005 und dem Active Directory-Management Pack können Sie die Active Directory-Implementierung Ihrer Organisation effizient und wirksam überwachen. Mit den Active Directory-, DHCP-, DNS-, FRS- und Windows Server-Basisbetriebssystem-Management Packs können Sie die meisten Aspekte Ihrer Infrastruktur überwachen und dadurch den guten Zustand Ihrer Active Directory-Infrastruktur (und das Wohlbefinden der Benutzer) sicherstellen. Anhand der umfangreichen Daten, die im Berichts-Data Warehouse gesammelt werden, können Sie die Leistungs- und Ereignisdaten analysieren. Diese Analysen helfen Ihnen bei der Planung von Kapazitäten und beim Erkennen von Trends im Leistungsverhalten.
Die in diesem Artikel besprochenen Management Packs und vieles mehr finden Sie im Management Pack-Katalog (auf Englisch).
Das nächste Update zum Active Directory-Management Pack wird die übliche Sammlung von Problembehebungen und eine Optimierung einiger Schwellenwerte enthalten. Interessanter sind die neuen Features, die für die nächste Veröffentlichung des Produkts unter der Bezeichnung „System Center Operations Manager 2007“ vorgesehen sind. Dazu gehören die Möglichkeit, mehrere Gesamtstrukturen von einer einzelnen Konfigurationsgruppe aus zu überwachen, Gruppen von Domänencontrollern festzulegen (jede Gruppe mit einer eigenen erwarteten Replikationswartezeit zu anderen Gruppen) und Domänencontroller zu überwachen, auf denen die nächste Version von Windows Server ausgeführt wird. Detaillierte Informationen finden Sie auf der MOM-Website unter http://www.microsoft.com/mom/ (auf Englisch).

John Hann hat seit MOM 2000 mit MOM gearbeitet und ist seit 2004 MVP für MOM. Er schreibt Beiträge für MyITForum.com, MOMCommunity.com und LearnMOM.com. Sie können John Hann über seinen Blog erreichen.


 Windows-Verwaltung: Spielen in einer sicheren Umgebung
Windows-Verwaltung Matt Clapham

Spielen in einer sicheren Umgebung
Kurz zusammengefasst:
  • Schreiben in geschützte Ordner und Registrierungsschlüssel
  • Kopierschutzfehler
  • Firewallprobleme
  • Probleme mit Unternehmensclients

Tagsüber arbeite ich als Security Program Manager bei Microsoft. Ich schreibe zudem recht häufig für das TechNet Magazin über das Thema Sicherheit. Daher ist es selbstverständlich, dass ich die Sicherheit sehr ernst nehme. Ich habe jedoch auch andere
Interessen. In meiner Freizeit spiele ich gern Windows®-basierte Spiele. Ich mag besonders Egoshooter, Simulatoren, Rollenspiele und Echtzeitstrategiespiele. Die Sache hat jedoch einen Haken. Wie meine Freunde Jesper Johansson und Aaron Margosis lehne ich es ab, Spiele mit Administratorrechten auszuführen, sofern es nicht unbedingt erforderlich ist. Dies beruht teilweise darauf, dass ich sicherstellen möchte, dass mir bei einem Netzwerkspiel die Meldung „0wn3d“ nur aufgrund meiner mangelnden Geschicklichkeit angezeigt wird und nicht, weil mich jemand mit einem Rootkit bombardiert, um meine Zielbewegungen zu verlangsamen (siehe „Quake 3 Buffer Overflow Advisory“ in der Randleiste „Ressourcen“).
Ich vertrete diesen Standpunkt so konsequent, dass ich häufig tolle neue Spiele nicht spielen kann (siehe Abbildung 1). Wenn ich ein Spiel unter meinem Standardbenutzerkonto auf einem zur SBS-Domäne (Small Business Server) gehörenden Client nicht zum Laufen bekomme, nachdem ich es unter einem Administratorkonto installiert und aktualisiert habe, entferne ich es sofort. Es gibt keine Entschuldigung für solche technischen Mängel, und ich habe genug Spiele, aus denen ich wählen kann. Ich gebe zu, dass sich diese Haltung extrem anhören mag, aber in diesem Punkt bin ich unnachgiebig. Dennoch habe ich nichts dagegen, für ein ungetrübtes Spielvergnügen einige kleinere Probleme zu umgehen, und darauf möchte ich in diesem Artikel eingehen. Lassen Sie mich also einige der mit Spielen verbundenen Probleme, mit denen ich konfrontiert wurde, und die Lösungen erklären, die sich als hilfreich erwiesen haben. Eine kurze Zusammenfassung von Best Practices finden Sie in der Randleiste „Tipps für das Spielen als Benutzer mit eingeschränkten Rechten“.
Abbildung 1 Dateizugriffsproblem beim manuellen Aktualisieren
Abbildung 1 Dateizugriffsproblem beim manuellen Aktualisieren (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 1 Dateizugriffsproblem beim manuellen Aktualisieren
Abbildung 1 Dateizugriffsproblem beim manuellen Aktualisieren (Klicken Sie zum Vergrößern auf das Bild)

Häufige Probleme
Dieses Berechtigungsproblem ist nicht neu. Es gibt zahlreiche Spiele und andere Arten von Programmen, die zur ordnungsgemäßen Ausführung Administratorrechte erfordern. Lesen Sie hierzu den Knowledge Base-Artikel „Bestimmte Programme funktionieren bei Anmeldung über ein Standardbenutzerkonto nicht ordnungsgemäß“ (siehe http://support.microsoft.com/kb/307091/de). Er enthält eine Liste von beinahe 200 Spielen und Anwendungen, bei denen Probleme auftreten, wenn sie von einem Benutzer mit eingeschränkten Rechten ausgeführt werden, einschließlich einiger Microsoft-Programme.
Ich möchte klarstellen, dass ich es nicht als Problem betrachte, dass zur Installation oder (manuellen) Aktualisierung eines Spiels Administratorrechte benötigt werden. Dies ist generell erforderlich, bis wir die Möglichkeit haben, routinemäßig Installationen für einzelne Benutzer unter Windows durchzuführen. Dieser Tag wird bald kommen, es ist jedoch noch nicht ganz so weit. Sobald jedoch ein Spiel installiert und aktualisiert wurde, sollte es von jedem Benutzer eines Systems gespielt werden können, selbst wenn er nur über eingeschränkte Rechte verfügt.
Schreibversuche in geschützten Ordnern und Registrierungsschlüsseln Das am häufigsten auftretende Problem besteht meiner Erfahrung nach darin, dass ein Spiel beim Start oder während des Spielens abstürzt, weil es versucht, in geschützte Ordner oder Registrierungsschlüssel zu schreiben (ein häufiger Vorgang in vielen Windows-basierten Anwendungen). Standardmäßig können nur Administratoren (und die veralteten Poweruser) in bestimmte Ordner (z. B. %PROGRAMFILES%) und Registrierungsstrukturen (wie HKEY_LOCAL_MACHINE) schreiben. Die daraus resultierenden Fehler können relativ offensichtlich sein: „Fehler 42: Protokolldateien können nicht in C:\Programme\CoolGamesInc\NewestFPS\Logs\ geschrieben werden“ oder „Spiel nicht ordnungsgemäß installiert, neu installieren und neu starten“. Ich habe auch Beispiele hierfür mitten im Spiel erlebt, z. B. Fehlermeldungen, die angezeigt werden, wenn ich meinen Spielstand speichere. Manchmal weisen die Spielentwickler den Benutzer zumindest darauf hin, dass für das Spiel derzeit Administratorrechte erforderlich sind, damit es funktioniert. Dies habe ich bei Age of Mythology® erlebt. Bei MMO-Spielen (Massively Multiplayer Online Games, MMOGs) treten oft Probleme mit Berechtigungen auf, da sie häufig automatisch aktualisiert werden und die Lösung des Problems der eigenständigen Aktualisierung technisch etwas anspruchsvoller ist. Beim Testen von EVE Online stellte ich fest, dass nicht nur Probleme auftraten, weil Protokolldateien an ungeeigneten Speicherorten abgelegt wurden, sondern auch, weil versucht wurde, Spielinhalte im Installationsordner automatisch zu aktualisieren.
Kopierschutz versagt Die zweithäufigste Ursache dafür, dass Spiele nicht gestartet werden, besteht meiner Erfahrung nach darin, dass der integrierte Kopierschutz des Spiels (oder eine andere Funktion zum Schutz vor Softwarepiraterie) bei Benutzern mit eingeschränkten Rechten nicht funktioniert. Dies könnte darauf zurückzuführen sein, dass der Treiber nicht ordnungsgemäß gestartet wurde oder ein Hintergrunddienst nicht ausgeführt wird. Die häufigste Manifestation dieses Problems, die ich erlebt habe, besteht darin, dass das Spiel den Benutzer auffordert, einen Datenträger einzulegen – selbst wenn sich das erforderliche Medium bereits im Laufwerk befindet. Ich habe auch Spiele gesehen, bei denen in dem Irrglauben, dass nur Administratoren die Kopierschutzprüfung ordnungsgemäß ausführen können, Administratorrechte verlangt wurden. Im schlimmsten Fall wird eine fehlerhaft gebildete, unsinnige Fehlermeldung angezeigt, die keinen Verweis auf die Supportwebsite des Spiels enthält.
Unterlassen der Anforderung von Firewallausnahmen Multiplayerspiele, die über ein lokales Netzwerk oder das Internet gespielt werden können, sind sehr verbreitet, und in Windows XP Service Pack 2 (SP2) wurde eine Warnmeldung hinzugefügt, die den Benutzer darauf hinweist, dass Anwendungen versuchen, auf das Netzwerk zuzugreifen. Dies bringt mich zum nächsten häufig auftretenden Problem, das ich beobachtet habe: Spiele, die eine Firewallausnahme erfordern, bei der Installation aber nicht zum Hinzufügen dieser Ausnahme auffordern. Da Benutzer mit eingeschränkten Rechten die Firewallkonfiguration nicht ändern können, kann dieses Problem (siehe Abbildung 2) nicht ohne bestimmte Konfigurationsmaßnahmen seitens eines Administrators behoben werden. Noch schlimmer ist, dass das Problem manchmal nicht offensichtlich ist, da die Warnung in der Windows-Shell und nicht innerhalb der Benutzeroberfläche des Spiels angezeigt wird. Tatsächlich sieht man die Fehlermeldung in der Regel erst, nachdem das Spiel beendet wurde.
Abbildung 2 Wenn Firewalleinstellungen den ganzen Spaß verderben
Abbildung 2 Wenn Firewalleinstellungen den ganzen Spaß verderben (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 2 Wenn Firewalleinstellungen den ganzen Spaß verderben
Abbildung 2 Wenn Firewalleinstellungen den ganzen Spaß verderben (Klicken Sie zum Vergrößern auf das Bild)
Probleme mit Unternehmensclients Ich habe ein weiteres Problem gefunden, das zwar nicht direkt mit eingeschränkten Rechten in Verbindung steht, aber trotzdem erwähnenswert ist. Ich führe meine Heimcomputerumgebung wie ein kleines Unternehmen aus. (Ich möchte an dieser Stelle nicht zu sehr ins Detail gehen. Sie können jedoch hierzu den Artikel „Beherrschen Sie Ihre Domäne: Erstellen Sie ein Unternehmensnetzwerk zu Hause“ lesen, den Jesper Johansson und ich für die Oktoberausgabe 2006 des TechNet Magazins geschrieben haben. Mithilfe von SBS 2003 (R2) habe ich eine vollständige Windows-Domäne mit einem Ordner „Eigene Dateien“ eingerichtet, der zu einer Serverfreigabe umgeleitet wird. Dabei habe ich das letzte häufige Problem entdeckt, auf das ich eingehen möchte: Spiele, die nicht mit Unternehmensclients kompatibel sind.
Bei Age of Empires® III (AoE3) habe ich ein doppeltes Problem bemerkt. Zur Ehre des Entwicklungsteams sei gesagt, dass das Spiel mit eingeschränkten Benutzerrechten ordnungsgemäß gestartet und ausgeführt wird. Ich habe jedoch festgestellt, dass Szenarios nur langsam geladen wurden, weil eine große Menge von Protokollierungsdaten über das Netzwerk geschrieben wurde. Zudem gingen in AoE3 bei jedem Beenden des Spiels meine Konfiguration, meine gespeicherten Spiele und mein Spielstand verloren. Die Dateien befanden sich eindeutig im Ordner „Eigene Dateien“, wurden aber vom Spiel einfach nicht geladen. Dies war eine echte Enttäuschung, insbesondere angesichts der Tatsache, dass AoE3 im Vergleich zu früheren Versionen der Reihe eine viel höhere Benutzerfreundlichkeit für Standardbenutzerkonten aufweist.
Ich habe ein Spiel gesehen, bei dem solche Probleme mit Unternehmensclients zumindest anerkannt werden. Als ich Fable®: The Lost Chapters™ ausprobiert habe, wurde mir wenigstens mitgeteilt, dass „Eigene Dateien“-Remoteordner nicht unterstützt werden, und dann wurde das Spiel ordnungsgemäß beendet. Ich muss das Entwicklungsteam loben, weil es ein nicht unterstütztes Szenario erkannt und ausgeschlossen hat. Es erschien jedoch etwas merkwürdig, dass man sich angesichts der Tatsache, dass durch das Spiel lediglich ein paar MB Daten im Ordner „Eigene Dateien“ abgelegt werden sollten, die Mühe machte, den Benutzer zu stoppen.

Einfache Lösungen
Ich habe diese Probleme immer wieder und bei mehr Spielen erlebt, als ich in Erinnerung habe. Glücklicherweise gibt es für die meisten Probleme praktische Lösungen. Meine bevorzugte Lösung besteht darin, das Spiel vollständig zu entfernen und zu einem für Standardbenutzerkonten geeigneten Titel eines anderen Herausgebers aus dem gleichen Genre zu wechseln. Das mag sich erneut etwas extrem anhören. Zudem ist dies keine tolle Lösung, wenn Sie gerade 60 Euro für ein neues Spiel ausgegeben haben und es nicht zurückgeben können, weil die Verpackung bereits geöffnet ist. Schauen wir uns also Möglichkeiten zur Problembehebung bei Spielen an, die Sie bereits besitzen.Tipps für das Spielen als Benutzer mit eingeschränkten Rechten
  • Aktualisieren Sie auf Windows Vista.
  • Testen Sie vor dem Kauf die Demoversion. Dabei treten wahrscheinlich alle Probleme in Bezug auf Benutzerkonten mit minimalen Rechten zutage, die auch bei der Vollversion vorkommen.
  • Prüfen Sie die Liste der Programme, von denen bekannt ist, dass bei der Ausführung unter einem Benutzerkonto mit minimalen Rechten Probleme auftreten.
  • Suchen Sie nach Spielen, die das Logo „Designed for Windows“ tragen.
  • Aktualisieren Sie das Spiel nach der Installation und vor der Ausführung mit eingeschränkten Rechten.
  • Wenn Sie ein Spiel finden, das mit eingeschränkten Benutzerrechten nicht funktioniert, teilen Sie das Problem dem Herausgeber und dem technischen Support des Unternehmens mit.
  • Wenn es gar nicht anders geht, verwenden Sie ein lokales Poweruserkonto des Systems.

Beheben von Kopierschutzproblemen Betrachten wir zuerst das Problem mit dem Kopierschutztreiber. Kopierschutzsysteme sind heute nicht mehr wegzudenken. Dies bedeutet jedoch nicht, dass sie Benutzer ohne Administratorrechte an der Ausführung von Spielen hindern sollten! Bei den meisten Spielen wird der SafeDisc-Kopierschutzmechanismus von Macrovision verwendet, der einen Treiber installiert, der auf einen Originalspieledatenträger prüft. Standardmäßig ist der Treiber so konfiguriert, dass er bei Bedarf gestartet wird (eine Funktion, die Benutzer mit eingeschränkten Rechten nicht verwenden dürfen). Microsoft und Macrovision haben Problembehebungen zur Verfügung gestellt, ich habe jedoch eine andere Lösung gefunden:
  1. Öffnen Sie den Geräte-Manager unter Verwendung eines Administratorkontos.
  2. Wählen Sie im Menü „Ansicht“ die Option „Ausgeblendete Geräte anzeigen“.
  3. Erweitern Sie den Knoten „Nicht-PnP-Treiber“.
  4. Öffnen Sie die Eigenschaften für den Security- oder SecDrv-Treiber (siehe
    Abbildung 3 Ermöglichen des ordnungsgemäßen Funktionierens des Kopierschutzes (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 3 Ermöglichen des ordnungsgemäßen Funktionierens des Kopierschutzes
Abbildung 3 Ermöglichen des ordnungsgemäßen Funktionierens des Kopierschutzes (Klicken Sie zum Vergrößern auf das Bild)
Da der Treiber jetzt beim Start des Computers gestartet wird, ist er bereit, wenn der Benutzer den Datenträger zum Ausführen des Spiels einlegt.
Beheben von Dateisystem- und Registrierungszugriffsproblemen Das Voraussetzen uneingeschränkten Zugriffs auf jeden Teil des Dateisystems oder der Registrierung ist ein Problem, das bei vielen aktuellen und älteren Programmen und nicht nur bei Spielen häufig auftritt. Der Artikel von Aaron Margosis „Berechtigungsprobleme: Suchen und Beheben von LUA-Fehlern“ beschäftigt sich ausführlicher mit Lösungen für die verschiedenen Probleme, die dazu führen, dass Administratorrechte erforderlich sind.
Das Aufspüren von Zugriffsproblemen kann mitunter etwas schwierig sein. Sobald jedoch der erforderliche Satz von Dateien, Ordnern und Registrierungsschlüsseln ermittelt wurde, können die Zugriffssteuerungslisten (ACLs) relativ einfach gelockert werden, um Benutzern mit eingeschränkten Rechten die Ausführung des Spiels zu ermöglichen. Ich hatte den meisten Erfolg mit der folgenden Methode:
  1. Laden Sie die aktuellen Versionen von Filemon und Regmon von microsoft.com/technet/sysinternals herunter.
  2. Führen Sie die Tools als Administrator aus, und lassen Sie sie mit der Erfassung von Protokollen beginnen.
  3. Spielen Sie das Spiel einige Minuten lang als Administrator, und führen Sie dabei die gängigsten Aufgaben aus (Starten einer neuen Kampagne, Speichern eines Spiels, Hosten eines Netzwerkspiels usw.).
  4. Filtern Sie die Ergebnisse von Filemon und Regmon, sodass sie sich auf Zugriffe seitens des getesteten Spiels konzentrieren.
  5. Lockern Sie nach Bedarf die ACLs für die betreffenden Ordner und Registrierungsschlüssel.
  6. Führen Sie das Spiel als Benutzer ohne Administratorrechte aus, um sicherzustellen, dass es jetzt funktioniert.
Noch ein Wort der Warnung in Bezug auf das Lockern der ACLs: Öffnen Sie sie nicht zu weit (z. B. Jeder – Vollzugriff) oder auf einer zu hohen Ebene (wie HKEY_CLASSES_ROOT). Zudem sollten Berechtigungen für Systemordner wie %SYSTEMROOT% und %PROGRAMFILES% am besten nicht geändert werden, um zu vermeiden, dass Windows völlig zerstört oder das System in einem unsicheren Zustand hinterlassen wird.
Eine andere mögliche Problemumgehung besteht darin, das Spiel als lokaler Poweruser des Systems auszuführen. Dies ist nicht meine erste Wahl, aber durch Verwendung eines lokalen Kontos des Systems sind die Auswirkungen zumindest auf eine einzelne Arbeitsstation begrenzt, falls etwas schief gehen sollte. Nach meiner Erfahrung hat sich diese Lösung bei den meisten Spielen bewährt, die nur mit Administratorrechten ordnungsgemäß zu funktionieren scheinen.
Übrigens habe ich herausgefunden, dass die kurze Ausführung eines Spiels als Administrator eine praktische Methode für dessen automatische Aktualisierung darstellt. Ich führe das Spiel in der Regel als Administrator aus, rufe seine Aktualisierungsoption auf und beende es dann. Anschließend verwende ich zum eigentlichen Spielen wieder mein Konto mit eingeschränkten Rechten. (Es ist erwähnenswert, dass Windows Vista™ Benutzern mit eingeschränkten Rechten die Aktualisierung von Anwendungen gestattet, wobei vorausgesetzt wird, dass der Patch vom ursprünglichen Herausgeber signiert wurde.)
Windows Vista unterstützt auch die Lösung von Problemen mit dem Datei- und Registrierungszugriff durch Spiele und andere Anwendungen. Für Programme, die von Benutzern mit eingeschränkten Rechten ausgeführt werden, werden standardmäßig Virtualisierungsshims aktiviert, die fehlgeleitete Datei- und Registrierungszugriffe in einen benutzerspezifischen Cache umleiten. Ich habe selbst erlebt, dass in der Windows 9x-Ära entwickelte Spiele (z. B. The Neverhood), die unter Windows XP (aufgrund von Berechtigungsproblemen) nicht ordnungsgemäß ausgeführt werden, unter Windows Vista mit den Standardshims einwandfrei funktionieren. Ich freue mich darauf, einige andere problematische Spiele unter Windows Vista zu testen, habe jedoch das Gefühl, dass es schwer sein wird, ein Spiel zu finden, das Windows Vista nicht ordnungsgemäß durch ein Shim unterstützen kann.
Beheben von Firewallproblemen. Das Firewallproblem wird am besten bei der Erstinstallation des Spiels gelöst. Wenn das Installationsprogramm des Spiels nicht ausgereift genug ist, um nach den erforderlichen Firewallanpassungen zu fragen und diese zu konfigurieren, kann die folgende Methode verwendet werden, die meiner Erfahrung nach ebenfalls funktioniert:
  1. Melden Sie sich als Administrator an.
  2. Öffnen Sie die Systemsteuerung, und wählen Sie die Option „Windows-Firewall“.
  3. Wählen Sie die Option zum Hinzufügen eines Programms zur Ausnahmeliste der Firewall aus.
  4. Wählen Sie das Spiel aus der Liste aus, oder suchen Sie nach der ausführbaren Datei des Spiels, wenn Sie dazu aufgefordert werden.
Durch Hinzufügen der ausführbaren Datei des Spiels zur Ausnahmeliste der Firewall wird sichergestellt, dass dem Spiel der Zugriff auf alle Ports gestattet wird, die für sein ordnungsgemäßes Funktionieren erforderlich sind. Danach steht dem Spielspaß nichts mehr im Wege!
Beheben von Problemen mit Unternehmensclients Die Probleme, die bei Spielen auf Unternehmensclients auftreten, werden mit der Zeit verschwinden. Die Zahl der Haushalte mit mehreren Computern und Breitbandanschluss steigt, und es gibt eine wachsende Community von Benutzern, die SBS zu Hause ausführen. Im Moment wird jedoch noch eine Lösung benötigt.
In meinem besonderen Fall habe ich festgestellt, dass durch ein lokales Systembenutzerkonto mit minimalen Rechten das Problem mit dem umgeleiteten Ordner „Eigene Dateien“ umgangen wird. Sowohl „Age of Empires II“ als auch „Fable: The Lost Chapters“ funktionieren mit eingeschränkten Benutzerrechten einwandfrei, solange der Ordner „Eigene Dateien“ nicht zu einem Netzwerkordner umgeleitet wird.Ressourcen
  • Quake 3 Buffer Overflow Advisory (auf Englisch)
  • Windows Vista Application Development Requirements for User Account Control Compatibility (auf Englisch)
  • Anwenden des Prinzips der geringsten Rechte auf Benutzerkonten in Windows XP
  • LUA Buglight-Tool von Aaron Margosis
  • Standard User Analyzer
  • Beherrschen Sie Ihre Domäne: Erstellen Sie ein Unternehmensnetzwerk zu Hause
  • Berechtigungsprobleme: Suchen und Beheben von LUA-Fehlern
  • Bestimmte Programme funktionieren bei Anmeldung über ein Standardbenutzerkonto nicht ordnungsgemäß

Schlussbemerkung
Ich empfehle nachdrücklich die Ausführung mit eingeschränkten Rechten, damit Sie die Vorteile nutzen können, die mit der Ausführung ohne Administratorrechte verbunden sind. Es ist nicht immer leicht, in einer mit einem Unternehmen verbundenen Umgebung zu spielen, die auf dem Prinzip der minimalen Rechte basiert – es ist jedoch auch alles andere als unmöglich. Im Laufe der Jahre habe ich eine Menge Spiele aus allen Genres entdeckt, die mit eingeschränkten Benutzerrechten einwandfrei funktionieren. Darüber hinaus habe ich einige Lösungen gefunden, die bei einer Reihe anderer Spiele funktionieren. Spiele, die sich unter Windows XP nicht mit eingeschränkten Rechten spielen ließen, funktionieren aufgrund der Virtualisierung in Windows Vista mittlerweile wieder.

Matt Claphamist als Security Program Manager bei Microsoft tätig. Er beteiligt sich außerdem aktiv in der IT-Sicherheitscommunity von Seattle und ist Mitglied des Risikomanagementteams für ein IT-Einführungsprojekt.


 Mitteilung der Redaktion: Aus dem N&#228;hk&#228;stchen
Mitteilung der Redaktion
Aus dem Nähkästchen

SICHERLICH WIRD WINDOWS VISTA 2007 erhebliche Auswirkungen auf die IT-Abteilungen von Unternehmen haben. Wie InformationWeek berichtet, geht ein vor kurzem veröffentlichter IDC-Bericht davon aus, dass der „Schub“, der von Windows Vista ausgeht, allein in den USA in diesem Jahr für bis zu 100.000 neue Jobs im IT-Bereich sorgen wird. 2007 werden etwa 90 Millionen neue Computer mit Windows Vista-Installation ausgeliefert. Bis 2008 wird sogar auf 80 Prozent der an Unternehmen verkauften Computer Windows Vista installiert sein. Nutzen Sie die Zeit, um zu entscheiden, ob das Betriebssystem bereits in Ihrem Unternehmen eingesetzt werden soll. Wir können Ihnen dabei helfen.
In diesem Monat startet im TechNet Magazin eine Serie, die sich detailliert um das Herz von Windows Vista kümmern wird – den Kernel. Klar verfügt Windows Vista über einige interessante neue Funktionen, aber die können nicht der Hauptgrund für einen Wechsel sein. Der Kernel stellt das Herz des Betriebssystems dar, und der von Windows Vista wurde in seiner Funktionsweise bedeutend verbessert.
Kein Geringerer als Mark Russinovich, der den Windows-Kernel wahrscheinlich besser kennt als jeder andere auf dieser Welt, hat sich die Mühe gemacht, diese Änderungen zu beschreiben. Sein Buch Windows Internals, das er zusammen mit David Solomon verfasst hat, ist mittlerweile die beliebteste Quelle für alle diejenigen, die sich für entsprechende Geschichten aus dem Windows-Nähkästchen interessieren.
Diesen Monat erzählt Mark uns etwas über Verbesserungen bei den CPU-Zuordnungen, die Desktopanwendungen lebendiger machen werden, und beschreibt dann, wie Windows Vista die Multimedialeistung auf der Kernelebene erhöht. Der Autor beschreibt darüber hinaus auch wichtige Änderungen am E/A-Modell von Windows Vista wie beispielsweise dateibasierte symbolische Links, die neu implementierte Möglichkeit, synchrone E/A-Vorgänge abzubrechen, was meiner Meinung nach die wichtigste Änderung ist, und das Konzept der E/A-Priorität. Wir empfehlen Ihnen dringend, diesen umfassenden Artikel von Mark Russinovich zu lesen, wenn Sie darüber nachdenken, Windows Vista in Ihrem Unternehmen einzusetzen.
Selbstverständlich gibt es noch die alltäglichen Aufgaben, die zu erledigen sind, und wir können Ihnen dabei natürlich auch helfen. Diese Ausgabe konzentriert sich hauptsächlich auf die Windows-Verwaltung. Sie finden darin Artikel über das Delegieren von Berechtigungen in Active Directory, neue Gruppenrichtlinienvorlagen in Windows Vista, das Behandeln von Problemen bei Gruppenrichtlinien sowie die Überwachung von Active Directory mit MOM.
Wenn Sie gerne spielen und sich gleichzeitig in Sicherheit wiegen, sollten Sie sich unsere Geschichte über das Spielen in sicheren Umgebungen ansehen. Sie wissen ja, wie das ist: Kleine Spielereien bringen die grauen Zellen auf Trab. JOSHUA TRUPIN

Unser Dank gilt den folgenden technischen Experten von Microsoft: Matt Ayers, Eugene Bak, Vijay Bharadwaj, Michael Fortin, David Hicks, Khushru Irani, Mehmet Iyigun, Arun Kishan, Mark Lawrence, Pavel Lebedynskiy, Ben Mickle, Michael Murgolo, John Orefice, Ravisankar Pudipeddi, Jeffrey Richter, David Solomon, Jim Truher, Landy Wang und Andy Zeigler.


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

Verschieben von Daten
SQL Examiner Bundle
www.sqlaccessories.com
Unabhängig davon in welcher Funktion sie in einer Organisation tätig sind, sei es als Datenbankadministrator, Entwickler, Experte für Betriebsvorgänge oder in einer anderen Funktion, gilt Folgendes: Wenn Sie mit SQL Server™ arbeiten, mussten Sie wahrscheinlich schon einmal Daten zwischen Umgebungen verschieben und die Integrität der Daten und der Datenstrukturen sicherstellen. Natürlich verfügt SQL Server über viele integrierte Replikations- und Synchronisierungsfeatures. Wenn Sie jedoch prüfen möchten, ob Ihre QA-Datenbank genau mit Ihrer Entwicklungsdatenbank übereinstimmt, ist ein Tool wie SQL Examiner Bundle von TulaSoft ausgesprochen hilfreich, weil es Ihnen Zeit und Mühe spart.
Damit die Anwendung Unstimmigkeiten zwischen zwei Datenbankinstanzen feststellen kann (und zwar sowohl in der Datenbankstruktur als auch innerhalb der Daten), sind nur ein paar Mausklicks erforderlich. Sie stellen die Anwendung einfach auf die Datenbanken ein, die Sie überprüfen möchten, und alles andere erfolgt automatisch. Wie der Name besagt, bündelt SQL Examiner Bundle zwei Anwendungen: SQL Examiner und SQL Data Examiner. SQL Examiner untersucht die Struktur Ihrer Datenbanken, während SQL Data Examiner alle Daten untersucht und die Unterschiede hervorhebt.
Durch SQL Examiner wird der gesamte Inhalt Ihrer Datenbankinstanzen unter die Lupe genommen, von Tabellen und gespeicherten Prozeduren bis zu Volltextkatalogen und Auflistungen von XML-Schemas. Benutzer, die SQL Server 2005 verwenden, können außerdem CLR-Assemblys (Common Language Runtime) miteinander vergleichen. Beim Vergleich von Datenbanken können Sie mit SQL Examiner auswählen, welche Datenbankobjekte synchronisiert werden sollen und in welcher Richtung die Synchronisierung erfolgen soll.
Untersuchen und Vergleichen von Datenbanken mit SQL Examiner
Untersuchen und Vergleichen von Datenbanken mit SQL Examiner (Klicken Sie zum Verkleinern auf das Bild)
Untersuchen und Vergleichen von Datenbanken mit SQL Examiner
Untersuchen und Vergleichen von Datenbanken mit SQL Examiner (Klicken Sie zum Vergrößern auf das Bild)
Ein höchst interessantes Feature von SQL Examiner besteht darin, dass die Anwendung das SQL-Skript generiert, das ein Objekt erstellt, und in diesem generierten Skript den Unterschied zwischen Ihren Datenbanken hervorhebt. Dies stellt eine gute Möglichkeit zur Fehlerhervorhebung dar, nachdem ein Erstellungs- oder Migrationsskript beim Aufbau der Struktur Ihrer Zieldatenbank fehlgeschlagen ist. („An dieser Stelle fehlt der gruppierte Index.“) Sie können die generierten Skripts einzeln ausführen oder für die spätere Ausführung speichern, oder Sie können einfach auf die Schaltfläche zum Synchronisieren klicken, damit die Anwendung die ganze Arbeit übernimmt.
Ein anderes nützliches Feature ist die Möglichkeit, Elemente vom Vergleich auszuschließen, wie z. B. durch Ignorieren von Kommentaren, Triggern, Indizes oder erweiterten Eigenschaften eines Objekts. Nachdem Sie den Strukturvergleich untersucht haben, können Sie mit SQL Data Examiner die Daten auf eventuelle Unstimmigkeiten überprüfen. Sie können wählen, welche Tabellen Sie vergleichen möchten, und die Spalten bestimmen, die in den angegebenen Tabellen zum Vergleich herangezogen werden. Nachdem der Vergleich der Datentabellen abgeschlossen ist, können Sie sehen, welche Zeilen identisch und welche unterschiedlich sind bzw. welche sich nur in der einen, jedoch nicht in der anderen Datenbank befinden.
Wie bei SQL Examiner können Sie mit SQL Data Examiner auf eine Schaltfläche klicken, um die Tabellen zu synchronisieren, oder Sie können auswählen, welche Daten übertragen werden sollen. Außerdem können Sie die Richtung dieser Übertragung festlegen. In beiden Anwendungen können Sie Ihr Setup als Projekt speichern, sodass Sie die Aufgaben nicht jedes Mal neu erstellen müssen. Beide Anwendungen sind getrennt erhältlich, werden jedoch erfahrungsgemäß oft zusammen erworben.
Preis: 299,95 $ für eine Einzelbenutzerlizenz.

Suchen nach duplizierten Dateien
zsDuplicateHunter (Professional Edition)
Zizasoft
Wenn Sie im Bereich Desktopverwaltung tätig sind, haben Sie zweifellos schon einmal einen Benutzer angetroffen, der auf seinem Computer „keinen Platz mehr“ hat. Bei genauerem Hinsehen stellen Sie fest, dass dieser Benutzer seine Dokumente bei jeder Bearbeitung kopiert hat, obwohl allen Benutzern ein gesichertes NAS-System (Network Attached Storage) zum Speichern von Dateien zur Verfügung steht. Oder Sie verfügen über einen Protokollserver mit Batchprozessen, durch die riesige Protokolle dupliziert wurden, die den gesamten zugeordneten Speicherplatz auf dem Server einnehmen. Eine mögliche Lösung für diese Probleme bietet zsDuplicateHunter Professional Edition, ein Java-basiertes Suchprogramm für Duplikate, das auf Windows®, Linux oder Mac Os X ausgeführt werden kann.
Mit dieser Anwendung können Sie leicht Laufwerke, Verzeichnisse oder Netzwerkfreigaben suchen und mögliche Duplikate erkennen. Über Namensvergleiche hinaus ermöglicht die Anwendung die Gruppierung von Dateien nach Dateigröße, Dateiprüfsumme oder sogar Dateidigestberechnung, damit gewährleistet ist, dass die bereinigten Dateien tatsächlich verschieden sind. Abgesehen davon müssen Sie Ihre Duplikate nicht endgültig löschen. Als Vorsichtsmaßnahme ermöglicht Ihnen die Anwendung, alle markierten Duplikate in einen angegebenen Ordner zu verschieben.
Ein anderes nützliches Feature ist die Option „Keep Files in this Folder, Delete Duplicates Elsewhere“ (Dateien in diesem Ordner beibehalten, Duplikate an anderen Orten löschen), mit der Sie ein sauberes Quellverzeichnis auswählen und alle anderen Verzeichnisse, die sich möglicherweise auf dem Datenträger befinden, löschen können. Innerhalb der Suchergebnisse können Sie außerdem auf Dateien doppelklicken, um sie mit einer zugehörigen Dateianzeige zu öffnen, sowie Dateien sortieren und auswählen, um das gewünschte Ergebnis zu erzielen. Mit dem hilfreichen „IT Pro“-Feature können Sie bestimmen, wie viel Speicherplatz die Anwendung bei der Suche nach Duplikaten einnehmen darf. Als zusätzlichen Schutz können Sie die Suche nach ausgeblendeten oder Systemdateien deaktivieren, um sicherzustellen, dass Sie keine falschen Dateien oder eine Datei löschen, die vom Betriebssystem oder einer anderen Anwendung verwaltet wird.
Die Professional Edition stellt Ihnen außerdem einen genau abgestimmten Filter für Ihre Suchergebnisse zur Verfügung, sodass Sie einen regulären Ausdruck anwenden können, um genau die zu löschenden Dateien zu finden.
Preis: 39,95 $ für eine Einzelbenutzerlizenz.

Mobile Anwendungen
MojoPac
www.mojopac.com
Wenn Sie von Umgebung zu Umgebung wechseln und Ihre Lieblingsanwendungen und Desktopeinstellungen vermissen, oder wenn Sie Ihre Spuren nicht gern auf fremden Desktops hinterlassen, sollten Sie sich MojoPac von RingCube Technologies näher ansehen.
Mit MojoPac können Sie Ihre Einstellungen und Anwendungen mithilfe einer USB-Festplatte, eines persönlichen Mediengeräts, das Sie über USB 2.0 mit einem Hostsystem verbinden können (z. B. Zune oder iPod), oder sogar mithilfe eines Mobiltelefons, das über genug Speicherplatz verfügt, auf ein beliebiges Windows XP-System (Home, Professional, Media Center oder Tablet) übertragen. Zum Zeitpunkt der Erstellung dieses Artikels werden Windows Vista™- und Windows 2000-Hosts nicht unterstützt. In der Dokumentation auf der Produktwebsite wird jedoch ein Upgrade zur Unterstützung dieser Betriebssysteme in Aussicht gestellt.
Mobile Einstellungen mit MojoPac
Mobile Einstellungen mit MojoPac (Klicken Sie zum Verkleinern auf das Bild)
Mobile Einstellungen mit MojoPac
Mobile Einstellungen mit MojoPac (Klicken Sie zum Vergrößern auf das Bild)
Derzeit sind zur Verwendung von MojoPac Administratorrechte auf dem Hostsystem erforderlich. Version 2.0, die sich in Entwicklung befindet, wird jedoch über Unterstützung für begrenzten Benutzermodus verfügen. Durch das Tool erfolgt eine Interferenz zwischen dem Hostbetriebssystem und den Speichervorrichtungen, und beim ersten Start nach der Anwendungsinstallation auf Ihrem tragbaren Gerät löst MojoPac die anfängliche Windows-Kontoeinrichtung aus, wodurch Ihre persönlichen Einstellungen für den MojoPac-Benutzer auf das MojoPac-Gerät konfiguriert werden.
Nachdem dies ausgeführt wurde, ist das Umschalten zwischen dem Hostsystem und dem Mojo-System mühelos: Klicken Sie dazu einfach oben auf Ihrem Bildschirm auf die Symbolleiste (die minimiert werden kann). Während MojoPac aktiviert ist, können Sie Ihre Anwendungen in gewohnter Weise auf Ihrem Mojo-Gerät installieren. Solange Sie die eindringliche Warnung in den Readme-Dokumenten über das Installieren im Standardverzeichnis beachten, sollte die Verwendung kein Problem sein.
MojoPac stellt potenziell ein großartiges Hilfsmittel für IT-Experten dar, die auch unterwegs nicht auf das eigene Setup verzichten möchten. So können Sie beispielsweise alle Ihre Systemdienstprogramme, Paketsniffer und Datenverkehrsmonitore auf Ihrem MojoPac mit sich tragen und die Problembehandlung von einem beliebigen PC in Ihrer Organisation ausführen, ohne jegliche Spuren zu hinterlassen.
Preis: 49,99 $ für eine Einzelbenutzerlizenz.

Buchbesprechung
Administrator’s Guide to SQL Server 2005
www.aw-bc.com
Immer mehr IT-Gruppen erkennen, welches Potenzial in puncto Leistung und Funktionalität in SQL Server 2005 steckt. Vom umfangreichen XML-Datensupport über SQL Server Integration Services (SSIS) bis zum SQL Server 2005 Service Broker steuert die Anwendung viele nützliche Verbesserungen bei. Als Starthilfe auf Ihrem Weg zur Aktualisierung bzw. um die Verwaltung Ihrer kürzlich veröffentlichten SQL Server 2005-Instanz zu unterstützen, hat Buck Woody ein ausgezeichnetes Nachschlagewerk verfasst: den Administrator’s Guide to SQL Server 2005 (Addison-Wesley Professional, 2006).
Über dieses Buch erhalten Sie einen Einblick in praktische Verwaltungsmethoden, wie sie auch auf der neuen Serverplattform angewendet werden. Darüber hinaus zeichnet es sich im Unterschied zu vielen anderen Nachschlagewerken durch seine Ausführlichkeit aus. Es beginnt mit einem Abschnitt über die korrekte Planung Ihrer Infrastruktur, um den Anforderungen Ihrer Anwendung gerecht zu werden, und bietet einen Leitfaden dafür, welche SQL Server-Version für die unterschiedlichen Szenarios in Frage kommt. Sie erfahren außerdem, wie Sie Ihre Infrastruktur entwerfen können, um sicherzustellen, dass Sie nicht mit vermeidbaren Leistungsengpässen auf Ihrer Installation konfrontiert werden.
Im Handbuch werden ferner die verschiedenen Tools beschrieben, die SQL Server bereitstellt, z. B. der erweiterte SQL Server Profiler und das neue SQL Server Management Studio. Sie erhalten einen detaillierten Einblick in Wartungs- und Automatisierungsaufgaben und erfahren, wie Sie auf der Grundlage der Serverprofilerstellung für Wachstum planen sowie einen geeigneten Wartungsplan für Ihre Implementierung erstellen können.
Im Kapitel über Sicherheit wird beschrieben, wie Sie Ihre Installation vom Netzwerk und der Hardware aus über die Betriebssystem- und die SQL Server-Instanz sichern. Sie erhalten einen Einblick in die zusätzlichen Verschlüsselungs-, Zertifikats- und Hauptverwaltungsdienste, die von der neuen Plattform bereitgestellt werden.
In einem weiteren Kapitel werden die verfügbaren Mechanismen erläutert, über die den Anforderungen Ihrer Implementierung entsprechend die hohe Verfügbarkeit Ihres Systems gewährleistet werden kann. Es werden Methoden wie die Clustererstellung, Datenbankspiegelung, Replikation und der Protokollversand untersucht, mit denen Sie Ihre Betriebszeitanforderungen erfüllen können. Angesichts der fortschreitenden Virtualisierung, mit der sich sehr gut eine hohe Verfügbarkeit ohne die Belastung physisch unterschiedlicher Infrastrukturen erzielen lässt, bietet das Buch eine schrittweise Anleitung zur Einrichtung eines Clusters mit zwei Knoten unter Verwendung von Microsoft Virtual Server.
Im Kapitel über SSIS wird veranschaulicht, wie Sie mit dem neuen Tool (das DTS ersetzt) nicht nur ETL-Funktionen (Extraktion, Transformation, Laden) entwickeln und bereitstellen, sondern auch Überwachungs-, E-Mail-Benachrichtigungs- und Sicherungsaufgaben erstellen können.
In den letzten Kapiteln werden die Berichts- und Analysedienste der neuen SQL Server-Plattform behandelt. Hier werden die Themen Berichtentwurf und -erstellung und die Verwaltung von Berichtssystemen angeschnitten, und Sie erfahren, was zur Wartung einer Bereitstellung von Analysediensten erforderlich ist.
Der Administrator’s Guide to SQL Server 2005 bietet insgesamt eine hervorragende Einführung in das Verwalten und Überwachen von sowie das Aktualisieren auf SQL Server 2005.
Preis: $49.99.


 SQL&#160;–&#160;Fragen und Antworten: Datenbankgr&#246;&#223;e, Spiegelung, markierte Transaktionen und mehr
SQL – Fragen und Antworten
Datenbankgröße, Spiegelung, markierte Transaktionen und mehr
Herausgegeben von Nancy Michell

Verschieben eines Clusters
F Ich muss einen SQL Server 2000-Cluster zu neuen IP-Adressen verschieben, und zwar sowohl für die physischen Server als auch die Windows®- und SQL Server™-Cluster. Muss ich dazu die ganze Lösung neu erstellen?
A Nein, Sie müssen nur das SQL Server-Setup ausführen und die IP-Adressen ändern. Hier ist ein Knowledge Base-Artikel mit Anleitungen.

Datenbankgröße
F Ich führe SQL Server 2000 SP4 mit einer wichtigen Datenbank von fast 10 GB, einem Wiederherstellungsmodell des Typs SIMPLE, einer primären Datei von 9850 MB und einer Transaktionsprotokolldatei von 88 MB aus. Die Größe der Datenbanksicherung beträgt ebenfalls fast 10 GB. Soll ich die Größe der Datenbank verringern, um die Leistung zu verbessern? Falls ja, soll ich DBCC SHRINKDATABASE oder DBCC SHRINKFILE verwenden? (Leider stehen mir für diese Wartungsaktion nur die Hauptlastzeiten zur Verfügung.)
A DBCC SHRINKDATABASE oder DBCC SHRINKFILE sind nur dann von Nutzen, wenn in der Datenbank viele Löschungen und Aktualisierungen vorgenommen werden, die zu einem kleineren Volumen der Daten führen. Die eigentliche Frage ist jedoch, warum Ihnen dies so wichtig ist. Ein 10-GB-Speicher kostet heutzutage ca. 20 Euro. Wäre es nicht sinnvoller, einen zusätzlichen Speicher von 100 GB hinzuzufügen und die Ausführung fortzusetzen? Die Leistung wird sich durch die erhöhte Fragmentierung verschlechtern, doch wenn Sie keine Wartung vornehmen können, haben Sie kaum eine andere Wahl. In solchen Fällen setzen manche Benutzer eine zweite Kopie der Datenbank ein. Sie erstellen eine Sicherungskopie mit aktueller Replikation, nehmen eine Wartung der Sicherungskopie vor und verknüpfen dann die Anwendungen mit der Sicherungskopie. Hierfür sind natürlich einige Codeänderungen und ein Wechsel vom Wiederherstellungsmodell des Typs SIMPLE (zum Typ FULL oder BULK_LOGGED) erforderlich. Dies könnte jedoch langfristig eine gute Lösung darstellen.

Aktualisieren und Leistung
F Ich muss zwei Anwendungen von SQL Server 2000 zu SQL Server 2005 verschieben. Wie kann ich Leistungseinbußen während der Aktualisierung vermeiden?
A In der Regel können die folgenden Szenarien einen Leistungsabfall verursachen und sollten nach Möglichkeit vermieden werden:
  1. Sie haben die Statistik nach dem Aktualisieren auf SQL Server 2005 nicht neu erstellt.
  2. Sie verwenden JOINS- und WHERE-Klauseln, die zwei verschiedene Datentypen miteinander vergleichen. Dies führt insbesondere dann zu einer Leistungsverminderung, wenn auf dem Server SQL Server 2000 SP3 oder eine vorherige Version ausgeführt wurde (siehe support.microsoft.com/kb/271566/).
  3. Die SQL Server 2005-Instanz ist nicht richtig konfiguriert. Speicher, Erweiterungen für die Adressfenstersteuerung, Treiber und so weiter sind falsch konfiguriert. Das System, auf dem SQL Server 2000 ausgeführt wird, wurde optimiert, doch der dafür verantwortliche Benutzer hat die Firma verlassen, ohne das Verfahren zu dokumentieren. Aus diesem Grund wurde die Optimierung für die SQL Server 2005-Instanz nicht durchgeführt.
  4. Die Hardware ist fehlerhaft. Oft wird neue Hardware gekauft, weil sie in der Werbung angepriesen wurde. In der Praxis hält sie jedoch oft den Anforderungen nicht stand.
Vor dem Einsatz einer SQL Server-Instanz sollte ein Leistungsvergleich vorgenommen werden, um sicherzustellen, dass die von Ihnen erwartete Leistung tatsächlich erzielt werden kann. Dadurch kann die Infrastruktur als mögliches Problem ausgeschlossen werden. Prüfen Sie dazu Leistungsindikatoren wie z. B. Datenträger, E/A und Speicher, und vergleichen Sie diese bei den verschiedenen Instanzen.

Datenbankspiegelung
F Ich verwende die Datenbankspiegelung und möchte die Datenbankoption READ_COMMITTED_SNAPSHOT aktivieren. Wenn ich versuche, die Option zu aktivieren, nachdem die Spiegelung eingerichtet wurde, erhalte ich eine Fehlermeldung mit der Information, dass die sich Datenbank in einer Spiegelungssitzung befindet, und der Befehl kann nicht ausgeführt werden.
A Zum Einrichten der Option READ_COMMITTED_SNAPSHOT ist ein Neustart der Datenbank erforderlich. Daher müssen Sie die Spiegelungssitzung unterbrechen, die Option festlegen und die Datenbank neu starten. Nachdem diese Schritte durchgeführt wurden, können Sie die Spiegelung neu einrichten. Die Spiegeldatenbank ruft die Option ab, sobald die Sitzung eingerichtet ist, und verwendet sie im Falle eines Failovers.

F Ich versuche, eine asynchrone Spiegelung einzurichten, und erhalte den Fehler 1418. Beim Ausführen von Netstat -ano zeigt sich, dass SQL Server auf allen Servern auf dem richtigen Port abfragt. Der Fehler wird angezeigt, wenn ich versuche, die Spiegelung zu starten. Was ist die Ursache des Problems?
A Eine Möglichkeit ist, dass Ihre Firewall die Kommunikation blockiert. Dies ist ein relativ häufiges Problem, das Sie untersuchen sollten. Weitere Informationen finden Sie in den folgenden Whitepapers: Troubleshooting Database Mirroring Setup (in englischer Sprache) unter und MSSQLSERVER_1418.
Beachten Sie dabei, dass sich dieses Problem nicht spezifisch auf die asynchrone Spiegelung bezieht. Es kann ebenso bei einer synchronen Spiegelung auftreten.
Die angezeigte Fehlermeldung (die besagt, dass die Servernetzwerkadresse nicht erreicht werden kann oder nicht vorhanden ist und in der Sie aufgefordert werden, den Netzwerkadressennamen zu prüfen und den Befehl erneut einzugeben) ist korrekt. Oft liegt es nicht daran, dass der Remotepartner nicht vorhanden ist, sondern dass der Remotepartner einfach nicht erreicht werden kann.
Dies kann passieren, wenn der Remotepartner heruntergefahren ist, den Port nicht abruft oder sogar wenn der Endpunkt heruntergefahren ist (möglicherweise können die Partner nicht den gleichen Verschlüsselungsmechanismus verwenden, oder es liegt ein anderes Authentifizierungsproblem vor). Außerdem kann dies passieren, wenn der Partner blockiert wird, was möglicherweise auf die Firewall des Partners zurückzuführen ist, der den Befehl initiiert.
Überprüfen Sie auch, ob möglicherweise ein Problem mit den Datenquellennamen (DSN) oder bei der Namensauflösung vorliegt. Die allgemeine Empfehlung lautet, vollständig qualifizierte Domänennamen zu verwenden. Auch wenn das Problem oft auf Ihre Firewall zurückzuführen ist, sollten Sie bedenken, dass es noch viele andere Ursachen gibt.

F Ich möchte die SQL Server 2005-Spiegelung verwenden, habe jedoch gehört, dass sie nicht empfohlen wird, wenn mehrere Anwendungen eine Verbindung zu mehreren Datenbanken auf der gleichen SQL Server-Instanz herstellen. Ist dies richtig?
A Das hängt davon ab, ob jede Anwendung über ihre eigene Datenbank verfügt oder ob die Anwendungen datenbankübergreifende oder DTC-Transaktionen (Distributed Transaction Coordinator) verwenden. Wenn datenbankübergreifende Transaktionen vorliegen, kann das Spiegeln logische Inkonsistenzen zur Folge haben, in denen Transaktionen nicht erwartungsgemäß übermittelt werden. Eine gute Erklärung dafür, was unter diesen Umständen geschieht, erhalten Sie hier.
Wenn es mehrere Datenbanken gibt, die von mehreren Anwendungen verwendet werden, und jede Anwendung über ihre eigene Datenbank verfügt, wird das Spiegeln diese Probleme nicht verursachen.

Markierte Transaktionen
F Was sind markierte Transaktionen, und können sie verwendet werden, wenn es sich bei einer der Datenbanken um eine SQL Server- und bei der anderen um eine Oracle-Datenbank handelt?
A Das Markieren einer Transaktion ist eine vom Datenbankadministrator regelmäßig durchgeführte Aktion, durch die in allen Protokollen an der gleichen Stelle eine Markierung eingefügt wird. Zusammen mit der Möglichkeit, eine Tabelle bis zu einer Transaktionsmarkierung wiederherzustellen, wird es Ihnen durch diese Aktion erlaubt, alle Datenbanken bis zum gleichen Punkt wiederherzustellen. Die Wiederherstellung kann insgesamt recht unerfreulich sein, da Sie alle relevanten Datenbanken wiederherstellen müssen und dabei in allen Datenbanken Daten verloren gehen. Deshalb sollten Sie dies vermeiden, indem Sie sicherstellen, dass Sie Ihre Protokolldateien nicht verlieren. Markierte Transaktionen sind SQL Server-spezifisch. Falls Ihre verteilten Transaktionen andere Datenbanken als SQL Server-Datenbanken umfassen, kann für diese keine Transaktionsmarkierung vorgenommen werden. Im Allgemeinen verwenden nur wenige verteilte Datenbanksysteme Transaktionsmarkierungen. In diesen Systemen ist der Verlust eines Transaktionsprotokolls ein schwerwiegendes Ereignis, für das viel manuelle Arbeit erforderlich ist, um den vorherigen Zustand wiederherzustellen.

Access-To-T-SQL-Konvertierungstool
F Gibt es ein automatisiertes Access™-To-T-SQL-Konvertierungstool, das für gespeicherte Prozeduren verfügbar ist?
A Versuchen Sie es mit SSMA (SQL Server Migration Assistant). Diese Komponente steht als Download zur Verfügung. Dort finden Sie außerdem SQL Server Migration Assistant for Oracle, SQL SQL Server Migration Assistant for Sybase und Migrating Informix Databases to Microsoft® SQL Server 2000.
Zum Aktualisieren von Access auf SQL Server könnten Sie auch den Office Upsizing-Assistenten verwenden. SSMA for Access (siehe Abbildung 1), bietet jedoch mehr Features, einschließlich Konvertierungsbewertungsberichte und Netzwerkscans. SSMA for Access behebt außerdem viele Probleme, die derzeit vom Office Upsizing-Assistenten nicht korrekt gehandhabt werden.
Abbildung 1 SQL Server Migration Assistant for Access
Abbildung 1 SQL Server Migration Assistant for Access (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 1 SQL Server Migration Assistant for Access
Abbildung 1 SQL Server Migration Assistant for Access (Klicken Sie zum Vergrößern auf das Bild)

Nicht gruppierte Indizes
F Ich habe eine Tabelle vorliegen, in der der Primärschlüssel aus zwei GUID besteht (GUID1 und GUID2). Ich verfüge bereits über einen eindeutigen gruppierten Index für GUID1 und GUID2. Aus Leistungsgründen will ich jetzt den zweiten nicht gruppierten Index für GUID2 und GUID1 erstellen. Ist ein zusätzlicher Leistungsaufwand erforderlich, wenn ich den Index als eindeutig deklariere?
A Die Leistung wird nicht beeinträchtigt, wenn Sie den nicht gruppierten Index als eindeutig deklarieren. Dies könnte sogar weniger Ebenen in der Indexstruktur zur Folge haben.
Wenn ein nicht gruppierter Index als nicht eindeutig deklariert wird, wird der Zeilenlokalisierer an den Hauptteil der Indexeinträge in den Seiten des Stamms und des inneren Knotens angehängt. Dadurch wird das Löschen und Aktualisieren von Indexeinträgen erleichtert, was das Scannen einer Synonymkette vermeidet, falls Duplikate eines Schlüssels vorhanden sind. Der entsprechende Eintrag, der geändert werden soll, kann über einen Systemsuchvorgang nach Schlüssel und Lokalisierer gefunden werden. Das Ergebnis ist, dass die Einträge länger sind (und zwar beachtlich länger für den ausgewählten Gruppierungsschlüssel). Demzufolge werden die Seiten des Stamms und des inneren Knotens natürlich schneller gefüllt. Wenn der Index eindeutig ist, sollten Sie ihn als solches deklarieren.
Unabhängig davon, ob die Tabelle einen gruppierten Index enthält oder nicht, wird bei jedem nicht gruppierten Tabellenindex, der nicht als eindeutig deklariert ist, der Lokalisierer an die Indexeinträge in den Stammseiten und anderen Seiten des inneren Knotens angehängt.
Auch wenn Sie eine int-Kennungsspalte als Ersatzschlüssel verwenden und dann zwei eindeutige Indizes, (GUID1, GUID2) und (GUID2, GUID1), hinzufügen, wird die Leistung dadurch wahrscheinlich verbessert, da die Indizes über einen 4-Byte-Gruppierungsschlüssel anstelle eines 32-Byte-Gruppierungsschlüssels verfügen.

Aktualisierungssperren
F Ich habe eine gespeicherte Prozedur mit der folgenden Struktur:
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION

-- Get The lock if available
UPDATE    ProcessingInstances
SET       LockHolder = @MessageId
WHERE     ( InstanceId = @InstanceId )
AND       ( LockHolder IS NULL )

COMMIT TRANSACTION
Diese gespeicherte Prozedur lässt nur einen Abruf durch die Sperre, während alle anderen Abrufe warten müssen. Kann ich das gleiche Verhalten durch Herabsetzen der Isolierungsstufe erreichen?
READ COMMITTED scheint die richtige Isolierungsstufe zu sein, weil diese Transaktion nur eine Abfrage enthält. Wenn eine andere Transaktion gerade den gleichen Datensatz aktualisiert, wartet diese Transaktion auf die andere. Ist dies richtig?
A Es ist nicht die serialisierbare Einstellung in Ihrem Beispiel, die die anderen Abrufe warten lässt, es ist die Aktualisierung selbst. Sie können die Isolierung auf READ COMMITTED einstellen. In diesem Falle wird durch die Aktualisierung automatisch eine Aktualisierungssperre auf den derzeit verwendeten Index angewendet. Dies verursacht Probleme für andere Prozesse, die die gleiche Anweisung ausführen, und die Prozesse werden blockiert, bis die Aktualisierung abgeschlossen ist. (Sie benötigen auch keine explizite Transaktion, wenn die Aktualisierung die einzige Anweisung ist. Jede Anweisung befindet sich implizit in ihrer eigenen Transaktion, falls sie sich nicht in einer expliziten befindet.)
Wenn es jedoch keine Zeilen gibt, die mit der WHERE-Klausel in der UPDATE-Anweisung übereinstimmen, dann verhindert die Verwendung der serialisierbaren Isolierungsstufe, dass solche Zeilen in anderen Transaktionen eingefügt oder geändert werden. Wenn Sie die Aktualisierungsanweisung in der READ COMMITTED-Isolierung ausführen, ist dies nicht der Fall, und andere Transaktionen können Zeilen einführen, die für die Aktualisierung in Frage kommen. Wenn der Code für die gespeicherte Prozedur dem Code entspricht, den Sie angegeben haben, macht es möglicherweise keinen Sinn, diese Aktionen auszuführen (weder die serialisierbare Variante noch die Transaktionsvariante). Führen Sie einfach nur die Aktualisierung durch.

Unser Dank gilt den folgenden Microsoft-IT-Experten für ihre fachliche Unterstützung: Gaurav Aggarwal, Anthony Bloesch, Todd Briley, Shaun Cox, Roberto Di Pietro, Michael Epprecht, Kevin Farlee, Umachandar Jayachandran, Chuck Ladd, Kaloian Manassiev, Luciano Moreira, Ward Pond, Mark Prazak, Arunachalam Thirupathi, Roger Wolter, Clement Yip und Frankie Yuen.


 Schwerpunkt Dienstprogramme: Group Policy Inventory
Schwerpunkt Dienstprogramme
Group Policy Inventory
Greg Steen
Laden Sie den Code für diesen Artikel herunter: GPInventory.exe (150KB)

WIE KÖNNEN SIE wissen, über welches Inventar Sie verfügen, wenn Sie es nicht überwachen? Der direkte Zugriff auf Inventarinformationen erspart Ihnen viele Sorgen, wenn Besprechungen zur Budgetvergabe und die jährlichen Abschlussprüfungen anstehen. Hinzu kommt, dass Vorgesetzte scheinbar ständig wissen wollen, wer über welches Inventar verfügt und warum und welcher Aufwand mit der nächsten größeren Aktualisierung verbunden ist.
Ein Tool, das Ihnen bei all dem helfen kann, ist Group Policy Inventory (GPInventory.exe), das im Windows Server® 2003 Resource Kit enthalten ist. Mit diesem Programm können Sie mithilfe von Richtlinienergebnissatz (Resultant Set of Policy, RSoP)- und/oder WMI (Windows® Management Instrumentation, Windows-Verwaltungsinstrumentation)-Abfragen Systeminformationen von mehreren Remotehosts abrufen (siehe Abbildung). Erwartungsgemäß lassen sich mit diesem Programm mühelos Gruppenrichtlinieninformationen abrufen. Es stellt jedoch auch ein effektives Mittel zum Abrufen ausführlicher Systeminformationen dar, z. B. Informationen zu installierten Anwendungen, Prozessorname und -geschwindigkeit sowie eine Liste der installierten Hotfixes. Das ist aber noch nicht alles. Da das Programm Bestandteil des Windows Server 2003 Resource Kits ist, erhalten Sie es absolut kostenlos.
Abbildung 1 Sammeln von Informationen mit GPInventory
Abbildung 1 Sammeln von Informationen mit GPInventory (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 1 Sammeln von Informationen mit GPInventory
Abbildung 1 Sammeln von Informationen mit GPInventory (Klicken Sie zum Vergrößern auf das Bild)
Für die Verwendung von GPInventory.exe gibt es zahlreiche Möglichkeiten. Wenn Sie z. B. den Garantiestatus überprüfen müssen, können Sie die Serien- oder Servicenummern der PCs in Ihrem Netzwerk erfassen, ohne sich an jeden einzelnen Computer setzen zu müssen. Falls Sie über eine Testumgebung verfügen und feststellen möchten, ob ein bestimmter Computer gerade verwendet wird, könnten Sie bequem von Ihrem Arbeitsplatz aus die Benutzer abfragen, die derzeit beim System angemeldet sind. Wenn Sie einen Bladeserver eingerichtet haben, bei dem regelmäßig Abbilder auf den Blades gespeichert werden (z. B. zum Bereinigen und Wiederherstellen Ihrer QA-Umgebung), könnten Sie das Installationsdatum des PCs abfragen, um zu überprüfen, wann das letzte Abbild angewendet wurde.
GPInventory zeichnet sich zudem durch eine unkomplizierte Verwendung aus. Sie geben eine Datei an, die eine Liste der Computer enthält, die Sie dem Inventar hinzufügen möchten, wählen die auszuführenden Abfragen aus und verarbeiten dann die Liste. Das Tool stellt daraufhin eine Verbindung zu jedem Computer in der Liste her und fragt ihn ab. Wenn Sie eine Schnellabfrage ausführen, können Sie zudem die Zielcomputer direkt aus Active Directory® und die durchzuführenden Abfrageaktionen im Menü „Abfrage“ auswählen.
Um eine Richtlinienergebnissatzabfrage auf einem Computer ausführen zu können, benötigen Sie die Berechtigung „Richtlinienergebnissatz erstellen (Protokollierung)“. (Domänenadministratoren und delegierte Administratoren verfügen standardmäßig über diese Berechtigung.) WMI-Abfragen erfordern Administratorrechte für den Remotecomputer, sofern Sie nicht mit dem MMC-Snap-In „WMI-Steuerung“ einem alternativen Benutzer Konto- und Remoteaktivierungsrechte für den Namespace „root\cimv2“ gewähren.
Wenn Sie Ihre Abfrage ausgeführt haben, können Sie die Ergebnisse als tabstoppgetrennte Textdatei oder im XML-Format speichern. Beide Versionen können zu Analysezwecken in Microsoft® Excel® importiert werden. Sie können die Daten sortieren und dann einen AutoFilter anwenden, um alle Details zu finden.
Da GPInventory auch die Befehlszeilenausführung unterstützt, können Sie mit wenig Aufwand einen geplanten Task zum Abfragen von Systeminformationen einrichten und ihn direkt in einer XML-Datei speichern, ohne dass Eingriffe über die grafische Benutzeroberfläche erforderlich sind. Dies kann für Abfragen mit langer Laufzeit sehr nützlich sein, die sich besser für die Ausführung außerhalb der normalen Arbeitszeiten eignen.
Im Lieferumfang des Tools ist ein Standardsatz von RSoP- und WMI-Abfragen enthalten. Sie können jedoch die Abfragedatei mit Ihrer eigenen benutzerdefinierten Liste ergänzen, bearbeiten und aktualisieren, wenn die von Ihnen benötigten Elemente nicht enthalten sind. Das mitgelieferte Hilfedokument zeigt Ihnen, wie Sie in der XML-Datei mit der Abfrageliste eine neue Abfrage definieren können.
GPInventory.exe eignet sich hervorragend für das Sammeln von Informationen auf den Windows-Computern in Ihrem Netzwerk, unabhängig davon, ob Sie Inventar-, Gruppenrichtlinien- oder Statusinformationen benötigen. Sie finden auf unserer Website im Downloadbereich einen Link zum Group Policy Inventory-Tool.

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.


 The Cable Guy: QoS-Support in Windows
The Cable Guy
QoS-Support in Windows
Joseph Davies
Dieser Artikel basiert teilweise auf einer Vorabversion von Windows Server „Longhorn“. Änderungen an den in diesem Artikel enthaltenen Informationen sind vorbehalten.

Die Dienstqualität (Quality of Service, QoS) umfasst eine Reihe von Technologien zum Verwalten des Netzwerkverkehrs in kostengünstiger Weise, um die Benutzerfreundlichkeit in privaten und Unternehmensumgebungen zu verbessern. QoS-Technologien ermöglichen Ihnen, die Bandbreite zu messen, sich verändernde Netzwerkbedingungen zu erkennen (wie z. B. die Überlastung oder Verfügbarkeit der Bandbreite),
und Prioritäten für den Datenverkehr zu setzen bzw. den Datenverkehr zu drosseln. Beispielsweise kann QoS dazu eingesetzt werden, der Übermittlung von wartezeitempfindlichem Datenverkehr (wie z. B. Stimmen- oder Videoanwendungen) Priorität einzuräumen und die Auswirkungen des wartezeitempfindlichen Datenverkehrs, wie z. B. Massendatenübertragungen, zu kontrollieren. Das Festlegen von Prioritäten für die Übermittlung des TCP/IP-Datenverkehrs muss von Hosts und Netzwerkinfrastrukturgeräten unterstützt werden. In diesem Artikel werden die Methoden zum Verwenden von QoS mit Microsoft® Windows®-basierten Hosts behandelt.
Das zentrale Problem beim Definieren der QoS für TCP/IP-Netzwerke besteht darin, wie die priorisierte Übermittlung des IP-Datenverkehrs angegeben und bereitgestellt werden soll. Obwohl die ursprüngliche RFC 791 für IP das TOS-Feld (Type of Service) mit der Fähigkeit zur Angabe von Rangfolge, Verspätung, Durchsatz, Zuverlässigkeit und Kostenmerkmalen definiert hat, ist IP im Grunde eine datagrammbasierte Paketschaltertechnologie, die in der Regel jedes Paket gleich und nach Eingangsposition behandelt (zuerst eingegangene Pakete werden zuerst verarbeitet).

Das Konfigurieren priorisierter Übermittlungen
Um einen priorisierten Zustelldienst bereitzustellen, können Sie folgendermaßen vorgehen. Sie können die Netzwerkinfrastruktur konfigurieren, um eine Sonderverarbeitung für markierten Datenverkehr bereitzustellen, und veranlassen, dass die sendenden Hosts ihren ausgehenden Datenverkehr markieren. Alternativ können Sie veranlassen, dass die sendenden Hosts die Netzwerkinfrastruktur dynamisch programmieren, um eine Sonderverarbeitung bereitzustellen, die auf den Merkmalen ihres ausgehenden Datenverkehrs (wie z. B. Adressen und Portnummern) basiert.
Für den TCP/IP-Datenverkehr können Sie verschiedene Methoden verwenden, um eine priorisierte Übermittlung bereitzustellen. Beispielsweise werden auf der Netzwerkschnittstellenebene für Ethernet durch die IEEE 802.1p-Kennzeichnung Frames, die von einem Host für priorisierte Übermittlung gesendet werden, mithilfe eines 3-Bit-Prioritätsfelds im VLAN-Header des Ethernet-Frames markiert. Der VLAN-Header befindet sich innerhalb des Ethernet-Headers, zwischen dem Quelladressfeld und dem Längenfeld (für einen IEEE 802.3-Frame) oder dem EtherType-Feld (für einen Ethernet II-Frame).
Damit Sie die 802.1p-Kennzeichnung auf einem sendenden Host implementieren können, müssen der Netzwerkadapter und der Gerätetreiber 802.1p unterstützen. Darüber hinaus muss für den Netzwerkadapter die 802.1p-Unterstützung aktiviert sein. Sie können die 802.1p-Unterstützung normalerweise auf der Registerkarte „Erweitert“ des Eigenschaftendialogfelds des Netzwerkadaptertreibers aktivieren. Für Ethernet-Schalter muss ebenfalls die 802.1p-Unterstützung aktiviert sein.
Auf der Netzwerkschnittstellenebene für drahtlose IEEE 802.11-Netzwerke definiert die Wi-Fi Alliance-Zertifizierung für Wi-Fi Multimedia (WMM) vier Zugriffskategorien für die Priorisierung des Netzwerkverkehrs. Diese Zugriffskategorien lauten (von der höchsten zur niedrigsten Priorität): Stimme, Video, beste Leistung und Hintergrund. Für die Hostunterstützung für die WMM-Priorisierung ist erforderlich, dass sowohl Drahtlosnetzwerkadapter als auch ihre Treiber WMM unterstützen. Drahtlose Zugriffspunkte müssen WMM-aktiviert sein.
Auf Internetebene können Sie das Protokoll „Differentiated Services“ verwenden und den DSCP-Wert (Differentiated Services Code Point) im IP-Header festlegen. Wie in RFC 2472 definiert, wird der DSCP-Wert durch die höherwertigen 6 Bit des TOS-Felds der IP-Version 4 (IPv4) und des Traffic Class-Felds der IP-Version 6 (IPv6) dargestellt.
Die meisten modernen Unternehmensrouter unterstützen die DSCP-Datenverkehrsdifferenzierung. Sie ist jedoch standardmäßig deaktiviert. Beim Weiterleiten lesen DSCP-fähige Router den DSCP-Wert und reihen das Paket in eine spezifische Warteschlange ein. Beispielsweise können Sie Ihre Router so konfigurieren, dass sie weitergeleitete Pakete in die Warteschlange für hohe Priorität oder beste Leistung oder in eine Warteschlange auf niedrigerer Ebene einreihen, je nachdem, welchen DSCP-Wert Sie definieren. Durch Konfigurieren von Warteschlangen und DSCP-Werten kann DSCP-markierter Datenverkehr unterschiedliche Servicelevels haben. Beispielsweise wird wichtiger Netzwerkverkehr vorrangig weitergeleitet und durch anderen Massendatenverkehr mit geringerer Priorität nicht verzögert. Mithilfe der WMM-Spezifikation wird definiert, wie die WMM-Zugriffskategorien DSCP-Werten zugeordnet werden. Ein WMM-fähiger drahtloser Zugriffspunkt liest den DSCP-Wert und verarbeitet den Datenverkehr auf der Grundlage seiner Zugriffskategorie.
Auf Internetebene können Sie auch das RSVP (Resource Reservation Protocol) verwenden, ein in RFC 2205 definiertes, signalisierendes Protokoll. Hosts können mit diesem Protokoll versuchen, Bandbreite über ein Netzwerk bis zu einem Endpunkt zu reservieren. Die Verwendung von RSVP auf Netzwerken ist jedoch nicht weit verbreitet und wird derzeit von Windows XP, Windows Server® 2003, Windows Vista™ und der nächsten Version von Windows Server, die den Codenamen „Longhorn“ hat (derzeit in Beta), nicht unterstützt.
Um Pakete zu senden, die für eine priorisierte Übermittlung vorgesehen sind, müssen Anwendungen oder Betriebssystemkomponenten die Werte der 802.1p-Priorität oder den DSCP-Wert angeben können. In den folgenden Abschnitten wird beschrieben, wie Windows-Komponenten oder Windows-basierte Anwendungen die 802.1p-Priorität für Ethernet-Frames oder den DSCP-Wert für den TCP/IP-Datenverkehr angeben können.

QoS in Windows XP und Windows Server 2003
Windows XP und Windows Server 2003 stellen APIs für das Zuweisen von QoS-Parametern zu Datenverkehr bereit. Anwendungsentwickler können die Winsock-APIs (Windows Sockets) und GQoS-APIs (Generic QoS) verwenden, um QoS-Parameter auf der Anwendungsebene auf einer Pro-Socket-Basis anzuwenden. Netzwerkadministratoren können Datenverkehrsverwaltungstools verwenden, mit denen die TC-API (Traffic Control) aufgerufen wird, um QoS-Parameter auf der Hostebene anzuwenden.
Sie können Winsock und die IP_TOS-Socketoption benutzen, um den DSCP-Wert für ausgehende Pakete für einen Socket festzulegen. Standardmäßig ignoriert der TCP/IP-Stapel jedoch die IP_TOS-Socketoption. Um die IP_TOS-Socketoption zu verwenden, müssen Sie zuerst den DWORD-Registrierungswert „DisableUserTOSSetting=0“ unter dem folgenden Registrierungsschlüssel erstellen und festlegen (siehe Abbildung 1):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Abbildung 1 Einstellen des Registrierungswerts von DisableUserTOSSetting
Abbildung 1 Einstellen des Registrierungswerts von DisableUserTOSSetting
Sie müssen den Computer neu starten, damit diese Registrierungseinstellung wirksam wird.
Um den DSCP-Wert für Datenverkehr anzugeben, ohne die IP_TOS-Socketoption zu verwenden, benutzen Sie die GQoS-APIs. GQoS ist Teil von Windows Sockets 2.0 (Winsock2). Die meisten QoS-aktivierten Anwendungen verwenden die GQoS-API, um QoS-Funktionen in Windows aufzurufen. GQoS in Windows XP Service Pack 2 (SP2) ermöglicht, dass eine Anwendung einen DSCP-Wert festlegen und den ausgehenden Datenverkehr drosseln kann. Um 802.1p-Prioritäten auf Computern festzulegen, auf denen Windows XP SP2 ausgeführt wird, müssen Sie die TC-API verwenden.
Die TC-API bietet Zugriff auf Datenverkehr-Steuermechanismen, die den Netzwerkverkehr auf dem lokalen Host regeln. Sie ermöglicht eine direkte Kontrolle der DSCP-Werte, der 802.1p-Tags und der Drosselungsrate. Netzwerkadministratoren können Verwaltungsprogramme für den Datenverkehr verwenden, um die TC-API direkt für Anwendungen aufzurufen, die QoS nicht unterstützen. Da es sich bei der TC-API im Vergleich zur GQoS-API um eine API auf einer niedrigeren Ebene handelt, sind hierfür Administratorrechte erforderlich.
Im Gegensatz zur GQoS-API ermöglicht die TC-API, dass der Datenverkehr von mehreren Anwendungen auf demselben sendenden Host in einem einzigen QoS-Datenfluss gesammelt werden kann. Als Teil dieser Aggregation kann der Datenverkehr durch eine Kombination von Quell- und Ziel-IP-Adressen, Quell- und Zielports sowie das Protokoll (TCP oder UDP) identifiziert werden. Beispielsweise kann der gesamte Datenverkehr für eine bestimmte Ziel-IP-Adresse in einem einzigen QoS-Datenfluss für einen beliebigen Quell- und Zielport enthalten sein, unabhängig von der sendenden Anwendung auf dem Host. Die GQoS-API ermöglicht andererseits, dass eine Anwendung ihre eigene QoS-Behandlung für die Daten definieren kann, die sie über einen Socket sendet.
Zur Unterstützung der QoS-Funktion muss auf Windows XP- und Windows Server 2003-basierten Computern über die Eigenschaften der Netzwerkverbindungen im Ordner „Netzwerkverbindungen“ (siehe Abbildung 2) die QoS-Paketplanerkomponente installiert und aktiviert werden. Die QoS-Paketplanerkomponente (Psched.sys) wird bei Windows XP-Computern standardmäßig installiert und aktiviert. Die Paketplanerkomponente kann auf Windows Server 2003 installiert werden.
Abbildung 2 Konfigurieren des QoS-Paketplaners
Abbildung 2 Konfigurieren des QoS-Paketplaners

QoS in Windows Vista und Windows Server „Longhorn“
Der QoS-Support in Windows Vista und Windows Server „Longhorn“ wurde sowohl verbessert als auch vereinfacht. IT-Mitarbeiter können jetzt richtlinienbasierte Dienstqualität (QoS) verwenden, um DSCP-Werte festzulegen und die Senderaten von Anwendungen zu steuern, ohne APIs verwenden oder vorhandene Anwendungen ändern zu müssen. Entwickler erhalten Unterstützung für die GQoS- und TC-APIs. Dies ist jedoch für zukünftige Versionen von Windows nicht vorgesehen. Zudem wurde die IP_TOS-Winsock-Option entfernt. Um die GQoS- und TC-APIs zu ersetzen und den QoS-Support in aktualisierten oder zukünftigen Anwendungen zu vereinfachen, unterstützen Windows Vista und Windows Server „Longhorn“ die neue QoS2-API, die auch als qWAVE (Quality Windows Audio-Video Experience) bezeichnet wird.
Richtlinienbasierte Dienstqualität in Windows Server „Longhorn“ und Windows Vista ermöglicht es Ihnen, eine verbesserte Benutzerfreundlichkeit anzubieten, die Bandbreitenkosten zu kontrollieren oder besser abgestimmte Servicelevels mit Bandbreitenanbietern oder Geschäftsabteilungen auszuhandeln. Sie können die Netzwerkbandbreite von Computern unter Windows Vista oder Windows Server „Longhorn“ unabhängig von der Anwendung und über eine gesamte Active Directory®-Infrastruktur zentral verwalten. Da die Datenverkehrsverwaltung unter der Anwendungsebene stattfindet, müssen vorhandene Anwendungen für die richtlinienbasierte QoS-Datenverkehrsverwaltung nicht geändert werden.
Richtlinienbasierte QoS-Einstellungen in Windows Server „Longhorn“ und Windows Vista ermöglichen Ihnen die Priorisierung bzw. Verwaltung der Senderate für ausgehenden Datenverkehr in Übereinstimmung mit den folgenden Bedingungen:
  • Sendende Anwendung (ausführbarer Pfad und Name)
  • Quell- oder Ziel-IPv4 oder IPv6-Adressen oder Adresspräfixe
  • Protokoll (TCP, UDP oder beides)
  • Quell- oder Zielports oder Portbereiche (TCP oder UDP)
QoS-Richtlinien werden auf eine Benutzeranmeldesitzung oder einen Computer als Teil eines Gruppenrichtlinienobjekts (GPO) angewendet, das mit einem Active Directory-Container, wie z. B. einer Domäne, Site oder Organisationseinheit, verknüpft ist, oder sie können auf eine Sicherheitsgruppe angewendet werden. Als Teil von Gruppenrichtlinien bauen QoS-Richtlinien auf Ihrer vorhandenen Active Directory-Verwaltungsinfrastruktur auf.
Richtlinienbasierte QoS ermöglicht es Ihnen, die Priorität des Datenverkehrs festzulegen. Sie können eine QoS-Richtlinie konfigurieren, um ausgehenden IPv4- oder IPv6-Datenverkehr mit einem bestimmten DSCP-Wert zu markieren. Darüber hinaus können Sie die Verwendung der Bandbreite für ausgehenden Datenverkehr verwalten. Sie können eine QoS-Richtlinie mit einer Drosselungsrate für ausgehenden Datenverkehr konfigurieren. Bei einer Drosselung schränken die QoS-Komponenten den gesamten ausgehenden Netzwerkverkehr auf die angegebene Rate ein. Für Computer können Sie die Verwendung der Bandbreite für eingehenden Datenverkehr verwalten und die erweiterten Einstellungen so konfigurieren, dass der eingehende Durchsatz für den TCP-Datenverkehr durch das Einstellen eines Höchstwerts für die TCP-Empfangsfenstergröße festgelegt wird.
In Windows Vista und Windows Server „Longhorn“ ist der QoS-Paketplaner standardmäßig installiert und aktiviert. Die Pacer.sys-Komponente ist ein neuer, einfacher NDIS 6.0-Filtertreiber (Network Device Interface Specification), der die Paketplanung für richtlinienbasierte QoS und für den Datenverkehr QoS-aktivierter Anwendungen steuert. Pacer.sys ersetzt Psched.sys in Windows XP und Windows Server 2003.
Um richtlinienbasierte QoS auf Ihrem Intranet bereitzustellen, konfigurieren Sie die benutzer- oder computerbasierten QoS-Richtlinien, und wenden sie diese auf den entsprechenden Active Directory-Container an. Auf Windows Vista oder Windows Server „Longhorn“ basierende Computer laden ihre richtlinienbasierten QoS-Einstellungen herunter und wenden sie an, wenn sie die Benutzerkonfigurations- oder Computerkonfigurations-Gruppenrichtlinien aktualisieren.
Da Netzwerke zunehmend sowohl für Daten- als auch für Audio/Video (A/V)-Anwendungen verwendet werden, muss mithilfe einer QoS-Lösung dem zeitabhängigen A/V-Datenverkehr eine bevorzugte Behandlung gegenüber dem übrigen Datenverkehr eingeräumt werden. Außerdem werden Netzwerke zunehmend drahtlos eingerichtet, wodurch zusätzliche Komplikationen bei wartezeit- und bandbreitenanfälligen Anwendungen entstehen.
Das qWAVE-Feature in Windows Vista stellt eine Sammlung QoS-bezogener Softwaremodule bereit, die entwickelt wurden, um die Anforderungen an das Netzwerk zu erfüllen, die von AV-Anwendungen und drahtlosen Netzwerken gestellt werden. qWAVE wird in das QoS-Subsystem integriert und arbeitet mit mehreren Paketprioritätstechnologien für Internet- und Netzwerkschnittstellenebenen zusammen. qWAVE unterstützt mehrere AV-Datenströme (Echtzeitdatenflüsse, für die QoS erforderlich ist) und Datenströme (Datenflüsse mit bester Leistung, z. B. E-Mail- oder Dateiübertragungen) gleichzeitig.
Mithilfe der Sammlung von qWAVE-Technologien wird die LAN-Bandbreite ermittelt und überwacht, die QoS-Fähigkeit des Netzwerks erkannt und eine verteilte Zugangskontrolle für eine ausgeglichene und konsistente Verwendung der Netzwerkbandbreite zur Verfügung gestellt. Diese Technologien aktivieren erweiterte A/V-Datenstromverfahren, sodass sich Anwendungen dynamisch an Änderungen der Netzwerkbedingungen anpassen können, und sind Entwicklern nur über die QoS2-API verfügbar.
Die QoS2-API in Windows Vista und Windows „Longhorn“ Server ersetzt die GQoS-API und die IP_TOS-Winsock-Option und ist wahrscheinlich leichter zu verwenden als die GQoS-API.

Weitere Informationen
Weitere Informationen zu QoS erhalten Sie in einer Reihe von ausgezeichneten Quellen, die über TechNet verfügbar sind. Beginnen Sie mit der Microsoft-Website Quality of Service (in englischer Sprache). Lesen Sie außerdem den QoS-Abschnitt des Blogs Windows Core Networking (in englischer Sprache).

Joseph Daviesist technischer Redakteur bei Microsoft und lehrt und schreibt seit 1992 über Windows-Netzwerkthemen. Er hat fünf Bücher für Microsoft Press® verfasst und ist der Autor der monatlich erscheinenden TechNet-Kolumne The Cable Guy


 Windows PowerShell: Zeilenweise Skripterstellung
Windows PowerShell
Zeilenweise Skripterstellung
Don Jones

In früheren Beiträgen habe ich die Tatsache betont, dass Windows PowerShell eine Shell ist. Windows PowerShell ist für die interaktive Verwendung gedacht – im Gegensatz zur Shell cmd.exe (bzw. Eingabeaufforderung), die Sie wahrscheinlich schon kennen. Windows PowerShell unterstützt jedoch trotzdem eine Skriptsprache, und zwar eine Skriptsprache, die robuster ist als die Stapelsprache von cmd.exe,
und ebenso leistungsfähig wie andere Sprachen (z. B. VBScript), wenn nicht sogar leistungsfähiger. Die Tatsache, dass es sich bei Windows PowerShell™ um eine interaktive Shell handelt, macht das Erlernen der Skripterstellung ausgesprochen einfach. Sie können Skripts sogar interaktiv innerhalb der Shell entwickeln und zeilenweise schreiben, sodass Sie die Ergebnisse Ihrer Arbeit sofort vor sich haben.
Diese iterative Skripterstellungstechnik erleichtert außerdem das Debuggen. Da Sie die Ergebnisse Ihrer Skripterstellung sofort sehen, können Sie das Skript schnell überarbeiten, wenn das Ergebnis nicht wie erwartet ausfällt.
In diesem Beitrag wird die interaktive Skripterstellung in Windows PowerShell anhand eines Beispiels vorgeführt. Es wird ein Skript erstellt, das Dienstnamen aus einer Textdatei liest und den Startmodus der jeweiligen Dienste so festlegt, dass sie deaktiviert sind.
Dieser Beitrag soll Ihnen das Konzept näher bringen, Windows PowerShell-Skripts in kleinen Schritten zu erstellen, statt ein ganzes Skript in einem Stück anzugehen. Sie können sich eine beliebige Verwaltungsaufgabe vornehmen, sie in ihre Bestandteile zerlegen und anschließend ausarbeiten, wie Sie die Bestandteile unabhängig voneinander funktionsfähig machen. Windows PowerShell stellt ausgezeichnete Möglichkeiten bereit, um die Teile zu verbinden. Dies wird im Weiteren erörtert. Dabei wird auch deutlich, dass Sie das endgültige Skript leichter schreiben können, wenn Sie stückweise vorgehen.

Lesen von Namen aus einer Datei
Herauszufinden, wie Textdateien in Windows PowerShell gelesen werden, kann eine Geduldsprobe darstellen. Wenn ich „Help *file*“ ausführe, wird nur die Hilfe für das Cmdlet „Out-File“ angezeigt, das einer Datei Text sendet, nicht jedoch Text liest. Das ist natürlich keine große Hilfe. Cmdlet-Namen in Windows PowerShell haben jedoch eine Art von Logik, die ich zu meinem Vorteil nutzen kann. Wenn Windows PowerShell ein Element abruft, beginnt der Cmdlet-Name gewöhnlich mit „Get“ (Abrufen). Daher führe ich „Help Get*“ aus, um diese Cmdlets anzuzeigen. Anschließend führe ich einen Bildlauf durch die Liste aus und finde Get-Content. Dies bringt mich meinem Ziel schon näher. Ich führe nun „Help Get-Content“ aus, um weitere Informationen anzuzeigen (siehe Abbildung 1), und erhalte das gewünschte Ergebnis.
Abbildung 1 Ausführen von „Help Get-Content“, um weitere Informationen anzuzeigen
Abbildung 1 Ausführen von „Help Get-Content“, um weitere Informationen anzuzeigen (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 1 Ausführen von „Help Get-Content“, um weitere Informationen anzuzeigen
Abbildung 1 Ausführen von „Help Get-Content“, um weitere Informationen anzuzeigen (Klicken Sie zum Vergrößern auf das Bild)
Windows PowerShell behandelt nahezu alles wie ein Objekt, und Textdateien stellen dabei keine Ausnahme dar. Eine Textdatei ist grundsätzlich eine Sammlung von Zeilen, wobei jede Zeile in der Datei eine Art unabhängiges Objekt darstellt. Nachdem eine Textdatei namens „C:\services.txt“ erstellt und mit Dienstnamen versehen wurde (jeder Name erhält seine eigene Zeile innerhalb der Datei), kann Windows PowerShell mithilfe des Cmdlets „Get-Content“ die Namen einzeln lesen. Da die vorliegende Anleitung zeigen soll, wie Skripts interaktiv entwickelt werden, wird als Erstes „Get-Content“ ausgeführt, wobei der Name der Beispieltextdatei verwendet wird, um zu sehen, was passiert:
PS C:\> get-content c:\services.txt
messenger
alerter
PS C:\>
Wie erwartet liest Windows PowerShell die Datei und zeigt den Namen an. Die Anzeige der Namen ist natürlich nicht das eigentliche Ziel. Jetzt ist jedoch klar, dass Get-Content erwartungsgemäß funktioniert.

Ändern eines Diensts
Als Nächstes soll der Startmodus eines Diensts geändert werden. Der erste Schritt ist wiederum das Finden des richtigen Cmdlets. Ich führe daher „Help *Service*“ aus. Daraufhin wird eine Auswahlliste zurückgegeben, und nur das Cmdlet „Set-Service“ scheint in diesem Falle nützlich zu sein. Ich will dieses Cmdlet testen, um sicherzustellen, dass ich verstehe, wie es funktioniert, bevor ich versuche, es in ein Skript einzufügen. Durch Ausführen von „Help Set-Service“ wird angezeigt, wie das Cmdlet funktioniert, und ein schneller Test bestätigt dies:
PS C:\> set-service messenger -startuptype
    disabled
PS C:\>

Kombinieren der Teile
Jetzt muss ich die Möglichkeit, Dienstnamen aus einer Datei zu lesen, mit dem Cmdlet „Set-Service“ kombinieren. An dieser Stelle kommen die leistungsfähigen Pipelinefunktionen von Windows PowerShell zum Einsatz. Mit der Pipeline kann eine Cmdlet-Ausgabe als Eingabe an ein zweites Cmdlet weitergeleitet werden. Die Pipeline leitet ganze Objekte weiter. Falls eine Sammlung von Objekten in die Pipeline gestellt wird, wird jedes Objekt einzeln durch die Pipeline geleitet. Das bedeutet, dass die Ausgabe von Get-Content, die eine Sammlung von Objekten ist, an Set-Service geleitet werden kann. Da Get-Content eine Sammlung weiterleitet, wird jedes Objekt bzw. jede Textzeile in der Sammlung einzeln an Set-Service geleitet. Das Ergebnis ist, dass Set-Service einmal für jede Zeile in meiner Textdatei ausgeführt wird. Der Befehl sieht folgendermaßen aus:
PS C:\> get-content c:\services.txt |
 set-service -startuptype disabled
PS C:\>
Es geschieht Folgendes:
  1. Das Cmdlet „Get-Content“ wird ausgeführt und liest die gesamte Datei. Jede Zeile in der Datei wird als ein eindeutiges Objekt behandelt, und zusammen stellen die Zeilen eine Sammlung von Objekten dar.
  2. Die Sammlung von Objekten wird an Set-Service geleitet.
  3. Die Pipeline führt das Cmdlet „Set-Service“ einmal für jedes Eingabeobjekt aus. Für jede Ausführung wird das Eingabeobjekt als der erste Parameter des Cmdlets, bei dem es sich um den Dienstnamen handelt, an Set-Service geleitet.
  4. Set-Service wird ausgeführt, wobei das Eingabeobjekt für seinen ersten Parameter bzw. alle anderen angegebenen Parameter verwendet wird, in diesem Fall für den Parameter „-startuptype“.
Interessanterweise ist die Aufgabe an diesem Punkt erledigt, und dabei ist das Skript noch nicht einmal geschrieben. Es wäre schwierig, dieselbe Aktion in der Cmd.exe-Shell auszuführen, und in VBScript wäre hierfür ein Dutzend Zeilen von Code erforderlich. Windows PowerShell wickelt all dies jedoch in einer einzigen Zeile ab. Die Aufgabe ist jedoch noch nicht ganz abgeschlossen. Wie Sie sehen können, stellt der Befehl nicht viel Statusausgabe oder Feedback bereit. Abgesehen davon, dass keine Fehler angezeigt wurden, ist es schwer festzustellen, ob tatsächlich ein Aktion ausgeführt wurde. Jetzt, da ich die Funktionen im Griff habe, um die Aufgabe abzuschließen, kann ich am Aussehen arbeiten, indem ich mit der eigentlichen Skripterstellung beginne.
„Windows PowerShell Prompt Here“ von Michael Murgolo
Zu den beliebtesten Microsoft® PowerToys für Windows® (und zu meinen Favoriten) gehört das Tool „Eingabeaufforderung hier öffnen“. Das Tool „Eingabeaufforderung hier öffnen“ ist als Teil von Microsoft PowerToys für Windows XP bzw. der Windows Server® 2003 Resource Kit Tools verfügbar. Mit diesem Tool können Sie durch Rechtsklicken auf einen Ordner oder ein Laufwerk in Windows-Explorer ein Befehlsfenster öffnen, das auf den ausgewählten Ordner zeigt.
Beim Erlernen der Verwendung von Windows PowerShell wurde mir bewusst, dass ich mir die gleiche Funktionalität wünschte. Aus diesem Grund änderte ich die setup.inf-Datei von „Eingabeaufforderung hier öffnen“ (cmdhere.inf) aus den Windows Server 2003 Resource Kit Tools, um ein Kontextmenü „Windows PowerShell Prompt Here“ (Windows PowerShell Eingabeaufforderung hier) zu erstellen. Diese .inf-Datei ist im ursprünglichen Blogbeitrag enthalten, auf dem diese Randleiste beruht (verfügbar unter leeholmes.com/blog/PowerShellPromptHerePowerToy.aspx). Um das Tool zu installieren, klicken Sie einfach mit der rechten Maustaste auf die .inf-Datei, und wählen Sie „Install“ (Installieren) aus.
Beim Erstellen der Windows PowerShell-Version dieses Tools habe ich im Original einen Fehler entdeckt: Beim Deinstallieren von „Eingabeaufforderung hier öffnen“ blieb ein deaktivierter Kontextmenüeintrag übrig. Deshalb habe ich eine aktualisierte Version von cmdhere.inf bereitgestellt. Sie finden sie ebenfalls im ursprünglichen Blogbeitrag.
Diese beiden PowerToys nutzen die Tatsache aus, dass diese Kontextmenüeinträge in der Registrierung unter Schlüsseln konfiguriert sind, die mit den Verzeichnis- und Laufwerksobjekttypen (Directory und Drive) verknüpft sind. Dies geschieht in derselben Weise, in der Kontextmenüaktionen mit Dateitypen verknüpft werden. Wenn Sie zum Beispiel mit der rechten Maustaste auf eine .txt-Datei in Windows-Explorer klicken, werden mehrere Aktionen am Anfang der Liste angezeigt (z. B. Öffnen, Drucken und Bearbeiten). Um zu verstehen, wie diese Elemente konfiguriert sind, wird als Nächstes die Registrierungsstruktur HKEY_CLASSES_ROOT untersucht.
Wenn Sie den Registrierungs-Editor öffnen und den Zweig HKEY_CLASSES_ROOT erweitern, sehen Sie, dass Schlüssel für bestimmte Dateitypen (wie .doc, .txt und Ähnliches) benannt sind. Wenn Sie auf den .txt-Schlüssel klicken, sehen Sie, dass der Wert (standardmäßig) „txtfile“ lautet (siehe Abbildung A). Dies ist der Objekttyp, der mit einer .txt-Datei verknüpft wird. Wenn Sie einen Bildlauf nach unten durchführen, den txtfile-Schlüssel erweitern und anschließend den Shellschlüssel darunter erweitern, sehen Sie die Schlüssel, die für manche der Kontextmenüeinträge für eine .txt-Datei benannt wurden. (Sie werden nicht alle sehen, weil es andere Methoden zum Erstellen von Kontextmenüs gibt.) Unter jedem dieser Schlüssel befindet sich ein Befehlsschlüssel. Der (standardmäßige) Wert unter dem Befehlsschlüssel ist die Befehlszeile, die Windows ausführt, wenn Sie das entsprechende Kontextmenüelement auswählen.
Die Tools für die cmd-Eingabeaufforderung und die Windows PowerShell-Eingabeaufforderung verwenden dieses Verfahren, um die Kontextmenüeinträge von „Eingabeaufforderung hier öffnen“ und „Windows PowerShell Prompt Here“ zu konfigurieren. Es gibt keine Dateitypen, die mit Laufwerken und Verzeichnissen verknüpft sind. Es gibt jedoch Laufwerks- und Verzeichnisschlüssel unter HKEY_CLASSES_ROOT, die mit diesen Objekten verknüpft sind.
Abbildung A Kontextmenüeinträge werden in der Registrierung konfiguriert
Abbildung A Kontextmenüeinträge werden in der Registrierung konfiguriert (Klicken Sie zum Verkleinern auf das Bild)
Abbildung A Kontextmenüeinträge werden in der Registrierung konfiguriert
Abbildung A Kontextmenüeinträge werden in der Registrierung konfiguriert (Klicken Sie zum Vergrößern auf das Bild)

Michael Murgolo ist ein leitender Infrastrukturberater für Microsoft Consulting Services. Er ist auf die Bereiche Betriebssysteme, Bereitstellung, Netzwerkdienste, Active Directory, Systemverwaltung, Automatisierung und Patchverwaltung spezialisiert.

Interaktive Skripterstellung
Eine meiner Aufgabenstellungen besteht darin, für jeden Dienst, der in C:\services.txt aufgelistet ist, mehrere Cmdlets auszuführen. So kann ich den gewünschten Dienstnamen und andere Informationen ausgeben, damit der Fortschritt des Skripts nachverfolgt werden kann.
Zuvor habe ich die Pipeline verwendet, um Objekte von einem Cmdlet an ein anderes weiterzuleiten. Diesmal werde ich jedoch ein Verfahren anwenden, das mehr einem Skript ähnelt und als Foreach-Konstrukt bezeichnet wird (dies wurde im letzten Monat in einem Beitrag vorgestellt). Das Foreach-Konstrukt kann eine Sammlung von Objekten annehmen und führt für jedes Objekt der Sammlung mehrere Cmdlets aus. Ich bestimme eine Variable, die das aktuelle Objekt in jedem Durchlauf darstellt. Das Konstrukt könnte zum Beispiel folgendermaßen beginnen:
foreach ($service in get-content c:\services.txt)
Ich führe nach wie vor das Cmdlet „Get-Content“ aus, um den Inhalt der Textdatei abzurufen. Diesmal soll das Foreach-Konstrukt die Sammlung der Objekte durchlaufen, die von Get-Content zurückgegeben werden. Die Schleife wird für jedes Objekt einmal ausgeführt, und das aktuelle Objekt wird in die Variable „$service“ gestellt. Jetzt muss ich nur den Code angeben, der innerhalb der Schleife ausgeführt werden soll. Ich dupliziere zunächst meinen ursprünglichen einzeiligen Befehl (dadurch wird die Komplexität minimiert und sichergestellt, dass die Funktionalität nicht beeinträchtigt wird):
PS C:\> foreach ($service in get-content c:\services.txt) {
>> set-service $service -startuptype disabled
>> }
>>
PS C:\>
Dies ist ein höchst interessanter Vorgang. Beachten Sie, dass ich die erste Zeile des Foreach-Konstrukts mit einer öffnenden geschweiften Klammer abgeschlossen habe. Alles innerhalb der öffnenden und schließenden geschweiften Klammern befindet sich in der Foreach-Schleife und wird einmal für jedes Objekt in der Eingabesammlung ausgeführt. Nach Eingabe von { und Drücken der Eingabetaste wurde die Eingabeaufforderung von Windows PowerShell in >> geändert (siehe Abbildung 2). Dies zeigt an, dass Windows PowerShell erkennt, dass ein Konstrukt begonnen wurde, und auf das Abschließen des Konstrukts wartet. Ich habe anschließend mein Cmdlet „Set-Service“ eingegeben. Diesmal wurde $service als erster Parameter verwendet, da $service den aktuellen aus meiner Textdatei gelesenen Dienstnamen darstellt. In der nächsten Zeile beende ich das Konstrukt mit einer schließenden geschweiften Klammer. Nach zweimaligen Drücken der Eingabetaste führt Windows PowerShell meinen Code sofort aus.
Abbildung 2 Windows Powershell erkennt, dass ein Konstrukt begonnen wurde
Abbildung 2 Windows Powershell erkennt, dass ein Konstrukt begonnen wurde (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 2 Windows Powershell erkennt, dass ein Konstrukt begonnen wurde
Abbildung 2 Windows Powershell erkennt, dass ein Konstrukt begonnen wurde (Klicken Sie zum Vergrößern auf das Bild)
Meine Eingabe ähnelt zwar einem Skript, Windows PowerShell führt die Eingabe jedoch direkt aus, und sie wird in keiner Textdatei gespeichert. Jetzt werde ich alles noch einmal eingeben und dabei eine Codezeile hinzufügen, die den aktuellen Dienstnamen ausgibt:
PS C:\> foreach ($service in get-content c:\services.txt) {
>> set-service $service -startuptype disabled
>> "Disabling $service"
>> }
>>
Disabling messenger
Disabling alerter
PS C:\>
Beachten Sie, dass ich eine Anzeigeaufforderung eingeschlossen und diese Aufforderung in doppelte Anführungszeichen gesetzt habe. Die Anführungszeichen teilen Windows PowerShell mit, dass dies eine Textzeichenfolge und kein weiterer Befehl ist. Wenn Sie jedoch doppelte Anführungszeichen statt einfacher verwenden, durchsucht Windows PowerShell die Textzeichenfolge nach Variablen. Wenn eine Variable gefunden wird, wird der eigentliche Wert der Variablen durch den Variablennamen ersetzt. Folglich können Sie sehen, dass der aktuelle Dienstname angezeigt wird, wenn dieser Code ausgeführt wird.
Dies ist jedoch noch kein Skript.
Bis zu diesem Zeitpunkt habe ich Windows PowerShell interaktiv verwendet, was eine hervorragende Möglichkeit darstellt, um die Ergebnisse meiner Arbeit unmittelbar anzuzeigen. Doch nach einer gewissen Zeit wird das wiederholte Schreiben dieser Codezeilen zu einer aufwändigen Angelegenheit. Aus diesem Grund kann Windows PowerShell auch Skripts ausführen. Bei Windows PowerShell-Skripts wird der Begriff „Skript“ wörtlich genommen: Windows PowerShell liest die Skripttextdatei und gibt jede gelesene Zeile genau so ein, als ob Sie die Zeilen manuell schreiben würden. Das heißt, alles, was ich zuvor ausgeführt habe, kann in eine Skriptdatei eingefügt werden. Ich verwende daher Editor, um eine Datei mit dem Namen „disableservices.ps1“ zu erstellen, und füge Folgendes ein:
foreach ($service in get-content c:\services.txt) {
 set-service $service -startuptype disabled
 "Disabling $service"
 }
Diese Datei wurde in einem Ordner mit dem Namen „C:\Test“ gespeichert. Jetzt versuche ich, die Datei von Windows PowerShell aus auszuführen:
PS C:\test> disableservices
'disableservices' is not recognized as a cmdlet, function, operable program, or
<script file.
At line:1 char:15
+ disableservices <<<<
PS C:\test>
Der Versuch schlägt fehl. Was ist schief gegangen? Windows PowerShell ist auf den Ordner „C:\Test“ ausgerichtet, hat das Skript jedoch nicht gefunden. Warum? Aufgrund von Sicherheitseinschränkungen wurde Windows PowerShell so konzipiert, dass kein Skript vom aktuellen Ordner ausgeführt werden kann. Dadurch wird verhindert, dass über ein Skript ein unberechtigter Zugriff auf einen Betriebssystembefehl erfolgt. Es ist beispielsweise nicht möglich, ein Skript mit dem Namen „dir.ps1“ zu erstellen, um damit den normalen dir-Befehl außer Kraft zu setzen. Wenn ein Skript vom aktuellen Ordner ausgeführt werden soll, muss ein relativer Pfad angegeben werden:
PS C:\test> ./disableservices
The file C:\test\disableservices.ps1 cannot be loaded.
The execution of scripts is disabled on this system.
Please see "get-help about_signing" for more details.
At line:1 char:17
+ ./disableservices <<<<
PS C:\test>
Leider funktioniert dies immer noch nicht. Ich habe den richtigen Pfad eingegeben, erhalte jedoch eine Meldung von Windows PowerShell, dass das Ausführen von Skripts nicht möglich ist. Die Ursache hierfür ist, dass Windows PowerShell Skripts standardmäßig nicht ausführen kann. Auch dies ist eine Sicherheitsvorkehrung, die dazu dient, die Probleme zu vermeiden, die bei der Verwendung von VBScript auftraten. Schädliche Skripts können unter Windows PowerShell standardmäßig nicht ausgeführt werden, da das Ausführen von Skripts standardmäßig nicht möglich ist. Um mein Skript auszuführen, muss ich die Ausführungsrichtlinie explizit ändern:
PS C:\test> set-executionpolicy remotesigned
Die Ausführungsrichtlinie „RemoteSigned“ ermöglicht das Ausführen unsignierter Skripts vom lokalen Computer. Heruntergeladene Skripts müssen zunächst signiert werden, damit sie ausgeführt werden können. Grundsätzlich stellt die Verwendung der Richtlinie „AllSigned“ die bessere Wahl dar. Mit dieser Richtlinie werden nur Skripts ausgeführt, die mit einem Zertifikat von einem vertrauenswürdigen Herausgeber digital signiert wurden. Da ich jedoch kein Zertifikat zur Hand habe, kann ich meine Skripts nicht signieren. In diesem Falle bietet sich daher die Verwendung der Richtlinie „RemoteSigned“ an. Jetzt versuche ich erneut, mein Skript auszuführen:
PS C:\test> ./disableservices
Disabling messenger
Disabling alerter
PS C:\test>
Beachten Sie, dass die hier verwendete Ausführungsrichtlinie „RemoteSigned“ keine optimale, sondern lediglich eine angemessene Lösung darstellt. Für eine sicherere Lösung empfiehlt sich Folgendes: Rufen Sie ein Code-signiertes Zertifikat ab, verwenden Sie das Windows PowerShell-Cmdlet „Set-AuthenticodeSignature“ zum Signieren der Skripts, und legen Sie als Ausführungsrichtlinie die wesentlich sicherere Ausführungsrichtlinie „AllSigned“ fest.
Darüber hinaus gibt es eine andere Richtlinie, die Richtlinie „Unrestricted“, deren Verwendung Sie auf jeden Fall vermeiden sollten. Mit dieser Richtlinie wird zugelassen, dass alle Skripts, sogar schädliche Skripts von Remotestandorten, ungehindert auf Ihrem Computer ausgeführt werden, und das kann Sie in eine gefährliche Lage bringen. Aus diesem Grund wird von der Verwendung der Richtlinie „Unrestricted“ kategorisch abgeraten.

Unmittelbare Ergebnisse
Mit den interaktiven Skriptfunktionen in Windows PowerShell können Sie schnell ein Musterskript oder kleine Skriptteile erstellen. Da das Ergebnis unmittelbar angezeigt wird, können Sie Ihre Skripts leicht anpassen, um die gewünschten Ergebnisse zu erzielen. Abschließend können Sie Ihren Code in eine .ps1-Datei verschieben. Auf diese Weise ist er stets leicht zugänglich. Denken Sie daran: Im Idealfall sollten Sie diese .ps1-Dateien digital signieren, damit Sie die Windows PowerShell-Ausführungsrichtlinie „AllSigned“, die sicherste Richtlinie zur Skriptausführung, nicht ändern müssen.

Don Jones ist der führende Experte für die Skripterstellung bei SAPIEN Technologies und Mitverfasser von Windows PowerShell: TFM (siehe www.SAPIENPress.com). Sie erreichen Don Jones unter don@sapien.com.


 Hey, Scripting Guy!: Autos nachjagen ... und XML
Hey, Scripting Guy!
Autos nachjagen ... und XML
Die Scripting Guys von Microsoft
Laden Sie den Code für diesen Artikel herunter: HeyScriptingGuy2007_02.exe (150KB)

„KEINE AHNUNG, warum mein Hund immer hinter Autos nachjagt“, geht der alte Witz. „Was würde er machen, wenn er tatsächlich mal eins fängt?“
Gute Frage. Die Scripting Guys können sie auch nicht beantworten. Es sei denn Lucy, eine Hündin ein paar Häuser weiter, erwischt das Auto. Die würde nämlich sofort einen Schnapsladen überfallen und dann den Wagen als Fluchtauto missbrauchen. Wenn man sich den Rasen im Vorgarten ansieht, würde sie unterwegs auch nicht anhalten, um mal auszutreten. Wenn Sie wissen, was wir meinen.
Wenn wir diese altehrwürdige Geschichte an das Hightechzeitalter anpassen müssten, ginge sie in etwa so: „Ich weiß nicht, warum mein Systemadministrator immer wieder versucht, XML zu lernen. Denn was würde er damit anfangen, wenn er es irgendwann endlich geschafft hätte?“
Hinweis: Zu unserer Verteidigung: Wir haben ja nur gesagt, dass wir den Witz anpassen, aber nicht, dass man dann auch darüber lachen kann.
Ganz ehrlich gesagt: Das Thema „XML“ ist wahrscheinlich ein wenig aufgebauscht worden, zumindest dann, wenn es um Systemverwaltung geht. Die Wahrheit ist, dass viele Systemadministratoren auf ein langes und zufriedenes Leben zurückblicken können, ohne je ein Skript geschrieben zu haben, das mit einer XML-Datei interagiert hätte, und wir glauben auch nicht, dass sich das in naher Zukunft ändern wird.
Dabei darf man allerdings nicht vergessen, dass XML in immer mehr Anwendungen als Standard für die Speicherung von Daten zum Einsatz kommt. Warum auch nicht? Es handelt sich ja lediglich um aufgemotzte Textdateien. XML lässt sich schnell und einfach erstellen, kann plattformübergreifend verwendet werden und benötigt keine komplizierten und teuren Datenbankprogramme. Haben Sie ein Betriebssystem und einen Texteditor? Dann können Sie eine XML-Datenbank erstellen.
Das heißt im Umkehrschluss, dass Systemadministratoren für XML mindestens eine Verwendung haben: Sie können damit Skripts schreiben, die eine XML-Datei abfragen, als wäre diese Datei eine vollwertige Datenbank. Wer wäre besser dafür geeignet, Ihnen ein paar Tipps in dieser Angelegenheit zu geben, als die Scripting Guys?
Gutes Argument. Aber wenn wir raten müssten, würden wir wetten, dass Lucy höchstwahrscheinlich keine Zeit hat, einen Artikel über XML zu schreiben, weil sie unbedingt das Blumenbeet im Garten des Nachbarn durchwühlen muss.
Zunächst wollen wir uns eine einfache XML-Datei anschauen (siehe Abbildung 1), eine Datenbankdatei mit vier Skripts, die auch in der täglichen Rubrik Hey, Scripting Guy! vorkommen.
Figure 1 Hey, Scripting Guy! Skripts in XML (Close Figure 1)
<?xml version="1.0" encoding="ISO-8859-1"?>
<Repository>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Access</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Print a Microsoft Access Report?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1020.mspx</URL>
  </Script>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Access</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Compact a Microsoft Access Database?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1009.mspx</URL>
  </Script>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Word</Subcategory>
    <Keyword>hyperlinks</Keyword>
    <Title>How Can I Change an Existing Hyperlink in a Microsoft Word Document?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1016.mspx</URL>
  </Script>
  <Script>
    <Category>Enterprise Servers</Category>
    <Subcategory>Microsoft SQL Server</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Create a Table in a SQL Server Database?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1016.mspx</URL>
  </Script>
</Repository>
Wie Sie sehen, handelt es sich um eine ziemlich einfache, kleine Datei. Jedes einzelne Skript ist unter einem <Script>-Tag abgelegt. Ab sofort betrachten wir diese Skripts als Datensätze. Sie haben Recht: XML-Liebhaber würden diese Elemente nie als Datensätze bezeichnen. Aber das geht in Ordnung. Wir wollen Ihnen hier beibringen, wie Sie etwas, das Sie schon kennen (Abfragetechniken für Datenbanken), auf eine neue, andersartige Datenquelle anwenden. Wir haben uns gedacht, dass wir uns zuerst darauf konzentrieren, wie wir die Sache erledigen, und später wieder auf das Thema zurückkommen, um Ihnen die richtige Terminologie beizubringen.
Zurück zu den Datensätzen. Jeder Datensatz enthält die folgenden Felder: <Category> (Kategorie), <Subcategory> (Unterkategorie), <Keyword> (Schlüsselwort), <Title> (Titel) und <URL>.
Sie sind nicht ganz so beeindruckt, wie wir es gehofft hatten. Vielleicht hilft es Ihnen, wenn wir Ihnen ein Skript zeigen, mit dem sich diese XML-Datei öffnen und der Inhalt wiedergeben lässt:
Set xmlDoc = CreateObject("Microsoft.XMLDOM")
xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Scripts.xml")

Set colNodes = xmlDoc.selectNodes _
("/Repository/Script/*")

For Each objNode in colNodes
   Wscript.Echo objNode.Text
Next
Hinweis: Bei den Bezeichnungen der Tags ist zwischen Groß- und Kleinschreibung zu unterscheiden. Es muss heißen „/Repository/Script“ und nicht etwa „/repository/script“ oder „/REPOSITORY/SCRIPT“.
Klar, auch das ist nicht besonders beeindruckend. Aber darum geht es ja: Die ganze Angelegenheit ist nicht halb so kompliziert, wie Sie gedacht haben.
Wie Sie anhand des Codes erkennen können, erstellen wir erst einmal eine Instanz des Objekts „Microsoft.XMLDOM“, dem COM-Objekt, das für die Arbeit mit XML-Dateien verwendet wird. Danach ändern wir die Eigenschaft „Async“ in „False“. Dadurch wird gewährleistet, dass die gesamte Datei in den Speicher eingelesen wird, bevor das Skript wieder die Kontrolle übernimmt. Anschließend verwenden wir die Load-Methode, um die Datei „C:\Scripts\Scripts.xml“ zu lesen:
xmlDoc.Load("C:\Scripts\Scripts.xml")
Sobald die Datei in den Speicher geladen worden ist, können wir mithilfe der selectNodes-Methode die angegebenen Datensätze aus der Datenbank wählen:
Set colNodes = xmlDoc.selectNodes _
("/Repository/Script/*")
Sehen Sie sich den Parameter näher an, der an selectNodes übergeben wurde. Es handelt sich dabei um den Pfad innerhalb der XML-Datei. Unsere XML-Datei hat die folgende Struktur:
<Repository>
    <Script>
        <Category></Category>
        <Subcategory></Subcategory>
        <Keyword></Keyword>
        <Title></Title>
        <URL></URL>
    </Script>
</Repository>
Ob Sie das interessieren sollte? Mit einem Wort: ja! Beim Umgang mit XML-Dateien ist die Struktur sehr wichtig. Wie ruft man beispielsweise die einzelnen Eigenschaften eines Datensatzes ab? Das ist einfach: Wir greifen auf das <Repository>-Tag zu, hinter dem das<Script>-Tag kommt, gefolgt von den einzelnen Eigenschaftstags. Wissen Sie was? Das ist derselbe Pfad, den wir selectNodes als Parameter übergegeben haben. Wir hängen dem Pfad einfach ein „/*“ an. Übersetzt heißt das: „Wähle alle Eigenschaften für diese Datensätze aus“. Mit anderen Worten: Die ausgegebene Sammlung besteht aus allen Eigenschaften für alle Datensätze in der Datenbank. Das ist so, als hätten Sie sich für die Abfrage „Select * From“ in Windows® Management Instrumentation (WMI) entschieden.
Hinweis: Probieren Sie das Beispielskript aus, dann wissen Sie genau, worauf wir hinauswollen.
Das restliche Skript ist leicht: Wir richten einfach nur eine For Each-Schleife ein, um die Sammlung durchzugehen und den Wert der Text-Eigenschaft für jedes Objekt und jede Eigenschaft wiederzugeben.
For Each objNode in colNodes
   Wscript.Echo objNode.Text
Next
Das ist viel einfacher, als hinter Autos nachzujagen.
Aber Sie haben Recht: Wenn wir nur den gesamten Inhalt der Datei hätten wiedergeben wollen, hätten wir uns gar nicht um den ganzen XML-Kram kümmern müssen und nur FileSystemObject verwendet. (Das wäre vielleicht ein bisschen komplizierter gewesen, aber auch nur ein bisschen). Um Sie restlos vom Nutzen von XML zu überzeugen, müssen wir uns aber wahrscheinlich noch etwas mehr anstrengen.
Mal sehen, ob wir das hinkriegen. Im ersten Skript haben wir alle Eigenschaftenwerte für alle Datensätze bekommen. Das ist ja schön und gut, aber nehmen wir mal an, wir wollten einfach nur den Skripttitel haben! Geht das überhaupt?
Laut Lucy müssen wir nur unseren selectNodes-Befehl ändern, indem wir die Eigenschaft, die uns interessiert, an das Ende des Pfads stellen. Anders gesagt:
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/Title")
Offensichtlich wurden beim ersten Mal alle Eigenschaften wiedergegeben, weil wir das Platzhalterzeichen „*“ verwendet haben. Jetzt erhalten wir nur die Title-Eigenschaft. Warum? Weil das der einzige Eigenschaftenwert ist, um den wir gebeten hatten.
Hinweis: Sehen Sie sich dies an: XML gibt Ihnen genau das, worum Sie gebeten haben. Sei nicht sauer, Lucy, aber es sieht so aus, als wäre jetzt XML der beste Freund des Menschen!
Sicher kann man mehr als eine Eigenschaft wiedergeben lassen! Dieser geänderte Befehl gibt z. B. Werte für die Title- und die URL-Eigenschaft wieder:
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/(Title | URL)")
Zugegeben, die Syntax macht einen etwas unaufgeräumten Eindruck, aber man gewöhnt sich daran. Zunächst legen wir den übergeordneten Anteil des Pfads fest, genau wie eben:
    /Repository/Script/
Wir fügen dann einen Satz Klammern hinzu und tragen innerhalb der Klammern die Eigenschaften ein, die wiedergegeben werden sollen. Hinweis: Die Eigenschaften werden dabei durch das |-Zeichen getrennt. Anders gesagt:
    (Title | URL)
Es ist zwar ein bisschen albern, aber es funktioniert.
Sie müssen sich nicht auf die Wiedergabe von zwei Eigenschaften beschränken. Sie müssen nur darauf achten, genügend Trennzeichen einzufügen, dann bekommen Sie alle Informationen angezeigt, die Sie sich wünschen. Der nachfolgende Befehl gibt z. B. drei Eigenschaften wieder (Title, URL und Keyword):
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/(Title | URL |          Keyword)")
Aber Sie haben wieder Recht: Bis jetzt haben wir nur Informationen zu allen Datensätzen in unserer Datenbank abgerufen. Daran ist aber auch nichts auszusetzen. Oft will man nämlich genau das und nichts anderes. Aber es kommt auch vor (und das gar nicht so selten), dass wir nur Informationen über eine Teilmenge der Datensätze abrufen möchten. Das kann beispielsweise der Fall sein, wenn wir lediglich die Skripts herausfiltern wollen, die über ein Schlüsselwort (Keyword) verfügen, das gleich „databases“ ist. Also mit einer Abfrage, die dieser hier ähnelt:
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’]")
Wieder ist die Syntax ein wenig schräg. Aber sie hat auch einen Vorteil: Sie ist einfach und direkt. Nach der Angabe des übergeordneten Pfads stellen wir unsere Where-Klausel (z. B. „Wo ist X gleich Y?“) in eckige Klammern:
/Repository/Script [Keyword = ‘databases’]
Wie Sie wahrscheinlich bereits wissen, befiehlt unsere Where-Klausel dem Skript: „Gib nur die Elemente wieder, bei denen das Keyword-Attribut gleich ‘databases’ ist.“ Beachten Sie, das ‘databases’ in einfachen Anführungszeichen steht. Das geht nicht nur in Ordnung, es ist ein absolutes Muss. Wenn der Filterbegriff in doppelten Anführungszeichen steht, erhalten Sie nämlich einen Syntaxfehler, sobald Sie versuchen, das Skript auszuführen.
Hinweis: Warum? Weil die gesamte Abfragezeichenfolge – "/Repository/Script [Keyword = ‘databases’]" – in doppelte Anführungszeichen eingeschlossen ist.
Selbstverständlich müssen Sie sich beim Filtern der Daten nicht auf das Gleichheitszeichen (=) beschränken. Sie können Größer-als-Zeichen (>) oder Kleiner-als-Zeichen (<) verwenden sowie die allseits beliebten Kleiner-gleich-Zeichen (<=) oder Größer-gleich-Zeichen (>=). Sie können diese Zeichen auch negieren, indem Sie ihnen ein Ausrufezeichen voranstellen. Der folgende Befehl fordert beispielsweise alle Skripts an, bei denen das Schlüsselwort ungleich „databases“ ist (beachten Sie das „!=“):
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword != ‘databases’]")
Moment mal! Wer hat gesagt, dass man Filter setzen kann, aber bestimmt keinen Filter setzen und die wiederzugebenden Eigenschaften bestimmen kann? Klar geht das!
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’]/Title")
Wenn alles gut läuft, wird durch diesen Befehl nur die Title-Eigenschaft für alle Skripts wiedergegeben, die über das Schlüsselwort „databases“ verfügen. Mal sehen, ob es funktioniert:
    How Can I Print a Microsoft Access Report?
    How Can I Compact a Microsoft Access Database?
    How Can I Create a Table in a SQL Server     Database?
Vielleicht können wir noch einen Befehl unterbringen, bevor wir für heute Schluss machen. Obwohl wir Fortschritte machen, bekommen wir vielleicht immer noch mehr Datensätze zurück, als wir eigentlich wollen. Schließlich gibt unser vorhergehender Befehl eine Mischung aus Microsoft® Access®- und Microsoft SQL Server™-Skripts wieder. (Warum? Weil alle diese Skripts das Schlüsselwort „databases“ verwenden.) Was ist, wenn wir die wiedergegebenen Daten auf Skripts beschränken wollen, die „databases“ als Schlüsselwort und „Microsoft SQL Server“ als Unterkategorie haben? Kann man vielleicht sogar nach mehreren Kriterien filtern?
Das müssen Sie doch gar nicht fragen:
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’ and " & _
    "Subcategory = ‘Microsoft SQL Server’]")
Die Syntaxgrundlage ist dieselbe, wir haben nur zwei unterschiedliche Kriterien (nämlich Keyword = ‘databases’ und Subcategory = ‘Microsoft SQL Server’) verwendet und beide mit dem Operator UND verknüpft.
Hinweis: Ja, Sie haben Recht: Mit dieser einfachen kleinen XML-Datei hätten wir alle Skripts anfordern können, bei denen die Unterkategorie gleich „Microsoft SQL Server“ war. Aber das hätte keinen Spaß gemacht, und Sie hatten auch nicht so viel gelernt.
Sie können auch ODER-Klauseln verwenden. Stellen Sie sich beispielsweise vor, wir hätten jede Menge Microsoft Office-Skripts gehabt, einschließlich solcher, deren Unterkategorien „Microsoft Excel®“, „Microsoft Powerpoint®“, „Microsoft Outlook®“ und so weiter gewesen wären. Ist es möglich, die wiedergegebenen Daten auf die Skripts aus den Unterkategorien „Microsoft Word“ oder „Microsoft Access“ zu beschränken? Mit Sicherheit.
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Subcategory = ‘Microsoft Word’ " & _
    "or Subcategory = ‘Microsoft Access’]")
Sieht doch besser aus, oder? Zugegeben, dieser Artikel hat Ihr Leben sicherlich nicht revolutioniert, aber die Chancen stehen gut, dass Ihnen die Fähigkeit, auf diese Weise mit einer XML-Datei umzugehen, früher oder später zugute kommen wird. Denken Sie daran, Sie haben die Wahl: Wollen Sie grundlegende XML-Techniken lernen oder lieber Autos nachjagen? Das entscheiden Sie allein. (Wenn Sie sich für die letztgenannte Alternative entscheiden und zufälligerweise Lucy, die Hündin, auf der Straße treffen sollten, grüßen Sie sie doch bitte herzlich von den Scripting Guys. Sagen Sie ihr, sie soll sich von unserem Vorgarten fernhalten!)
Hey, Scripting Guy! – jeden Tag
Sie haben sich gerade die Monatsausgabe von „Hey Scripting Guy!“ durchgelesen und gedacht, dass das ja wohl die genialste technische Information sein muss, die Ihnen je unter die Augen gekommen ist. Vielleicht gehen Sie noch einen Schritt weiter und behaupten, dass es sich um das größte Schriftstück aller Zeiten handelt! Außerdem stehen Sie gerade ungeduldig neben Ihrem Postfach und warten auf die neue Ausgabe des TechNet Magazins, damit Sie noch mehr solche tollen Artikel lesen können.
Worauf warten Sie dann noch? Möchten Sie noch mehr über Lucy, die freundliche Hündin aus der Nachbarschaft oder die neuesten Heldentaten des Scripting Son erfahren? Bleiben Sie bei diesen „wichtigen“ Fragen einfach auf dem Laufenden, indem Sie die täglich erscheinenden Artikel aus der Rubrik „Hey, Scripting Guy!“ lesen. Von Montag bis Freitag (außer an Feiertagen und Urlaubstagen der Scripting Guys) erfahren Sie alles über Highschoolbaseball, Collegefootball und -basketball in den USA und können gelegentlich einen lokalen Wetterbericht abrufen. (Sicher ist der nur lokal, wenn Redmond für Sie lokal ist, aber eigentlich will doch jeder wissen, ob es in Redmond gerade regnet oder nicht, stimmt’s?)
Dann werden Sie auch noch jeden Tag etwas Neues über Skripting erfahren! Richtig, die Skriptinginformationen werden quasi in eine Flut packender Inhalte eingebettet. In jeder Ausgabe beantworten die Scripting Guys echte Fragen, die hoffentlich auch von echten Menschen gestellt wurden. Die Rubrik erscheint täglich online in englischer Sprache unter microsoft.com/technet/scriptcenter/resources/qanda. Da sie bereits hunderte von Fragen beantwortet haben, ist ihr Archiv ziemlich umfangreich und daher eine hervorragende Quelle für Skriptinginformationen (siehe microsoft.com/technet/scriptcenter/resources/qanda/hsgarch.mspx).
Sie haben eine Frage an die Scripting Guys? Schicken Sie sie an scripter@microsoft.com, und wenn Sie Glück haben, wird sie auch beantwortet! (Wenn Sie sie nicht abschicken, kriegen Sie garantiert keine Antwort. Sie haben also nichts zu verlieren. Im Unterschied zu einem Lottoschein kostet die Teilnahme nichts, und Ihre Chancen auf einen Hauptgewinn stehen etwas besser.)

Die Scripting Guys von Microsoft arbeiten für (und sind Angestellte von) Microsoft. 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: Bereitstellen von EFS: Teil&#160;1
Sicherheit auf dem Prüfstand
Bereitstellen von EFS: Teil 1
John Morello

Sicher hat heute schon jeder Berichte zum Verlust persönlicher oder vertraulicher Daten durch den Diebstahl oder Verlust von Laptops gehört. Es kommt häufig vor, dass Laptops verloren gehen. Mit dem Anstieg im Bereich des Identitätsdiebstahls und immer strengeren gesetzlich vorgeschriebenen Konformitätsvorgaben ist der eingehende Schutz von Daten auf mobilen Computersystemen unerlässlich.
Eine Möglichkeit bietet die Nutzung des verschlüsselnden Dateisystems (Encrypting File System, EFS) das in Windows® seit der Version Windows 2000 enthalten ist und eine integrierte, leistungsstarke und datenträgerbasierte Verschlüsselung bereitstellt. EFS ist nahtlos in Windows-Explorer integriert, sodass es die Endbenutzer oft gar nicht bemerken, wenn es sich bei einer von ihnen verwendeten Datei um eine verschlüsselte Datei handelt. Darüber hinaus funktioniert EFS ebenso gut mit den systemeigenen Authentifizierungs- und Zugriffssteuerungstechnologien von Windows. Die Benutzer müssen sich daher nicht mehrere Kennwörter merken, um auf ihre Daten zugreifen zu können. Nicht zuletzt stellt EFS auch verwaltbare Optionen für die Wiederherstellung von Daten in Situationen bereit, in denen ein Benutzer den Zugriff auf seine Verschlüsselungsschlüssel verloren hat (z. B. wenn sein Benutzerprofil gelöscht wurde oder beschädigt ist oder wenn die Smartcard des Benutzers nicht auffindbar ist).
EFS nutzt unter Windows die integrierte Kryptografietechnologie, um leistungsstarke Verschlüsselungsschlüssel zum Schutz von Daten zu generieren, zu speichern und bereitzustellen. Unter Windows XP Service Pack 1 (SP1) und späteren Versionen verwendet EFS den Algorithmus des erweiterten Verschlüsselungsstandards (Advanced Encryption Standard, AES) mit einem 256-Bit-Schlüssel, um Daten auf Datenträgern zu verschlüsseln. Diese symmetrischen Schlüssel werden dann durch ein asymmetrisches (RSA-)Schlüsselpaar geschützt. EFS verschlüsselt jede Datei mit seinem AES-Schlüssel, verschlüsselt dann diesen Schlüssel mit dem RSA-Schlüssel des Benutzers und speichert das Ergebnis in der Datei. Weitere Informationen zur EFS-Kryptografie, finden Sie in der Randleiste „EFS-Ressourcen“. Vorläufig werde ich mich nicht auf die technischen Grundlagen von EFS konzentrieren, sondern auf dessen Bereitstellung und Umsetzung in Ihrer Umgebung. Daher wird in diesem Artikel davon ausgegangen, dass Vorkenntnisse zur EFS-Kryptografie bestehen.

Hinweis zur EFS-Sicherheit
Von einigen Anwendungen wird behauptet, sie könnten die EFS-Verschlüsselung knacken oder entschlüsseln. Keine dieser Anwendungen entschlüsselt tatsächlich den durch AES (oder Data Encryption Standard, DES, oder Expanded Data Encryption Standard, DESX) verschlüsselten Text. Die Anwendung erhält vielmehr Zugriff auf den privaten EFS-Schlüssel des Benutzers, indem ein Brute-Force-Angriff auf das Benutzerkennwort ausgeübt wird. Bei der EFS-Verschlüsselung ist unbedingt zu berücksichtigen, dass die privaten Schlüssel, die zum Generieren und zum Schutz der verschlüsselten Daten verwendet werden, die DPAPI (Data Protection API) einsetzen. DPAPI verwendet Ableitungen der Anmeldeinformationen eines Benutzers zum Schutz von Daten, was dazu führt, dass der Schutz von Daten mit EFS nur so gut wie das Kennwort des Benutzers sein kann. Mit Windows Vista™ können Sie jetzt EFS-Verschlüsselungszertifikate auf Smartcards speichern, um dieses Paradigma aufzuheben und die relative Sicherheit von durch EFS geschützten Daten deutlich zu erhöhen.
Wie lang muss ein Kennwort sein, um diesen Angriffen zu widerstehen? Mit den heutigen Hardwarefunktionen und modernen Kennwortangriffsalgorithmen werden für ein Kennwort (oder, genauer gesagt, für die Passphrase) elf Zeichen oder mehr empfohlen. Eine Passphrase mit elf oder mehr Zeichen bietet einen guten Widerstand gegenüber den heutzutage angewendeten ausgefeilten Methoden, einschließlich vorausberechneter Hashangriffe (wie z. B. Rainbow Table; in der Randleiste „Ressourcen“ im Blog „Why you shouldn’t be using passwords of any kind on your Windows networks“ finden Sie weitere Informationen dazu).

PKI oder keine PKI?
In einer der häufigsten falschen Annahmen zu EFS wird davon ausgegangen, dass für EFS eine PKI (Public Key Infrastructure) erforderlich ist. Obwohl EFS einfach in eine PKI integriert werden und deren Vorteile nutzen kann (sofern Ihre Organisation über eine PKI verfügt), ist eine PKI nicht unbedingt erforderlich. Die Entscheidung, ob eine PKI in Ihrer EFS-Bereitstellung verwendet wird oder nicht, wirkt sich jedoch auf viele zukünftige Bereitstellungsentscheidungen aus. Daher sollte eine solche Entscheidung an erster Stelle stehen.
Der wichtigste Vorteil bei der Verwendung einer PKI mit EFS besteht in der Möglichkeit, Schlüssel zu archivieren und wiederherzustellen. Während EFS nur Administratoren die Durchführung einer Datenwiederherstellung ermöglicht, ist eine automatische Schlüsselwiederherstellung nur mit einer PKI verfügbar und auch nur dann, wenn Windows Server® 2003 Enterprise Edition als Zertifizierungsstelle (Certification Authority, CA) ausgeführt wird. Bei der Datenwiederherstellung handelt es sich um den Prozess, bei dem ein Benutzer, der den Zugriff auf seinen Verschlüsselungsschlüssel verliert, einem bestimmten Administrator, der als Datenwiederherstellungs-Agent (Data Recovery Agent, DRA) bezeichnet wird, seine verschlüsselten Daten bereitstellen kann. Der Agent kann diese Daten dann entschlüsseln und an den Benutzer zurückgeben oder sie für die Verwendung mit einem neuen privaten Schlüssel erneut verschlüsseln. Der DRA arbeitet im Hintergrund des Verschlüsselungsprozesses des Benutzers, wobei sämtliche Daten, die der Benutzer mit seinem Schlüssel verschlüsselt, auch mit einer Kopie des DRA-Schlüssels verschlüsselt werden. Wenn also der Schlüssel des Benutzers verloren geht, kann der DRA eingreifen, die Daten des verschlüsselten Texts abrufen, den DRA-Schlüssel zur Entschlüsselung (oder erneuten Verschlüsselung) darauf anwenden und anschließend die Daten an den Benutzer zurückgeben. Der DRA-Ansatz ist ein gut funktionierendes Verfahren, kann jedoch Schwierigkeiten bei der Verwaltung bereiten, wenn der Benutzer große Datenmengen verschlüsselt hat oder keine lokalen IT-Mitarbeiter die Rolle von DRAs übernehmen können.
Bei der Schlüsselwiederherstellung muss dagegen die Zertifizierungsstelle während des Schlüsselerstellungsprozesses eine Kopie des Verschlüsselungsschlüssels des Benutzers erstellen und diese sicher in der Datenbank der Zertifizierungsstelle speichern. Wenn ein Benutzer den Zugriff auf verschlüsselte Dateien verliert, muss der Zertifizierungsstellenadministrator lediglich auf diese Datenbank zugreifen und den Schlüssel des Benutzers abrufen. Der Benutzer erhält dann wieder umgehend den Zugriff auf seine Daten, ohne dass diese für ihn vom DRA wiederhergestellt werden müssen. Auf diese Weise kann die Schlüsselwiederherstellung schneller und effizienter ablaufen. Beachten Sie jedoch, dass gemäß der bewährten Methode stets DRAs vorhanden sein sollten, auch wenn eine Schlüsselwiederherstellung eingesetzt wird, um für den Fall des Verlusts von Schlüsseln einen Sicherungsmechanismus bereitzustellen. So können auch große Organisationen über ein verteiltes Wiederherstellungssystem verfügen, in dem lokale IT-Administratoren die Daten von Benutzern wiederherstellen können, ohne die PKI-Administratorengruppe einbeziehen zu müssen.
Ein anderer möglicher Vorteil bei der Verwendung einer PKI mit EFS besteht in der einfacheren Freigabe verschlüsselter Dateien. Denken Sie daran, dass EFS nicht nur auf Laptopsysteme beschränkt ist, sondern auch in Situationen wertvolle Unterstützung bietet, in denen die physische Sicherheit eines Computers nicht garantiert werden kann. In solchen Situationen kann es beispielsweise erforderlich sein, dass mehrere Benutzer auf dieselben verschlüsselten Daten zugreifen. Obwohl bei der Windows-Unterstützung Einschränkungen für freigegebene Dateien bestehen, da nur die Freigabe von einzelnen Dateien statt von Verzeichnissen zulässig ist, kann Windows ein nützliches Tool darstellen. Um die Freigabe von EFS-Dateien zu erleichtern, muss der Benutzer, der die Datei freigibt, über Zugriff auf die öffentlichen Schlüssel der Benutzer verfügen, für die die Freigabe erfolgt (dies ist am einfachsten, wenn die Benutzer ein gültiges EFS-Zertifikat besitzen, das in Active Directory® für ihre Konten veröffentlicht wurde). Diese Veröffentlichung kann manuell durchgeführt werden kann. Durch die Verwendung einer Windows-Zertifizierungsstelle, die im Enterprise-Mode (Active Directory-integriert) installiert wurde, wird der Prozess jedoch vollständig automatisiert.

EFS-Schlüsselverwaltung
Wenn eine PKI, die auf Windows Server 2003 basiert, für die Verwendung verfügbar ist, ist die Generierung von EFS-Zertifikaten für Benutzer ein einfacher Prozess. Eine Zertifizierungsstelle von Windows Server 2003 enthält einen Standardsatz von Zertifikatsvorlagen, einschließlich einer Vorlage mit der Bezeichnung „Basis-EFS“. Bei dieser Vorlage handelt es sich jedoch um eine Vorlage der Version 1, die keine Schlüsselarchivierung unterstützt. Daher sollten Sie die Vorlage duplizieren, bevor Sie diese auf Ihrer Zertifizierungsstelle bereitstellen, um eine neue Vorlage der Version 2 zu erstellen (z. B. könnten Sie dieser die Bezeichnung „EFS with Key Archive“ zuweisen, wie in Abbildung 1 dargestellt). Wechseln Sie auf dieser neuen Vorlage zur Registerkarte „Anforderungsverarbeitung“, und wählen Sie die Option zur Archivierung des Verschlüsselungsschlüssels des Benutzers aus. Beachten Sie, dass die Schlüsselarchivierung ordnungsgemäß auf der Zertifizierungsstelle konfiguriert sein muss, bevor Sie diese Option aktivieren. Der Abschnitt mit Ressourcen umfasst eine ausgezeichnete exemplarische Anleitung für den Prozess. Sie sollten diese Vorlage entsprechend einstellen, sodass die Basis-EFS-Vorlage ersetzt wird, um sicherzustellen, dass die Clients die neue Version verwenden (siehe Abbildung 2).
Abbildung 1 EFS mit Schlüsselarchiv
Abbildung 1 EFS mit Schlüsselarchiv (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 1 EFS mit Schlüsselarchiv
Abbildung 1 EFS mit Schlüsselarchiv (Klicken Sie zum Vergrößern auf das Bild)
Abbildung 2 Ersetzen der Basis-EFS-Vorlage
Abbildung 2 Ersetzen der Basis-EFS-Vorlage (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 2 Ersetzen der Basis-EFS-Vorlage
Abbildung 2 Ersetzen der Basis-EFS-Vorlage (Klicken Sie zum Vergrößern auf das Bild)
Im nächsten Schritt müssen Sie in der Vorlage die geeigneten Berechtigungen festlegen, um dem richtigen Benutzersatz Registrierungszugriff auf die Vorlage zuzuweisen. Da die EFS-Komponente unter Windows bei der ersten Verwendung von EFS automatisch ein Zertifikat anfordert, müssen Sie den Benutzern in der Regel keine automatische Registrierung für die EFS-Vorlage erlauben. Es empfiehlt sich vielmehr, keine Aktivierung der automatischen Registrierung für EFS-Zertifikate vorzunehmen, sofern Sie nicht sicher sind, dass alle Benutzer, die eine automatische Registrierung vornehmen können, EFS verwenden. In Abbildung 3 sind die EFS-Registrierungseinstellungen dargestellt. Durch das Ausstellen von Zertifikaten für Benutzer, die wahrscheinlich nie EFS verwenden, wird lediglich die Größe der Zertifizierungsstellendatenbank erhöht, ohne dass ein Nutzen daraus gezogen wird. Auch wenn die Zertifizierungsstellendatenbank selbst keiner Größenbeschränkung unterliegt, kann die Verwaltung der Datenbank bei einer größeren Anzahl an ausgegebenen Zertifikaten erschwert werden (insbesondere bei Verwendung der Microsoft Management Console oder MMC).
Abbildung 3 Einstellen von EFS-Benutzerberechtigungen
Abbildung 3 Einstellen von EFS-Benutzerberechtigungen (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 3 Einstellen von EFS-Benutzerberechtigungen
Abbildung 3 Einstellen von EFS-Benutzerberechtigungen (Klicken Sie zum Vergrößern auf das Bild)
Wenn Sie die Freigabe verschlüsselter Dateien unterstützen müssen, sollten Sie veranlassen, dass die Zertifizierungsstelle das Zertifikat des Benutzers automatisch in Active Directory veröffentlicht.
Sobald Sie die Vorlage ordnungsgemäß auf Ihrer Zertifizierungsstelle konfiguriert haben, erhält ein Benutzer bei der ersten Verschlüsselung einer Datei mit EFS sein Zertifikat von Ihrer Zertifizierungsstelle, und Ihre Zertifizierungsstelle archiviert automatisch seinen privaten Schlüssel.

DRA-Schlüsselverwaltung
Wenn eine PKI vorhanden ist, sollten Sie überlegen, ob Sie durch eine Zertifizierungsstelle generierte DRA-Zertifikate verwenden möchten oder nicht. Was spricht gegen die Verwendung von DRA-Zertifikaten von Ihrer PKI? Betrachten Sie als Beispiel ein Szenario, in dem eine Zertifizierungsstelle mit einem recht kurzen Gültigkeitszeitraum (zwei Jahre oder weniger) Zertifikate ausgibt. Diese Zertifizierungsstelle kann keine Zertifikate ausgeben, deren Gültigkeitsdauer die eigene überschreitet, sodass der Gültigkeitszeitraum Ihrer DRA-Zertifikate (höchstens) bei zwei Jahren liegt. Das kann zu einem erheblich komplizierteren Datenwiederherstellungsszenario führen. Dieses hypothetische Beispiel ist im folgenden Szenario dargestellt.
  1. Ein Benutzer verschlüsselt eine Datei im Januar 2006. Die DRA-Zertifikate, die auf ihren Computer über eine Gruppenrichtlinie übertragen wurden, verfügen über einen Gültigkeitszeitraum von zwei Jahren (sie laufen im Januar 2008 ab).
  2. Der Benutzer arbeitet weiterhin mit EFS zum Verschlüsseln neuer Dateien.
  3. Im Januar 2008 laufen die DRA-Zertifikate ab, und der Administrator verschiebt neue Zertifikate über eine Gruppenrichtlinie auf den Computer.
  4. Sämtliche Verschlüsselungsvorgänge verwenden von diesem Zeitpunkt an die neuen DRA-Zertifikate (einschließlich sämtlicher vom Benutzer geöffneter Dateien, die mit den alten DRAs verschlüsselt wurden und für die beim Speichern die neuen DRAs verwendet werden). Alle Dateien, die im weiteren Verlauf nicht vom Benutzer verwendet werden, werden jedoch weiterhin durch die alten DRAs geschützt.
  5. Der Benutzer beschädigt versehentlich sein Profil, sodass eine Datenwiederherstellung erforderlich ist.
  6. Der IT-Administrator muss jetzt über zwei Sätze von DRA-Zertifikaten verfügen: Den neuen für alle Dateien, die seit Schritt 3 verwendet wurden, und den alten für alle Dateien, die seit diesem Zeitpunkt nicht angetastet wurden.
Auch wenn der IT-Administrator nach Schritt 3 ein Skript ausführen kann, um alle Dateien mit dem neuen DRA zu aktualisieren (mithilfe von cipher.exe /u), kann dies ein zeitaufwändiger Prozess sein. Darüber hinaus sind die DRA-Schlüsselpaare nach ihrem Ablaufdatum weiterhin nützlich, auch wenn die EFS-Komponente keine neuen Verschlüsselungsvorgänge erlaubt, wenn ein abgelaufenes DRA-Zertifikat in der entsprechenden Wiederherstellungsrichtlinie enthalten ist. Alte Dateien, die mit abgelaufenen DRA-Schlüsselpaaren verschlüsselt wurden, können natürlich weiterhin über diese wiederhergestellt werden. Daher sollten DRA-Schlüsselpaare nie verworfen werden, auch wenn deren Gültigkeitszeitraum überschritten wurde. Sie wissen schließlich nie genau, wann Sie diese wieder verwenden müssen.
Aus diesem Grund empfiehlt sich für Umgebungen, die Zertifizierungsstellen mit einer kurzen Gültigkeitsdauer für Zertifikate umfassen, die Bereitstellung von selbstsignierten DRA-Zertifikaten mit einer längeren Gültigkeitsdauer. Das Verschlüsselungsdienstprogramm umfasst einen Schalter (cipher.exe /r), der automatisch Schlüsselpaare für den EFS-Wiederherstellungs-Agent erstellt, die über eine Gültigkeitsdauer von 100 Jahren verfügen (siehe Abbildung 4). Das Zertifikat dieses Schlüsselpaars kann dann an Gruppenrichtlinienobjekte (Group Policy Objects, GPOs) angehängt werden und als DRA in Ihrer gesamten Organisation verwendet werden. Da die EFS-Komponente keine Prüfung der Vertrauenskette von DRA-Zertifikaten vornimmt, funktionieren diese selbstsignierten Zertifikate, ohne dass auf Ihren Systemen Änderungen an der Liste der vertrauenswürdigen Stammzertifizierungsstellen vorgenommen werden müssen. Unabhängig von der Gültigkeitsdauer der Zertifizierungsstelle einer Organisation, empfiehlt sich die Erstellung von mindestens einem DRA-Zertifikat mit langer Gültigkeit, das an ein domänenweites Gruppenrichtlinienobjekt angehängt werden sollte. Dabei sollte die Option zur Fallbackdatenwiederherstellung verwendet werden, für den Fall, dass alle anderen Optionen fehlschlagen. Das ist insbesondere dann von Bedeutung, wenn Sie DRA-Schlüssel verwenden, die von einer Zertifizierungsstelle generiert wurden, und kein Zertifizierungsschlüsselarchiv vorhanden ist. Für den Fall, dass ein DRA-Zertifikat manipuliert wird, können Sie das Gruppenrichtlinienobjekt mit einem neuen Zertifikat aktualisieren und cipher.exe /u verwenden, wie zuvor für die Aktualisierung von Dateien erläutert.

Abbildung 4 Ausführen von Cipher /R (Klicken Sie zum Verkleinern auf das Bild)

Abbildung 4 Ausführen von Cipher /R (Klicken Sie zum Vergrößern auf das Bild)
EFS-Ressource
Auf den folgenden Websites erhalten Sie eine Vielzahl weiterer Informationen zu Einzelheiten und bewährten Methoden für EFS.
  • Why you shouldn’t be using passwords of any kind on your Windows networks (in englischer Sprache)
  • Implementing Key Archival Walkthrough (in englischer Sprache)
  • Encrypting File System in Windows XP and Windows Server 2003 (in englischer Sprache)

KRA- und DRA-Bereitstellung
Die Schlüsselarchivierung bietet Administratoren von Zertifizierungsstellen die Möglichkeit, hinterlegte Verschlüsselungsschlüssel für den Benutzer wiederherzustellen. Dabei handelt es sich um eine äußerst sensible und leistungsstarke Funktion, da ein Zertifizierungsstellenadministrator so alle Daten in der Organisation entschlüsseln kann, für die ein Schlüssel verwendet wird, der von der Zertifizierungsstelle signiert wurde. Daher sollte die Schlüsselarchivierung und -wiederherstellung sehr sorgfältig behandelt werden, und nur einer geringen Anzahl an vertrauenswürdigen Sicherheitsmitarbeitern sollte eine Berechtigung dazu erteilt werden. Da die Schlüsselwiederherstellung ein sensibler Vorgang ist, ist eine eindeutige Definition eines Eskalationsprozesses für Wiederherstellungsanforderungen, die an Ihr Zertifizierungsstellenverwaltungsteam zu senden sind, unabdingbar, wenn Sie sich auf die Schlüsselwiederherstellung als primären Mechanismus verlassen möchten, um erneut Zugriff auf EFS-verschlüsselte Daten zu erlangen. Erst nach einer sorgfältigen Prüfung der Anforderung sollte der Wiederherstellungsprozess initiiert werden. Sobald die eigentliche Schlüsselwiederherstellung erfolgt ist, sollte der Schlüssel dem Benutzer über eine sichere Methode (also nicht über E-Mail) bereitgestellt werden, da der wiederhergestellte Schlüssel Zugriff auf sämtliche EFS-geschützte Daten des Benutzers ermöglicht.
Die Schlüssel des Schlüsselwiederherstellungs-Agent (Key Recovery Agent, KRA) werden von Zertifizierungsstellenadministratoren generiert und von diesen aufbewahrt und nicht über eine Gruppenrichtlinie bekannt gegeben. EFS selbst kann nicht feststellen, ob ein von ihm verwendeter Schlüssel archiviert wurde oder nicht. Es führt lediglich wie üblich die Verschlüsselungsvorgänge aus. Darüber hinaus sind die auf der Zertifizierungsstelle erstellten KRA-Schlüssel in keiner Weise für EFS spezifisch. Eine Zertifizierungsstelle, die eine Schlüsselarchivierung verwendet, verfügt über eine Anzahl von n KRA-Schlüsseln. Diese werden an die Zertifizierungsstelle auf der Zertifizierungsstellenebene angehängt, die zum Schutz aller von der Zertifizierungsstelle archivierten Schlüssel verwendet wird. Zu diesen Schlüsseln können die Schlüssel gehören, die mit EFS, sicherer E-Mail oder allen anderen Zertifizierungszwecken verwendet werden, bei denen eine Verschlüsselung vorgenommen wird. KRA-Schlüssel sollten sicher von den jeweiligen Schlüsselwiederherstellungs-Agents gespeichert werden, und es sollten mindestens zwei KRAs eingesetzt werden, um ein Fallback bereitzustellen, falls einer der Schlüssel verloren geht.
Wenn sich der Administrator zum ersten Mal in einer neu erstellten Domäne beim Domänencontroller anmeldet, wird auf Domänenebene eine standardmäßige Wiederherstellungsrichtlinie erstellt, wobei ein selbstsigniertes Zertifikat und Schlüsselpaar verwendet werden, die im Profil des Administrators auf dem DC gespeichert werden. Für dieses DRA-Zertifikat besteht eine Gültigkeitsdauer von drei Jahren. Es empfiehlt sich, dieses Standardzertifikat zu entfernen und durch selbstsignierte Zertifikate mit einer längeren Gültigkeitsdauer oder durch Zertifikate, die von Ihrer PKI ausgegeben wurden, zu ersetzen. Wenn Sie dieses selbstsignierte Standardzertifikat nicht entfernen, wird drei Jahre nach dessen Erstellung die Verschlüsselung neuer Dateien in Ihrer gesamten Domäne durch EFS gestoppt. Das liegt daran, dass das Zertifikat abgelaufen ist und EFS die Verschlüsselung von allen weiteren Daten verhindert, wenn ein abgelaufenes DRA-Zertifikat in der entsprechenden Wiederherstellungsrichtlinie enthalten ist. Auch wenn Windows XP und neuere Systeme ohne Richtlinie für Wiederherstellungs-Agents betrieben werden können, wird davon stark abgeraten. Wenn ein Benutzer aus irgendeinem Grund den Zugriff auf seinen Verschlüsselungsschlüssel verliert und keine Schlüsselwiederherstellung möglich ist, sind die Daten unwiderruflich verloren.
Wie bereits erwähnt, können DRA-Schlüssel entweder selbstsigniert sein oder von einer Zertifizierungsstelle ausgegeben werden. In den meisten Fällen stellt ein kombinierter Ansatz die optimale Methode dar, bei dem als letztes Mittel mindestens zwei selbstsignierte DRAs mit langer Gültigkeitsdauer unternehmensweit zur Verfügung stehen. Da DRA-Zertifikate über Gruppenrichtlinienobjekte bereitgestellt werden, verfügen sie über dieselben Vererbungsfunktionen wie andere GPOs. Mit anderen Worten, das standardmäßige Gebietsschema, die Site, die Domäne, die GPO-Ansammlung der Organisationseinheit (Organizational Unit, OU) und der Anwendungsalgorithmus, der die Anwendung von anderen GPO-Einstellungen steuert, gilt ebenfalls für DRAs. Daher kann eine Organisation einfach einen Stufenansatz für DRAs implementieren, bei dem die zentrale IT-Gruppe in allen Teilen des Unternehmens über einen DRA-Zugriff verfügt, die lokale IT-Gruppe jedoch darüber hinaus weiterhin ihre bestimmten Verantwortungsbereiche beibehält. Das stellt insbesondere in großen, geografisch verstreuten Organisationen eine wertvolle Hilfestellung dar, da so der Bedarf an der Übertragung großer verschlüsselter Datenmengen über WAN-Verbindungen reduziert wird, um die Datenwiederherstellung zu vereinfachen. In Abbildung 5 ist eine typische DRA-Bereitstellung in mehreren Stufen dargestellt.
Abbildung 5 Mehrstufige DRA-Bereitstellung
Abbildung 5 Mehrstufige DRA-Bereitstellung
In diesem Falle wäre das Ergebnis für einen Benutzer in der Baton Rouge-OU sechs DRAs für jede verschlüsselte Datei: Zwei von seinen lokalen Administratoren, zwei von der North America-IT-Gruppe und zwei von der Domänenebene. Wenn der Benutzer den Zugriff auf seine verschlüsselten Daten verliert, kann er daher für diese eine Wiederherstellung von einem lokalen DRA in Baton Rouge oder von der North America-IT-Gruppe veranlassen. Als letztes Fallback können auch die DRAs auf Domänenebene die Wiederherstellung der Daten übernehmen, wenn diese vier DRAs nicht oder nicht mehr verfügbar sind. Unabhängig davon, welcher DRA die Wiederherstellung durchgeführt hat, bleibt der Prozessverlauf im Wesentlichen gleich. Der Benutzer stellt die Daten zunächst dem DRA zur Verfügung. Es ist äußerst wichtig, dass der DRA die notwendigen Schritte vornimmt, um sicherzustellen, dass die Anforderung legitim ist und vom tatsächlichen Besitzer der Daten stammt. Sobald eine solche Prüfung erfolgt ist, lädt der DRA das DRA-Zertifikat, entschlüsselt die Daten (und verschlüsselt diese im Idealfall erneut) und sendet dann die Daten zurück an den Endbenutzer. Einige Organisationen entscheiden sich für eine lokale Wiederherstellung, bei der der DRA den Benutzer, bei dem das Problem besteht, vor Ort besucht, sein DRA-Schlüsselpaar in das Profil lädt, die Daten dann entschlüsselt und das Schlüsselpaar entfernt. Der Benutzer kann dann auf die Daten im Nur-Text-Format zugreifen und diese mit einem neuen Schlüssel erneut verschlüsseln. Dabei ist zu beachten, dass dieser Ansatz eine weitaus geringere Sicherheit bietet, da das DRA-Schlüsselpaar (wenn auch temporär) auf den lokalen Computer kopiert wird. Andererseits kann dieser Ansatz Zeit sparen, insbesondere dann, wenn eine große Datenmenge wiederhergestellt werden muss.
Bei der Bereitstellung einer Wiederherstellung für einen Benutzer über eine Schlüsselarchivierung und -wiederherstellung ist darauf zu achten, dass die Wiederherstellungsanforderung vollständig getrennt von diesem Prozess behandelt wird. Ohne den Einsatz eines DRA richtet sich die Wiederherstellungsanforderung des Benutzers an die Zertifizierungsstellenadministratoren, die die Anforderung überprüfen müssen und dann den privaten Schlüssel des Benutzers aus dem Archiv abrufen. Sie stellen dem Benutzer dann diesen privaten Schlüssel über eine sichere Methode zur Verfügung, z. B. durch Bereitstellen des Schlüssels zum Download auf einer sicheren Website. (Wenn der Benutzer zum Speichern seines EFS-Schlüssels eine Smartcard, die mit Windows Vista verfügbar ist, verwendet hat, sollte dieser Schlüssel ebenfalls erneut ausgegeben werden.) Der Benutzer lädt diesen Schlüssel in sein Profil und verfügt dann sofort über den Zugriff auf seine sämtlichen verschlüsselten Daten.
Da die DRA- und KRA-Schlüsselpaare zum Entschlüsseln von vertraulichen Daten verwendet werden können, ist ein ausreichender Schutz dieser Daten äußerst wichtig. DRA- und KRA-Schlüsselpaare sollten nicht in den normalen Desktopprofilen der Administratoren gespeichert werden (die Profile, in denen diese ihre normalen täglichen Aufgaben ausführen). Stattdessen sollten diese Schlüsselpaare sicher offline auf einer Diskette bzw. einem optischen oder Flash-Medium gespeichert werden, das an einem physisch sicheren Ort aufgewahrt wird. Wenn eine Wiederherstellung erforderlich ist, kann der Wiederherstellungs-Agent dann das Schlüsselpaar von diesem Medium auf eine Wiederherstellungsarbeitsstation laden, den Wiederherstellungsvorgang durchführen und das Schlüsselpaar entfernen. In einigen Organisationen, in denen eine besonders hohe Sicherheit gewährt werden muss, sind bestimmte Arbeitsstationen speziell für die Wiederherstellung vorgesehen, um die Sicherheit für diese Schlüsselpaare weiter zu erhöhen. Dies ist jedoch keine Anforderung für alle Organisationen.

Ausblick
Nachdem nun die EFS-Planung aus dem Blickwinkel der Schlüsselverwaltung und der Datenwiederherstellung sowie aus der Sicht von Active Directory untersucht wurde, werde ich mich in Teil 2 dieses Themas im nächsten Monat auf clientbasierte Bereitstellungsfragen konzentrieren. In diesem Zusammenhang werden unter anderem die folgenden Themen behandelt werden: die Steuerung der EFS-Verwendung über Gruppenrichtlinien, die Entscheidung darüber, was verschlüsselt werden sollte, die automatische Datenverschlüsselung durch Anmeldeskripts und clientbasierte Verbesserungen für Windows-Explorer, um die Arbeit mit EFS-geschützten Daten noch einfacher zu gestalten.

John Morello hat seine Promotion an der LSU mit Summa cum Laude abgeschlossen 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 Programm-Manager in der Windows Server Group an Sicherheits- und Remotezugriffstechnologien.


 Die Desktopdateien: Erweitern von Windows&#160;PE
Die Desktopdateien
Erweitern von Windows PE
Wes Miller

Schon bevor wir Windows PE vor über fünf Jahren veröffentlichten, hatten uns eifrige Kunden um mehr Features gebeten. Leider war Windows PE, im Unterschied zu beispielsweise Windows XP Embedded, nicht für unkomplizierte Erweiterungen durch Hinzufügen neuer Betriebssystemschichten entworfen worden. Selbstverständlich musste Windows PE grundlegende
Unterstützung für Win32® bieten (damit die meisten Windows®-Anwendungen darunter funktionieren) und natürlich Netzwerk- und Massenspeicherfunktionen unterstützen, damit nicht nur über das Netzwerk kommuniziert, sondern auch Windows installiert werden konnte. Wir wollten die Shell von Anfang an einschränken: Durch den Einsatz von „cmd.exe“ statt der herkömmlichen Shell des Windows-Explorers begrenzten wir die Funktionalität der Windows PE-Umgebung, und was noch wichtiger war: Die Standardumgebung haben wir so gestaltet, dass sie für alle Automatisierungsaufgaben darin skriptfähig war.
Man kann Windows PE erweitern. Man muss nur stets bedenken, dass diesem Vorhaben Grenzen gesetzt sind. Sie können davon ausgehen, dass eine Anwendung nicht funktioniert oder nur fehlerhaft ausgeführt wird, wenn dafür eine der in Abbildung 1 aufgelisteten Anwendungen erforderlich ist. (Diese Aufzählung ist nicht vollständig.)
Figure 1 Fehlende Windows-APIs (Close Figure 1)

.NET Framework (beliebige Version)
Active Directory® Service Interfaces (ADSI)
DirectX®
Microsoft Data Access Components (MDAC)
Jet (Access)
Visual Basic® (pre-.NET-Versionen eingeschlossen)
Jeder ausführbare Typ, für den ein Framework erforderlich ist, das nicht systemintern mit Windows installiert wird.
Windows-Explorer oder Internet Explorer
Windows Media® Player
SAPI, MAPI, TAPI (Windows-Sprachausgabe, E-Mail bzw. Telefonie-APIs)
Wenn Sie nicht wissen, wovon Ihre Anwendung abhängt, müssen Sie es herausfinden. Aber wie? Als wir versuchten, die ADO-, HTML Applications (HTA)- und Windows Script Host (WSH)-Komponenten unter Windows PE vor seiner Veröffentlichung zum Laufen zu bekommen, hatten wir dasselbe Problem. Wir möchten übrigens darauf hinweisen, dass dieser Artikel zwar Methoden enthält, wie man diese Abhängigkeiten aufspürt, dass das Hinzufügen von binärem Windows-Code zu ihrem Windows PE-Image, das über die Implikationen des MKIMG-Befehls hinausgeht, jedoch nicht vom Endbenutzer-Lizenzvertrag (End User License Agreement, EULA) abgedeckt wird. Sie benötigen eine Lizenzierungsergänzung von Microsoft, um entsprechende Änderungen in Ihrer Umgebung zu implementieren.

Erläuterung von Abhängigkeiten
Durch das Öffnen und gründliche Analysieren der .inf-Datei einer Anwendung in Editor können Sie viel lernen. Eigentlich bekommt man so oft am schnellsten heraus, was hinter einer Anwendung steckt und welche Abhängigkeiten sie hat. Das Wichtigste, was man über Windows PE wissen muss, ist, dass es normalerweise so eingeschränkt ist, dass man mehrere Ebenen von Abhängigkeiten zu debuggen hat – sowohl die direkten Abhängigkeiten der Anwendung als auch solche, die aus diesen Abhängigkeiten entstehen – um die Anwendung stabil ausführen zu können. Wenn man nicht aufpasst, kann dabei schnell eine wahre Kaskade aus Abhängigkeiten entstehen. Das zufällige (oder beabsichtigte) Hinzufügen einiger weniger Komponenten kann das Abbild erheblich an Größe und Komplexität zunehmen lassen.
Durch eine .inf-Datei, in der die Anwendung beschrieben wird, bekommen Sie Anhaltspunkte in Bezug auf die Abhängigkeiten, indem Sie nach Registrierungsschlüsseln und Dateien suchen, die von der .inf-Datei Ihrem System hinzugefügt werden. Suchen Sie nach den Abschnitten „CopyFiles“ und „AddReg“. Diese Eintragungen weisen auf Anwendungen, DLLs und andere Dateien hin, von denen Ihre Anwendung abhängt. Von den drei Add-Ins für Windows PE (ADO, HTA und WSH) war WSH am einfachsten zu erstellen. Da es immer noch eine weitervertreibbare WSH-Version für ältere Windows-Versionen gab und es heute eine in Windows integrierte .inf-Datei gibt, mit der die Dateizuordnungen für WSH vorgenommen werden (unter %windir%\inf\wsh.inf), war die Installation unter Windows PE verhältnismäßig einfach.

Orca und Erstellen von Snapshots
Wenn die betreffende Anwendung als Microsoft® Installer (MSI)-Datei verkauft wird, stehen Ihnen zwei Methoden für die Suche nach deren Abhängigkeiten zur Verfügung. Wenn Sie ein MSI-Experte sind, können Sie dazu Orca verwenden (ein Tool zum Bearbeiten von Windows Installer-Dateien, das im Rahmen des Windows Server® 2003 R2 Plattform SDK vertrieben wird): go.microsoft.com/fwlink/?LinkId=77941 Sie können den MSI auch für die gewünschten Komponenten installieren und eine Vorher/Nachher-Analyse der geänderten Dateien und Registrierungsschlüssel vornehmen. Sie können eine Sicherung von der Registrierung anlegen, die Anwendung installieren, die Registrierung erneut exportieren und anschließend WinDiff ausführen (siehe Randleiste „Verwenden von WinDiff“). Das Ergebnis lässt sich dann als Vorlage für Änderungen verwenden, die an der Registrierung vorzunehmen sind. Das Problem ist, dass es sich dabei um unzählige Änderungen handeln kann. Manchmal ist es jedoch am besten, wenn Sie keine .inf-Datei (oder den Autor der Anwendung) zur Verfügung haben.
Mit dem Prozess des Erstellens von Anwendungssnapshots werden Sie wahrscheinlich vertraut sein. Im Grunde genommen handelt es sich dabei um dieselbe Vorher-/Nachher-Analyse, die Sie durchführen, um Ihre Anwendung lauffähig zu bekommen. Früher war in Windows 2000 von Microsoft ein Tool enthalten, mit dem genau das möglich war. Leider funktionierte es mit späteren Windows-Versionen nicht mehr. Sie können zu diesem Zweck mittlerweile auf mehrere kommerzielle Anwendungen (so genannte Installationsrepackager) oder auch auf kostenlose Dienstprogramme zurückgreifen. Zum einen lässt sich dafür das Platform SDK installieren (siehe der Link im vorherigen Absatz), das WinDiff enthält. Hinweis: Wenn Sie mit WinDiff einen Vergleich durchführen möchten, sollten Sie die Anwendung im Idealfall auf Windows Server 2003, Service Pack 1 (SP1) installieren, da es sich dabei um die Version von Windows PE handelt, die zur Verwendung empfohlen wird: ein aus der Standard Edition oder Enterprise Edition (mit SP1) erstelltes Windows PE 1.6. Durch das Durchführen dieser Aufgabe unter Windows Server 2003 arbeiten Sie in einer Umgebung, die der von Windows PE am meisten ähnelt. Denken Sie daran, dass Sie MSI unter Windows PE nicht ausführen können. Folgen Sie den Schritten in der Randleiste „Verwenden von WinDiff“.
Dort finden Sie einen Großteil der Informationen, die geändert wurden. Bedauerlicherweise ist es nicht gerade einfach, die geänderten Informationen oder erfasste Dateien aus der Registrierung zu exportieren, um eine Art Manifest zur Installation Ihrer Anwendung zu erstellen. Sie müssen die Änderungen manuell implementieren. Dabei sind wir auf einige der größten Probleme mit der ersten Version von Windows PE gestoßen. Es war schon kompliziert, überhaupt die HTA-Komponenten zum Laufen zu bringen, da Microsoft sie außerhalb des Internet Explorers®) nicht definiert hatte. Durch Differenzierung konnten wir genügend HTA-Unterstützung bereitstellen, um es zum Laufen zu bringen. Sie können diese Schlüssel zwar manuell in die Registrierung von Windows PE einfügen, sollten damit aber warten, bis Windows PE hochgefahren ist. Sehen Sie sich die Dateien „OC.bat“ und „OC2.bat“ an, die zur Installation der HTA-, WSH- und/oder ADO-Unterstützung durch das Skript „buildoptionalcomponents.vbs“ aus den Buildtools von Windows PE verwendet wurden.

Nützliche Tools
Sogar nach dem Isolieren der direkten Abhängigkeiten findet man nicht immer alle Binärdateien, von denen Ihre Anwendung abhängt. Sie werden z. B. nicht wissen, ob sie zur Durchführung ihrer Aufgaben noch zusätzliche DLL- oder OCX-Dateien benötigen. Woher weiß man das? Mark Russinovich von Sysinternals (jetzt Technical Fellow bei Microsoft) hat ein praktisches Dienstprogramm namens „listdlls“ geschrieben, das genau diese Lücke füllt. Listdlls kann von microsoft.com/technet/sysinternals/utilities/ListDlls.mspx heruntergeladen werden. Um das Dienstprogramm zu verwenden, führen Sie den Befehl „listdlls.exe > dlls.txt“ aus, und sehen Sie sich die ausgegebenen Daten näher an. Abbildung 2 spiegelt die Ausgabe von listdlls nach der Ausführung auf sich selbst wider. Sie können diese Liste mit den DLL- und OCX-Dateien in Windows PE vergleichen, um zu bestimmen, ob alle Abhängigkeiten Ihrer Anwendung an der richtigen Stelle sind oder nicht (im Fall von listdlls sind sie bereits vorhanden). Bei der HTA-Unterstützung unter Windows PE war listdlls ganz wichtig für die Identifizierung bestimmter Abhängigkeiten, die sonst nicht aufzufinden waren.
Abbildung 2 Ausgabe von lisdlls nach Ausführung auf sich selbst
Abbildung 2 Ausgabe von lisdlls nach Ausführung auf sich selbst (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 2 Ausgabe von lisdlls nach Ausführung auf sich selbst
Abbildung 2 Ausgabe von lisdlls nach Ausführung auf sich selbst (Klicken Sie zum Vergrößern auf das Bild)
Das bedeutet aber nicht, dass eine aufgelistete DLL auch unbedingt erforderlich ist, damit die Anwendung funktioniert. Wenn Sie z. B. Editor laden, lädt es die Datei „uxtheme.dll“ mit. Unter Windows PE ist diese DLL nicht verfügbar, und da Windows-Designs dort keine Verwendung finden, wird diese auch nie geladen. Man muss sich klar machen, welche von den durch listdlls angezeigten DLLs wirklich erforderlich sind, und welche bei Bedarf von Windows geladen werden. Das ist leider eine schwierige Angelegenheit. Man kann sich diese Fähigkeit entweder durch Ausprobieren oder durch Untersuchen der grundlegenden Ebenen von Windows aneignen. (Dazu empfehle ich das Buch Microsoft Windows Internals, Fourth Edition (Microsoft Press® 2004) von Mark Russinovich und David Solomon.)
Mark hat übrigens auch dieselbe Funktionalität in dem frei verfügbaren „Process Explorer“ (Ersatz für den Task-Manager von Windows) bereitgestellt. Der Unterschied besteht meiner Meinung nach darin, dass die von listdlls ausgegebenen Daten leichter bearbeitbare Skripts enthalten und sich besser für das Finden und Sammeln fehlender Abhängigkeiten eignen.
Bedenken Sie, dass Sie auch nach dem Hinzufügen einer DLL zu einem Abbild durchaus etwas zu tun haben könnten. Das heißt, es gibt zwei Arten von DLLs: solche, die registriert werden müssen, und solche, bei denen das nicht erforderlich ist. Leider kann man sie nicht so leicht voneinander unterscheiden. Man muss sie einzeln registrieren, um das herauszufinden. Führen Sie zum Registrieren einer DLL oder einer OCX „regsvr32 dllname.dll“ aus. Wenn es funktioniert, erhalten Sie eine Mitteilung, dass die DLL registriert wurde. Wenn nicht, erhalten Sie entweder keine Mitteilung, oder es wird ein Dialogfeld angezeigt, das Sie darüber informiert, dass die DLL nicht registriert wurde oder nicht registriert werden konnte. Beim Entwickeln der optionalen HTA- und ADO-Komponenten für Windows PE fanden wir heraus, dass DLLs bei der Durchführung ihrer Registrierung beschreibbaren Speicher brauchen, um entweder temporär eine .inf-Datei für die Installation abzulegen oder eine andere Abhängigkeit (z. B. ein bestimmtes Verzeichnis) aufzuzeichnen. Unter Windows PE bedeutete das, dass Fehler auftraten. Glücklicherweise können solche Aufgaben unter Windows PE 2.0 durchgeführt werden, da es jetzt standardmäßig einen sicheren Speicherbereich für temporäre Dateien gibt.
Außerdem hat Mark vor kurzem noch ein drittes Tool namens „Process Monitor“ veröffentlicht. Process Monitor kann als eine Art Superset von „Regmon“ und „Filemon“ betrachtet werden und bietet noch erheblich mehr Details als beide Programme zusammen, weil es dem Anwender eine ganz neue Ebene der Kommunikation zwischen Prozessen eröffnet. Dieses unglaublich leistungsfähige Tool kann Ihnen dabei helfen, Anwendungsfehler unter Windows zu beheben, und Ihnen Fragen zu gegenseitigen Abhängigkeiten von DLLs beantworten. Sie können Process Monitor herunterladen.

Entfernen von Windows PE-Dateien
Außer der Möglichkeit, Windows PE etwas hinzuzufügen, wurde oft eine zweite Bitte laut: Das Betriebssystem selbst sollte verkleinert werden. Sie können verschiedene Schritte unternehmen, um den Umfang von Windows PE etwas zu verringern. Ihre lizenzierte Kopie von Windows PE müsste eine Sammlung von Buildtools und eine Dokumentation umfassen. Eines der Dokumente ist eine Hilfedatei namens „winpe.chm“. Wenn Sie diese Datei öffnen und sich den Abschnitt mit dem Benutzerhandbuch für die Vorinstallationsumgebung durchlesen, stoßen Sie auf ein Thema, das sich mit der Verringerung der Größe von Windows PE beschäftigt. In diesem Abschnitt finden Sie eine Liste mit Dateien, die Sie beruhigt entfernen können, vorausgesetzt, Sie benötigen sie nicht für Ihre Zwecke. Die entfernbaren Dateien werden in drei Abschnitten behandelt:
  • Schriftartendateien können immer problemlos entfernt werden.
  • Netzwerkbezogene .inf-Dateien und Dienstprogramme können auch entfernt werden, doch das sollten Sie nur dann tun, wenn Sie Ihren Build überhaupt nicht in einem Netzwerk verwenden möchten.
  • Befehlszeilenprogramme sollten nicht entfernt werden. Ich rate Ihnen davon ab, solche Programme zu entfernen, wenn Sie nicht ganz genau wissen, welche Aufgaben diese haben und welche Folgen ein Entfernen haben könnte.
Wenn Sie wissen, welche Dateien Sie guten Gewissens ausschließen können, schreiben Sie einfach eine Batchdatei oder ein Skript, lassen Sie „mkimg.com“ den Build fertig stellen, und entfernen Sie anschließend Ihre Auswahl aus Windows PE.

Ändern der Windows PE-Registrierung
Sie werden bemerkt haben, dass wir die optionalen Komponenten absichtlich nicht zusammen mit dem Build installiert haben. Obwohl das ein bisschen mehr Zeit zur Laufzeit bedeutete, mussten wir auf der anderen Seite keine völlig neue Methode erfinden, um diese Komponenten wieder in Windows PE zu integrieren. Dazu hatten wir nämlich keine Zeit, und wenn es hart auf hart gekommen wäre, hätten wir die Komponenten ganz weglassen müssen. Doch was, wenn man eine Änderung an der Registrierung vornehmen will (wie das Einfügen eines Deltas mit den Registrierungsänderungen für Ihre Anwendung) oder einen Schlüssel bearbeiten möchte, mit dem die Anwendung vielleicht lauffähig bleibt? Das geht mit „regedit“ ganz einfach (siehe Abbildung 3). Führen Sie die folgenden Schritte aus:
  1. Führen Sie „regedit“ aus, und wählen Sie die Struktur HKEY_LOCAL_MACHINE.
  2. Wählen Sie „File“ (Datei) | „Load Hive“ (Struktur laden), und suchen Sie nach dem Speicherort Ihres Windows PE-Builds. Wählen Sie „setupreg.hiv“ unter I386\System32\ (oder MiniNT\System32, wenn Sie das Abbild auf einer Festplatte ablegen wollen).
  3. Geben Sie einen vorläufigen Namen für die Struktur wie z. B. „WinPE“ ein, und navigieren Sie unter HKLM zu diesem Knoten.
  4. Ändern Sie diesen Schlüssel entsprechend. Interessanterweise ist dieser Knoten eigentlich identisch mit dem Knoten „HKLM\System“, den man auf einer normalen Windows-Installation findet.
  5. Wenn Sie Ihre Änderungen durchgeführt haben, wählen Sie den Schlüssel unter HKLM aus, den Sie in Schritt 3 erstellt haben. Achten Sie dabei auf eine korrekte Durchführung, sonst beschädigen Sie u. U. Ihr System.
  6. Wählen Sie „File“ (Datei) | „Unload Hive“ (Struktur entfernen), und bestätigen Sie das Ja/Nein-Dialogfeld. Achten Sie darauf, die Registrierung jedes Mal freizugeben, denn eine Sperre verhindert ein erfolgreiches Build von Windows PE.
Abbildung 3 Öffnen der Windows PE-Registrierung
Abbildung 3 Öffnen der Windows PE-Registrierung (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 3 Öffnen der Windows PE-Registrierung
Abbildung 3 Öffnen der Windows PE-Registrierung (Klicken Sie zum Vergrößern auf das Bild)
HKLM\System ändern Sie, indem Sie die nachfolgenden Schritte ausführen. Unter I386\System32 gibt es noch zwei weitere Schlüssel, mit denen Sie andere Bereiche der Registrierung ändern können: DEFAULT, die Standardstruktur für Benutzer (auch SYSTEM, das Sie ausführen, während Sie Windows PE verwenden), und SOFTWARE, das identisch mit HKLM\Software ist. Ändern Sie die Registrierung wie immer mit der größten Sorgfalt, und führen Sie dabei nur wirklich erforderliche Schritte aus.
Jetzt wissen Sie ungefähr, wie Sie Ihr Lieblingstool für die Fehlerbehebung oder Wiederherstellung auf Windows PE migrieren können. Nächsten Monat bespreche ich die PSTools-Suite mit Ihnen, eine Sammlung sehr nützlicher Tools für die Systemverwaltung, die ebenfalls von Mark Russinovich geschrieben wurden.
Verwenden von WinDiff
WinDiff kann Ihnen helfen, die Abhängigkeiten ihrer Anwendung zu finden. Führen Sie die folgenden Schritte für eine erfolgreiche Installation und Ausführung aus:
  1. Bereiten Sie Ihr System für die Installation vor. Die Zeiten und die Änderungen an Dateien oder der Registrierung zwischen dem ursprünglichen und finalen Snapshot müssen auf ein Minimum reduziert werden.
  2. Öffnen Sie die Eingabeaufforderung, und führen Sie „reg export HKLM C:\HKLM1.reg“ aus, um die Registrierungsstruktur von HKEY_Local_Machine vollständig zu exportieren.
  3. Führen Sie „dir C:\*.* /S > C:\C1.txt“ aus, um ein Abbild aller Dateien auf Laufwerk C: zu erstellen, falls C: Ihr Systemlaufwerk ist.
  4. Installieren Sie Ihre Anwendung, und konfigurieren Sie alle Einstellungen, die nach der Installation vorzunehmen sind.
  5. Führen Sie „reg export HKLM C:\HKLM2.reg“ aus.
  6. Führen Sie „dir C:\*.* /S > C:\C2.txt“ aus.
  7. Öffnen Sie WinDiff, und wählen Sie „File“ (Datei) | „Compare Files...“ (Dateien vergleichen...). Danach wählen Sie HKLM1.reg im ersten Dateifeld zu Öffnen der Datei aus und HKLM2.reg im zweiten.
  8. Eine in roter Schrift dargestellte Meldung teilt Ihnen mit, welche davon neueren Datums ist. Seien Sie geduldig: Der Vorgang kann etwas dauern, da die HKLM-Exporte manchmal ziemlich groß sind.
  9. Doppelklicken Sie auf den roten Text, um die Unterschiede zu erweitern.
  10. Sie können bestimmen, welche Daten in dem Vergleich angezeigt werden sollen, indem Sie „Options“ (Optionen) | Show Right-Only Lines“ (Nur-Rechts-Zeilen anzeigen) auswählen. Dadurch werden nur die neu hinzugefügten Zeilen in der zweiten Vergleichsdatei angezeigt. Sie sehen also dort nur neue Dateien und Registrierungsschlüssel.
Hinweis: Es kann sein, dass Sie die Find-Funktion einsetzen müssen, um Schlüssel zu finden, die sich auf Ihre Anwendung beziehen. In den Abbildungen A und B sehen Sie Datei- und Registrierungsänderungen an einer Beispieldatei, die ich erstellt habe. Zum Glück kann man in WinDiff auch kopieren und einfügen. Um diese Funktionen zu verwenden, klicken Sie einfach auf die !>-Zeile und wählen die gewünschten Zeilen aus.
Abbildung A WinDiff-Einträge
Abbildung A WinDiff-Einträge (Klicken Sie zum Verkleinern auf das Bild)
Abbildung A WinDiff-Einträge
Abbildung A WinDiff-Einträge (Klicken Sie zum Vergrößern auf das Bild)
Abbildung B Bestimmter Schlüssel in WinDiff
Abbildung B Bestimmter Schlüssel in WinDiff (Klicken Sie zum Verkleinern auf das Bild)
Abbildung B Bestimmter Schlüssel in WinDiff
Abbildung B Bestimmter Schlüssel in WinDiff (Klicken Sie zum Vergrößern auf das Bild)

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


 Berichte aus der Praxis: Die Verbindung wird einfach unterbrochen
Berichte aus der Praxis
Die Verbindung wird einfach unterbrochen
R'ykandar Korra'ti

„Meine Verbindung wird immer wieder getrennt.“
„Zu einer bestimmten Tageszeit? Machen Sie gerade etwas Bestimmtes, wenn das geschieht? Stellen Sie von einem bestimmten Computer eine Verbindung her?“
„Nein. Erst bin ich drin und dann auf einmal nicht mehr. Ganz plötzlich.“
„Das ist nicht gerade viel, um mir ein Bild machen zu können. Versuchen Sie, das Problem genauer zu beschreiben“.
„Ich habe alles erzählt, was ich weiß. Manchmal wird die Verbindung einfach getrennt. Können Sie das Problem beheben?“
Ich sage, dass ich mich darum kümmern werde. Die Routerprotokolle geben nicht viel her, aber unser Datenverkehr fällt wirklich gelegentlich ab, was darauf hinweist, dass etwas nicht in Ordnung ist, jedoch immer nur für ein oder zwei Minuten, und danach ist alles wieder normal. Keine Fehler, kein Muster, nur ab und zu kein Datenverkehr. Es ist seltsam. Dann haben wir Glück:
Dasan die DSL-Buchse angeschlossene Telefon klingelt.
Daraufhinfällt unsere IP-Verbindung aus.
Das kann doch nicht wahr sein, denke ich. Dennoch lässt sich der Fehler reproduzieren: Wenn jemand die DSL-Telefonnummer anruft – jene, die niemand verwendet und von der keiner etwas wissen sollte – wird unsere Verbindung getrennt. Das Hauptverkaufsargument für den Service der Telefongesellschaft, das Hauptproblem, von dem sie behaupten, dass man sich darüber überhaupt keine Sorgen machen müsse, tritt ein – live und in Farbe.
Dabei sind wir nur 300 m von der Verteilerstation entfernt. Dies dürfte nicht passieren. Ich prüfe die Kabel, setze alles zurück und reinige sogar die Anschlüsse, um zu sehen, ob es hilft. Aber natürlich tut es das nicht. Daher rufe ich die Telefongesellschaft an. „Sie versprechen doch, dass die Verbindung nie durch eingehende Telefonanrufe unterbrochen wird? Raten Sie mal, was passiert! Unsere Verbindung kann durch Anrufe von Telefonwerbern zusammenbrechen.“
Vielleicht liegt es am Kupfer ...
Vielleicht liegt es am Kupfer ...
Am nächsten Tag kommt ein Techniker vorbei und stellt fest, dass wir laut Test unerklärlicherweise mehr als 900 m von der Verteilerstation entfernt sind – weit genug, dass ein launisches Eichhörnchen mit einem kleinen Kompassmagneten unsere Verbindung trennen könnte. Schließlich finden wir Folgendes heraus: Als unsere Nachbarschaft damals verkabelt wurde, wurden alle Telefonleitungen gebündelt, und jede Leitung wurde zu jedem Gebäude im Viertel verlegt. So sollte vermieden werden, dass jemals neue Kabel verlegt werden müssten. Das ist in Ordnung, wenn Ihre ganze Welt aus analogen Telefonverbindungen besteht, vom DSL-Standpunkt aus verlängert jedoch jeder lineare Zoll dieser Verzweigungen die Entfernung von der Verteilerstation, wodurch die Signalstärke abnimmt.
Zum Glück konnte das Problem schnell und einfach behoben werden. Alle seitlichen Verzweigungen der Leitung wurden getrennt, und es wurde eine Notiz mit dem Hinweis hinzugefügt: „NICHT WIEDER ANSCHLIESSEN. DSL-FUNKTION IN GEBRAUCH“. Hurra! Eine Entfernung von nur 300 m, ein viel stärkeres Signal, und, was am wichtigsten ist, kein Verbindungsausfall beim Klingeln.
Die Moral der Geschichte: Nehmen Sie nicht an, dass ein Verbindungsproblem nur von Eingeweihten gelöst werden kann oder gar durch Software verursacht wird. Manchmal liegt es einfach an der Kupferleitung. Lassen Sie die Mitarbeiter der Telefongesellschaft bei der Installation immer die tatsächliche DSL-Signalstärke prüfen, selbst wenn sie sicher sind, dass dies nicht nötig ist. Sie können nie wissen, was sonst noch an die Leitung angeschlossen ist und nur darauf wartet, Sie später zu verwirren. Verlassen Sie sich auch nicht auf ihre Angaben zur Entfernung von der Verteilerstation. Sie wissen nicht, wohin diese Kabel verlaufen, und auch die Leute von der Telefongesellschaft haben keine Ahnung. Finden Sie es heraus. Die Telefongesellschaft verfügt über die erforderlichen Werkzeuge und die entsprechende Technologie. Bringen Sie sie dazu, sie einzusetzen. Sie werden froh darüber sein, insbesondere wenn Telefonwerber Ihre DSL-Nummer herausfinden.

R'ykandar Korra'ti, Postmaster eines kleinen, genossenschaftlichen Internetdienstanbieters, lebt mit ihrer Partnerin Anna in der Nähe von Seattle. Früher war sie bei Microsoft für den Versand von E-Mail-Produkten verantwortlich und erwägt jetzt, eine Hochschule für Aufbaustudien in einem Fach zu besuchen, das so esoterisch ist, dass es keinen richtigen Namen hat. Potenzielle Hochschulberater können sie unter darako@murkworks.net


 Windows Confidential: Ein zweischneidiges Schwert
Windows Confidential
Ein zweischneidiges Schwert
Raymond Chens

Wenn Sie eine CD oder DVD einlegen, überprüft die Shell den Datenträger, um zu ermitteln, welche Art von Inhalten sich darauf befindet. Anhand dieser Information kann die Shell dann entscheiden, welche Aktion zur automatischen Wiedergabe ausgeführt werden muss. Die genauen Details dazu, wie diese Überprüfung („Sniffing“) erfolgt, sind nicht dokumentiert, da es sich hierbei um heuristische Methoden handelt, die sich in der Zukunft ändern können, wenn ein besserer Algorithmus gefunden wird.
Durch eine Dokumentation des Algorithmus würde dieser vertraglich festgelegt, wodurch verhindert würde, dass der Algorithmus in späteren Versionen optimiert werden kann. Offiziell werden daher die Details des Algorithmus nicht angegeben.
Wenn Sie noch nie eine Dokumentation für ein SDK geschrieben haben, wissen Sie vielleicht nicht, dass die Dokumentation zu einer vertraglichen Bindung führt. Sobald Sie schriftlich niederlegen, dass sich etwas auf eine bestimmte Weise verhält, können Sie es nicht mehr ändern. Andernfalls sagen die Leute, die sich auf dieses Verhalten verlassen haben: „Das steht aber nicht in der Dokumentation. Sie ändern die Regeln, nachdem das Spiel bereits begonnen hat.“
Nachdem ich diese Warnung ausgesprochen habe, soll an dieser Stelle ein schnelle, unglaublich stark vereinfachte Beschreibung der Methode folgen, mit der Windows® XP Service Pack 2 (SP2) den Inhalt von Daten-CDs und Daten-DVDs kategorisiert, auf denen die Datei „autorun.inf“ fehlt. (Zukünftige Service Packs und Windows-Versionen könnten sich anders verhalten.) Ich sage „unglaublich stark vereinfacht“, weil der eigentliche Algorithmus eine 61 Schritte umfassende Entscheidungstabelle ist, die alle Arten von Informationen berücksichtigt, z. B. ob die Vordergrundanwendung auf die Benachrichtigung „Query cancel autoplay“ reagiert hat, ob ein Programm im Vollbildmodus ausgeführt wird und sogar ob es sich bei dem Computer um einen Laptop handelt, der vor kurzem an- oder abgedockt wurde. Ich werde jedoch nur auf den Schritt der Inhaltsermittlung eingehen.

Zuerst prüft die Shell, ob der Benutzer „Keine Aktion durchführen“ als Aktion für alle Inhaltstypen festgelegt hat. Wenn dies der Fall ist, hat das Sniffing keinen Sinn. Die Entscheidung lautet einfach „Keine Aktion durchführen“.
Andernfalls hat die Shell etwas zu tun. Sie prüft jede Datei auf dem Datenträger – auf bis zu vier Verzeichnisebenen – und teilt sie auf Basis des erkannten Typs in eine der folgenden Kategorien ein: Bild, Musik, Film.
Dateien, die in keine dieser Kategorien passen, werden ignoriert. Wenn alle geprüften Dateien zu nur einer Kategorie gehören (wenn beispielsweise alle Dateien auf dem Datenträger Musikdateien sind), wird dadurch der Typ des Datenträgers bestimmt. Wenn mehr als eine der drei Kategorien vertreten ist, wird festgestellt, dass der Datenträger gemischten Inhalt enthält.
Dies bedeutet, dass Nichtmusikdateien auf einer Musik-CD dazu führen, dass die CD von Windows XP SP2 als Datenträger mit gemischtem Inhalt behandelt wird. Dies ist eines der Dinge, die wahrscheinlich optimiert werden sollten. Angenommen, dieser Algorithmus würde jedoch optimiert und wir würden entscheiden, dass vereinzelte Bilder auf einer CD mit MP3-Dateien nicht den Ausschlag dafür geben sollten, dass von gemischtem Inhalt ausgegangen wird. Ein Unternehmen verfügt möglicherweise über eine CD mit vielen Audiodateien und nur wenigen Bildern. Das Unternehmen verlässt sich in der Tat darauf, dass die CD als Datenträger mit gemischtem Inhalt erkannt wird. Wird der Algorithmus jedoch geändert, wird die CD fälschlicherweise als Musik-CD kategorisiert. Das Unternehmen ist darüber natürlich nicht glücklich. Wer trägt jedoch die Schuld an diesem Problem? Kann dem Unternehmen vorgeworfen werden, dass es sich auf die Details des Sniffingalgorithmus verlassen hat? Oder sollte Windows die Schuld gegeben werden, weil es für die Änderung des Algorithmus verantwortlich ist?
Siehe da, in Windows Vista™ wurde der Algorithmus geändert – wenn auch nur geringfügig. In Windows Vista werden im Voraus mehrere Prüfungen durchgeführt, um den Algorithmus für bestimmte bekannte Datenträgerlayouts kurzzuschließen. Wenn z. B. ein DCIM-Ordner im Stammverzeichnis des Datenträgers vorhanden ist, wird angenommen, dass er aus digitalen Bildern besteht. Jetzt warten wir ab, ob es irgendjemand merkt.

Raymond Chens Website, The Old New Thing, und sein gleichnamiges Buch (Addison-Wesley, 2007) beschäftigen sich mit der Windows-Geschichte und der Win32-Programmierung. Raymond Chen fragt sich, wie die Sonne aussieht.