Gruppenrichtlinie

Leistungsoptimierung für Gruppenrichtlinien

Darren Mar-Elia

Kurz zusammengefasst:

• Monolithische und funktionale Gruppenrichtlinienobjekte
• So verarbeiten Sie Gruppenrichtlinieneinträge
• Was geschieht bei Änderungen an einer Gruppenrichtlinie?

Ich werde oft gefragt, ob es unter Leistungsgesichtspunkten besser ist, eher weniger und größere GPOs zu haben oder eher viele kleinere.Um diese und andere Fragen zu Entwurf und Leistung von Gruppenrichtlinien geht es in diesem Artikel.Wie bei den meisten stark verallgemeinernden Fragen

kann ich Ihnen die Antwort im Voraus geben:„Es kommt darauf an“.Das ist zwar zunächst eine ausweichende Antwort, doch Ziel dieses Artikels ist die Erläuterung der Methoden, die der Gruppenrichtlinienverarbeitung zu Grunde liegen. So sind Sie bei Entscheidungen über Ihren Gruppenrichtlinienentwurf gut informiert, unabhängig davon, ob Sie ganz am Anfang stehen oder ob Sie eine Umgebung mit Hunderten bereits vorhandener GPOs optimieren möchten.

Monolithische und funktionale Gruppenrichtlinienobjekte

Zunächst wird beschrieben, auf welche verschiedenen Arten GPOs implementiert werden können.Die Begriffe „monolithisch“ und „funktional“ bezeichnen die Art, wie Sie Ihre GPOs entwerfen.Monolithische GPOs enthalten Einstellungen aus vielen verschiedenen Bereichen.So könnte zum Beispiel ein einzelnes monolithisches GPO Richtlinien zu Einstellungen administrativer Vorlagen, zur Internet Explorer-Wartung und zur Softwareinstallation enthalten.Im Gegensatz dazu bewirken funktionale GPOs in der Regel nur eine Sache.So enthält zum Beispiel ein funktionales GPO etwa nur Richtlinien zur Softwareinstallation, oder es erzwingt lediglich Sicherheitseinstellungen.Es gibt sogar funktionale GPOs, die nur eine einzige Richtlinieneinstellung enthalten!Aber das ist wahrscheinlich eine Ausnahme.Abbildung 1 zeigt einige der Vor- und Nachteile des jeweiligen Ansatzes.

Figure 1 Vergleich monolithischer und funktionaler GPOs

Wie Sie sehen, gibt es keine eindeutige Antwort, das ein bestimmter Ansatz, der monolithische oder der funktionale, in allen Fällen der beste ist.In Ihrer Umgebung sind wahrscheinliche beide erforderlich.Zum Beispiel finden Sie möglicherweise den funktionalen Ansatz vorteilhafter, wenn Sie für Ihre ganze Domäne eine Sicherheitsrichtlinie erstellen.Wenn ein einziges GPO vorliegt, das nur Sicherheitseinstellungen enthält, können Sie die Kontrolle über dieses GPO leicht an Ihre Sicherheitsadministratoren delegieren, bei denen niemand anders Zugriff darauf hat.Wenn Sie demgegenüber die Verwaltung der Gruppenrichtlinie an die Administratoren einer Organisationseinheit delegieren, erhalten diese Administratoren durch die Einrichtung eines monolithischen GPOs für jede Organisationseinheit einen einzigen Ort, an dem alle Richtlinieneinstellungen verwaltet werden können.Dies kann für die Administratoren zu verringerter Komplexität führen und es Ihnen ermöglichen, die Anzahl der GPOs zu beschränken, die für Benutzer und Computer einer bestimmten Organisationseinheit erstellt werden.

Wie wirken sich diese grundlegenden Entwurfsentscheidungen auf die Leistung der Gruppenrichtlinienverarbeitung aus, und wie können Sie zum Entwurf von Gruppenrichtlinien intelligente Entscheidungen treffen, die minimale Auswirkungen auf die Leistung haben?Der erste Schritt der Leistungsmaximierung für Ihre Gruppenrichtlinieninfrastruktur besteht darin zu verstehen, wie Gruppenrichtlinienverarbeitung im Detail funktioniert.

Erläuterungen zur Gruppenrichtlinienverarbeitung

Gruppenrichtlinienverarbeitung ist ein komplexer Satz von Interaktionen, an denen viele Teile Ihrer Windows®- und Active Directory®-Infrastruktur beteiligt sind.Im Grundsatz besteht die Gruppenrichtlinienverarbeitung aus zwei Teilen.Der erste wird als Kernverarbeitung oder Verarbeitung der Gruppenrichtlinieninfrastruktur bezeichnet.In dieser Phase fragt der Client einer Windows-Gruppenrichtlinie seinen nächsten Domänencontroller nach der Verbindungsgeschwindigkeit zum DC, nach dessen Speicherort in der Active Directory-Hierarchie (d. h. Mitglied welcher Site, Domäne und Organisationseinheit der Client ist), sowie nach den GPOs, die für den Computer oder den derzeit angemeldeten Benutzer gelten.(Hierbei ist zu beachten, dass ein Client in diesem Zusammenhang ein Server oder eine Arbeitsstation sein könnte, der bzw. die an einer Active Directory-Domäne beteiligt ist.)Nach Erstellung der GPO-Liste folgt als nächste Phase die Verarbeitung der clientseitigen Erweiterung (Client-Side Extension, CSE).Während der CSE-Phase verarbeitet jede registrierte CSE die Liste der GPOs, bei denen im Bereich dieser Liste Einstellungen implementiert sind.Zum Beispiel wird die Registrierungsvorlagen-CSE oder die CSE für administrative Vorlagen in allen Fällen zuerst ausgeführt und verarbeitet alle GPOs, die für den vorliegenden Computer oder Benutzer gelten und in denen Registrierungsrichtlinien implementiert sind.

In der folgenden Liste sind die Schritte aufgeführt, die der Verarbeitungszyklus der Gruppenrichtlinie durchläuft, einschließlich der Netzwerkinteraktionen zwischen dem Client und dem Domänencontroller.Sie müssen berücksichtigen, dass Gruppenrichtlinien sowohl für Computer als auch für Benutzer gelten.Deshalb wird jedes Mal, wenn die Richtlinie einen Verarbeitungsvorgang durchführt – zum Beispiel während einer Hintergrundaktualisierung von Gruppenrichtlinien –, der unten aufgeführte Zyklus sowohl für den Computer als auch für das derzeit angemeldete Benutzerkonto auf einem bestimmten System wiederholt, da jeder Computer und jedes Benutzerkonto möglicherweise einen jeweils unterschiedlichen Satz geltender Richtlinien hat.In dem Fall führt Windows den Verarbeitungszyklus gleichzeitig sowohl für den Computer als auch für den Benutzer durch, wobei jeder Zyklus auf einem unterschiedlichen Thread innerhalb des Gruppenrichtlinienmodulprozesses ausgeführt wird.(Der Winlogon-Prozess für Windows 2000, Windows XP und Windows Server® 2003 sowie der Gruppenrichtlinienclient-Dienst in Windows Vista® und Windows Server 2008.)

Die Verarbeitung einer Gruppenrichtlinie ist ein sechsstufiges Verfahren:

