Jump to content

DFS-R und Officedokumente von mehreren Usern benutzen


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo, WIN2k3 R2 Standard wird eingesetzt in einer AD Umgebung. 3 Standorte mit jeweils einem Server und einer SDSL VPN Verbindung. 2 DC's und ein Memberserver. Der Namespace ist im AD veröffentlicht und die Freigaben lokal auf den Servern gesetzt. Die Replikation funktioniert aber wenn ein User aus Standort A eine Officedatei öffnet z.B. test.xls erhält der User in Standort B der die selbe Datei öffnet eine Meldung nur schreibgeschützt möglich (soll ja auch so sein) aber der User in Standort C erhält diese Meldung nicht. Gibt es dazu vielleicht einige Informationen. Vielen Dank im voraus holunder

Link zu diesem Kommentar

Hallo,

 

leider ist Deine Beschreibung nicht ganz eindeutig. Ist an jedem Standort ein Replikationsordner vorhanden?

 

Da die Replikation keine File-Locks repliziert, sondern im Moment eines File-Lockings die Datei gar nicht repliziert (das nennt sich dann "sharing violation" und verlangsamt die Replikation insgesamt unter Umständen sehr stark), kann die Zugriffsverweigerung bzw. "nur lesen" Situation nur auftreten, wenn zwei Clients tatsächlich auf die gleiche Datei auf dem gleichen Server zugreifen.

 

D.h. greifen zwei Benutzer auf die gleiche Datei auf zwei verschiedenen Servern / Replikationszielen zu, kann der jeweils andere Client nichts davon bemerken.

 

Greifen jedoch (weil beispielsweise ein Replikationsordner eines Standorts nicht verfügbar ist) zwei Clients auf die gleiche Datei des gleichen Servers zu, bekommst Du ggf. die Fehlermeldung.

 

Vielleicht kannst Du Deine Situationsbeschreibung ja noch einmal ein wenig genauer ausführen.

 

Gruß olc

Link zu diesem Kommentar

Hallo,

leider ist Deine Beschreibung nicht ganz eindeutig. Ist an jedem Standort ein Replikationsordner vorhanden?

Sry, 3 Server hosten den Namespace, und seit heute 4 Server (darunter die 3 Namespaceserver) einen Replikationsordner. In dem befinden Unterverzeichnisse und die Excel- und Worddateien die von den 4 Standortusern benutzt werden. Auif die jetzt 4 Replikationspartner bezieht sich meine Frage nach der Information für einen Benutzer, der auf Dateien zugreifen möchte, die schon von anderen Usern geöffnet wurden.

Da die Replikation keine File-Locks repliziert, sondern im Moment eines File-Lockings die Datei gar nicht repliziert (das nennt sich dann "sharing violation" und verlangsamt die Replikation insgesamt unter Umständen sehr stark), kann die Zugriffsverweigerung bzw. "nur lesen" Situation nur auftreten, wenn zwei Clients tatsächlich auf die gleiche Datei auf dem gleichen Server zugreifen.

