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

„Diese Einstellung wird per GPO verteilt“, „die PCs beim Kunden sind durch Gruppenrichtlinien eingeschränkt“ — wer mit Windows-Fachanwendungen zu tun hat, hört das Wort „GPO“ ständig fallen. Doch sobald es darum geht, selbst die AD-Administration zu übernehmen oder eine App auf einem domänenverbundenen PC beim Kunden zu installieren, können erstaunlich wenige Menschen genau erklären, wann, von wo und in welcher Rangfolge Gruppenrichtlinien angewendet werden.

„Ich habe die Einstellung geändert, aber sie wirkt nicht“, „man hat mir gesagt, ich soll gpupdate ausführen, aber ich weiß nicht, was das eigentlich tut“, „die App läuft auf dem Entwicklungsrechner, aber nicht beim Kunden, und es stellte sich heraus, dass es an der GPO lag“ — dieser Artikel richtet sich an Entwickler von Fachanwendungen, die in solche Situationen geraten, sowie an IT-Verantwortliche kleiner und mittlerer Unternehmen, die eine AD-Umgebung übernommen haben. Er ordnet, gestützt auf Primärquellen zum Stand August 2026, die Funktionsweise von Gruppenrichtlinien (die LSDOU-Anwendungsreihenfolge), den Zeitpunkt der Anwendung, die Fehlersuche mit gpresult und dem Ereignisprotokoll, ADMX und den zentralen Speicher sowie die Abgrenzung zu Intune (MDM).

1. Das Wichtigste zuerst

• Gruppenrichtlinien folgen dem Prinzip „zuletzt gewinnt“. Sie werden in der Reihenfolge Lokal → Standort → Domäne → OU (LSDOU) verarbeitet, und bei einem Konflikt setzt sich die zuletzt verarbeitete GPO durch. Die lokale GPO (gpedit.msc) ist die schwächste Ebene.¹
• Die Anwendung erfolgt „im Vordergrund und im Hintergrund“. Die Computerkonfiguration wird immer beim Start angewendet, die Benutzerkonfiguration immer bei der Anmeldung; zusätzlich erfolgt standardmäßig eine Hintergrundaktualisierung alle rund 90 Minuten plus einem zufälligen Versatz von 0 bis 30 Minuten (auf Domänencontrollern alle 5 Minuten).²
• gpupdate /force bedeutet „alle Einstellungen erneut anwenden“ — es ist kein Allheilmittel. Manche Einstellungen, etwa Softwareinstallationen oder Ordnerumleitungen, werden nur bei der Anmeldung oder beim Neustart verarbeitet (genau dafür gibt es die Optionen /logoff und /boot).³
• Ausgangspunkt der Fehlersuche ist der RSoP-Bericht von gpresult /h. Er zeigt sowohl angewendete als auch verweigerte GPOs mit Begründung. Für eine tiefere Untersuchung dient das GroupPolicy-Betriebsprotokoll (Microsoft-Windows-GroupPolicy/Operational).⁴⁵
• Richtlinien aus administrativen Vorlagen werden grundsätzlich in die dafür vorgesehenen Registrierungsschlüssel (Software\Policies u. Ä.) geschrieben. Der Richtlinienwert hat Vorrang vor der eigenen Einstellung der App, und „Nicht konfiguriert“ schreibt nichts. Einige wenige Richtlinien schreiben jedoch außerhalb dieser dedizierten Schlüssel (Abschnitt 5).⁶
• Der zentrale ADMX-Speicher ist der PolicyDefinitions-Ordner in SYSVOL. Legen Sie ihn an, beginnt GPMC, die domänenweiten Vorlagendefinitionen von dort zu beziehen.⁷
• Ob GPO oder Intune, entscheidet die Identitätsgrundlage des Geräts. Konfigurieren Sie dieselbe Einstellung über beide Wege, ist das Ergebnis nicht garantiert. Für die Migrationsplanung eignet sich Group Policy analytics.⁸⁹
• Für Entwickler ist die GPO beim Kunden ein klassischer Grund dafür, dass eine App „nur dort“ nicht läuft. Ausführungsrichtlinie, deaktiviertes lokales Regel-Merging der Firewall, Proxy- und Laufwerkskonfiguration und Ähnliches — Einstellungen, die die Grundannahmen Ihrer App verändern, werden zentral verteilt.¹⁰¹¹

2. Was Gruppenrichtlinien sind ── Lokale GPOs und Domänen-GPOs

