Praktischer Leitfaden für Gruppenrichtlinien (GPO) — Funktionsweise, Überprüfung der Anwendung und Wahl zwischen GPO und Intune

„Ich habe die GPO geändert, und nichts ist passiert.“ „Ich habe gpupdate ausgeführt, und die Einstellung hat sich trotzdem nicht geändert.“ „Die App läuft auf dem Entwicklungsrechner, aber nicht auf den PCs beim Kunden.“ Solche Probleme lassen sich deutlich leichter eingrenzen, sobald Sie welche GPOs im Geltungsbereich sind, welche Einstellung gewinnt und wann die Verarbeitung stattfand voneinander trennen.

Gruppenrichtlinien sind der Mechanismus, der Windows-Einstellungen in einer Organisation verteilt und verwaltet. Die Auskunft, etwas werde „per GPO verteilt“, sagt noch nicht, was auf einem bestimmten PC oder für einen bestimmten Benutzer tatsächlich gilt. Sie müssen die Konfiguration auf der verteilenden Seite mit dem Ergebnis auf der empfangenden Seite vergleichen.

Dieser Artikel ist eine praktische Einführung für IT-Personal kleiner und mittlerer Unternehmen, das eine AD-Umgebung übernommen hat, und für Entwickler, die Fachanwendungen auf domänenverbundenen PCs bereitstellen. Er behandelt die Anwendungsreihenfolge, wann Einstellungen wirksam werden, die Eingrenzung mit gpresult und dem Ereignisprotokoll, ADMX und den zentralen Speicher sowie die Wahl zwischen GPO und Intune. Die Erklärungen stützen sich auf Primärquellen zum Stand August 2026.

Beginnen Sie bei dem, worauf Sie stoßen

Bei der ersten Lektüre holen Sie die Begriffe in Kapitel 2, verstehen den Mechanismus in den Kapiteln 3 und 4 und gehen dann zu den Prüfschritten in Kapitel 5. Wenn Sie mitten in einer Untersuchung sind, beginnen Sie bei Kapitel 5 und gehen Sie je nach den Ergebnissen zu den Erklärungen von Rangfolge und Zeitpunkt zurück.

1. Zuerst das Wichtigste

„Welche Einstellung gewinnt“ und „wann sie ankommt“ sind getrennte Probleme

Gruppenrichtlinien werden in der Reihenfolge lokal, Standort, Domäne, OU (LSDOU) verarbeitet, und wenn dieselbe Einstellung kollidiert, gewinnt zuletzt geschrieben. Die lokale GPO ist die schwächste Ebene. Allerdings ändern Vererbung deaktivieren und Erzwungen diesen Standardablauf.¹

Die Anwendung hat zwei Formen: die Vordergrundverarbeitung beim Start und bei der Anmeldung sowie die Hintergrundaktualisierung in einem Standardintervall von rund 90 Minuten plus einem zufälligen Versatz von 0 bis 30 Minuten. Die Hintergrundaktualisierung auf Domänencontrollern beträgt standardmäßig 5 Minuten. gpupdate /force wendet jede Einstellung erneut an; es ist kein Allzweckbefehl, der auch Einstellungen, die nur bei der Anmeldung oder beim Neustart verarbeitet werden, sofort anwendet.²³

Prüfen Sie das angekommene Ergebnis, bevor Sie weiter ändern

Die Eingrenzung beginnt beim RSoP-Bericht, den gpresult /h erzeugt. Prüfen Sie die angewendeten GPOs, die verweigerten GPOs und ihre Gründe sowie die gewinnende GPO für jede Einstellung. Wenn Sie Verarbeitungsfehler oder Verzögerungen vertiefen müssen, nutzen Sie das GroupPolicy-Betriebsprotokoll.⁴⁵

Einstellungen administrativer Vorlagen werden in der Regel in Registrierungsorte wie Software\Policies geschrieben, und richtlinienbewusste Apps geben diesen Werten Vorrang vor ihren eigenen Einstellungen. „Nicht konfiguriert“ schreibt keinen Wert. Manche Einstellungen schreiben jedoch außerhalb der eigenen Schlüssel; wenn ein Wert zurückbleibt, prüfen Sie, wohin er geschrieben wurde.⁶

Richten Sie die Verwaltungsmethode an den Annahmen aus, von denen die App abhängt

In einer Domäne werden ADMX-Definitionen im PolicyDefinitions-Zentralen Speicher in SYSVOL zusammengeführt. Er existiert, damit GPMC einen gemeinsamen Vorlagensatz referenziert.⁷

Wählen Sie zwischen GPO und Intune anhand der Identitätsgrundlage des Geräts und des Einsatzorts. In einer hybriden Umgebung vermeiden Sie, dieselbe Einstellung doppelt zu konfigurieren, und legen Sie fest, wer jeden Bereich besitzt. Group Policy analytics ist nützlich, um Einstellungen vor einer Migration zu sortieren.⁸⁹

Auch für Entwickler ist GPO Teil der Umgebungsspezifikation. Einstellungen, die Annahmen einer App ändern, etwa die Ausführungsrichtlinie, das Zusammenführen lokaler Firewallregeln sowie Proxy- und Laufwerkskonfiguration, werden zentral verteilt. Verläuft etwas „nur beim Kunden fehl“, bestätigen Sie diese Annahmen mit dem Bericht und den tatsächlichen Werten.¹⁰¹¹

In der Abbildung kennzeichnet eine durchgezogene Linie eine stets geltende Beziehung und eine gestrichelte Linie eine bedingte (die Bedingungen stehen bei jeder Beziehung auf der Detailseite). Die vollständige Liste der Beziehungen (29 insgesamt, mit Beleg und Sicherheitsgrad) und die Definitionen der wichtigsten Konzepte sind auf der Detailseite der Wissenskarte (auf Japanisch) zusammengestellt. Daten: JSON-LD / Turtle

2. Was Gruppenrichtlinien sind — lokale GPOs und Domänen-GPOs

Gruppenrichtlinien sind der Mechanismus, mit dem ein Administrator Windows-Einstellungen zentral festlegt und auf Zielcomputer und -benutzer anwendet. Ein Bündel von Einstellungen heißt GPO (Gruppenrichtlinienobjekt).

Beginnen Sie damit, „die lokale GPO, die im PC selbst verwaltet wird“ von „der Domänen-GPO, die von AD verteilt wird“ zu trennen.

Wo Einstellungen leben: lokal oder Domäne

Ein Arbeitsgruppen-PC, also einer, der nicht der Domäne angehört, verarbeitet nur die lokale GPO.¹ Mit anderen Worten: Wenn jemand sagt, ein Rechner sei „per GPO verwaltet“, ist in der Praxis fast immer eine Domänen-GPO gemeint.

flowchart TB
    accTitle: GPOs, die ein Arbeitsgruppen-PC und ein domänenverbundener PC verarbeiten
    accDescr: Ein Arbeitsgruppen-PC verarbeitet nur die lokale GPO, während ein domänenverbundener PC zusätzlich die von Active Directory verteilten Domänen-GPOs verarbeitet
    pc{"Wie ist der PC verbunden?"}
    pc -->|Arbeitsgruppe| wg["Verarbeitet nur die lokale GPO"]
    pc -->|Domänenverbunden| dom["Lokal plus Domänen-GPOs"]
    dom -.-> note["GPOs in der Praxis sind fast alle Domänen-GPOs"]

Abbildung 1: Ein Arbeitsgruppen-PC verarbeitet nur die lokale GPO, während ein domänenverbundener PC auch Domänen-GPOs verarbeitet.

Wen Einstellungen treffen: den PC oder den Benutzer

Unabhängig von der GPO fällt ihr Inhalt in zwei große Zweige.

• Computerkonfiguration: Einstellungen, die für jeden gelten, der sich an diesem PC anmeldet. Werden beim Start angewendet.
• Benutzerkonfiguration: Einstellungen, die für diesen Benutzer gelten, egal an welchem PC er sich anmeldet. Werden bei der Anmeldung angewendet.

