Explorer with Network Drive Disconnected

Keine Netzlaufwerke nach Windows-Update

()

Netzwerkprobleme nach Update, kein Zugriff auf Netzlaufwerke

Windows 10 Clients zeigen Netzlaufwerke in Windows-Explorer nicht mehr korrekt an, Zugriff zu NAS und Server mit SMBv1 Freigaben sind nicht mehr möglich, nachdem Funktionsupdate für Windows 10, Version 2004 installiert wurde.

Freigabe zu NAS und Server unterbrochen nach Funktionsupdate 2004

Symptom

Netzlaufwerke zu Windows Freigaben können nicht mehr hergestellt werden, dies nachdem der Funktionsupdate 2004 vom Mai 2020 heruntergeladen wurde. Mit dem Windows-Update 2004 Build 19041.508, ist der Zugriff für Standard Benutzer zu Freigaben und Netzlaufwerke nicht mehr möglich, diese das Netzwerkprotokoll SMB 1.0/CIFS-Protokoll verwenden.

Ursache

Microsoft hat mit dem Windows 10 Funktionsupdate 2004 das verhalten für das Netzwerkprotokoll SMB Version 1 geändert. Das Netzwerk-protokoll SMBv1 gilt als nicht mehr sicher, die Empfehlung von Microsoft ist es, das veraltete SMB 1.0/CIFS-Protokoll nicht mehr zu verwenden. Siehe auch – Windows 10: Zugriff auf SMBv1-Freigabe nicht mehr möglich.

Lösung

Der Registry Key ProviderFlags steuert die Wiederherstellung von Netzwerkfreigaben mit Server Message Block (SMB) Version 1, wenn diese in der Registry gespeichert werden. Der Registry DWORD Key ProviderFlags kann mittels Registry Editor unter [HKEY_CURRENT_USER\Network\<Lw>] hinzugefügt werden, oder durch ausführen der folgenden Zeile in einem Command Prompt:

REG ADD "HKCU\Network\i" /v "ProviderFlags" /t REG_DWORD /d "1" /f
Der Registry DWORD Key ProviderFlags kann mittels Registry Editor hinzugefügt werden.
Abbildung: Registry Key ProviderFlags

Das Netzlaufwerk (i) ist hier auf die Freigabe info gemappt auf SERVER01 dieser das Netzwerkprotokoll SMBv1 nutzt. Der Key ProviderFlags ist dann erforderlich, wenn Netzlaufwerke genutzt werden, die Geräte mit SMBv1 nutzen, es müssen dann alle Netzlaufwerke im Zweig HKCU\Network mit dem REG_DWORD ProviderFlags registrtriert werden. Die Änderung erfordert ein Neustart.

Lösung: net use persistent:no

Eine weitere Lösung ergibt sich unter Verwendung des Parameter /persistent:no, dort wo das Netzlaufwerk mapping aus Login-Scripts ausgeführt wird, wie durch Batchdateien auf dem Anmeldeserver \\SERVER01\netlogon, oder in einem Netzwerk ohne ADS, durch ein lokales Anmeldeskript auf dem Client. Dabei werden die Netzlaufwerke im Anmeldeskript mit net use /persistent:no erstellt.

@echo off
net time \\SERVER01 /set /y
net use * /delete /y
net use i: \\SERVER01\info /persistent:no
net use j: \\SERVER01\daten /persistent:no

In diesem Beispiel werden alle Netzlaufwerke gelöscht, bevor diese erstellt werden, dabei werden die Netzlaufwerke nicht in der Registry dauerhaft gespeichert, hierdurch es nicht erneut zum Unterbruch kommt, das es mit dem Funktionsupdate 2004 für Netzlaufwerke gibt, mit Geräte die Netzwerkfreigaben und dem Netzwerkprotokoll SMBv1 verwenden.

Herunterfahren mit Shift-Taste

Möglicherweise muss der Rechner vollständig Herunterfahren werden, um ohne Schnellstart ein Kaltstart auszulösen drückt man die Shift-Taste beim Ausschalten des Rechners, gleichzeitig bei Klick auf Herunterfahren, so erfolgt beim nächsten Neustart ein Kaltstart.

Wie hilfreich war dieser Beitrag?

Klicke auf die Sterne um zu bewerten!

Durchschnittliche Bewertung / 5. Anzahl Bewertungen:

Bisher keine Bewertungen! Sei der Erste, der diesen Beitrag bewertet.

Es tut uns leid, dass der Beitrag für dich nicht hilfreich war!

Lasse uns diesen Beitrag verbessern!

Wie können wir diesen Beitrag verbessern?

