In Ihrem Unternehmen stellen mobile Anwender via VPN die Verbindung mit der Domäne her. Nun berichten einige Anwender, dass Einstellungen, welche Sie als Administrator normalerweise mittels Gruppenrichtlinen setzen, nicht vorhanden sind und somit u.a. exotische Fehler auftreten.

Das Eventlog auf betroffenen Clients vermerkt einen Fehler mit der EventID 1054:

"Der Domänencontrollername für das Computernetzwerk konnte nicht ermittelt werden. (Die angegebene Domäne ist nicht vorhanden oder es konnte keine Verbindung hergestellt werden.) Die Verarbeitung der Gruppenrichtlinie wird abgebrochen."

Als ersten Schritt zum Analysieren von Gruppenrichtlinienproblemen aktivieren Sie das unserenv debug logging für den Client.
Hier dürften Sie u.a. Einträge der Art "ProcessGPOs: DSGetDCName failed with 59." finden.

Hintergründe:
Beim Anwenden bzw. Updaten der Gruppenrichtlinien prüft der Client die Verbindungsgüte zu seinem Domain Controller. Diese sogenannte "Slow-Link-Detection" sorgt dafür, dass bei einer schlechten Verbindung die Abarbeitung der GPOs (wobei in rel. geringer Zeit einiges an Daten übertragen werden muss) übersprungen wird.
Als default Wert für eine "schnelle" Verbindung gelten 500 Kb pro Sekunde (Kbps). Dieser Wert kann via GPO (Computer\Administrative Vorlagen\System\Gruppenrichtlinien\Gruppenrichtlinien zur Erkennung von langsamen Verbindungen) angepasst werden.

Die Art und Weise, wie diese Bandbreite errechnet wird, stellt sich wie folgt dar:
Der Client pingt seinen DC mit ICMP-Paketen mit einer Standardgröße von 2048 Byte (2KB) an. Anhand folgender Formel wird nun die anliegende Geschwindigkeit errechnet:

How Group Policy measures link speed?

1. Ping the server with 0 bytes of data and time the number of milliseconds. This value is time#1. If it is less than 10 ms, exit (assume a fast link).
2. Ping the server with 2 kilobytes (KB) of uncompressible data, and time the number of milliseconds. This value is time#2. The algorithm uses a compressed .jpg file to ping the server.
3. DELTA = time#2 - time#1. This removes the overhead of session setup, with the result being equal to the time to move 2 KB of data.
4. Calculate Delta three times, adding to TOTAL each DELTA value. Use the following calculations:
5. TOTAL/3 = Average of DELTA in milliseconds.
6. 2 * (2 KB) * (1000 ms/sec) / DELTA Average ms = X
7. X = (4000 KB/sec) / DELTA Average
8. Z Kbps = ((4000 KB) / DELTA Average) *(8 bits/byte)
9. Z Kbps = 32000 kbps/Delta Average.
Two KB of data have moved in each direction (this is represented by the leading factor two on the left side in step six) through each modem, Ethernet card, or other device in the loop once. The resulting Z value is evaluated against the policy setting. A default of less than 500 Kbps is considered a slow link; faster than 500 Kbps is a fast link.

If Z is less than 500 Kbps the connection is considered slow, otherwise it is considered fast.

Auswirkungen:
Es können nun folgende Probleme auftreten:

• a) Die Verbindungsgüte ist hervorragend, das Netzwerk zum Zeitpunkt des GPO-Processings aber noch nicht bereit.
• b) Die Verbindungsgeschwindigkeit ist dauerhaft schlecht; die Clients haben zusätzlich nicht doch Möglichkeit, regelmäßig am corporate lan ihre Richtlinien zu aktualisieren.
• c) Trotz guter Verbindungsgüte meldet das userenv, dass der DC nicht erreicht werden kann; ein direktes Ansprechen (pingen mit der Standard-Framesize von 32 Byte) der Domain ist jedoch problemlos möglich.

Lösung für Fall a):

Hier kann per Skript bzw. ein angepasstes ADM-Template ein Registry-Wert bearbeitet werden, welcher das GPO-Processing nach einer definierten Zeit erneut ausführt. Folgender Key ist hierbei anzulegen / zu bearbeiten:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\WinLogon\GpNetworkStartTimeoutPolicyValue; als default Wert kann mit 60 (Sekunden) begonnen werden; die minimalen und maximalen Werte sollten sich zwischen 30 und 600 bewegen. Hier gilt es durch Probieren, den für das Netzwerk passenden Wert herauszufinden.

Folgendes ADM-Template kann hierfür verwendet werden (Auszug):

;-------------------------------------------------------------
    CATEGORY !!new

        KEYNAME "Software\Microsoft\Windows NT\CurrentVersion\Winlogon"
;~~~~~~~~~~~~~~~~~~~ Beim Startup: Abarbeitung der GPO's nach eingestellter Zeit [sec.] erneut ausführen~~~~~~~~~~~~~~~~~~~

            POLICY !!Timeoutinfo
                EXPLAIN !!Timeout_Help
            PART !!TimeOutValue    NUMERIC REQUIRED SPIN 1
                DEFAULT 60
                MAX 600
                MIN 30
                VALUENAME "GpNetworkStartTimeoutPolicyValue"
            END PART
            END POLICY

    END CATEGORY

Lösung für Fall b):

Zunächst sollte man versuchen, den Schwellwert für die Slow-Link-Detection soweit herabzusetzen, bis alle Clients erfolgreich die Gruppenrichtlinien abwenden können. Dies geschieht über die bereits o.g.Gruppenrichtlinie bzw. über folgend Registry-Wert: HKLM\Software\Policies\Microsoft\Windows\System\GroupPolicyMinTransferRate.
Aktiviert man diese GPO und setzt den Wert per GPO oder Registry auf "0", so wird das GPO-Processing unabhängig von der Übertragungsgeschwindigkeit auf jeden Fall durchgeführt.

Lösung für Fall c):

Hier wird es ein wenig komplizierter.
Die Feststellung der Verbindungsgüte erfolg wie bereits erwähnt über ICMP-Pakete mit großer Framesize (2048 Byte; ein Standard "ping"-Befehl sendet Pakete mit einer Größe von 32 Byte). Nun vermuten einige Hersteller von VPN-Gateways hinter großen bzw. fragmentierten ICMP-Paketen einen bösartigen Angriff. Als Konsequenz werden TCP-Pakete ab einer gewissen Größe einfach verworfen; der Client bekommt somit scheinbar keine Antwort von seinem Domain Controller und kommentiert dies mit der Meldung "ProcessGPOs: DSGetDCName failed with 59."

Es gibt nun zwei Möglichkeiten:
Entweder konfiguriert man die Gateways, Router und Switches, damit große bzw. fragmentierte ICMP-Request weitergeleitet werden.
Auf der anderen Seite gibt es die Möglichkeit, die Standardgröße der ICMP-Pakete für die Slow-Link-Detection anzupassen. Hierfür gilt es, folgenden Registrywert zu konfigurieren:
HKLM\Software\Policies\Microsoft\Windows\System\PingBufferSize
Zur Ermittlung eines passendes Wertes für die PingBufferSize empfielt es sich, auf einem betroffenden Client die Domäne mit ICMP-Paketen bestimmter Framesize zu pingen. Dies erfolgt mittels eines ping -l 2048 <domain> (in diesem Falle wird die Domäne mit einem 2048 Byte großen Paket angesprochen). Veringern Sie den Wert so lange, bis Sie wiederholt Antwort von Ihrem Domain Controller erhalten!