Die Achse „ist diese Einstellung an den PC oder an die Person gebunden“ taucht durchgängig in der Anwendungsreihenfolge und in der Bestätigung, dass eine Einstellung wirksam wurde, auf, die beide folgen. Manche Elemente gibt es in beiden Zweigen, daher sollten Sie sich angewöhnen, beide zu prüfen, wann immer Sie eine Einstellung suchen.

flowchart TB
    accTitle: Die zwei Zweige innerhalb einer GPO
    accDescr: Jede GPO hat einen Zweig Computerkonfiguration und einen Zweig Benutzerkonfiguration, wobei die Computerkonfiguration beim Start angewendet wird und für jeden gilt, der sich an diesem PC anmeldet, und die Benutzerkonfiguration bei der Anmeldung angewendet wird und gilt, egal an welchem PC sich der Benutzer anmeldet
    gpo["Inhalt einer GPO"] --> comp["Computerkonfiguration"]
    gpo --> user["Benutzerkonfiguration"]
    comp --> boot["Beim Start angewendet"]
    user --> logon["Bei der Anmeldung angewendet"]
    boot -.-> anyone["Gilt für jeden, der sich anmeldet"]
    logon -.-> anypc["Gilt auf jedem PC"]

Abbildung 2: Eine GPO hat zwei Zweige, die an den PC gebundene Computerkonfiguration und die an die Person gebundene Benutzerkonfiguration.

3. Wie die Anwendung funktioniert — das „zuletzt geschrieben gewinnt“ von LSDOU und die Steuerung der Vererbung

3.1. LSDOU: lokal, Standort, Domäne, OU

Auf einem domänenverbundenen PC werden GPOs in der folgenden Reihenfolge verarbeitet.¹

1. Die lokale GPO
2. GPOs, die mit dem Standort verknüpft sind
3. GPOs, die mit der Domäne verknüpft sind
4. GPOs, die mit einer OU (Organisationseinheit) verknüpft sind — von der obersten OU nach unten verarbeitet, endend mit den GPOs der OU, die den Zielcomputer oder -benutzer direkt enthält

Der Name LSDOU kommt von diesen Initialen. Er bezeichnet die Reihenfolge, in der Richtlinien verarbeitet werden, nicht eine Reihenfolge „von höchster Priorität nach unten“.

Wenn mehrere GPOs dieselbe Einstellung konfigurieren, gewinnt die später verarbeitete GPO. Einstellungen, die nicht kollidieren, werden einfach kombiniert.¹

In dieser Standardreihenfolge ist die GPO der dem Ziel nächsten OU die stärkste und die lokale GPO die schwächste. „Ich habe es in gpedit.msc korrigiert, und es ist zurückgekehrt“ ist genau dieses Verhalten gemäß Spezifikation. Die Ausnahmen, die die Vererbung ändern, behandelt Abschnitt 3.2.

flowchart TB
    accTitle: Die LSDOU-Verarbeitungsreihenfolge und zuletzt geschrieben gewinnt
    accDescr: GPOs werden in der Reihenfolge lokal, Standort, Domäne, OU verarbeitet, und bei einem Konflikt gewinnt die später verarbeitete GPO, sodass die GPO der dem Ziel nächsten OU die stärkste und die lokale GPO die schwächste ist
    l["1. Lokale GPO"] --> s["2. Standort"]
    s --> d["3. Domäne"]
    d --> ou["4. OU (von oben nach unten)"]
    ou --> win["Zuletzt geschrieben gewinnt bei einem Konflikt"]
    win -.-> strongest["Die GPO der nächsten OU ist am stärksten"]
    win -.-> weakest["Die lokale GPO ist am schwächsten"]

Abbildung 3: LSDOU ist die Reihenfolge, in der Richtlinien verarbeitet werden, und wenn dieselbe Einstellung kollidiert, gewinnt die später verarbeitete GPO.

Am selben Ort gewinnt die niedrigste Verknüpfungsreihenfolge

Wenn mehrere GPOs mit demselben Standort, derselben Domäne oder derselben OU verknüpft sind, prüfen Sie die Verknüpfungsreihenfolge auf der Registerkarte „Verknüpfte Gruppenrichtlinienobjekte“ in GPMC.

Die GPO mit der niedrigsten Nummer wird zuletzt verarbeitet und hat daher die höchste Priorität. Wichtig ist, das nicht als „eine niedrigere Nummer bedeutet, sie wird zuerst verarbeitet“ zu lesen.¹

flowchart TB
    accTitle: Verknüpfungsreihenfolge, wenn mehrere GPOs am selben Ort sitzen
    accDescr: Wenn mehrere GPOs mit demselben Standort, derselben Domäne oder derselben OU verknüpft sind, entscheidet die Verknüpfungsreihenfolge in GPMC über die Verarbeitung, und die GPO mit der niedrigsten Nummer wird zuletzt verarbeitet und erhält die höchste Priorität
    multi["Mehrere GPOs am selben Ort"] --> tab["Entscheidet die Verknüpfungsreihenfolge in GPMC"]
    tab --> last["Die GPO mit der niedrigsten Nummer wird zuletzt verarbeitet"]
    last --> win["Gewinnt durch zuletzt geschrieben und hat die höchste Priorität"]

Abbildung 4: Am selben Verknüpfungsziel wird die GPO mit der niedrigsten Verknüpfungsreihenfolge zuletzt verarbeitet und gewinnt.

3.2. Vererbung deaktivieren und Erzwungen

Vererbung deaktivieren und Erzwungen sind die Mechanismen, die Ausnahmen zur Standardreihenfolge in Abschnitt 3.1 erzeugen. Lesen Sie sie, indem Sie wo Sie sie setzen von was sie stoppen trennen.¹

• Vererbung deaktivieren: an einer Domäne oder OU gesetzt, stoppt es die Vererbung von GPOs von oben. Es ist das Werkzeug für „diese OU allein soll den unternehmensweiten Standard nicht erhalten“.
• Erzwungen (früher No Override): an einer GPO-Verknüpfung gesetzt, sorgt es dafür, dass diese GPO immer angewendet wird, auch dort, wo die Vererbung darunter blockiert ist, und verhindert, dass untergeordnete GPOs sie überschreiben. Wenn Vererbung deaktivieren und Erzwungen kollidieren, gewinnt Erzwungen.¹

flowchart TB
    accTitle: Wie Vererbung deaktivieren und Erzwungen zusammenhängen
    accDescr: Vererbung deaktivieren stoppt die Vererbung von GPOs von oben, aber eine erzwungene GPO wird immer angewendet, auch dort, wo die Vererbung darunter blockiert ist, und kann nicht von untergeordneten GPOs überschrieben werden
    upper["GPO von oben"] --> blocked{"Vererbung darunter deaktiviert?"}
    blocked -->|Nein| inherit["Wird unverändert geerbt"]
    blocked -->|Ja| enforced{"Ist die GPO-Verknüpfung erzwungen?"}
    enforced -->|Nein| stop["Die Vererbung stoppt"]
    enforced -->|Ja| apply["Immer angewendet"]
    apply -.-> noover["Wird nicht von untergeordneten GPOs überschrieben"]

Abbildung 5: Vererbung deaktivieren stoppt die Vererbung von oben, aber eine erzwungene GPO durchquert die Sperre und wird immer angewendet.

Begrenzen Sie, wofür Sie Erzwungen nutzen

Weil Erzwungen das standardmäßige „zuletzt geschrieben gewinnt“ ändert, erzeugt ein großzügiger Einsatz mehr Ergebnisse, die auch beim Lesen des RSoP nicht zur Intuition passen. Die Faustregel ist, es auf Dinge wie Sicherheitseinstellungen zu beschränken, die unternehmensweit unbedingt gelten müssen.

Damit sind Vererbung und Rangfolge abgedeckt. Ob eine GPO überhaupt auf ein Ziel angewendet werden kann, entscheidet außerdem die Sicherheitsfilterung, die als Nächstes kommt.

3.3. Sicherheitsfilterung