9 Gedanken zu „Keine Netzlaufwerke nach Windows-Update“

  1. Hallo Don,
    zunächst mal vielen Dank für Deinen Beitrag. Er war sehr hilfreich. Leider habe ich aber festgestellt, dass es beim ersten Start eines Rechners im Netzwerk trotzdem immer wieder mal zu getrennten Verbindungen kommt. Ich habe hier ein bisschen weiter herumprobiert, und dabei festgestellt, dass das Problem nicht auftritt, wenn man den Windows10-PC mit Herunterfahren + „SHIFT“ herunterfährt. Danach trat benanntes Phänomen nicht mehr auf. Um den Usern das tägliche Drücken der Shift-Taste zu ersparen, habe ich dann unter den Energieoptionen den Schnellstart deaktiviert. Habe es jetzt an ca. 7 Clients mit Windows 10 20H2 so konfiguriert, und es scheint zu klappen. Dies könnte also in Kombination mit „ProviderFlags“ ein zusätzlicher Lösungsansatz sein. Sollte es doch nur ein Zufallsbefund sein, werde ich berichten.

    1. Hallo Michael,
      Da die Schnell-Startmethode technisch auf dem Hibernation-Mode basiert, wäre das schon möglich, ich selber habe es bei vielen Clients gemacht und nicht feststellen können, es kann auch Hardware abhängig sein, mit dem jeweils vorinstallierten OEM-Windows!

  2. Hallo Don,
    bei mir scheint es ein Nachfolgeproblem zu geben, hatte ich jetzt schon bei drei der insgesamt zehn Clients, welche von dem ursprünglichen Problem betroffen waren: Nach einem Neustart des Computers verbindet sich dieser nicht mit den Netzlaufwerken. Also sie werden im Explorer gar nicht mehr angezeigt, auch nicht als «nicht verbunden». Wenn man aber dann ein Netzlaufwerk neu hinzufügen möchte und den Buchstaben dafür wählt, dann steht im Dropdown mit allen Buchstaben bereits bei jedem Buchstaben, mit welchem Netzlaufwerk er eigentlich gemappt war. Man kann ihn dann aber neu auswählen und verbinden.
    Eine einfache Lösung war jetzt natürlich einfach ein kleines Skript zu hinterlegen, welches die Netzlaufwerke verbindet. Aber mich würde interessieren, ob Du oder andere Leser dieser Seite auch schon ähnliche Erfahrungen gemacht haben?

    1. Hallo Hendrik
      Es könnte bei dem mapping mit net use /persistent:no liegen, das die zuvor gemappten Laufwerke im verlauf erscheinen ist weil diese noch in den MRU-Listen stehen, wenn Du /persistent:no anwendest, muss ein Loginscript dafür sorgen das diese bei der nächsten Anmeldung wieder gemappt werden.

      1. Hallo Don,
        daran liegt es eher nicht, ich habe die Netzlaufwerke nicht mit einem Skript sondern fix (also manuell) hinterlegt.
        Nachdem die «Registry Key ProviderFlags» Lösung nun ein paar Wochen gut geklappt hat, fängt das Problem bei uns wieder an aufzutreten! Der Key ist weiterhin korrekt gesetzt, aber es tritt wieder das Problem auf, dass keine Verbindung zu den Netzlaufwerken hergestellt werden kann. Das Verhalten vom Explorer ist dabei genau gleich wie vor dem Setzen des Registry Keys.
        Du hast nicht zufällig einen Tipp?

        1. Hallo Hendrik,
          Habe noch kein PC vorgefunden bei diesem es nicht mehr geht, ist SMBv1 auch tatsächlich aktiviert ? abfrage in der Powershell als admin Get-WindowsOptionalFeature –Online –FeatureName SMB1Protocol

  3. Hallo Don, super, genau nach dieser Lösung habe ich seit Tagen gesucht, laut Datum seit gestern online. Ich habe schon diverse Versuche („Windows Features aktivieren oder deaktivieren“ via Systemeinstellungen und via PowerShell-Befehl) unternommen, mein SMB1-NAS unter Win10 FU 2004 wieder erreichbar zu machen. Nach Abschalten des SMB1-NAS und Herunter-/Hochfahren von Windows war mein SMB1-NAS immer wieder nicht erreichbar. Ein Blick in „Windows Features aktivieren oder deaktivieren“ zeigte, dass die SMB1-Unterstützung von Windows jedes Mal automatisch entfernt wurde. Schuld daran ist vermutlich die Option „SMB1.0/CIFS automatisch entfernen“, die sich trotz zuvor anderslautender Einstellung anscheinend von selbst aktiviert, sobald kein SMB1-Gerät im Netzwerk erkannt wird. Zum Verständnis: Sorgt der beschriebene Registry-Eintrag dafür, dass sich die Option „SMB1.0/CIFS automatisch entfernen“ nicht von selbst aktiviert, sobald das entsprechende SMB1-Gerät nicht eingeschaltet und mit dem Netzwerk verbunden ist?

    1. Hallo Manfred, Ja dieser Beitrag ist Brandneu, es hat aber nach meiner Erkenntnis nicht mit „SMB1.0/CIFS automatisch entfernen“ zu tun, vermutlich aber sind die Symptome nicht in jeder Umgebung und Konfiguration dieselben! So zB. in einer AD Domäne mit Geräte unterschiedlicher SMB Versionen, oder ohne Domäne, kann es ein anderes verhalten geben! Vermutlich hat sich mit FU2004 die Anforderungsanfrage vom Client an den Server geändert, dabei gibt der SMBv1 Server STATUS NOT FOUND zurück, der Key „ProviderFalgs“ scheint dabei ein Konflikt zu umgehen, indem der SMBv1 Share erneut aufgebaut wird, und nicht aus dem Cache abgerufen wird, wo der Eintrag blockiert ist. Man kann es auch mit „net use /persistent:no“ machen, damit das Lw bei jedem Login erneut gemappt wird.

      1. Hallo Don, besten Dank für Deine Antwort. Genau das macht die Fehlersuche so schwierig: Jede Netzwerkumgebung sieht anders aus, und deshalb sind auch die Symptome so unterschiedlich. Ich hoffe aber, dass sich Win10 FU 2004 bezüglich SMB1 nach diesen Maßnahmen nun stabil verhält und mein SMB1-NAS wieder dauerhaft erreichbar ist.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert