# War Room: Eine verschwundene Sicherheits-GPO Typ: Checkliste Herkunft: active-directory / group-policy / ad-gpo-evidence-quest Version: ad-gpo-evidence-quest-2026-07-29 Geprüft: 2026-07-29 ACHTUNG: Dieses Dokument ist ein Lernartefakt aus einer Schulungssequenz. Es ist kein produktives Runbook. Vor jeder Anwendung in einer realen Umgebung müssen die Schritte gegen lokale Dokumentation, Runbooks und Freigabestatus geprüft werden. ## Szenario Die neue Browser-Härtung greift auf CLIENT-17 nicht. Ein Kollege will gleichzeitig Vererbung, Security Filtering und WMI-Filter ändern. Du übernimmst den Fall und musst eine beweisbare Diagnosekette bauen. ## Schritte 1. Betroffenen Benutzer, Computer, Zeitpunkt und die erwartete Einstellung eindeutig festhalten. 2. Auf CLIENT-17 einen aktuellen `gpresult`-Bericht für den betroffenen Kontext erzeugen und angewandte sowie abgelehnte GPOs prüfen. 3. Bei unklarer oder fehlerhafter Verarbeitung die passende Activity ID im Group-Policy-Operational-Log isolieren. 4. Aus Ablehnungsgrund und Logphase genau eine Hypothese zu Link, Berechtigung, WMI-Filter oder Client-Side Extension bilden. 5. Nur die belegte Ursache in kontrolliertem Scope ändern und Rückweg dokumentieren. 6. Policy gezielt aktualisieren, neuen Verarbeitungslauf erfassen und erwartete Einstellung sowie Nebenwirkungen verifizieren. ## Begründung Warum: Ein Resultant-Set-Bericht grenzt zuerst ein, ob und warum eine GPO angewandt oder abgelehnt wurde. Die Activity ID verbindet anschließend genau einen Verarbeitungslauf mit seinen Phasen. Erst dieser Befund rechtfertigt eine gezielte Änderung. Folgen: **+** Die Ursache bleibt von gleichzeitig sichtbaren GPO-Effekten unterscheidbar. **−** Nach jedem `gpupdate` entsteht eine neue Activity ID, die für die Verifikation erneut erfasst werden muss. ## Quellen 1. https://learn.microsoft.com/en-ca/troubleshoot/windows-server/group-policy/applying-group-policy-troubleshooting-guidance 2. https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/gpresult