Freitag, 5. April 2013

Der große Group Policy Troubleshooting Guide - Teil 2/3

Nachdem ich euch in Teil 1 des "Group Policy Troubleshooting Guides" bereits die häufigsten logischen Fehler gezeigt habe, geht es nun um technische Fehler.

Folgende Themen werden behandelt:

  • Welche Fehler können auftreten?
  • Wo finde ich GPO-Eventlogs?
  • Welche Logfiles werden geschrieben?
  • Wie kann das Verhalten einzelner CSEs analysiert werden
DNS - Die Grundlage für eine korrekte Richtlinienabarbeitung
Eine funktionierende DNS-Auflösung ist die Grundlage für eine funktionierende Authentifizierung und Anwendung von Gruppenrichtlinien.
Damit der Client einen Domaincontroller finden kann, muss dieser Anfragen an den DNS Server stellen. Im Zuge dieses Prozesses wird ebenfalls die betreffende Active Directory Site des Clients ermittelt.
Den kompletten Vorgang der Ermittlung des Domaincontrollers findet ihr bei Yusuf Dikmenoglu.

Im weiteren Verlauf der Gruppenrichtlinienabarbeitung werden immer wieder LDAP Abfragen an den DC gesendet. Funktioniert die DNS Auflösung nicht oder nur teilweise, so sollte spätestens beim Zugriff auf das SYSVOL Verzeichnis ein Fehler auftreten. Die GPSVC Engine versucht unter anderem das File Gpt.ini aus dem Verzeichnis jeder Policy zu lesen.

Den genauen Prozessablauf findet ihr hier:
http://technet.microsoft.com/en-us/library/cc784268%28v=ws.10%29.aspx

Beliebte Fehler in der DNS Konfiguration
1. Am Client ist der primäre DNS Server kein DC

Ein Fehler der gerade in kleineren Umgebungen häufig zu finden ist.
Dort wird oftmals als primärer DNS am Client ein Internet Router angegeben.

Der Hintergedanke ist wohl meist, dass dieser Router sowohl die lokalen Adressen, als auch die "unbekannten" Adressen des Internets auflösen kann.

Für die Anwendung von Gruppenrichtlinien kann das jedoch fatale Folgen haben. Der DC Locator Process ist auf die sogenannten SRV Records angewiesen.

Diese sind in der Regel auf Microsoft DNS Server vorhanden, jedoch nicht zwangsläufig auf dem DNS Server des Internet Routers.
Fehlen diese SRV Records (dazu auch mehr in 2.), kann auch die Anwendung der Richtlinien fehlschlagen.

 

Deshalb merken:
Als primärer DNS sollte immer ein DC mit DNS Server (oder ein anderer Windows DNS Server) eingetragen werden.

Im optimalen Falle befindet sich dieser in der gleichen AD-Site wie der Client.

 

2. Fehlende DNS Records
Für die Suche des Domaincontrollers sind diverse SRV Records erforderlich.

Fehlt ein Teil oder alle diese Einträge, kann die Anwendung der Gruppenrichtlinien und die Ermittlung des Domaincontrollers fehlschlagen.

Sollten nicht nur einzelne Clients betroffen sein und dessen Client DNS Konfiguration korrekt sein, sollte man die SRV Records auf den Domaincontrollern überprüfen.

Dazu eignen sich folgende Tools:
DNSLint /ad
dcdiag /test:dns

Leider ist dieser genannte Fehler schwer zu diagnostizieren,
deshalb hier noch einige weiterführende Informationen:

http://blogs.technet.com/b/askpfeplat/archive/2012/07/09/the-case-of-the-missing-srv-records.aspx
http://support.microsoft.com/kb/816587/en-us


3. Grundlegende Netzwerkprobleme

Stimmt das Netzwerklayout nicht oder handelt es sich um eine Misskonfiguration auf Netzwerkebene, kann die DNS-Auflösung und somit auch das Abarbeiten der Gruppenrichtlinien fehlschlagen.

Hierzu zählen unter anderem Probleme wie:

  • falsch eingetragene Routen
  • falsche Firewallkonfigurationen
  • nicht erreichbare DNS-Server
  • falsch konfigurierte DNS Reihenfolge
  • fehlende / falsche DNS Suffixe
  • falsch konfigurierte DNS Forwarder
  • falsche VLAN Einstellungen
