Vorspiel

Ich habe in letzter Zeit auf Arbeit mit einigen Rechnern gekämpft, die die AD-Gruppenrichtlinien nicht mehr ausführen wollten, genau genommen gar keine AD-Verbindung mehr hatten. Die Anzahl der Geräte, die sich bei meinem Deployment-Manager gemeldet haben, sank immer weiter.
Mit den PCs schien ansonsten alles in Ordnung: Domänenmitgliedschaft, Internet, Intranet, Serververbindung mit Netzlaufwerken, alles da.
Wie kommt’s?

Analyse

In der Ereignisanzeige werden folgende Meldungen ausgegeben:
Event ID 5719, NETLOGON:
Der Computer konnte eine sichere Sitzung mit einem Domänencontroller in der Domäne BARKETING aufgrund der folgenden Ursache nicht einrichten:
Es sind momentan keine Anmeldeserver zum Verarbeiten der Anmeldeanforderung verfügbar.
Dies kann zu Authentifizierungsproblemen führen. Stellen Sie sicher, dass der Computer mit dem Netzwerk verbunden ist. Wenden Sie sich an den Domänenadministrator, wenn das Problem weiterhin besteht.
ZUSÄTZLICHE INFORMATIONEN
Wenn dieser Computer ein Domänencontroller der bestimmten Domäne ist, wird eine sichere Sitzung zum primären Domänencontrolleremulator in der bestimmten Domäne eingerichtet. Andernfalls richtet dieser Computer eine sichere Sitzung zu einem beliebigen Domänencontroller in der bestimmten Domäne ein.

Event ID 5719, GroupPolicy:
Fehler bei der Verarbeitung der Gruppenrichtlinie. Der Computername konnte nicht aufgelöst werden. Dies kann mindestens eine der folgenden Ursachen haben:
a) Fehler bei der Namensauflösung mit dem aktuellen Domänencontroller.
b) Active Directory-Replikationswartezeit (ein auf einem anderen Domänencontroller erstelltes Konto hat nicht auf dem aktuellen Domänencontroller repliziert).

Recht schnell konnte ich das Verhalten auf die PCs eingrenzen, die in den letzten Wochen auf WLAN umgestellt wurden.
Der Grund: WLAN braucht wesentlich mehr Zeit zum Initialisieren als LAN. Dadurch ist die Wahrscheinlichkeit hoch, dass die Verarbeitung der Gruppenrichtlinien/AD zu schnell ist – das WLAN ist noch nicht bereit und AD-Server werden nicht gefunden.

Microsoft umschreibt das Problem so:

The behavior is caused by a race condition between network initialization, locating a Domain Controller and processing Group Policy. If the network is not available, a Domain Controller will not be located, and Group Policy processing will fail.

via

Und weiterführend auch hier:

The problem occurs because link status fluctuates as the network adapter (also known as the network interface card, or NIC) driver initializes and as the network adapter hardware negotiates a link with the network infrastructure. The Group Policy application stack executes before the negotiation process is completed and can fail because of the absence of a valid link.

via

Lösungen

Es gibt viele Tipps wenn es um WLAN in einem AD-Netzwerk geht. Hier zuerst die Lösung, die bei mir letztlich das Problem beheben konnte:

„Media Sensing“ Feature deaktivieren

Microsoft benutzt ein Feature namens „Media Sensing“, um die Verfügbarkeit von Netzwerkschnittstellen zu testen. Das Feature scheint mit WLAN aber nicht immer gut klarzukommen. In diesem Artikel wird beschrieben, wie es deaktiviert werden kann:
Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
Neuer DWORD Key namens DisableDHCPMediaSense mit dem Value 1.
Download der entsprechenden .reg Datei hier. Doppelklick oder skriptbasiert ausführen mit

reg import

.
Neustart, fertig! Mein Test-PC hat sich direkt nach diesem Neustart bei der Domäne gemeldet und alles lief wie gewünscht.

via-Kette: via –> via –> via –> via

Falls das Problem damit noch nicht behoben ist, hier noch eine Lösung – Deaktiviertes Media Sense und die folgende Konfiguration lösen das Problem wohl zu 95%, wenn es das beschriebene Problem ist:

Abhängigkeit von gpsvc anpassen

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.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\gpsvc
DependOnService bekommt in einer neuen Zeile iphlpsvc oder lmhosts hinzugefügt.
Damit das geht, muss vorher das Besitzrecht des Keys übernommen werden:

via
Wenn die Lösung 1 (Media Sense) allein nicht ausreicht, dann hilft die Kombi bestimmt. Ich würde empfehlen, beide Einstellungen zu setzen, dann gibt es vermutlich keine Probleme mehr.

Nun noch weitere Einstellungen, die bei der Verwendung von WLAN-Clients überprüft werden sollten:

Gruppenrichtlinieneinstellungen

• „Administrative Templates/System/Anmelden/Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten“ via
• „Administrative Templates/System/Gruppenrichtlinie/Wartezeit für Richtlinienverarbeitung beim Systemstart“ via
• „Administrative Templates/System/Gruppenrichtlinie/Erwartet Einwählverzögerung bei der Anmeldung“ via
• „Administrative Templates/System/Gruppenrichtlinie/Anmeldeskripts gleichzeitig ausführen“ via

WLAN: Perform immediate sign in before user logon

Diese Seite beschreibt eine WLAN-Einstellung, die die Verbindung zum WLAN optimieren soll. Funktioniert glaube ich nur bei WPA2-Enterprise WLANs oder anderen speziellen WLAN-Systemen – ich konnte die Einstellung bei unserem Netz nicht finden.

WLAN Connect im Autorun

Ein weiterer Workaround für den Notfall wäre auch dieser: Artikel. Sollte aber nicht produktiv dauerhaft verwendet werden, hat bei mir selber auch nicht funktioniert.

Verteilung

Am liebsten hätte ich hier eine Lösung gebracht, wie man die Einstellung auf alle PCs verteilt – leider habe ich selber keine Verteilung hinbekommen.
Why? An sich muss „nur“ ein Registry Wert gesetzt werden, allerdings im HKLM Bereich, wofür Adminrechte nötig sind. Diese bekommt man nur über Startscripts des Computers, die mit SYSTEM ausgeführt werden. Die Startscripts werden aber aufgrund dieses Problems nicht ausgeführt. User/Logon-Scripts dagegen schon; die können jedoch nicht in HKLM schreiben. Nun könnte man versuchen mit dem Tool CPAU ein elevated Logon-Script für diesen Zweck zu basteln, aber auch das klappt nicht. Denn Registry-Manipulation braucht nicht nur einen Nutzer mit Adminrechten (das kann CPAU) sondern muss in einer elevated CMD ausgeführt werden (das kann es nicht)! Somit gibt es auch „Fehler beim Zugriff auf die Registrierung“-Fehler wenn

reg import

via CPAU mit einem Adminaccount getriggert wird.
Fazit: ich musste heute tatsächlich händisch an jeden PC, der über WLAN läuft, und die Einstellungen über den Benutzerwechsel zu einem Admin händisch setzen. Ätzend. Wer da bessere Ideen hat, immer her damit.