GPO nicht angewendet: Event-ID 1058 beheben

Das Problem

Ein Client meldet im Ereignisprotokoll wiederholt den Fehler:

The processing of Group Policy failed. Windows attempted to read the file <domain>SYSVOL<domain>Policies{GUID}gpt.ini from a domain controller and was not successful. Group Policy settings may not be resolved until this event is resolved.

Dies ist Event-ID 1058. Die Ursache liegt fast immer in der SYSVOL-Replikation zwischen den Domänencontrollern – nicht am Client selbst.

Diagnose-Schritte

Schritt 1: gpresult auf dem Client ausführen

Prüfen Sie mit gpresult /r, welche GPOs als applied oder failed markiert sind:

gpresult /r

Für eine detaillierte Ausgabe aller Policies inklusive Fehlerquellen verwenden Sie gpresult /v oder speichern einen HTML-Bericht:

gpresult /h C:TempGPReport.html
start C:TempGPReport.html

Schritt 2: Den logon Server ermitteln

echo %LOGONSERVER%

Dies zeigt, von welchem DC der Client aktuell bedient wird. Prüfen Sie dort den SYSVOL-Zugriff:

dir \%COMPUTERNAME%SYSVOL

Schritt 3: DCDiag auf dem Domänencontroller ausführen

dcdiag /test:SysVolCheck /v
dcdiag /test:DFSREvent /v
dcdiag /test:FrsEvent /v
dcdiag /test:NetLogons /v
dcdiag /test:Replications /v

Die Tests geben Aufschluss über den Replikationsstatus von SYSVOL undeventuelle DFSR-/FRS-Probleme.

Schritt 4: DFSR-Backlog prüfen

Ein wachsender Backlog zeigt an, dass Dateien auf einem DC zurückbleiben:

dfsrdiag backlog /RGName:SYSVOLShare /SrcDc:DC01 /DstDc:DC02

Ursache: SYSVOL-Replikation defekt

Bei älteren Umgebungen (Windows Server 2008/2012) lief SYSVOL über FRS (File Replication Service). Seit Server 2008 R2 kann SYSVOL über DFSR (Distributed File System Replication) repliziert werden. Ein Defekt in dieser Replikation führt dazu, dass ein DC keine aktuellen GPO-Dateien (insbesondere gpt.ini und registry.pol) ausliefern kann.

Lösung: Authoritative und non-authoritative Synchronisation

Microsoft beschreibt den korrekten Ablauf in KB 2218556. Das Ziel ist, den aktuellsten DC als Quelle zu erhalten und alle anderen DCs erneut synchronisieren zu lassen.

Vorbereitung

Identifizieren Sie den DC mit den aktuellsten SYSVOL-Inhalten. Der PDC-Emulator ist meist der richtige Kandidat, da er als primärer Zeitgeber und Schreibdominanz-DC fungiert.

Non-authoritative Synchronisation auf den betroffenen DCs (D2-Verhalten)

1. Öffnen Sie auf dem DC, der synchronisiert werden soll, adsiedit.msc.
2. Navigieren Sie zu diesem DN:

   CN=SYSVOL Subscription,CN=Domain System Volume,
   CN=DFSR-LocalSettings,CN=<Servername>,OU=Domain Controllers,DC=<domain>

3. Setzen Sie msDFSR-Enabled auf FALSE.
4. Starten Sie den Befehl:

   DFSRDIAG POLLAD

   Die Ereignis-ID 4114 im DFSR-Ereignisprotokoll bestätigt, dass die Replikation für SYSVOL gestoppt wurde.

5. Setzen Sie msDFSR-Enabled wieder auf TRUE.
6. Starten Sie erneut DFSRDIAG POLLAD.
7. Die Ereignis-IDs 4614 und 4604 zeigen den Start der Synchronisation an – der DC hat nun einen D2-Vorgang durchgeführt und bezieht seine SYSVOL-Daten vom autoritativen Partner.

Authoritative Synchronisation auf dem PDC (D4-Verhalten)

Nur erforderlich, wenn der aktuellste Inhalt auf dem autoritativen DC liegt und alle anderen DCs darauf synchronisiert werden sollen:

1. Stoppen Sie den Dienst DFSR auf ALLEN DCs:

   net stop dfsr

2. Setzen Sie am PDC-Emulator über adsiedit.msc folgende Werte für den DN aus Schritt 1:
   • msDFSR-Enabled = FALSE
   • msDFSR-options = 1
3. Setzen Sie auf allen anderen DCs msDFSR-Enabled auf FALSE.
4. Starten Sie DFSR nur auf dem PDC:

   net start dfsr

5. Die Ereignis-ID 4114 erscheint auf dem PDC.
6. Setzen Sie am PDC msDFSR-Enabled wieder auf TRUE.
7. Starten Sie auf dem PDC:

   DFSRDIAG POLLAD

   Die Ereignis-ID 4602 bestätigt den D4-Vorgang.

8. Starten Sie DFSR auf den restlichen DCs und führen Sie dort ebenfalls DFSRDIAG POLLAD aus.
9. Stellen Sie den Dienst auf Automatisch zurück.

Client-Seitig

Nach Behebung der SYSVOL-Replikation erzwingen Sie auf dem Client eine frische GPO-Verarbeitung:

gpupdate /force
# Optional mit Warteschleife:
gpupdate /force /wait:0

Prüfen Sie anschließend erneut mit gpresult /r und im Ereignisprotokoll, ob Event-ID 1058 nicht mehr auftritt.

FAQ

Was bedeutet Error Code 0x80070005 bei Event 1058?

Dies ist ACCESS_DENIED. Prüfen Sie die NTFS-Berechtigungen auf dem SYSVOL-Share sowie die Freigabeberechtigungen. Die Gruppe Authenticated Users muss mindestens Lesen auf dem SYSVOL-Ordner haben.

Was bedeutet Error Code 0x00000422?

Dies ist ERROR_SERVICE_DOES_NOT_EXIST. Der DFSR-Dienst ist auf dem angegebenen DC nicht aktiv oder das SYSVOL ist noch nicht replikationsbereit. Lassen Sie den Replikationsstatus mit dcdiag /test:SysVolCheck prüfen.

Wann führt Event 1058 zu Event 1096?

Event 1096 tritt auf, wenn die registry.pol-Datei im GPO-Ordner nicht gelesen oder geschrieben werden kann – etwa weil sie korrupt ist oder die Berechtigungen nicht passen. Umbenennen Sie die Datei in registry.bak und starten Sie gpupdate /force, damit sie neu erstellt wird.

Sollte ich FRS oder DFSR nutzen?

FRS ist seit Windows Server 2008 R2 abgelöst. Wenn Ihre Domäne noch auf FRS läuft, sollte die Migration zu DFSR priorisiert werden. Microsoft hat FRS aus dem Support-Exit entnommen und empfiehlt ausschließlich DFSR für SYSVOL.

Wie prüfe ich den DFSR-Backlog systematisch?

dfsrdiag replicationgraph /RGName:SYSVOLShare
# Oder pro DC-Paar:
dfsrdiag backlog /RGName:SYSVOLShare /SrcDc:<Src> /DstDc:<Dst>
# Status aller Subscription-Objekte:
dfsrdiag subscriptions /RGName:SYSVOLShare

Quellen

• gpresult – Microsoft Learn
• gpupdate – Microsoft Learn
• DCDiag – Microsoft Learn
• Force synchronization for DFSR-replicated SYSVOL – Microsoft KB 2218556
• Fix: Group Policy Processing Error in Windows – Woshub
• Resultant Set of Policy – Microsoft Learn