SSD zu schnell - Synchroner Startvorgang nicht möglich
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, daß das Netzwerk keine Chance hat in dem kurzen Zeitraum zu starten. Der Rechner ist 2-3 Sekunden zu schnell. Zum Zeitpunkt der Benutzernanmeldung ist das Netzwerk dann vorhanden, das sind die 2 Sekunden Verzögerung die sich durch die Eingabe des Kennworts ergeben. Zum Zeitpunkt des Computerstart fehlt das Netzwerk und dadurch haben wir keine Vordergrundrichtlinien Verarbeitung 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, 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, daß 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 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?
a) der Gruppenrichtlinienclient startet, wenn der IP-Hilfsdienst gestartet ist. Sobald dieser gestartet ist, ist das Netzwerk vorhanden. Wir haben damit keinen Zeitintervall, sondern die genaue Zuordnung "wann" der Gruppenrichtlinienclient loslegen soll.
b) 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 habeen 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 ausser mir und euch macht das keiner :-) ... aber genauso schnell wie der Eintrag in die Registry kommt ist er auch wieder entfernt.