Active Directory (AD) basierte Gruppenrichtlinienobjekte (auf Englisch: Group Policy Object, kurz GPO) bestehen hauptsächlich aus zwei Komponenten, bestehend aus der logischen und physikalischen Struktur. Der logische Teil einer GPO wird in der AD-Datenbank (NTDS.dit) gespeichert und wird als Gruppenrichtliniencontainer (auf Englisch: Group Policy Container, kurz GPC) bezeichnet. Die physikalische Komponente einer GPO wird im Dateisystem, im replizierten Verzeichnis SYSVOL gespeichert und lautet Gruppenrichtlinienvorlage (auf Englisch: Group Policy Template, kurz GPT).

In den Eigenschaften eines GPC werden alle AD relevanten Konfigurationsdaten einer GPO gespeichert, wie beispielsweise der Pfad zur Gruppenrichtlinienvorlage (das Attribut gPCFileSysPath im entsprechenden GPC , also der Pfad zum GPT), der Status von Gruppenrichtlinienobjekten (das Attribut flags ) oder die Zugriffsteuerungsliste (Access Control List, kurz ACL) die bestimmt, welcher Benutzer bzw. Gruppe die Einstellungen eines GPOs verwalten darf. Den GPC selbst findet man in der Domänenpartition im Container CN=Policies,CN=System,DC=<Domäne> . Diesen Container kann man in der MMC Active Directory-Benutzer und –Computer (dsa.msc) zum Vorschein bringen. Dazu muss man jedoch zuerst in der MMC dsa.msc unter Ansicht die „Erweiterte Features“ aktivieren. Die GPC werden im AD-Container Policies mit ihrer {GUID} dargestellt und ist derselbe, wie er auch im GPT angezeigt wird.

Im GPT befinden sich die meisten Einstellungen eines GPOs sowie verschiedene Verzeichnisse und Konfigurationsdateien. Im GPT werden also alle aktuellen GPO-Einstellungen eines GPOs gespeichert. Die GPTs werden im Dateisystem tatsächlich unter %windir%\SYSVOL\domain\Policies , jeweils dargestellt mit ihrer {GUID} , gespeichert. Nicht zu verwechseln mit den Junction Points unter %windir%\SYSVOL\sysvol\<Domäne>\Policies . Tools für die Verwaltung von GPOs (z.B. die GPMC) verwenden die Junction Points und nicht den echten Speicherort der GPTs.

Wichtig für das Troubleshooting ist zu wissen, dass die hauptsächlichen Komponenten einer GPO, nämlich der GPC und das GPT, auf unterschiedliche Weise repliziert werden. Der GPC wird im Rahmen der AD-Replikation repliziert. Das GPT wird je nach Domänenfunktionsmodus entweder vom FRS (File Replication Service) oder vom DFS-R (Distributed File System Replication) repliziert. Liegen die Wurzeln einer Domäne im Domänenfunktionsmodus „Windows Server 2003“ oder niedriger, wird das GPT durch den FRS repliziert. Wurde die Domäne mindestens im Domänenfunktionsmodus „Windows Server 2008“ installiert, kommt DFS-R für die Replikation des GPT und somit des SYSVOLs zum Einsatz.

Die Performance bei der Abarbeitung von GPOs erhöhen

Für die Performance des Clients bei der Abarbeitung von GPOs (die auf ihn wirken) ist es empfehlenswert, den nicht konfigurierten Teil einer GPO stets zu deaktivieren. Das bedeutet, wenn in einer GPO lediglich Einstellungen im Benutzerkonfigurationsteil vorgenommen wurden, sollte der Computerkonfigurationsteil deaktiviert werden und vice versa.

Deaktivieren lässt sich ein Teil oder die gesamte GPO in der GPMC (Group Policy Management Console, zu Deutsch: Gruppenrichtlinienverwaltungskonsole). Mit einem Rechtsklick auf der entsprechenden GPO wählt man die Option Objektstatus aus und kann dann den gewünschten Teil oder die gesamte GPO deaktivieren. Das funktioniert auch wenn man die entsprechende GPO in der GPMC ausgewählt hat und danach zum Reiter Details wechselt.

Den Status der GPOs abfragen

Den Status einer GPO veranschaulicht das Attribut flags , das sich in den Eigenschaften jedes GPCs befindet.
Dabei kann das Attribut flags folgende Werte enthalten:

• Der Wert 0 im Attribut flags bedeutet, das gesamte Gruppenrichtlinienobjekt, also der Benutzerkonfigurations- und Computerkonfigurationsteil ist aktiviert.
• Der Wert 1 bedeutet, der Benutzerkonfigurationsteil einer GPO ist deaktiviert.
• Ist der Wert 2 , wurde der Computerkonfigurationsteil einer GPO deaktiviert.
• Beim Wert 3 ist das gesamte GPO deaktiviert.

State of the Art kann man den Status der GPOs in der AD-PowerShell mit folgenden Einzeilern abfragen:

# Alle GPOs mit ihrem Status anzeigen lassen:

Get-ADObject -Server <DC> -LDAPFilter "(flags=*)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope Subtree -Properties displayName,flags | Select displayName,flags | FT -A

Das Attribut flags automatisiert mit einem AD-PowerShellskript abfragen

Man kann die Abfrage auch automatisiert mit folgendem AD-PowerShellskript durchführen.

                ######################################################
