# Group Policy: Verarbeitung, Scoping und Fit

> Wie GPOs verarbeitet werden (LSDOU, Präzedenz, Vererbung), wie du sie sauber scopest (Security-Filtering, Loopback) und wann Group Policy das falsche Werkzeug ist.

Track: [Active Directory](https://physar.tech/learn/active-directory)  
Kanonische Fassung: https://physar.tech/learn/active-directory/group-policy  
Stand: 2026-07-26  
Interaktiver Teil: 7 Checks (nur im Browser)

## Group Policy: Verarbeitung, Scoping und Fit

### Verarbeitungsreihenfolge: L → S → D → OU

Ein Client zieht bei Anmeldung/Start **nicht** eine einzelne GPO, sondern alle verknüpften GPOs — und wendet sie in einer festen Reihenfolge an: **Local → Site → Domain → OU** (Merkwort **LSDOU**). Innerhalb einer Ebene mit mehreren Links entscheidet die **Link-Order** (niedrigste Nummer zuletzt/oben).

Der Kern ist ein simples Prinzip: **Zuletzt angewandt gewinnt.** OUs werden zuletzt und von oben nach unten durchlaufen, also setzt sich bei einem Konflikt die **nächstgelegene OU** durch — die dem Objekt am nächsten verknüpfte GPO überschreibt weiter oben gesetzte Werte.

_[Abbildung: Die vier Ebenen werden von oben nach unten angewandt; die nächstgelegene OU wird zuletzt verarbeitet und gewinnt bei Konflikten — außer „Enforced“ kehrt das um.]_

> **Merksatz:** Nur **konfliktäre** Einstellungen werden überschrieben. Nicht kollidierende Einstellungen aus allen Ebenen **akkumulieren** — das Ergebnis ist die Summe (Resultant Set of Policy), nicht nur die letzte GPO.

### Vererbung: Block Inheritance vs. Enforced

Zwei Schalter greifen in die LSDOU-Präzedenz ein — und ihr Zusammenspiel wird oft falsch erinnert:

|  |  |
| --- | --- |
| **Block Inheritance** | auf einer **OU** gesetzt: blockt alle von oben (Site/Domain/übergeordnete OU) geerbten GPOs für diese OU und darunter. Ein Werkzeug der OU, die sich abschottet. |
| **Enforced** | auf einem **GPO-Link** gesetzt: erzwingt diese GPO nach unten. Sie durchdringt jedes `Block Inheritance` und **gewinnt** zusätzlich gegen konfliktäre Einstellungen näherliegender GPOs — sie kehrt die normale Präzedenz um. |

> **Kernregel:** **Enforced schlägt Block Inheritance.** Setzt eine höhere Ebene (z. B. eine Domain-GPO mit Sicherheitsbaseline) `Enforced`, hilft `Block Inheritance` auf der Ziel-OU **nicht** — die erzwungene Einstellung greift trotzdem. So stellen Sicherheitsteams sicher, dass Baselines nicht lokal abgeschaltet werden.

### Security-Filtering: Apply UND Read — im Computer-Kontext

Eine GPO gilt zunächst für **Authenticated Users**. Mit **Security-Filtering** schränkst du das auf eine Security-Gruppe ein: das Ziel braucht dann zwei ACL-Rechte auf der GPO — **`Read`** UND **`Apply group policy`**. Fehlt eines, wird die GPO nicht wirksam.

Der Fallstrick: GPOs werden im **Sicherheitskontext des Computerkontos** abgerufen — auch **benutzerbezogene** GPOs. Filterst du nur auf eine **Benutzer**-Gruppe und entfernst `Authenticated Users` komplett, kann das **Computerkonto die GPO nicht mehr lesen** — und sie wird still nicht angewandt.

> **Betriebsregel:** Beim Filtern das **Leserecht** für die Computer sichern: entweder `Authenticated Users` mit **nur `Read`** (ohne `Apply`) belassen oder `Domain Computers` mit `Read` ergänzen. `Apply` bleibt auf der gefilterten Zielgruppe. So bleibt das Scoping eng, ohne den Abruf zu brechen.

### Loopback: Benutzereinstellungen nach dem Rechner

Normalerweise kommen Benutzereinstellungen aus den GPOs der **User-OU** — egal, an welchem Rechner sich jemand anmeldet. Auf geteilten Maschinen (Terminalserver/RDS, Kioske, Konferenzräume) willst du das oft umkehren: die Benutzererfahrung soll sich nach dem **Computer** richten, nicht nach der Person.

Genau das leistet **Loopback-Verarbeitung** — eine Computer-Einstellung. Sie wertet die **Benutzer**seite der GPOs aus, die an der **Computer**-OU hängen. Zwei Modi:

|  |  |
| --- | --- |
| **Replace** | die normalen User-GPOs werden **ignoriert**; nur die Benutzereinstellungen der Computer-OU gelten. Für streng standardisierte Kiosk-/RDS-Umgebungen. |
| **Merge** | erst die normalen User-GPOs, **dann** die der Computer-OU obendrauf — letztere gewinnen bei Konflikten. Für „normale Einstellungen plus rechnerspezifische Overrides“. |

> **Merksatz:** Ohne Loopback bringt es **nichts**, eine User-GPO an eine Computer-OU zu verknüpfen — die Benutzerseite einer GPO wird nie über die Computer-OU ausgewertet, außer Loopback ist aktiv.

### Policy vs. Preference vs. externes Config-Management

Group Policy hat zwei Hälften mit unterschiedlichem Verhalten — plus eine Grenze, ab der ein anderes Werkzeug passt:

|  |  |
| --- | --- |
| **Policy (Administrative Templates)** | **erzwungen** und nicht vom Nutzer änderbar; bei jedem Refresh neu durchgesetzt, driftet also nicht. Wird die GPO entfernt, verschwindet die Einstellung wieder. Für Sicherheits- und Compliance-Vorgaben. |
| **Preference (GPP)** | setzt einen **Ausgangswert**, den der Nutzer danach **ändern darf** (z. B. Laufwerks-/Druckerzuordnung, Verknüpfungen, Registry-Defaults). Optionen wie „apply once“ oder Item-Level-Targeting. Für Komfort-Defaults, nicht für Erzwingung. |
| **Externes Config-Mgmt / DSC** | idempotenter, versionierter **Desired State** für komplexe Serverkonfiguration. Wenn GPP-Logik zum Skript-Wildwuchs wird, ist die Grenze erreicht. |

> **Fit-Regel:** Frage nicht „geht das mit GPO?“, sondern „darf der Nutzer es **ändern**?“. Änderbar → Preference. Erzwungen und driftfrei → Policy. Komplexer, testbarer Server-State → externes Config-Mgmt.

### Performance: die Anmeldung nicht zubauen

Jede angewandte GPO kostet Verarbeitungszeit bei Anmeldung und Start. Zwei Dinge treiben langsame Logons besonders: **zu viele GPOs** (jede wird gelesen und ausgewertet) und **WMI-Filter**.

Ein **WMI-Filter** ist eine Abfrage, die pro GPO **bei jedem Verarbeitungszyklus neu ausgewertet** wird — noch bevor feststeht, ob die GPO überhaupt gilt. Teure oder viele WMI-Abfragen summieren sich zu spürbarer Verzögerung.

> **Betriebsregel:** Zuerst **konsolidieren** (weniger, klarere GPOs) und WMI-Filter durch **OU-Struktur oder Security-Group-Targeting** ersetzen — das Zielobjekt wird einmalig ausgewertet statt bei jedem Refresh. Das Refresh-Intervall hochzusetzen versteckt nur das Symptom.

### Zusammenfassung — gleich im Check

Du kennst jetzt die Achsen: **LSDOU-Präzedenz** (nächste OU gewinnt), **Enforced vs. Block Inheritance**, **Security-Filtering** (Apply + Read, Computer-Kontext), **Loopback** (merge/replace), **Policy vs. Preference vs. Config-Mgmt** und **GPO-Performance**.

> **Gleich im Check:** In den nächsten Entscheidungen wählst du für konkrete Ops-Situationen selbst — und siehst pro Option, **warum** sie trägt oder aus welchem konkreten Grund nicht.

## Quellen

- Microsoft Learn — Group Policy processing and precedence (LSDOU, Link-Order)
- Microsoft Learn — Managing inheritance of Group Policy (Block Inheritance, Enforced)
- Microsoft Learn — Filter the scope of a GPO (Security Filtering: Read + Apply group policy)
- Microsoft Support KB3159398 / MS16-072 — GPO retrieval in the computer security context (computer account needs Read)
- Microsoft Learn — Configure user Group Policy loopback processing mode (Merge/Replace)
- Microsoft Learn — Group Policy Preferences overview (Preferences vs. Policies)
- Microsoft Learn — Group Policy WMI filtering and processing performance considerations
- Microsoft Learn — Group Policy processing and precedence (LSDOU)
- Microsoft Learn — Group Policy inheritance and link order
- Microsoft Learn — Managing inheritance of Group Policy (Enforced, Block Inheritance)
- Microsoft Learn — Group Policy processing and precedence
- Microsoft Learn — Filter the scope of a GPO (Read + Apply group policy required)
- Microsoft Support KB3159398 / MS16-072 — GPOs retrieved in the computer security context; computer account needs Read
- Microsoft Learn — Loopback processing for Remote Desktop Session Hosts / shared computers
- Microsoft Learn — Group Policy Preferences overview (Preferences vs. Policies, Item-Level Targeting)
- Microsoft Learn — Configure a mapped drive item (Drive Maps preference)
- Microsoft Learn — Filter the scope of a GPO (Security Filtering as alternative to WMI targeting)
- learn.microsoft.com/en-ca/troubleshoot/windows…bleshooting-guidance — https://learn.microsoft.com/en-ca/troubleshoot/windows-server/group-policy/applying-group-policy-troubleshooting-guidance
- learn.microsoft.com/en-us/windows-server/admin…ws-commands/gpresult — https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/gpresult