1. Der Client führt ICMP-Erkennung (Internet Control Message Protocol) langsamer Verbindungen zu einem Domänencontroller in seiner Site durch, um die Verbindungsgeschwindigkeit zu ermitteln.In Windows Vista wird die Verwendung von ICMP zur Erkennung langsamer Verbindungen durch den NLA-Dienst (Network Location Awareness) ersetzt.
2. Der Client liest die CSE-Statusinformationen in der lokalen Registrierung, um zu ermitteln, welche GPOs zuletzt verarbeitet wurden.
3. Der Client verwendet LDAP, um das Attribut „gpLink“ in Active Directory auf jedem Containerobjekt innerhalb seines Speicherorts in der Active Directory-Hierarchie zu suchen: zuerst auf der Ebene der Organisationseinheit (einschließlich aller geschachtelten Organisationseinheiten), dann auf der Ebene der Domäne, und schließlich auf der Ebene des Active Directory-Standorts.Aus den Ergebnissen dieser Suche erstellt der Client eine Liste von GPOs, die für die Verarbeitung bewertet werden müssen.
4. Dann wird jedes GPO in Active Directory gesucht, um zu bestimmen, ob der Client (Benutzer oder Computer) die erforderlichen Berechtigungen für dessen Verarbeitung hat.Ebenfalls bewertet werden die Versionsnummer, der Pfad zur Gruppenrichtlinienvorlage (Group Policy Template, GPT), der Anteil des GPOs in SYSVOL, sowie die Frage, welche CSEs in diesem GPO implementiert sind.
5. Der Client verwendet dann das SMB-Protokoll (Server Message Block), um den Inhalt der GPT zu lesen und die Versionsnummer des GPOs aus der gpt.ini-Datei abzurufen.Die Versionsnummern im Gruppenrichtliniencontainer (Group Policy Container, GPC) und die GPT sind ein Faktor, mit dessen Hilfe bestimmt wird, ob sich ein GPO seit dem letzten Verarbeitungszyklus geändert hat.
6. Jede CSE wird in der unter HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions registrierten Reihenfolge ausgeführt und verarbeitet die GPOs, die diese CSE implementieren, falls sich das GPO seit dem letzten Verarbeitungszyklus (wie bei der Kernverarbeitung bestimmt) geändert hat.Jede CSE protokolliert bei jeder Aktualisierung, wenn verfügbar, auch die Daten des Richtlinienergebnissatzes (Resultant Set of User Policy, RSOP) zur Windows-Verwaltungsinstrumentation (Windows Management Instrumentation, WMI).

Durch Analysieren dieses Prozesses soll festgestellt werden, wie sich dies auf die Leistung auswirken kann.Als Erstes ist festzustellen, dass es einen Unterschied zwischen Vordergrund- und Hintergrundverarbeitung gibt.Vordergrundverarbeitung findet für Computer während eines Systemneustarts und für Benutzer während einer Benutzeranmeldung statt.Hintergrundaktualisierungen finden auf Arbeitsstationen und Mitgliedsservern standardmäßig alle 90 Minuten plus bis zu 30 Minuten nach einem Zufallswert statt.Hintergrundaktualisierungen finden auf Domänencontrollern standardmäßig alle 5 Minuten statt.In Windows Vista gibt es dazu auf NLA basierende Aktualisierungen, die im Wesentlichen Hintergrundaktualisierungsereignisse sind, ausgelöst durch einen vorausgegangenen Fehler bei der Gruppenrichtlinienverarbeitung wegen fehlenden Zugriffs auf einen Domänencontroller (als ob der Client während einer Hintergrundaktualisierung offline war).Weshalb sind diese Unterschiede wichtig?Hauptsächlich, weil bestimmte CSEs (zum Beispiel die CSEs für Softwareinstallation und Ordnerumleitung) während einer Hintergrundaktualisierung nicht ausgeführt werden.Ebenso werden Skripts zum Anmelden/Abmelden oder Starten/Herunterfahren während einer Hintergrundaktualisierung nicht ausgeführt.

Gleichermaßen wurde in Schritt 1 dieses Prozesses der Prozess zur Erkennung langsamer Verbindungen erwähnt.In Systemen, die älter als Windows Vista sind, stützt sich dieser Prozess auf Clients, die ICMP zum Senden einer Pinganforderung an den Domänencontroller verwenden, um dessen Verfügbarkeit und Verbindungsgeschwindigkeit zu bestimmen.Wenn die berechnete Verbindungsgeschwindigkeit unter einen bestimmten Schwellenwert fällt (Standardwert: 500 Kb/s), wird die Verbindung als langsam betrachtet, und wieder werden bestimmte CSEs, z. B. Softwareinstallation, Ordnerumleitung und Internet Explorer-Wartung, nicht ausgeführt.Alle diese Bedingungen können Auswirkungen auf die Leistung wie auch auf die erwartete Bereitstellung der Richtlinie haben.