also bemerkt habe ich solche Fehlermeldungen im Log. Habe mich auch schon sehr bemüht, die Ursache für diese Fehlermeldung zu finden. Habe den Namen dieser Datei, welche die Zugriffsverletzung verursacht hat, im Stageingordner immer schon finden wollen. Aber ohne Erfolg. Jetzt kenne ich wahrscheinlich den Grund. Und ich denke, dass nur wenn die Fehlermeldung auftrat, auch wirklich 2 Clients auf dem selben Server waren. :( Und das auch nur deshalb, weil es irgendwilche Netzwerkprobleme gab .. hm

D.h. greifen zwei Benutzer auf die gleiche Datei auf zwei verschiedenen Servern / Replikationszielen zu, kann der jeweils andere Client nichts davon bemerken.

oh mann.

Greifen jedoch (weil beispielsweise ein Replikationsordner eines Standorts nicht verfügbar ist) zwei Clients auf die gleiche Datei des gleichen Servers zu, bekommst Du ggf. die Fehlermeldung.

:(

Vielleicht kannst Du Deine Situationsbeschreibung ja noch einmal ein wenig genauer ausführen. Gruß olc

 

Du hast mich durchschaut :) Kann ich dafür eine Lösung schaffen? Hoffentlich. Gruß holunder

Link zu diesem Kommentar

Hallo holunder,

 

Sry, 3 Server hosten den Namespace, und seit heute 4 Server (darunter die 3 Namespaceserver) einen Replikationsordner. In dem befinden Unterverzeichnisse und die Excel- und Worddateien die von den 4 Standortusern benutzt werden. Auif die jetzt 4 Replikationspartner bezieht sich meine Frage nach der Information für einen Benutzer, der auf Dateien zugreifen möchte, die schon von anderen Usern geöffnet wurden.

 

Ok. Also so, wie vermutet. :)

 

also bemerkt habe ich solche Fehlermeldungen im Log. Habe mich auch schon sehr bemüht, die Ursache für diese Fehlermeldung zu finden. Habe den Namen dieser Datei, welche die Zugriffsverletzung verursacht hat, im Stageingordner immer schon finden wollen. Aber ohne Erfolg.

 

Im Staging Folder liegt diese Datei nicht - wenn tatsächlich "sharing violations" auftreten, dann landet die Datei gar nicht im Staging Folder --> der Zugriff wird ja verweigert. Die Datei muß also - wenn es sich tatsächlich um gelockte Dateien handelt - im normalen Replikationsordner liegen.

 

Bitte bedenke dabei auch, daß nicht alle Dateitypen bzw. Programme im geöffneten Zustand ein "lock" auf die Datei setzen. Textdateien tun dies beispielsweise nicht. D.h. DFS-R kann die Daten trotzdem replizieren, während dessen unter Umständen ein Benutzer die Meldung bekommt, daß ein anderer Benutzer in der Datei arbeitet.

 

Welche Ereignisse bekommst Du denn im DFS-R Eventlog?

 

Jetzt kenne ich wahrscheinlich den Grund. Und ich denke, dass nur wenn die Fehlermeldung auftrat, auch wirklich 2 Clients auf dem selben Server waren. :( Und das auch nur deshalb, weil es irgendwilche Netzwerkprobleme gab .. hm

 

Ja, das macht dann auch Sinn. Im Normalfall werden sich die Clients auf den Server / einen der Server Ihres Standord verbinden. Ist dieser beispielsweise aufgrund von Netzwerproblemen nicht erreichbar oder gar nicht online, ziehen sich die Clients über die Namespaceserver ein anderes Ziel - und versuchen dabei den "billigsten" Netzwerkpfad zu wählen.

 

Du hast mich durchschaut :) Kann ich dafür eine Lösung schaffen?

 

Die Frage ist, was Du lösen willst. Die Netzwerkprobleme solltest Du in jedem Fall lösen. ;)

 

Daß Zugriffsverletzungen beim Zugriff auf ein und dieselbe Datei auftreten, kannst Du nicht ändern. Das ist ja auch sinnvoll so und nicht nur bei DFS-N bzw. DFS-R der Fall...

 

Wenn es Dir darum geht eine Datei auf allen Replikationsordnern zu sperren, wenn an irgend einem Standort ein Benutzer darin arbeitet, muß ich Dich enttäuschen - das geht nicht. Das wäre auch nicht sinnvoll, denn dann nützt die verteilte Datenhaltung recht wenig.

Eine Möglichkeit, alle Benutzer auf einen bestimmten Ordner zu leiten (sofern dieser verfügbar ist), wäre mit (DFS-N)Prioritäten zu arbeiten. Aber dann würden die Remote-Benutzer in Deiner Umgebung - wenn ich Dich richtig verstanden habe - immer über das (Inter-)Netz zugreifen, was sicherlich nicht gewünscht ist.

 

