Was sind Gruppenrichtlinien?

Autor: Mark Heitbrink - vom 15.01.2013 - Kategorie(n): Erste Schritte Hintergrundwissen Topartikel

Das wichtigste vorweg: Jede hier getroffene Pauschalaussage ist falsch und Gruppenrichtlinien können nicht zaubern.

... auch das ist eine Pauschalaussage, aber das ignorier ich jetzt :-)
 
Es gibt zu jeder Aussage mindestens eine Ausnahme (Komponente = Client Side Extension), die sich nicht so verhält wie pauschal behauptet. Manchmal ist sogar die Pauschalaussage die Ausnahme von der Regel, aber darauf  gehe ich in diesem Artikel nicht weiter ein. Wichtig ist, es gibt nicht das Verhalten "der einen" Gruppenrichtlinie im Generellen, sondern es gibt "die 50" Komponenten (CSEs) einer Gruppenrichtlinie. Die Gruppenrichtlinie als solche ist erst mal nur eine leere Hülle, die als Transportmittel verwendet wird.
 
Die Gruppenrichtlinien Infrastruktur ist nichts anderes als ein Deployment Tool, das Werte bereitstellt, die schliesslich von einem Objekt abgeholt und importiert werden. Im Gegensatz zu einem Drittanbieter, muss der "Installations Agent" nicht zusätzlich installiert werden, er ist schon nativ onboard. Die Gruppenrichtlinien nutzen die Infrastruktur das Active Directory es muss keine zusätzliche Struktur aufgebaut und gepflegt werden.
 
Es ist immer ein PULL Mechanismus., niemals ein PUSH. Bei einem PUSH müsste der Server den genauen Kenntnisstand haben, was auf dem Client vorhanden ist und was noch fehlt, damit die exakte Differenz übergeben werden kann. Das ist technisch unmöglich. Nur das Objekt weiss, was es braucht und auch übernehmen kann. Deswegen muss die Übernahme als Client Prozess ein PULL sein.

Richtlinien (Policies) unterscheiden sich im Verhalten von Einstellungen (Preferences). Das ist einer der Gründe, warum sie auch im GP Editor als jeweils eigene Knoten in der Baumstruktur dargestellt sind.

Gemeinsamkeiten

  • Es gibt einen Vordergrund (Foreground) Prozess, der immer dann gegeben ist, wenn eine Sitzung initialisiert wird, also beim Rechnerstart für den Computer und bei der Anmeldung für den Benutzer. Es gibt Hintergrund (Background) Prozesse, die am Client alle 90 Minuten mit einer Variantion von +-30 Minuten laufen und an einem Domänen Controller alle 5 Minuten. Ein per Hand aufgerufenes "gpupdate" ist ein Hintergrundprozess, denn die Sitzung besteht schon.
  • Die meisten Inhalte des GPObjekts können im Hintergrund übergeben werden. Das Problem ist nur: Das Programm, das ich manipulieren möchte muss diese neuen Werte auch verarbeiten. Manchmal reicht es, wenn das Programm beendet und neu geöffnet wird (z.B.: Internet Explorer und Office), manchmal muss man sich aber doch abmelden (viele Windows Explorer Einstellungen), manchmal reicht es eine Dienst erneut zustarten, aber dann wiederum muss man den ganzen Rechner neustarten, weil der Dienst in Abhängigkeiten steht, die ebenfalls neugestartet werden müssen.
  • Richtlinien haben eine Version. Jeder Schreibvorgang innerhalb des GPObjekts erhöht diesen. Das System muss das GPObjekt nur dann übernehmen, wenn es sich geändert hat oder es noch nie übernommen wurde. Das System speichert lokal die Version der angewendeten Gruppenrichtlinie. Vor der Übernahme kommt zu einem Vergleich der Versionen (Lokal vs. Domäne) und wenn sich die Version nicht geändert hat, muss keine Übernahme erfolgen. Das Objekt wurde mit diesen Einstellungen schon importiert.
  • Es gibt kein JETZT. "Jetzt" ist in einem internationalen Unternehmen unmöglich. 24 Stunden Zeitzone, Leute fangen an zu arbeiten, die anderen hören gerade auf, die nächsten schlafen schon. Die einen haben Urlaub und die anderen sind krank, kommen später, weil sie Gleitzeit haben und melden sich spontan später an oder sind schwanger, im Mutterschutz oder auch in Elternzeit. Es gibt keine einzige Regel die "jetzt" so dringend ist, daß sie angewendet werden muss. Selbst wenn es den Wunsch dazu gäbe, es gibt keinen Zeitpunkt an dem ich "jetzt" alle erwische. Das geht nur beim Small Business Kunden, im Büro, wo ich alle 6 Arbeitsplätze zur Not per Hand anschalte.
  • Zeit. Zeit ist ein wichtiger Faktor. Denkt daran, daß der minimale Zeitinterval der Replikation zwischen 2 Standorten (Inter-Site) bei 15 Minuten liegt. Die GPMC verbindet sich bevorzugt mit dem PDC Emulator, wenn dieser in einem anderen Standort steht, als ihr euch gerade befindet, dann benötigt es mindestens 15 Minuten, bis ihr die Gruppenrichtlinie in euren Standort testen könnt. Alternativ: Verbindet die GPMC mit eurem Standort DC. Das kann jede MMC Konsole.
  • Die Netzwerkgeschwindigkeit wird ermittelt und bei einem sogenannten erkanntem "Slow Link" sind einige Funktionen ausgeschaltet. Praktisch alle Komponenten, die ein größeres Datenvolumen mit sich bringen, werden abgeschaltet, z.B.: Scripte, Ordnerumleitung, Softwareinstallation und Dateien

 

