Windows Server 2025 / Probleme bei der Anwendung von Gruppenrichtlinien beheben

Wird eine Gruppenrichtlinieneinstellung in Windows Server 2025 nicht wirksam, prüfen Sie konfigurierten Inhalt, Verknüpfung und Bereich, Filter und Berechtigungen, Domänenverbindung und das tatsächliche Clientergebnis. Ermitteln Sie mit gpresult und Ereignissen den Ablehnungsgrund oder die Richtlinie, die den endgültigen Wert liefert, bevor Sie Änderungen vornehmen. Wiederholtes gpupdate allein beweist nicht, dass die Einstellung den richtigen Benutzer oder Computer erreicht.

Betroffenen Computer, Benutzer und Wert festlegen

Legen Sie einen konkreten Computer, Benutzer und Einstellungswert als Untersuchungsziel fest. Notieren Sie für die fehlende Anmeldemeldung auf CLIENT1 das Gruppenrichtlinienobjekt (GPO), die Organisationseinheit (OU) des Computers und den erwarteten Titel. Verwenden Sie die Übung zum Erstellen und Verknüpfen eines GPO, prüfen Sie Lab-Computer-Message an Lab\Workstations und den unveränderten Titel Lab computer. Haben Sie die Meldung bereits zurückgenommen, klären Sie zuerst den jetzt vorgesehenen Zustand. Bei einer Benutzerrichtlinie sind dagegen der tatsächlich angemeldete Benutzer und dessen OU maßgeblich. Unterscheiden Sie eine einzelne fehlende Einstellung, vollständig fehlende Richtlinien und Unterschiede zwischen Clients.

Die folgenden Abfragen auf CLIENT1 zeigen Rechnername, Sitzungsidentität und Domänenmitgliedschaft. Im Labor sind CLIENT1 und PartOfDomain = True zu erwarten; sie belegen jedoch keine Verarbeitung eines bestimmten GPO. LOGONSERVER bezeichnet den Anmeldekontext und identifiziert nicht verlässlich den Controller jedes späteren Richtlinienzyklus. Während der Replikation können Controller vorübergehend unterschiedliche Änderungsstände zeigen. Die Microsoft-Anleitung zur Diagnose der Gruppenrichtlinienanwendung empfiehlt den Abgleich von Berichten und Ereignissen:

hostname
whoami
$env:LOGONSERVER
Get-CimInstance Win32_ComputerSystem | Select-Object Domain,PartOfDomain

Inhalt und Verknüpfungen in der GPMC prüfen

1. Öffnen Sie in der Gruppenrichtlinienverwaltung (GPMC, gpmc.msc) das richtige GPO und die Registerkarte Einstellungen. Prüfen Sie den gespeicherten Sollwert. Für das Beispiel befinden sich Titel und Text der Anmeldemeldung unter Computerkonfiguration → Richtlinien → Windows-Einstellungen → Sicherheitseinstellungen → Lokale Richtlinien → Sicherheitsoptionen.
2. Prüfen Sie, ob die Einstellung zur Computer- oder Benutzerkonfiguration gehört. Die Position des Computerobjekts bestimmt den Computerbereich; die OU des verwaltenden Administrators ersetzt sie nicht.
3. Kontrollieren Sie die Verknüpfung an der vorgesehenen OU, Verknüpfung aktiviert und den GPO-Status. Eine deaktivierte Verknüpfung, ein vollständig deaktiviertes GPO und ein deaktivierter Computer- oder Benutzerabschnitt sind verschiedene Ursachen.
4. Unterscheiden Sie unter Bereich und Delegierung Lesen von Gruppenrichtlinie übernehmen und prüfen Sie effektive Rechte und Verweigerungen. Gruppenmitgliedschaft oder die Möglichkeit, das GPO zu öffnen, beweist nicht allein die Anwendbarkeit.
5. Prüfen Sie den Filter der Windows-Verwaltungsinstrumentation (WMI), der auf dem Zielcomputer ausgewertet wird, sowie Vererbung blockieren und Erzwungen. Untersuchen Sie diese Bedingungen, statt sie ungeprüft zu aktivieren oder zu entfernen.

