Bei Windows 10 beklagen Benutzer ja immer wieder eine unvollständige oder fehlerhafte Einbindung von Netzlaufwerken. Das scheint aber ein Feature zu sein, welches Microsoft mal eingeführt hat. Ich stelle mal eine Information hier im Blog ein, die mir gerade unter die Augen gekommen ist.
Anzeige
Worum geht es beim Netzlaufwerk-Problem?
Ich hatte das Thema vor einiger Zeit im Blog-Beitrag Windows 10: Netzlaufwerke unvollständig verbundenen schon mal aufgegriffen. Benutzer von Windows 10 (und älteren Betriebssystemversionen) laufen bei Verwendung von Netzlaufwerken in ein nerviges Problem. Diese Netzlaufwerke werden beim Start oder im Betrieb nicht sauber eingebunden.
Der Speicherplatz für dieses Netzlaufwerk wird zwar angezeigt, aber die Verbindung ist nicht da. Der obige Screenshot zeigt dieses Szenario. Die mit einem roten X versehenen Laufwerke müssen angeklickt werden, um auf die Inhalte zugreifen zu können.
Blog-Leser Karl hatte mich bereits im November 2017 auf dieses Problem in Windows 10 aufmerksam gemacht. Karl schrieb dazu:
Anzeige
Es ist wirklich sehr nervig, und ich frage mich, ob ich wohl der einzige Benutzer bin der zuhause Netzwerklaufwerke nutzt. Ein NAS (Ziel-PC läuft mit Windows 10) ist doch heute nichts mehr besonderes.
Ich habe so viele Versuche unternommen um Microsoft dazu zu bewegen sich der Sache anzunehmen.
Blog-Leser Karl hat das Thema kürzlich bei Twitter erneut auf die Agende gebracht und @MicrosoftHelps mit adressiert.
@woodyleonhard @etguenni @SBSDiva @MicrosoftHelps It's still unfixed in 1809. Bug exists since Windows 7, also in Enterprises.
Partly connected network drives after start up.
Ticket SR1406423459, raised in November 2017.
I would like speak to a support engineer please. pic.twitter.com/btRnYPK7Sp— al Qamar (@Karl_F1_Fan) 7. Oktober 2018
Interessante Rückmeldung von SBSDiva
Auf diesem Tweet gab es dann eine interessante Rückmeldung von @SBSDiva. Hinter diesem Twitter-Namen verbirgt sich Susan Bradley, die bei askwoody.com und auch auf patchmanagement.org sehr aktiv ist. Susan Bradley weist in ihrer Antwort darauf hin, dass das Ganze ein Feature und by design sei.
That's actually a feature. Disable autodisconnect and that will stop happening https://t.co/llqu6gGXwD In Enterprises, they don't want all mapped drives to light up. I've disabled this for years
— SBSDiva (@SBSDiva) 7. Oktober 2018
Ist das ein Feature?
Microsoft hat zu Zeiten von Windows Server 2003 und Windows 7 den Support-Beitrag Mapped Drive Connection to Network Share May Be Lost veröffentlicht, und diesen letztmalig im Mai 2018 aktualisiert. Dort schreibt man:
On a computer that runs one of the versions of Windows that is listed at the beginning of this article, if you map a drive to a network share, the mapped drive may be disconnected after a regular interval of inactivity, and Windows Explorer may display a red "X" on the icon of the mapped drive. However, if you try to access or browse the mapped drive, it reconnects quickly.
In Kurz: Eingerichtete Netzlaufwerke können irgendwann mit einem roten X angezeigt werden, wenn die Verbindung verloren geht. Greift man auf die Netzlaufwerke zu oder navigiert man durch die Laufwerke, sollte die Verbindung wiederhergestellt werden. Das Ganze bezieht sich zwar auf Windows 7 und älter. Aber das 'Fehlerbild' entspricht dem, was oben für Windows 10 beschrieben wurde. Überrascht hat mich dann die Erklärung Microsofts:
This behavior occurs because the systems can drop idle connections after a specified time-out period (by default, 15 minutes) to prevent wasting server resources on unused sessions. The connection can be re-established very quickly, if required.
Das soll also so sein, nicht benutzte Netzwerkverbindungen werden nach 15 Minuten als eingerichtetes Netzlaufwerk getrennt. Das soll Server-Ressoucen schonen. Ein Klick auf das Laufwerk stellt die Verbindung wieder her. Im Microsoft-Beitrag wird dann beschrieben, wie man den Timeout-Wert über die Registrierung anpassen kann. Mit dem Befehl:
net config server /autodisconnect:-1
ausgeführt in einer administrativen Eingabeaufforderung (am Server), lässt sich diese automatische Trennung deaktivieren. Frage: Löst dies das Netzlaufmapping-Problem unter Windows 10? Betroffene können da ja ggf. mal Rückmeldung geben, ob der obige Befehl geholfen hat. Bei NAS-Laufwerken dürfte das aber eher nicht helfen.
Ergänzung: Auf Facebook hat Mark Heitbrink mich noch auf diese uralte Newsgroup-Diskussion hingewiesen, die sich mit der Thematik befasst.
Ähnliche Artikel:
Windows 10 Wiki/FAQ
Windows 10: Netzlaufwerke unvollständig verbundenen
Windows 10 Netzwerkübersicht
Windows 10-Fehler: Netzwerkprotokoll fehlt – Teil 1
Windows 10: Falle bei Netzwerk-Zugriffen
Netzwerksymbol zeigt Störung (roter Kreis mit X)
Windows 10 Version 1703: Netzwerkdrucker nicht installierbar
Windows 10: Updates belegen ganze Netzwerkbandbreite
Windows 10: Netzwerk zeigt Fehler 0x80070035
Windows 10: Abschied von der Heimnetzgruppe
Anzeige
… werde ich glatt mal ausprobieren. Mit diesem Problem schlage ich mich auch schon seit Jahren herum. Hoffe auf eine Lösung :)
Aktuell nutze ich eine ganz pragmatische Lösung. Über eine kleines batch file (sh. https://www.xblogger.de/usb-festplatte-an-fritzbox-nutzen-1116/) wird einfach das Netzlaufwerk bei jeden Start neu gesetzt und per robocopy eine Datei auf mein NAS kopiert. Somit habe ich ein aktives Netzlaufwerk und zudem die angeschlossen Platte ggf. aus dem sleep geweckt. Das Ganze kann dann auch noch als Trigger für ein tgl. Backup genutzt werden.
Sorry … aber ich sehe das Problem nicht…..
Das Netzlaufwerk ist vorhanden und wenn ich es anklicke dann kann man darauf zugreifen.
Es gibt wohl genügend Leute, denen das Verhalten Ärger macht – z.B. werden Scripte aller Art scheitern, die diese Laufwerke brauchen …
Das freut mich für Dich Rolf.
Es gibt aber auch noch genügend Software (wie z.B. unser ERP) die auf ein gemapptes Laufwerk angewiesen sind, dazu kommen noch z.B. unternehmensweite CAD Bibliotheken, Office Vorlagen etc. Da Windows die Verbindung zu den Laufwerken nur durch draufklicken wiederherstellt und nicht beim Zugriff kannst halt gar nicht mehr arbeiten bevor nicht alle Laufwerke durchgeklickt wurden. Genauso wenig kann man Dateien z.B. aus Office oder über den Explorer Schnellzugriff direkt aufmachen.
Das Problem ist nicht, dass ich im explorer das Laufwerk anclicke und dann die Verbindung hergestellt wird, sondern das Problem ist, dass ich z.B. einen Link auf eine Anwendung auf einem Netzwerklaufwerk habe und dieser nicht funktioniert weil das Netzwerklaufwerk nicht vorhanden ist.
Ich habe das Problem bei Kunden und das ist sehr lästig immer erst das Laufwerk anzuclicken und dann erst die Applikation zu starten.
Die hier beschriebene Vorgangsweise betrifft aber den Server-Dienst, muss also am PC/Server mit der Ordnerfreigabe ausgeführt werden! Auf der Client-Seite hilft das gar nicht!
Stimmt, danke für die Klarstellung
Wir sind den Upgrade von 2016 LTSB (1607) auf LTSC 2019 (1809) am testen und da ist mir das Verhalten mit den Netzlaufwerken auch aufgefallen.
Habe den folgenden Befehl auf einem Windows Server 2016 ausgeführt, aber
der Client meldet immer noch dass das Netzlaufwerk nicht wiederhergestellt werden kann.
net config server /autodisconnect:-1
Habe Windows 10 v1809 und Windows 10 LTSC 2019 ebenfalls getestet und bin auf keinen grünen Zweig gekommen. Hier hatte ich schon meine Eindrücke hinterlassen:
https://www.borncity.com/blog/2018/10/04/windows-10-oktober-update-version-1809-upgrade-faq/#comment-63414
So sieht das bei mir mit LTSC 2019 aus:
https://oli.new-lan.de/wp-content/uploads/2018/10/win10_ltsc_2019_drivemap_failed.png
Falls ihr eine Lösung findet, melden :F.
Ich glaube aber Günther hat hier 2 Symptome durcheinander geworfen. Das Drive-Map-GPP-Problem ab v1809 / LTSC 2019 hat jetzt erstmal nichts mit dem Autodisconnect-Problem zu tun, welches ja schon länger gibt. Das ist eigt. bekannt und abschaltbar. Wir haben das übrigens gar nicht konfiguriert und trotzdem funktionieren bei uns die Laufwerkmappings problemlos (liegt vlt. am Domänennetzwerk?). Erst mit 1809/LTSC 2019 halt die Probleme. Den Registry-Eintrag fürs Abschalten des Autodisconnects hatte ich dann natürlich trotzdem getestet, aber wie bei Markus ohne Erfolg. Wie ich schon im anderen Beitrag schrieb, irgendetwas hat MS geändert und es nicht kommuniziert.
diese vermutung trifft zumindest in jedem fall (windows pc mit inet) auf geräte-treiber zu. was genau dort geändert wurde da bin ich noch nicht hintergestiegen (außer dass es am 11. september (sowenig meine wahl wie der 8. mai…) per update den letzten tritt zum GO bekommen hat). dass es ein problem gibt konnte ich in den berechtigungen für den registry-zweig: HKLM/system/ccs/sessionmanager/enum/pci nachvollziehen. der selbe wurde von ms auch in "workarounds" bezüglich des bis heute schleierhaften .inf eintrags im gerätemanager erwähnt. ich sage, dass es auch den von mir erwähnten vpn treiber oemvista.inf betrifft, aber vpn wirkt allgemein unwiederstehlich für microschrott. da wird nichts an ort und stelle gelassen..
irgend ein treiber wird auch vom server, oder client für das nlw verwendet, den würde ich mir mal ansehen (ereignisse), wäre NULL überrascht wenn sich dort etwas fände..
ich bin mir nach wie vor unschlüssig was dieses "betriebssystem" betrifft, außer darin dass ich mich von diesem kein 3. mal werde anp***** lassen. ich bin bereits mehr als bedient!
gruß!
Kann man eine ISO-Testversion von LTSC 2109 bei Microsoft herunterladen?
Leute… wenn ich schon lese "bereits 2017…" LOL! – das "Problem" besteht seit der Einführung von Windows 8 (2012). Beispiel: Ich habe zu Hause ein NAS.
Wenn ich meinen Rechner neu starte, bekomme ich jedes Mal (100%) die Meldung "konnte nicht alle Netzlaufwerke verbinden". Wenn ich meinen Rechner runterfahre und sofort wieder hochfahre, passiert das NIE (0%). Was ist da nun der Unterschied?
Ich verwende "fast startup". Das ist seit Win8 bei UEFi-Installationen der Default und dient dazu, Zeit beim Booten zu sparen, indem Kernel-Hibernation eingesetzt wird.
Beim Vorgang "Runterfahren – Hochfahren" wird fast startup benutzt. Der PC startet schnell (SSD), die Netzwerkkarte ist noch nicht voll initialisiert und schon schlägt der Timeout in Windows zu und Windows informiert (!), dass es das NLW nicht wiederverbinden konnte. Das ist eine Info, und kein Fehler!
Startet man jedoch neu, wird fast startup gar nicht benutzt, der Rechner braucht ein paar Sekunden länger und alles ist gut! Moment, ist im anderen Fall mit "fast startup" etwa nicht "alles gut"? Doch, bereits 2 Sekunden, nachdem die Infomeldung kommt, kann ich die NLWs benutzen. Es ist lediglich ein ungünstig kurz gewählter Timeout.
Wer jetzt hofft, fast startup deaktivieren zu können, hat die Zeilen nicht verstanden, denn es verhält sich genau anders herum: mit fast startup geht es in der Regel.
Auch ohne fast startup kann das Problem auftreten, wenn die Netzwerkkarte schlicht zu lange braucht. Probiert andere Treiber, andere Netzwerkkarten, oder wartet schlicht 5 Sekunden und ignoriert die Meldung. Skripte oder Programme, die so döselig eingestellt sind, dass sie sofort nach der Anmeldung loslaufen sollen und NLWs nutzen wollen, gehören angepasst.
Klasse, mit aktiviertem Schnellstart geht aber bekanntermaßen u.a. kein WOL mehr.
Abgesehen davon geht es nicht um die Meldung an sich, die hatten wir auch schon ewig, trotzdem waren die Netzlaufwerke verbunden. Es geht darum dass die Netzlaufwerke jetzt plötzlich nicht mehr verbunden sind bzw. automatisch verbunden werden, und das sehe ich sehr wohl als Fehler!
Hallo,
dieses Problem ist lästig und leider schon (ur)alt.
Meistens löse ich es (halbwegs) mit dem Regedit-Schnipsel:
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\lanmanserver\parameters]
"autodisconnect"=dword:0000ffff
"enableforcedlogoff"=dword:00000001
Gruß SH
Beseht das Problem auch, wenn man ein NWL per skript in autostart beim Anmelden mounten möchte?
Ich nutze hier noch Win7, da funktioniert alles so wie es sein soll. Mit Win10 habe ich noch keine Erfahrung, deshalb meine Frage dazu.
Grüße
Das Problem tritt ebenfalls bei einem Linux File Server auf!
Die Win Clients haben in dieser Konstelation ebenfalls das rote X bei gemappten Lw.
"net config server /autodisconnect:-1"
schön und gut, aber es wäre hilfreich zu wissen, wie man dies wieder rückgängig machen kann (default-Wert).
Wie ich das verstandenhab ersetzt man die -1 durch eine 15
15 für 15 Minuten timeout wie im Artikel erwähnt
Hallo Zusammen,
das Problem ist ja seit Windows 7 allseits bekannt.
In einem AD-Umfeld läßt sich das jedoch sehr einfach lösen:
Eine GPO auf Computerbasis erstellen mit der Einstellung „Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten" aktiviert sowie „Wartezeit für Richtlinienverarbeitung beim Systemstart angeben" 20 Sekunden erstellen.
Mit einer weiteren GPO auf Benutzerebene das Netzlaufwerk einbinden und dabei die Option „Verbindung wiederherstellen" aktivieren.
Wer es ganz elegant lösen möchte nimmt eine DFS-Namespace-Adresse anstatt der Freigabe-Adresse auf dem Server.
Mit diesen Einstellungen habe ich das Problem seit Jahren nicht mehr auf den Workstations der User.
MfG
Genau mit diesen Einstellungen habe ich das Problem seit Jahren nicht mehr auf den Workstations der User…. jep, bis da kam Windows 1809
Ich lass hier die Clients weder aufs Netzwerk warten, noch ist eine Wartezeit für die GPOs eingerichtet. Die Netzlaufwerke kommen ganz normal per GPO und eingerichtet ist, dass sie nicht persistent gemappt werden sollen.
Ich kenn die Problematik von hier überhaupt nicht. Unter keinem Windows in der Domäne. Da muss irgendwie noch mehr reinspielen.
Wenn ich aber testweise ein W10 Home, d.h. kein Domänenmitglied, manuell mit Netzlaufwerken an den gleichen Server anbinde und den Haken setze, er möge die Netzwerke automatisch wieder verbinden, sehe ich genau den Effekt, dass sie beim Systemstart nicht verbunden sind, sondern erst nach einem Klick aufs rote X.
Lese ich in Susan Bradly einen gewissen Sarkasmus der Begründung dass das ganze ein Feature by design sei heraus?
Ich bin davon ausgegangen das es ein Fehler beim Wiederverbinden ist, da ich selbiges Problem bei mir mit Windows 10 und eingebundenen Netzlaufwerken von Windows 7 als auch Windows Server 2012 r2 gibt, das Problem oder 'Feature by design' tritt jedoch bei mir nicht immer auf.
Ich habe einen Fileserver auf Basis von Samba unter Linux laufen und exakt das gleiche Problem an meinen Windows Clients nach jedem Start des Rechners. Für mich ist das jedoch nicht schlimm, weil ich eben keine Scripte habe, die auf eine Anwendung auf einem Netzwerklaufwerk zugreifen müssen. Ich bin der Meinung, dass Windows auf Teufel komm raus versucht, eine Verbindung zu einem Netzwerklaufwerk her zu stellen, obwohl die Netzwerkverbindung des Rechners noch gar nicht bereit ist. Also ein schlichtes Timing-Problem, das Winzigweich aber völlig egal ist. Im Grunde würde auch eine kleine Batchdatei im Autostart des Clients reichen, der alle Netzwerklaufwerke trennt und danach neu verbindet. "net use" existiert ja.
Das werde ich heute Abend auch ausprobieren – ist schon sehr nervig wenn auf einem Laptop die automatische Sicherung fehlschlägt, weil das Programm das Netzlaufwerk als "nicht verbunden" ansieht.
Allerdings wundert es mich schon stark, dass es ein "Feature" im eigentlichen Sinn sein soll: (verstehe den Hintergrund durchaus) bei meinem Win10 Laptop und einem neu installierten Win7 PC sind alle Laufwerke immer verbunden, zwei andere, schon länger installierte Win7 Laptops weisen den Fehler auf. Konsistenz?
Danke an Günther und den Blog Leser, dass es hier offenbar eine Lösung gibt.
Bei uns war der WSUS zu aktiv und hat schon das 1809 freigegeben. Einige Clients haben es schon und bei denen wird beim Start das Netzlaufwerk nicht mehr richtig verbunden! Ich habe heut Abend auf das Monats-Update auf die 17763.55 gehofft, wurde aber enttäuscht – da wurde das Problem noch nicht gefixt!
Es nervt echt, wenn jeder anruft, weil er eine Bilder in der Warenwirtschaft hat, da das Netzlaufwerk nicht richtig verbunden ist!
Man versteht das irgendwie auch alles nicht mehr – habe zuletzt die cmd als Admin ausgeführt und wollte auf das Netz-LW wechseln, aber da hat er es gar nicht gekannt. CMD als "normaler" Benutzer ausgeführt konnte er drauf zugreifen.
Habt ihr auch schon die Erfahrung gemacht?
Jop, hatte alles schon hier geschrieben:
https://www.borncity.com/blog/2018/10/04/windows-10-oktober-update-version-1809-upgrade-faq/#comment-63414
Betrifft auch die LTSC 2019 Version. Abwarten und Tee trinken, v1809 würd ich im WSUS noch nicht freigeben bzw. die Genehmigung wieder entziehen. Irgendetwas wurde von MS geändert und noch nicht kommuniziert. Oder es ist einfach ein Bug.
>Man versteht das irgendwie auch alles nicht mehr – habe zuletzt die cmd als >Admin ausgeführt und wollte auf das Netz-LW wechseln, aber da hat er es gar >nicht gekannt. CMD als "normaler" Benutzer ausgeführt konnte er drauf >zugreifen.
Korrigiert mich, falls ich falsch liege, ist das nicht sogar korrekt? Eigentlich hebt man doch mit "Als Admin ausführen" den für Zugriffe auf Netzlaufwerke nötigen Userkontext auf.
Hallo Leidensgenossen,
ich habe zumindest für meine Domain Clients (im folgenden "Opfer" genannt) eine Lösung gefunden.
1) In der GPP der einzelnen Laufwerkszuordnungen"Verbindung wiederherstellen" deaktivieren
2) ggf. gpupdate auf dem Opfer durchführen
3) Wichtig: erst alle Mappings auf dem Opfer per Hand trennen (löschen per GPP ging bei mir nicht), nach Neustart sind alle Laufwerke ohne rotes Kreuz da
In der GPP der einzelnen Laufwerkszuordnungen"Verbindung wiederherstellen" deaktiviert lassen!!! Sonst geht die ganze Kacke von vorne los.
Ich verstehe es zwar nicht, aber ich geb's mit MS bald echt auf…
Thx Tom, werds mal testen. Die Option "Verbindung wiederherstellen" zu deaktivieren, bin ich jetzt gar nicht gekommen. Obwohl es durchaus Sinn macht, dass diese Option einen Einfluss haben könnte.
Habe es gerade getestet! Bei mir hat es auch geholfen, einfach die Option "Verbindung wiederherstellen" zu deaktivieren!
Mal schauen, ob das Problem jetzt dauerhaft gelöst ist!
Wieso macht Microsoft wirklich so unnötige Änderungen!??!?!
Hi Tom,
coole Sache, hat bei uns auch funktioniert :). Hatte wirklich schon alles andere probiert.
Nur komisch das bis Version 1803 wirklich alles sauber funktionierte.
LG
Ralf
Sauber, danke Tom, funktioniert tatsächlich. Ich hatte noch ein Laufwerk mit "Aktualisieren" verknüpft. Das wird allerdings trotzdem nicht verbunden. Habs jetzt auch auf "Ersetzen" gestellt und wat soll ich sagen, loift :F.
Hallo,
kann es sein, dass es neben einem Problem von MS im Windows 1809 auch an der noch nicht für 1809 zur Verfügung stehenden Administrative Templates (.admx) für Windows 10 liegen kann? Haben die da vielleicht was geändert?
Weiß einer wann die rauskommen?
Achso, mein Test lief auf LTSC 2019, falls das wer schon einsetzt. Jetzt hab ich nur noch das Problem des User-Profil-Löschens. Eben mitm Testbenutzer nach 2 Tagen wieder eingeloggt und es kam jetzt wieder (schon zum 3. oder 4. Mal) die Ersteinrichtung ("Fast geschafft" my ass). Könnte durchaus sein, dass das der Fehler ist, der jetzt mit dem Oktober-Update gefixed wurde. Werd mal das Update installieren.
Das Problem mit den Netzlaufwerksverbindungen hab ich auch nach Upgrade auf 1809.
Nachvollziehbar bei allen PCs auf denen ich die 1809 installiert habe.
Bisher nur 2 (zum Test), aber absolut immer auftretend.
PCs sind in der Domäne, Laufwerke per Logonskript.
Bis 1803 keine Probleme, ab 1809 bei jedem Login eine Fehlermeldung das Netzlaufwerke nicht verbunden werden können. Laufwerke sind dann aber trotzdem da.
Microsoft nervt… Die sollen einfach mal die Finger von Dingen lassen die funktionieren, und nicht ständig Dinge einbauen nach denen niemand gefragt hat.
Änder mal den persistent-Parameter zu "/persistent:no". Das müsste ja eigtentlich das Pendent zur GPP-Option "Verbindung wiederherstellen" sein.
Danke!
Nach (komischerweise) 2 Neustarts und dem setzen von /persistent:no in dem Logon Skript kommt keine Fehlermeldung mehr. War auch replizierbar mit einem anderen Logonskript bei meiner zweiten Testmaschine.
Aber mal ehrlich: Das sieht für mich entweder nach einem unbeabsichtigten Verhalten aus, oder nach einem nicht gewünschten oder nicht dokumentierten Verhalten.
Ja, ich habe das schon vor fast ner Woche hier geschrieben. MS ändert irgendwas und kommuniziert es nicht. Aber Tom sei dank, wissen wir ja jetzt, woran die Fehlermeldung liegt :>. Nur die eigentlichen Hintergründe wissen wir trotzdem noch nicht :F.
Wow so viele Rückmeldungen.
Günter Susan kann da nicht recht haben. Wie andere schreiben werden die
1. Nicht erst nach nicht Benutzung getrennt sondern nach dem Systemstart schon
2. Ein Zugriff auf das Laufwerk z. B. Über snipping tool oder anderes führt nicht zur wieder verbindung des teilweise getrennten Laufwerks.
Insbesondere snipping tool lässt Speichern gar nicht mehr zu bis das Laufwerk per Hand im Explorer angeklickt wird.
Für mich bleibt es kein Feature. Wie ich den Kommentaren entnehme bin ich da nicht allein.
Karl, ich gebe dir Recht! Ich hatte den Tweet von Susan gesehen und in der Nacht mal schnell einen Blog-Beitrag erstellt. Die Zahl der Rückmeldungen sowie die inhaltlichen Vorschläge zeigen, dass die Entscheidung richtig war – auch wenn mein ursprüngliches Postulat möglicherweise falsch war.
Mal sehen, ob ich da einen weiteren Beitrag mit einem Exzerpt aus den Kommentaren fabriziere. Jedenfalls danke an alle Leute, die Rückmeldungen und Vorschläge gemacht haben.
Hat schon jemand bemerkt, dass die "Set user home folder" GPO seit 1809 ein ähnliches Problem hat?
Das gemappte Home-Laufwerk wird einfach nicht mehr im Explorer angezeigt, mit 1803 funktioniert es einwandfrei. Mit diversen Computern geprüft.
Kann das jemand bestätigen?
Checkt mal das bei Windows 10 1809 sind die Mappings endgültig hinne, LOL
https://support.microsoft.com/en-us/help/4471218/mapped-network-drives-don-t-work-in-windows-10-version-1809
Ich habe es jetzt gewagt in der Domäne einen Fabrikneuen Rechner mit dem "neuen" 1809 zu bestücken, der Horror!
Moin,
ein Lösungsansatz fehlt mir an dieser Stelle.
In den Energieeinstellungen den Schnellstart deaktivieren.
Aufgrund des hybriden Schnellstartens und der fixen SSD Festplatten, verpennt Windows das eine oder andere mitzuladen..
Eine These, die sich bei mir an 2 Rechnern schon bewährt hat.
Zudem ist in diesem Thread nicht ganz klar worum es geht.
Entweder ein Fehler am Client oder am Server..
Ich tippe auf den Client :-)
VG und Danke!
Hallo,
dem kann ich nicht beipflichten.
Das Problem zeigt sich bei einem OSX Server, einer Linux NAS (Buffalo) und einem Windows Server (2012). Das Problem liegt doch vermutlich eher an dem Clientsystem (Windows 7, 8, 10) und wie es angemeldet wird.
Mir werden die Lösungsansätze hier nicht klar, da sie bei einem OSX Server oder einer NAS nicht anwendbar sind. Bis auf die Lösung mit der Batch beim Start vielleicht.
Was kann ich am Client einstellen, um das Verhalten einzudämmen?
Schnellstart deaktivieren bringt nichts.
Viele Grüße und Danke in die City
Tom
Hallo,
gestestet unter Windows 10 1809 und 1903 und es funktioniert..
Verzeichnis Scripts anlegen und die ps1 einfügen und einfach mal die cmd Datei ausführen. Die Laufwerke werden dann gemappt :-)
Die cmd muss dann nur noch automatisch mit gestartet werden.
Hier der Link: https://windowsunited.de/loesung-windows-10-1809-netzlaufwerke-wieder-richtig-anzeigen/
Good Luck an alle
Hallo zusammen,
ich bin hier zufällig gelandet und habe kaum eine Ahnung vom PC.
Die Diskusssion, fand ich aber so spannend, weil ich hier an meiner Arbeitsstelle ( 9 PC´s)
dieses Problem mit den nichtverbundenen Netzwerken ständig erlebe.
Allerdings passiert dies nicht immer. Wenn es nicht geschieht, also alleLaufwerke sind verbunden, dann ist geschätzt in über 90 % der Zeit der Nummernblock
ausgeschaltet. Außerdem gibt es 2 PC´s die ab und zu aus der Reihe tanzen und alle Laufwerke verbunden sind, obwohl der Rest nicht mit allen Laufwerken verbunden ist.
Ich wollte diese Variante einfach mal los werden, eine Lösung scheint es ja bisher nicht zu geben.
Unser zuständiger PC-Fachmann konnte das Problem bisher nicht lösen und es sieht ja so aus, bei soviel Kompetzenz in diesen Blog, daß es auch noch nicht möglich ist.
Vielen Dank !
Armin Schindler
Schlaflabor
Mahlzeit!
Ich betreibe eine Domäne mit WS2019 Core und Clients die mit GPO die LW Mappings bekommen. W10 mit 1909. Bei 2-3 Usern zeigt der Windows Explorer die LW nicht an, aber der TotalCommander! Net Use zeigt die Mappings sauber an. Tritt aber manchmal auf und manchmal nicht. Bei einem User alle 3-4 Wochen.
Treffer :) Hat geholfen
Eine fritz.box (7590) als Netzwerklaufwerk unter Windows 10 zu verbinden, ist grundsätzlich nicht schwierig.
In das Eingabefeld für die Suche in der Taskleiste \\fritz.box eingeben und die Eingabetaste drücken. Dann geht es zum Explorer. Die fritz.box wird angezeigt. Mit einem Rechstklick darauf kann das Netzlaufwerk verbunden werden.
Das hat bei mir aber komische Fehlermeldungen hervorgerufen. Durch Zufall bin ich auf folgenden Trick gekommen. Bei den Einstellungen in der fritz.box
Heimnetz -> USB / Speicher -> Geräte und Heimnetzfreigabe / "Unterstützung für SMBv1 aktivieren"
anklicken. Und dann speichern. Es kann der Haken auch gleich wieder rausgenommen werden. Aus irgendeinem Grund kann die fritz.box dann ohne Probleme, wie oben beschrieben, als Netzlaufwerk verbunden werden.
Falls das Laufwerk irgendwann nicht mehr funktioniert (irgendwie verliert es nach einigen Tagen oder Wochen die Einstellung), also mit dem roten x versehen ist. Dann kann man dasselbe wiederholen. Und wenn man dann auf das rote x klickt, läuft es wieder.
Vieleicht hilft das jemandem.
SMBv1 ist nicht grundlos in der Standardeinstellung deaktiviert – zu viele Sicherheitsrisiken.
Du solltest lieber andere Möglichkeiten in Betracht ziehen und SMBv1 ganz schnell wieder deaktivieren.
Deine Box sollte SMBv3 unterstützen. Falls es wider Erwarten zu Problemen kommt, kannst Du Dich ja mal an der Liste abarbeiten.
SMBv1 sollte aber (wie auch CIFS) die letzte aller Optionen sein.