Update 27.01.2009 

Hi, Fabian hier. Möglicherweise möchte man einen oder mehrere Replikationsgruppenmitglieder eines via DFS-R replizierten Ordners unter Windows Server 2003 R2 noch einmal durch die Initialreplikation laufen lassen, um so etwa einen konsistenten Datenbestand auf verschiedenen Servern herbeizuführen. Dies kann etwa dann sinnvoll sein, wenn die DFS-Replikation aus verschiedensten Gründen nicht korrekt lief. Ein konkretes Beispiel wäre, daß für einen Zeitraum X die Netzwerkverbindung zwischen zwei Standorten nicht verfügbar war und auf beiden Seiten der Replikationspartner gearbeitet wurde. Somit müßte man sich auf die DFS-R eigenen Methoden zur Konfliktlösung verlassen, was in der genannten Konstellation unter Umständen nicht gewünscht ist, da hierbei die Daten je nach „Gewinner“ eines Konflikts vermengt (merged) werden würden.

Der einfachste Weg scheint dann der zu sein, den Mitgliedsserver, der die forcierte Initialreplikation „verlieren“ soll, aus der Replikationsgruppe zu entfernen, diese Änderung auf alle DCs und DFS-R Replikationspartner replizieren bzw. anwenden zu lassen und danach den Server wieder der Replikationsgruppe hinzuzufügen.

Hierbei gibt es jedoch einen Stolperstein zu beachten: Der entfernte Server wird in der DFS-R Datenbank nicht vollständig entfernt – vielmehr wird ein Tombstone auf das entsprechende Objekt gesetzt, welches wieder reaktiviert wird, wenn der Server erneut in die Replikationsgruppe aufgenommen wird, ohne daß signifikante Änderungen an der Konfiguration stattgefunden haben (z.B. der Replikationsordner auf ein anderes Volume verschoben wurde o.ä.). Dieser Tombstone gilt für 30 Tage – erst danach wird der entsprechende Server wie ein vollkommen neu hinzugefügter Replikationspartner in dieser Replikationsgruppe behandelt.

Wurde nun – wie oben beispielhaft beschrieben – auf beiden oder mehreren Seiten gearbeitet, werden bei einem einfachen Neu-Hinzufügen des alten Servers die normalen Konfliktlösungsmechanismen in Kraft treten. Im Grunde läuft also die Replikation an der Stelle weiter, zu der sie zuletzt aufgehört hat. Und genau hier kann in dem genannten Szenario ein Problem liegen, denn man riskiert hier einen inkonsistenten Zustand der Daten durch die Änderungen, die für einen später kaum noch nachvollziehbar sind.

Um den gewünschten Effekt der Initialreplikation für den erneut hinzugefügten Server zu erreichen, kann man eine der folgenden Methoden wählen:

  1. Man entfernt den Server nicht aus der jeweiligen Replikationsgruppe, sondern man deaktiviert lediglich die Mitgliedschaft dieses Servers. Möchte man dann die Mitgliedschaft wieder aktivieren, muß man die Pfade zum Replikationsordner etc. neu angeben und die Initialreplikation läuft nun wie gewünscht mit dem erneut aktivierten Server als „Datennehmer“, also nicht-autorativen System.

  2. Man kann mehr als 30 Tage warten, bis man den Server wieder der Replikationsgruppe hinzufügt.

  3. Man sorgt dafür, daß die Daten auf dem neu hinzuzufügenden Server nicht neuer sind als die auf den gewünschten Quellsystemen, also autorativen Servern. Hierbei wäre weiterhin zu beachten, daß keine gänzlich neuen Dateien oder Ordner auf dem Zielsystem existieren dürfen, die auf den autorisierenden Systemen nicht vorhanden sind. Dies ist jedoch kaum auszuschließen, wenn auf beiden Seiten gearbeitet wurde, während keine Replikation stattfand.
    Die radikalste Lösung wäre natürlich das Löschen der Daten auf dem Server, der „Datennehmer“ sein soll, oder das Rücksichern eines alten Backups. Hierbei ist jedoch zu beachten, daß sich eine Rücksicherung auf alle Replikationsordner des Laufwerks / Volumes auswirken kann, auf dem der zurückgesicherte Replikationsordner liegt. Diese Backup-Methode würde ich daher nicht empfehlen. Hierzu werden wir später einen weiteren Blog Eintrag veröffentlichen. In Bezug auf das Löschen der Daten vom Zielsystem müßte auf die erhöhte Last auf den WAN Leitungen als auch der erhöhten Last auf den DFS-R Systemen geachtet werden, weshalb ich auch diese Variante nicht empfehlen würde.

Möchte man also den alten Server wieder der entsprechenden Replikationsgruppe hinzufügen und soll dieser "Datennehmer", also nicht autorativ für die replizierten Daten sein, ist das empfohlene Vorgehen ganz klar die Mitgliedschaft zu deaktivieren und danach wieder zu aktivieren.

Update 27.01.2009
Zusätzlich zum Blog Eintrag haben wir einen KB-Artikel zu dem Thema fertig gemacht, der nun veröffentlicht wurde: 961655 After you re-add a member server to a DFS replication group in Windows Server 2003 R2, initial replication does not occur on the member server, and changes in the replicated folder are replicated unexpectedly to other replication partners http://support.microsoft.com/default.aspx?scid=kb;EN-US;961655

Viele Grüße, Fabian.