Gruppenrichtlinie greift nicht: Verarbeitung und Richtlinienergebnissatz nachvollziehen
Die häufigste verlorene Stunde entsteht dadurch, dass am Server gesucht wird, obwohl der Client bereits weiß, warum eine Richtlinie nicht angewendet wurde, und es auch ausgibt.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Es wird am Server gesucht, obwohl der Client die Antwort schon hat
Der übliche Ablauf beginnt in der Verwaltungskonsole. Die Richtlinie wird geöffnet, die Einstellung ist da, die Verknüpfung ist da, alles sieht richtig aus. Dann wird die Richtlinie gelöscht und neu angelegt, ein weiterer Kollege sieht drauf, jemand startet den Client neu, und irgendwann funktioniert es oder auch nicht. Dabei liegt die Antwort am Client, und zwar in einem Bericht, den ein einziger Aufruf erzeugt.
Der zweite Grund für lange Suche ist eine Fehlvorstellung über die Verarbeitung. Viele erwarten, dass eine Richtlinie unmittelbar nach dem Speichern am Client wirkt. Tatsächlich wird die Computerrichtlinie im Hintergrund standardmäßig alle 90 Minuten aktualisiert, mit einer zufälligen Verschiebung von null bis 30 Minuten, damit nicht alle Rechner gleichzeitig anfragen. Auf Domänencontrollern liegt der Standardwert bei fünf Minuten. Wer nach zwei Minuten prüft und nichts sieht, hat noch gar nichts gemessen.
Der dritte Grund ist die Verwechslung von Computer- und Benutzerkonfiguration. Eine Richtlinie mit Benutzereinstellungen, die an der Organisationseinheit der Computer hängt, tut gar nichts, und umgekehrt genauso. Windows verarbeitet die Computerkonfiguration anhand des Ortes des Computerobjekts und die Benutzerkonfiguration anhand des Ortes des Benutzerobjekts, unabhängig davon, an welchem Rechner sich jemand anmeldet. Genau für den Fall, dass diese Trennung nicht passt, gibt es die Loopbackverarbeitung, und wer sie nicht kennt, baut stattdessen Umwege.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die Befunde, die im Betrieb tatsächlich auftreten
Sechs Fälle decken den größten Teil dessen ab, was in einer gewachsenen Umgebung an nicht wirkenden Richtlinien vorkommt. Zu jedem steht hier, woran du ihn erkennst, was ihn verursacht und was der nächste Griff ist.
Symptom
Die Richtlinie taucht im Bericht am Client überhaupt nicht auf, weder unter den angewendeten noch unter den verweigerten.
Ursache
Der Client kennt sie nicht, weil er nicht in ihrem Geltungsbereich liegt. Windows arbeitet die Richtlinien in einer festen Reihenfolge ab, vom lokalen Satz über den Standort und die Domäne bis zu den Organisationseinheiten, wobei die Einheiten von oben nach unten durchlaufen werden. Eine Richtlinie, die an einer anderen Organisationseinheit hängt oder deren Verknüpfung deaktiviert ist, kommt in dieser Kette nicht vor.
Lösung
Prüf zuerst, in welcher Organisationseinheit das Objekt tatsächlich steht, und zwar getrennt für Computer und Benutzer. Der häufigste Befund ist ein Computerobjekt im Standardcontainer statt in der vorgesehenen Einheit. Prüf danach, ob die Verknüpfung aktiviert ist und ob an der Richtlinie selbst die Computer- oder Benutzerkonfiguration abgeschaltet wurde, denn eine abgeschaltete Hälfte wird gar nicht erst gelesen.
Symptom
Die Richtlinie steht im Bericht unter den nicht angewendeten, als Grund ist der Sicherheitsfilter genannt.
Ursache
Dem Objekt fehlt eine der beiden nötigen Berechtigungen an der Richtlinie: das Leserecht und das Recht, die Gruppenrichtlinie anzuwenden. Der klassische Auslöser ist eine Delegierung, bei der die Gruppe der authentifizierten Benutzer entfernt und durch eine engere Gruppe ersetzt wurde. Übersehen wird dabei regelmäßig, dass für die Verarbeitung der Benutzerkonfiguration auch das Computerkonto Leserecht auf die Richtlinie braucht.
Lösung
Sieh dir die Berechtigungen der Richtlinie an und prüf getrennt, wer lesen darf und wer anwenden darf. Wurde die Gruppe der authentifizierten Benutzer entfernt, ergänze ein ausdrückliches Leserecht für die betroffenen Computerkonten, etwa über die Gruppe der Domänencomputer. Prüf außerdem, ob die Zielgruppe die richtige ist, denn eine Mitgliedschaft, die nach der letzten Anmeldung hinzugefügt wurde, wirkt erst nach einer neuen Anmeldung.
Symptom
Die Richtlinie steht im Bericht unter den nicht angewendeten, als Grund ist ein WMI-Filter genannt.
Ursache
Die WMI-Abfrage des Filters hat für dieses Objekt nicht True ergeben. Häufige Ursachen sind eine Abfrage, die auf eine bestimmte Betriebssystemversion oder Bauart zielt und nach einem Upgrade nicht mehr passt, eine Abfrage gegen eine Eigenschaft, die auf diesem Gerät nicht existiert, und schlicht ein Tippfehler in der Abfrage. Zu bedenken ist außerdem, dass ein WMI-Filter für die gesamte Richtlinie gilt und nicht für einzelne Einstellungen darin.
Lösung
Führ die Abfrage des Filters direkt auf dem betroffenen Gerät aus und sieh nach, was sie zurückgibt. Kommt kein Ergebnis, liegt es an der Abfrage und nicht an der Richtlinie. Prüf danach, ob der Filter überhaupt nötig ist: In vielen Fällen lässt sich dasselbe Ziel mit einer eigenen Organisationseinheit oder einer Sicherheitsgruppe erreichen, und beides ist im Betrieb leichter nachvollziehbar.
Symptom
Die Einstellung steht in einer Richtlinie, die an der Organisationseinheit der Computer hängt, wirkt aber bei keinem Benutzer.
Ursache
Es handelt sich um eine Einstellung aus der Benutzerkonfiguration. Windows sammelt die Benutzerrichtlinien anhand des Ortes des Benutzerobjekts, unabhängig davon, an welchem Rechner sich jemand anmeldet. Eine Benutzereinstellung an der Computer-Organisationseinheit läuft deshalb ins Leere. Für Rechner, bei denen genau das gewünscht ist, etwa in öffentlich zugänglichen Bereichen, in Laboren oder in Schulungsräumen, ist die Loopbackverarbeitung vorgesehen.
Lösung
Schalte in der Computerkonfiguration unter Administrative Vorlagen, System, Gruppenrichtlinie die Option für den Loopbackverarbeitungsmodus der Benutzergruppenrichtlinie ein und wähl den passenden Modus. Im Modus Zusammenführen wird zuerst die Liste der Benutzerrichtlinien ermittelt und die Liste der Computerrichtlinien hinten angehängt, wodurch Letztere den höheren Vorrang bekommen. Im Modus Ersetzen wird die Liste der Benutzerrichtlinien gar nicht erst ermittelt.
Symptom
Die Richtlinie wird laut Bericht angewendet, der wirksame Wert der Einstellung stammt aber aus einer anderen Richtlinie.
Ursache
Mehrere Richtlinien setzen denselben Wert, und der Vorrang entscheidet. Ohne besondere Kennzeichnung gewinnt die Richtlinie, die dem Objekt am nächsten liegt, weil sie zuletzt verarbeitet wird. Diese Reihenfolge lässt sich an zwei Stellen umdrehen: durch das Erzwingen einer Verknüpfung, die dann Vorrang behält, und durch das Blockieren der Vererbung an einer Organisationseinheit, was allerdings gegen eine erzwungene Verknüpfung nichts ausrichtet.
Lösung
Ruf den Bericht mit der Option für alle verfügbaren Angaben ab. Sie zeigt laut Dokumentation nicht nur die Einstellungen mit dem Vorrang eins, sondern auch die mit niedrigerem Vorrang, und damit siehst du, welche Richtlinien um denselben Wert konkurrieren. Danach entscheidest du in der Konsole, ob die konkurrierende Einstellung entfernt, die Verknüpfung verschoben oder das Erzwingen gesetzt wird.
Symptom
Die Einstellung erscheint nach einer erzwungenen Aktualisierung im Bericht, wirkt aber erst nach einer Abmeldung oder einem Neustart.
Ursache
Nicht jede Erweiterung arbeitet im Hintergrund. Microsoft nennt dafür ausdrücklich Beispiele: benutzerbezogene Softwareverteilung und Ordnerumleitung werden bei der Anmeldung verarbeitet, computerbezogene Softwareverteilung beim Start. Solche Einstellungen stehen nach einer Aktualisierung im Bericht, weil sie zugestellt wurden, angewendet werden sie aber erst am nächsten Verarbeitungszeitpunkt im Vordergrund.
Lösung
Nutz die dafür vorgesehenen Schalter von gpupdate. Mit /logoff folgt nach der Aktualisierung eine Abmeldung, mit /boot ein Neustart, und beide bleiben ohne Wirkung, wenn keine Erweiterung aufgerufen wurde, die das verlangt. Für den planbaren Fall gibt es /sync, womit die nächste Verarbeitung im Vordergrund, also beim Start oder bei der Anmeldung, synchron abläuft. Die Schalter /force und /wait werden dabei laut Dokumentation ignoriert.
Fünf Fragen in dieser Reihenfolge
- 01 Steht das Objekt unterhalb der Stelle, an der die Richtlinie verknüpft ist?
- 02 Erscheint die Richtlinie im Bericht überhaupt, und wenn nein, mit welcher Begründung?
- 03 Passt der Bereich der Einstellung zum Ort des Objekts, Computer oder Benutzer?
- 04 Setzt eine andere Richtlinie denselben Wert mit höherem Vorrang?
- 05 Wird diese Art von Einstellung im Hintergrund überhaupt verarbeitet?
Was du in der ersten Viertelstunde tust
Sechs Schritte in dieser Reihenfolge beantworten die Frage in den allermeisten Fällen. Der erste kostet zehn Sekunden und erledigt einen erstaunlich großen Teil der Fälle.
Zuerst prüfen, wo Computer- und Benutzerobjekt tatsächlich stehen
Eine Richtlinie wirkt auf Objekte unterhalb der Stelle, an der sie verknüpft ist. Der häufigste Befund ist banal: Das Computerobjekt liegt noch im Standardcontainer für Computer und nicht in der Organisationseinheit, an der die Richtlinie hängt. Diese Prüfung dauert zehn Sekunden und erspart in vielen Fällen den ganzen Rest.
Den Richtlinienergebnissatz am Client abrufen und richtig lesen
gpresult zeigt den tatsächlich wirksamen Satz an Einstellungen. Wichtig ist die Wahl der Ausgabeoption, denn ohne sie läuft der Aufruf nicht: /r liefert die Zusammenfassung, /v die ausführlichen Angaben und /z alles Verfügbare. Der Unterschied zwischen den letzten beiden ist dokumentiert: /v zeigt die Einstellungen mit dem Vorrang eins, /z zusätzlich die mit niedrigerem Vorrang. Für einen Bericht zum Weitergeben gibt es /h mit einem Dateinamen.
Die Liste der verweigerten Richtlinien ansehen, nicht nur die angewendeten
Der interessante Teil des Berichts ist nicht die Liste der angewendeten Richtlinien, sondern die der nicht angewendeten samt Begründung. Dort steht, ob eine Richtlinie am Sicherheitsfilter, am WMI-Filter oder daran gescheitert ist, dass sie keine Einstellungen für diesen Bereich enthält. Diese eine Spalte ersetzt einen Großteil der Fehlersuche.
Den richtigen Bereich abfragen und den Kontext beachten
Mit /scope wird zwischen Benutzer und Computer unterschieden, und ohne diese Angabe zeigt gpresult beides. Für eine andere Person am selben Rechner gibt es /user mit Domäne und Anmeldename, für einen entfernten Rechner /s. Wichtig ist, dass die Daten des Benutzers nur derjenige sehen kann, für den sie erhoben wurden oder wer entsprechend berechtigt ist.
Eine Aktualisierung erzwingen statt zu warten
gpupdate stößt die Verarbeitung sofort an. Ohne Zusatz werden nur geänderte Einstellungen angewendet, mit /force alle. Mit /target lässt sich auf Computer oder Benutzer eingrenzen. Für Erweiterungen, die im Hintergrund gar nicht arbeiten, gibt es /logoff und /boot, die eine Abmeldung beziehungsweise einen Neustart nach der Aktualisierung auslösen.
Erst danach am Server suchen
Wenn der Client sagt, dass eine Richtlinie am Sicherheitsfilter gescheitert ist, dann ist die Berechtigung das Thema und nicht die Einstellung. Wenn er sie gar nicht kennt, ist die Verknüpfung das Thema. Wenn er sie anwendet und der Wert trotzdem anders ist, ist der Vorrang das Thema. Erst mit dieser Zuordnung lohnt sich der Wechsel in die Verwaltungskonsole.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Wann Windows Richtlinien überhaupt verarbeitet
Es gibt zwei Verarbeitungszeitpunkte im Vordergrund und einen fortlaufenden im Hintergrund. Im Vordergrund geschieht das beim Start des Rechners für die Computerkonfiguration und bei der Anmeldung für die Benutzerkonfiguration. Im Hintergrund läuft die Aktualisierung in festen Abständen weiter. Für Computer nennt Microsoft als Standard alle 90 Minuten mit einer zufälligen Verschiebung von null bis 30 Minuten, damit nicht alle Geräte gleichzeitig anfragen. Auf Domänencontrollern liegt der Standard bei fünf Minuten.
Diese Werte lassen sich per Richtlinie ändern, und dabei lauert eine Falle. Wird das Intervall auf null Minuten gesetzt, versucht der Rechner laut Dokumentation alle sieben Sekunden zu aktualisieren. Microsoft weist im selben Atemzug darauf hin, dass sehr kurze Intervalle die Arbeit stören und den Netzverkehr erhöhen und deshalb für die meisten Installationen nicht geeignet sind. Wer die Aktualisierung beschleunigen will, sollte einen sinnvollen Wert setzen und nicht die Null.
Für die Fehlersuche folgt daraus eine einfache Regel: Nach einer Änderung an einer Richtlinie wird nicht gewartet, sondern gpupdate ausgeführt. Ohne Zusatz werden nur geänderte Einstellungen angewendet, was schnell geht und für den Normalfall ausreicht. Mit /force werden alle Einstellungen erneut angewendet, was länger dauert und dann sinnvoll ist, wenn jemand am Client von Hand in die Registrierung eingegriffen hat. Der Schalter /wait steuert dabei nur, wie lange die Eingabeaufforderung wartet, und hat auf die Verarbeitung selbst keinen Einfluss.
Den Richtlinienergebnissatz richtig lesen
gpresult gibt aus, welche Einstellungen für einen bestimmten Rechner und eine bestimmte Person tatsächlich gelten. Der Aufruf verlangt immer eine Ausgabeoption, sonst läuft er nicht. Für den schnellen Blick gibt es die Zusammenfassung, für die Einzelheiten die ausführliche Ausgabe und für den vollständigen Bestand die dritte Stufe. Der Unterschied zwischen den beiden ausführlichen Stufen ist dokumentiert und im Alltag entscheidend: Die eine zeigt die Einstellungen mit dem Vorrang eins, die andere zusätzlich die mit niedrigerem Vorrang. Genau dort steht, welche Richtlinien um denselben Wert konkurrieren.
Weil diese Ausgaben umfangreich werden, empfiehlt die Dokumentation, sie in eine Textdatei umzuleiten. Für die Weitergabe an andere gibt es die Ausgabe als HTML oder XML mit einem Dateinamen, und mit einem weiteren Schalter lässt sich eine vorhandene Datei überschreiben. Zu beachten ist, dass sich diese Dateiausgaben nicht mit den Optionen für andere Anmeldedaten oder für die Konsolenausgabe kombinieren lassen.
Zwei Aufrufvarianten lohnen sich im Alltag besonders. Die erste grenzt mit der Bereichsangabe auf Benutzer oder Computer ein, denn ohne sie werden beide ausgegeben und der interessante Teil geht in der Länge unter. Die zweite fragt gezielt eine andere Person am selben Rechner ab, was bei Meldungen wie es funktioniert nur bei mir nicht in einem Aufruf klärt, ob es tatsächlich am Konto liegt. Beides lässt sich mit der Angabe eines entfernten Rechners kombinieren.
Loopbackverarbeitung, und wann sie die richtige Antwort ist
Die normale Verarbeitung folgt einer klaren Trennung: Computer bekommen die Richtlinien ihrer eigenen Organisationseinheit beim Start, Personen die Richtlinien ihrer eigenen Organisationseinheit bei der Anmeldung, unabhängig davon, an welchem Rechner sie sich anmelden. Für die meisten Fälle ist das genau richtig, und Microsoft empfiehlt ausdrücklich, Einstellungen an der Organisationseinheit auszurichten, in der das jeweilige Objekt liegt.
Es gibt aber Rechner, bei denen die Umgebung wichtiger ist als die Person: öffentlich zugängliche Geräte, Laborrechner, Schulungsräume, Terminalserver. Für diese Fälle ist die Loopbackverarbeitung gedacht. Sie wird in der Computerkonfiguration unter Administrative Vorlagen, System, Gruppenrichtlinie eingeschaltet und weist das System an, die Richtlinien des Computers auf jede Person anzuwenden, die sich an diesem Gerät anmeldet.
Die beiden Modi unterscheiden sich deutlich. Im Modus Zusammenführen wird zunächst wie gewohnt die Liste der Benutzerrichtlinien ermittelt, danach wird dieselbe Ermittlung noch einmal für den Ort des Computerobjekts durchgeführt, und diese zweite Liste wird an die erste hinten angehängt. Weil zuletzt verarbeitet wird, was gewinnt, haben die Richtlinien des Computers damit den höheren Vorrang. Im Modus Ersetzen wird die Liste der Benutzerrichtlinien gar nicht erst ermittelt, es zählt ausschließlich die Liste des Computers. Zwei Randbedingungen nennt Microsoft: Die Loopbackverarbeitung funktioniert nur in einer Active-Directory-Umgebung mit Computer- und Benutzerkonto im Verzeichnis, und die so angewendeten Benutzereinstellungen lassen sich nicht dadurch filtern, dass man dem Computerobjekt die Rechte zum Lesen und Anwenden entzieht.
Vorrang, Vererbung und warum Erzwingen sparsam gehört
Ohne besondere Kennzeichnung gewinnt die Richtlinie, die dem Objekt am nächsten liegt, weil sie zuletzt verarbeitet wird. Hängen an derselben Organisationseinheit mehrere Richtlinien, entscheidet ihre Reihenfolge in der Konsole. Diese beiden Regeln reichen aus, um die meisten Konflikte zu erklären, und der Bericht mit allen verfügbaren Angaben zeigt genau diese Konkurrenz.
Zwei Werkzeuge drehen die Reihenfolge um. Das Erzwingen einer Verknüpfung sorgt dafür, dass ihre Einstellungen von weiter unten nicht mehr überschrieben werden können. Das Blockieren der Vererbung an einer Organisationseinheit hält Richtlinien von oben fern, richtet aber gegen eine erzwungene Verknüpfung nichts aus. Beide sind nützlich, und beide machen eine Umgebung schwerer verständlich, weil sie die einfache Regel außer Kraft setzen.
Für den Alltag lohnt sich deshalb Zurückhaltung. Ein Erzwingen an der Domäne für die wenigen Vorgaben, die überall gelten müssen, ist nachvollziehbar. Ein Erzwingen an fünf verschiedenen Ebenen zusammen mit blockierter Vererbung an drei Organisationseinheiten führt dazu, dass niemand mehr im Kopf ausrechnen kann, welcher Wert am Ende gilt. Wenn du an einem solchen Punkt stehst, ist die Frage nach dem Aufräumen der Richtlinienstruktur die ehrlichere als die nach dem nächsten Sonderfall.
Dazu passende Kurse
Wenn die Richtlinienstruktur bei euch über Jahre gewachsen ist, geben dir Kurse zur Verwaltung von Gruppenrichtlinien die Systematik zurück.
Weil hinter vielen nicht greifenden Richtlinien eine Berechtigungsfrage steckt, gehören Kurse zu Berechtigungen und Absicherung im Microsoft-Umfeld zur selben Baustelle.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Danke an Trainer Sven, welcher ein sehr detailliertes und fachliches KnowHow besitzt.
Ich beziehe mich hier nur auf die Nachschlung durch Herrn Marco Jachmann. Herr Jachmann ist überaus kompetent und hat alle Inhalte professionell vermittelt.
Sehr sehr gut aufbereitete Nachschulung mit genau dem notwendigen Engagement und der erforderlichen Vorbereitung innerhalb von 48 Stunden.
Häufige Fragen
Wie schnell wirkt eine geänderte Richtlinie am Client?
Was ist der Unterschied zwischen den ausführlichen Ausgaben von gpresult?
Warum greift unsere Richtlinie nicht mehr, seit wir den Sicherheitsfilter geändert haben?
Wann brauchen wir Loopbackverarbeitung?
Warum steht die Einstellung im Bericht, wirkt aber nicht?
Können wir den Bericht auch für einen anderen Rechner abrufen?
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Windows Server-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Gruppenrichtlinien so bauen, dass die Suche kurz bleibt
Im Aufbaukurs zur Gruppenrichtlinienadministration bei cmt arbeitest du an Verknüpfung, Vorrang, Sicherheits- und WMI-Filtern sowie an der Loopbackverarbeitung und siehst dabei, wie sich die Befunde im Richtlinienergebnissatz unterscheiden.
Passt dazu
- Loopbackverarbeitung in Gruppenrichtlinien: Benutzereinstellungen am Gerät festmachen
- Gewachsene Gruppenrichtlinien aufräumen: Bestand aufnehmen, zusammenlegen, dokumentieren
- Gruppenrichtlinien oder Intune: welche Einstellung gehört wohin
- Active-Directory-Replikation hängt: mit repadmin und dcdiag zur Ursache