Win 2008 R2 - Netzlaufwerk wird mit rotem X als nicht verbunden angezeigt - Zugriff besteht trotzdem
Hallo zusammen,
im Einsatz sind zwei Terminalserver 2008 R2.
Die User starten Remotedesktopverbindungen.
Verschiedene Netzlaufwerke werden durch das beim AD-Benutzerobjekt hinterlegte BAT-Script (Script-Datei ist in der Sysvol-Freigabe gespeichert) bei der Anmeldung automatisch gemappt (NET USE).
Problem:
Seit einiger Zeit wird bei allen Benutzern, die auf beiden Terminalservern arbeiten, immer das Laufwerk "U:" mit einem roten Kreuz als nicht verbundenes Netzlaufwerk angezeigt.
Alle anderen Netzlaufwerke werden korrekt angezeigt.
Wenn man allerdings Doppelklick auf dieses Netzlaufwerk "U:" macht, dann funktioniert der Zugriff auf den Dateiserver.
Es sind Netzwerkanwendungen auf den Terminalservern im Einsatz, die Schwierigkeiten haben, sobald das Netzlaufwerk U: über das die Anwendungen ausgeführt werden, mit rotem Kreuz angezeigt wird.
Früher war im AD-Benutzerobjekt immer als Basisordner Netzlaufwerk Z: gemappt.
Diese Einstellung wurde nun, da nicht mehr benötigt, im AD-Benutzerobjekt entfernt, das heißt lokaler Basisordner.
Nun tritt in der TS-Sitzung das Problem auf, dass Z: auch als nicht verbundenes Netzlaufwerk angezeigt wird und wenn man Doppelklick auf Z: macht, wird merwürdiger weise die Netzwerkfreigabe, die zu Netzlaufwerk U: gehört geöffnet.
Merkwürdig ist, dass wenn man die beiden Terminalserver neustartet, auf beiden Terminalservern bei allen Benutzern das Netzlaufwerk ca. 2 Tage korrekt mit grünem, also verbundenen Symbol angezeigt wird.
Dann kommt es am nächsten Tag auf beiden Terminalservern und allen Benutzern wieder zu dem Problemverhalten.
1. Wie kann ich das Problem beseitigen?
2. Gibt es eine bessere Variante Netzlaufwerke für TS-Sitzungen zu mappen (anlegen und beim Logon aktualisieren), ggf. über GPO?
3. Was kann die Ursache des Problems sein (evtl. Netzwerkfehler verursacht durch SMB1 und SMB2 oder fehlende Windows Patchs)?
Vielen Dank für Tipps!
Gruß
im Einsatz sind zwei Terminalserver 2008 R2.
Die User starten Remotedesktopverbindungen.
Verschiedene Netzlaufwerke werden durch das beim AD-Benutzerobjekt hinterlegte BAT-Script (Script-Datei ist in der Sysvol-Freigabe gespeichert) bei der Anmeldung automatisch gemappt (NET USE).
Problem:
Seit einiger Zeit wird bei allen Benutzern, die auf beiden Terminalservern arbeiten, immer das Laufwerk "U:" mit einem roten Kreuz als nicht verbundenes Netzlaufwerk angezeigt.
Alle anderen Netzlaufwerke werden korrekt angezeigt.
Wenn man allerdings Doppelklick auf dieses Netzlaufwerk "U:" macht, dann funktioniert der Zugriff auf den Dateiserver.
Es sind Netzwerkanwendungen auf den Terminalservern im Einsatz, die Schwierigkeiten haben, sobald das Netzlaufwerk U: über das die Anwendungen ausgeführt werden, mit rotem Kreuz angezeigt wird.
Früher war im AD-Benutzerobjekt immer als Basisordner Netzlaufwerk Z: gemappt.
Diese Einstellung wurde nun, da nicht mehr benötigt, im AD-Benutzerobjekt entfernt, das heißt lokaler Basisordner.
Nun tritt in der TS-Sitzung das Problem auf, dass Z: auch als nicht verbundenes Netzlaufwerk angezeigt wird und wenn man Doppelklick auf Z: macht, wird merwürdiger weise die Netzwerkfreigabe, die zu Netzlaufwerk U: gehört geöffnet.
Merkwürdig ist, dass wenn man die beiden Terminalserver neustartet, auf beiden Terminalservern bei allen Benutzern das Netzlaufwerk ca. 2 Tage korrekt mit grünem, also verbundenen Symbol angezeigt wird.
Dann kommt es am nächsten Tag auf beiden Terminalservern und allen Benutzern wieder zu dem Problemverhalten.
1. Wie kann ich das Problem beseitigen?
2. Gibt es eine bessere Variante Netzlaufwerke für TS-Sitzungen zu mappen (anlegen und beim Logon aktualisieren), ggf. über GPO?
3. Was kann die Ursache des Problems sein (evtl. Netzwerkfehler verursacht durch SMB1 und SMB2 oder fehlende Windows Patchs)?
Vielen Dank für Tipps!
Gruß
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 173559
Url: https://administrator.de/contentid/173559
Ausgedruckt am: 20.11.2024 um 03:11 Uhr
18 Kommentare
Neuester Kommentar
moinsen,
nur mal aus Jux und Dollerei...
ein
ins Ende vom Loginscript schreiben, schadet nix, ist nicht elegant und nur ein krummer Würgaround, der nur ein Notnageltest ist.
Ich würde mir aber das Eventlog vom TS und vom betreffenden Fileserver anschauen....
Gruß
nur mal aus Jux und Dollerei...
ein
cd /d u:\ >nul 2>nul
Ich würde mir aber das Eventlog vom TS und vom betreffenden Fileserver anschauen....
Gruß
moinsen...
nun hab ich das mal genauer durchgelesen...
nun hab ich das mal genauer durchgelesen...
Früher war im AD-Benutzerobjekt immer als Basisordner Netzlaufwerk Z: gemappt.
Diese Einstellung wurde nun, da nicht mehr benötigt, im AD-Benutzerobjekt entfernt, das heißt lokaler Basisordner.
wenn man Doppelklick auf Z: macht, wird merwürdiger weise die Netzwerkfreigabe, die zu Netzlaufwerk U: gehört geöffnet.
Diese Einstellung wurde nun, da nicht mehr benötigt, im AD-Benutzerobjekt entfernt, das heißt lokaler Basisordner.
wenn man Doppelklick auf Z: macht, wird merwürdiger weise die Netzwerkfreigabe, die zu Netzlaufwerk U: gehört geöffnet.
- wer hat das gesagt, dass der Basisordner z:\ nicht mehr gebraucht wird?
- steht ein net use z: /d im Loginscript?
- ist das verbinden vom Basislaufwerk z: bei allen Usern rausgenommen?
- schonmal mit einem neu angelegten User probiert, der die Einstellung z:\ nie bekommen hat?
naabend..
Und ihr habt zufälligerweise das zum Bleistift Office Paket auf dem TS Server installiert?
Nein auch wenn hst-winf drum bettelt, das loginscript müssen wir gar nicht lesen, aber ganz ehrlich Viper - du solltest dir ein paar MSPress Bücher anlachen und unters Kopfkissen legen...
schau mal spasseshalber in der Registry, und du wirst dich wundern, ärgern und es beim nächsten mal besser wissen...
N8.
Mit dem Basisordner der aus der Einstellung des AD-Benutzerobjekts kam früher wurde lediglich auf z.B. \\SERVER\PROFILES\USERXY also auf den Benutzerprofilordner gemappt (servergespeichertes Userprofil), mehr nicht.
Und ihr habt zufälligerweise das zum Bleistift Office Paket auf dem TS Server installiert?
Nein auch wenn hst-winf drum bettelt, das loginscript müssen wir gar nicht lesen, aber ganz ehrlich Viper - du solltest dir ein paar MSPress Bücher anlachen und unters Kopfkissen legen...
schau mal spasseshalber in der Registry, und du wirst dich wundern, ärgern und es beim nächsten mal besser wissen...
N8.
hallo,
hattest du denn mal versucht die Laufwerke mit net use /delete am Anfang des scriptes erst zu entfernen und dann mit den vorhandenen befehlen hinzuzufügen?
Also:
NET USE * /delete
REM Laufwerkszuordnungen
NET USE G: \\SERVER\SHARE1
NET USE H: \\SERVER\SHARE2
NET USE M: \\SERVER\SHARE3
NET USE P: \\SERVER\SHARE4
NET USE R: \\MAIL\SHARE5
NET USE T: \\SERVER\SHARE6
NET USE U: \\SERVER\SHARE7
Gruß
hattest du denn mal versucht die Laufwerke mit net use /delete am Anfang des scriptes erst zu entfernen und dann mit den vorhandenen befehlen hinzuzufügen?
Also:
NET USE * /delete
REM Laufwerkszuordnungen
NET USE G: \\SERVER\SHARE1
NET USE H: \\SERVER\SHARE2
NET USE M: \\SERVER\SHARE3
NET USE P: \\SERVER\SHARE4
NET USE R: \\MAIL\SHARE5
NET USE T: \\SERVER\SHARE6
NET USE U: \\SERVER\SHARE7
Gruß
moin,
N8
Zitat von @Excaliburx:
Hallo,
ja, auf den TS ist das Office Paket installiert.
Bitte um nähere Hinweise, was nun Office damit zu tun hat mit dem Basisordner bzw. Z:
Mittlerweile kennen wir beide uns doch, les mal geanu, was ich geschrieben habe und dann das, was zwischen den Zeilen steht.Hallo,
ja, auf den TS ist das Office Paket installiert.
Bitte um nähere Hinweise, was nun Office damit zu tun hat mit dem Basisordner bzw. Z:
Welche MSPress Bücher sollte ich mir denn anschauen bitte?
- Um welche Themen haben sich denn deine letzten Fragen allesamt gedreht?
Und welche Registry Einträge?
welches Office?Hinweis:
Habe die Freigabenemen in SHARE geändert, da ich die Freigabenamen nicht bekannt geben soll.
Habe die Freigabenemen in SHARE geändert, da ich die Freigabenamen nicht bekannt geben soll.
Danke!
N8
Moinsen,
darf ich dich zitieren?
Das sowas nicht normal ist und das man sowas nichtmal in Redmont unabsichtlich verzimmert hat, dürfte sogar der Philipp Rösler einsehen.
Und die Tatsache, das du es bis jetzt noch nicht geschafft hast, mal in der Registry nach deinem hier antonymisierten Pfaden, die sich eventuell hinter z oder u verbergen, zu suchen - sagen mir mit deinem Elan etwas zu lösen und sich einem selbstgemachten Problem zu stellen - stimmt was nicht.
Denk mal wirklich drüber nach.
N8
Zitat von @Excaliburx:
Hallo zusammen,
hat niemand eine Lösung für das Problem mit den roten X bei dem Netzlaufwerk?
Hallo zusammen,
hat niemand eine Lösung für das Problem mit den roten X bei dem Netzlaufwerk?
darf ich dich zitieren?
Nun tritt in der TS-Sitzung das Problem auf, dass Z: auch als nicht verbundenes Netzlaufwerk angezeigt wird und wenn man Doppelklick auf Z: macht, wird merwürdiger weise die Netzwerkfreigabe, die zu Netzlaufwerk U: gehört geöffnet.
Das sowas nicht normal ist und das man sowas nichtmal in Redmont unabsichtlich verzimmert hat, dürfte sogar der Philipp Rösler einsehen.
Und die Tatsache, das du es bis jetzt noch nicht geschafft hast, mal in der Registry nach deinem hier antonymisierten Pfaden, die sich eventuell hinter z oder u verbergen, zu suchen - sagen mir mit deinem Elan etwas zu lösen und sich einem selbstgemachten Problem zu stellen - stimmt was nicht.
Denk mal wirklich drüber nach.
N8
Zitat von @Excaliburx:
Hi,
vielen Dank für die hilfreiche Antwort auf meine Fragen "TimoBeil".
PS:
Das Problem wurde bisher von mir beseitigt!
Gruß
Hi,
vielen Dank für die hilfreiche Antwort auf meine Fragen "TimoBeil".
PS:
Das Problem wurde bisher von mir beseitigt!
Gruß
Hi,
was hast du denn gegen dein Problem getan? Ich habe hier ein ähliches Problem, allerdings werden bei einem Clientenpc die Netzlaufwerke als offline angezeigt und nicht bei einer Terminalsitzung. Sobald man auf die rot ge - x - ten Laufwerke klickt besteht zugriff und es wird grün angezeigt.
Hallo,
ich weiß, dass Thema ist alt, aber ich stehe momentan vor demselben Problem. Wenn also jemand die Lösung kennt, dann postet es doch bitte.
Das Problem wird bei uns vermutlich durch einen bestimmten User verursacht.
Beispiel: Samstags booten alle TS. User X meldet sich moontags an TS 1 ein, die Session des Users wird zum Feierabend nicht abgemeldet sondern nur getrennt. Am Dienstag findet ein Reconnect auf TS 1 statt. Alle User, die sich jetzt neu mit TS 1 verbinden sehen ein rotes Kreuz vor einer der zahlreichen Laufwerksverbindungen. Der Zugriff ist dennoch möglich. User X selbst sieht die Laufwerksverbindung ohne rotes Kreuz. Nach einem Neustart von TS1 ist alles wieder ok. Das Problem wandert scheinbar mit User X zum nächsten TS, aber auch erst, wenn die Session "über Nacht" nur getrennt wird anstatt ab- und neu angemeldet wird.
Das Problem tritt sowohl bei Usern auf, die ihre LW-Verbindungen via Logonscript verbunden bekommen als auch bei Usern, die via GPO ihre Laufwerke erhalten.
Ich habe versucht mittels Procmon und Regshot die Ursache zu ermitteln - leider ohne Erfolg bislang.
Bin für jeden Tipp dankbar.
Gruß
AndKon
ich weiß, dass Thema ist alt, aber ich stehe momentan vor demselben Problem. Wenn also jemand die Lösung kennt, dann postet es doch bitte.
Das Problem wird bei uns vermutlich durch einen bestimmten User verursacht.
Beispiel: Samstags booten alle TS. User X meldet sich moontags an TS 1 ein, die Session des Users wird zum Feierabend nicht abgemeldet sondern nur getrennt. Am Dienstag findet ein Reconnect auf TS 1 statt. Alle User, die sich jetzt neu mit TS 1 verbinden sehen ein rotes Kreuz vor einer der zahlreichen Laufwerksverbindungen. Der Zugriff ist dennoch möglich. User X selbst sieht die Laufwerksverbindung ohne rotes Kreuz. Nach einem Neustart von TS1 ist alles wieder ok. Das Problem wandert scheinbar mit User X zum nächsten TS, aber auch erst, wenn die Session "über Nacht" nur getrennt wird anstatt ab- und neu angemeldet wird.
Das Problem tritt sowohl bei Usern auf, die ihre LW-Verbindungen via Logonscript verbunden bekommen als auch bei Usern, die via GPO ihre Laufwerke erhalten.
Ich habe versucht mittels Procmon und Regshot die Ursache zu ermitteln - leider ohne Erfolg bislang.
Bin für jeden Tipp dankbar.
Gruß
AndKon