DFS-Replikationsfehler 9098 (veralteter Inhalt)

Question

3 Server, die DFS-Replikation funktionierte 2 Jahre lang. Vor Kurzem meldete einer der Mitgliedsserver Folgendes:

The DFS Replication service stopped replication on replicated folder projects at local path Z:\projects due to Error ID: 9098 (A tombstoned content set deletion has been scheduled). Event ID: 4004

Egal was ich tue, dieser Server meldet weiterhin denselben Tombston-Fehler. Nichts wird zu/von diesem Problemserver repliziert.

Ich habe sogar auf jedem der drei Mitgliedsserver eine neue Freigabe erstellt. Dann habe ich einen neuen Namespace erstellt und die DFS-Replikation aktiviert. Zwei Server replizieren ohne Probleme, aber der eine Problemserver meldet immer noch einen Tombstoned-Fehler.

Ich habe versucht, die DFS-Replikationsrolle zu entfernen/neu zu installieren, aber das passiert immer noch.

Ich bin hier völlig ratlos, irgendwelche Ideen? Pings vom Problemserver zu anderen sind in Ordnung. „Topologie überprüfen“ funktioniert im DFS-Manager einwandfrei.

Answer 1

Versuche Folgendes:

1. Suchen Sie in der Ereignisanzeige nach allen Replikationsgruppen/-ordnern, die den Tombstone-Fehler verursachen. Sobald Sie sie identifiziert haben, gehen Sie in die DFS-Verwaltungs-GUI und löschen Sie die mit diesem Ordner verknüpfte Replikationsgruppe vollständig. Sie müssen den DFS-Namespace für diesen Ordner nicht löschen, sondern nur die Replikationsfunktionalität dieses Namespace-Ordners. Wenn Sie in Ihrem DFS-R andere Replikationsgruppen haben, die die 9098-Fehler nicht erhalten, müssen Sie dies für diese Ordner nicht tun.

2. Stoppen Sie die DFSR-Dienste (Sie müssen den Dienst möglicherweise mit dem Befehl „taskkill“ beenden, wenn er beim Stoppversuch hängen bleibt).

3. Geben Sie sich selbst Berechtigungen für den versteckten Ordner „System Volume Information“. Wenn Ihr Konto zur Gruppe der Domänenadministratoren gehört, können Sie einfach die Sicherheitsgruppe hinzufügen. Dieser Ordner existiert auf allen Servern, die Mitglied der Replikationsgruppe sind. In meinem Fall haben 2 der 3 Server diesen Ordner nicht als vorhanden angezeigt, selbst als ich die Anzeige versteckter Ordner aktiviert habe. Wenn Ihnen das passiert, lügt Sie der Server an, indem er sagt, dass er nicht da ist. Er ist da. Hören Sie nicht darauf. Ich schlage vor, dass Sie den Dateimanager 7-zip herunterladen und verwenden. Er erkennt den Ordner und hilft Ihnen, die Berechtigungen dafür festzulegen sowie Dateien zu löschen, die länger als 256 Zeichen sind (was ein Problem ist, wenn Sie den nächsten Schritt über die Befehlszeile ausführen). Beachten Sie, dass Ihnen nach dem Festlegen der Berechtigungen möglicherweise angezeigt wird, dass Sie immer noch keinen Zugriff auf diesen Ordner haben. Schließen Sie 7-zip einfach und öffnen Sie es erneut. Sie sollten nun auf diesen Ordner und seine Unterordner zugreifen können.

4. Sobald Sie Zugriff auf diesen Ordner haben, löschen Sie den darunter liegenden DFSR-Ordner. Sie sollten dies auf allen Servern tun, auf denen die DFSR-Rolle installiert ist und die Mitglied einer Replikationsgruppe sind. Sie können den Befehlszeilenbefehl „rmdir“ verwenden, dieser löscht jedoch keine Dateien/Ordner, die länger als 256 Zeichen sind. Aus diesem Grund ist der Dateimanager 7-zip eine bessere Option, um den DFSR-Ordner unter System Volume Information zu löschen. Es gibt jedoch Fälle, in denen 7-zip eine Datei oder einen Ordner nicht löschen kann. Wenn Sie in diesem Szenario arbeiten, verwenden Sie den Befehl rmdir in einer Eingabeaufforderung mit erhöhten Rechten. Im Wesentlichen wird eine Kombination dieser beiden Befehle schließlich alles löschen, was Sie löschen müssen.

5. Schalten Sie die DFSR-Dienste wieder ein. Dadurch wird der Vorgang zur Neuerstellung des DFSR-Hashes und des virtuellen Baums gestartet, den Sie gerade gelöscht haben.

6. Erstellen Sie die gewünschte Replikationsgruppe neu.

7. Bei den Replikationsgruppen, die Sie nicht gelöscht haben, erhalten Sie möglicherweise die Warnung: „Der DFS-Replikationsdienst hat den replizierten Ordner im lokalen Pfad initialisiert und wartet auf die erste Replikation. Der replizierte Ordner bleibt in diesem Zustand, bis er direkt oder indirekt replizierte Daten vom angegebenen primären Mitglied erhalten hat.“ Wenn Sie dies tun, müssen Sie die Befehlszeile ausführen, um einen der DFSR-Server als primären Server für diese Replikationsgruppe festzulegen. Sobald dies festgelegt ist – das ist wichtig – müssen Sie in die DFS-Verwaltungs-GUI gehen, auf die Replikationsgruppe mit der zugehörigen Warnung klicken, die Registerkarte „Verbindungen“ auswählen und dann mit der rechten Maustaste auf das sendende Mitglied klicken, das Sie gerade als primär festgelegt haben, und „Jetzt replizieren …“ auswählen. Dadurch wird die Replikation initialisiert, und Sie müssen dies nur dieses eine Mal tun, damit sie von nun an repliziert werden kann. Sie müssen die Option „Jetzt replizieren …“ für jedes empfangende Mitglied auswählen, an das der sendende Mitglieds-/Primärmitgliedsserver in dieser Replikationsgruppe angeschlossen ist.

8. Warten Sie etwa 5–10 Minuten und führen Sie den Befehl „dfsrdiag backlog“ für jede Replikationsgruppe aus. Prüfen Sie, ob ein Rückstand für die Replikation/Synchronisierung erstellt wird. Führen Sie diesen Befehl alle 5 bis 10 Minuten aus, um zu prüfen, ob der Wert für die Anzahl der Rückstandsdateien abnimmt. Wenn dies der Fall ist, wird eine Synchronisierung/Replikation durchgeführt.

PS: Wenn Sie DFS-R nur aus Gründen der Ausfallsicherheit verwenden, ist dies nicht der beste Weg, dies zu erreichen. Sehen Sie sich die hochverfügbare FileServer-Rolle im Failovercluster an, beispielsweise wie folgtHier

Answer 2

Habe das Problem gefunden. Der Ordner „System Volume Information/DFSR“, den ich gelöscht habe, befand sich auf Laufwerk C, NICHT auf Laufwerk Z, auf dem die Freigaben vorhanden sind! Sobald ich Z:\System Volume Information/DFSR gelöscht habe, war das Problem behoben.