Anwendung erfordert sowohl „Lesen“ als auch „Übernehmen“

Über das Verknüpfungsziel hinaus lässt sich für wen eine GPO gilt auch pro GPO eingrenzen. Der Zielbenutzer oder -computer muss sowohl die Berechtigungen „Lesen“ als auch „Gruppenrichtlinie übernehmen“ für diese GPO besitzen.¹³

Standardmäßig besitzen Authentifizierte Benutzer, die Benutzer und Computer umfassen, beide Berechtigungen, sodass alles unter dem Verknüpfungsziel im Geltungsbereich liegt. Das Einengen auf eine bestimmte Sicherheitsgruppe ist die Sicherheitsfilterung.

Der Filter wirkt auf die GPO als Ganzes. Es ist kein Mechanismus, um einzelne Einstellungen innerhalb einer GPO auf unterschiedliche Ziele einzugrenzen.¹³

Bei benutzerbezogenen GPOs die Leseberechtigung des PCs behalten

Wenn Sie das Ziel eingrenzen, entfernen Sie „Lesen“ nicht bei Authentifizierten Benutzern. Seit MS16-072 (2016) wird die benutzerbezogene Richtlinie im Sicherheitskontext des Computers abgerufen. Kann der PC die GPO nicht lesen, wird sie nicht angewendet, selbst wenn der Zielbenutzer beide Berechtigungen besitzt.¹⁴

Betrachten Sie die erforderlichen Berechtigungen als zwei getrennte Dinge.

• Geben Sie der Zielgruppe Lesen plus Gruppenrichtlinie übernehmen.
• Belassen Sie nur Lesen für Authentifizierte Benutzer oder Domänencomputer. Die Berechtigung Übernehmen ist nicht nötig.¹⁴

flowchart TB
    accTitle: Wie die Sicherheitsfilterung entscheidet, ob eine GPO angewendet wird
    accDescr: Damit eine GPO angewendet wird, müssen der Zielbenutzer oder -computer sowohl die Berechtigungen Lesen als auch Gruppenrichtlinie übernehmen besitzen, und eine benutzerbezogene GPO erfordert zusätzlich, dass das Computerkonto sie lesen kann
    target["Ziel unter der GPO-Verknüpfung"] --> perm{"Sowohl Lesen als auch Übernehmen?"}
    perm -->|Nein| deny["Durch Filterung verweigert"]
    perm -->|Ja| usergpo{"Benutzerbezogene GPO?"}
    usergpo -->|Nein| apply["Angewendet"]
    usergpo -->|Ja| comp{"Kann der Computer sie lesen?"}
    comp -->|Ja| apply
    comp -->|Nein| deny2["Nicht angewendet (MS16-072)"]

Abbildung 6: Die Anwendung erfordert sowohl „Lesen“ als auch „Gruppenrichtlinie übernehmen“, und eine benutzerbezogene GPO erfordert außerdem Lesen für das Computerkonto.

Nach einer Gruppenänderung mit einem neuen Token bestätigen

Das falsche Objekt zu treffen — „die Einstellung ist computerbezogen, aber nur der Benutzer wurde der Gruppe hinzugefügt“ — ist ein häufiger Stolperstein. Prüfen Sie zuerst, ob die Einstellung auf der Computerseite oder auf der Benutzerseite liegt.

Das andere ist „ich habe sie aus der Gruppe entfernt, und es gilt trotzdem“. Die Mitgliedschaft wird aus dem Sicherheitstoken bewertet, das bei der Anmeldung aufgebaut wird, sodass bloßes Warten auf eine Hintergrundaktualisierung nichts ändert.

Die Gruppenänderung eines Benutzers erreicht den Filter nach Abmeldung und erneuter Anmeldung, die eines Computers nach einem Neustart, sobald ein neues Token aufgebaut wurde.

flowchart TB
    accTitle: Wie lange eine Gruppenänderung braucht, bis sie den Filter erreicht
    accDescr: Die Gruppenmitgliedschaft wird aus dem Sicherheitstoken bewertet, das bei der Anmeldung aufgebaut wird, sodass die Änderung eines Benutzers den Filter erst nach erneuter Anmeldung und die eines Computers erst nach einem Neustart erreicht, der ein neues Token aufbaut
    change["Mitglieder einer Gruppe ändern"] --> old["Nicht reflektiert, solange das alte Token steht"]
    old --> u["Der Benutzer meldet sich erneut an"]
    old --> c["Der Computer startet neu"]
    u --> token["Mit dem neuen Token bewertet"]
    c --> token
    token --> ok["Im Filter reflektiert"]
    old -.-> bg["Eine Hintergrundaktualisierung löst es nicht"]

Abbildung 7: Eine Gruppenänderung erreicht den Filter erst, wenn eine Abmeldung oder ein Neustart ein neues Token aufbaut.

Eine Anwendung für gemeinsam genutzte PCs: Loopbackverarbeitung

Auf gemeinsam genutzten PCs und Remotedesktopservern möchten Sie manchmal „die Benutzerkonfiguration für jeden tauschen, der sich an diesem PC anmeldet“. Der Sondermodus dafür ist die Loopbackverarbeitung.

Sie wendet Benutzereinstellungen anhand des Computerstandorts an und hat zwei Modi, Ersetzen und Zusammenführen. Es ist eine erweiterte Funktion für Kioskterminals und Schulungs-PCs, und dieser Artikel hält nur fest, dass sie existiert.¹⁵

flowchart TB
    accTitle: Die Idee hinter der Loopbackverarbeitung
    accDescr: Die Loopbackverarbeitung ist ein Sondermodus, der die Benutzerkonfiguration anhand des Computerstandorts anwendet, die zwei Modi Ersetzen und Zusammenführen hat und dort genutzt wird, wo jede Person, die sich anmeldet, dieselben Benutzereinstellungen erhalten soll, etwa auf gemeinsam genutzten PCs und Kioskterminals
    shared["Gemeinsam genutzte PCs, Kioskterminals und Ähnliches"] --> lb["Loopbackverarbeitung"]
    lb --> base["Entscheidet der Computerstandort"]
    base --> rep["Modus Ersetzen"]
    base --> mrg["Modus Zusammenführen"]
    lb -.-> aim["Gilt für jeden, der sich anmeldet"]

Abbildung 8: Die Loopbackverarbeitung ist ein Sondermodus, der die Benutzerkonfiguration anhand des Computerstandorts anwendet, und sie hat die zwei Modi Ersetzen und Zusammenführen.

4. Wann Einstellungen wirksam werden — Vordergrundverarbeitung und Hintergrundaktualisierung

Nach einer Einstellungsänderung ist der Zeitpunkt der Anwendung möglicherweise einfach noch nicht gekommen. Trennen Sie hier ob das Gerät einen DC erreichen kann von wann genau diese Einstellung verarbeitet wird.²

Start und Anmeldung von Aktualisierungen im laufenden Betrieb trennen

Zuerst muss das Gerät einen DC erreichen können

Auf einem laufenden Gerät, das einen Domänencontroller erreichen kann, verbreiten sich Einstellungen, die die Hintergrundaktualisierung unterstützen, standardmäßig in rund zwei Stunden über den Bestand. Offline-Geräte oder Laptops, die ohne VPN-Verbindung außer Haus sind, erreichen sie erst beim nächsten Verbindungsaufbau zum DC.

Einstellungen, die nur durch Vordergrundverarbeitung angewendet werden, erfordern darüber hinaus das Warten auf einen Start oder eine Anmeldung.

Der Unterschied zwischen gpupdate und /force

Wenn Sie es eilig haben, führen Sie gpupdate auf dem Ziel-PC aus. Normalerweise wendet es nur die geänderten Einstellungen an; mit /force wendet es jede Einstellung erneut an, unabhängig davon, ob sie sich geändert hat.³

rem Nur das Geänderte aktualisieren (normalerweise reicht das)
gpupdate

rem Jede Einstellung erneut anwenden (wenn Sie den zwischengespeicherten Zustand vermuten)
gpupdate /force

