Bents Blog

Eigentlich mag ich DFS (Distributed File System) von Microsoft sehr, es ist seit Windows Server 2003 R2 im Betriebssystem integriert, verursacht keinerlei Zusatzkosten und ist relativ einfach einzurichten und zu administrieren. Außerdem bietet es mit Hilfe der Replikationsfunktion DFSR (Distributed File System Replication) einen Schutz für Dateien durch Schaffung von Redundanzen. DFSR hat dabei nichts mit FRS (File Replication Services) zu tun, bitte nicht verwechseln.

Allerdings sollte man wissen, dass DFSR seit der Version von Windows Server 2003 R2 ständig weiterentwickelt wurde und mittlerweile in der Version von Windows Server 2008 R2 sehr sinnvolle Verbesserungen erleben durfte. In der ersten Version replizierte DFSR eine Datei vollständig (also unabhängig von der Größe) sobald sich nur ein Byte änderte. Das ist wenig nützlich, hier ein Beispiel:

Typischerweise repliziert man mit Hilfe von DFSR die Benutzerordner einer Domäne (die via DFS-Stamm bereitgestellt und als Homelaufwerk verbunden werden). Auf dem Homelaufwerk kann ein Benutzer aber z.B. sein Archiv (PST-Datei) seines Outlook ablegen, welches über die Zeit kontinuierlich wächst (mehr als 1 GByte sind keine Seltenheit). Öffnet der Benutzer nun am Morgen sein Outlook, öffnet selbiges seine Archiv-Datei und setzt ein Filehandle und das Datum. Ergo: Die Datei wurde „verändert“ und wird nun brav vom DFSR Mitgliedsserver repliziert. Weiter muss ich – glaube ich – nicht ausholen. In der aktuellen Version macht DFSR hier einen Trick: Bei Dateien mit einer Größe unter 50 KByte wird bei einer Änderung die komplette Datei repliziert, ist die Datei größer, wird nur der geänderte Block synchronisiert. Clever und effektiv. Soweit zu meinem kleinen Exkurs. Weitere allgemeine Informationen zur DFSR findet man auf MSDN unter folgendem Link.

Problem

Doch nun zu meinem Problem. Wir nutzen in unserem eigenen Unternehmen DFS und DFSR seit einigen Jahren, auf der Basis von Windows Server 2003 R2 (Service Pack 2). Mittlerweile nutzen wir einen größeren DFS Stamm, verteilt auf mehreren Mitgliedsservern. Ein Verzeichnis wird jedoch im „Full-Mesh“ Modus zwischen 2 Servern repliziert. Da die Replikation einige Verzögerungen und Probleme im Netzwerk verursachte, habe ich die Replikation intensiver untersucht.

Die Einrichtung als auch die Administration von DFS und DFSR erfolgt typischerweise über die MMC DFS-Verwaltung. Hier können Namespaces, Mitgliedsserver und Replikationsgruppen erstellt und konfiguriert werden. Den Zustand der Replikation zeigt diese MMC allerdings nicht an, dazu benötigt man das Tool dfsrdiag. Der folgende Aufruf

dfsrdiag backlog /SendingMember:<Server1> /ReceivingMember:<Server2> /RGName:<Replication-Group>/RFName:<Replication-Folder>

lieferte mir die folgende Information:

Soweit so gut, es befand sich also noch 1 Datei in der Warteschlange – doch in der anderen Richtung (bei Full-Mesh gibt es in jeder Richtung eine Replikationsverbindung) brachte der Befehl

dfsrdiag backlog /SendingMember:<Server2> /ReceivingMember:<Server1> /RGName:<Replication-Group>/RFName:<Replication-Folder>

folgende Meldung:

Da ich keinerlei Fehlermeldung im DFS-Replikation-Ereignisprotokoll fand, machte ich mich nach der obigen Fehlermeldung im Netz auf die Suche. Eine der hilfreichsten Seiten zum Thema fand ich im Technet Blog des Directory Services Teams. Zwar stand nichts zu dem genannten Fehler, aber ich konnte weiter „forschen“.

Die interne Konfiguration von DFS uns DFSR (also auf Ebende des OS) erfolgt zum großen Anteil via WMI (Windows Management Instrumentation). Mit Hilfe des folgenden WMI-Befehls (auf der Kommandozeile ausgeführt)