Grundsätzlich auch noch einmal der Hinweis, daß es mit Vorsicht zu genießen ist, an verschiedenen Standorten gleichzeitig an gleichen Daten zu arbeiten. Davon kann man in der Praxis eigentlich nur abraten. In jedem Fall mußt Du in einer solchen Konstellation einen sehr guten Reviewprozess für die Eventlogs einrichten, um alle Konfliktvorgänge auf dem Schirm zu haben. Sonst kommt es irgendwann einmal zu einer wirklich unschönen Situation... :rolleyes:

 

Gruß olc

Link zu diesem Kommentar

Hallo olc,

 

ich denke es verstanden zu haben.

Fehlermeldung:

Der DFS-Replikationsdienst wurde wiederholt daran gehindert, eine Datei zu replizieren. Der Grund besteht in fortdauernden Freigabeverletzungen fr die Datei. Der Dienst konnte das Staging fr eine Datei fr die Replikation aufgrund einer Freigabeverletzung nicht durchfhren.

Weitere Informationen:

Dateipfad: "Pfad"

Stamm des replizierten Ordners: "Pfad"

Dateikennung: {A7C175C6-9AC5-49B1-8439-18D545B11B5A}-v255091

Name des replizierten Ordners: "Name"

Kennung des replizierten Ordners: 36A22A8C-7AA2-4B3A-AC04-8DAFAF775A11

Replikationsgruppenname: ""

Replikationsgruppenkennung: 73D12EA4-DFC8-41D8-941D-FB1F6D0E07D3

Mitgliedskennung: 292F529D-6A37-470E-9C59-B17C4BD003AA

Weitere Informationen ber die Hilfe- und Supportdienste erhalten Sie Glücklich darüber bin ich nicht.

Ärger gabe es auch noch nicht. Aber gibt es trotzdem eine Lösung dafür? Muss ja nicht via DFS erfolgen. Möglichkeiten von Drittanbietern sind willkommen. Danke Dir, dass Du Zeit hattest über mein Problem nachzudenken. Gruß holunder

Link zu diesem Kommentar

Hi holunder,

 

ich denke es verstanden zu haben.

 

Gut, das ist die halbe Miete. :)

 

Fehlermeldung:

Der DFS-Replikationsdienst wurde wiederholt daran gehindert, eine Datei zu replizieren. Der Grund besteht in fortdauernden Freigabeverletzungen fr die Datei. Der Dienst konnte das Staging fr eine Datei fr die Replikation aufgrund einer Freigabeverletzung nicht durchfhren.
Weitere Informationen:
Dateipfad: "Pfad"
Stamm des replizierten Ordners: "Pfad"
Dateikennung: {A7C175C6-9AC5-49B1-8439-18D545B11B5A}-v255091
Name des replizierten Ordners: "Name"
Kennung des replizierten Ordners: 36A22A8C-7AA2-4B3A-AC04-8DAFAF775A11
Replikationsgruppenname: ""
Replikationsgruppenkennung: 73D12EA4-DFC8-41D8-941D-FB1F6D0E07D3
Mitgliedskennung: 292F529D-6A37-470E-9C59-B17C4BD003AA

 

Bitte poste einmal die gesamte Meldung, inkl. der Event ID, der Zeit und der Pfade. Ggf. kannst Du aus Datenschutzgründen die Pfadnamen bei vertraulichen Namen ja ändern, solange Du konsistent die gleichen Bezeichnungen wählst. Anders kann man das Event kaum auswerten...

 

Was mich verwundert ist, daß die Dateien scheinbar wirklich Staging Dateien sind - zumindest läßt der Name dies vermuten.

 

Werden diese Events an allen Standorten geloggt oder nur an einigen?

Nutzt Ihr Virenscanner auf den Systemen, die auch die Replikationsordner scannen?