flowchart TB
    accTitle: DC-Erreichbarkeit und wie Einstellungen ankommen
    accDescr: Auf einem laufenden Gerät, das einen Domänencontroller erreichen kann, verbreiten sich Einstellungen, die die Hintergrundaktualisierung unterstützen, in rund zwei Stunden, aber sie erreichen ein Offline-Gerät oder einen Laptop außer Haus ohne VPN-Verbindung erst bei der nächsten Verbindung zu einem DC
    pc{"Kann es einen DC erreichen?"}
    pc -->|Ja| ok["Verbreitet sich in rund zwei Stunden"]
    pc -->|Nein| ng["Kommt nicht an, bis es sich verbindet"]
    ng -.-> ex["Offline-Geräte und Laptops außer Haus ohne VPN"]

Abbildung 9: Ein laufendes Gerät, das einen DC erreichen kann, erhält die Einstellungen in rund zwei Stunden, während ein Offline-Gerät bis zur nächsten Verbindung zu einem DC nichts erhält.

Auch /force kann die Vordergrundverarbeitung nicht überspringen

Benutzerbezogene Softwareinstallation und Ordnerumleitung werden nur bei der Anmeldung verarbeitet, computerbezogene Softwareinstallation nur beim Start.³

Die Option /logoff von gpupdate meldet nach der Aktualisierung ab und /boot startet danach neu. Wenn das Hinzufügen von /force nichts ändert, prüfen Sie, ob die Einstellung zu den Arten gehört, die eine Anmeldung oder einen Neustart erfordern.³

flowchart TB
    accTitle: Die Wege, auf denen eine Einstellung wirksam wird
    accDescr: Eine GPO-Änderung kommt im Standardintervall von rund 90 Minuten plus 0 bis 30 Minuten Versatz an, wenn die Einstellung die Hintergrundaktualisierung unterstützt, während eine nur durch Vordergrundverarbeitung angewendete Einstellung auf einen Start oder eine Anmeldung warten muss, und selbst gpupdate braucht /logoff oder /boot für nur-vordergrundbezogene Einstellungen, wenn Sie es eilig haben
    change["Eine GPO ändern"] --> kind{"Unterstützt Hintergrundaktualisierung?"}
    kind -->|Ja| bg["Aktualisiert in rund 90 Minuten plus 0 bis 30"]
    kind -->|Nein| fg["Beim Start oder bei der Anmeldung angewendet"]
    bg --> done["Wird wirksam"]
    fg --> done
    rush["Wenn Sie es eilig haben"] -.-> upd["gpupdate ausführen"]
    upd -.-> force["/force wendet alles erneut an"]
    upd -.-> reboot["Vordergrund braucht /logoff oder /boot"]

Abbildung 10: Die Hintergrundaktualisierung liefert nur die Einstellungen, die sie unterstützen, und nur durch Vordergrundverarbeitung angewendete Einstellungen brauchen nach gpupdate weiterhin eine Abmeldung oder einen Neustart.

5. Eingrenzung, wenn eine Einstellung nicht wirksam wird — gpresult, Ereignisprotokoll und Registrierung

Die Werkzeuge haben unterschiedliche Rollen. gpresult zeigt das Ergebnis der Anwendung, das Betriebsprotokoll den Verlauf der Verarbeitung und die Registrierung die tatsächlich geschriebenen Werte. Statt sofort wieder Einstellungen zu ändern, grenzen Sie die Ursache vom Ergebnis her ein.

5.1. Das RSoP mit gpresult /h prüfen

Das Endergebnis mehrerer überlagerter GPOs heißt RSoP (Resultant Set of Policy). Das Standardwerkzeug gpresult erzeugt aus einer erhöhten Eingabeaufforderung einen HTML-Bericht, der leichter zu lesen ist.⁴⁵

Im folgenden Beispiel legen Sie den Ausgabeordner C:\temp an, bevor Sie es ausführen. Wenn Sie den Bericht lesen, bestätigen Sie außerdem, dass es das Ergebnis für den PC und den Benutzer ist, den Sie untersuchen wollen.

rem Einen HTML-Bericht des RSoP für Benutzer und Computer schreiben
gpresult /h C:\temp\gp-report.html /f

rem Um nur die Zusammenfassung auf der Konsole zu prüfen
gpresult /r
gpresult /scope computer /r

Nicht bei „sie wurde angewendet“ stehen bleiben

Im Bericht betrachten Sie der Reihe nach die folgenden drei Punkte. Selbst wenn die gewünschte GPO in der Liste steht, hat die Einstellung nicht den erwarteten Wert, wenn eine andere GPO sie überschreibt.

1. Die Liste der angewendeten GPOs — steht die gewünschte GPO darin
2. Die Liste der verweigerten GPOs und die Gründe — der Grund, warum sie nicht angewendet wurde, etwa Sicherheitsfilterung, ein WMI-Filter oder eine leere GPO, wird angezeigt⁵
3. Die gewinnende GPO für jede Einstellung — wessen GPO-Wert die Einstellung entschieden hat, die Sie interessiert. Gewinnt eine andere GPO, gehen Sie zu den Rangfolgeregeln in Kapitel 3 zurück

flowchart TB
    accTitle: Die drei Punkte, die Sie zuerst in einem RSoP-Bericht betrachten
    accDescr: In einem gpresult-Bericht prüfen Sie zuerst, ob die gewünschte GPO in der Liste der angewendeten GPOs steht, dann die Liste der verweigerten GPOs und die Gründe, und schließlich nutzen Sie die gewinnende GPO für jede Einstellung, um zu identifizieren, wessen Wert gewonnen hat
    rep["Den RSoP-Bericht öffnen"] --> one["1. Liste der angewendeten GPOs"]
    one --> two["2. Verweigerte GPOs und Gründe"]
    two --> three["3. Gewinnende GPO je Einstellung"]
    three -.-> review["Zurückgehen, wenn eine andere GPO gewinnt"]

Abbildung 11: Lesen Sie einen RSoP-Bericht in der Reihenfolge angewendete GPOs, verweigerte GPOs und Gründe sowie die gewinnende GPO für jede Einstellung.

5.2. Das GroupPolicy-Betriebsprotokoll

Verarbeitungsfehler und Verzögerungen verfolgen

Fehler, die gpresult allein nicht zeigt, und Probleme, bei denen die Verarbeitung zu lange dauert, prüfen Sie im GroupPolicy-Betriebsprotokoll der Ereignisanzeige.

Der Ort ist Anwendungs- und Dienstprotokolle > Microsoft > Windows > GroupPolicy > Operational. Der Protokollname ist Microsoft-Windows-GroupPolicy/Operational, und es zeichnet alles vom Beginn bis zum Ende der Verarbeitung, die Listen der angewendeten und verweigerten GPOs sowie die Verweigerungsgründe auf.⁵

Mit ActivityID auf einen einzelnen Verarbeitungsdurchlauf eingrenzen

Jedem Durchlauf der Richtlinienverarbeitung wird eine eindeutige ActivityID zugewiesen. Das von Microsoft dokumentierte Verfahren besteht darin, die ActivityID aus einer Warnung oder einem Fehler im Systemprotokoll aufzunehmen und mit einer benutzerdefinierten Ansicht auf die Ereignisse genau dieses Durchlaufs einzugrenzen. So verfolgen Sie einen Durchlauf von Anfang bis Ende, ohne Datensätze eines anderen zu vermischen.⁵

flowchart TB
    accTitle: Wie Sie das GroupPolicy-Betriebsprotokoll eingrenzen
    accDescr: Jedem Durchlauf der Richtlinienverarbeitung wird im GroupPolicy-Betriebsprotokoll eine eindeutige ActivityID zugewiesen, nehmen Sie die ActivityID daher aus einer Warnung oder einem Fehler im Systemprotokoll auf und grenzen Sie die Lektüre mit einer benutzerdefinierten Ansicht auf die Ereignisse dieses einen Durchlaufs ein
    sys["Warnung oder Fehler im Systemprotokoll"] --> aid["Die ActivityID aufnehmen"]
    aid --> cv["Mit einer benutzerdefinierten Ansicht eingrenzen"]
    cv --> one["Die Ereignisse eines Verarbeitungsdurchlaufs lesen"]
    one -.-> rec["Listen angewendeter und verweigerter GPOs mit Gründen"]