Die größten Auswirkungen auf die Leistung bei allen Aspekten des Richtlinienverarbeitungszyklus hat wahrscheinlich die Logik, die ermittelt, ob sich für einen Computer oder Benutzer geltende GPOs geändert haben.Das Gruppenrichtlinienmodul verfügt über eine integrierte Optimierung, die besagt, dass keine Verarbeitung stattfindet, falls sich seit der letzten Verarbeitung nichts für einen Computer oder Benutzer geändert hat.Dies kann natürlich enorme Auswirkungen auf die Zeit haben, die Ihre Clients zur Verarbeitung der Richtlinie benötigen, besonders wenn Ihre Gruppenrichtlinienumgebung relativ statisch ist.Im Folgenden soll näher betrachtet werden, worin eine Änderung besteht.

Änderungen der Gruppenrichtlinie

Worin also besteht eine Änderung der Gruppenrichtlinienverarbeitung?Es gibt eine Anzahl von Faktoren, aber der offensichtlichste besteht darin, dass Clients bei einer Änderung an einem GPO die Änderung erkennen und das GPO erneut verarbeiten.Woher weiß ein Client, dass sich ein GPO geändert hat?Der Client verwendet Versionsnummern auf dem GPO und innerhalb des Clients, um dies herauszufinden.

Ein GPO besteht aus zwei Teilen: dem GPC, der in Active Directory unter dem CN=Richtlinien, CN=Systemcontainer innerhalb jeder Domäne gespeichert wird, und der GPT, die in SYSVOL unter dem Ordner „Richtlinien“ gespeichert wird.Jedes Teil des GPOs enthält eine Versionsnummer.Für den GPC ist diese Versionsnummer im Attribut „versionNumber“ auf dem GPC-Objekt gespeichert.Für die GPT ist es innerhalb der gpt.ini-Datei im Stamm einer jeweiligen GPT gespeichert.Der Client speichert in seiner Registrierung ebenfalls einen Datensatz der Versionsnummern der von ihm verarbeiteten GPOs (sowohl pro Computer als auch pro Benutzer).Diese Versionsinformationen sind auf jedem Client für den Computer unter HKLM\Software\Microsoft\Windows\Currentversion\Group Policy\History for the computer and HKLM\Software\Microsoft\Windows\Currentversion\Group Policy\<SID of User> gespeichert.

Wenn eine Gruppenrichtlinienverarbeitung stattfindet, werden u. a. die Versionsnummern aller GPOs untersucht, die für den Computer oder den Benutzer gelten, und mit allen in der Registrierung vorhandenen Versionsnummern verglichen, die während des letzten Zyklus verarbeitet wurden.Wenn aktuelle GPOs abweichende Versionsnummern aufweisen (beachten Sie, dass sie nur voneinander abweichen müssen – sie können höher oder auch niedriger sein!), werden diese GPOs während des aktuellen Verarbeitungszyklus verarbeitet.Falls nicht, werden sie nicht verarbeitet, sofern nicht eine der anderen Änderungsbedingungen erfüllt ist.Die anderen Änderungsbedingungen sind Folgende:

• Eine Änderung in der Liste der für einen Benutzer oder Computer geltenden GPOs (ein GPO wurde hinzugefügt oder entfernt)
• Eine Änderung in der Sicherheitsgruppenmitgliedschaft eines Benutzers oder Computers
• Eine Änderung in einem mit einem GPO verknüpften WMI-Filter (ein WMI-Filter wurde hinzugefügt oder entfernt)

Wenn eine dieser Änderungsbedingungen erfüllt ist, verarbeitet der Client die Richtlinie während dieses Zyklus erneut.Es gibt in diesem Prozess jedoch Feinheiten, derer Sie sich bewusst sein müssen, da sich diese erhebliche auf die Leistung auswirken können.Wenn sich bei einer bestimmten CSE eines von zehn GPOs ändert, müssen für diese CSE alle GPOs verarbeitet werden.Bedenken Sie, dass die Verarbeitung individuell für die einzelnen CSEs erfolgt.CSEs müssen jedoch die Richtlinie in der Rangfolge verarbeiten, die die Verarbeitung steuert (zuerst lokale GPOs, dann standortverknüpfte GPOs, dann domänenverknüpfte GPOs, schließlich OU-verknüpfte GPOs).Ein Beispiel zur Erläuterung dieser Anforderung: Angenommen auf einen Benutzer treffen zehn GPOs zu, von denen jedes auf unterschiedlichen Ebenen der Active Directory-Hierarchie verknüpft ist.Außerdem wird angenommen, dass jedes dieser zehn GPOs Richtlinieneinstellungen für administrative Vorlagen implementiert.Nun ändert ein Administrator ein GPO, das mit der Domäne verknüpft ist, indem er eine neue Richtlinieneinstellung für administrative Vorlagen hinzufügt.Dann beginnt der Computer oder der Benutzer mit der Verarbeitung der Richtlinie und stellt fest, dass die Versionsnummer dieses geänderten GPOs höher ist als bei der letzten Verarbeitung: also muss das GPO erneut verarbeitet werden.Um jedoch die Rangfolge der Gruppenrichtlinienverarbeitung beizubehalten, müssen alle Einstellung für administrative Vorlagen verarbeitet werden, die für alle GPOs gelten.Daher kann eine einfache Änderung an einem GPO möglicherweise erhebliche Auswirkungen auf die Leistung dieses Clients haben.