Gruppenrichtlinien sind ein Mechanismus, mit dem ein Administrator Windows-Einstellungen zentral definiert und sie den betroffenen Computern und Benutzern zwingend auferlegt. Ein Bündel von Einstellungen heißt GPO (Gruppenrichtlinienobjekt). Für eine GPO gibt es zwei Ablageorte.

Ein PC in einer Arbeitsgruppe (nicht domänenverbunden) verarbeitet nur die lokale GPO.¹ Wenn also in der Praxis von einem „per GPO verwalteten“ Gerät die Rede ist, ist damit fast immer eine Domänen-GPO gemeint.

Jede GPO gliedert sich inhaltlich grob in zwei Bereiche.

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

Die Achse „an den PC oder an die Person gebunden“ zieht sich konsequent durch die spätere Anwendungsreihenfolge wie auch durch die Überprüfung der Anwendung. Manche Einstellungen existieren in beiden Konfigurationen, gewöhnen Sie sich also an, bei der Suche nach einer Einstellung immer beide Bereiche zu prüfen.

3. Wie die Anwendung funktioniert ── LSDOU, „zuletzt gewinnt“ und die Steuerung der Vererbung

3.1. LSDOU: Lokal → Standort → Domäne → OU

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

1. Lokale GPO
2. Mit dem Standort verknüpfte GPOs
3. Mit der Domäne verknüpfte GPOs
4. Mit einer OU (Organisationseinheit) verknüpfte GPOs ── verarbeitet von der obersten OU abwärts, wobei zuletzt die GPO der OU verarbeitet wird, in der der betroffene Computer bzw. Benutzer direkt Mitglied ist

Nach den Anfangsbuchstaben wird diese Reihenfolge LSDOU genannt. Entscheidend ist, dass dies nicht „die Reihenfolge nach absteigender Priorität“ ist, sondern die Reihenfolge, in der verarbeitet wird. Konfigurieren mehrere GPOs dieselbe Einstellung, gewinnt die zuletzt verarbeitete GPO (nicht widersprüchliche Einstellungen werden einfach addiert).¹ Mit anderen Worten: Die GPO der dem Ziel am nächsten liegenden OU ist am stärksten, die lokale GPO am schwächsten. Dass sich eine in gpedit.msc vorgenommene Korrektur wieder zurücksetzt, ist kein Defekt, sondern genau dieses Verhalten laut Spezifikation.

Sind mehrere GPOs mit demselben Standort, derselben Domäne oder derselben OU verknüpft, entscheidet die Verknüpfungsreihenfolge auf der Registerkarte „Verknüpfte Gruppenrichtlinienobjekte“ von GPMC. Die GPO mit der niedrigsten Nummer in der Verknüpfungsreihenfolge wird zuletzt verarbeitet und hat somit den höchsten Vorrang.¹

3.2. Vererbung blockieren und Erzwingen (Enforced)

Von der Standardreihenfolge lassen sich Ausnahmen einrichten.¹

• Vererbung blockieren: An einer Domäne oder OU gesetzt, unterbindet dies die Vererbung von GPOs aus höheren Ebenen. Das Werkzeug für den Fall „nur diese eine OU soll den unternehmensweiten Standard nicht erhalten“.
• Erzwingen (Enforced, früher: Kein Vorrang): An der Verknüpfung einer GPO gesetzt, sorgt dies dafür, dass diese GPO immer angewendet wird, selbst wenn auf einer niedrigeren Ebene die Vererbung blockiert ist, und dass sie nicht mehr von einer niedrigeren GPO überschrieben werden kann. Stehen Vererbungsblockade und Erzwingen im Widerspruch, gewinnt Erzwingen.¹

Erzwingen bricht das Prinzip „zuletzt gewinnt“, sodass ein häufiger Einsatz dazu führt, dass Ihnen die RSoP-Ergebnisse immer öfter kontraintuitiv erscheinen. Es empfiehlt sich, es ausschließlich für Sicherheitseinstellungen zu verwenden, die im gesamten Unternehmen unbedingt eingehalten werden müssen.

3.3. Sicherheitsfilterung

Über den Verknüpfungsort hinaus lässt sich auch wer eine GPO erhält, pro GPO eingrenzen. Damit eine GPO angewendet wird, müssen der betroffene Benutzer oder Computer für diese GPO beide Berechtigungen — „Lesen“ und „Gruppenrichtlinie übernehmen“ — besitzen. Standardmäßig werden beide Berechtigungen den Authentifizierten Benutzern (die sowohl Benutzer als auch Computer einschließen) gewährt, sodass die GPO auf alle unter dem Verknüpfungsziel wirkt. Die Sicherheitsfilterung dient dazu, dies auf bestimmte Sicherheitsgruppen einzugrenzen. Der Filter wirkt auf die GPO als Ganzes; er lässt sich nicht pro Einstellung innerhalb der GPO variieren.¹³