Abbildung 12: Für das Betriebsprotokoll nehmen Sie die ActivityID aus dem Systemprotokoll auf und lesen mit einer benutzerdefinierten Ansicht nur einen Durchlauf der Richtlinienverarbeitung.

5.3. Die Beziehung zu den Policies-Schlüsseln der Registrierung

Richtlinien administrativer Vorlagen, die das nächste Kapitel behandelt, werden am Ende als Registrierungswerte geschrieben. In der Regel werden sie in die folgenden eigenen Richtlinienschlüssel geschrieben.⁶

• HKEY_LOCAL_MACHINE\Software\Policies (Computerkonfiguration; der empfohlene Ort)
• HKEY_CURRENT_USER\Software\Policies (Benutzerkonfiguration; der empfohlene Ort)
• HKLM\Software\Microsoft\Windows\CurrentVersion\Policies und HKCU\Software\Microsoft\Windows\CurrentVersion\Policies

Richtlinienwerte werden vor den eigenen Einstellungen einer App gelesen

Eine richtlinienbewusste App verhält sich so: Sie liest zuerst den Policies-Schlüssel, verwendet diesen Wert, falls einer vorhanden ist, und fällt andernfalls auf die eigene Einstellung oder einen Standardwert zurück. Eine auf „Nicht konfiguriert“ belassene Richtlinie schreibt keinen Wert in die Registrierung.⁶

Mit anderen Worten: Eine administrative Vorlage, die die eigenen Richtlinienschlüssel nutzt, schreibt die eigene Einstellung der App nicht um und hinterlässt kein „Tattoo“; sie legt einen erzwungenen Wert an einem anderen Ort ab. Beenden Sie die Konfiguration, und die App folgt wieder ihrer eigenen Einstellung.

flowchart TB
    accTitle: Rangfolge zwischen einem Richtlinienwert und einer App-Einstellung
    accDescr: Eine richtlinienbewusste App liest zuerst den Policies-Schlüssel und verwendet diesen Wert, falls einer vorhanden ist, andernfalls die eigene Einstellung oder einen Standardwert, und eine auf Nicht konfiguriert belassene Richtlinie schreibt nichts in die Registrierung
    app["Eine richtlinienbewusste App liest eine Einstellung"] --> haspol{"Gibt es einen Wert im Policies-Schlüssel?"}
    haspol -->|Ja| pol["Der Richtlinienwert gewinnt"]
    haspol -->|Nein| pref["Nutzt die eigene Einstellung oder einen Standardwert"]
    notconf["Eine Nicht-konfiguriert-Richtlinie"] -.-> nowrite["Schreibt nichts in die Registrierung"]

Abbildung 13: Eine Richtlinie schreibt die eigene Einstellung der App nicht um; stattdessen wird ein andernorts abgelegter erzwungener Wert mit höherer Priorität gelesen.

Achten Sie auf Einstellungen, die außerhalb der eigenen Schlüssel schreiben und Werte hinterlassen

Nicht jede Richtlinie schreibt in einen eigenen Schlüssel. „Win32-Lange Pfade aktivieren“ schreibt beispielsweise nach LongPathsEnabled unter HKLM\SYSTEM\CurrentControlSet\Control\FileSystem. Ältere und Drittanbieter-Vorlagen enthalten ebenfalls solche, die in beliebige Pfade schreiben.

Einstellungen dieser Art hinterlassen ihren Wert, auch nachdem Sie die Richtlinie nicht mehr konfigurieren. Prüfen Sie anhand der ADMX-Definition, des Erklärungstexts der Einstellung und des gpresult-Berichts, in welchen Schlüssel die Sie betreffende Einstellung schreibt.

Werte, die ein Skript oder Einstellungen für Gruppenrichtlinien außerhalb der eigenen Schlüssel schreiben, sind ebenfalls gewöhnliche Registrierungswerte. Behandeln Sie sie im Gegensatz zu den eigenen Richtlinienschlüsseln als Werte, die nach dem Ende der Konfiguration bleiben.

Prüfen Sie, wohin der Wert tatsächlich geschrieben wurde

Beginnen Sie mit den tatsächlichen Werten unter den Policies-Schlüsseln. Schließen Sie aber nicht daraus, „GPO hat hier keinen Einfluss“, nur weil nichts da ist; prüfen Sie auch, ob die Einstellung zu denen gehört, die außerhalb der eigenen Schlüssel schreiben. Die folgenden Befehle sind ein Beispiel für die Prüfung unter Policies, wo die meisten Richtlinien schreiben.

# Example of checking values distributed by policy directly (most policies write under Policies)
Get-ChildItem "HKLM:\SOFTWARE\Policies" -Recurse | Select-Object Name
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\System" -ErrorAction SilentlyContinue

flowchart TB
    accTitle: Eingrenzungsschritte, wenn eine Einstellung nicht wirksam wird
    accDescr: Prüfen Sie zuerst die angewendeten und verweigerten GPOs im RSoP-Bericht von gpresult, grenzen Sie das GroupPolicy-Betriebsprotokoll bei Bedarf über ActivityID ein und bestätigen Sie die verteilten Werte direkt in den Policies-Schlüsseln der Registrierung
    start["Die Einstellung wird nicht wirksam"] --> rsop["Das RSoP mit gpresult /h prüfen"]
    rsop --> found{"Sehen Sie die Gründe angewendet und verweigert?"}
    found -->|Ja| fix["Zu Rangfolge und Filterung zurückkehren"]
    found -->|Nein| oplog["Das GroupPolicy-Betriebsprotokoll lesen"]
    oplog -.-> aid["Mit ActivityID auf einen Durchlauf eingrenzen"]
    rsop -.-> reg["Die tatsächlichen Werte in den Policies-Schlüsseln prüfen"]

Abbildung 14: Die Eingrenzung geht mechanisch von gpresult /h zum GroupPolicy-Betriebsprotokoll, wenn das nicht reicht, und zur direkten Prüfung der Policies-Schlüssel auf tatsächliche Werte.

6. Administrative Vorlagen (ADMX) und der zentrale Speicher

ADMX enthält die Definitionen, ADML die Anzeigezeichenfolgen

Die unter „Administrative Vorlagen“ in GPMC aufgeführten Elemente haben ihre Einstellungsdefinitionen in ADMX-Dateien und ihre sprachspezifischen Anzeigezeichenfolgen in ADML-Dateien.

Jeder PC hat die mit dem Betriebssystem gelieferten Definitionen in C:\Windows\PolicyDefinitions, und die Verwaltungswerkzeuge lesen sie, um den Einstellungsbildschirm aufzubauen.⁷

In einer Domäne einen gemeinsamen zentralen Speicher referenzieren

Für den Domänenbetrieb legen Sie unter SYSVOL auf einem DC einen Ordner PolicyDefinitions an. Ein Beispiel ist \\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions.

Der Inhalt wird auf jeden DC der Domäne repliziert, und die Gruppenrichtlinienwerkzeuge referenzieren den zentralen Speicher dann standardmäßig. Er existiert, um das Problem unterschiedlicher Vorlagenversionen zwischen Verwaltungsrechnern zu verhindern, sodass die sichtbaren Elemente nicht mehr übereinstimmen. ADML-Dateien gehören in sprachspezifische Unterordner wie ja-JP.⁷