Replikations- oder AD-Probleme
Technisch betrachtet besteht jede Gruppenrichtlinie aus zwei Teilen.
Gemeint ist hier nicht die Benutzer- und Computerkonfiguration, sondern der Richtlinienanteil im Group Policy Container (GPC) und der Anteil innerhalb des Group Policy Templates (GPT).

GPC - Group Policy Container: 

Innerhalb des GPC werden nicht die einzelnen Einstellungen der Richtlinien gespeichert, sondern viel mehr die "Metadaten" der Richtlinien.
Hier sind Informationen hinterlegt wie:

  • Welche Richtlinien gibt es
  • Wo sind die einzelnen Richtlinien verlinkt
  • Welche Client Side Extensions (CSEs) verwenden die einzelnen Richtlinien
  • Wie lautet der Pfad zum GPT
  • Welche Berechtigungen haben die einzelnen Richtlinien
  • Der GUID jeder Richtlinie
Vereinzelt werden dennoch spezielle Richtlinieneinstellungen innerhalb des GPC gespeichert. Hierzu gehören Einstellungen wie:
  • Wired Network Policies (802.3)
  • Wireless Network Policies (802.11)
  • Deployed Printer Connections
GPT - Group Policy Template:
Hier sind die eigentlichen Einstellungen hinterlegt.
Beim GPT handelt es sich um eine Netzwerkfreigabe namens "SYSVOL".

Pro Richtlinie gibt es jeweils ein Verzeichnis.
Der Verzeichnisname entspricht dem GUID der Richtlinie.

Der GPC und GPT werden unterschiedlich repliziert.
Der GPC wird über die Active Directory Replikation wie alle anderen AD-Objekte repliziert. Die Replikation des GPT übernimmt der FRS (File Replication Service) oder unter Server 2008 (falls konfiguriert) DFS-R.

GPC und GPT besitzen jeweils eine eigene Versionierung.
Stimmt die Versionsnummer der beiden Richtlinienanteile im GPC und GPT nicht überein, so treten Probleme bei der Anwendung der Richtlinie auf.
Zu bedenken ist auch, dass die Replikation unter Umständen einen größeren Zeitraum in Anspruch nehmen kann.
Dies gilt insbesondere für Replikationen die nicht innerhalb einer Active Directory Site stattfinden.


Replikationsprobleme erkennen
Der erste Anhaltspunkt sollte wie so oft die Ereignisanzeige sein.

Ereigniskategorien die ihr unbedingt prüfen solltet:



Weitere Tools um die AD-Funktionalität und Replikation zu überprüfen:

  • dcdiag
    Der Klassiker für die AD-Diagnose.
  • GPOTool
    Das GPOTool ist schon etwas in die Jahre gekommen. Dennoch bietet es noch zuverlässige Dienste. Mit dem GPOTool können die einzelnen Richtlinienversionen auf den verschiedenen Domaincontrollern verglichen werden.
  • Die GPMC von Server 2012 (und Windows 8).
    Hier können nun unter dem Reiter "Status" die Versionsstände verglichen werden.
    (in der Testumgebung des Screenshots gab es nur einen DC, deshalb wird bei beiden Werten "0" angezeigt)



Auf das Netzwerk warten?
Gruppenrichtlinien können im Vordergrund oder im Hintergrund ausgeführt werden. Vereinfacht könnte man es so bezeichnen:

 
Im Vordergrund =
Beim Hochfahren des Rechners
Beim Anmelden Benutzers.

Im Hintergrund =
Zu allen anderen Zeitpunkten werden die Richtlinien "Im Hintergrund" angewendet.

Seit Windows XP beschleunigt eine neue Option names "Fast Logon Optimization" das Booten und Anmelden.
Allerdings hat dies negative Auswirkungen auf die Anwendung von Gruppenrichtlinien. Fast Logon lässt sich mittels dieser Einstellung deaktivieren:


http://gpsearch.azurewebsites.net/#1839


Zusätzlich sollte auch noch das Anmeldeverhalten geändert werden:


http://gpsearch.azurewebsites.net/#2302


(genau genommen beeinflussen sich technisch beide Richtlinieneinstellungen)