Ein wichtiger Hinweis: Beim Eingrenzen des Geltungsbereichs dürfen Sie den Authentifizierten Benutzern nicht auch die Berechtigung „Lesen“ entziehen. Seit dem Sicherheitsupdate MS16-072 (2016) wird die Benutzerrichtlinie im Sicherheitskontext des Computers abgerufen, sodass die benutzerbezogene GPO nicht angewendet wird, wenn das Computerkonto die GPO nicht lesen kann — selbst wenn der betroffene Benutzer beide Berechtigungen besitzt.¹⁴ Die richtige Vorgehensweise beim Eingrenzen besteht darin, der Zielgruppe „Lesen + Gruppenrichtlinie übernehmen“ zu gewähren und den Authentifizierten Benutzern (oder Domänencomputern) nur „Lesen“ zu belassen.¹⁴

In der Praxis sind „zur Gruppe hinzugefügt, aber trotzdem nicht angewendet (bei einer computerbezogenen Einstellung wurde nur der Benutzer zur Gruppe hinzugefügt)“ und „aus der Gruppe entfernt, aber die Anwendung hält trotzdem an“ die klassischen Stolperfallen. Letzteres löst sich auch durch Abwarten der Hintergrundaktualisierung nicht auf. Die Gruppenmitgliedschaft wird anhand des bei der Anmeldung erstellten Sicherheitstokens ausgewertet, sodass eine Gruppenänderung beim Benutzer erst nach einem Ab- und wieder Anmelden und beim Computer erst nach einem Neustart in einem neuen Token und damit im Filter wirksam wird.

Für Fälle wie gemeinsam genutzte PCs oder Remotedesktop-Server, bei denen jeder, der sich an diesem PC anmeldet, eine ersetzte Benutzerkonfiguration erhalten soll, gibt es außerdem den speziellen Modus Loopback-Verarbeitung (ein Mechanismus, der Benutzereinstellungen anhand des Standorts des Computers anwendet, mit den beiden Modi Ersetzen und Zusammenführen).¹⁵ Da es sich um eine fortgeschrittene Funktion für Kiosk-Rechner oder Klassenzimmer-PCs handelt, beschränkt sich dieser Artikel darauf, sie zu erwähnen.

4. Wann Einstellungen wirksam werden ── Vordergrundverarbeitung und Hintergrundaktualisierung

Die Hälfte der Fälle von „eingestellt, aber nicht wirksam“ liegt schlicht daran, dass der Zeitpunkt der Anwendung noch nicht gekommen ist. Es gibt zwei Arten der Anwendung.²

Mit anderen Worten: Bei einem laufenden Gerät, das einen Domänencontroller erreichen kann, verbreiten sich Einstellungen, die Hintergrundaktualisierung unterstützen, ohne weiteres Zutun innerhalb von etwa zwei Stunden, nachdem Sie die GPO geändert haben. Offline-Geräte oder ohne VPN mitgenommene Notebooks erreicht die Änderung erst, wenn sie das nächste Mal einen Domänencontroller erreichen. Einstellungen, die nur durch Vordergrundverarbeitung angewendet werden, müssen zusätzlich auf einen Start oder eine Anmeldung warten. Eilt es, führen Sie auf dem betroffenen PC gpupdate aus. Standardmäßig werden nur geänderte Einstellungen angewendet; mit /force werden alle Einstellungen erneut angewendet, unabhängig davon, ob sie sich geändert haben.³

rem Nur geänderte Einstellungen aktualisieren (normalerweise ausreichend)
gpupdate

rem Alle Einstellungen erneut anwenden (wenn Sie einen zwischengespeicherten Zustand vermuten)
gpupdate /force

Zu beachten ist, dass es Einstellungen gibt, die durch gpupdate nicht wirksam werden. Softwareinstallationen und Ordnerumleitungen für Benutzer werden nur bei der Anmeldung, softwarebezogene Einstellungen für Computer nur beim Start verarbeitet. Genau dafür stellt gpupdate die Optionen /logoff (nach der Aktualisierung abmelden) und /boot (nach der Aktualisierung neu starten) bereit.³ Bevor Sie sich beschweren, dass „gpupdate /force ausgeführt wurde und die Einstellung trotzdem nicht greift“, prüfen Sie also, ob es sich um eine Einstellungsart handelt, die einen Neustart oder eine Anmeldung erfordert.

5. Fehlersuche, wenn nichts wirkt ── gpresult, Ereignisprotokoll und Registrierung

