Teil 1 behandelte vor allem logische Fehler im Umgang mit Gruppenrichtlinien.
Teil 2 befasste sich mit technischen Fehlern und Tools mit denen die Abarbeitung von Richtlinien überprüft werden kann.
Der letzte Teil des GPO Troubleshooting Guides behandelt das Thema "GPO Performance."
Inhalt:
- Welche Timeouts können beim Abarbeiten von Policies auftreten?
- Wie lassen sich erhöhte Laufzeiten von Policies erkennen?
- Welche CSEs können erhöhte Laufzeiten verursachen?
- Wie wirkt sich das Policy- und AD Design auf die Laufzeit der GPOs aus?
- Wie wirkt sich Group Policy Loopback auf die Laufzeit der GPOs aus?
- Wie wirkt sich die Anzahl der GPOs auf die Laufzeit aus?
Welche Timeouts können auftreten?
Im Laufe der Gruppenrichtlinienabarbeitung können verschiedene Timeouts auftreten. Da insbesondere bei der synchronen Richtlinienanwendung unendliche Start- und Anmeldezeiten verursacht werden könnten, sind diese Timeouts als Sicherheitsmechanismus anzusehen.
Der 60 Minuten Timeout:
Diese maximale Zeitspanne lässt sich nicht konfigurieren. Es handelt sich um einen hartcodierten Wert von genau 60 Minuten. Ist eine Client Side Extension nach dieser Zeitspanne mit der Anwendung der Einstellungen nicht fertig, so wechselt die GPO-Engine in den asynchronen Modus. Dies bedeutet nichts anderes, als dass der Start- bzw. Anmeldeprozess fortgeführt wird.
Die restlichen Richtlinien werden (wenn möglich) im Hintergrund abgearbeitet.
Die betreffende CSE wird jedoch nicht beendet, sondern läuft ebenfalls im Hintergrund weiter. 60 Minuten ist ein größzügig bemessener Timeout.
Eine CSE die definitiv in diesen Timeout laufen kann, ist die "Software Installation" CSE. Dauert eine Softwareinstallation länger als 60 Minuten, so tritt dieses Verhalten ein.
Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten:
Diese Richtlinie kennen wir bereits aus Teil 2.
Die Beschreibung der Richtlinie lässt vermuten, dass so lange auf das Netzwerk gewartet wird, bis dieses verfügbar ist. Dem ist jedoch nicht so.
Es gilt ein Standard Timeout von 30 Sekunden. Dieser kann mit dieser Richtlinie allerdings geändert werden:
"Wartezeit für Richtlinienverarbeitung beim Systemstart angeben"
Es kann zusätzlich noch eine separate Policy konfiguriert werden, die die maximale Wartezeit für DirectAccess Verbindungen definiert. Hier ist der Default 60 Sekunden. Leider ist der Name der Policy missverständlich.
"Wartezeit der Arbeitsbereichskonnektivität für Richtlinienverarbeitung angeben"
Maximale Wartezeit für Gruppenrichtlinienskripts angeben:
Dieser Timeout definiert die maximale Ausführungszeit der Skripte beim Starten, Anmelden, Abmelden und Herunterahren des Computers.
Der Standardwert liegt bei 10 Minuten.
Definiert man eine Wartezeit von 0 Sekunden, so bedeutet dies, unendlich.
Zu beachten ist jedoch, dass die Skripte von keiner CSE ausgeführt werden.
Das bedeutet, der Standard CSE Timeout von 60 Minuten gilt hier nicht.
"Maximale Wartezeit für Gruppenrichtlinienskripts angeben"
Gruppenrichtlinien zur Erkennung von langsamen Verbindungen
Hierbei handelt sich nicht um einen zeitlichen Timeout, sondern vielmehr um eine Bandbreitenmessung. Wird eine langsame Netzwerkverbindung erkannt, so werden Teile der Gruppenrichtlinien nicht angewendet.
Hierbei handelt es sich um alle Client Side Extensions bei denen der Registrywert "NoSlowLink" auf 0x1 gesetzt wurde.
Dieser Schlüssel befindet sich unter "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions" unterhalb des GUID der jeweiligen CSE.
Dies ist das Standardverhalten (Quelle TechNet):
Richtlinien, die standardmäßig angewendet werden:
- Registrierungseinstellungen (aus administrativen Vorlagen) müssen immer angewendet werden – dies kann nicht geändert werden
- Sicherheitsrichtlinien müssen immer angewendet werden - dies kann nicht geändert werden)
- EFS-Wiederherstellungsrichtlinie
- IP-Sicherheit
Richtlinien, die nicht angewendet werden:
- Anwendungsbereitstellung
- Skripts
- Ordnerumleitung
- Datenträgerkontingente
Alle Verbindungen bei denen eine Bandbreite von weniger 500 KBit/s erkannt wird, gelten standardmäßig als "langsame Verbindung".
Beeinflusst kann dieser Wert mit dieser Policy werden:
"Gruppenrichtlinien zur Erkennung von langsamen Verbindungen"
Der WMI-Filter Timeout:
Richtlinien können mit WMI Filtern verknüpft werden.
Über die GPO-Performance im Zusammenhang mit WMI-Filtern habe ich bereits in meinem Post "The lies of GPOs! #4" berichtet.
Noch vor Windows Vista (bzw. Server 2008) konnte ein WMI-Filter theoretisch unendlich lange ausgeführt werden. Dies hat man nun mit einem WMI-Timeout unterbunden. Dieser Timeout ist 30 Sekunden und kann nicht geändert werden.
Dauert die Ausführung eines WMI-Filters länger als 30 Sekunden, so wird das Ergebnis mit "false" beantwortet.
Zwischenzeitlich findet man nun auch auch eine offizielle Erwähnung dieses Timeouts. Den Link hierzu findet ihr hier.
GPP - nicht verfügbare Netzlaufwerke:
Versucht man ein nicht verfügbares Netzlaufwerk mit der Client Side Extension "Drive Maps" zu verbinden, so tritt auch hier ein Timeout auf.
Dieser liegt ebenfalls bei 30 Sekunden und kann nicht geändert werden.
Möchte man diesen Timeout jedoch umgehen, so kann man Martin Binder's Workaround benutzen.
Mehr dazu findet ihr in seinem Blog-Post über dieses Thema:
http://evilgpo.blogspot.de/2013/01/group-policy-preferences.html
Der TCP Standard Timeout
Abschließend sei noch ein Timeout erwähnt, der theoretisch bei unterschiedlichen Sektionen der Gruppenrichtlinienanwendung auftreten kann.
Es handelt sich um den Standard Timeout für TCP/IP Verbindungen.
Dieser Timeout wird von zwei Registryschlüsseln kontrolliert.
Der Schlüssel "TCPInitialRtt" gibt den anfänglichen Timeout an.
Der Schlüssel "TcpMaxDataRetransmissions" gibt dann die Anzahl der Wiederholversuche an. Mit jedem Wiederholversuch wird der Timeout "TCPInitialRtt" dann verdoppelt.
Dieser Timeout ist leider schwer zu erkennen.
Es sollten größere Zeitsprünge im gpsvc.log erkennen zu sein.
Mehr zum Anpassen dieses Timeouts findet ihr hier: http://support.microsoft.com/kb/170359/en-us
Wie lassen sich erhöhte Laufzeiten von Policies erkennen?
Im Eventlog:
Ab Windows Vista lassen sich die Laufzeiten der jeweiligen Client Side Extensions komfortabel im Eventlog ablesen.
Interessieren euch die Laufzeiten der einzelnen Erweiterungen, dann solltet ihr nach Event-ID 5016 suchen.
800x Events zeigen euch die Gesamtlaufzeit der GPO Anwendung.
Dauert die Abarbeitung der jeweiligen CSE ungewöhnlich lange, so wird ein Fehler im Eventlog vermerkt. Die Event-ID ist dann in der Regel die 7016.
Im gpsvc.log:
Das Logfile des Gruppenrichtlinien-Clients muss zunächst aktiviert werden.
Das Logfile lässt sich am komfortabelsten mit dem Policy Reporter auswerten.
Zu beachten ist jedoch, dass nicht alle Ausführungszeiten im Logfile erscheinen.
Die Laufzeiten der Skripte wird zum Beispiel nicht im Logfile erfasst.
In der GPMC und im gpresult /h von Windows 8 und Server 2012:
Über die Funktion "Gruppenrichtlinienergebnisse" können die Laufzeiten der jeweiligen CSEs angezeigt werden.
Mit Hilfe von GPTime.exe
Das Tool GPTime.exe liest die Gesamtlaufzeit der Benutzer- und Computerkonfiguration aus den jeweiligen Registrywerten und konvertiert diese in eine lesbare Zeitangabe.
Welche CSEs können erhöhte Laufzeiten verursachen?
Die Anwendung der Richtlinien besteht aus zwei Anteilen:
Dem "Core Processing":
Hierbei wird bestimmt, welche Richtlinien angewendet werden müssen.
Es werden die Sicherheits- und WMI Filter durchlaufen.
Zudem wird ermittelt welche CSEs registriert sind und welche CSEs aufgerufen werden müssen.
Dem "CSE Processing":
Hierbei werden die eigentlichen Einstellungen angewendet.
Jede zutreffende CSE wird nach ihrer registrierten Reihenfolge ausgeführt
und arbeit die Einstellungen ab.
Die jeweils benötigte Zeitdauer dieser beiden Anteile kann variieren.
Bei asynchroner Richtlinenverarbeitung gilt:
Bei einem nicht erzwungenen GPO Refresh (z.B. gpupdate) nimmt das Core Processing in der Regel mehr Zeit in Anspruch als das CSE Processing.
Erzwingt man jedoch einen vollständigen Refresh (z.B. gpupdate /force),
so müssen alle Einstellungen erneut angewendet werden.
Hierbei nimmt das CSE Processing in der Regel mehr Zeit in Anspruch.
Bei synchroner Richtlinenverarbeitung gilt:
Da in diesem Falle auf das Netzwerk gewartet wird, kann das Core Processing mehr Zeit benötigen. Wie lange das CSE Processing dauert, hängt in erster Linie von den Einstellungen in den Richtlinen ab.
Typische Beispiele für zeitintensive Client Side Extensions:
- Software Installation CSE
Je nachdem wieviele und wie umfangreiche Installationen ausgeführt werden, kann diese CSE viel Zeit beanspruchen.
- Security CSE
Mit dieser CSE lassen sich unter anderem Datei- und Ordnerberechtigungen setzen. Werden Verzeichnisse mit vielen Dateien bearbeitet, so kann diese CSE sehr viel Zeit in Anspruch nehmen.
- Scripts CSE
Hier muss man unterscheiden. Die eigentliche CSE ist sehr schnell abgearbeitet. Hierbei werden nur die Einstellungen in die Registry geschrieben. Die Skripte laufen dann unabhängig von der Richtlinenanwendung beim Starten, Anmelden, Abmelden und Herunterfahren. Sind hier zeitintensive Skripte hinterlegt, so kann auch hier eine hohe Ausführungszeit entstehen.
Der Sonderfall Group Policy Preferences Item Level Targeting:
GPPs (Group Policy Preferences) bieten einem die Möglichkeit eine sogenannte Zielgruppenadressierung (Item Level Targeting) zu verwenden. Mehr dazu auch im Abschnitt "Item Level Targeting - jetzt wird es granular" im Teil 1 des Guides.
Der Sonderfall hierbei ist, dass das Filtern innerhalb des CSE Processings stattfindet. Hier können ebenfalls zeitintensive Filter hinterlegt sein.
Zielgruppenadressierungen die viel Zeit in Anspruch nehmen können:
- Sicherheitsgruppenziele
Auf Computerebene kann diese viel Zeit beanspruchen.
Auf Benutzerebene wird dies lokal ausgeführt und benötigt nur wenig Zeit.
- LDAP-Abfrage
- Domäne
- Siteziele
- Organisationseinheit
Tipp:
Eine Liste der Zielgruppenadressierungen findet ihr hier.
Mehr zum Thema ITLs die viel Zeit in Anspruch nehmen können findet ihr hier.
Wie wirkt sich das Policy- und AD Design auf die Laufzeit der GPOs aus?
Bei dem Thema möchte ich vor allem auf MVP Darren Mar-Elia's exzellenten Beitrag hinweisen.
Er unterteilt Richtlinien in zwei Kategorien.
"Monolithic and Functional GPOs".
"Monolithic GPOs":
Enthalten Einstellungen aus verschiedenen Gruppenrichtlinienbereichen (z.B. administrative Vorlagen, Sicherheitseinstellungen, Software Installationen).
Da die Versionierung nur pro Computerkonfiguration und Benutzerkonfiguration besteht, so müssen im Zweifelsfalle bei einer Änderung alle Einstellungen erneut angewendet werden. Die Delegierung (Zugriffsrechte) an einzelne Administratoren gestaltet sich hier schwierig, da dies ebenfalls nur pro Richtlinie möglich ist.
Um ein einfaches Beispiel zu nennen:
In einem großen Unternehmen gibt es Administratoren die nur administrative Vorlagen verwalten. Verwendet man nun "Monolithic GPOs", so könnten diese Administratoren mit ihren Zugriffsrechten auch andere Richtlinien Einstellungen (z.B. Skripte) bearbeiten.
"Functional GPOs":
Enthalten Einstellungen aus speziellen Bereichen (z.B. nur administrative Vorlagen). Hierbei besteht das beschriebene Problem mit der Versionierung nicht. Jedoch führt dies unweigerlich zu einer großen Anzahl von Richtlinien. Diese Richtlinien können jedoch aufgrund ihrer Granularität besser an einzelne Administratoren delegiert werden.
Wie wirkt sich Group Policy Loopback auf die Laufzeit der GPOs aus?
Group Policy Loopback kann in zwei verschiedenen Modi ausgeführt werden,
Merge und Replace.
Loopback Merge:
Hierbei entstehen zwei GPO Durchläufe.
Der erste Durchlauf läuft wie gewohnt ab, die Benutzereinstellungen werden anhand der Position des Benutzerobjekts im Active Directory abgearbeitet. Ist dieser Prozess abgeschlossen, wird der Suchfilter geändert.
Nun startet ein zweiter Durchlauf, hierbei ist allerdings die Position des Computerobjekts im Active Directory entscheidend. Zum Verständnis noch einmal, es geht nur um die Anwendung der Benutzereinstellungen. Loopback Merge verdoppelt die Abarbeitungszeit der Richtlinien nahezu.
Loopback Replace:
Bei Replace ist nur noch die Position des Computerobjekts entscheidend. Es gibt nur einen Durchlauf. Loopback Replace hat praktisch keine Auswirkungen auf die Abarbeitungszeit der Richtlinien.
Wie wirkt sich die Anzahl der GPOs auf die Laufzeit aus?
Die Antwort ist kurz und knapp: Geringfügig.
Die Anzahl der Richtlinien ist kaum entscheidend. Die Ausführungszeit wird vielmehr von den Einstellungen der Policies und den Filtern, die mit den Policies verknüpft sind, beinflusst.