Leistungsvergleich zwischen monolithischen und funktionalen GPOs

Nach dieser Betrachtung des Verarbeitungszyklus sowie der Art und Weise, wie sich Änderungen an der Gruppenrichtlinienumgebung auf die Verarbeitung auswirken, will ich zur Erörterung monolithischer und funktionaler GPOs zurückkehren und untersuchen, wie sich der jeweilige Ansatz auf die Leistung auswirkt.

Monolithische GPOs können aufgrund der Art und Weise, wie die Versionsverwaltung von Gruppenrichtlinien funktioniert, einen versteckten Leistungsabfall aufweisen.Die Gründe hierfür sind nicht ganz offensichtlich, aber sie hängen damit zusammen, dass es innerhalb der Gruppenrichtlinienverarbeitung kein Konzept der Versionsverwaltung für einzelne CSEs gibt.Angenommen ein Benutzer verfügt über drei für ihn geltende GPOs.Alle GPOs sind monolithisch, da sie mehrere Richtlinienbereiche implementieren.Beispielsweise implementieren diese GPOs jeweils die Richtlinie für administrative Vorlagen, die Richtlinie für Softwareinstallation und die Richtlinie für Ordnerumleitung.Jetzt nimmt ein Administrator eine Änderung an der Richtlinie für administrative Vorlagen in einem dieser GPOs vor.Durch diese Änderung erhöht sich die Versionsnummer.Der Benutzer verarbeitet anschließend die Gruppenrichtlinie.Die CSE für administrative Vorlagen startet und stellt fest, dass sich eines der GPOs geändert hat, also verarbeitet sie alle drei GPOs erneut.

Wenn die CSEs für Softwareinstallation und Ordnerumleitung ausgeführt werden, prüfen auch sie die GPO-Versionsnummern und stellen die neue Versionsnummer auf einem der GPOs fest.Da aber die Versionsnummer nichts darüber aussagt, welcher Richtlinienbereich in diesem GPO geändert wurde, werden für alle Fälle alle drei GPOs erneut verarbeitet.Somit können bei der Implementierung eines monolithischen GPO Änderungen an einem Bereich der Richtlinie zu Verarbeitungsaktivität in einem anderen Bereich führen.

Im Fall der Richtlinie für Softwareinstallation oder Ordnerumleitung führen diese CSEs zwar möglicherweise überhaupt keine Arbeit durch, da beispielsweise eine bereits installierte Anwendung nicht erneut installiert wird.Das Entscheidende aber ist, dass dieses Verhalten mit jeder CSE auftreten kann und beim Entwurf monolithischer GPOs berücksichtigt werden muss.Wenn sich einer Ihrer Richtlinienbereiche oft ändert, könnten Sie in Betracht ziehen, die GPOs, die diesen Richtlinienbereich implementieren, von anderen Richtlinienbereichen getrennt zu halten.

Bei funktionalen GPOs sind die Leistungsüberlegungen ersichtlicher.Wenn mehr GPOs pro Benutzer oder Computer vorliegen (weil der funktionale Ansatz in der Regel mehr GPOs für einen bestimmten Satz von Richtlinieneinstellungen bedeutet), muss das Gruppenrichtlinienmodul folglich mehr Zeit aufwenden, um diese GPOs während der Kernphase der Gruppenrichtlinienverarbeitung aufzulisten.Wie jedoch im nächsten Abschnitt erläutert wird, wirkt sich dies nicht unbedingt wesentlich auf die Leistung aus.

