2
Netzlaufwerke lokal und auf TS teilweise asynchron
Ich bin seit einigen Tagen einem Phänomen auf der Spur, was einigen Benutzern in unserem Netzwerk aufgefallen ist.
Exemplarisch an einem Benutzer:
Ein Benutzer hat sowohl lokal als auch im Terminalserver die selben Netzlaufwerke über GPO gemappt bekommen.
Der Benutzer scannt z.B. über den Bürodrucker ein Dokument ein und das landet im Netzlaufwerk S:
Der Benutzer läuft zu seinem PC zurück und sieht das Dokument in seinem lokal gemappten S: jedoch nicht am Terminalserver.
Oder:
Benutzer verändert lokal Daten in einem Netzlaufwerk - er arbeitet z.B. an einer CAD-Zeichnung, speichert diese und sieht die "neue" Datei auch im Netzlaufwerk mit korrekter Datum und Uhrzeit. Er wechselt in seine Terminalsitzung und will die Datei per Mail verschicken und bemerkt aber, dass die Datei im Netzlaufwerk auf dem TS noch den alten Stand (inkl. Datum und Uhrzeit der vorhergehenden Bearbeitung) und sogar noch mit dem alten Stand geöffnet werden kann.
Das gleiche passiert auch mit gelöschten Dateien und neu angelegten Ordnern.
Betroffen sind davon mehrere Netzlaufwerke.
Nach einiger Zeit macht es dann flupp und das Netzlaufwerk zeigt den korrekten Stand an.
Einmal habe ich das live mitbekommen und da liess sich das Problem durch ab- und wieder anmelden am TS lösen - das kann aber zeitlicher Zufall gewesen sein.
Das Problem ist jetzt:
Offline-Dateien sind auf allen Freigaben deaktiviert
Das Problem tritt nur in unregelmäßigen Abständen auf und ist nicht wirklich reproduzierbar
Es gibt keine Einträge im Ereignislog, die auf ein Fehler hindeuten würden
Es gibt zwar auch einen DFS-Namespace der auf einen Teil dieser Ordner verweist, aber die Laufwerke sind erstens alle über die "normale" Freigabe gemountet und zum anderen sind auch Ordner (z.B. der Scan-Ordner) betroffen, die noch nie etwas mit DFS zu tun hatten und schon immer normale Freigaben waren.
Sonstige Netzwerkprobleme treten nicht auf, DNS funktioniert wunderbar und in alle Richtungen, keine Performanceprobleme.
Hat jemand eine Idee?
Exemplarisch an einem Benutzer:
Ein Benutzer hat sowohl lokal als auch im Terminalserver die selben Netzlaufwerke über GPO gemappt bekommen.
Der Benutzer scannt z.B. über den Bürodrucker ein Dokument ein und das landet im Netzlaufwerk S:
Der Benutzer läuft zu seinem PC zurück und sieht das Dokument in seinem lokal gemappten S: jedoch nicht am Terminalserver.
Oder:
Benutzer verändert lokal Daten in einem Netzlaufwerk - er arbeitet z.B. an einer CAD-Zeichnung, speichert diese und sieht die "neue" Datei auch im Netzlaufwerk mit korrekter Datum und Uhrzeit. Er wechselt in seine Terminalsitzung und will die Datei per Mail verschicken und bemerkt aber, dass die Datei im Netzlaufwerk auf dem TS noch den alten Stand (inkl. Datum und Uhrzeit der vorhergehenden Bearbeitung) und sogar noch mit dem alten Stand geöffnet werden kann.
Das gleiche passiert auch mit gelöschten Dateien und neu angelegten Ordnern.
Betroffen sind davon mehrere Netzlaufwerke.
Nach einiger Zeit macht es dann flupp und das Netzlaufwerk zeigt den korrekten Stand an.
Einmal habe ich das live mitbekommen und da liess sich das Problem durch ab- und wieder anmelden am TS lösen - das kann aber zeitlicher Zufall gewesen sein.
Das Problem ist jetzt:
Offline-Dateien sind auf allen Freigaben deaktiviert
Das Problem tritt nur in unregelmäßigen Abständen auf und ist nicht wirklich reproduzierbar
Es gibt keine Einträge im Ereignislog, die auf ein Fehler hindeuten würden
Es gibt zwar auch einen DFS-Namespace der auf einen Teil dieser Ordner verweist, aber die Laufwerke sind erstens alle über die "normale" Freigabe gemountet und zum anderen sind auch Ordner (z.B. der Scan-Ordner) betroffen, die noch nie etwas mit DFS zu tun hatten und schon immer normale Freigaben waren.
Sonstige Netzwerkprobleme treten nicht auf, DNS funktioniert wunderbar und in alle Richtungen, keine Performanceprobleme.
Hat jemand eine Idee?
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: 223108
Url: https://administrator.de/contentid/223108
Ausgedruckt am: 13.11.2024 um 07:11 Uhr
2 Kommentare
Neuester Kommentar
Tritt das Problem seit ein paar Tagen auf oder ist das Problem erst seit ein paar Tagen aufgefallen? (Sofern sich das beantworten lässt)
Da du DFS schon angesprochen hast... ist es ein einzelner Fileserver, der einen DFS-Stamm hat, oder sind da mehrere Fileserver am Werk, die synchron gehalten werden müssen? Falls ja, ist mehr als ein Fileserver am Standort (Subnetz) des PCs und des Terminalservers?
Da du DFS schon angesprochen hast... ist es ein einzelner Fileserver, der einen DFS-Stamm hat, oder sind da mehrere Fileserver am Werk, die synchron gehalten werden müssen? Falls ja, ist mehr als ein Fileserver am Standort (Subnetz) des PCs und des Terminalservers?
Zitat von @loonydeluxe:
Tritt das Problem seit ein paar Tagen auf oder ist das Problem erst seit ein paar Tagen aufgefallen? (Sofern sich das beantworten
lässt)
Da du DFS schon angesprochen hast... ist es ein einzelner Fileserver, der einen DFS-Stamm hat, oder sind da mehrere Fileserver am
Werk, die synchron gehalten werden müssen? Falls ja, ist mehr als ein Fileserver am Standort (Subnetz) des PCs und des
Terminalservers?
Tritt das Problem seit ein paar Tagen auf oder ist das Problem erst seit ein paar Tagen aufgefallen? (Sofern sich das beantworten
lässt)
Da du DFS schon angesprochen hast... ist es ein einzelner Fileserver, der einen DFS-Stamm hat, oder sind da mehrere Fileserver am
Werk, die synchron gehalten werden müssen? Falls ja, ist mehr als ein Fileserver am Standort (Subnetz) des PCs und des
Terminalservers?
Danke für die Antwort.
Das Problem ist erst ein paar Tage lang aufgefallen, muss aber schon länger bestehen.
DFS verwende ich nur zur Replikation einer Handvoll Verzeichnisse. Alle Freigaben sind klassisch über GPO mit \\server\share gemappt.
Ich bin durch Zufall jetzt auf eine mögliche Lösung gestossen.
Und zwar gibt es da wohl ein Problem mit dem RDP-Protokoll, welches Microsoft durch einen Hotfix beseitigt:
Hier der entsprechende KB-Artikel: http://support.microsoft.com/kb/2769790/de
Das habe ich am Wochenende jetzt mal eingespielt und jetzt schaue ich mal, ob das Problem weg ist.