Das Entfernen von Authentifizierte Benutzer aus der Sicherheitsfilterung entzieht sowohl Lesen als auch Gruppenrichtlinie übernehmen und schafft allein noch keinen richtigen eingeschränkten Bereich. Die Zielbenutzer benötigen passende Berechtigungen; zusätzlich muss das Computerkonto das Benutzer-GPO lesen können. Die Microsoft-Erklärung zu GPO-Leserechten der Computer erläutert diese getrennten Anforderungen. Ist fehlender Computer-Lesezugriff als Ursache bestätigt, vergeben Sie unter Delegierung → Hinzufügen nur Lesen an die vorgesehenen Computer oder deren Gruppe. Erteilen Sie nicht zur Vereinfachung der ganzen Domäne das Anwendungsrecht. Prüfen Sie auch explizite Verweigerungen. Die Dokumentation zu Bereich und Filterung hilft bei der Zuordnung; verändern Sie produktive Filter nicht für eine Vorführung.

Die tatsächlichen Clientergebnisse erfassen

Öffnen Sie auf CLIENT1 Windows PowerShell als Administrator für die Computerabfragen und den Computerbericht. Die letzte Zeile fragt die Benutzeridentität ab, unter der der Befehl läuft. Nur wenn diese dem betroffenen Benutzer entspricht, sind das dessen Ergebnisse. Haben Sie mit einem anderen Administratorkonto erhöht, führen Sie gpresult /r /scope user getrennt in der echten Sitzung des betroffenen Benutzers aus. Ersetzen Sie dessen Daten nicht durch die des Administrators. gpresult zeigt den Richtlinienergebnissatz (Resultant Set of Policy, RSoP). Die Übung setzt einen x64-Client voraus; unter Windows ARM64 ist laut Microsoft für /h das Programm in SysWow64 erforderlich:

$reportDirectory = Join-Path $env:TEMP ('gp-check-' + (Get-Date -Format 'yyyyMMdd-HHmmss'))
New-Item -ItemType Directory -Path $reportDirectory | Out-Null
gpresult /r /scope computer
gpresult /scope computer /h (Join-Path $reportDirectory 'computer.html')
gpresult /r /scope user

Der Block legt im temporären Verzeichnis einen Ordner gp-check mit Zeitstempel an und speichert darin computer.html; er öffnet keinen Browser. Lesen Sie den Wert von $reportDirectory ab und öffnen Sie die Datei im Browser. Schlägt die Ordnererstellung fehl oder meldet gpresult einen Fehler, halten Sie an und interpretieren keinen alten Bericht als aktuelles Ergebnis. Prüfen Sie Computer, Bereich und Erfassungszeit im Bericht. Die Benutzerzusammenfassung der letzten Zeile erscheint in der Konsole und wird nicht in computer.html gespeichert.

Ein GPO in der Liste angewendeter Objekte garantiert nicht die Wirkung jeder Einstellung. Suchen Sie in computer.html den konkreten Wert und sein verursachendes GPO und ordnen Sie das Ergebnis anhand der Tabelle ein. Prüfen Sie unterstützte Betriebssystemversion, Verwaltungsvorlagen, Computer- oder Benutzerabschnitt und Fehler der zuständigen Erweiterung. Die Dokumentation zu Gruppenrichtlinienergebnissen unterscheidet beobachtete Ergebnisse von einer Modellierung. Liefert ein anderes GPO den endgültigen Wert, prüfen Sie mit der Lektion zu Verarbeitungsreihenfolge und Vererbung die Priorität, statt ungeprüft Erzwungen zu aktivieren.

DNS, SYSVOL, Replikation und Ereignisse abgleichen

Führen Sie diese Diagnoseabfragen auf CLIENT1 mit Leserecht für das Ereignisprotokoll aus. Resolve-DnsName verwendet die DNS-Konfiguration des Clients und muss die Dienste der Labordomäne finden können; ersetzen Sie dafür den Domänen-DNS nicht durch einen öffentlichen Resolver. Test-Path prüft nur die Erreichbarkeit des angegebenen Pfads. True bestätigt weder alle Dateien jedes GPO noch deren Berechtigungen; False bestimmt ebenfalls keine einzelne Ursache. Namensauflösung, Zugriff oder Verbindung können betroffen sein. Die letzte Zeile zeigt nur die jüngsten 30 Ereignisse und kann den relevanten Zyklus verfehlen. Deaktivieren Sie nicht die Firewall, um eine Antwort zu erzwingen.

