none
Dateireplikation zwischen zwei Standorten mittels DFSR RRS feed

  • Frage

  • Guten Tag Zusammen

    Ich habe bei einem unserer Kunden ein grösseres Problem mit DFSR. Die Replikation zwischen dem Hauptstandort und einer Nebenstelle funktioniert nicht einwandfrei. Mal eine kurze Beschreibung zur Umgebung.

    Hauptstandort:

    Am Hauptstandort haben wir einen Cluster aus zwei Servern und einen Storage dazu. Es laufen mehrere File-Server und auch zwei DCs.

    Nebenstandort:

    Am Aussenstandort haben wir ein NAS, auf welchem wir einen Windows Server (virtuell) betreiben, welcher dazu dient, dass wen die VPN Verbindung zwischen den Standorten abbricht, die Mitarbeiter an diesem immer noch auf sämtliche Projekt und Abteilungsdaten zugreifen können.

    Zum genauen Problem.

    Wir betreiben jetzt zwei verschiedenen Replikationsgruppen, welche die Daten zwischen dem Server am Aussenstandort und zweier Server am Hauptstandort synchronisieren sollte. Dabei sind die Server am Hauptstandort die Primären Server der Replikationsgruppen. Die Daten am Hauptstandort liegen nicht auf dem selben virtuellen Server. Seit wir vor drei Wochen von SSL-VPN (site-site) auf IPsec (site-site) umgestellt haben, läuft diese Synchronisierung überhaupt nicht mehr rund. Auf dem Sever am Aussenstandort kann ich im Log auslesen, dass er mit alle 20 Sekunden die folgende Warnmeldung ausgibt:

    Der DFS-Replikationsdienst beendet die Kommunikation mit Partner Remoteserver für Replikationsgruppe domain.local\Freigabe\Ordner aufgrund eines Fehlers. Der Dienst wird regelmäßig versuchen, die Verbindung wiederherzustellen. 
     
    Weitere Informationen: 
    Fehler: 1726 (Der Remoteprozeduraufruf ist fehlgeschlagen.) 
    Verbindungs-ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 
    Replikationsgruppen-ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

    (Fettgedruckt = Aufgrund von Datenschutz geändert)

    Auf den Servern (also auf beiden) am Hauptstandort bekomme ich hingegen die folgende Fehlermeldung:

    Fehler beim DFS-Replikationsdienst bei der Kommunikation mit Partner "Remoteserver" für Replikationsgruppe "domain.local\Freigabe\Ordner". 
      
    Partner-DNS-Adresse: Server.domain.local
      
    Optionale Daten, falls verfügbar: 
    Partner-WINS-Adresse: Server
    Partner-IP-Adresse: Server-IP 
      
    Der Dienst versucht regelmäßig, die Verbindung erneut herzustellen. 
     
    Weitere Informationen: 
    Fehler: 1727 (Der Remoteprozeduraufruf ist fehlgeschlagen und wurde nicht ausgeführt.) 
    Verbindungs-ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 
    Replikationsgruppen-ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

    (Fettgedruckt = Aufgrund von Datenschutz geändert)

    Noch ein par zusätzliche Informationen zu den Fehlermeldungen:

    Am Nebenstandort handelt sich um die Ereignis-ID: 5014

    Am Hauptstandort handelt es sich um die Ereignis ID: 5002

    Noch als kleine Info zum Server am Ausstandort als Ergänzung. Der Server war bis gestern Abend (10.11.2020) auch noch Domain Controller. Ich haben diesen allerdings demoted, um aus zu schliessen, das dies mitunter ein Grund für den Fehler ist.

    Solltet ihr noch weitere Infos benötigen, meldet euch doch, dann kann ich diese noch nach reichen.

    Gruss und danke im Voraus ;)

    Mittwoch, 11. November 2020 08:35

Antworten

  • Hallo Snadro,

    ich vermute, dass das Problem mit einer instabilen WAN-Verbindung zusammenhängt. Du kannst die Netzwerkablaufverfolgung erfassen, um festzulegen, ob die Ursache des Problems auf der Netzwerkebene liegt. 

    In der Zwischenzeit schlage ich vor, dass Du die DEBUG-Protokolle für die DFS-Replikation überprüfst, die sich im Ordner %szstemroot%\debug befinden. 

    Diese Dokumente können Dir bei der Behebung des Problems der DFS-Replikation helfen.

    Top 10 Common Causes of Slow Replication with DFSR

    Grüße,

    Mihaela


    Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Donnerstag, 12. November 2020 00:31
    Moderator