Was für eine Backup Lösung nutzt Ihr?

 

Ärger gabe es auch noch nicht. Aber gibt es trotzdem eine Lösung dafür? Muss ja nicht via DFS erfolgen. Möglichkeiten von Drittanbietern sind willkommen.

 

Mir persönlich sind keine Lösungen bekannt, die ein solches Szenario (also das Locking von Dateien an mehreren Standorten, sollte ein Benutzer an einem anderen Standort die gleiche Datei bearbeiten) abdecken würden - es sei denn, der Zugriff der Benutzer erfolgt direkt über das Netz hin zu zentralen Systemen. iSCSI oder ähnliches wäre in diesem Fall auch denkbar - aber auch das setzt eine ordentliche Konnektivität voraus. In diesem Fall also m.E. eher ungeeignet.

 

Danke Dir, dass Du Zeit hattest über mein Problem nachzudenken.

 

Nichts zu danken - ich hoffe es bringt Dich weiter.

 

Gruß olc

Link zu diesem Kommentar

hallo olc,

ich habe die Logs mal verglichen. Die Meldung der Zugriffsverletzung erfolgte immer nur auf einem Server. Es war nicht feststellbar, dass auf unterschiedlichen Shares die selbe Datei von verschiedenen Benutzern göffnet wurde. Wie verhält es sich eigentlich damit, wenn der Benutzer über den Namesspace auf die Server zugreift. Also ich mein "\\domainname\dfsnamespace\share" und nicht wie im Moment "\\Standortserver\share" wird die Anfrage über die schnellste Verbindung realisiert? Wie finde ich eigentlich die Auflösung für