5.1. RSoP mit gpresult /h prüfen

gpresult ist das Standardwerkzeug, um das Endergebnis (RSoP: Resultant Set of Policy) zu prüfen, nachdem sich mehrere GPOs überlagert haben. Am besten lesbar ist ein HTML-Bericht, den Sie aus einer erhöhten Eingabeaufforderung erzeugen.⁴⁵

rem RSoP-Bericht für Benutzer und Computer gemeinsam als HTML ausgeben
gpresult /h C:\temp\gp-report.html /f

rem Nur eine Übersicht in der Konsole anzeigen
gpresult /r
gpresult /scope computer /r

Im Bericht sollten Sie zuerst diese drei Punkte prüfen:

1. Die Liste der angewendeten GPOs ── Ist die gesuchte GPO enthalten?
2. Die Liste der verweigerten GPOs mit Begründung ── Gründe für die Nichtanwendung wie Sicherheitsfilterung, WMI-Filter oder eine leere GPO werden hier angezeigt⁵
3. Die „gewinnende GPO“ je Einstellung ── Welche GPO über die gesuchte Einstellung entschieden hat. Setzt sich eine andere GPO durch, prüfen Sie die Rangfolge aus Kapitel 3 erneut

5.2. Das GroupPolicy-Betriebsprotokoll

Reicht gpresult nicht aus (etwa weil die Verarbeitung von vornherein fehlschlägt oder zu lange dauert), sehen Sie im Ereignisanzeige-Snap-In im GroupPolicy-Betriebsprotokoll nach. Es befindet sich unter „Anwendungs- und Dienstprotokolle > Microsoft > Windows > GroupPolicy > Operational“ (Protokollname Microsoft-Windows-GroupPolicy/Operational). Hier wird die gesamte Richtlinienverarbeitung von Anfang bis Ende festgehalten, zusammen mit der Liste der angewendeten GPOs und der Liste der verweigerten GPOs (mit Begründung). Jedem Durchlauf der Richtlinienverarbeitung wird eine eindeutige ActivityID zugewiesen; Microsofts empfohlenes Vorgehen ist daher, die ActivityID aus einem Warn- oder Fehlerereignis im Systemprotokoll zu entnehmen und dann mit einer benutzerdefinierten Ansicht nur diesen einen Durchlauf einzugrenzen.⁵

5.3. Der Zusammenhang mit dem Policies-Schlüssel in der Registrierung

Richtlinien aus administrativen Vorlagen (nächstes Kapitel) werden letztlich als Registrierungswerte geschrieben. Der Schreibort ist grundsätzlich einer dieser dedizierten Richtlinienschlüssel.⁶

• HKEY_LOCAL_MACHINE\Software\Policies (Computerkonfiguration; empfohlener Ort)
• HKEY_CURRENT_USER\Software\Policies (Benutzerkonfiguration; empfohlener Ort)
• HKLM\Software\Microsoft\Windows\CurrentVersion\Policies / HKCU\Software\Microsoft\Windows\CurrentVersion\Policies

Dahinter steckt ein wichtiges Designprinzip. Eine richtlinienfähige App verhält sich so, dass sie zuerst den Policies-Schlüssel liest; ist dort ein Wert vorhanden, hat er Vorrang; ist keiner vorhanden, greift die App auf ihre eigene Einstellung (Präferenz) oder den Standardwert zurück. Eine „nicht konfigurierte“ Richtlinie schreibt nichts in die Registrierung.⁶ Mit anderen Worten: Richtlinien aus administrativen Vorlagen überschreiben nicht die eigene Einstellung der App und hinterlassen keine bleibende Spur (kein „Tattoo“) — stattdessen wird ein an anderer Stelle abgelegter, erzwungener Wert vorrangig herangezogen. Beenden Sie die Konfiguration der Richtlinie, kehrt die App zu ihrer eigenen Einstellung zurück.

Allerdings schreiben nicht alle Richtlinien in einen dedizierten Schlüssel. Manche in das Betriebssystem integrierte Einstellungen (zum Beispiel schreibt „Lange Win32-Pfade aktivieren“ nach LongPathsEnabled unter HKLM\SYSTEM\CurrentControlSet\Control\FileSystem) sowie ältere oder Drittanbieter-Vorlagen schreiben an beliebige Pfade außerhalb der dedizierten Schlüssel. Bei dieser Art von Einstellung bleibt der Wert auch nach dem Beenden der Richtlinienkonfiguration bestehen. Ob eine bestimmte Einstellung tatsächlich in diesen Schlüssel schreibt, prüfen Sie anhand der ADMX-Definition, der Beschreibung der Einstellung oder des gpresult-Berichts.