flowchart TB
    accTitle: Wie der zentrale Speicher funktioniert
    accDescr: Das Anlegen eines PolicyDefinitions-Ordners unter SYSVOL auf einem Domänencontroller repliziert seinen Inhalt auf jeden Domänencontroller und lässt die Gruppenrichtlinienwerkzeuge den zentralen Speicher standardmäßig referenzieren, sodass Definitionen zwischen Verwaltungsrechnern nicht mehr voneinander abweichen
    create["Unter SYSVOL anlegen"] --> cs["PolicyDefinitions"]
    cs --> repl["Auf jeden DC repliziert"]
    cs --> ref["GP-Werkzeuge referenzieren ihn standardmäßig"]
    ref -.-> benefit["Definitionsabweichungen zwischen Rechnern verschwinden"]
    cs -.-> adml["ADML-Dateien gehören in sprachspezifische Ordner"]

Abbildung 15: Der PolicyDefinitions-Ordner in SYSVOL wird auf jeden Domänencontroller repliziert, und die Gruppenrichtlinienwerkzeuge referenzieren ihn standardmäßig.

Updates in einem Arbeitsordner vorbereiten und dann umschalten

Microsoft verteilt ADMX-Dateien für neue Windows-Versionen versionsweise. Was Sie aktualisieren, ist der zentrale Speicher. Das Ersetzen von C:\Windows\PolicyDefinitions auf jedem PC durch die heruntergeladene Version wird nicht unterstützt.⁷

Aktualisieren Sie einen bestehenden Speicher über die folgenden Schritte, statt den Produktionsordner direkt zu überschreiben.

1. Legen Sie einen Arbeitsordner mit Versionsnamen an, etwa PolicyDefinitions-24H2.
2. Stellen Sie den vollständigen ADMX-Satz für das Betriebssystem und für Apps wie Office und Edge zusammen.
3. Benennen Sie das aktuelle PolicyDefinitions in etwas wie PolicyDefinitions-23H2 um, um es beiseitezulegen.
4. Benennen Sie den Arbeitsordner in PolicyDefinitions um, damit er als Produktion referenziert wird.⁷

Der referenzierte Ordner ist der mit dem Namen PolicyDefinitions. Dateien einfach in einen versionsbenannten Ordner zu legen, hat keine Wirkung. Den alten Ordner beiseitezuhalten, erlaubt ein Zurückrollen, wenn etwas schiefgeht.⁷

flowchart TB
    accTitle: Schritte zum Aktualisieren des zentralen Speichers
    accDescr: Zum Aktualisieren stellen Sie den vollständigen ADMX-Satz für Betriebssystem und Apps in einem versionsbenannten Arbeitsordner zusammen, benennen den aktuellen Ordner um und legen ihn beiseite, benennen dann den Arbeitsordner in den Produktionsnamen PolicyDefinitions um und rollen bei einem Problem zum beiseitegelegten Ordner zurück
    work["Versionsbenannter Arbeitsordner"] --> gather["OS- und App-Sätze zusammenstellen"]
    gather --> evac["Den aktuellen umbenennen und beiseitelegen"]
    evac --> rename["Den Arbeitsordner in den Produktionsnamen umbenennen"]
    rename --> live["Als Produktion referenziert"]
    live -.-> back["Bei Problemen zum alten Ordner zurückrollen"]

Abbildung 16: Für ein Update stellen Sie den vollständigen Satz in einem Arbeitsordner zusammen, legen den aktuellen beiseite und heben durch Umbenennen in die Produktion.

7. GPO gegenüber Intune (MDM/CSP) gegenüber manueller und Skriptverteilung — eine Entscheidungstabelle

GPO ist nicht mehr die einzige Option für die Konfigurationsverwaltung von Windows-Geräten. MDM, dessen Vertreter Intune ist, konfiguriert Betriebssystemeinstellungen über einen Mechanismus namens CSP (Configuration Service Provider). Hier ist eine Entscheidungstabelle, um zu wählen, worum Sie aufbauen.

Anhand der Identitätsgrundlage des Geräts und des Standorts entscheiden

Die Grundlage ist ob das Gerät auf AD oder auf Microsoft Entra aufbaut und wo es eingesetzt wird. GPO ist zuverlässig für stationäre Büro-PCs, die mit einem lokalen AD domänenverbunden sind, während Domänen-GPOs einen Entra-verbundenen Mobil-PC nie erreichen.

Wichtig ist, Geräte im Büro und außer Haus nicht als dieselben Erreichbarkeitsbedingungen zu behandeln.

In einer hybriden Umgebung festlegen, wer jede Einstellung besitzt

Auch in kleinen und mittleren Unternehmen ist der hybride Betrieb üblich, der Domänenbeitritt mit Intune-Registrierung kombiniert. Was Sie hier vermeiden wollen, ist, dieselbe Einstellung über GPO und MDM zu konfigurieren.

Policy CSP enthält MDMWinsOverGP, das MDM bei einem Konflikt den Vorrang gibt. Es gilt jedoch nur für die entsprechenden Richtlinien innerhalb von Policy CSP. Konfigurieren Sie eine Einstellung, die nicht unter dieser Steuerung steht, doppelt, gibt es keine Garantie, welche gewinnt. Microsoft rät ebenfalls von doppelter Konfiguration ab.⁸

Der Grundsatz ist, „dieser Bereich ist GPO, jener Bereich ist Intune“ festzulegen und jeden Bereich einem der beiden zu übergeben.

flowchart TB
    accTitle: Die Wahl zwischen GPO und Intune
    accDescr: GPO eignet sich für Geräte, deren Identitätsgrundlage das lokale AD ist und die im Büro bleiben, Intune eignet sich für Entra-verbundene und außer-Haus-Geräte, und in einer hybriden Umgebung vermeiden Sie, dieselbe Einstellung doppelt zu konfigurieren, und übergeben jeden Einstellungsbereich einer Seite
    q{"Identitätsgrundlage und Standort?"}
    q -->|AD-verbunden und im Büro| gpo["GPO ist zuverlässig und fein granular"]
    q -->|Entra-verbunden oder außer Haus| intune["Intune erreicht Geräte außer Haus"]
    q -->|Hybrid| split["Jeden Bereich einer Seite übergeben"]
    split -.-> warn["Doppelte Konfiguration hat kein garantiertes Ergebnis"]
    split -.-> ana["Mit Group Policy analytics sortieren"]

Abbildung 17: Wählen Sie anhand der Identitätsgrundlage des Geräts und des Standorts, und konfigurieren Sie in einer hybriden Umgebung dieselbe Einstellung nicht über GPO und MDM.

Mit Group Policy analytics vor dem Umzug sortieren

Der Einstieg, um eine Migration zu erwägen, ist Group Policy analytics in Intune. Importieren Sie als XML aus GPMC exportierte GPOs, und es analysiert Einstellung für Einstellung, was MDM unterstützt, was veraltet ist und was nicht unterstützt werden kann. Unterstützte Einstellungen können in eine Einstellungskatalog-Richtlinie von Intune migriert werden.⁹

Nutzen Sie es nicht als „ein Werkzeug, das alles verschiebt“, sondern als ein Werkzeug, um zu sortieren, was verschoben werden kann, was nicht und was Sie aufgeben.

Die Zuständigkeit für die Windows-Update-Verwaltung wird im selben Zusammenhang neu geordnet. Siehe auch „Windows Update-Verwaltung nach der WSUS-Abschaffung“.

flowchart TB
    accTitle: Sortieren mit Group Policy analytics
    accDescr: Das Importieren von als XML aus GPMC exportierten GPOs in Group Policy analytics sortiert jede Einstellung danach, ob MDM sie unterstützt oder ob sie veraltet oder nicht unterstützt ist, und unterstützte Einstellungen können in eine Einstellungskatalog-Richtlinie migriert werden
    exp["Als XML aus GPMC exportieren"] --> imp["In analytics importieren"]
    imp --> ana["Unterstützung je Einstellung analysieren"]
    ana --> ok["Von MDM unterstützt"]
    ana --> dep["Veraltet oder nicht unterstützt"]
    ok --> mig["In eine Einstellungskatalog-Richtlinie migrieren"]

Abbildung 18: Group Policy analytics importiert exportierte GPOs und trennt die Einstellungen, die nach MDM wandern können, von denen, die es nicht können.