Leistungsmessung für Gruppenrichtlinien

Um letztendlich die richtigen Entscheidungen über die Leistung Ihrer Gruppenrichtlinieninfrastruktur zu treffen, müssen Sie messen können, wie Gruppenrichtlinien in Ihrer realen Umgebung funktionieren.Die Leistung von Gruppenrichtlinien zu modellieren oder vorherzusagen, ist beinahe unmöglich angesichts der Vielzahl von Faktoren, die sich auf einen bestimmten Verarbeitungszyklus auswirken können.Aus diesem Grund sollte möglichst mit einer empirischen Messung festgestellt werden, ob die Leistung der Gruppenrichtlinienverarbeitung problematisch ist.Was macht eine schlechte Leistung aus?Nun, eine schlechte Leistung ist jede Situation, in der sich die Gruppenrichtlinienverarbeitung auf die Benutzerfreundlichkeit auf den Systemen Ihrer Benutzer auswirkt.Dies kann für jede Organisation unterschiedlich sein, die Hauptsache aber ist das Wissen, dass ein Problem vorliegt.

Wie können Sie aber die Dauer eines bestimmten Gruppenrichtlinienverarbeitungszyklus messen?Auch diese Antwort ist nicht einfach.Wenn Sie Windows Vista oder Windows Server 2008 ausführen, können Sie die neuen Betriebsprotokolle in der Ereignisanzeige nutzen.Das Betriebsprotokoll für Gruppenrichtlinien innerhalb der Ereignisanzeige, zu finden unter „Anwendungs- und Dienstprotokolle\Microsoft\Windows\Gruppenrichtlinie\Betriebsbereit“, stellt eine ausgezeichnete Instrumentation aller Schritte des Gruppenrichtlinienverarbeitungszyklus bereit, einschließlich der während jeder Verarbeitungsphase beanspruchten Zeit (siehe Abbildung 2).

Abbildung 2** Das Ereignis im Betriebsprotokoll für Gruppenrichtlinien, das die Richtlinienverarbeitungszeit anzeigt **(Klicken Sie zum Vergrößern auf das Bild)

Wenn Sie allerdings nicht in einer Windows Vista- oder Windows Server 2008-Umgebung arbeiten, sind die Methoden zur Messung der Richtlinienverarbeitungszeiten weniger direkt.In diesem Fall müssen Sie entweder die ausführliche userenv-Protokollierung aktivieren (siehe Microsoft-Supportartikel unter support.microsoft.com/kb/221833) und für einen bestimmten Verarbeitungszyklus die Zeitstempel innerhalb dieser Datei anzeigen, oder Sie müssen die in der Registrierung auf dem Client gespeicherten Werte verwenden, die die Start- und Endzeit für die Richtlinienverarbeitung anzeigen.Diese Werte sind nachfolgend für den Computer

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
Group Policy\State\Machine\Extension-List\
{00000000-0000-0000-0000-000000000000}

und hier für den Benutzer gespeichert:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
Group Policy\State\<SID of User>\Extension-List\
{00000000-0000-0000-0000-000000000000}