Anders ausgedrückt: Das oben beschriebene vorbildliche Verhalten gilt nur innerhalb des Rahmens administrativer Vorlagen (der dedizierten Richtlinienschlüssel). Werte, die Skripte oder Gruppenrichtlinien-Grundeinstellungen (Preferences) außerhalb des Policies-Schlüssels schreiben, verhalten sich wie gewöhnliche Registrierungswerte, und dieser Rahmen bietet keinen Mechanismus, sie nach dem Ende der Verteilung automatisch zurückzusetzen. In der Praxis ist der schnellste und zuverlässigste Weg der Fehlersuche, direkt zu prüfen, ob die gesuchte Einstellung unter dem Policies-Schlüssel geschrieben ist.

# Beispiel zur direkten Prüfung eines per Richtlinie verteilten Werts (die meisten Richtlinien schreiben unter Policies)
Get-ChildItem "HKLM:\SOFTWARE\Policies" -Recurse | Select-Object Name
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\System" -ErrorAction SilentlyContinue

6. Administrative Vorlagen (ADMX) und der zentrale Speicher

Die Definitionen hinter den Einstellungen, die unter „Administrative Vorlagen“ in GPMC aufgeführt sind, bestehen aus ADMX-Dateien (dem eigentlichen Definitionskörper) und ADML-Dateien (den sprachspezifischen Anzeigetexten). Auf jedem PC liegen die vom Betriebssystem mitgelieferten Definitionen unter C:\Windows\PolicyDefinitions, und die Verwaltungswerkzeuge laden diese, um den Einstellungsbildschirm aufzubauen.⁷

Wer eine Domäne betreibt, sollte grundsätzlich einen zentralen Speicher einrichten. Legen Sie unter dem SYSVOL eines Domänencontrollers einen Ordner PolicyDefinitions an (zum Beispiel \\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions), wird dessen Inhalt auf alle Domänencontroller der Domäne repliziert, und die Gruppenrichtlinien-Werkzeuge greifen dann standardmäßig auf den zentralen Speicher zurück.⁷ Damit entfällt das Problem, dass „sich die Vorlagenversion von Verwaltungsrechner zu Verwaltungsrechner unterscheidet und die sichtbaren Einstellungen nicht übereinstimmen“. ADML-Dateien werden in sprachspezifischen Unterordnern abgelegt (für Deutsch de-DE).⁷

Es gibt zwei betriebliche Hinweise. Erstens veröffentlicht Microsoft für jede neue Windows-Version neue ADMX-Dateien; beim Aktualisieren tauschen Sie die Dateien im zentralen Speicher aus. Das Ersetzen von C:\Windows\PolicyDefinitions auf jedem einzelnen PC durch die heruntergeladene Version wird nicht unterstützt.⁷ Zweitens: Beim Aktualisieren eines bestehenden zentralen Speichers sollten Sie das produktive PolicyDefinitions nicht direkt überschreiben. Stellen Sie stattdessen den vollständigen ADMX-Satz — sowohl für das Betriebssystem als auch für Anwendungen wie Office oder Edge — in einem versionsbenannten Arbeitsordner wie PolicyDefinitions-24H2 zusammen, benennen Sie den aktuellen Ordner zur Sicherung in etwas wie PolicyDefinitions-23H2 um, und benennen Sie anschließend den Arbeitsordner in PolicyDefinitions um, um ihn zu produktiv zu machen.⁷ Die Gruppenrichtlinien-Werkzeuge greifen ausschließlich auf einen Ordner mit dem Namen PolicyDefinitions zu; nur einen versionsbenannten Ordner anzulegen, hat also noch keine Wirkung. Der Vorteil dieses Vorgehens ist, dass Sie bei Problemen zum zurückgestellten alten Ordner zurückkehren können.⁷

7. GPO vs. Intune (MDM/CSP) vs. manuelle Verteilung/Skripte ── Entscheidungstabelle

Für die Konfigurationsverwaltung von Windows-Geräten ist GPO heute nicht mehr die einzige Option. MDM, wie es Intune verkörpert, konfiguriert Betriebssystemeinstellungen über einen Mechanismus namens CSP (Configuration Service Provider). Hier eine Entscheidungstabelle, woran Sie sich orientieren können.

Die entscheidende Achse ist einfach: die Identitätsgrundlage des Geräts (AD oder Microsoft Entra) und der Aufenthaltsort des Geräts. Für eine Gruppe fest im Büro stehender PCs, die vollständig einer On-Premises-AD angehören, ist GPO am zuverlässigsten; Entra-verbundene mobile PCs erreicht GPO gar nicht erst.

