SSD zu schnell: Synchroner Startvorgang nicht möglich

Dieser Artikel erschien zuerst auf gruppenrichtlinien.de

Vielleicht liegt es an meinem deutschen Kontrollzwang, aber ich gehöre wie viele meiner Kollegen zu den Administratoren, die gerne eine Kontrolle über den Start- und/oder Anmeldevorgang ihrer Computer und Benutzer haben.

Windows XP hat uns gelehrt diese beiden Richtlinien zu aktiveren:
„Bei Neustart des Computers und der Anmeldung immer auf das Netzwerk warten“ = Aktiviert
und
„AnmeldeSkritps gleichzeitig auszuführen“= Aktiviert

Siehe auch: Fast Logon – Schnelles Anmelden – Asynchrones Startverhalten – ehemals FAQ 36

Jetzt kommen wir in das Dilemma, das SSD-Platten unter Umständen so schnell sind, dass das Netzwerk keine Chance hat, in dem kurzen Zeitraum zu starten. Der Rechner ist 2-3 Sekunden zu schnell. Zum Zeitpunkt der Benutzeranmeldung ist das Netzwerk dann vorhanden, das sind die zwei Sekunden Verzögerung, die sich durch die Eingabe des Kennworts ergeben. Zum Zeitpunkt des Computerstarts fehlt das Netzwerk, und dadurch haben wir keine Vordergrund-Richtlinienverarbeitung der Computerrichtlinien und Computer-Startup-Skripte laufen nicht.

Die offizielle Lösung von Microsoft ist:
Computer Configuration\Administrative Templates\System\Gruppenrichtlinie\
„Wartezeit für Richtlinienverarbeitung beim Systemstart angeben“
der empfohlene Richtwert beträgt 60 Sekunden.

WICHTIG! Das ist bei einem verbundenem LAN-Client kein Timeout, sondern ein maximaler Zeitraum, während dessen der Gruppenrichtlinienclient-Dienst (gpsvc) versucht, Kontakt zu seiner Infrastruktur aufzunehmen. Sobald diese erreichbar ist, werden die Richtlinien verarbeitet, und die Anmeldemaske für den Benutzer erscheint. Solange das Netzwerk nicht zur Verfügung steht, wartet der Rechner und macht direkt weiter, sobald das Netzwerk verfügbar ist. Wir verlieren nur minimal Zeit: eben die 2-3 Sekunden, die der Start der Netzwerkdienste benötigt, und zusätzlich die Zeit, die es braucht, die Richtlinien zu verarbeiten. Wir bekommen aber wieder eine kontrollierbare Startumgebung.

Es gibt jetzt nur ein blödes Phänomen: Notebooks.

Ohne jeglichen Netzwerkkontakt sind die 60 Sekunden leider kein Intervall, sondern doch ein Timeout. Die Richtlinie orientiert sich nicht am MediaSense 🙁 Normalerweise sind netzwerkabhängige Dienste so gestrickt, dass sie die generelle Verfügbarkeit eines Netzwerk prüfen und sich entsprechend verhalten. Leider sie ist dieser Zusammenhang dem GPSVC-Dienst nicht gegeben. Der wartet jetzt 60 Sekunden, es könnte ja jemand noch ein Kabel einstecken …

Alternative Lösung

Vorab, das ist nicht von Microsoft supported und das ist keine offizielle Lösung, sondern eine, mit der ich im Test und beim Kunden keinen Fehler finden konnte, aber genau das erreicht habe, was ich wollte. Wir definieren eine neue Abhängigkeit des GPSVC-Dienstes zu einem Netzwerkdienst, der per Default immer gestartet wird: IP-Hilfsdienst (iphlpsvc), alternativ wäre der „TCP/IP-NetBIOS-Hilfsdienst“ (lmhosts) auch eine Möglichkeit.

Was wird passieren?

• der Gruppenrichtlinienclient startet, wenn der IP-Hilfsdienst gestartet ist. Sobald dieser gestartet ist, ist das Netzwerk vorhanden.  Wir haben damit kein Zeitintervall, sondern die genaue Zuordnung, „wann“ der Gruppenrichtlinienclient loslegen soll.
• Offline-Clients ohne jeglichen Netzwerkkontakt werden den IP-Hilfsdienst niemals starten, da dieser auf Mediasense reagiert und ohne Netzwerk gar nicht erst aktiv wird. Wenn dieser Dienst nicht gestartet wird, wird der GPSVC nicht gestartet, und somit entfällt der 60-Sekunden-Timeout . Wir haben keine Wartezeit, sondern einen direkten Start. Das war das Ziel.

Nachteil dieser Lösung

Es ist keine offizielle Lösung, und sie manipuliert eine Dienstabhängigkeit, die sonst nicht gegeben wäre. Kann es schaden? Ich denke nein, denn ohne Netzwerk gibt es keine Gruppenrichtlinien. Aber die Lösung ist weit weg vom Standard und außer mir und euch macht das keiner 🙂 … aber genauso schnell wie der Eintrag in die Registry kommt ist er auch wieder entfernt.