Simon Stamm

Häufig hat man das Problem, dass entweder das Laden des Netzwerktreibers länger dauert oder der eigene NAS erst starten muss, sodass Windows beim Start keine Verbindung zum Netzlaufwerk aufbauen kann. Somit erscheint jedes Mal die nervige Meldung:

Es konnten nicht alle Netzlaufwerke wiederhergestellt werden

Trotzdem möchte man auf den Haken „beim Start automatisch verbinden“ beim Einrichten des Netzlaufwerkes nicht verzichten, damit es beim nächsten Start nicht vom Arbeitsplatz verschwindet.

Die Lösung (Windows 7, 8.1, 10) ist, Netzlaufwerke erst dann zu aktivieren, wenn sie vom Anwender oder der Anwendung benötigt werden. Dazu muss in der Registry unter:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider

ein neues DWORD mit dem Namen „RestoreConnection“ und dem Wert 0 erzeugt werden. In Einzelfällen hat hier auch der Wert 1 zum Ziel geführt.

Sodass es am Ende dann so aussieht:

Windows-Anmeldeinformationen dauerhaft speichern

Wenn die Zugangsdaten nur über die Eingabeaufforderung des Explorers eingegeben werden, ist das Problem, dass der Wert „Dauerhaftigkeit“ nur auf „laufende Sitzung“ eingestellt ist.

Die Lösung: Manuelle Eingabe der Verbindungsdaten über Systemsteuerung / Benutzerkonten / Anmeldeinformationsverwaltung

Was bewirkt der Eintrag genau?
Welche Folgen gibt es?

Der Wert 0 beim RestoreConnection sorgt dafür, dass die Netzwerkverbindungen erst beim Zugriff wiederhergestellt werden. In einigen Fällen führt dies dazu, dass Anwendungen aber nicht auf eine Datei zugreifen können, die auf dem Netzlaufwerk liegt, wenn vorher die Verbindung nicht über den Explorer (z.B. per Doppelklick auf das Laufwerk) hergestellt wurde. Konkret heißt das: Liegen bspw. Maildateien (*.pst) von Outlook, Thunderbird o.ä. auf dem Netzlaufwerk, kann der Mailclient nicht direkt auf die Dateien zugreifen, wurde die Verbindung nicht hergestellt.

Warum die offizielle Lösung via GPOs nicht immer zum Erfolg führt

Im ersten Moment könnte man auf die Idee kommen, die GPOs „Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten“ und „Anmeldeskripts gleichzeitig ausführen“ zu aktivieren. Das wird aber nicht immer zum Erfolg führen. Insbesondere, wenn SSDs im Einsatz sind, fehlt zum Zeitpunkt des Computerstarts das Netzwerk – und dadurch kommt keine Vordergrund-Richtlinienverarbeitung zustande.

Die offizielle Lösung von Microsoft ist, Computer Configuration\Administrative Templates\System\Gruppenrichtlinie\
„Wartezeit für Richtlinienverarbeitung beim Systemstart angeben“ auf 60 Sekunden zu setzen.

Nachteil: Ist mal keine Netzwerkverbindung vorhanden (z.B. bei Laptops), versucht der Gruppenrichtlinienclient-Dienst (gpsvc) 60 Sekunden lang Kontakt zur Infrastruktur aufzunehmen. Somit verzögert sich der Start um diese 60 Sekunden.

Eine alternative Lösung mittels GPOs

Auf einer Website zum Thema SSD zu schnell: Synchroner Startvorgang nicht möglich wird ein interessanter Vorschlag vorgestellt. Und zwar wird eine neue Abhängigkeit des GPSVC-Dienstes zu einem Netzwerkdienst definiert, die standardmäßig immer gestartet wird: IP-Hilfsdienst (iphlpsvc), alternativ wäre der „TCP/IP-NetBIOS-Hilfsdienst“ (lmhosts) ebenso möglich.

Hierfür wird ein neues Registrierungselement bspw. „DependOnService“ erstellt:

Das wird passieren:

• Der Gruppenrichtlinenclient startet erst, wenn der IP-Hilfsdienst gestartet ist. Letzterer ist gestartet, sobald das Netzwerk vorhanden ist.
• Clients ohne Netzwerkkonnektivität starten den IP-Hilfsdienst nicht, was dazu führt, dass GPSVC nicht gestartet wird und der 60-Sekunden-Timeout entfällt.