Mit der Einführung von DFS-R in Windows Server 2003 R2 wurde die Replikation von Daten im Distributed Filesystem auf ein bis dahin unbekanntes Niveau gehoben. Während in älteren Windows Server Versionen die Dateien noch über FRS synchronisiert wurden, hilft die neue Technologie in Windows Server 2003 R2, Windows Server 2008 und Windows Server 2008 R2, eine zuverlässige Replikation großer Datenmengen durchführen zu können.
Die Grundlage für die Metadaten im DFS-R ist eine Datenbank im ESE-Format namens DFSR.DB. Wenn diese Datenbank zerschossen wird, dann ist dies auf offiziellem Weg nicht reparabel. Ein typischer Fehler ist hier die Event ID 476 von der Quelle ESENT. Bei Auftreten dieses Problems weist die Fehlermeldung auf eine leere Seite in der Datenbank hin. In diesem Zustand stellt Windows Server die Dateireplikation vollständig ein.
Ein eleganter Weg zur Reparatur ist der Einsatz des vor allem von Exchange Server bekannten Tools ESEUTIL. Damit man die DFSR-Datenbank reparieren kann, muss man dies im Systemkontext tun und das DFS auf dem betroffenen System in den Diensten herunterfahren. Um im Systemkontext arbeiten zu können, nutzt man zum Beispiel PsExec aus Microsofts Windows Sysinternals Tools mit dem Parameter /S.
Vor einer Reparatur der Datenbank sollte man den gesamten Datenbankordner (System Volume InformationDFSRdatabase_…) kopieren und die Reparatur auf der Kopie durchführen. Die Reparatur erfolgt dann über ESEUTIL /P, die Integrität der Datenbank kann mit ESEUTIL /G überprüft werden. Nach einer erfolgreichen (und mit ESEUTIL /G überprüften) Reparatur kopiert man das Verzeichnis zurück und startet das DFS wieder neu.
Die Reparatur erfolgt mit folgenden Schritten:
1. DFS-Dienste beenden.
2. Über “psexec -S cmd.exe” eine Befehlszeile im Systemkontext aufrufen.
3. DFS-Datenbankverzeichnis (System Volume InformationDFSRdatabase_…) kopieren auf einen lokalen Pfad.
4. In den lokalen Pfad wechseln.
5. Mit “eseutil /g dfsr.db” die Integrität überprüfen. Dies sollte negativ quittiert werden.
6. Mit “eseutil /p dfsr.db” die Datenbank reparieren.
7. Mit “eseutil /g dfsr.db” erneut die Integrität überprüfen. Jetzt sollte kein Fehler mehr ausgegeben werden.
8. DFS-Datenbankverzeichnis zurück kopieren.
9. DFS-Dienste starten.
Auch wenn sich über diesen Weg in vielen Fällen eine Neuinstallation vermeiden lässt, kann die undokumentierte (und damit vom Hersteller wohl eher nicht supportete) Vorgehensweise ggf. auch in anderen Situationen erfolglos verlaufen. In jedem Fall sollte man nach der Reparatur die Replikation intensiv testen und einige Tage kritisch beobachten.