In der Realität liegen die meisten kleinen und mittleren Unternehmen dazwischen, also in einer hybriden Konstellation (domänenverbunden plus in Intune registriert), und hier ist das Schlechteste, was Sie tun können, „dieselbe Einstellung sowohl über GPO als auch über MDM zu konfigurieren“. Policy CSP kennt eine Richtlinie namens MDMWinsOverGP, die MDM bei einem Konflikt zwischen GPO und MDM gewinnen lässt, deren Geltungsbereich sich aber auf die entsprechenden Richtlinien innerhalb von Policy CSP beschränkt. Microsoft selbst stellt ausdrücklich klar, dass das Konfigurieren einer außerhalb dieser Kontrolle liegenden Einstellung über sowohl GPO als auch MDM einen Wettlaufzustand ohne garantierten Gewinner erzeugt, und rät von einer solchen Doppelkonfiguration ab.⁸ Der erste Grundsatz im hybriden Betrieb lautet, pro Einstellungsbereich festzulegen „das hier ist GPO, das hier ist Intune“, und sich auf eine einzige zuständige Instanz festzulegen.

Erwägen Sie den Übergang von GPO zu Intune, ist Intunes Group Policy analytics der Einstiegspunkt. Importieren Sie aus GPMC exportierte GPOs (XML), lässt sich analysieren, ob eine Einstellung von MDM unterstützt wird oder veraltet bzw. nicht unterstützt ist; unterstützte Einstellungen lassen sich in eine Einstellungskatalog-Richtlinie von Intune überführen.⁹ Es entspricht der Praxis eher, dieses Werkzeug nicht als „alles verschieben“, sondern als Mittel zum „Sortieren dessen, was sich verschieben lässt, was nicht, und was aufgegeben wird“ zu betrachten. Auch die Zuständigkeit für die Windows-Update-Verwaltung wird im selben Kontext neu geordnet. Siehe hierzu auch „Windows-Update-Verwaltung nach der Abschaffung von WSUS“.

8. Die Falle aus Entwicklersicht ── Wie die Kunden-GPO das Verhalten Ihrer App verändert

Zum Schluss ein Punkt, den Sie als Auftragsentwickler kennen sollten. Die GPO beim Kunden verändert still und leise die Grundannahmen Ihrer App. Neben Firewall und Virenschutz ist die GPO ein regelmäßiger Verdächtiger dafür, dass „es auf dem Entwicklungsrechner läuft, beim Kunden aber nicht“. Hier einige konkrete Beispiele.

• Die PowerShell-Ausführungsrichtlinie: Die Ausführungsrichtlinie lässt sich zentral über GPO konfigurieren, und die aus der GPO stammenden Bereiche MachinePolicy/UserPolicy haben immer Vorrang vor einem lokal oder auf Prozessebene gesetzten Wert.¹⁰ Ist ein Installationsprogramm oder Betriebsskript auf der Annahme aufgebaut, dass „-ExecutionPolicy Bypass schon reichen wird“, startet es unter GPO-Verwaltung nicht einmal. Näheres dazu finden Sie unter „PowerShell-Ausführungsrichtlinie und Skriptsignierung“.
• Deaktiviertes lokales Regel-Merging der Firewall: In Umgebungen, in denen die Firewall zentral über GPO/Intune verwaltet wird, lässt sich pro Profil das „Zusammenführen lokaler Regeln“ (AllowLocalPolicyMerge) deaktivieren. Ist es deaktiviert, wird eine vom Installationsprogramm lokal registrierte Eingangsregel zwar angezeigt, aber nicht angewendet.¹¹ Das ist ein Punkt, den Sie vor der Einführung einer serverartigen App unbedingt prüfen sollten; ausführlich behandelt in „Windows-Firewall und Fachanwendungen“.
• Umgebungskonfiguration wie Laufwerkszuordnungen und Proxys: Die Zuordnung von Netzlaufwerken, Druckern und Ähnlichem wird üblicherweise über Gruppenrichtlinien-Grundeinstellungen (Preferences) verteilt.¹⁶ Umgebungsannahmen wie „das Z-Laufwerk müsste da sein“ oder „der Proxy müsste direkt verbunden sein“ können je nach angemeldetem Benutzer oder OU-Zugehörigkeit des PCs zusammenbrechen. Auch leicht zu übersehen ist bei dauerhaft laufenden Anwendungen, dass über die Benutzerkonfiguration verteilte Einstellungen selbstverständlich nicht für das Konto gelten, unter dem ein Dienst oder eine geplante Aufgabe läuft.
• Die Einstellung lässt sich gar nicht erst „zurücksetzen“: Einstellungen, die aus administrativen Vorlagen stammen, lassen sich im Normalfall vom Benutzer über die Oberfläche nicht ändern (der Eintrag ist ausgegraut). Dass „lassen Sie den Kunden die Einstellung selbst ändern“ nicht funktioniert, wirkt sich unmittelbar darauf aus, wie Sie Ihren Support gestalten sollten.

