Gerade in größeren Netzwerken kann es zu einem nicht ganz trivialen Problem mit Windows 7 (oder Windows Server 2008)-Clients, die ihre IP-Adresse per DHCP beziehen und Routern kommen. Es könnte auch in anderen größeren Netzwerken zutreffen, die sich gerade in der Windows 7-Einführung befinden bzw. die Einführung vor kurzem abgeschlossen haben und sich manche Fehler nicht erklären können.
Fehlerbild
Viele oder alle Clients haben im Rahmen das Ereignisprotokolls Einträge, dass während des Starts keine Verbindung zur Domäne hergestellt werden konnte (Event-ID 5719 – kein Domänencontroller verfügbar) oder dass keine Gruppenrichtlinien verarbeitet werden konnten (Event-ID 1105). Die Verarbeitung von Gruppenrichtlinien funktioniert jedoch später tadellos (gpupdate, regelmäßige Aktualisierung) und das Ereignis erscheint auch nur beim Bootvorgang. Leider kann es da schon für einige GPOs, die nur beim Rechnerstart angewandt werden (z. B. Computer-Startup-Skript) zu spät sein.
Weiterhin auffällig ist, dass das Beziehen einer DHCP-Adresse beim Booten etwa 5-10 sek. benötigt.
Das Problem tritt aber nur in folgender Konstellation auf:
- es werden mehrere IP-Subnetze betrieben
- Die IP-Vergabe für diese erfolgt durch einen zentralen DHCP-Server
- Für die einzelnen Subnetze werden Nicht-Microsoft-DHCP-Relay-Agenten (z.B. Router) verwendet – auch bekannt als „IP-Helper“
Ursache
Das Beziehen einer IP-Adresse per DHCP basiert normalerweise auf Basis von Broadcast-Paketen. Der Client fragt per Broadcast ins Netzwerk – der Server antwortet per Broadcast mit einem „Offer“ und alles funktioniert.
Kommt nun ein DHCP-Relay-Agent zum Einsatz ist es etwas anders:
- Agent (Router) nimmt Broadcast-Paket an
- sendet es als Unicast-Paket an konfigurierten DHCP-Server
- bekommt Antwort (IP-Adresse) vom DHCP-Server (DHCP-Offer)
- schickt Offer an den Client
Nun ist die Frage, wie das Paket im Schritt 4 versandt wird – als Broadcast- oder Unicast-Paket. Beides ist möglich und Windows 7 kann (eigentlich) auch beides und versucht auch dynamisch die richtige Methode zu ermitteln (die Erläuterung dazu wäre ein weiteren Blogbeitrag wert).
Leider können oder wollen einige Router nur Unicast-Pakete beim DHCP-Offer zurückschicken!
Windows 7 versteht dies wie gesagt problemlos und nimmt auch die Pakete an – wenn da nicht die Firewall wäre. Während des Boot-Vorgangs ist für eine kurze Zeit eine sogenannte boot-time-policy der Firewall aktiv. Und die lässt keine DHCP-Offer-Pakete per Unicast durch!
Damit hat der Client erstmal keine IP-Adresse. Er versucht es nach 3-5 sek. wieder. Dann ist der Rechner vollständig gestartet, das richtige Firewall-Profil geladen, die DHCP-Offer-Pakete gehen auch als Unicast durch, der Client hat eine IP-Adresse und alles ist gut.
Dummerweise starten während dieser paar Sekunden auch andere Dienste wie netlogon etc. Diese finden dann auf Grund der fehlenden IP-Adresse keine Domänencontroller, melden dies und als Folge werden zu diesem Zeitpunkt auch keine GPOs angewandt.
Nach den 5 sek. verhält sich der Rechner ganz normal, hat eine IP-Adresse, man kann ein gpupdate durchführen oder ähnliches. Aber leider kann es für einige Einstellungen zu spät sein.
Lösung
Abhilfe bringt ein Hotfix von Microsoft: http://support.microsoft.com/kb/2459530 In diesem Artikel ist auch Workaround zur Konfiguration der NW-Karten per Registry erläutert. Leider bezieht sich der auf die Registry-Einstellungen der NW-Karte – und da wird auf jeden Rechner eine andere GUID verwandet. Also nichts für eine eigene Gruppenrichtlinie…
Zusatz
Auch eine Konfiguration der GPO-Einstellung „Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten“ bringt hier keine Lösung. Diese Einstellung bedeutet nur, dass auf das Laden der NW-Kartentreiber für alle weiteren Schritte gewartet wird. Und die haben wir ja hier schon lange geladen…