# # AD-PowerShellskript zur Statusabfrage von GPOs # # Von: Yusuf Dikmenoglu 05/2011
# # http://blog.dikmenoglu.de #
###################################################### $auswahl = Read-Host "Welcher
GPO-Status soll angezeigt werden (0... Alle komplett aktiven GPOs anzeigen 1...Benutzerkonfiguration
ist deaktiviert 2...Computerkonfiguration ist deaktiviert 3...GPOs die komplett deaktiviert
sind):"switch ($auswahl){
0 {         Get-ADObject -Server <DC>
-LDAPFilter "(flags=*)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope
Subtree -Properties displayName,flags | ForEach-Object
{                      if ($_.flags
-eq 0){          write-host "Gesamte
GPO aktiviert: " $_.displayName } } } 1 {         Get-ADObject
-Server <DC> -LDAPFilter "(flags=*)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope
Subtree -Properties displayName,flags | ForEach-Object
{                      if ($_.flags
-eq 1){          write-host "Benutzerkonfiguration
des GPO ist deaktiviert: " $_.displayName } } } 2 { Get-ADObject -Server <DC>
-LDAPFilter "(flags=*)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope
Subtree -Properties displayName,flags | ForEach-Object
{                      if ($_.flags
-eq 2){          write-host "Computerkonfiguration
des GPO ist deaktiviert: " $_.displayName } } } 3 { Get-ADObject -Server <DC>
-LDAPFilter "(flags=*)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope
Subtree -Properties displayName,flags | ForEach-Object
{                      if ($_.flags
-eq 3){          write-host "Gesamte
GPO deaktiviert: " $_.displayName } } } default{
Write-Host "Ungültige
Eingabe" } }
              

Dem Administrator steht seit Windows Server 2003 die gespeicherte Abfrage im Snap-In Active Directory-Benutzer und -Computer (dsa.msc) zur Verfügung. Mit dieser Funktion hat man die Möglichkeit, Suchanfragen zu speichern. Die gespeicherten Abfragen stehen dann für erneute Suchanfragen zu einem späteren Zeitpunkt zur Verfügung. Komplexe Abfragen müssen somit nicht jedesmal neu erstellt werden und können bei gleichbleibenden Bedingungen jedesmal genutzt werden. Mit einer gespeicherten Abfrage können auch benutzerdefinierte Abfragen erstellt werden, die einen LDAP-Suchfilter enthalten.

Alle erstellten Abfragen werden im Ordner Gespeicherte Abfragen gespeichert. Dort können sie bearbeitet und gelöscht werden. Die gespeicherten Abfragen werden jedoch nur in der MMC gespeichert, in der sie durchgeführt wurden und dort auch nur unter dem angemeldeten Benutzer. Fügt man die dsa.msc in eine neue MMC (Start-Ausführen-MMC) hinzu, kann dieses Snap-In als MSC-Datei mit samt den gespeicherten Abfragen gespeichert und auf einer anderen Maschine verwendet bzw. den IT-Kollegen zur Verfügung gestellt werden.

Die gespeicherten Abfragen kann man aber auch als XML-Datei exportieren und auf einer anderen Maschine importieren. Mit einem Rechtsklick auf die gespeicherte Abfrage kann aus dem Kontextmenü die Abfrage mit der Option Abfragedefinition exportieren… als XML-Datei exportiert werden. Auf einer anderen Maschine lässt sich anschließend mit einem Rechtsklick auf den Ordner Gespeicherte Abfrage oder auf einem selbst erstellen Ordner die Option Abfragedefinition importieren… auswählen, um danach die XML-Datei zu importieren.  

In der folgenden ZIP-Datei sind 72 gespeicherte Abfragen, sortiert nach Benutzer-, Gruppen-, Computer-, Drucker und Exchange-Abfragen als XML-Datei gespeichert.

Gespeicherte-Abfragen.zip (55,66 KB)

Weitere Informationen:
Wie finde ich heraus wo sich ein Objekt befindet?
Die Active Directory-Attribute hinter den Feldnamen
Active Directory - Abfrage
AD-PowerShell Befehle

In einigen Attributen wie z.B. badPasswordTime, Last-Logon, Last-Logon-TimeStamp oder pwdLastSet wird ein Large Integer Wert (im Integer8 Format) gespeichert. Da man mit solch einem Wert herzlich wenig anfangen kann, muss dieser in unser Zeitformat umgerechnet werden. Das geht mit den Windows Support Tools oder mit Bordmitteln wie folgt.

REPADMIN

Eine weitere Möglichkeit einen Large Integer Wert umzurechnen, ist das Schweizer Messer Werkzeug für die AD-Replikation REPADMIN. Unter Windows 2000 und Windows Server 2003 befindet sich REPADMIN in den Windows Support Tools und ist ab Windows Server 2008 bereits „on Bord“. Bei dem REPADMIN-Befehl müssen jedoch die letzten sieben Zeichen des Integer Wert entfernt werden. Der Befehl lautet wie folgt: REPADMIN /SHOWTIME 12903275725

Anschließend wandelt man den eingetragenen Wert mit einem Klick auf Hex in einen Hexadezimal Wert um.

Nun gibt man in einer Kommandozeile den Befehl NLTEST /TIME:<HEX> ein. Bei dem Hexadezimal Wert gilt es zu beachten, mit einem Leerzeichen dazwischen, die rechten acht Zeichen voranzustellen. Der Befehl sieht dann so aus: NLTEST /TIME:EC821F4A 1CA6A9B