Resolve-DnsName '_ldap._tcp.dc._msdcs.ad.example.test' -Type SRV
Test-Path '\\ad.example.test\SYSVOL'
Get-WinEvent -LogName 'Microsoft-Windows-GroupPolicy/Operational' -MaxEvents 30 | Select-Object TimeCreated,Id,LevelDisplayName,Message

Öffnen Sie auf CLIENT1 in der Ereignisanzeige Windows-Protokolle → System und suchen Sie die GroupPolicy-Warnung oder den Fehler zum betroffenen Zeitpunkt. Prüfen Sie unter Details die ActivityID und den genannten Controller. Gehen Sie anschließend zu Anwendungs- und Dienstprotokolle → Microsoft → Windows → GroupPolicy → Operational und ordnen Sie die Ereignisse demselben Zyklus zu. Die Eigenschaftsauswahl des Befehls zeigt ActivityID nicht an; öffnen Sie dafür die Details. Eine spätere Aktualisierung erhält eine andere Kennung. Vermischen Sie keine Zyklen und verwechseln Sie einen alten Erfolg nicht mit dem gerade wiederholten Test. Falls die letzten 30 Ereignisse den Zeitraum nicht abdecken, erweitern Sie die Prüfung entsprechend.

Ein GPO besteht aus einem Anteil in Active Directory (AD) und Dateien in SYSVOL, der Domänenfreigabe für Richtlinien und Skripts. Prüfen Sie den im Ereignis genannten Controller und ob die betreffenden Änderungen DC1 und DC2 erreicht haben. Die Lektion zur AD-Replikation hilft bei der Verzeichnisreplikation; deren Erfolg beweist nicht allein, dass SYSVOL-Dateien repliziert wurden. Ziehen Sie dazu den passenden Zustand und die Ereignisse von DFS Replication, der Replikation des verteilten Dateisystems, heran. Erzwingen Sie keine Kopie einer alten Controllerversion und löschen Sie SYSVOL nicht als allgemeine Reparatur.

Eine Ursache korrigieren und erneut prüfen

Korrigieren Sie eine nachgewiesene Ursache und dokumentieren Sie Änderung und vorherigen Wert. Aktualisieren Sie für den Computerfall auf CLIENT1 nur diesen Bereich mit dem folgenden Befehl. Betrifft der Fehler eine Benutzerrichtlinie, behandeln Sie deren Bereich in der passenden Sitzung. Melden Sie sich nur neu an oder starten Sie nur neu, wenn die betreffende Einstellung es verlangt. Die Labormeldung wird bei der nächsten Anmeldung überprüft und rechtfertigt keinen pauschalen Serverneustart:

gpupdate /target:computer /force

Erstellen Sie nach der Korrektur einen neuen Bericht in einem neuen Verzeichnis und vergleichen Sie Sollwert, endgültiges Quell-GPO und tatsächliches Verhalten. Die gpupdate-Ausgabe allein bestätigt diese Punkte nicht. Die Bedingungen der Richtlinienverarbeitung umfassen Erweiterungen, die Anmeldung oder Start erfordern. In ausdrücklich eingerichteten Szenarien kann die Loopbackverarbeitung Benutzerrichtlinien mit denen des Computers zusammenführen oder durch sie ersetzen; aktivieren Sie das nicht als allgemeinen Lösungsversuch. Bleibt der Fehler bestehen, nehmen Sie nur Ihre Änderung zurück und bewahren den offenen Fehler samt Erfassungszeit und verwendeter Identität auf.

HTML-Berichte und Ereignisse können Benutzer- und Computernamen, Domänen und interne Pfade enthalten. Speichern Sie sie mit begrenztem Zugriff, wählen Sie die tatsächlich benötigten Informationen aus und entfernen Sie unnötige interne Angaben vor einer öffentlichen Weitergabe. Nehmen Sie keine Kennwörter auf und aktivieren Sie ausführliche Debugprotokollierung nicht dauerhaft nur zur Vergrößerung der Datensammlung.