Die Werte sind im FILETIME-Format gespeichert und müssen in eine normale Datums- und Zeitangabe umgewandelt werden.Sie können zum Abrufen derselben Informationen auch das kostenlose von mir geschriebene GPTime.exe-Dienstprogramm verwenden (verfügbar unter gpoguy.com/tools.htm#GP_Time_Utility).

Wenn Sie keine Windows Vista- oder Windows Server 2008-Umgebung, aber Zugriff auf ein userenv-Protokoll haben, können Sie trotzdem wertvolle Informationen darüber abrufen, wie viel Zeit in jedem Richtlinienverarbeitungszyklus beansprucht wurde.So zeigt zum Beispiel Abbildung 3 einen Ausschnitt des userenv-Protokolls, in dem ein Teil der Kernphase der Gruppenrichtlinienverarbeitung zu sehen ist.

Abbildung 3** Ein Teil des userenv-Protokolls **(Klicken Sie zum Vergrößern auf das Bild)

Beachten Sie, dass jede Zeile der Protokolldatei einen Zeitstempel enthält.Der zentrale Teil des Gruppenrichtlinienverarbeitungszyklus beginnt, wenn Sie ein Ereignis sehen, das ungefähr Folgendes besagt: „ProcessGPOs:Starting user Group Policy (Background) processing ...“Der CSE-Teil des Verarbeitungszyklus beginnt, wenn Sie die Zeile „ProcessGPOs:Processing extension Registry“ sehen.Mithilfe dieses Protokolls und der darin enthaltenen Zeitstempel können Sie ermitteln, wie lange jeder Teil eines Richtlinienzyklus dauert.

Allgemeine Beobachtungen hinsichtlich der Leistung

Wenn Sie sich eine Weile mit den userenv-Protokolldateien beschäftigen, erkennen Sie schließlich Muster, und obwohl sich nicht vorhersagen lässt, wie lange die Richtlinienverarbeitung dauern wird, können Sie bereits allgemeine Beobachtungen darüber anstellen, wo in einem bestimmten Verarbeitungszyklus Zeit beansprucht wird.Wenn zum Beispiel während eines Richtlinienverarbeitungsereignisses Richtlinienänderungen verarbeitet werden und CSEs wegen einer Änderung tätig werden müssen, so wird im zentralen Teil der Gruppenrichtlinienverarbeitung in der Regel vergleichsweise viel weniger Zeit beansprucht als im CSE-Teil.

Dies trifft für die meisten Richtlinienbereiche zu, da die meisten CSEs Aufgaben ausführen müssen, die länger dauern als der zentrale Teil ihrer Verarbeitung, deren aufwändigste Vorgänge die Abfragen von Active Directory und SYSVOL sind.Zum Beispiel gibt es keinen Vergleich zwischen der Zeit, die bei der Kernverarbeitung beansprucht wird, und der Zeit, die beansprucht wird, wenn die CSE für Softwareinstallation Microsoft® Office installiert.Für die normale Hintergrundaktualisierung einer Richtlinie jedoch, bei der sich seit dem letzten Zyklus nichts geändert hat, beansprucht der zentrale Teil des Verarbeitungszyklus ungefähr gleich viel Zeit wie der CSE-Teil.Die Ausnahme hierzu ist die Registrierungsrichtlinienverarbeitung: Diese erfolgt tatsächlich ziemlich schnell, es sei denn, es liegen für einen bestimmten Benutzer oder Computer Dutzende oder Hunderte von Registrierungsrichtlinieneinstellungen vor.

Darüber hinaus hat es auf die Leistung der Richtlinienverarbeitung wenig Einfluss, wenn Sie die Computer- oder Benutzerseite eines GPOs deaktivieren, weil es nicht verwendet wird.Wenn eine Richtlinienseite nicht verwendet wird, besteht der einzige Aufwand darin, diese Tatsache bei der Abfrage von Active Directory zu ermitteln, und die gleiche Abfrage muss durchgeführt werden, um die Option zum Deaktivieren anzuzeigen, um zu ermitteln, ob eine CSE für diese Seite des GPOs implementiert wurde.Die Auswirkungen der Deaktivierung einer Seite sind unbedeutend.

Entwurfsempfehlungen für eine optimale Leistung von Gruppenrichtlinien

Nach dieser eingehenden Betrachtung einer Reihe von Leistungsaspekten der Gruppenrichtlinienverarbeitung sollten Sie sich nun mit einigen Entwurfsempfehlungen vertraut machen, die sich direkt auf die Leistung auswirken können.Diese lassen sich in vier Hauptpunkten zusammenfassen.

1. Wenn Sie an Ihren GPOs häufige Änderungen vornehmen, bedenken Sie den oben erwähnten Effekt, dass sich eine Änderung an einer einzigen CSE auf die Verarbeitung aller CSEs auswirken kann.Wenn Sie also planen, häufige Änderungen beispielsweise an der Registrierungsrichtlinie vorzunehmen, ist es sinnvoller, die Registrierungsrichtlinie in funktionale GPOs (GPOs nur für Registrierungsrichtlinien) zu stellen, da hierdurch andere CSEs von der Verarbeitung abgetrennt werden, wenn Änderungen stattfinden.
2. Bei der Frage, wie viele GPOs zu viele sind, bedenken Sie, dass Richtlinienverarbeitung nur bei Änderungen stattfindet, und dass „aufwändige“ CSEs wie Softwareinstallation, Ordnerumleitung oder die Behandlung einer großen Anzahl von Registrierungsrichtlinien oder Einstellungsberechtigungen auf großen Datei- oder Registrierungsstrukturen die meiste Zeit beanspruchen.Die Zeit für das Abfragen von Active Directory nach der GPO-Liste während der Kernverarbeitung ist oft der kleinste Teil des Verarbeitungszyklus.Daher beanspruchen 30 GPOs, die für einen bestimmten Benutzer gelten, aber nur minimale Änderungen an der Registrierungsrichtlinie vornehmen und sich nicht oft ändern, möglicherweise weniger Verarbeitungszeit als 5 GPOs, die regelmäßig aufwändige CSEs ausführen, da sich diese GPOs oft ändern.
3. Vermeiden Sie Verhaltensweisen, die bei der Leistung der Richtlinienverarbeitung offensichtliche Verlangsamungen erzwingen.Zum Beispiel können Sie eine Richtlinie so einstellen, dass CSEs zur Verarbeitung gezwungen werden, selbst wenn sich kein GPO geändert hat (unter Computerkonfiguration\Administrative Vorlagen\System\Gruppenrichtlinie).Dann müssen Sie sich jedoch darauf einstellen, dass die Richtlinienverarbeitung bei jedem Zyklus länger dauert.
4. Bedenken Sie die Vor- und Nachteile einer Deaktivierung von Fast Logon Optimization in Windows XP und Windows Vista (dies erfolgt durch Aktivierung der Richtlinie unter Computerkonfiguration\Administrative Vorlagen\System\Anmeldung\Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten).Wenn diese Richtlinie aktiviert ist, schaltet die Vordergrundverarbeitung von asynchron auf synchron um.Dies bedeutet, dass Computer- und Benutzerrichtlinie bis zum Abschluss ausgeführt werden müssen, bevor der Benutzer die Kontrolle über Computer und Desktop erhält.Dies kann auch von Vorteil sein, weil dadurch das Problem umgangen wird, dass zwei oder mehr Neustarts oder Anmeldungen erforderlich sind, damit Softwareinstallations- und Ordnerumleitungsrichtlinien wirksam werden.

Schlussbemerkung

Die Leistung bei der Verarbeitung von Gruppenrichtlinien ist zwar keine exakte Wissenschaft, Sie können sich aber einen gewissen Einblick verschaffen, der bei Berücksichtigung im Entwurfsprozess zur Verringerung von Leistungsproblemen beiträgt.

Wenn Sie erst einmal verstehen, wie der Verarbeitungszyklus funktioniert und an welcher Stelle Zeit beansprucht wird, sind Sie beim Aufspüren von Leistungsproblemen schon ein gutes Stück weiter gekommen.Verwenden Sie die Windows Vista- oder Windows Server 2008-Betriebsprotokolle (oder userenv-Protokolle in früheren Versionen von Windows), um instrumentierte Informationen über den Verarbeitungszyklus zu erhalten.Beachten Sie die Unberechenbarkeiten der CSE-Verarbeitung und das, was aus der Perspektive einer CSE eine Änderung an einer Richtlinie ausmacht.Vergessen Sie auch nicht, dass in dynamischen Umgebungen mit vielen Änderungen funktionale GPOs möglicherweise sinnvoller sind als monolithische.Im Endeffekt aber sind Gruppenrichtlinien eine Technologie, die darauf ausgerichtet ist, Ihnen bei der besseren Verwaltung Ihrer Windows-Umgebung zu helfen.Es ist sehr wichtig, dass der Gruppenrichtlinienentwurf von Ihren Unternehmensanforderungen bestimmt wird, nicht umgekehrt.Die Berücksichtigung einiger der hier erläuterten Leistungsverhaltensweisen tragen dazu bei, dieses Ziel zu erreichen.

Darren Mar-Eliaist 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.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.