Wenige Richtlinien sind schneller als viele - Mythos #5

In der Logik wäre ein Fahrzeug mit 2 Rädern immer schneller als eines mit 4 Rädern. Roller vs. Sportwagen, 1000ccm Krad vs. LKW, Fahrrad vs. Bollerwagen etc? Die Anzahl der GPOs hat den geringsten Anteil an der Geschwindigkeit.

Wer wissen will wie lange seine GPO Übernahme dauert, dem lege ich das  GPAnalyser.ps1 Script ans Herz. Leider hat Microsoft die Technet Gallery abgeschaltet, deswegen gibt es das hier zum Download. 

Der wichtigste Punkt ist, alleine anhand der Anzahl der Richtlinien könnt ihr niemals eine Aussage zur Performance treffen. Nie. Nicht. Niemals.

Die Begründung liegt in der Verwechslung "Richtlinie" und "Funktion", bzw. Inhalt. Die Richtlinie ist nur eine Transporthülle für Funktionen. Diese Funktionen (Client Side Extensions) bestimmen die zu importierenden Daten aus dem Sysvol für den Client. Jede CSE für sich hat unterschiedliche Aufgaben und Prozesse, Datenvolumen, Datenformate und damit Übertragungsraten in einem Netzwerk und am Ende dadurch extrem unterschiedliche Prozesszeiten.

Machen wir ein paar Milchmädchenrechnungen auf und reden über den Inhalt.

• 5 Richtlinien vs. 20 Richtlinien

Der erste Gedanke wird sein, 5 GPOs sind schneller als 20, das fühlt sich logisch an, es sind weniger. Dann schaut ihr in die Richtlinien und stellt fest, das der Admin der 5 Richtlinien jeweils 5 CSEs verbaut hat, der Admin mit den 20 aber granular immer nur eine Funktion/CSE verwendet hat, durch seinen eher thematischen Ansatz der Richtlinien.
Jetzt stehen unterm Strich 5x5 = 25 DLL Prozesse den 20x1 DLL Prozessen gegenüber und auf einmal sind 25 CSE DLLs langsamer als 20 CSEs.
Fazit: ohne Kenntnis des Inhalts sagt die pure Anzahl nichts.

• Ihr möchtet 300 Werte an einen Client übergeben.

Von Registry bis Security, Erweiterte Überwachungskonfiguration, Microsoft Firewall, Applocker, Desktop Shortcuts, Ordnerumleitung, Scripte, etc. Wir bauen diese in 2 Konzepten auf, einmal eine GPO mit Allem, einmal viele kleine GPOs.

Die Übernahme der einen großen wird messbar schneller sein, was das Lesen aus dem Netzwerk betrifft. 100kB am Stück lassen sich I/O seitig schneller lesen, als 100x1kB. Der Anwender wird es kaum merken, aber messbar ist es.

Jetzt ändert der Admin eine einzige Policy im Bereich der Administrativen Vorlagen. Was wird passieren? Die Hülle der Gruppenrichtlinie aktualisiert sich und der Zähler wird plus 1 erhöht. Damit ist jetzt jede CSE der GPO angewiesen alle Daten erneut zu importieren, da sich die Hülle aktualisiert hat. Es gibt keine Versionhistorie auf CSE Ebene, sondern nur auf Gruppenrichtlinien (Hüllen) Ebene.
Die kleine Änderung führt dazu, das 8 oder 10 DLLs erneut alles verarbeiten müssen und nicht nur eine CSE. Bei 2 oder 3 Richtlinien mit jeweils vielen CSE kann das einen riesen Rattenschwanz auslösen. Siehe Mythos 2. am Ende des Artikels.

• WiFi ist der Tod der Gruppenrichtlinien Übernahme.

Aus der ca. 3-5 Sekunden LDAP Query zur Ermittlung aller Objekte werden 45+. Aus dem Download der wenigen Kilobyte, die im Gigabit Netzwerk keinen interessieren, werden "Stunden", da WiFi und SMB sich nicht mögen ... und dann kommt noch jemand auf die Idee "AlwaysOn" in der Pampa mit Latenzen jenseits der 150ms zu aktivieren. 
In dem Moment ist die Anzal der Richtlinien völlig egal. Das System ist langsam.

• Das Datenformat zur Übergabe ist relevant.

Group Policy Preferenzen kosten Zeit. GPP Registry vs Administrative Vorlagen sind ca. Faktor 10 langsamer obwohl mit beiden Schnittstellen nur Registrywerte geschrieben werden. Der Grund ist, GPPs erzeugen ein XML. Ein XML hat anhand der Syntax ein unglückliches Verhältnis von Volumen zu Kontext und auch mehr Dateivolumen als das von den Administrativen Vorhagen verwendete .pol Format. Entscheidender ist: Durch das XML muss ein Parser, um zu bewerten, was zu tun ist. Das registry.pol File der Administrativen Vorlagen ist natives Registry Datenbank Format. Wenn das File gültig ist, wird es ohne weitere Prüfung gemerged.

Group Policy Preferences Shortcut sind technisch ein große Hilfe, aber langsam da immer die Zieldatei auf Existenz geprüft wird. Liegt diese im Netzwerk, kostet es zusätzlich Zeit. GPP Environment ist langsam. GPP Laufwerksmapping kann in einen Default Timeout von 20 Sekunden laufen, wenn der Server zwar erreichbar ist, aber zB durch eine Firewall Regel SMB blockiert.

Nehmt euch den gpanalyser zur Hand und testet euer Netzwerk. Vorher kann keiner etwas zur Performance nur durch zählen der Richtlinien sagen. Das ist ein Blick in die Glaskugel und Raten.

Anhand der Analyse könnt ihr entscheiden auf welcher Schnittstelle zB durch Technikwechsel Performance zu gewinnen ist. Das kann geschiehen, durch das Verlegen von Richtlinien Werte ins Deployment Werkzeug, Änderung der GPP Registry zu ADM(x) usw.

Am Ende habt ihr ein schöne performante Umgebung ... und dann baut jemand ein Anmeldescript mit einen "wait 30" oder kopiert bei jeder Anmeldung 50MB, oder verteilt Drucker, deren Treiber heruntergeladen werden müssen und macht damit alles kaputt.

P.S.: "Immer auf das Netwzerk warten" ("Always wait for the Network") zwingt den Rechner jedesmal in einen Synchronen Vordergrundprozess obwohl er in den meisten Fällen nicht notwendig ist. Die Richtlinien wartet nicht auf das Netzwerk. Der RegistryValue dahinter heisst: SyncForegroundPolicy = 1, wenn aktiviert und das bremst den Rechner aus. Er wartet aber nicht auf das Netzwerk. sondern ist langsamer in der Hoffnung, das das Netzwerk bis dahin da sein könnte. Synchron/Seriell ist immer langsamer als Multitasking. Das ist so XP ... macht das nicht.