13
Fragwürdige GPO Fehler im Syslog
Hallo!
Ich kriege bei manchen (oder sogar allen? -prüfe noch) Clients folgenden Fehler bei mehreren GPOs (aber nicht bei allen):
Protokollname: System
Quelle: Microsoft-Windows-GroupPolicy
Datum: 24.05.2018 11:27:49
Ereignis-ID: 1058
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:
Benutzer: *
Computer: Pe
Beschreibung:
Fehler bei der Verarbeitung der Gruppenrichtlinie. Der Versuch, die Datei "\e\sysvol\**e\Policies\{DFFD853F-D8FC-4B01-A7C6-85F063CBB66A}\gpt.ini" von einem Domänencontroller zu lesen, war nicht erfolgreich. Die Gruppenrichtlinieneinstellungen dürfen nicht angewendet werden, bis dieses Ereignis behoben ist. Dies ist möglicherweise ein vorübergehendes Problem, das mindestens eine der folgenden Ursachen haben kann:
a) Namensauflösung/Netzwerkverbindung mit dem aktuellen Domänencontroller.
b) Wartezeit des Dateireplikationsdienstes (eine auf einem anderen Domänencontroller erstellte Datei hat nicht auf dem aktuellen Domänencontroller repliziert).
c) Der DFS-Client (Distributed File System) wurde deaktiviert.
Die GPOs ziehen aber alle. Daher bin ich auch nur nebenbei über den Fehler gestolpert. Die Replizierung der beiden DCs ist aber laut diesem AD Analyse Tool von MS ok. Selbst auf Serversystemen mit ganz anderen GPOs kriege ich diese Meldung.
Kann es sein, dass sich das Problem bei der nächsten GPO Abfrage von selbst löst und die GPO deshalb angewendet wird? Also ein Fehler den man getrost ignorieren kann? Das Sysvol Verzeichnis ist aber nicht zu 100% auf beiden DCs gleich. Sondern zu 99%. Ich glaube das ist noch vertretbar oder?
Zu diesem DFS Client: Hatte ich bisher noch nix mit zu tun. Läuft der auf dem DC oder aufm Client als Service?
Ich kriege bei manchen (oder sogar allen? -prüfe noch) Clients folgenden Fehler bei mehreren GPOs (aber nicht bei allen):
Protokollname: System
Quelle: Microsoft-Windows-GroupPolicy
Datum: 24.05.2018 11:27:49
Ereignis-ID: 1058
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:
Benutzer: *
Computer: Pe
Beschreibung:
Fehler bei der Verarbeitung der Gruppenrichtlinie. Der Versuch, die Datei "\e\sysvol\**e\Policies\{DFFD853F-D8FC-4B01-A7C6-85F063CBB66A}\gpt.ini" von einem Domänencontroller zu lesen, war nicht erfolgreich. Die Gruppenrichtlinieneinstellungen dürfen nicht angewendet werden, bis dieses Ereignis behoben ist. Dies ist möglicherweise ein vorübergehendes Problem, das mindestens eine der folgenden Ursachen haben kann:
a) Namensauflösung/Netzwerkverbindung mit dem aktuellen Domänencontroller.
b) Wartezeit des Dateireplikationsdienstes (eine auf einem anderen Domänencontroller erstellte Datei hat nicht auf dem aktuellen Domänencontroller repliziert).
c) Der DFS-Client (Distributed File System) wurde deaktiviert.
Die GPOs ziehen aber alle. Daher bin ich auch nur nebenbei über den Fehler gestolpert. Die Replizierung der beiden DCs ist aber laut diesem AD Analyse Tool von MS ok. Selbst auf Serversystemen mit ganz anderen GPOs kriege ich diese Meldung.
Kann es sein, dass sich das Problem bei der nächsten GPO Abfrage von selbst löst und die GPO deshalb angewendet wird? Also ein Fehler den man getrost ignorieren kann? Das Sysvol Verzeichnis ist aber nicht zu 100% auf beiden DCs gleich. Sondern zu 99%. Ich glaube das ist noch vertretbar oder?
Zu diesem DFS Client: Hatte ich bisher noch nix mit zu tun. Läuft der auf dem DC oder aufm Client als Service?
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 375048
Url: https://administrator.de/forum/fragwuerdige-gpo-fehler-im-syslog-375048.html
Ausgedruckt am: 07.04.2025 um 18:04 Uhr
13 Kommentare
Neuester Kommentar
Hi,
Wobei man wissen müsste, was dieses 1% ist.
Diese Meldung ist allgemein ein Hinweis auf eine Störung in der Replikation des SYSVOL. Die Domäne hat das GPO-Objekt bereits repliziert, das DFS-R oder NtFRS aber die assoziierten Dateien noch nicht.
E.
Das Sysvol Verzeichnis ist aber nicht zu 100% auf beiden DCs gleich. Sondern zu 99%. Ich glaube das ist noch vertretbar oder?
Nein.Wobei man wissen müsste, was dieses 1% ist.
".... "\e\sysvol\**e\Policies...."
Was ist dieses "\e"? Ein Fehler von Dir beim Unkenntlichmachen des Domänennamens?Diese Meldung ist allgemein ein Hinweis auf eine Störung in der Replikation des SYSVOL. Die Domäne hat das GPO-Objekt bereits repliziert, das DFS-R oder NtFRS aber die assoziierten Dateien noch nicht.
E.
Hi,
also das AD Replication Status Tool von MS sagt mir aber alles okay. Hast du ein Tip für mich, wie ich die korrekte Replizierung ausserdem überprüfen kann? Grundsätlich kann ich aber sagen, dass ich noch nie ein Problem damit hatte. GPOs, DNS & Co. wurde immer repliziert.
Nur der Backup DC ist hin und wieder beim Backup etwas auffällig. Da hängt sich öfters mal dieser SQL VSS Writer Dienst auf und ich muss den händisch beenden. Der DC01 hat diesen Dienst nicht.
Und ja das sind nur Formatierungsfehler vom zensieren.
also das AD Replication Status Tool von MS sagt mir aber alles okay. Hast du ein Tip für mich, wie ich die korrekte Replizierung ausserdem überprüfen kann? Grundsätlich kann ich aber sagen, dass ich noch nie ein Problem damit hatte. GPOs, DNS & Co. wurde immer repliziert.
Nur der Backup DC ist hin und wieder beim Backup etwas auffällig. Da hängt sich öfters mal dieser SQL VSS Writer Dienst auf und ich muss den händisch beenden. Der DC01 hat diesen Dienst nicht.
Und ja das sind nur Formatierungsfehler vom zensieren.
also das AD Replication Status Tool von MS sagt mir aber alles okay.
Es sagt ja auch nur etwas über die AD-Replikation aus, und nichts über Dateireplikationen. Eine GPO besteht aus einem AD-Objekt und mehreren Dateien. Die Eventlog-Meldung (nicht "syslog"!) sagt etwas über Probleme in der Dateireplikation aus.
1
oh okay. Aber sie funktioniert ja. Zumindest bei neuen Dateien. Genau wie die GPO. Würde die Dateireplikation nicht funktionieren, würde die GPO ja auch nicht ziehen. Aber sie zieht ja.
/Udpate: ich habe jetzt einfach nochmal eine Testdatei ins Sysvol gelegt. Mal sehen.
/Update2: Oh Mist. Die Replizierung der Dateien scheint echt zu klemmen. Die aktuelleste Policy auf dem dc02 ist vom 12.03. Aufm primären DC jeodch 28.04.
Meine Testdatei wird auch nicht repliziert. Oder ich bin zu ungeduldig. Es würde bisher also genau 2 GPOs treffen. Alles andere ist replziert. Das kommt hin.
/Udpate: ich habe jetzt einfach nochmal eine Testdatei ins Sysvol gelegt. Mal sehen.
/Update2: Oh Mist. Die Replizierung der Dateien scheint echt zu klemmen. Die aktuelleste Policy auf dem dc02 ist vom 12.03. Aufm primären DC jeodch 28.04.
Meine Testdatei wird auch nicht repliziert. Oder ich bin zu ungeduldig. Es würde bisher also genau 2 GPOs treffen. Alles andere ist replziert. Das kommt hin.
Beachte
".......\gpt.ini" von einem Domänencontroller zu lesen, ....."
Sie hat also auf einem der DC gefehlt.Meine Testdatei wird auch nicht repliziert. Oder ich bin zu ungeduldig. Es würde bisher also genau 2 GPOs treffen. Alles andere ist replziert. Das kommt hin.
Nein, nicht zu ungedultig. Im "Normal"-AD geht das innerhalb von ein paar Sekunden.
ja okay, da haben wir das Problem gefunden. Im Netlogon funtzt die Replikation auch nicht mehr. Na super. Würde ein Reboot der beiden DCs helfen?
Kann.
Welche Windows Version nun? DFS-R oder NtFRS im Einsatz?
DFS-R
Ein Ansatz: Non-Authoritative and Authoritative SYSVOL Restore (DFS Replication)
NtFRS
Using the BurFlags registry key to reinitialize File Replication Service
Welche Windows Version nun? DFS-R oder NtFRS im Einsatz?
DFS-R
Ein Ansatz: Non-Authoritative and Authoritative SYSVOL Restore (DFS Replication)
NtFRS
Using the BurFlags registry key to reinitialize File Replication Service
NTFRS / windows Server 2012R2
Ich sehe auch aktuell diesen Fehler im Eventlog:
Der Dateireplikationsdienst hat ermittelt, dass ein Replikatstammpfad von "c:\windows\sysvol\domain" in "c:\windows\sysvol\domain" geändert wurde. Falls diese Änderungen absichtlich vorgenommen wurde, muss die Datei NTFRS_CMD_FILE_MOVE_ROOT im neuen Stammpfad neu erstellt werden.
Folgendes wurde für diesen Replikatsatz ermittelt:
"DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"
Die Replikat-Stammpfadänderung erfolgt in zwei Schritten, die durch das Erstellen der Datei NTFRS_CMD_FILE_MOVE_ROOT ausgelöst wird.
[1] Bei der ersten Abfrage, die in 5 Minuten durchgeführt wird, wird dieser Computer vom Replikatsatz entfernt.
[2] Bei der darauf folgenden Abfrage wird der Computer dem Replikatsatz erneut hinzugefügt. Durch das Hinzufügen wird eine vollständige Struktursynchronisierung ausgelöst. Nach der Synchronisierung befinden sich alle erforderlichen Dateien am neuen Ort.
Ich sehe auch aktuell diesen Fehler im Eventlog:
Der Dateireplikationsdienst hat ermittelt, dass ein Replikatstammpfad von "c:\windows\sysvol\domain" in "c:\windows\sysvol\domain" geändert wurde. Falls diese Änderungen absichtlich vorgenommen wurde, muss die Datei NTFRS_CMD_FILE_MOVE_ROOT im neuen Stammpfad neu erstellt werden.
Folgendes wurde für diesen Replikatsatz ermittelt:
"DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"
Die Replikat-Stammpfadänderung erfolgt in zwei Schritten, die durch das Erstellen der Datei NTFRS_CMD_FILE_MOVE_ROOT ausgelöst wird.
[1] Bei der ersten Abfrage, die in 5 Minuten durchgeführt wird, wird dieser Computer vom Replikatsatz entfernt.
[2] Bei der darauf folgenden Abfrage wird der Computer dem Replikatsatz erneut hinzugefügt. Durch das Hinzufügen wird eine vollständige Struktursynchronisierung ausgelöst. Nach der Synchronisierung befinden sich alle erforderlichen Dateien am neuen Ort.
Na dann mach doch. Steht doch da.
Ich bin drann. Melde mich.
So ich habe die besagte Datei angelegt. Sysvol und Netlogon Share sind aktuell offline. Gut das ich nen Snapshot gemacht hab... Mal sehen ob sich das von selbst behebt. Laut DC sollte die Synchronisierung vor ein paar Minuten begonnen haben.
/Update: Also DC01 tut was. Er hat alle Policy Ordner gekillt. Zieht der die sich jetzt vom DC02 ?
/Update2: jep. Shares sind wieder da. Ordner alle nagelneu. Ich prüfe nach der Pause weiter
/Update: Also DC01 tut was. Er hat alle Policy Ordner gekillt. Zieht der die sich jetzt vom DC02 ?
/Update2: jep. Shares sind wieder da. Ordner alle nagelneu. Ich prüfe nach der Pause weiter
Finales Update: Hat alles geklappt. Zwar hat er die letzten 3 aktualisierten GPOs rausgeworfen, ich konnte diese aber aus dem Ordner "NtFrs_PreExisting___See_EventLog" händisch in die Policies verschieben. Nach der Replikation wurden dann auch diese 3 GPO Objekte wieder von der Konsole gefunden. Die FM am Client und auf Servern sind weg.
Danke dir =)
Ich wünsche noch ein Ticket freien Rest Freitag.
Danke dir =)
Ich wünsche noch ein Ticket freien Rest Freitag.
