DFS-Replikation funktioniert nur nach Restart der Dienste

[mcdaniels 22]

Hallo,

ich habe 2x Server 2012 DC (aktueller Patchstand), die offenbar ein Problem bei der DFS-Replikation haben. Ich kann allerdings nicht nachvollziehen, warum das so ist. Aufgefallen ist mir das zuletzt, als ich eine GPO erstelle, die dann auf einem Client (gpupdate) eine Fehlermeldung ausgeworfen hat.

 

Ich habe die GPO dann wieder gelöscht und versucht den Fehler zu finden. Interessanterweise steht überhaupt nichts in den Eventlogs. Nur, dass die DFS-Replikation am Abend aufgrund einer Datensicherung gestoppt wurde / danach wieder ordnungsgemäß hochgefahren ist. Warnmeldung ist die Folgende:
 

Der DFS-Replikationsdienst beendet die Kommunikation mit Partner SRV-DC2 für Replikationsgruppe Domain System Volume aufgrund eines Fehlers. Der Dienst wird regelmäßig versuchen, die Verbindung wiederherzustellen.
 
Weitere Informationen:
Fehler: 9036 (Zum Sichern oder Wiederherstellen angehalten)
Verbindungs-ID: 2F1E8FC8-0634-4C46-A909-52A4ABEB0B94
Replikationsgruppen-ID: 13783446-D95B-4EB5-A4B2-4119C1F97545

Schließlich habe ich per DFS-Management-Konsole diverse Tests durchgeführt, die allesamt erfolgreich waren.

 

Dennoch: legte ich auf DC1 eine Datei in den Sysvol/Domain/policies-Ordner wurde diese nicht in das Sysvol des DC2 repliziert (auch nicht umgekehrt).

 

Irgendwann ist mir dann eingefallen, dass ich den Dienst DFS-Replikation auf beiden Servern noch neu starten könnte. Und - siehe da - die Replikation funktionierte plötzlich wieder in alle Richtungen:
DC1 file erstellt -> repliziert auf DC2 -> gelöscht auf DC2 -> wird gelöscht auf DC1

DC2 file erstellt -> repliziert auf DC1 -> gelöscht auf DC1 -> wird gelöscht auf DC2

 

Das funktioniert dann offenbar bis zum nächsten Tag. Ggf. ist der Auslöser ja die Sicherung, die am Abend stattfindet (bei der die Replikation angehalten wird.)

 

Was ich noch dazu sagen muss ist, dass die DFS Replikation vor einigen Monaten erst wiederhergestellt wurde, da sie fast 1 Jahr (ist niemandem aufgefallen) nicht mehr synchronisiert hat.  Hatte deshalb hier mal diesen Beitrag geschrieben (Stichwort MaxOfflineTimeInDays ):

Jegliche Tipps gerne gelesen

[NilsK 2.781]

Moin,

 

wie wird die Datensicherung denn ausgeführt?

 

Gruß, Nils

 

[mcdaniels 22]

Servus Nils,

es handelt sich beim DC1 um einen physischen Rechner (Datensicherung Arcserve UDP) und beim DC2 um eine VM (Datensicherung Veeam).

 

Danke!

LG

[NilsK 2.781]

Moin,

 

und auf welchem der DCs besteht das Problem mit dem DFS-Dienst?

Besteht das Problem auch, wenn du die Datensicherung temporär abschaltest?

Was wurde genau unternommen, als das DFS "repariert" wurde?

 

Gruß, Nils

 

 

 

[mcdaniels 22]

Hi,

die MaxOfflineTimeInDays wurde auf beiden DCs nach oben geschraubt und steht noch auf diesem Wert.

 

EDIT: Wert steht auf: 999

 

Backup hatte ich bislang noch nicht deaktiviert. Muss ich testen.

 

DFS Dienst wurde immer auf beiden Servern neu gestartet. Werd ich mal nur auf einem Server testen.

bearbeitet 19. Dezember 2018 von mcdaniels

[mcdaniels 22]

Die Datensicherung ist es nicht. Ist gerade gelaufen und fertig geworden. Eintrag betr. Datensicherung ist im Eventlog vorhanden. Replikation funktioniert.

[NilsK 2.781]

Moin,

 

laut den Fundstellen im Web gibt es eine ganze Menge an Ursachen für das Phänomen. Als Workaround könntest du einen geplanten Task einrichten, der den Dienst neu startet. Um das Problem dann zu lösen, würde ich einen Call beim Hersteller in Erwägung ziehen.

 