Die Deaktivierung der "Fast Logon Optimization" ist eine sinnvolle Sache.
Jedoch kann dies Verzögerungen im Start- und Anmeldeprozess des Rechners verursachen. Bevor die Policies abgearbeitet werden können, arbeitet die GPSVC-Engine mit dem Dienst NLA (Network Location Awareness) zusammen.

Es wird sichergestellt, dass das Netzwerk erfolgreich initialisiert wurde, bevor die Richtlinien abgearbeitet werden.
Treten in diesem Zusammenhang Fehler auf, so sollte nicht einfach die Fast Logon Optimization wieder aktiviert werden, sondern man sollte der Ursache des Problems auf den Grund gehen.


Hierzu können Ursachen gehören wie:

  • Netzwerktreiber die während des Bootvorgangs eine lange Zeit zum Initialisieren benötigen
  • WLAN Verbindungen mit gleichzeitigen LAN Verbindungen die den NLA Dienst beschäftigen
  • Falsch konfigurierte Switche (Portfast nicht aktiviert)
  • Firewalleinstellungen blockieren den Netzwerk-Traffic während des Bootens
Wie kann man feststellen ob Richtlinieneinstellungen angewendet werden?
Ist der Fehler noch nicht im Detail bekannt, sollte man zunächst einmal überprüfen ob der Client die Einstellungen anwendet.
Diese Methode bezieht sich ebenfalls auf die Logikfehler von Teil 1 des Guides.

Die meisten Tools beziehen ihre Daten mittels des RSoP (Resultant Set of Policies). Dieser ermittelt die benötigten Daten per WMI (Windows Management Instrumentation).

Tipp:
Den genauen Prozess findet ihr hier.
Die wichtigsten Tools:
  • rsop.msc - Hierbei handelt es sich um ein MMC-SnapIn, das die Daten des RSoP ermittelt. Rsop.msc ist allerdings nicht auf dem aktuellen technischen Stand. Das SnapIn kann keine Daten der Group Policy Preferences anzeigen. Die Darstellung orientiert sich am Group Policy Editor.
  • gpresult /r - Es handelt sich um ein Kommandozeilentool welches die angewendeten und abgelehnten Richtlinien anzeigt.
  • gpresult /h - Es wird ein html-Bericht generiert. Diese Methode sollte die Standardmethode zum Ermitteln der GPO-Daten sein. Es handelt sich um eine Kombination aus gpresult /r und rsop.msc. Der Vorteil: Hier werden auch Daten der Preferences angezeigt.
  • GPMC - Gruppenrichtlinienergebnisse
  • Die GPMC bietet ebenfalls die Möglichkeit einen RSoP remote zu erstellen.
    Zu beachten ist allerdings, dass hierzu am Client einige Firewallausnahmen definiert werden müssen.
Wo finde ich GPO-Eventlogs?
Die erste Anlaufstelle sollte immer das Eventlog sein.
Die verschiedenen Events finden sich primär in diesen Kategorien:

  • Anwendung (vereinzelt)
  • System 
  • Anwendungs- und Dienstprotokolle > Microsoft > Windows > GroupPolicy (ab Windows Vista verfügbar) Das letzte Log ist hierbei am umfangreichsten:

 

Der Eventviewer von Windows XP und Server 2003 besitzt noch keine Anwendungs- und Dienstprotokolle.
Tipp:
Mehr Informationen findet ihr hier.

Welche Logfiles werden geschrieben?
Zunächst einmal werden keine Logfiles geschrieben. Im Problemfall muss das Logging aktiviert werden.

 

Logging des Gruppenrichtliniendienstes:
Hierbei handelt es sich um das Logfile der GPSVC-Engine.
Dieses Logfile ist als Zusammenfassung der verschiedenen Client Side Extensions zu sehen. Das Logfile ist relativ umfangreich und lässt sich am besten mit dem Tool "Policy Reporter" auswerten.
 

www.sysprosoft.com/policyreporter.shtml  

Das Programm ist kostenlos und wertet unter anderem die Zeitdauer einzelnen Prozessschritte aus.
Tipp:
In meinem Post "Das gpsvc-logging aktivieren" erfahrt ihr wie ihr das Logging aktiviert.