8. Stolpersteine aus Entwicklersicht — die GPO des Kunden ändert, wie Ihre App sich verhält

Zum Schluss, was aus der Position der Custom Software Development festzuhalten ist. Die GPOs des Kunden schreiben still die Annahmen um, von denen Ihre App abhängt. Neben Firewalls und Antivirus ist GPO ein regelmäßiger Verdächtiger hinter „es läuft auf dem Entwicklungsrechner, aber nicht beim Kunden“. Hier sind Beispiele aus der Praxis.

Die PowerShell-Ausführungsrichtlinie

Die Ausführungsrichtlinie lässt sich zentral über GPO konfigurieren, und die Bereiche MachinePolicy und UserPolicy, die von der GPO kommen, haben immer Vorrang vor lokal oder pro Prozess gesetzten Werten.¹⁰ Ist ein Installationsprogramm oder ein Betriebsskript auf der Annahme gebaut, „mit -ExecutionPolicy Bypass sollte es laufen“, startet es unter GPO-Verwaltung nicht einmal. Details siehe „PowerShell-Ausführungsrichtlinien und Skriptsignatur“.

Zusammenführen lokaler Firewallregeln ausgeschaltet

In Umgebungen, in denen die Firewall zentral über GPO oder Intune verwaltet wird, kann das Zusammenführen lokaler Regeln (AllowLocalPolicyMerge) pro Profil ausgeschaltet werden. Wo es aus ist, existieren eingehende Regeln, die ein Installationsprogramm lokal registriert hat, werden aber nicht angewendet.¹¹ Das ist ein Punkt, den Sie vor der Bereitstellung einer serverartigen App unbedingt prüfen, und er wird ausführlich in „Windows-Firewall und Fachanwendungen“ behandelt.

Laufwerkszuordnungen, Proxys und andere Umgebungskonfiguration

Netzwerklaufwerkszuordnungen, Drucker und Ähnliches werden typischerweise über Einstellungen für Gruppenrichtlinien verteilt.¹⁶ Umgebungsannahmen wie „es sollte ein Z-Laufwerk geben“ oder „der Proxy sollte eine Direktverbindung sein“ zerfallen je nachdem, welcher Benutzer sich anmeldet und zu welcher OU der PC gehört. Ein weiteres, das residente Apps leicht übersehen: Über die Benutzerkonfiguration verteilte Einstellungen werden naturgemäß nicht auf die Konten angewendet, unter denen Dienste und geplante Aufgaben laufen.

Die Einstellung lässt sich von vornherein nicht zurückändern

Einstellungen aus administrativen Vorlagen werden für den Benutzer in der Regel in der Benutzeroberfläche nicht mehr änderbar; das Element ist ausgegraut. Dass „es behoben ist, wenn Sie den Kunden die Einstellung ändern lassen“ nicht funktioniert, hat Folgen dafür, wie Sie den Reaktionsplan entwerfen.

flowchart TB
    accTitle: Die Annahmen, die eine Kunden-GPO ändert
    accDescr: Die GPOs eines Kunden ändern die Annahmen einer App, indem sie die Ausführungsrichtlinie erzwingen, das Zusammenführen lokaler Firewallregeln ausschalten, Laufwerkszuordnungen und Proxyeinstellungen verteilen und den Benutzer daran hindern, Einstellungen zurückzuändern, was ein Grund ist, warum eine App nur beim Kunden fehlschlägt
    gpo["Die GPOs des Kunden"] --> ep["Ausführungsrichtlinie erzwungen"]
    gpo --> fw["Zusammenführen lokaler Regeln aus"]
    gpo --> env["Laufwerks- und Proxyverteilung"]
    gpo --> lock["Einstellungen lassen sich nicht zurückändern"]
    ep --> sym["Ein Grund, warum es nur beim Kunden fehlschlägt"]
    fw --> sym
    env --> sym
    lock --> sym

Abbildung 19: Die GPOs des Kunden schreiben still die Annahmen einer App um, einschließlich Ausführungsrichtlinie, Firewall und Umgebungskonfiguration.

Im Voraus festlegen, was Entwickler vor der Bereitstellung und bei einem Vorfall prüfen

Es gibt drei Vorbereitungen.

Wo die Grenze bei Rechten zu ziehen ist, behandelt „Wann sind unter Windows tatsächlich Administratorrechte nötig?“. GPO ist nicht Ihr Feind; sie ist Teil der Umgebungsspezifikation. Behandeln Sie sie als Spezifikation und stimmen Sie die zu bestätigenden Punkte mit dem Administrator ab, dann kann die Eingrenzung mechanisch voranschreiten.

flowchart TB
    accTitle: Die drei Vorbereitungen auf der Entwicklungsseite
    accDescr: Die drei Vorbereitungen auf der Entwicklungsseite sind, die Umgebungsannahmen, von denen die App abhängt, als Bereitstellungsanforderungen zu dokumentieren und die IT des Kunden vor der Bereitstellung um Bestätigung zu bitten, bei Störungen den gpresult-Bericht und die tatsächlichen Werte in den Policies-Schlüsseln zu prüfen und zur Entwurfszeit die Verarbeitung zu trennen, die Administratorrechte braucht
    dev["Vorbereitung auf der Entwicklungsseite"] --> doc["1. Die Umgebungsannahmen dokumentieren"]
    dev --> chk["2. Mit gpresult und tatsächlichen Werten bestätigen"]
    dev --> priv["3. Rechtebedarf im Entwurf trennen"]
    doc -.-> ask["Die IT des Kunden vor der Bereitstellung fragen"]

Abbildung 20: Die drei Vorbereitungen auf der Entwicklungsseite sind das Dokumentieren der Umgebungsannahmen, das Bestätigen mit gpresult und tatsächlichen Werten sowie das Trennen des Bedarfs an Administratorrechten im Entwurf.

9. Zusammenfassung

• Gruppenrichtlinien sind ein Mechanismus, der Einstellungen pro GPO in der Reihenfolge lokal, Standort, Domäne, OU (LSDOU) verarbeitet, und Konflikte entscheidet zuletzt geschrieben gewinnt. Die GPO der dem Ziel nächsten OU ist die stärkste und die lokale GPO die schwächste Ebene.
• Vererbung deaktivieren, Erzwungen und Sicherheitsfilterung steuern den Standardablauf. Erzwungen schlägt auch Vererbung deaktivieren, daher nicht übermäßig einsetzen.
• Die Anwendung hat zwei Formen: Vordergrundverarbeitung beim Start und bei der Anmeldung sowie eine Hintergrundaktualisierung in einem Standardintervall von rund 90 Minuten plus einem zufälligen Versatz. gpupdate /force wendet jede Einstellung erneut an und hat keine Wirkung auf Einstellungen, die nur bei Anmeldung oder Neustart verarbeitet werden.
• Wird eine Einstellung nicht wirksam, grenzen Sie mechanisch in der Reihenfolge gpresult /h, dann das GroupPolicy-Betriebsprotokoll, dann die Policies-Schlüssel der Registrierung ein. Verweigerte GPOs kommen mit einem Grund.
• Definitionen administrativer Vorlagen leben in ADMX- und ADML-Dateien und werden in einer Domäne im zentralen Speicher in SYSVOL zusammengeführt. Zum Aktualisieren tauschen Sie die Seite des zentralen Speichers aus, statt das lokale PolicyDefinitions zu ersetzen.
• Entscheiden Sie zwischen GPO und Intune anhand der Identitätsgrundlage des Geräts und des Standorts, und vermeiden Sie in einer hybriden Umgebung, dieselbe Einstellung doppelt zu konfigurieren, und übergeben Sie jeden Bereich einem Besitzer. Group Policy analytics ist nützlich, um eine Migration zu sortieren.
• Für Entwickler sind die GPOs des Kunden Teil der Umgebungsspezifikation. Dokumentieren Sie die Annahmen wie Ausführungsrichtlinie, Firewall sowie Laufwerks- und Proxykonfiguration und bauen Sie die Praxis auf, sie mit gpresult zu bestätigen, dann hören die meisten Fälle von „es schlägt nur beim Kunden fehl“ auf, beängstigend zu sein.

