Wird der Domaincontroller z.B. durch einen Stromausfall unsauber heruntergefahren, kann es passieren dass die DFS-Replikation anschließend nicht mehr korrekt funktioniert. In dem Fall tauchen im Eventlog Fehlermeldungen mit den ID’s: 6012, 1204, 2203 oder 4012 auf, die das bestätigen.
Wenn die Replikation nicht mehr funktioniert, wird das SYSVOL Verzeichnis nicht mit anderen Domain Controllern synchronisiert. Es werden also keine Gruppenrichtlinen oder Startskripte synchronisiert/aktualisiert.
Die Fehlermeldungen im Detail:
Der DFS-Replikationsdienst hat die Replikation für den Ordner unter dem folgenden lokalen Pfad "C:\Windows\SYSVOL\domain" beendet. Dieser Server wurde von anderen Partnern für 218 Tage getrennt. Dadurch wird die im Parameter "MaxOfflineTimeInDays" zulässige Dauer überschritten (60). Aus diesem Grund geht der DFS-Replikationsdienst davon aus, dass diese Daten veraltet sind, und dieser Ordner wird vom Server erst nach Korrektur dieses Fehlers wieder repliziert. Verwenden Sie zum Fortsetzen der Replikation dieses Ordners das DFS-Verwaltungs-Snap-Ins zum Entfernen dieses Servers aus der Replikationsgruppe, und fügen Sie ihn dann der Gruppe erneut zu. Dadurch führt der Server einen ersten Synchronisierungstask aus, wodurch die veralteten Daten durch aktuelle Daten der Mitglieder der Replikationsgruppe ersetzt werden. Weitere Informationen: Fehler: 9061 (Der replizierte Ordner war zu lange offline.) Name des replizierten Ordners: SYSVOL Share ID des replizierten Ordners: 02A2AFE0-7636-4311-8224-7870CA231A31 Replikationsgruppenname: Domain System Volume ID der Replikationsgruppe: D312232D-1934-4F65-9EC8-3A92F9A1ABEF Mitglieds-ID: F12B1BC5-158F-48F4-9B36-9585C7F8DF46
Vom DFS-Replikationsdienst wurde die Replikation für das Volume "C:" beendet. Dieser Fall tritt ein, wenn eine DFSR-JET-Datenbank nicht ordnungsgemäß heruntergefahren wird und die automatische Wiederherstellung deaktiviert ist. Sichern Sie zum Beheben dieses Problems die Dateien in den betroffenen replizierten Ordnern, und setzen Sie die Replikation anschließend mithilfe der WMI-Methode "ResumeReplication" fort. Weitere Informationen: Volume: C: GUID: 41230C60-D123-11E2-93E8-123E6F6E6123 Wiederherstellungsschritte 1. Sichern Sie die Dateien in allen replizierten Ordnern auf dem Volume. Andernfalls gehen möglicherweise aufgrund einer unerwarteten Konfliktauflösung im Rahmen der Wiederherstellung der replizierten Ordner Daten verloren. 2. Setzen Sie die Replikation für dieses Volume mithilfe der WMI-Methode "ResumeReplication" der DfsrVolumeConfig-Klasse fort. Geben Sie hierzu an einer Eingabeaufforderung mit erhöhten Rechten beispielsweise den folgenden Befehl ein: wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid="41230C60-D123-11E2-93E8-123E6F6E6123" call ResumeReplication Weitere Informationen finden Sie hier: http://support.microsoft.com/kb/2663685.
Als erstes kann man folgende Schritte unternehmen um die Replikation zu überprüfen. In meinem Fall handelt es sich um mehrere Domaincontroller, es geht also um das SYSVOL Verzeichnis. (Quelle: Technet)
For /f %i IN ('dsquery server -o rdn') do @echo %i && @(net view \\%i | find "SYSVOL") & echo
Anschließend kann man sich den Status der DFS Replikation ausgeben lassen:
For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i" /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo WHERE replicatedfoldername='SYSVOL share' get replicationgroupname,replicatedfoldername,stateDie Statuscodes haben folgende Bedeutung:
0 = Uninitialized 1 = Initialized 2 = Initial Sync 3 = Auto Recovery 4 = Normal 5 = In Error
[stextbox id=’alert‘]Vorher eine Sicherung des geteilten Ordners machen! Also in meinem Fall: C:\Windows\SYSVOL. Bei der Wiederherstellung kann es vorkommen, dass die Inhalte der Freigabe verloren gehen.[/stextbox]
Nun geht es an die Wiederherstellung der Replikation. Bei mehreren DC’s oder bei neu hinzugefügten DC’s kann es sein, dass das SYSVOL Verzeichnis noch nie synchronisiert wurde und daher leer ist bzw. gar nicht existiert. Daher die folgenden Schritte auf dem „primären“ DC ausführen, von dem aus der Sync erfolgen soll.
Schritt 1: Replikation fortsetzen
Aus der 2. Fehlermeldung von oben ergibt sich, dass die Replikation gestoppt ist. Diese müssen wir wieder fortsetzen. Der passende Befehl dazu findet sich zum Glück direkt im Eventlog.
wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid="41230C60-D123-11E2-93E8-123E6F6E6123" call ResumeReplication
Im Eventlog finden sich jetzt weitere Einträge, dass die Replikation zwar fortgesetzt wird – jedoch nicht funktioniert, da der Partner immer noch zulange offline war.
Schritt 2: MaxOfflineTimeInDays hochsetzen
Die Lifetime also den Wert „MaxOfflineTimeinDays“ können wir mit folgenden Befehl für alle DC’s überprüfen:
For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i" /namespace:\\root\microsoftdfs path DfsrMachineConfig get MaxOfflineTimeInDaysDieser wird jetzt auf eine Anzahl Tage gesetzt die höher ist, als die im Eventlog vermerkte Anzahl. In meinem Fall wäre das dann 220. Der Befehl muss auf allen DC’s mit dem Fehler ausgeführt werden.
wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig set MaxOfflineTimeInDays=220
Damit die Änderung des Wertes greift muss jeweils noch der Dienst „DFS Replication“ (DFSR) neugestartet werden.
net stop DFSR && net start DFSR
Ab jetzt sollte die Replikation wieder korrekt durchlaufen. Dies kann man über das Eventlog weiter verfolgen.
Schritt 3: MaxOfflineTimeInDays – back to default
Wenn die Replikation abgeschlossen wurde sollte der Wert „MaxOfflineTimeInDays“ – wie in Schritt 2 – wieder auf den Standard von 60 Tagen zurückgesetzt werden.
