7
DFS Replikation - Schlägt fehl - Event 4302
Hallo Zusammen,
ich bin dabei mich in die DFS-Replikation einzuarbeiten und habe dabei ein doch sehr großes Problem entdeckt...
Zur Basis:
Windows Server 2012 R2
DFS Replikation zwischen zwei APP's
Namespace angelegt
Replikationspartner angelegt
Replikation wurde initial einmal ausgeführt
Also funktioniert es in erster Linie...
In zweiter Linie kann eine bestimmte Datei nicht repliziert werden, weil diese im Zugriff ist?
Eventlog:
The DFS Replication service has been repeatedly prevented from replicating a file due to consistent sharing violations encountered on the file. A local sharing violation occurs when the service fails to receive an updated file because the local file is currently in use.
Additional Information:
File Path: E:\FORMS\AVW\FRM_ORDER.fmx
Replicated Folder Root: E:\FORMS
File ID: {0DF4F9C9-0432-4FBF-B043-14A82D755603}-v502849
Replicated Folder Name: FORMS
Replicated Folder ID: 0A6AAAB4-91BD-438C-8C67-DAD80A07A867
Replication Group Name: "Domäne"\apps\forms
Replication Group ID: FCFDA16A-8D9A-4E4E-B943-3F00B86921F7
Member ID: C3FB5A75-5472-408E-BCB6-B2664DC4192B
Event ID: 4302
Level: Warning
Da diese Datei ständig verändert wird (Versionsstände, etc..) und von vielen Benutzern in der Domäne genutzt wird (ist für ein Hauptprogramm erforderlich, quasi wie eine Config) muss diese auf beiden Servern immer aktuell sein und am Besten fast zeitgleich repliziert werden.
Wenn ich "dfsrdiag.exe replicationstate" ausführe, wird mir ebenfalls diese Datei in der Warteschlange zum replizieren angezeigt.
Updates scheduled:
[1] Update Name: FRM_ORDER.fmx
Total number of inbound updates scheduled: 1
Es passiert aber 0...
Was kann ich tun?
Danke und Gruß!
ich bin dabei mich in die DFS-Replikation einzuarbeiten und habe dabei ein doch sehr großes Problem entdeckt...
Zur Basis:
Windows Server 2012 R2
DFS Replikation zwischen zwei APP's
Namespace angelegt
Replikationspartner angelegt
Replikation wurde initial einmal ausgeführt
Also funktioniert es in erster Linie...
In zweiter Linie kann eine bestimmte Datei nicht repliziert werden, weil diese im Zugriff ist?
Eventlog:
The DFS Replication service has been repeatedly prevented from replicating a file due to consistent sharing violations encountered on the file. A local sharing violation occurs when the service fails to receive an updated file because the local file is currently in use.
Additional Information:
File Path: E:\FORMS\AVW\FRM_ORDER.fmx
Replicated Folder Root: E:\FORMS
File ID: {0DF4F9C9-0432-4FBF-B043-14A82D755603}-v502849
Replicated Folder Name: FORMS
Replicated Folder ID: 0A6AAAB4-91BD-438C-8C67-DAD80A07A867
Replication Group Name: "Domäne"\apps\forms
Replication Group ID: FCFDA16A-8D9A-4E4E-B943-3F00B86921F7
Member ID: C3FB5A75-5472-408E-BCB6-B2664DC4192B
Event ID: 4302
Level: Warning
Da diese Datei ständig verändert wird (Versionsstände, etc..) und von vielen Benutzern in der Domäne genutzt wird (ist für ein Hauptprogramm erforderlich, quasi wie eine Config) muss diese auf beiden Servern immer aktuell sein und am Besten fast zeitgleich repliziert werden.
Wenn ich "dfsrdiag.exe replicationstate" ausführe, wird mir ebenfalls diese Datei in der Warteschlange zum replizieren angezeigt.
Updates scheduled:
[1] Update Name: FRM_ORDER.fmx
Total number of inbound updates scheduled: 1
Es passiert aber 0...
Was kann ich tun?
Danke und Gruß!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 281698
Url: https://administrator.de/contentid/281698
Ausgedruckt am: 25.11.2024 um 12:11 Uhr
7 Kommentare
Neuester Kommentar
Hi,
E.
Da diese Datei ständig verändert wird (Versionsstände, etc..) und von vielen Benutzern in der Domäne genutzt wird (ist für ein Hauptprogramm erforderlich, quasi wie eine Config) muss diese auf beiden Servern immer aktuell sein und am Besten fast zeitgleich repliziert werden.
DFS-R kann auch nicht zaubern. Wenn die Datei von einer Anwendung gelockt ist, dann kommt DFS-R da nicht ran und muss warten, bis alle Locks wieder aufgehoben sind, sprich keiner diese Datei mehr benutzt.E.
Hallo emeriks,
danke für die Antwort.
Das die Datei gelockt ist und man warten muss bis diese nicht mehr genutzt wird, ist mir schon klar..
Aber gibt es keine Regeldefinition o.ä. dafür?
Wenn alles Stricke reißen, muss ich da auf eine andere Technologie ausweichen?
Es muss doch eine Möglichkeit geben, sonst kann ich das Thema DFS für unsere Zwecke direkt an den Haken hängen...
Thx,
Gruß
danke für die Antwort.
Das die Datei gelockt ist und man warten muss bis diese nicht mehr genutzt wird, ist mir schon klar..
Aber gibt es keine Regeldefinition o.ä. dafür?
Wenn alles Stricke reißen, muss ich da auf eine andere Technologie ausweichen?
Es muss doch eine Möglichkeit geben, sonst kann ich das Thema DFS für unsere Zwecke direkt an den Haken hängen...
Thx,
Gruß
Was willst Du denn erreichen?
Du hast eine Anwendung, die Du redundant anbieten willst/musst? Nur an einem Standort oder verteilt an mehreren?
Hat die Anwendung klar getrennte Programm- und Datenpfaden?
Wird die Anwendung vom Hersteller hinsichtlich DFS-N und DFS-R überhaupt offiziell unterstützt?
Du hast eine Anwendung, die Du redundant anbieten willst/musst? Nur an einem Standort oder verteilt an mehreren?
Hat die Anwendung klar getrennte Programm- und Datenpfaden?
Wird die Anwendung vom Hersteller hinsichtlich DFS-N und DFS-R überhaupt offiziell unterstützt?
Ganz einfach...
Alle User arbeiten mit einer zentralen Anwendung welches immer hochverfügbar sein muss.
Aus dem Grunde haben wir uns für die DFS Replikation entschieden..
Die User greifen auf einen gemeinsamen Namespace zu "Domäne.de" und sollen nicht mehr den direkten Pfad der Anwendung öffnen..
Somit falls ein Server ausfällt, der zweite Server eingreift und die Anwendung übernimmt.
Alle User arbeiten mit einer zentralen Anwendung welches immer hochverfügbar sein muss.
Aus dem Grunde haben wir uns für die DFS Replikation entschieden..
Die User greifen auf einen gemeinsamen Namespace zu "Domäne.de" und sollen nicht mehr den direkten Pfad der Anwendung öffnen..
Somit falls ein Server ausfällt, der zweite Server eingreift und die Anwendung übernimmt.
Und alles an einem Standort?
Kommt die Anwendung eigentlich mit dem "last writer wins" klar? Allein das von Dir genannte Beispiel mit dieser einen Datei
Wie aktuell muss denn die Redundanz sein? Sekundengenau? Minutengenau? Stunden?
Kommt die Anwendung eigentlich mit dem "last writer wins" klar? Allein das von Dir genannte Beispiel mit dieser einen Datei
Da diese Datei ständig verändert wird (Versionsstände, etc..) und von vielen Benutzern in der Domäne genutzt wird (ist für ein Hauptprogramm erforderlich, quasi wie eine Config) muss diese auf beiden Servern immer aktuell sein und am Besten fast zeitgleich repliziert werden.
Wer ändert diese Datei? Wann und wie?Wie aktuell muss denn die Redundanz sein? Sekundengenau? Minutengenau? Stunden?
Ja an einem Standort.
Die Datei wird von unserer Softwareentwicklung regelmäßig angepasst und dann in das gemeinsame Share kopiert..
Allerdings da die Datei im Zugriff ist, klappt die ganze Geschichte nicht so und die o. g. Fehlermeldung wird ausgespuckt..
Die Redundanz sollte schon alle paar Minuten gewährleistet sein.
Die Datei wird von unserer Softwareentwicklung regelmäßig angepasst und dann in das gemeinsame Share kopiert..
Allerdings da die Datei im Zugriff ist, klappt die ganze Geschichte nicht so und die o. g. Fehlermeldung wird ausgespuckt..
Die Redundanz sollte schon alle paar Minuten gewährleistet sein.
Das wäre bei uns im Haus ein Fall für die Wartung. Sprich, das Programm wird für ein vorher kommuniziertes Zeitfenster offline genommen, die Update eingespielt und dann wieder freigegeben. Somit wären keine Dateien in Benutzung.
