Group Policy Verarbeitung und SMB Latenz

Hallo,
hier ist mal wieder Florian – diesmal nicht von der Grenze zur Schweiz, sondern jenseits davon. Heute mit einem Gast-Beitrag für die DEDS-Kollegen zu Gruppenrichtlinien und Schwierigkeiten, die sich bei Verbindungen mit größeren Latenz auftun können.

Meine Kollegen und ich von den Enterprise Consulting Services in der Schweiz bekommen hin und wieder Anfragen, wie problembehaftet Latenz auf WAN-Strecken bezüglich Active Directory wirklich ist. In diesem Blogartikel wollen wir uns dem Latenzproblem im Zusammenhang mit GPOs widmen.

Bei der Planung von Standorten für Domänencontroller und der Entscheidungsfindung, ob ein Domänencontroller in einem Standort platziert werden soll oder nicht, spielen mehrere Faktoren eine Rolle. Unter anderem wird immer auf die verfügbare Bandbreite zwischen Standorten verwiesen, die Ausfallsicherheit der Verbindung, die Anzahl der Clients und schließlich die Dienste, die über die WAN-Verbindung ebenfalls, neben den AD-Authentifizierungen, konsumiert werden müssen.

Aus einer Verzeichnisdienstperspektive gibt es, neben der Mindestbandbreite, die für Authentifizierungen zur Verfügung stehen muss, keine Beschränkungen zur maximalen Latenz. Gewiss ist, dass das Verzeichnis und viele seiner Komponenten, an RPC und andere TCP-Dienste gebunden sind. Wird die Latenz zu groß als dass TCP und seine Kontrollmechanismen den korrekten Datenverkehr gewährleisten können, werden folglich auch die Komponenten von Active Directory ihre Mühen haben, ihren Dienst zu vollbringen.

Wo Kunden erfahrungsgemäß früher Grenzen der maximal möglichen Latenz aufgezeigt bekommen, ist der Einsatz von Gruppenrichtlinien. Die Verarbeitung der Richtlinien über WAN-Strecken mit hoher Latenz kann die Verarbeitung der Richtlinien und damit die Anmeldezeit stark beeinflussen. Dies geschieht, weil Gruppenrichtlinien in zwei Objekte aufgeteilt sind, die beide unabhängig voneinander repliziert und vom Client später ausgewertet werden. Ein Teil liegt in Active Directory, der sogenannte Group Policy Container (GPC), der zweite Teil im SYSVOL-Verzeichnis, das Group Policy Template (GPT). Der GPC wird via LDAP-Anfragen abgerufen, der GPT-Teil ähnlich wie Aufrufe von Dateifreigaben über das SMB-Protokoll.

Hier liegt das Problem: das SMB-Protokoll benötigt für den Aufruf einer Datei und der Prüfung, ob eine Richtlinie verarbeitet werden muss oder nicht, mehrere Anfragen an den Server. Bei hoher Latenz und bei großem Gesprächsbedarf steigt auch die Verarbeitungszeit. Der folgende Netzwerktrace zeigt den Verbindungsverlauf eines Windows XP-Clients zu einem Domänencontroller auf, wenn alle Gruppenrichtlinien neu heruntergeladen werden müssen (das Verhalten zeigt sich etwa bei „gpupdate /force“). Im Beispiel wurde das Netzwerkgespräch aufgezeichnet und nach SMB-Verbindungen gefiltert. Die im Bild zu sehenden Verbindungen wurden alle für _eine_ Gruppenrichtlinie geöffnet:

Zu sehen ist, dass der Client per SMB 1.1 mehrere Verbindungen für ein und dasselbe File auf dem System erstellt, nämlich das GPT.INI-File, anhand dessen der Client entscheiden soll, ob die Richtlinie weiter verarbeitet wird (weil sie jüngst geändert wurde), oder eben nicht (weil sie seit der letzten Verarbeitung unverändert ist). Allein dieser Call benötigt nahezu 10 SMB-Aufrufe, bis die GPT.INI-Datei auf dem Client gelesen wurde.

