DFS-R Replikation nur in eine Richtung. Replikation beim ausgehenden Datenverkehr bleibt beim eingehenden Datenverkehr hängen.

DFS-R Replikation nur in eine Richtung. Replikation beim ausgehenden Datenverkehr bleibt beim eingehenden Datenverkehr hängen.

Ich habe ZWEI Windows 2012 R2-Server mit identischen Pfaden und Laufwerksnamen (nicht absichtlich).

Wenn ich einen Ordner auf Server A erstelle, wird dieser sofort auf Server B repliziert. Wenn ich jedoch einen Ordner auf Server B erstelle, wird dieser nicht auf Server A repliziert.

Ich habe die DFS-Diagnose ausgeführt und sie hat nichts gefunden. Wenn ich jedoch einen Ausbreitungstest von Server B zu Server AI ausführe, erhalte ich keinen Fehler. Nur eine Warnung, dass der Test unvollständig ist.

Ich habe einen Test, der 6 Tage alt ist (Dateireplikationstest). Der Replikationsstatus für diese Testdatei bleibt bei „Ankunft ausstehend“ hängen.

Bedenken Sie, dass sich Löschungen von Server A auf B problemlos reproduzieren lassen. Alles von B auf A funktioniert nicht.

Soweit ich weiß, ist alles richtig eingerichtet und es liegen keine Fehler vor.

Die Datenmenge beträgt etwa 6 TB und wurde vorab vorbelegt. Die Replikation erfolgt zwischen einem Dateiservercluster und einem Einzelserver. Die DFS-Beziehung besteht seit über 3 Wochen.

Ideen?

Antwort1

Es gibt viele Gründe, warum eine Replikation fehlschlagen kann. Leider helfen Symptome allein hier nicht weiter.

Können Sie bitte die Informationen unterhttp://blogs.technet.com/b/askds/archive/2009/04/09/dfsr-debug-log-series-wrapup-and-downloadable-copies.aspxund dann die Frage mit allen spezifischen Debug-Protokolleinträgen aktualisieren, die Sie von beiden Servern sehen?

Da Sie 2012 R2 verwenden, ist das Blog zwar etwas veraltet, aber es wird Ihnen trotzdem helfen.

Machen Sie bitte nur Einträge, die sich speziell auf diesen Ordner beziehen.

Alternativ schlage ich vor, Folgendes zu tun, um B mit A neu zu initialisieren.

  1. Sichern Sie B. Dies ist erforderlich, wenn Sie Endbenutzer haben, die Änderungen an B vorgenommen haben, aber nicht wissen, dass diese nicht auf A repliziert wurden. Die folgenden Schritte setzen alle Daten auf B auf die Versionen von A zurück, was zu einem gewissen „Datenverlust“ führen kann, wenn die Änderungen an B nicht gesichert wurden.

  2. Deaktivieren Sie B als Mitglied für diesen replizierten Ordner (RF) mithilfe der DFS-Konsole auf B. Dadurch wird die Konfiguration für die Topologie auf einem DC aktualisiert, der B am nächsten ist (oder vielmehr einem, den B gerade verwendet).

  3. Führen Sie einen „dfsrdiag pollad“ auf B durch, damit es die Topologieänderungen von AD liest

  4. Führen Sie „wmic /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo get replicatedfoldername,replicationgroupname,state“ aus. Stellen Sie sicher, dass der Ordner NICHT in der Liste angezeigt wird. (Bearbeitet: WMIC-Namespace behoben).

  5. Suchen Sie nach einem Ereignis 4114, das anzeigt, dass die Replikation des Ordners beendet wurde

  6. Suchen Sie optional auch in den Debug-Protokollen nach Einträgen von ldbmanager::deleteidrecords, die darauf hinweisen, dass die Datenbank bereinigt wurde.

  7. Aktivieren Sie das B-Mitglied mithilfe der DFS-Konsole auf B erneut.

  8. Führen Sie ein „dfsrdiag pollad“ auf B durch, um sicherzustellen, dass die Änderungen übernommen werden

  9. Wenn sich A und B an unterschiedlichen Standorten befinden und Sie B deaktivieren/aktivieren, bevor A es bemerkt, müssen Sie bei A nichts unternehmen. Andernfalls müssen Sie möglicherweise auch die Latenz der AD-Replikation berücksichtigen und warten, bis die AD-Änderungen auf den von A verwendeten DC konvergieren. Führen Sie dann ein „dfsrdiag pollad“ aus, um sicherzustellen, dass jede von Ihnen vorgenommene Topologieänderung (also das Deaktivieren und anschließende Aktivieren des Mitglieds) erkannt wird.

  10. Führen Sie „wmic /namespace:\root\microsoftdfs path dfsrreplicatedfolderinfo get replicatedfoldername,replicationgroupname,state“ aus. Stellen Sie sicher, dass der Ordner schließlich den Status 4 erreicht. Weitere Details zum Status finden Sie hierhttp://blogs.technet.com/b/filecab/archive/2008/10/27/how-to-check-if-the-initial-replication-was-completed-successfully.aspx

Wenn das Problem dadurch immer noch nicht behoben werden kann, sind Debug-Protokolleinträge erforderlich, um eine genauere Antwort zu geben.

Ich fürchte, ich werde nicht in der Lage sein, immer wieder Fragen zur Fehlerbehebung hin und her zu beantworten. Ich schlage vor, einen Fall beim Microsoft-Support zu eröffnen, wenn Sie weitere Hilfe benötigen. Andere auf der Site haben möglicherweise Zeit, Ihnen zu helfen.

Antwort2

Haben Sie diese Volumes zufällig erstellt, indem Sie virtuelle Festplatten oder ganze VMs ohne Sysprepping geklont haben? Das klingt, als ob die Laufwerksseriennummer oder die Volumeseriennummer zwischen den beiden Servern nicht eindeutig sind, was dazu führt, dass DFS-R fehlschlägt.

verwandte Informationen