Auf Entwicklerseite gibt es drei realistische Vorkehrungen. Erstens: Dokumentieren Sie als Bereitstellungsanforderung die Umgebungsvoraussetzungen, von denen Ihre App abhängt — Ausführungsrichtlinie, Empfangsport, Zielordner für Schreibzugriffe, Proxy-Pfad und Ähnliches — und lassen Sie diese vor der Einführung von der IT-Abteilung des Kunden bestätigen. Zweitens: Prüfen Sie bei Problemen nicht auf Verdacht, sondern anhand des tatsächlichen gpresult /h-Berichts und der realen Werte unter HKLM\Software\Policies (Kapitel 5). Drittens: Trennen Sie bereits im Entwurf, welche Vorgänge Administratorrechte benötigen und welche nicht (diese Abgrenzung wird in „Wann sind unter Windows Administratorrechte wirklich nötig? – UAC, geschützte Bereiche und wie Sie es im Entwurf erkennen“ behandelt). Die GPO ist nicht der Feind, sondern eine Spezifikation der Umgebung. Behandeln Sie sie als Spezifikation, wird die Fehlersuche zu einer mechanischen Angelegenheit.

9. Zusammenfassung

• Gruppenrichtlinien sind ein Mechanismus, der GPO-Einstellungen in der Reihenfolge Lokal → Standort → Domäne → OU (LSDOU) verarbeitet, wobei Konflikte nach dem Prinzip „zuletzt gewinnt“ aufgelöst werden. Die GPO der dem Ziel am nächsten liegenden OU ist am stärksten, die lokale GPO am schwächsten.
• Vererbung blockieren, Erzwingen (Enforced) und Sicherheitsfilterung erlauben es, den Standardablauf zu steuern. Erzwingen gewinnt auch gegen die Vererbungsblockade, weshalb Sie es nicht übermäßig einsetzen sollten.
• Die Anwendung erfolgt über zwei Kanäle: Vordergrundverarbeitung beim Start bzw. bei der Anmeldung sowie eine standardmäßig etwa alle 90 Minuten plus zufälligem Versatz erfolgende Hintergrundaktualisierung. gpupdate /force wendet alle Einstellungen erneut an, wirkt aber nicht auf Einstellungen, die nur bei der Anmeldung oder beim Neustart verarbeitet werden.
• Wirkt eine Einstellung nicht, gehen Sie systematisch in der Reihenfolge gpresult /h → GroupPolicy-Betriebsprotokoll → Policies-Schlüssel in der Registrierung vor. Verweigerte GPOs werden mit Begründung angezeigt.
• Die Definitionen administrativer Vorlagen liegen als ADMX/ADML vor; im Domänenbetrieb sollten Sie sie im zentralen Speicher unter SYSVOL bündeln. Beim Aktualisieren tauschen Sie den zentralen Speicher aus, statt das lokale PolicyDefinitions zu ersetzen.
• Ob GPO oder Intune, entscheiden Sie anhand der Identitätsgrundlage und des Standorts des Geräts; vermeiden Sie im Hybridbetrieb die Doppelkonfiguration derselben Einstellung und lassen Sie die Zuständigkeit auf einer Seite. Für die Sortierung bei einer Migration eignet sich Group Policy analytics.
• Für Entwickler ist die GPO beim Kunden Teil der Umgebungsspezifikation. Dokumentieren Sie die Voraussetzungen rund um Ausführungsrichtlinie, Firewall, Laufwerkszuordnungen und Proxy-Konfiguration, und schaffen Sie sich die Gewohnheit, sie mit gpresult zu überprüfen — dann verlieren die meisten Fälle von „läuft nur beim Kunden nicht“ ihren Schrecken.

Verwandte Artikel

• Windows-Firewall und Fachanwendungen ── Eingangsregeln über das Installationsprogramm registrieren
• Windows-Update-Verwaltung nach der Abschaffung von WSUS ── Wie Sie zwischen WUfB, Autopatch und Intune wählen
• PowerShell-Ausführungsrichtlinie und Skriptsignierung ── Praktischer Leitfaden für den Abschied vom „mit Bypass zukleben“
• PC-Kitting mit winget + PowerShell automatisieren ── Die Anleitung ausführbar machen
• Leitfaden zum Ausstieg aus IE-Modus-abhängigen Systemen
• Wann sind unter Windows Administratorrechte wirklich nötig? – UAC, geschützte Bereiche und wie Sie es im Entwurf erkennen