Unter Windows XP und Server 2003 gibt es noch kein gpsvc.log.
Dort lässt sich das userenv-logging aktivieren.
Dieses wird allerdings nicht nur für Fehlerdiagnose der Gruppenrichtlinienanwendung verwendet, sondern hat noch andere Funktionen und lässt sich deshalb schlechter auswerten.
 

Der Policy Reporter kann mit beiden Logdateien umgehen.
 

Fehler beim Anwenden von Sicherheitseinstellungen:
Fehler beim Abarbeiten von Sicherheitseinstellungen (Berechtigungen auf Registry Schlüssel, Dateien, Diensten, Vergabe von Benutzerrechten usw.) werden in einer separaten Logdatei festgehalten.
Das File befindet sich unter %SYSTEMROOT%\security\logs\winlogon.log.


http://support.microsoft.com/kb/324383/de  

Fehler innerhalb der GPMC:
Treten Fehler in der GPMC beim Erstellen oder Ändern von Richtlinien auf, so kann das GPMC-logging aktiviert werden.


http://technet.microsoft.com/en-us/library/cc737379%28v=ws.10%29.aspx
Tipp:
Eine umfangreiche Liste der Logfiles findet ihr hier.

Wie kann das Verhalten einzelner CSEs analysiert werden?
Neben den einzelnen Logfiles (wie oben genannt) werden auch noch Einträge für diverse CSEs im Eventlog geschrieben.




Für die Client Side Extension der Group Policy Preferences können einzelne Logfiles geschrieben werden. Diese nennen sich "Tracing-Files" und können wie folgt aktiviert werden.


http://blogs.technet.com/b/askds/archive/2008/07/18/enabling-group-policy-preferences-debug-logging-using-the-rsat.aspx

Exotische GPO Tools?
Es gibt noch etliche mehr oder weniger bekannte GPO Tools.

Diese können im speziellen Falle hilfreich sein, jedoch würde ich diese Tools nicht überbewerten. Viele dieser Tools werden nicht weiterentwickelt und sind veraltet. 

    • Dcgpofix.exe
      Damit lassen sich die Default Policies der Domäne wiederherstellen.
    • GPMonitor.exe
      Der GPMonitor sammelt Daten über die Anwendung von Richtlinien und kann diese an einer zentralen Stelle im Netzwerk speichern.
    • GPOTool.exe
      Vergleicht die SYSVOL und AD Versionen auf allen DCs.
    • GPLogView
      Kann ab Windows Vista eingesetzt werden. Das Tool sammelt Informationen aus dem Eventlog. Sehr interessant ist auch die Möglichkeit "live" zu loggen. (Option -m)
    • GPMC-Skripte
      Backup, Restore, Importieren, Exportieren uvm.

      3 Kommentare:

      1. Großartiger Beitrag, vielen Dank! Vor allem die Infos zum Logging sind spitze...
        Mir drängt sich immer noch eine Frage auf, die ich auch mit längerer Recherche noch nicht klären konnte. Als Admin alter Schule habe ich noch gelernt, dass die GroupPolicyEngine durch winlogon/userenv.dll den Zugriff auf die CSE-dlls organisiert. Gilt das nicht mehr? Warum läuft seit Vista ein GPSVC innerhalb eines svchost-Prozesses? Wie hängt das zusammen? Bin für jeden Hinweis dankbar.

        AntwortenLöschen
      2. Hallo,

        erst einmal vielen Dank!
        Wie genau das Zusammenspiel zwischen der GPSVC und den CSE DLLs
        ist, verrät uns Microsoft leider nicht.
        Fakt ist, es gibt nun eine gpsvc.dll, diese Steuert die Policy Anwendung. Der svchost Prozess ist ja ohnehin nur ein "Shape".
        Also eine Umgebung in die die DLL geladen wird.

        Du kannst z.B. einmal einen Mitschnitt mittels Process Monitor machen und dabei einen gpupdate ausführen.
        Dort wird ersichtlich, dass gpsvc.dll die Ausführungen der einzelnen CSEs koordiniert.

        AntwortenLöschen
      3. Dank Dir! Das mit dem Processmonitor hatte ich jetzt auch schon gemacht. Und der Rest also leider wieder mal die gute alte MS-Blackbox ;-)
        Ansonsten: Weiter so mit dem Blog, große Lektüre!

        AntwortenLöschen