Priorität Group Policy Objects vs. Group Policy Preferences

Hallo, Fabian hier. Mit zunehmender Verbreitung der Group Policy Preferences (GPP) stellen wir fest, daß die Frage nach der Priorität der Anwendung von GPP im Vergleich zu normalen Group Policy Objects (GPOs ) zunimmt. Leider auch bedingt durch die ein oder andere nicht ganz korrekte Dokumentation von uns aus der Anfangszeit, nachdem die GPP in unsere Produktpalette integriert wurden, hält sich hartnäckig das Gerücht, daß normale GPOs grundsätzlich Vorrang vor den Group Policy Preferences hätten. Dem ist jedoch nicht so.

An dieser Stelle nur ein kurzer, stark vereinfachter Ausflug in die Theorie der Gruppenrichtlinienverarbeitung: Wenn ein Client die für ihn oder den angemeldeten Benutzer eingesetzten Gruppenrichtlinien abarbeitet, gibt es im Grunde zwei Stufen - zuerst wird im Core Processing geprüft, welche Gruppenrichtlinien überhaupt wirken und ob die benötigten Zugriffsrechte / WMI-Filter etc. den Zugriff auf die Richtlinie ermöglichen. Hierbei werden auch die Daten ausgelesen, welche Komponenten in den Gruppenrichtlinien konfiguriert sind. Diese Komponenten sind zum Beispiel die Sicherheitseinstellungen, die administrativen Vorlagen, Softwareverteilung, Drahtlosverbindungseinstellungen etc. – und eben auch die GPP Komponenten. Für jede dieser Komponenten ist eine sogenannte Client Side Extension zuständig (CSE), die durch eine *.dll realisiert ist.

Nun treten wir mit der Abarbeitung der Gruppenrichtlinien in die zweite Phase ein: Nachdem wir durch das Core Processing wissen, welche Gruppenrichtlinien überhaupt greifen und welche Komponenten (Client Side Extensions) in den Richtlinien angesprochen werden, lesen wir die Richtlinieneinstellungen aus und bringen sie nacheinander zur Anwendung. Hierbei wird der sogenannte Richtlinienergebnissatz (Resultant Set of  Policy - RSOP) errechnet - d.h. jede Komponente wird die Ihr bekannten anzuwendenden Einstellungen prüfen und zusammenführen, um dann letztendlich die "gewinnenden" Einstellungen auf dem Client vorzunehmen. Hier kann sich jede CSE unterschiedlich verhalten - die administrativen Vorlagen etwa, die über die Registry-CSE angewendet werden, schreiben tatsächlich die Einstellungen jeder einzelnen angewendeten Policy nacheinander in die Registrierung. Hingegen wird bei mehreren Policies mit "restricted groups" nur die Policy mit der höchsten Priorität angewendet werden, d.h. die CSE arbeitet "ersetzend", nicht "ergänzend".

Die Group Policy Preferences bringen eigene CSEs mit, daher sind sie komplett eigenständig und auch für die GPP CSEs wird also ein eigener RSOP errechnet. Es findet kein Abgleich mit den "alten" GPOs (bzw. GPO CSEs) statt.
Die auf einem Client vorhandenen CSEs kann man unter folgenden Registrierungsschlüssel überprüfen: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions

Siehe dazu auch 216357 Identifying Group Policy Client-Side Extensions https://support.microsoft.com/kb/216357/en-US.

Klickt man sich hier ein wenig durch, findet man unter den GUIDs auch die entsprechenden Namen der CSE und die dazugehörige *.dll.
Die CSEs werden nacheinander in alphabetischer Reihenfolge abgearbeitet, d.h. die GUID der jeweiligen CSE entscheidet, wann genau in Phase zwei, also dem CSE Processing, bei der Gruppenrichtlinienverarbeitung die Anwendung einer Einstellung auf dem Client erfolgt. Ausnahme ist hierbei die GPO Registrierungs-CSE, diese wird immer zuerst abgearbeitet, unabhängig von der alphabetischen Anordnung der GPO Registrierungs-CSE {35378EAC-683F-11D2-A89A-00C04FBBCFA2}. Ansonsten kann man die Abarbeitungsreihenfolge anhand der Anordnung im Registrierungseditor genau voraussehen.

Ok, zurück zur praktischen Bedeutung dieser grauen Theorie: Definiert man nun also unterschiedliche Einstellungen in unseren GPOs und zusätzlich auch diesen GPOs widersprechende Group Policy Preferences, gewinnt eben nicht unbedingt die GPO, nur weil man dieser GPO etwa eine höhere Priorität zugewiesen hat. Vielmehr entscheidet der Zeitpunkt der Abarbeitung jeder einzelnen CSE, welche Einstellung gewinnt.

Definiert man beispielsweise in den Sicherheitseinstellungen (Security Templates) eine Einstellung, die bei der Abarbeitung einen Registrierungsschlüssel schreibt, und definiert zusätzlich die Einstellung "manuell" über die Group Policy Preferences Registry Einstellungen mit einem entgegengesetzten Wert, wird die Group Policy Preference gewinnen - die CSE wird schlichtweg später abgearbeitet:

[...]
Security, scecli.dll: {827D319E-6EAC-11D2-A4EA-00C04F79F83A}
[...]
Group Policy Registry, gpprefcl.dll: {B087BE9D-ED37-454f-AF9C-04291E351182}

