Debuggen von Gruppenrichtlinien

Hin und wieder greift eine Gruppenrichtlinie nicht so, wie sie soll. Hier meine 08/15 Taktik, um das zu debuggen.

Logischer Menschenverstand

Natürlich sollte man erst mal nachdenken, ob einem spontan etwas einfällt, warum die Gruppenrichtlinie nicht greift. 87,34% der Sachen greifen z.B. nur beim Start des Rechners oder beim Login – wenn jemand im Home-Office sitzt und erst nach dem Login das VPN startet, ist es natürlich logisch, dass die nicht greifen. Übrigens: solltest du OpenVPN nutzen, so verbindet man automatisch beim Windows-Start zu dem VPN-Server.

Selbes gilt auch in anderen Situationen – ist der DC nicht erreichbar, greifen die GPOs nicht.

Aktualisieren von GPOs

GPOs aktualisieren auch auf den Clients nicht in Echtzeit. Standardmäßig machen Sie das alle 90 Minuten +- 30 Minuten (zufällig), beim Systemstart oder beim Login.

Jedes mal einen Benutzer aus- und wieder einzuloggen oder im schlimmsten Fall 2 Stunden warten, um nur eine kurze Änderung zu testen, ist allerdings auch ätzend. Folgender Befehl lädt sofort die Gruppenrichtlinien herunter und wendet die Änderungen an:

gpupdate

Wenn wir alle Gruppenrichtlinien erneut anwenden wollen, also z.B. auch die Software-Installationen neu erzwingen wollen obwohl dem nicht Not tut, gibt es auch den Befehl

gpupdate /force

Der Befehl fragt vorher nach, wenn Änderungen nur bei einem Neustart (z.B. Softwareinstallationen) oder nach einem Logout (z.B. Folder-Redirection) notwendig sind. Und in 99% der Fällen ist dieser Befehl auch nicht notwendig.

DNS nachprüfen

Wir können erst mal checken, welcher DC eigentlich nun für uns verantwortlich ist. Dazu wechseln wir in eine CMD und geben folgenden Befehl ein:

nslookup

Daraufhin sind wir in einer eigenen CLI und können hier frei mit unseren Befehlen rumkaspern. Unser erster Befehl wird lauten:

set type=srv

Was effektiv bedeutet, dass wir einen DNS-Record vom Typ SRV abfragen.

Nun definieren wir, welchen Record wir abfragen wollen – indem wir ihn einfach stumpf mit dem Präfix _ldap._tcp. eingeben. Da meine interne Domäne tino-ruge.de lautet, lautet meine Eingabe dementsprechend:

_ldap._tcp.tino-ruge.de

Und, wie der Screenshos suggeriert – in meinem Fall ist der Server dc.tino-ruge.de für die Domäne an sich zuständig.

DC vom Gerät abfragen und anpingen

Das mag simple klingen. Und nach dem vorherigen Troubleshooting ist das hier auch Bullshit. Aber wenn auf einer Site ein sekundärer DC ausgefallen ist und man kein vernünftiges Fallback hat, kann alles komisch werden.

Von daher: mit folgendem Befehl kann man sich den DC, den das lokale Gerät nutzt, auflisten lassen:

echo %LogonServer%

Ist die Ausgabe z.B. \\DC – einfach mal nen Ping absetzen und schauen, ob das korrekt läuft.

Auflisten der angewendeten Gruppenrichtlinien

Der Befehl dürfte jedem einigermaßen bekannt sein:

gpresult /h gpreport.html

Der Befehl lädt sämtliche GPOs vom Server und fasst diese in einem Bericht gpreport.html zusammen. Wir bekommen einen Report, der auflistet, was Phase ist.

Der Befehl gpresult erzeugt eine HTML-Datei, welche sämtliche Gruppenrichtlinien sowie die getätigten Einstellungen auf dem Gerät anzeigt
Wir sehen welche Gruppenrichtlinie verantwortlich ist
Ebenfalls häufig eine Info, ob etwas korrekt funktioniert hat

Im oberen Bereich sehen wir allgemeine Informationen zu unserem Benutzer, unserer Organisationseinheit und auf Wunsch die Gruppen, in denen wir Mitglied sind.

Anschließend folgt ein Bereich „Einstellungen“, der uns alle angewendeten Einstellungen anzeigt. Über „Einblenden“ können wir uns mehr Informationen zu dem entsprechenden Einstellungen anzeigen lassen – also z.B. welche Laufwerkszuordnungen in meinem Fall ausgeführt werden, welches Script mein Rechner bei jedem Login mappt, oder welche Drucker ich automatisiert hinzugefügt bekomme.

Der letzte Bereich listet alle Informationen zu den angewendeten Gruppenrichtlinien auf. Wir sehen hier drei angewendete GPOs – Drucker, Freigabe und OEMInfo.

Ereignisanzeige

Windows+R, eventvwr – und man bekommt unter Benutzerdefinierte Ansichten > Administrative Ereignisse sofort sämtliche Fehlermeldungen des lokalen Computers angezeigt.

Ab da ist Google der beste Freund und Helfer.

UserEnv-Debug-Logs

Diese Logs helfen primär bei Sachen um das User-Profil. Einfach mal die Logs aktivieren. Dafür müssen wir das Verzeichnis C:\Windows\debug\usermode erstellen und unter:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics

einen REG_DWORD-Value GPSvcDebugLevel erstellen. Diesem geben wir hexadezimal den Wert 00030002.

Abmelden, neu anmelden, Logs checken.

Debuggen von netlogon

Auch hier benötigen wir wieder das Verzeichnis C:\Windows\debug – und führen dann folgenden Befehl aus:

nltest /dbflag:0x2080ffff

Reboot tut gut, und nach dem Login sehen wir in C:\Windows\debug\netlogon.log

Zum Deaktivieren setzen wir das Flag wieder auf 0:

nltest /dbflag:0x0

Und starten noch mal neu.

Kategorie: Gruppenrichtlinien

tino-ruge.de wird tino-kuptz.de

Im Laufe des Jahres 2024 wird dieser Blog umziehen. Alle Inhalte werden 1:1 weitergeleitet, nix geht verloren. Neue Domain, alter Autor, alter Inhalt.