8
Probleme beim Speichern auf Netzwerkshares
Hallo zusammen,
wir haben seit einiger Zeit Probleme beim Speichern von Officedokumenten auf unsere Netzlaufwerke (DFS).
Das Problem tritt auch mehreren Shares auf, die auf unterschiedlichen Servern liegen.
Ich habe bis jetzt noch nichts finden können, was die Probleme verursacht.
Auch im WWW sowie im Forum konnte ich zu diesen Fehlern nicht wirklich etwas finden.
Bei einigen Usern aus unterschiedlichen Abteilungen kommt es zu diesen Problemen:
Was meistens zu funktionieren scheint: Speichern unter --> Desktop
Anschließend die Datei am eigentlich vorgesehenen Zielort ersetzen.
Zuerst hatte ich den MS Defender for Endpoint auf den Servern im Verdacht, da dieser erst seit Anfang April installiert ist und Mitte/Ende April ich zum ersten Mal über das Problem informiert wurde.
Unser Dienstleister meinte es dürfte nicht am Defender liegen, es wäre zumindest das erste Mal, dass er davon hört.
Wir haben daraufhin natürlich auch im Defender nachgeschaut, konnten dort aber nichts finden.
Möchte es deshalb aber nicht ausschließen.
Zu unserer Umgebung:
AV auf den Server: MS Defender for Endpoint
AV auf den Clients: Forticlient
FW: Fortigate
Server: von WS2019 bis 2012r2 alles dabei.
ES gibt sowohl DFS-Shares als auch per GPO gemappte Netzlaufwerke.
Das Laufwerk G: z. B. ist ein DFS-Ordner, der via GPO als Laufwerk gemappt wird.
In der DFS-Verwaltung zeigt das Verzeichnis (Pfad) dann auf ein Share auf einem anderen Server.
Die meisten anderen Shares liegen auf unserem Fileserver.
Ich hoffe, Ihr habt ein paar Ideen, bevor ich weiter im Dunkeln rumstochere.
P.S: Wenn ich etwas im Forum übersehen haben sollte, bin ich auch für diese Art von Hinweisen dankbar.
Vielen Dank
LG
NIls
wir haben seit einiger Zeit Probleme beim Speichern von Officedokumenten auf unsere Netzlaufwerke (DFS).
Das Problem tritt auch mehreren Shares auf, die auf unterschiedlichen Servern liegen.
Ich habe bis jetzt noch nichts finden können, was die Probleme verursacht.
Auch im WWW sowie im Forum konnte ich zu diesen Fehlern nicht wirklich etwas finden.
Bei einigen Usern aus unterschiedlichen Abteilungen kommt es zu diesen Problemen:
Was meistens zu funktionieren scheint: Speichern unter --> Desktop
Anschließend die Datei am eigentlich vorgesehenen Zielort ersetzen.
Zuerst hatte ich den MS Defender for Endpoint auf den Servern im Verdacht, da dieser erst seit Anfang April installiert ist und Mitte/Ende April ich zum ersten Mal über das Problem informiert wurde.
Unser Dienstleister meinte es dürfte nicht am Defender liegen, es wäre zumindest das erste Mal, dass er davon hört.
Wir haben daraufhin natürlich auch im Defender nachgeschaut, konnten dort aber nichts finden.
Möchte es deshalb aber nicht ausschließen.
Zu unserer Umgebung:
AV auf den Server: MS Defender for Endpoint
AV auf den Clients: Forticlient
FW: Fortigate
Server: von WS2019 bis 2012r2 alles dabei.
ES gibt sowohl DFS-Shares als auch per GPO gemappte Netzlaufwerke.
Das Laufwerk G: z. B. ist ein DFS-Ordner, der via GPO als Laufwerk gemappt wird.
In der DFS-Verwaltung zeigt das Verzeichnis (Pfad) dann auf ein Share auf einem anderen Server.
Die meisten anderen Shares liegen auf unserem Fileserver.
Ich hoffe, Ihr habt ein paar Ideen, bevor ich weiter im Dunkeln rumstochere.
P.S: Wenn ich etwas im Forum übersehen haben sollte, bin ich auch für diese Art von Hinweisen dankbar.
Vielen Dank
LG
NIls
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 3151949848
Url: https://administrator.de/contentid/3151949848
Printed on: April 24, 2024 at 01:04 o'clock
8 Comments
Latest comment
Moin,
Falls ja ist hier das Problem: Ersetzen bedeutet:
Das könnte die Ursache sein.
Warum das aber bei den UNC-Pfaden passiert: da hab ich derzeit auch keine Idee.
Gibt es Hinweise im Eventlog des Clients?
ES gibt sowohl DFS-Shares als auch per GPO gemappte Netzlaufwerke.
Das Laufwerk G: z. B. ist ein DFS-Ordner, der via GPO als Laufwerk gemappt wird.
Wie werden die Laufwerke konkret gemapped? stehen die auf "Ersetzen"?Das Laufwerk G: z. B. ist ein DFS-Ordner, der via GPO als Laufwerk gemappt wird.
Falls ja ist hier das Problem: Ersetzen bedeutet:
- Trenne das Laufwerk (analog zu net use g: /del)
- Verbinde es Neu
Das könnte die Ursache sein.
Warum das aber bei den UNC-Pfaden passiert: da hab ich derzeit auch keine Idee.
Gibt es Hinweise im Eventlog des Clients?
Zitat von @em-pie:
Moin,
Falls ja ist hier das Problem: Ersetzen bedeutet:
Das könnte die Ursache sein.
Warum das aber bei den UNC-Pfaden passiert: da hab ich derzeit auch keine Idee.
Gibt es Hinweise im Eventlog des Clients?
Moin,
ES gibt sowohl DFS-Shares als auch per GPO gemappte Netzlaufwerke.
Das Laufwerk G: z. B. ist ein DFS-Ordner, der via GPO als Laufwerk gemappt wird.
Wie werden die Laufwerke konkret gemapped? stehen die auf "Ersetzen"?Das Laufwerk G: z. B. ist ein DFS-Ordner, der via GPO als Laufwerk gemappt wird.
Falls ja ist hier das Problem: Ersetzen bedeutet:
- Trenne das Laufwerk (analog zu net use g: /del)
- Verbinde es Neu
Das könnte die Ursache sein.
Warum das aber bei den UNC-Pfaden passiert: da hab ich derzeit auch keine Idee.
Gibt es Hinweise im Eventlog des Clients?
Hallo,
danke für deine Ideen.
Das G-Laufwerk steht auf Aktualisieren.
Andere Laufwerke stehen auf Erstsetzen, da bei Aktualisieren die Laufwerke oft "Offline" sind, wenn man sich anmeldet.
Ich habe eben nochmals in der Ereignisanzeige nachgeschaut.
Bis auf das hier konnte ich nichts Ungewöhnliches feststellen:
Das war allerdings schon 3 Minuten nach Erstellung des Tickets. Vorher wäre mir nichts aufgefallen.
Ein Tipp in welchem Log ich noch schauen sollte?
Habe bis jetzt nur die Windows-Protokolle im Blick gehabt.
Danke
ist auch kein Hacken mehr bei...
Hacken benutzt man im Garten oder hat es am Fuß aber niemals in der IT!!https://www.duden.de/rechtschreibung/Haken
Zitat von @148523:
https://www.duden.de/rechtschreibung/Haken
ist auch kein Hacken mehr bei...
Hacken benutzt man im Garten oder hat es am Fuß aber niemals in der IT!!https://www.duden.de/rechtschreibung/Haken
Habe ich was verpasst?
Zitat von @em-pie:
Moin,
Falls ja ist hier das Problem: Ersetzen bedeutet:
Das könnte die Ursache sein.
Warum das aber bei den UNC-Pfaden passiert: da hab ich derzeit auch keine Idee.
Gibt es Hinweise im Eventlog des Clients?
Moin,
ES gibt sowohl DFS-Shares als auch per GPO gemappte Netzlaufwerke.
Das Laufwerk G: z. B. ist ein DFS-Ordner, der via GPO als Laufwerk gemappt wird.
Wie werden die Laufwerke konkret gemapped? stehen die auf "Ersetzen"?Das Laufwerk G: z. B. ist ein DFS-Ordner, der via GPO als Laufwerk gemappt wird.
Falls ja ist hier das Problem: Ersetzen bedeutet:
- Trenne das Laufwerk (analog zu net use g: /del)
- Verbinde es Neu
Das könnte die Ursache sein.
Warum das aber bei den UNC-Pfaden passiert: da hab ich derzeit auch keine Idee.
Gibt es Hinweise im Eventlog des Clients?
Ergänzend, was unter Microsoft Office Alerts zu finden war:
Microsoft Excel
Das Dokument wurde nicht gespeichert.
P1: 100490
P2: 16.0.15028.20248
P3: xsmhP4: 0x8007003B
Daraus werde ich leider auch nicht schlauer..
Hallo,
Quota voll? Updates bei den Klienten nicht gemacht aber bei den anderen?
Dateipfad wird versucht zu speichern.
Wurde da ein Ordner umbenannt?
Wurde dort ein alter Pfad benutzt der nicht mehr existent ist?
Das wäre die Richtung in die ich schauen würde.
Dobby
Quota voll? Updates bei den Klienten nicht gemacht aber bei den anderen?
Was meistens zu funktionieren scheint: Speichern unter --> Desktop
Dateipfad wurde verschoben und/oder geändert! Oder aber auf einem nicht mehr existierendemDateipfad wird versucht zu speichern.
Anschließend die Datei am eigentlich vorgesehenen Zielort ersetzen.
Ist eine einfache Umgehung des Problems, schließt aber Berechtigungsfehler und Funktionsfehler aus.Wurde da ein Ordner umbenannt?
Wurde dort ein alter Pfad benutzt der nicht mehr existent ist?
Das wäre die Richtung in die ich schauen würde.
Dobby
Zitat von @108012:
Hallo,
Quota voll? Updates bei den Klienten nicht gemacht aber bei den anderen?
Hallo,
Quota voll? Updates bei den Klienten nicht gemacht aber bei den anderen?
Dobby
Guten Morgen,
vielen Dank für deine Ideen.
Es handelt sich hierbei um DFS-N, nach meinem Kenntnisstand gibt es hier kein Quota, sondern nur bei DFS-R?
Was meistens zu funktionieren scheint: Speichern unter --> Desktop
Dateipfad wurde verschoben und/oder geändert! Oder aber auf einem nicht mehr existierendemDateipfad wird versucht zu speichern.
Als ich die Meldung zum ersten Mal bekommen habe, dachte ich das auch. Allerdings tritt es dafür fast zu häufig auf.
Gibt es irgendwelche Logs, in denen ich das Prüfen/überwachen kann?
Anschließend die Datei am eigentlich vorgesehenen Zielort ersetzen.
Ist eine einfache Umgehung des Problems, schließt aber Berechtigungsfehler und Funktionsfehler aus.Wurde da ein Ordner umbenannt?
Wurde dort ein alter Pfad benutzt der nicht mehr existent ist?
Auch das ist nicht unmöglich. Teilweise öffnen die Mitarbeiter morgens um 7 Uhr Dateien und speichern sie dann um 17 Uhr wieder. Dass sich in der Zwischenzeit was ändert, ist nicht unmöglich. --> Logs?
Das wäre die Richtung in die ich schauen würde.
Danke dir
LG
Nils
Hallo,
kurzes Update nach über einem Jahr Fehlersuche :O
Falls jemand anderes vor einem ähnlichen Problem steht:
Ich habe in der DFS Konsole alle Namespaceserver außer unseren Fileserver deaktiviert sowie die DFS-Namespacecachedauer auf 120sec reduziert.
Seit rund einem Monat ist das Problem nicht mehr aufgetreten.
Danke an alle für die Mithilfe.
LG
Nils
kurzes Update nach über einem Jahr Fehlersuche :O
Falls jemand anderes vor einem ähnlichen Problem steht:
Ich habe in der DFS Konsole alle Namespaceserver außer unseren Fileserver deaktiviert sowie die DFS-Namespacecachedauer auf 120sec reduziert.
Seit rund einem Monat ist das Problem nicht mehr aufgetreten.
Danke an alle für die Mithilfe.
LG
Nils