Verwandte Artikel

• Windows-Firewall und Fachanwendungen — Eingehende Regeln über das Installationsprogramm registrieren
• Windows Update-Verwaltung nach der WSUS-Abschaffung — Wie Sie zwischen WUfB, Autopatch und Intune wählen
• PowerShell-Ausführungsrichtlinien und Skriptsignatur — Ein praktischer Leitfaden zum Abschied vom „Zudecken mit Bypass“
• PC-Kitting mit winget + PowerShell automatisieren — Aus dem Handbuch ein ausführbares Skript machen
• Leitfaden zum Ausstieg aus der Abhängigkeit vom IE-Modus
• Wann sind unter Windows tatsächlich Administratorrechte nötig? - UAC, geschützte Bereiche und wie man es am Design erkennt

Verwandte Beratungsfelder

KomuraSoft LLC übernimmt die Ursachenuntersuchung, wenn eine Fachanwendung in einer Kundenumgebung unter GPO-Verwaltung fehlschlägt, das Ordnen von Bereitstellungsanforderungen wie Ausführungsrichtlinie, Firewall und Netzwerkannahmen sowie technische Beratung zu Richtlinieninventaren und Intune-Koexistenzstrategie für IT-Personal, das eine AD-Umgebung übernommen hat. Mit etwas wie „lesen Sie diesen gpresult-Bericht mit mir“ zu beginnen, ist völlig in Ordnung.

• Technische Beratung und Design-Review
• Fehleruntersuchung und Ursachenanalyse
• Windows-Anwendungsentwicklung
• Kontakt

Quellen

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Ich habe gpupdate /force ausgeführt, aber die Einstellung wird trotzdem nicht wirksam. Woran liegt das?

Prüfen Sie zunächst, ob es sich um eine Einstellungsart handelt, die eine Hintergrundaktualisierung nie anwendet. Softwareinstallationen und Ordnerumleitungen für Benutzer werden nur bei der Anmeldung verarbeitet, Softwareinstallationen für Computer nur beim Start, sodass nach dem Abschluss von gpupdate eine Abmeldung (/logoff) oder ein Neustart (/boot) nötig ist. Als Nächstes erzeugen Sie mit gpresult /h einen RSoP-Bericht und prüfen, ob die betreffende GPO in der Liste der angewendeten GPOs erscheint und ob sie in der Liste der verweigerten GPOs mit einer Begründung auftaucht. Wird sie angewendet, ändert sich das Verhalten aber trotzdem nicht, sollten Sie vermuten, dass eine andere GPO mit höherer Priorität dieselbe Einstellung überschreibt (zuletzt geschrieben gewinnt). Der Bericht zeigt zu jeder Einstellung die gewinnende GPO an, sodass Sie genau bestimmen können, welche GPO sich durchsetzt.

Was bedeutet „Verweigert (Filterung)“ in einem gpresult-Bericht?

Das bedeutet, dass die GPO dem Verknüpfungsort nach im Geltungsbereich liegt, die Filterung sie aber von der Anwendung ausgeschlossen hat. Die häufigste Ursache ist die Sicherheitsfilterung: Damit eine GPO angewendet wird, müssen der Benutzer oder der Computer für diese GPO sowohl die Berechtigung Lesen als auch Gruppenrichtlinie übernehmen besitzen. Standardmäßig werden beide Berechtigungen den Authentifizierten Benutzern gewährt; wenn Sie sie auf bestimmte Gruppen einschränken, führt eine fehlende Gruppenmitgliedschaft oder ein vergessenes Computerkonto zu einer Verweigerung. Bei benutzerbezogenen GPOs reicht es nicht, dem Zielbenutzer beide Berechtigungen zu erteilen. Seit MS16-072 wird die Benutzerrichtlinie im Sicherheitskontext des Computers abgerufen, sodass Lesen (Übernehmen ist nicht nötig) für Authentifizierte Benutzer oder Domänencomputer erhalten bleiben muss. Weitere Ursachen sind ein WMI-Filter, dessen Bedingung nicht zutrifft, oder dass die Benutzer- bzw. Computerseite der GPO deaktiviert ist. Der Grund für die Verweigerung wird sowohl im gpresult-Bericht als auch im GroupPolicy-Betriebsprotokoll festgehalten.

Sollte ich Geräte mit GPO oder mit Intune verwalten?

Die Grundregel ist, sich an der Identitätsgrundlage des Geräts zu orientieren. Sind die Geräte überwiegend mit einem lokalen AD domänenverbunden und dauerhaft mit dem internen Netzwerk verbunden, ist GPO die zuverlässigste und feinkörnigste Option. Nehmen Microsoft-Entra-verbundene Geräte oder Homeoffice-Rechner zu, die nie einen Domänencontroller erreichen, eignet sich Intune (MDM/CSP) besser, weil es Konfigurationen auch außerhalb des Firmennetzes zustellt. In einer hybriden Umgebung, in der beide nebeneinander bestehen, führt das Konfigurieren derselben Einstellung über GPO und MDM gleichzeitig zu einem Konflikt ohne garantiertes Ergebnis. Der Grundsatz lautet daher, pro Einstellungsbereich festzulegen, welches der beiden Systeme zuständig ist, und sich darauf festzulegen. Sobald Sie eine Migration erwägen, können Sie mit Group Policy analytics in Intune Ihre bestehenden GPOs importieren und Einstellungen, die MDM bereits unterstützt, von nicht unterstützten oder als veraltet markierten Einstellungen trennen.

Eine Einstellung, die ich im Editor für lokale Gruppenrichtlinien (gpedit.msc) vorgenommen habe, wird von der Domäneneinstellung überschrieben. Ist das so vorgesehen?

Ja, das ist so vorgesehen. Gruppenrichtlinien werden in der Reihenfolge lokal, Standort, Domäne, OU (LSDOU) verarbeitet, und bei einem Konflikt gewinnt die zuletzt verarbeitete GPO, wodurch die lokale GPO die schwächste Ebene ist. Konfiguriert eine Domänen-GPO dieselbe Einstellung, wird Ihre lokale Änderung immer überschrieben. Umgekehrt bleibt der Wert der lokalen GPO wirksam, wenn die Domänenseite diese Einstellung auf Nicht konfiguriert belässt. Selbst wenn Sie für einen Test unbedingt der lokalen Einstellung den Vorrang geben möchten, gibt es auf einem domänenverbundenen PC keine Möglichkeit, diese Rangfolge umzukehren. Realistische Ansätze sind, eine Test-OU anzulegen und die Domänen-GPO dort anzupassen, oder einen nicht domänenverbundenen Testrechner zu verwenden.

Die von uns entwickelte Fachanwendung schlägt nur in der Kundenumgebung fehl. Gibt es eine Möglichkeit zu prüfen, ob GPO die Ursache ist?

Der erste Schritt ist, den Administrator des Kunden zu bitten, auf dem betroffenen PC aus einer erhöhten Eingabeaufforderung gpresult /h report.html auszuführen und den RSoP-Bericht durchzusehen. Achten Sie auf Einstellungen, die das Verhalten der App verändern: durch die Ausführungsrichtlinie blockierte Skripte, deaktiviertes Zusammenführen lokaler Firewallregeln oder konfigurierte Proxy- und Laufwerkszuordnungen. Zusätzlich hilft es zu prüfen, ob unter HKLM\Software\Policies und HKCU\Software\Policies in der Registrierung Richtlinienwerte für das betreffende Produkt geschrieben wurden — so lassen sich erzwungene Einstellungen aus administrativen Vorlagen mechanisch aufspüren. Auf der Entwicklungsseite besteht die Vorbereitung darin, die Annahmen, von denen die App abhängt, etwa die Ausführungsrichtlinie, Eingangsports und Schreibordner, in der Bereitstellungsanleitung zu dokumentieren und vor der Bereitstellung von der IT des Kunden bestätigen zu lassen.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.