Die Abarbeitung kann man auch gut in einem UserEnv / GPSVC Debug Log nachvollziehen. Hier schaut man in in die Abarbeitung der Gruppenrichtlinien und stellt fest, daß wie oben beschreiben die Registry CSE zuerst abgearbeitet wird und danach die Reihenfolge der Abarbeitung genau mit der Reihenfolge der GUIDs / CSEs übereinstimmt, die man auch in der Registrierung gesehen hat:

[…]
GPSVC(218.ac8) 21:41:46:732 ProcessGPOs: -----------------------
GPSVC(218.ac8) 21:41:46:732 ProcessGPOs: Processing extension Registrierung GPSVC(218.ac8) 21:41:46:732 CompareGPOLists: The lists are the same.
GPSVC(218.67c) 21:41:46:733 ReadStatus: Read Extension's Previous status successfully.
GPSVC(218.ac8) 21:41:46:733 ProcessGPOs: Extension Registrierung skipped because both deleted and changed GPO lists are empty.
GPSVC(218.67c) 21:41:46:733 CompareGPOLists: The lists are the same.
GPSVC(218.ac8) 21:41:46:733 ProcessGPOs: -----------------------
GPSVC(218.67c) 21:41:46:733 CheckGPOs: No GPO changes and no security group membership change and extension Registrierung has NoGPOChanges set.
GPSVC(218.ac8) 21:41:46:733 ProcessGPOs: Processing extension Wireless Group Policy GPSVC(218.67c) 21:41:46:733 ProcessGPOs: -----------------------
GPSVC(218.ac8) 21:41:46:733 CompareGPOLists: The lists are the same.
GPSVC(218.67c) 21:41:46:734 ProcessGPOs: -----------------------
GPSVC(218.ac8) 21:41:46:734 CheckGPOs: No GPO changes but couldn't read extension Wireless Group Policy's status or policy time.
GPSVC(218.67c) 21:41:46:734 ProcessGPOs: Processing extension Wireless Group Policy
GPSVC(218.ac8) 21:41:46:734 ProcessGPOs: Extension Wireless Group Policy skipped with flags 0x210002.
GPSVC(218.67c) 21:41:46:734 CompareGPOLists: The lists are the same.
GPSVC(218.ac8) 21:41:46:734 ProcessGPOs: -----------------------
GPSVC(218.67c) 21:41:46:734 CheckGPOs: No GPO changes but couldn't read extension Wireless Group Policy's status or policy time.
GPSVC(218.ac8) 21:41:46:734 ProcessGPOs: Processing extension Group Policy Environment GPSVC(218.67c) 21:41:46:735 ProcessGPOs: Extension Wireless Group Policy skipped because both deleted and changed GPO lists are empty.
GPSVC(218.ac8) 21:41:46:735 CompareGPOLists: The lists are the same.
GPSVC(218.67c) 21:41:46:735 ProcessGPOs: -----------------------
[...]
GPSVC(218.ac8) 21:41:46:756 ProcessGPOs: -----------------------
GPSVC(218.67c) 21:41:46:756 ProcessGPOs: Processing extension Security GPSVC(218.ac8) 21:41:46:758 CompareGPOLists: The lists are the same.
GPSVC(218.ac8) 21:41:46:758 CheckGPOs: No GPO changes but couldn't read extension Windows Search Group Policy Extension's status or policy time.
GPSVC(218.67c) 21:41:46:758 CheckGPOs: No GPO changes but couldn't read extension Security's status or policy time.
GPSVC(218.ac8) 21:41:46:758 ProcessGPOs: Extension Windows Search Group Policy Extension skipped because both deleted and changed GPO lists are empty.
GPSVC(218.ac8) 21:41:46:759 ProcessGPOs: -----------------------
[…]

Die Abarbeitung der CSEs von GPO und GPP erfolgt dementsprechend "vermengt" / mixed.

In jedem Fall ist also zu empfehlen, Einstellungen nur an einer Stelle vorzunehmen und nicht gleiche Einstellungen in GPO und GPP mit verschiedenen Werten zu versehen - das kann eine Vorhersage der Einstellung, die am Ende wirklich greift, recht komplex machen und sorgt für Probleme, sollte man doch einmal ein Troubleshooting durchführen müssen. Wenn man jedoch herausfinden möchte, welche Einstellung greifen würde, muß man die Abarbeitungsreihenfolge der CSEs betrachten, nicht die Reihenfolge / Priorität der jeweiligen Gruppenrichtlinie, in der die GPO Einstellungen / Preferences definiert wurde. Das ist “by design” und auch so gewünscht.

Die genannten Punkte gelten natürlich nur für Einstellungen, die 1:1 an die gleichen Stellen (etwa in der Registrierung) geschrieben werden. Schreibt eine GPP etwa in den HKEY_CURRENT_USER\Software Zweig und nicht in den HKEY_CURRENT_USER\Software\Policies Zweig, wie die meisten von uns mitgelieferten GPO Einstellungen, kann sich das Verhalten wiederum unterscheiden. Die jeweils damit konfigurierte Applikation entscheidet dann, welcher Schlüssel Vorrang hat. Ein Grund mehr die Konstellationen simpel und vor allen Dingen eindeutig zu halten - denn hier nimmt der Komplexitätsgrad der möglichen Ergebnisse noch einmal stark zu.

Viele Grüße
Fabian