Gruß, Nils

 

[mcdaniels 22]

@Nilsk ja, das hab ich mir auch schon gedacht, mit dem Restart-Task. Vielen Dank für deinen Input.

 

LG

 

[NorbertFe 1.799]

Guten Abend,

 

irgendwie kommt mir das Problem bekannt vor. Hast du mal geprüft, ob es ggf. Hotfixes DFS-R bezogene Hotfixes gibt, die nicht per Windows Update oder WSUS verteilt werden und jetzt fehlen?

https://support.microsoft.com/en-us/help/2951262/list-of-currently-available-hotfixes-for-distributed-file-system-dfs-t

 

Bye

Norbert

[mcdaniels 22]

Hi Norbert,

danke für den Link.  Da würde ggf. das hier passen: https://support.microsoft.com/en-us/help/2996883/dfsr-stops-replication-after-an-unexpected-shutdown-in-a-windows-8-1-o   ist aber für Server 2012 R2 (nicht für  2012).

 

Folgendes kann ich an Informationen noch beisteuern: Die lange Phase in der die 2 DCs keine funktionierende DFS Replikation hatten, wurde dadurch verursacht, dass der DC1 immer wieder abgestürzt / neu gestartet ist. Daraufhin hat dann die Replikation nicht mehr funktioniert. Event ID: 4012. Der replizierte Ordner war zu lange offline (384 Tage). (Meldung auf DC1).

 

Es wurde -wie weiter oben erwähnt- die MaxOfflineTimeInDays auf den Wert 999 erhöht.

 

Nachdem es gestern normal funktioniert hat. Habe ich aktuell diesen Status:

 

DC1: File im Sysvol erstellt -> repliziert nicht auf DC2

DC2: File im Sysvol erstellt -> repliziert auf DC1

DC1: File im Sysvol gelöscht -> wird nicht auf DC2 gelöscht

DC2: File im Sysvol gelöscht -> wird auf DC1 gelöscht

 

D.h. das Problem besteht von DC1 -> DC2

 

Ein Restart des Dienstes DFS-Replikation auf DC1 reicht aus, um die Replikation DC1->DC2 wieder in Gang zu setzen.

 

Die Frage, die sich mir stellt, ist, was man aufgrund der Historie des Problems jetzt bestenfalls machen könnte.

 

Danke nochmals.

 

bearbeitet 21. Dezember 2018 von mcdaniels

[Nobbyaushb 1.355]

den DC1 depromoten und wieder neu als DC ins AD nehmen.

 

[NilsK 2.781]

Moin,

 

für mich klingt reines Neu-promoten nicht erfolgversprechend. Wenn man schon so einen Schritt macht, bei dem der DC länger offline ist und neu ins AD gebracht wird, dann würde ich gleich das ganze OS neu aufsetzen. Dauert nur wenig länger, hat aber das Potenzial, mehr zu beheben.

 

Ist aber die Frage, ob das (jetzt) sinnvoll ist, wenn es ein Workaround auch erst mal tut. Da könnte man ggf. nach einem besseren Zeitpunkt Ausschau halten, etwa wenn ein Wechsel der OS-Version ansteht. Abwägungssache.

 

Gruß, Nils

 

[mcdaniels 22]

Hallo Leute,

demoten werd ich ihn vorerst wohl nicht, nachdem alles andere ohne Probleme läuft. Trotzdem passts mir nicht, dass es nicht ganz rund läuft

Der DC1 macht auch noch WSUS und hat ein paar andere Services inne.

 

Die 999 Tage MaxOfflineTimeInDays sind zwar sehr hoch angesetzt, haben aber damit wohl nix zutun? Sollte man das besser wieder runtersetzen, oder ist das irrelevant?

bearbeitet 21. Dezember 2018 von mcdaniels

[Nobbyaushb 1.355]

vor einer Stunde schrieb NilsK:

Ist aber die Frage, ob das (jetzt) sinnvoll ist, wenn es ein Workaround auch erst mal tut. Da könnte man ggf. nach einem besseren Zeitpunkt Ausschau halten, etwa wenn ein Wechsel der OS-Version ansteht. Abwägungssache.

Da bin ich vollständig deiner Meinung.

@mcdaniels müsste mal auf einem DC nach den Default gucken...

[mcdaniels 22]

vor 50 Minuten schrieb Nobbyaushb:

müsste mal auf einem DC nach den Default gucken...

wie meinst du das?

bearbeitet 21. Dezember 2018 von mcdaniels