Verwandte Beratungsleistungen

Die KomuraSoft LLC übernimmt die Ursachenermittlung dafür, warum eine Fachanwendung in einer GPO-verwalteten Kundenumgebung nicht läuft, die Aufbereitung von Bereitstellungsanforderungen (Ausführungsrichtlinie, Firewall, Netzwerkvoraussetzungen) sowie technische Beratung zur Richtlinienbestandsaufnahme und zu Intune-Koexistenzstrategien für IT-Verantwortliche, die eine AD-Umgebung übernommen haben. Sie können auch schon in einer frühen Phase beginnen, etwa mit „Lesen Sie den gpresult-Bericht gemeinsam mit uns durch“.

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

Referenzlinks

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 durch eine Hintergrundaktualisierung überhaupt nicht wirksam wird. Softwareinstallationen und Ordnerumleitungen für Benutzer werden nur bei der Anmeldung verarbeitet, softwarebezogene Einstellungen 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 geben Sie mit gpresult /h einen RSoP-Bericht aus und prüfen, ob die betreffende GPO unter „Angewendete GPOs“ erscheint, oder ob sie mit einer Begründung unter „Verweigerte GPOs“ 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 (der zuletzt verarbeitete Wert gewinnt). Der Bericht zeigt zu jeder Einstellung die „gewinnende GPO“ an, sodass Sie genau bestimmen können, welche GPO sich durchsetzt.

Was bedeutet es, wenn gpresult „Verweigert wegen Filterung“ anzeigt?

Das bedeutet, dass die GPO zwar dem Verknüpfungsort nach im Geltungsbereich liegt, aber durch eine Filterung von der tatsächlichen Anwendung ausgeschlossen wurde. 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 das jedoch auf bestimmte Gruppen eingeschränkt haben, führt eine vergessene Gruppenmitgliedschaft — sei es beim Hinzufügen der Gruppe oder beim Hinzufügen des Computerkontos — zu einer Verweigerung. Bei benutzerbezogenen GPOs genügt es zudem nicht, dem betroffenen Benutzer allein beide Berechtigungen zu erteilen. Seit MS16-072 wird die Benutzerrichtlinie im Sicherheitskontext des Computers abgerufen, sodass für die Authentifizierten Benutzer oder Domänencomputer die Berechtigung „Lesen“ (nicht „Übernehmen“) erhalten bleiben muss. Weitere Ursachen sind ein nicht zutreffender WMI-Filter oder eine an der GPO selbst deaktivierte Benutzer- bzw. Computerkonfiguration. 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 Ihre Geräte überwiegend domänenverbunden mit einem lokalen AD und dauerhaft mit dem internen Netzwerk verbunden, ist GPO die zuverlässigste und feinkörnigste Option. Nehmen die Microsoft-Entra-verbundenen Geräte oder die Homeoffice-Rechner zu, die nie einen Domänencontroller erreichen, eignet sich Intune (MDM/CSP) besser, da es Konfigurationen auch außerhalb des Firmennetzes zustellen kann. 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 konsequent auf eines festzulegen. Sobald Sie eine Migration erwägen, können Sie mit Group Policy analytics in Intune Ihre bestehenden GPOs importieren und Einstellungen, die von MDM bereits unterstützt werden, von nicht unterstützten oder als veraltet markierten Einstellungen trennen.

Eine Einstellung, die ich über die lokale Gruppenrichtlinie (gpedit.msc) vorgenommen habe, wird ständig 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 Testzwecke 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 daher, eine eigene Test-OU anzulegen und die Domänen-GPO dort anzupassen, oder einen nicht domänenverbundenen Testrechner zu verwenden.

Die von uns entwickelte Fachanwendung läuft nur in der Kundenumgebung nicht. 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 dabei auf Einstellungen, die das Verhalten Ihrer App verändern können: durch die Ausführungsrichtlinie blockierte Skripte, deaktiviertes lokales Regel-Merging der Firewall 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 systematisch aufspüren. Auf Entwicklerseite besteht die praktische Vorsorge darin, die Voraussetzungen, von denen die App abhängt (Ausführungsrichtlinie, Empfangsport, Zielordner für Schreibzugriffe usw.), als Bereitstellungsanforderung zu dokumentieren und vor der Einführung von der IT-Abteilung 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.