Fehler DFS-Replikation

[Friesenjunge 17]

Moin zusammen,

folgende Situation:

 

Wir betreiben an zwei Standorten jeweils einen Fileserver, auf dem zwei Verzeichnisse als separate Replikationsgruppe angelegt sind.

 

Da das Betriebssystem veraltet ist (Windows Server 2008 R2, JA, ich weiß) , soll diese DFS Umgebung auf einen aktuellen Server migriert werden.

Der Kollege, dem das anvertraut wurde, hat folgendes gemacht:

Einen neuen File-Server (unter Windows Server 2019 Datacenter, auch nicht perfekt, aber Lizenzen und Cals für 2022 sind geordert) aufgesetzt.

Dort die DFS-Dienste installiert, ein entsprechendes Verzeichnis angelegt und freigegeben und diesen Server der Replikationsgruppe als Mitglied hinzugefügt.

 

Seitdem replizieren die Server nicht mehr.

Dann wurde ich zur Hilfe gerufen.

 

Festgestellt habe ich, dass beim Absetzen des folgenden Befehls in einer administrativen Kommandozeile der ebenfalls folgende Fehler ausgegeben wird:

dfsrdiag PollAD /Member:DOMAIN\\Server1

Zitat

[FEHLER] Fehler beim Ausfhren der PollDsNow-Methode. Err: -2147217406 (0x80041002)
[FEHLER] Fehler beim Ausfhren des PollAD-Befehls Err: -2147217406 (0x80041002)
Fehler bei Vorgang

 

Daraufhin habe ich den Windows WMI Dienst geprüft und neu gestartet.  Ebenfalls den DFS-Dienst

Nach dem Neustart des WMI-Dienstes bleib bei "dfsrdiag PollAD /Member:DOMAIN\\Server1" der Fehler aus und es wurde gemeldet, dass der Vorgang erfolgreich abgeschlossen wurde.

 

Danach habe ich mit folgendem Befehl versucht, die Replikation manuell anzustoßen:

dfsrdiag SyncNow /Partner:<Domain>\<Server> /RGName:<Replikationsgruppenname> /Time:<DauerInMinuten>

 

Auch hier kein Fehler.

Dennoch wird nicht repliziert.

Im Eventlog wird auch brav gemeldet, dass geänderte Dateien erkannt wurden und die Replikation durchgeführt wird. jedoch werden die Änderungen in keine Richtung übertragen.

 

Ich weiß jetzt nicht weiter.

 

Hinweis: Beide Server wurden nicht neu gestartet. das werde ich per Task Scheduler über Nacht durchführen, weil Abhängigkeiten von anderen Systemen (ERP) zu den Daten in den Replikationsgruppen bestehen, das ist im laufenden Betrieb über den Tag leider nicht möglich.

 

 

Meine Idee ist, ein völlig neues DFS mit zwei völlig neuen Servern, die identisch sind (OS, Patchlevel), aufzubauen.

Dann die Inhalte der betroffenen Replikationsgruppen per Robocopy mit der Option, nur neuere Dateien zu kopieren, in die neuen DFS-Verzeichnisse zu kopieren.

 

Bis dahin soll aber der bestehende DFS wieder rund laufen.

Was kann ich hier tun?

 

Ich bin für jede konstruktive Anregung dankbar! Bitte keine Hinweise darauf, dass die eingesetzte OS-Version veraltet ist. Das weiß ich und das wollen wir ja abstellen.

 

Herzlichen Dank und viele Grüße

Euer Friesenjunge

 

 

bearbeitet Mittwoch um 10:25 von Friesenjunge
Hatte etwas vergessen...

[vkf 0]

Warum jetzt kein Server 2025?

[Friesenjunge 17]

vor 1 Minute schrieb vkf:

Warum jetzt kein Server 2025?

Entscheidung des Mutterkonzerns.

[vkf 0]

Hast den belegten Plattenplatz nochmal frei auf beiden Seiten?