Betrachten wir uns die Zeiten der Verbindungen genauer, stellen wir fest, dass zwischen den Calls eine Menge Zeit vergeht – der Test wurde über eine WAN-Strecke mit 300 Millisekunden Latenz zu einem Windows Server 2008R2 Domänencontroller durchgeführt. Zwischen vielen Aufrufen sehen wir „Löcher“ von 300ms, in denen nichts passiert. Ein Beispiel hierzu ist Paket 210 bei 22.114426 Sekunden und dessen Antwortpaket 212 bei 22.422855 Sekunden. Genau dies sind die Problemzonen langer Latenz, die besonders bei SMB (durch seine Geschwätzigkeit) und damit auch Gruppenrichtlinien zu einem Problem werden können!

Dieses Verhalten tritt nicht nur bei Vollaktualisierungen der Gruppenrichtlinien auf – auch bei Hintergrundaktualisierungen muss der Client den Zugriff auf die GPT.INI einer jeden Gruppenrichtlinie in seinem Geltungsbereich erhalten – und wird dies auch versuchen, mit oben genanntem Verbindungsaufwand. Die Anzahl der Verbindungen wird während jeder zyklischen Hintergrundaktualisierung der Richtlinien wiederholt.

Die ganze Beispielübung, 2 Gruppenrichtlinien und die Default Domain Policy komplett neu anzuwenden, hat für den Test-Windows XP Client etwa 35 Sekunden gedauert. Hierbei eingeschlossen sind die LDAP-Calls nach Active Directory und das Suchen und Finden der benötigten Dateien auf dem SYSVOL via SMB (GPT.INI, die Registry.POL für Administrative Vorlagen und die GPTmpl.inf für Sicherheitseinstellungen).

Im Gegensatz dazu ein Netzwerktrace eines Windows 7 Clients, der die gleichen Richtlinien per „gpupdate /force“ aktualisiert. Der Unterschied: der Windows 7 Client holt sich die Richtlinien von einem Windows Server 2008 R2 der gleichen Domäne. Hier kommt SMB2 zum Einsatz, das wesentliche Verbesserungen und ein schlankeres Gesprächsprotokoll mitbringt, was sich positiv auf dem Kabel bemerkbar macht. Näheres zu SMB2: https://technet.microsoft.com/de-de/library/ff625695(WS.10).aspx und https://blogs.technet.com/b/josebda/archive/2008/12/09/smb2-a-complete-redesign-of-the-main-remote-file-protocol-for-windows.aspx

Markiert im Bild sind die Gesprächsteile, die zuvor bei einem Windows XP-Client mit einem Windows Server 2008R2 DC etwa 10 Calls benötigten. Durch das schlankere Protokoll wurde die Zahl der Verbindungen auf drei Calls für beispielsweise die GPT.INI pro GPO reduziert. Die Verarbeitung geht somit deutlich schneller von Statten – weniger Calls bedeuten weniger kumulierte Latenz. Der Windows 7-Client schaffte die Komplettverarbeitung der Richtlinien im Test in nahezu 17 Sekunden.

Die in den Traces gezeigten Zeiten und die Anzahl der Calls machen deutlich, dass einige Verbindungen zum Server aufgebaut werden, damit die benötigten Informationen von Active Directory und SYSVOL zum Client fließen können. Es wird deutlich, dass bei großer Latenz die Abarbeitung von Richtlinien zu einem Problem werden können, da Clients einige Verbindungen zum SYSVOL-Share öffnen müssen.

Unsere Erkenntnisse und die daraus folgenden Schlüsse lassen sich wie folgt zusammenfassen:

• SMB 1.1 ist ein relativ gesprächiges Protokoll
• Für Clients, die per SMB 1.1 mit dem Domänencontroller kommunizieren (müssen), die ihre Gruppenrichtlinien aktualisieren, egal ob Komplettanwendung oder zyklische Wiederholung alle 90-120 Minuten, werden mindestens 10 Nachrichten an den Domänencontroller via SMB geschickt (Prüfung der GPT.INI, ob eine Richtlinie verarbeitet werden muss).
• Falls die Richtlinie verarbeitet werden soll, folgende weitere Calls je nach konfigurierten Einstellung (Registry.POL mit 4 Verbindungen, Sicherheitseinstellungen mit etwa 6 Verbindungen, ...).
• Wenn SMB 1.1-Clients GPOs also über eine WAN-Strecke mit „hoher“ Latenz konsumieren, kann sich die Abarbeitungsgeschwindigkeit sehr stark nach der Anzahl der Richtlinien verändern – was bei nicht latenzbehafteten Verbindungen nicht merklich der Fall ist.
• Im Test hat die Verarbeitung der Richtlinien im Vergleich zwischen SMB1.1 und SMB2 bei gleichen Richtlinien und gleichem Windows 7 Client (einmal gegen Server 2003, einmal gegen Server 2008 R2) für SMB1.1 fast doppelt so lange gedauert als bei SMB2.
• Zur Linderung des Problems sollten folgende Schritte in Betracht gezogen werden:
  • Aktualisierung der Clients und des Domänencontrollers jenseits der WAN-Strecke nach Windows Vista+ und Windows Server 2008+.
  • Das Verbessern der WAN-Strecke, sodass die Latenz abnimmt. Da die Latenz durch viele SMB-Calls die Verarbeitungszeit stark verändern kann, wäre eine Besserung der Latenz von 250ms auf 150ms schon deutlich spürbar!
  • Die Kumulierung von Gruppenrichtlinien zu weniger, größeren GPOs, damit die Anzahl der SMB-Nachrichten sinkt. Dies ist aus Managementsicht allerdings nicht immer handhabbar und für die Dokumentation und Administration der Richtlinien nicht immer empfehlenswert.
• Die Abarbeitungszeit für das Wiederanwenden aller Richtlinien (gpupdate /force, neuer Client) war bei der Verwendung mehrerer Richtlinien (mehr als 6 GPOs) über eine Latenz größer als 150ms im Lab-Test etwa doppelt so lang bei SMB1.1 (Windows XP an Server 2003) als bei SMB2 (Windows 7 an Server 2008 R2).

Welche Betriebssysteme in welchen Konstellationen welche SMB-Version miteinander verwenden, zeigt die folgende Tabelle aus https://blogs.technet.com/b/josebda/archive/2010/10/26/what-version-of-smb2-am-i-using-on-my-windows-file-server.aspx:

Es genügt also nicht, den Clients einen Server 2008 R2-DC anzubieten, wenn die Clients selbst durch Windows XP nur SMB 1.1 verwenden können. Sowohl Client- als auch Serverbetriebssystem muss passen, damit SMB2 verwendet wird.

Wie lassen sich lange Richtlinienverarbeitungszeiten auf Latenz auf dem WAN-Link zurückführen? Zum einen lässt sich das Troubleshooting mit einem einfachen „Ping“ vom Client auf die Domäne, im Beispiel fabrikam.com starten – der Roundtrip des Pings gibt eine gute Idee zur Latenz der Leitung. Desweiteren helfen ein Netzwerktrace wie etwa aus den Screenshots ersichtlich oder die Verbose Logfiles des Richtliniensubsystems, beschrieben in https://support.microsoft.com/kb/221833/en-us für Windows XP. Im userenv.log von Windows XP lassen sich diese zeitlichen „Lücken“ mehrfach feststellen, immer dann, wenn Interaktion mit dem Domänencontroller gesucht wird.

Zum Zugriff auf die sogenannte Registry.POL auf dem SYSVOL, in der unter anderem die Einstellungen der Administrativen Vorlagen für den Client zur Übernahme gespeichert werden, gibt es weiteren Optimierungsspielraum, nämlich wenn etwa viele Clients über eine schmale Leitung auf wenige DCs zugreifen, siehe https://support.microsoft.com/default.aspx?scid=kb;EN-US;319440.

Ich hoffe das Posting war ein wenig interessant und hilft bei der Planung (und Eliminierung) von latenzbehafteten standortübergreifenden Anmeldungen.

Viele Grüße,

Florian