"Replikationsgruppenkennung: 73D12EA4-DFC8-41D8-941D-FB1F6D0E07D3" ich habe im AD schon gesucht, aber nix gefunden. Die Zeichen stimmen einfach nicht überein. Die Replikationsgruppenkennung(en) haben andere Zeichneketten :( Fragen über Fragen ..

Link zu diesem Kommentar

Guten Abend,

 

ich habe die Logs mal verglichen. Die Meldung der Zugriffsverletzung erfolgte immer nur auf einem Server. Es war nicht feststellbar, dass auf unterschiedlichen Shares die selbe Datei von verschiedenen Benutzern göffnet wurde.

 

In diesem Fall kann die Lösung recht einfach sein: Es treten auch Zugriffsverletzungen auf, wenn temporäre Dateien geöffnet sind oder Dateien, die den Zugriff locken, wenn man sie öffnet - so z.B. Excel Dateien.

 

Das wäre dann alles kein Problem, denn nachdem die Dateien nicht mehr gelockt sind, werden diese wieder repliziert.

 

Wie oft treten denn diese Fehlermeldungen auf?

 

Ordne den UIDs der oben genannten Datei doch einmal einen Dateinamen zu, indem Du die im Event genannte UID in den Backlogs Deines Servers suchst. Die Backlogs findest Du unter %SYSTEMROOT%\Debug\Dfsr####.log bzw. alte Dateien *.gz.

Dann sehen wir, was das für Dateien bzw. insbesondere Dateitypen sind.

 

Wie verhält es sich eigentlich damit, wenn der Benutzer über den Namesspace auf die Server zugreift. Also ich mein "\\domainname\dfsnamespace\share" und nicht wie im Moment "\\Standortserver\share" wird die Anfrage über die schnellste Verbindung realisiert?

 

Wenn Du an den DFS-N Einstellungen nichts geändert hast, dann greift der Client immer auf die Server seines Standortes zu, solange diese verfügbar sind. Man kann dieses Verhalten jedoch auch bearbeiten, indem man an den Prioritäten etwas ändert.

 

Wie finde ich eigentlich die Auflösung für

"Replikationsgruppenkennung: 73D12EA4-DFC8-41D8-941D-FB1F6D0E07D3" ich habe im AD schon gesucht, aber nix gefunden. Die Zeichen stimmen einfach nicht überein. Die Replikationsgruppenkennung(en) haben andere Zeichneketten :(

 

In der AD liegt die Konfiguration unterhalb Deines Domain NC --> System Container --> DFSR-GlobalSettings. Du kannst neben ADSIEdit oder LDP auch einen Export der DFS-R AD-Daten machen, indem Du folgenden Befehl auf der CMD eingibst:

 

dfsrdiag dumpadcfg

 

Am bequemsten exportierst Du die GUIDs jedoch über:

 

dfsradmin rg list /attr:all

 

Um noch einmal auf meine Fragen von oben zurückzukommen:

 

- Wie lautet die Event ID der Fehlermeldungen? Ich nehme an 4302?

- Setzt Ihr Virenscanner auf dem Server ein, auf dem die Events geloggt werden?

- Werden zum Zeitpunkt der Meldungen Backups gezogen?

- Was für Daten liegen auf den DFS-R Shares, um welche Dateitypen handelt es sich?

- Habt Ihr irgendwelche FRSM Filescreens am laufen, also die Sperrung von bestimmten Dateitypen (neben den DFS-R eigenen)?

 

Fragen über Fragen ..

 

...die wir hoffentlich gelöst bekommen. ;)

 

Gruß olc

Link zu diesem Kommentar

Ärger gabe es auch noch nicht. Aber gibt es trotzdem eine Lösung dafür? Muss ja nicht via DFS erfolgen. Möglichkeiten von Drittanbietern sind willkommen. Danke Dir, dass Du Zeit hattest über mein Problem nachzudenken. Gruß holunder

Wenn es Dir hilft: die Lösung dafür wird es wohl mit Windows Server 2008 R2 geben - bis dahin sieht es mit Bordmitteln schlecht aus.

 

ASR

Link zu diesem Kommentar

Guten Abend,

 

In diesem Fall kann die Lösung recht einfach sein: Es treten auch Zugriffsverletzungen auf, wenn temporäre Dateien geöffnet sind oder Dateien, die den Zugriff locken, wenn man sie öffnet - so z.B. Excel Dateien. Das wäre dann alles kein Problem, denn nachdem die Dateien nicht mehr gelockt sind, werden diese wieder repliziert. Wie oft treten denn diese Fehlermeldungen auf?

Ja, es dreht sich ausschliesslich um Excel- und Worddateien. Die Fehlermeldung tritt auf, wenn eine Officedatei geöffnet ist. Fehlermeldung 4304 Quelle DFSR. Die Aktualisierung der Datei wird auch repliziert. Wenn das VPN Netz nicht so laggy wäre, würden die DFS Mitglieder 24h online sein, ohne Verbindungsprobleme. Hatte erst gedacht, dass es replizierbar wäre, wenn ein DFS Kommunikationspartenr durch Ausfall einer VPN Verbindung zu diesem Standort diese Fehlermeldung verursacht. An dem ist aber nicht so. Auch wenn alle Replikationspartner online sind tritt diese Fehlermeldung auf 4304.

 

Ordne den UIDs der oben genannten Datei doch einmal einen Dateinamen zu, indem Du die im Event genannte UID in den Backlogs Deines Servers suchst. Die Backlogs findest Du unter %SYSTEMROOT%\Debug\Dfsr####.log bzw. alte Dateien *.gz.

Dann sehen wir, was das für Dateien bzw. insbesondere Dateitypen sind.

Im Eventlog steht ja auch der reale Name der Datei. Aber die Kennung der Replikationspartner ist mir immer noch verborgen geblieben. Trotz Blacklogs :(

 

Wenn Du an den DFS-N Einstellungen nichts geändert hast, dann greift der Client immer auf die Server seines Standortes zu, solange diese verfügbar sind. Man kann dieses Verhalten jedoch auch bearbeiten, indem man an den Prioritäten etwas ändert.
Sucht der Client den Server der ihm am nähchsten ist? Welchen sucht er dabei. Den der den Namespace hostet oder auch einen der "nur" einen Replikationsordner hostet? (Dieser Replikationsordner allerdings auch das Share für den Zugriff der Clients unterstützt).

 

In der AD liegt die Konfiguration unterhalb Deines Domain NC --> System Container --> DFSR-GlobalSettings. Du kannst neben ADSIEdit oder LDP auch einen Export der DFS-R AD-Daten machen, indem Du folgenden Befehl auf der CMD eingibst:

"dfsrdiag dumpadcfg"

Der Befehl hat mir die Zuordnung zu den Servern ermöglicht. Danke. Jetzt verstehe ich die Fehlermeldung auch besser. Da User aus Standort A auf die selbe Datei zugreifen erfolgt eine Zugriffsverletzung, wenn der 2. User diese Datei im Schreibschutz öffnet und geöffnet lässt, wenn der 1. User die Datei abspeichert. Kann aber auch sein, dass ein User in Standort B Datei 123 öffnet und bearbeitet, zeitgleich ein anderer User auch die Datei 123 öffnet, allerdings in Standort C und bei der Replikation der zueben gespeicherten Datei 123 in Standort B erfolgt eine Fehlermeldung durch die Zugriffsverletzung der Datei 123 auf Replikationsmitglied in Standort C. Kann ich das so deuten?

 

Um noch einmal auf meine Fragen von oben zurückzukommen:

- Wie lautet die Event ID der Fehlermeldungen? Ich nehme an 4302? 4304 Quelle DFSR

- Setzt Ihr Virenscanner auf dem Server ein, auf dem die Events geloggt werden? ja NAV Version 10

- Werden zum Zeitpunkt der Meldungen Backups gezogen? nein

- Was für Daten liegen auf den DFS-R Shares, um welche Dateitypen handelt es sich? xls, doc

- Habt Ihr irgendwelche FRSM Filescreens am laufen, also die Sperrung von bestimmten Dateitypen (neben den DFS-R eigenen)? weiss nicht genau was Du meinst :confused:

 

Ich bin beim Fragen stellen allerdings absolute Weltklasse :)

Link zu diesem Kommentar

Hallo ASR

 

Wenn es Dir hilft: die Lösung dafür wird es wohl mit Windows Server 2008 R2 geben - bis dahin sieht es mit Bordmitteln schlecht aus.

Das ist mir jetzt leider auch klar. Abhilfe von Drittanbietern die WIN2k3 kompitabel sind gibt es die vielleicht schon? Oder erst ab der von Dir beschriebenen Version des Microsoft Server OS. Da bleibt dann wohl vorerst nur der Weg über nen Terminalserver. Kann ich Outlook auch problemlos via Terminal betreiben? Habe da schon viele "schlimme" Sachen gelesen. Umgebung wäre OfficeXPpro, WIN XP pro und WIN2k3 Server R2.

 

Danke für Deine Hilfe Gruß holunder

Link zu diesem Kommentar

N'Abend,

 

ausschliesslich um Excel- und Worddateien. [...]Fehlermeldung 4304 Quelle DFSR. Die Aktualisierung der Datei wird auch repliziert.

 

Dann hast Du damit die "Lösung" Deines Problems: Die Meldungen werden geloggt, wenn die Datei wegen Zugriffs gelockt ist. Das ist vollkommen normal und stellt, wenn diese Events nicht exzessiv geloggt werden, im Normalfall kein Problem da...

Werden diese Events massiv geloggt, leidet darunter jedoch die Replikationsgeschwindigkeit / -performance.

 

Aber die Kennung der Replikationspartner ist mir immer noch verborgen geblieben. Trotz Blacklogs :(

 

Hast Du Dir die Befehle angeschaut, die ich gepostet hatte? Damit kannst Du die IDs zuordnen.

 

Sucht der Client den Server der ihm am nähchsten ist? Welchen sucht er dabei. Den der den Namespace hostet oder auch einen der "nur" einen Replikationsordner hostet? [...]

 

Wenn Du auf den Namespace zugreifst, z.B. "\\domain.tld\public", dann fragt der Client in der AD an, welche Namespaceserver verfügbar sind. Von diesen Namespaceservern erhält der Client dann die Verweise auf die Server, auf denen die Replikationsordner / Shares liegen. Schau mal in das HowTo auf Serverhowto.de, da wird darauf eingegangen.

Das heißt also, daß der Client auf das Share zugreift, welches ihm am "nächsten" ist - im Normalfall ein Server an seinem Standort. Hierfür werden die Standorte der AD Sites & Services verwendet.

 

Windows Server How-To Guides: Teil 1 - Verteilung von Namespaces auf verschiedene Server - ServerHowTo.de

 

Der Befehl hat mir die Zuordnung zu den Servern ermöglicht. Danke. Jetzt verstehe ich die Fehlermeldung auch besser.

 

Ok, dann konntest Du die IDs der Replikationsgruppen also doch zuordnen.

 

Da User aus Standort A [...]

 

Nein, das haut so nicht ganz hin. Du mußt unbedingt unterscheiden zwischen den normalen Dateisperren, die halt auftreten, wenn mehrere Benutzer einen Datei öffnen wollen. Das ist unabhängig von DFS-N oder DFS-R.

 

In Bezug auf DFS-R geht es ausschließlich um die Replikation, d.h. die Datei soll repliziert werden, ist jedoch gelockt. In diesem Fall versucht der DFS-R Dienst später wieder, die Datei zu replizieren. Dazu muß nur ein Benutzer die Datei geöffnet haben, kein zweiter Benutzer ist für dieses Verhalten "notwendig".

 

Der dritte Punkt ist dann ein Konflikt beim Replizieren --> diese Thematik haben wir noch gar nicht bearbeitet, denn diese ist eine ganz andere Baustelle. Tritt ein solcher Konflikt auf, wird nicht das von Dir angegebene Event geloggt. Die Event ID lautet dann 4412 und die Event-Beschreibung ist (natürlich) eine andere...

 

Windows Server How-To Guides: Teil 4 - Konflikterkennung bzw. Ablage von durch DFS-R gelöschter Dateien und Ordner - ServerHowTo.de

 

...unten geht es weiter...

Link zu diesem Kommentar
- Virenscanner? ja NAV Version 10

 

In diesem Fall solltest Du vorsichtshalber in jedem Fall Hotfix Distributed File System Replication in Windows Server 2003 R2 performs unnecessary replication when an antivirus application is installed installieren.

 

- um welche Dateitypen handelt es sich? xls, doc

 

Wie oben schon gesagt - damit hast Du die Erklärung für die Events.

 

- FRSM Filescreens? weiss nicht genau was Du meinst :confused:

 

Du kannst mit FSRM, das beim R2 Server mit dabei ist, auch Dateitypen sperren. Ist aber aufgrund der oben genannten Hintergründe erst einmal nicht mehr "wichtig"...

 

Windows Server 2003 R2 Simplifies Storage Management

 

Ich bin beim Fragen stellen allerdings absolute Weltklasse :)

 

Ist - denke ich - nicht mehr notwendig. ;)

 

Wenn es Dir hilft: die Lösung dafür wird es wohl mit Windows Server 2008 R2 geben - bis dahin sieht es mit Bordmitteln schlecht aus.

 

Das bringt bei dem Fehlerbild jedoch nichts. Aber BTW: Woher hast Du diese Information? Würde mich interessieren, wie genau dieses Feature (distributed locking) implementiert werden soll...

 

Gruß olc

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...