[NilsK 2.990]

Moin,

 

fangen wir mal vorne an: Was wollt ihr mit dem DFS erreichen? Für viele Use Cases ist das keine gute Lösung, daher verdient das ggf. einen kritischen Blick.

 

Gruß, Nils

 

[vkf 0]

Oh, der Motor deines Autos qualmt und deine Autoreifen sind nciht mehr gut? Dann nimm doch einfach einen Helikopter.

[Friesenjunge 17]

vor 2 Stunden schrieb vkf:

Hast den belegten Plattenplatz nochmal frei auf beiden Seiten?

Ja, ca. 25 %

 

vor 2 Stunden schrieb NilsK:

[...]Was wollt ihr mit dem DFS erreichen?[...]

 

Moin Nils,

Wir sind ein Konzern mit mehreren Standorten.

Ursprünglich Mitbewerber, durch Zukauf jetzt Teil der Familie, soweit zur Historie.

 

Es gibt diverse Fileserver mit Freigaben.

Um Standortübergreifend bestimmte Daten performant verfügbar zu halten, wurden DFS Replikationsgruppen gebildet und im AD veröffentlicht. Es werden dort ausschließlich reine Dateien (PDF, XLSX, DOCX, etc. ...) abgelegt, keine Datenbanken oder ähnliche Sachen.

So gibt es z.B.:

• \\<unsereDomain>\Standortübergreifend (enthält Dateien, die über die Abteilungen überall verfügbar sein sollen)
• \\<unsereDomain>\CMS (Dateiablage unseres ERP, in dem fertige Dokumente, z.B. Angebote, Rechnungen, etc. ...) abgelegt werden.

Active Dirextory Standorte und Dienste ist sauber mit allen Netzwerksegmenten gepflegt.

Im Loginscript werden die entsprechenden Laufwerke nach dem Schema \\<unsereDomain>\<Freigabename> verbunden.

Die Clients verbinden sich dann mit dem nächstgelegenen Server.

Das funktioniert gut und hat sich bewährt.

 

Welche Alternativen schlägst Du denn vor? Nur, damit wir uns nicht die Mühe machen, alles einzurichten, obwohl es eine für uns passendere Lösung gibt.

 

 

BTW:
Nach Reboot des einen Servers mit dem WMI-Problem repliziert alles wieder sauber!

Offensichtlich wurden auch die während des Fehlerfalles durchgeführten Änderungen "nachgezogen".

Eine eingehende Prüfung ergab, dass weder Daten fehlen, noch in einer falschen Version vorliegen.

 

Das Problem ist also behoben.

Danke!

bearbeitet Donnerstag um 10:32 von Friesenjunge

[NilsK 2.990]

Moin,

 

okay, prima, das ist ja gut zu hören. Auf das Naheliegende - Reboot tut gut - kommt man manchmal ja erst verzögert. Kenn ich.

 

Ob DFS für euren Use Case eine gute Wahl ist, könnte man unabhängig beleuchten. Ich bin aus Prinzip immer skeptisch, wenn Replikation im Spiel ist, weil das oft eine "teure" Lösung ist in dem Sinne, dass man sich erhebliche Risiken einkauft. Gerade DFS ist in vielen Umgebungen ein dauernder Problemquell. So erwähnst du verteilte Zugriffe - dass dort Datenverluste drohen, weil DFS-R die simple Logik "Last Writer Wins" umsetzt, ist hoffentlich bekannt?

 

Gruß, Nils

 

[Friesenjunge 17]

vor 30 Minuten schrieb NilsK:

[...]So erwähnst du verteilte Zugriffe - dass dort Datenverluste drohen, weil DFS-R die simple Logik "Last Writer Wins" umsetzt, ist hoffentlich bekannt?[...]

 

Das ist bekannt. Das hat in der Vergangenheit aber noch nie bei uns zu Konflikten geführt.

Wir nutzen das schon seit 2017.