WMIC /namespace:\\root\MicrosoftDfs path DfsrReplicatedFolderConfig

erhielt ich auf dem Server 1 detaillierte Informationen zur Konfiguration des replizierten Ordners. Auf dem Server 2 lieferte der selbe Befehl die folgende Rückmeldung:

Nun gebe ich nicht gleich auf, wenn etwas nicht gleich funktioniert. Also wollte ich die Instanz manuell mit Hilfe des Tools %SystemRoot%\system32\wbem\wbemtest.exe selber erzeugen, natürlich mit den korrekten spezifischen Werten für den betreffenden Server. Allerdings hat die Klasse DfsrReplicatedFolderConfig, der ich die Instanz hinzufügen wollte, folgende helfende Beschreibung:

Eine solche Instanz wird folglich nur beim Anlegen der Replikation erzeugt und kann nicht manuell erstellt werden.

Lösung

Aus diesem Grund musste ich die Replikation vollständig neu erstellen und dafür alle alten Konfigurationsdaten löschen. Dazu sollte man folgende Dinge beachten (für mein Beispiel ist Server 1 das funktionierende System, Server 2 das problembehaftete):

1. Backup der Daten (für den Fall das eben doch einmal etwas schief geht)
2. Ordnerziel des zu replizierenden Ordners auf dem Server 2 deaktivieren und anschließend entfernen (dadurch verbinden sich Clients nicht mehr mit dieser Freigabe)
3. Replikation beenden und löschen (ohne die Freigabe und die Daten auf dem Server 1 zu löschen)
4. Daten (sowie den Ordner) des zu replizierenden Ordners auf dem Server 2 komplett löschen

Danach kann man beginnen, die DFSR-Datenbank zu bereinigen bzw. zu entfernen. Dazu öffnet man den Explorer auf dem Server 1 und wechselt in den Unterordner [DfsrPrivate]. Dieser Ordner ist ein Systemordner und wird vom System versteckt. Alle darin enthaltenen Ordner können gelöscht werden, selbige werden bei der Neueinrichtung der Replikation automatisch erzeugt – die folgenden 4 Unterordner sollten existieren:

Danach wechselt man (auf Server 1 und Server 2) in die Wurzel des Laufwerks, auf dem sich der zu replizierende Ordner befindet. In diesem Bereich befindet sich der Ordner [System Volume Information], dem zuerst Leserechte des aktuellen Benutzers hinzugefügt werden müssen.

Der in diesem Ordner enthaltene Ordner [DFSR] enthält nun die gesamte Konfiguration der DFS-Replikation. Entfernt man alle darin enthaltenen Daten, so wird die DFSR-Konfiguration vollständig zurückgesetzt. Dafür muss vorher allerdings der DFSR-Dienst beendet werden, nach dem Löschen kann dieser erneut gestartet werden. Nach Abschluss dieser Arbeiten kann die Replikation für beide Server erneut eingerichtet und konfiguriert werden. Ohne dem Löschen der Daten im Ordner [<Laufwerk>:\System Volume Information\DFSR] konnte ich in meinem Fall zwar eine neue Replikation einrichten, der oben dokumentierte Fehler trat danach aber sofort wieder auf dem Server 2 auf. Erst die Entfernung der DFSR-Konfiguration führte zum Erfolg und zur Lösung des Problems.

Fazit

Ich glaube, an Hand der Größe des Artikels ist erkennbar, wie umfangreich die Konfiguration als auch die Fehlersuche bei Einsatz von DFSR ist. Bei Fragen zum Vorgehen oder auftauchenden Problemen nutzt bitte die Kommentar-Funktion. Wie bei allen meinen anderen Beiträgen gilt auch hier wieder: Bei Tipps, Vorschlägen sowie Fragen oder Kritiken hinterlasst bitte einen Kommentar.

Einen Blog am Leben zu erhalten kostet Zeit und Geld. Da ich auf meiner Seite weder Werbung einbinde, noch andersweitige Zuwendungen erhalte, freue ich mich über jede kleine Spende. Einfach und unkompliziert geht das über PayPalMe. Du unterstützt damit diesen Blog. Vielen Dank.