Richtlinien/Policies

  • Richtlinien sind sicher vor dem Benutzerzugriff, sie schreiben ihre Werte in die .\Policies Schlüssel der Registry, in denen der Benutzer selbst innerhalb der eigenen ntuser.dat nur über Lesen Rechte verfügt und der Besitzer dieses Teilschlüssels ist das System.
  • Da Policies in einen alternativen Speicherort schreiben und den Orginalwert nicht manipulieren, sind sie löschbar. Sobald die Richtlinie gelöscht wird oder das Objekt den Verwaltungsbereich der Richtlinie verlässt, wird ebenso der Wert, der im alternativen Speicherbereich geschrieben wurde, aus der Registry des Objekts gelöscht. Das geschieht automatisch beim nächsten Prozess.
  • Das Objekt speichert die aus einer Gruppenrichtlinie stammenden Werte in ein einer lokalen Datei (siehe ntuser.pol im %userprofile%) und kann sie deswegen auch gezielt löschen. Die Werte sind dokumentiert.
  • Die zu kontrollierende Anwendung muss die Technik der beiden Speicherorte unterstützen und den  Wert unterhalb der .\Policies in der Registry bevorzugen. Es geht um eine Priorisierung, die der Entwickler definieren muss. Ist in .\Policies ein Wert, verwende diesen. Ist dort keiner, lies den Orginal/Standardpfad und nimm den.
  • Richtlinien werden nur bei Neuerungen oder Änderungen angewendet. Sie haben, wie schon geschrieben, eine Version. Die Einmalige Übernahme reicht, denn der Benutzer kann es nicht ändern. Da nur ein Administrator die Richtlinie ändern darf und damit die Version ändert, muss der Update Vorgang und damit die Übernahme des Werts nur bei einer Änderung erfolgen. Wenn es nicht geändert ist, muss es nicht erneut importiert werden. Das spart Traffic und unnötige Schreibvorgänge.

 

Einstellungen/Preferences

  • Einstellungen werden jedesmal verarbeitet und angewendet, sie ignorieren die Version.
  • Einstellungen schreiben in den Orginalpfad, es gibt keinen alternativen Speicherort.
  • Da es keinen Alternativen Speicherort gibt, sind sie nicht löschbar
  • Sie sind nicht sicher vor Benutzerzugriff, denn der Benutzer kann die Werte in seiner ntuser.dat ändern, deswegen werden sie jedesmal angewendet.
  • Aus meiner Sicht sind Preferences ein Scriptreplacement. Sie haben den großen Vorteil, daß ich keine Scriptsprache und Syntax erlernen muss, da die GUI die Eingaben vorgibt. Dadurch ergibt sich aber auch der Punkt: Alles was ich möchte, muss ich selber definieren. Soll sich ein Wert unter bestimmten Bedingungen löschen, dann muss das in der GPO definiert werden.
  • Group Policy Preferences sind ein zugekauftes Produkt: Das war der PolicyMaker von Desktopstandard. Da sie von einem Drittanbieter stammen, funktioneren viele Dinge von alleine so, wie man es sich denkt. Kopieren und Einfügen, ein einheitliches Format, eine einzige DLL für den Prozess, eine XML Datei.