Die Richtlinie ist verknüpft, die Einstellung ist gesetzt – und der Client bleibt trotzdem unverändert. Das ist einer der häufigsten Support-Fälle im Windows-Umfeld. In den meisten Fällen liegt es nicht an Windows selbst, sondern an einem Filter, einer Vererbungsregel oder an SYSVOL. Dieser Beitrag zeigt ein festes Diagnose-Vorgehen für Administratoren in KMU und Kommunen.
1. Symptom eingrenzen: Computer- oder Benutzerteil?
Der erste Blick gilt der Frage, welcher Teil der Richtlinie fehlt. Computereinstellungen werden beim Start verarbeitet, Benutzereinstellungen bei der Anmeldung. Fehlt beides, ist das GPO nicht im Gültigkeitsbereich, die Verknüpfung ist deaktiviert oder die Vererbung blockiert. Fehlt nur der Benutzerteil, liegt es meist an Loopback-Verarbeitung oder einer fehlenden Client-Erweiterung.
gpupdate /force /target:computer
gpupdate /force /target:userErscheint nach dem erzwungenen Update keine Änderung, ist die Ursache fast immer serverseitig oder im Filter zu suchen – nicht im Client.
2. Ergebnisbericht lesen statt raten
gpresult /r listet nur angewandte und abgelehnte GPOs. Der HTML-Bericht zeigt zusätzlich den Grund: „Verweigert (Filterung)“ bei WMI- oder Sicherheitsfiltern, „Nicht angewendet (leer)“ bei fehlenden Einstellungen, außerdem blockierte Vererbung und deaktivierte Verknüpfungen.
gpresult /h C:\Temp\gpresult.html /f
start C:\Temp\gpresult.htmlDer Bericht ist eine Momentaufnahme des angemeldeten Kontexts. Bei Benutzerproblemen als betroffener Benutzer messen, bei Computerproblemen in einer Eingabeaufforderung mit erhöhten Rechten.
3. Ereignisprotokoll: 1129, 1058 und 1030
Drei Ereignis-IDs decken den Großteil der Fälle ab. 1129 bedeutet, dass der Domänencontroller beim Start nicht erreichbar war – typisch bei VPN-Clients, WLAN mit Verzögerung oder fehlerhafter DNS-Auflösung. 1058 und 1030 zeigen, dass die Datei gpt.ini aus SYSVOL nicht gelesen werden konnte. Das ist ein Rechte- oder Replikationsproblem, kein Client-Problem.
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-GroupPolicy'} -MaxEvents 20 |
Select-Object TimeCreated, Id, LevelDisplayName, MessageBei 1129 zuerst nltest /sc_verify:firma.local und die Zeitsynchronisation prüfen: Eine Zeitabweichung von mehr als fünf Minuten lässt die Kerberos-Authentifizierung scheitern.
4. SYSVOL und Replikation prüfen
Der schnellste Test prüft, ob der Client die Richtlinienvorlage überhaupt lesen kann. Der Pfad enthält die GUID des GPO und muss von jedem Client aus erreichbar sein.
Test-Path '\firma.local\SYSVOL\firma.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini'
nltest /dsgetdc:firma.local
dcdiag /test:sysvolcheck /test:netlogonsAntwortet Test-Path mit False, während der Ordner auf dem Domänencontroller existiert, hängt die DFS-R-Replikation oder es fehlen Leserechte für Authentifizierte Benutzer und Domänencomputer.
5. Sicherheitsfilterung und der MS16-072-Effekt
Seit dem Update MS16-072 vom Juni 2016 liest der Gruppenrichtlinienclient das GPO mit dem Computerkonto, nicht mehr mit dem Benutzerkonto. Wer „Authenticated Users“ aus dem Geltungsbereich entfernt und nur einer Gruppe „Übernehmen“ zuweist, muss deshalb Domänencomputer mindestens Leserechte einräumen – sonst wird das GPO ohne Fehlermeldung übersprungen.
Das ist die häufigste Ursache nach AD-Bereinigungen und einer der wenigen Fälle, in denen ein GPO im Bericht korrekt als verweigert erscheint, obwohl die Einstellungen stimmen.
6. WMI-Filter einzeln testen
Ein WMI-Filter auf eine bestimmte Windows-Version oder ein Modell ist schnell gesetzt und schwer zu erkennen. Im Bericht erscheint das GPO als gefiltert. Die Abfrage lässt sich mit denselben Klassen direkt prüfen.
Get-CimInstance -Namespace root\cimv2 -ClassName Win32_OperatingSystem |
Select-Object Caption, Version, OperatingSystemSKULiefert die Abfrage auf dem Zielsystem kein Ergebnis, greift das GPO dort nicht – unabhängig davon, wie korrekt die Verknüpfung ist.
7. Langsame Verbindung, Loopback, deaktivierte Abschnitte
Drei Einstellungen erklären scheinbar unlogisches Verhalten: Die Erkennung langsamer Verbindungen überspringt standardmäßig unter 500 kbit/s die Computereinstellungen. Die Loopback-Verarbeitung ersetzt auf Terminalservern die Benutzerrichtlinien durch die des Computers. Und ein GPO mit dem Status „Computerkonfigurationseinstellungen deaktiviert“ liefert nur die Hälfte seiner Konfiguration.
Get-GPO -All | Where-Object { $_.GpoStatus -ne 'AllSettingsEnabled' } |
Select-Object DisplayName, GpoStatusDie langsame Verbindung lässt sich über die Richtlinie „Konfigurieren der Gruppenrichtlinien-Verarbeitung für langsame Verbindungen“ (Computerkonfiguration, Administrative Vorlagen, System, Gruppenrichtlinie) auf einen passenden Wert setzen.
8. Ausführliche Protokollierung einschalten
Wenn Bericht und Ereignisprotokoll nichts hergeben, hilft das Debug-Log des Gruppenrichtlinienclients. Es wird über die Registry aktiviert und nach der Analyse wieder entfernt, weil es schnell sehr groß wird.
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics" /v GPSvcDebugLevel /t REG_DWORD /d 0x30002 /f
gpupdate /force
notepad %windir%\debug\usermode\gpsvc.logDanach den Wert wieder auf 0 setzen. Zusätzlich lohnt der Blick in das operative Protokoll Microsoft-Windows-GroupPolicy/Operational, das bei aktiver Protokollierung jede Verarbeitungsstufe dokumentiert.
Fazit
In der Praxis führt die Reihenfolge Bericht, Ereignisprotokoll, SYSVOL-Test, Filter zuverlässig zur Ursache. Wichtig ist, den Gültigkeitsbereich eines GPO nie nur im Editor zu beurteilen, sondern immer aus Sicht des Clients. Wer nach Änderungen an Sicherheitsfiltern zusätzlich Domänencomputer mit Leserechten bedenkt, vermeidet den häufigsten Rückfall.
Quellen
- Microsoft Learn: Anleitungen zur Fehlerbehebung für Gruppenrichtlinien (abgerufen am 29.10.2026)
- Microsoft Learn: gpresult – Befehlsreferenz (abgerufen am 29.10.2026)
- Microsoft Security Bulletin MS16-072 (14.06.2016)
Hinweis: Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz (KI) erstellt.
No responses yet