Gruppenrichtlinien

Infos zu Gruppenrichtlinien für Entwickler finden Sie am Ende der Seite. Vielleicht lesen Sie aber dennoch die Seite von Anfang und schauen etwas über den Tellerrand hinaus.

Was haben Gruppenrichtlinien mit der MSXFAQ zu tun ?. Damit kann man doch nur die Clients kontrollieren. Das ist aber nur die halbe Wahrheit. Gruppenrichtlinien sind in einem Exchange Umfeld sowohl für Server und Clients wichtig.

Generell gilt aber auch hier, dass ohne Planung das Ganze schnell in Chaos ausartet.

Um Gruppenrichtlinien einzusetzen, ist es zwingend notwendig, eine Windows 2000 Domäne zu betreiben und die Clients ebenfalls Windows 2000 und neuer sind.

Wie funktionieren Gruppenrichtlinien ?

Ohne Windows 2000 gab es nur die Möglichkeit, über das Anmeldeskript bestimmte Einstellungen bei einem Benutzer durchzusetzen. Das Problem dabei ist, dass alle Aktionen nur die Teile betreffen können, die vom Benutzer auch geändert werden können. Damit ist es für einen Benutzer auch möglich, die Einstellungen wieder aufzuheben. Und die Einstellungen erfolgen nur einmal je Anmeldung, was in Zeiten von Suspend und Hibernate nicht mehr oft genug passiert.

Windows NT kannte schon einen Vorläufer der Gruppenrichtlinien in Form des POLEDIT und den Policies. Dies war eine Datei NTCONFIG.POL bzw. CONFIG.POL in der NETLOGN-Freigabe. Die Zuordnung der Einstellungen erfolgte über die primäre Gruppe.

Windows 2000 erlaubt nun eine sehr viel leistungsfähigere Definition von Richtlinien, in dem nicht nur auf der Domäne, sondern auch auf OU's, Standorten und dem lokalen System entsprechende Einstellungen hinterlegt werden können. Die Richtlinien werden bis auf Skripte und Softwarepakete auch immer wieder wiederholt angewendet und sind nach Computereinstellungen und Benutzereinstellungen getrennt.

Zum System der Gruppenrichtlinien gehören mehrere Komponenten:

Der PC startet nun und verbindet sich mit dem Active Directory. Entsprechend seiner Position im Directory durchläuft er den Standort, die Domäne und OUs und list die für ihn zutreffenden Richtlinien ein und wendet den Computerbestandteil an. Der Benutzerbestandteil ist nicht von Belang.

Meldet sich nun ein Benutzer an, so geht der Anmeldeprozess (WINLOGON) erneut die Struktur durch, in der sich nun das Benutzerobjekt befindet und wendet nun die für den Benutzer zutreffenden Bestandteile an.

Dies bedeutet, dass es unterschiedliche Gruppenrichtlinien für das System und den Anwender gibt, wenn die Anwender und Computer nicht in der gleichen OU sind.

Loopback und Gruppenrichtlinien

Eine besondere Funktion, die häufig missverstanden wird ist die Loopback Einstellung. Sie wissen mittlerweile, dass eine Gruppenrichtlinie aus einem Benutzeranteil und einem Computeranteil besteht und immer der angewendet wird, der für das Objekt zutrifft. Dies ist z.B. in zwei Fällen nicht sehr hilfreich:

Für diese Fälle gibt es die Möglichkeit, den Loopback Mode einzuschalten. Hierbei wird dann die Behandlung der Benutzerrichtlinien verändert. In der MMC findest sich die Einstellung hier.


(Klicken zum Vergrößern)

Es gibt zwei Einstellungen:

Beim Ersetzen sieht das Bild so aus:

Obwohl der Benutzer in seiner eigenen OU ebenfalls Gruppenrichtlinien hat, werden aufgrund der Loopback Funktion die Benutzereinstellungen vom Computer genommen. Dies ist besonders für Server zur Verhinderung benutzerabhängiger Einstellungen und Einstellung serverspezifischer Parameter (z.B. Hintergrundbild, Bildschirmschoner) als auch für öffentliche Systeme zur sicheren Einschränkung nutzbar.

Achtung: Die Loopback Option greift nicht "pro Richtlinie" sondern global für die Einstellungen des aktuell angemeldeten Anwenders, d.h. alle Computerrichtlinien werden angewendet !. Vergleichen Sie dazu auch das Beispiel weiter unten !!

Vererbung und Hierarchie

Die effektiv für einen Benutzer und Computer wirkenden Gruppenrichtlinien setzen sich aus mehreren einzelnen Gruppenrichtlinien zusammen, die anhand der Struktur im Active Directory zusammen gestellt werden.

Es werden zuerst die lokalen Richtlinien angewendet, dann die Standortrichtlinien gefolgt von den Richtlinien der Domäne und absteigend die Richtlinien, die an OU's gebunden sind. Eine später angewendete Richtlinie kann dabei Einstellungen einer vorherige Richtlinie außer Kraft setzen oder sogar umkehren.

Vista
Mit Vista werden die lokalen Richtlinien noch weiter aufgeteilt. So gibt es die lokalen Richtlinien, dann die Richtlinien für Administratoren und nicht Administratoren und dann noch einmal pro Benutzer individuelle Richtlinien.

Damit es nicht ganz so einfach wird, können Sie zusätzlich mit Berechtigungen für Benutzer, Computer und Gruppen die Sichtbarkeit filtern und seit Windows 2003 auch WMI-Filter einsetzen. Des weiteren können Sie auch noch in den Richtlinien selbst die Vererbung deakivieren oder überschreiben. Details hier finden Sie z.B. auch auf http://www.grurili.de/Grundlagen/Vererbungen_Hierarchien.htm#VererbungundHierarchien

Gruppenrichtlinien als Beispiel

Weil das nun alles sehr kompliziert ist, gibt es hier ein Beispiel mit einer einfachen Struktur und den Ergebnissen. Vielleicht machen Sie sich selbst das Spiel, die Ergebnisse noch nicht anzuschauen, sondern auf einem Stück Papier ihr Ergebnis aufzuschreiben und dann zu vergleichen:

Gegeben ist folgende etwas kniffligere Struktur. Wir haben eine Domäne mit zwei OU's. Der Computer und der Anwender ist eine einer unterschiedlichen OU.

Jede Richtlinie hat Einstellungen bezüglich der Benutzer und der Computer.

Betriebsart
Ergebnis		 Beschreibung
Normale Anwendung
  • Der Computer erhält den Computeranteil der ihm zugewiesenen Richtlinien.
  • Der Anwender erhält den den Benutzeranteil seiner Richtlinien.

Nur die Richtlinie GPO1 wird anteilig zweimal angewendet.
GPO2: Loopback Ersetzen
  • Der Computer erhält den Computeranteil der ihm zugewiesenen Richtlinien.
  • Der Anwender erhält den den Benutzeranteil der dem Computer zugewiesenen Richtlinien.

Beachten Sie, dass auch von GPO4 die Benutzereinstellungen beim Benutzer angewendet werden, obwohl dort nicht die Loopback Option aktiv ist.

Ebenso wird die Richtlinie GPO3 des Benutzers überhaupt nicht angewendet, da die Betriebsart "Ersetzen" gewählt ist.
GPO2: Loopback Merge
  • Der Computer erhält den Computeranteil der ihm zugewiesenen Richtlinien.
  • Der Anwender erhält den den Benutzeranteil der dem Computer zugewiesenen Richtlinien.

Beachten Sie, dass auch von GPO4 die Benutzereinstellungen beim Benutzer angewendet werden, obwohl dort nicht die Loopback Option aktiv ist.

Weiterhin wird hier nun die Richtlinie GPO3 des Benutzers angewendet, da die Betriebsart "zusammenführen" gewählt ist. Aber auch die GPO1 wird sogar zweimal angewendet.

Bei der Konstellation müssen Sie daher die Reihenfolge beachten, da z.B. eine Einstellung in GPO1 anfangs beim Benutzer gesetzt werden, aber z.B. durch GPO3 wieder geändert werden und durch die Loopback-Option erneut von GPO1 überschrieben werden kann.

Das kann zu Verwirrungen führen, da Sie davon ausgehen, dass die GPO3 die GPO1 überstimmt, wenn Sie bei der GPO1 nicht "force overwrite" aktiviert und die Vererbung nicht abgeschaltet haben.

Um Zweifel und Rückfragen zu vermeiden, hier gleich die beiden Optionen, die sie vielleicht selbst als Antwort gegeben hätten:

Betriebsart
Ergebnis		 Beschreibung
Loopback Ersetzen
auf GPO2 aktiv

Sie könnten auf den Gedanken kommen, dass bei einem Ersetzen einfach die Benutzerrichtlinien übergangen und die fragliche Richtlinie GPO2 eingesetzt wird. Entsprechend würde die GPO4 nicht zum Einsatz kommen, da Sie nicht dem Benutzer zugeordnet ist und darin kein Loopback aktiv ist.

Dies ist nicht der Fall!
Loopback Merge
auf GPO2 aktiv

Wenn Loopback auf der GPO2 aktiv ist, dann könnten Sie auf den Gedanken kommen, dass damit nur die GPO2 im "Loopback Mode" konfiguriert ist, d.h. der Anwender weiterhin "seine" Richtlinien bekommt und zusätzlich der Benutzeranteil der Richtlinie GPO2 des Computers angewendet wird.

Dies ist nicht der Fall!

Sobald in einer Richtlinie Loopback aktiv ist, gilt der Betrieb für alle Richtlinien. Einzig die Betriebsart "Ersetzen" oder "Zusammenführen" wird durch die Summe der Einstellungen am Ende der Verarbeitung festgelegt.

Wenn Sie daher mit Richtlinien arbeiten und nicht sicher sind, dann sollten GPMC, RSOP, GPResult etc. keine unbekannten Werkzeuge zur Fehlersuche sein. Das Beispiel macht keinen gebrauch von folgenden Funktionen die Wirkung von Gruppenrichtlinien zu steuern

Wie wirken Gruppenrichtlinien ?

Die Richtlinien selbst wirken überwiegend so, dass sie bestimmte Einstellungen in Registrierungsschlüssel setzen und die Anwendungen darauf reagieren. Es ist also nicht Windows 2000, welche die Anwendungen begrenzt, sondern die Anwendung selbst ist dafür zuständig, entsprechende Einstellungen zu lesen und die Oberfläche entsprechend anzupassen.

Damit ist auch klar, dass nicht alle Programme sich an die Einstellungen halten müssen. Selbst wenn Sie mit Richtlinien den Zugriff auf bestimmte Programme begrenzen, so greift dies nur, solange der Explorer die Shell ist.

Zudem ist auch verständlich, dass zumindest lokale Administratoren mit eigenen Richtlinien natürlich die Richtlinien des Netzwerks außer Kraft setzen können. Wobei das natürlich logisch ist, da ein Administrator eben die volle Kontrolle über das System hat. Nur "normale" Benutzer haben keine Berechtigungen, die Richtlinien zu umgehen. Dies ist aber nu bedingt korrekt, da auf http://www.sysinternals.com/blog/2005/12/circumventing-group-policy-as-limited.html gezeigt wird, wie ein Anwender die Richtlinien umgehen kann, sofern er ein eigenes Programm starten darf.

Echte und falsche Richtlinien

Beim Einsatz von Richtlinien fällt immer auf dass Richtlinien drei verschiedene Einstellungen einnehmen können:

Es wird oft erzählt, dass im Gegensatz zu Windows NT4 Richtlinien die Windows 2000 Policies bei einer Entfernung wieder rückgängig gemacht werden. Das ist nur zum Teil richtig. Werden Registrierungsschlüssel über Richtlinien gesetzt, so sind dieser in den meisten Fällen wirklich "gesetzt".

Allerdings gibt es seit Windows 2000 einen definierten Ort, an denen Richtlinien für Anwendungen gespeichert werden sollten. Es handelt sich dabei um folgende vier Bereiche in der Registrierung, an deren der Anwender selbst nur leserecht hat. Nur der WINLOGON Prozess kann hier über die Gruppenrichtlinien Werte schreiben. Damit ist die Unveränderbarkeit durch den Anwender gesichert. Er kann die Einstellungen selbst nicht verändern.

Einstellungen an dieser Stelle werden beim Abmelden wieder gelöscht. Windows 2000 merkt sich also entgegen der landläufigen Meinung nicht die "Standardwerte", sondern die Anwendung verhält sich einfach wieder "Standard", wenn die Einstellungen in den Schlüsseln "POLICY" nicht wieder gesetzt werden.

Für solche "UNDO"-fähigen Richtlinien ist es aber auch notwendig, dass die Anwendung entsprechend programmiert ist. Ein Programmierer sollte daher darauf achten, dass seine Anwendung zuerst in den vier POLICY Zweigen nach Einstellungen sucht und erst dann nach HKCU\Software\Firmenname\Anwendung sucht und schreibt.

Gruppenrichtlinien verwalten mit der GPMC

Seit 2003 gibt es von Microsoft das Programm Group Policy Management Console (GPMC), mit dem eine sehr viel bessere Verwaltung der Gruppenrichtlinien möglich ist. Sie sollten daher nicht mehr die MMC für Benutzer und Computer nutzen, sondern die GPMC installieren. Zumal Microsoft den Lizenzvertrag so geändert hat, dass der Einsatz der GPMC nun auch in reinen Windows 2000 Active Directory Umgebungen erlaubt ist. Sie benötigen aber weiterhin Windows XP oder Windows 2003, um die GPMC zu installieren.

Die GPMC zeigt ihnen dann nicht nur die Domänen und Organisationseinheiten, sondern auch die Liste aller konfigurierten Richtlinien.

Wenn Sie dann eine Richtlinie anwählen, sehen Sie sehr schnell worauf diese wirkt.

Zudem erlaubt die GPMC auch eine einfache Dokumentation der aktuellen Einstellungen.

Hier sehen Sie die WINLOGON.ADM Richtlinie im Einsatz. Wenn Sie die Richtlinie dann aber wieder bearbeiten wollen, dann startet doch wieder die alte gewohnte MMC.

ADM/ADMX/ADML Vorlagen und mehr

Nach nun klar ist, dass der Editor die Einstellungen für Gruppenrichtlinien aus den Vorlagen ausliest, stellt sich nun die Frage, welche ADM-Vorlagen es gibt, wo man diese herbekommt und wie man eigene erstellen kann.

Windows speichert diese Vorlagen im Unterverzeichnis INF im Windows Verzeichnis. Dort finden sich die meisten Vorlagen nach der Installation einer Software.

Wird eine ADM-Vorlage in eine Gruppenrichtlinie importiert, so wird diese auch nach \\domäne.tld\sysvol\ kopiert und in der Folge genutzt. Damit ist sichergestellt, dass alle zukünftigen Administratoren alle die passende ADM-Vorlage zu der Richtlinie verwenden. Dies heißt aber auch, dass bei einer neueren Version die bestehenden nicht aktualisiert werden und dass bei der Neuanlage einer GPO die aktuelle Version im lokalen INF-Verzeichnis vorliegt. Daher sollten Sie sich einen ADM-Pool anlegen, in der sie konsistent die aktuelle Version sammeln.

Diese "Auto Update Funktion" für ADM-Vorlagen können Sie selbst wieder über eine Gruppenrichtlinie ein und abschalten. Die Einstellung ist unter "Benutzerkonfiguration/Administrative Vorlagen/System/Gruppenrichtlinien/Automatische Aktualisierung von ADM-Dateien deaktivieren" versteckt.

Downloadpaket aller ADM-Vorlagen
http://www.Microsoft.com/downloads/details.aspx?FamilyID=92759d4b-7112-4b6c-ad4a-bbf3802a5c9b&DisplayLang=en

Office 2003 Service Pack 2 Administrative Template (ADM), OPAs, and Explain Text Update
http://www.Microsoft.com/downloads/details.aspx?FamilyID=BA8BC720-EDC2-479B-B115-5ABB70B3F490&displaylang=en

msxfaq-drive.adm Wechsellaufwerke blockieren
555324 HOWTO: Use Group Policy to disable USB, CD-ROM, Floppy Disk and LS-120 drivers
Fertige ADM-Vorlage basierend auf dem KB-Artikel von Simon Geary (MVP) um USB, CD-ROM, Floppylaufwerke und LS-120 Treiber zu deaktivieren.

msxfaq-winlogon.adm Setzen der Anmeldedomäne
Als Beispiel habe ich den Zweig  HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon exportiert und in eine ADM-Datei konvertiert. Diese Richtlinie ist z.B.: nützlich, um die "Default Domain" einer Workstation vorzugeben. Speziell wenn Sie per RIS eine Workstation installieren, dann ist das Default Domain oftmals der Computername eingetragen, was der Benutzer aber bei der ersten Anmeldung nicht sieht. Die Anmeldung schlägt fehl und erst dann sieht der Anwender die falsche Domäne und muss diese ändern.
Mittlerweile auch als Flash Tip: Setting the Default Logon Domain Using a Group Policy Object
http://www.microsoft.com/technet/abouttn/flash/tips/tips_080305_2.mspx

msxfaq-rdp.adm Remote Desktop aktivieren
Die Nutzung der Terminal Dienste als Administrator ist sicher einer der großen Vorteile seit Windows 2000. Damit ist es fast immer überflüssig, Drittprodukte zur Fernwartung zu installieren. Aber allzu oft wird einfach vergessen, diese "Terminaldienste" für den Administrator zu aktivieren. Ab Windows 2003 ist es ja nur noch eine Option in den Computereigenschaften. Diese ADM-Vorlage setzt genau den gleichen Registrierungsschlüssel. Nach dem Neustart des Windows 2003 Server sind dann automatisch die Terminaldienste aktiviert.

msxfaq-dumpsteralwayson.adm
Vorlage zum Aktivieren des Outlook Dumpsters für alle Ordner. Siehe auch Exchange NOTFALL - Ordner gelöscht

ADM Und Zeilenumbrüche
Achten Sie darauf, dass die letzte Zeile der ADM-Datei eine leere Zeile ist. verschiedene Versionen der MMC lesen ADM-Vorlagen nicht ein, die nach dem letzten "CATEGORY" kein CRLF enthalten.

Per Default zeigt die MMC nur die "echten" Richtlinien an. Um den Inhalt dieser Vorlagen zu nutzen, müssen Sie die Voreinstellungen (Preferences) der MMC ändern. Siehe auch
http://www.Microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/e50f1e64-d7e5-4b6d-87ff-adb3cf874365.mspx

Achten Sie weiterhin darauf, dass Einstellungen nicht doppelt in verschiedenen ADM-Vorlagen gesetzt werden, da sich diese sonst eventuell aufheben. Leider gibt es keine einfache Suche nach solchen Dubletten. Allerdings gibt es von Microsoft ein Programm ADMX, mit dem verschiedene ADM-Vorlagen verglichen werden können.

Zudem gibt es oft mit einem neuen Servicepack oder neuen Betriebssystem aktualisierte ADM-Dateien. Hierzu müssen Sie wissen, dass per Default die MMC kontrolliert, ob lokale ADM-Dateien neuen sind. Wenn lokal neuere Dateien zu finden sind, dann werden diese ohne Rückfrage nach SYSVOL in die aktuell bearbeitete Richtlinie kopiert. Dabei wird auch keine Rücksicht auf die Sprache genommen. Wenn Sie z.B. einen englischen Domain Controller haben und dann das erste mal mit ihrer nagelneuen Windows XP Workstation die GPO's bearbeiten, dann werden alle ADM-Vorlagen durch die aktuellen Vorlagen ersetzt. Das ist nicht besonders schlimm, wenn Sie dieses Verhalten kennen und akzeptieren. Allerdings ist dies auch nicht immer Problemlos, da neuere Vorlagen durch z.B. alte MMC's nicht immer geöffnet werden können.

ADMX-Vorlagen mit Windows Vista und höher

Gruppenrichtlinien wird es auch bei Vista geben. Allerdings wird sich hierbei doch einiges ändern.

Mit Vista, Windows 2008 und höher ist es möglich, die ADMX-Vorlagen zentral im SYSVOL-Share zu halten und damit nicht mehr in jeder GPO als Kopie abzulegen

ADAX: %systemroot%\sysvol\domain\policies\PolicyDefinitions\
ADML: %systemroot%\sysvol\domain\policies\PolicyDefinitions\[MUIculture]

Die Mehrsprachigkeit zeigt sich auch, dass die Vorlagen in ADMX (Settings) und ADML (Sprachabhängige Daten) getrennt sind. So können nun auch mehrsprachige Vorlagen parallel verwendet werden.

Einen solchen zentralen Konfigurationsspeicher legt Windows leider nicht von alleine an. Da sind sie als Administrator gefragt:

Im wesentlichen müssen Sie nur zwei Verzeichnisse anlegen und dann die Vorlagen dort hinein kopieren.

md %logonserver%\sysvol\%userdnsdomain%\policies\PolicyDefinitions
md %logonserver%\sysvol\%userdnsdomain%\policies\PolicyDefinitions\de-DE
copy %systemroot%\PolicyDefinitions\* %logonserver%\sysvol\%userdnsdomain%\policies\PolicyDefinitions
copy %systemroot%\PolicyDefinitions\de-DE\* %logonserver%\sysvol\%userdnsdomain%\policies\PolicyDefinitions\de-DE

Wer noch weiter Sprachen betreuen muss, muss die anderen Verzeichnisse auch noch anlegen und kopieren.

Die Templates sind nun mehrsprachig und müssen nicht mehr in der GPO selbst mit abgespeichert, sondern können an einem zentralen Ort abgelegt werden. Dies ist immer in "\\domain.tld\sysvol\\\domain.tld\policies\PolicyDefinitions". Allerdings muss dieses Verzeichnis schon vom Administrator angelegt werden. Sie müssen dann auch die ADMX-Dateien und die Sprachdateien schon manuell dort hin kopieren. Achten Sie immer darauf, dass Sie beim Austausch der ADMX-Datei auch ALLE Sprachdateien in den jeweiligen Unterverzeichnissen parallel updaten. Wer also nur mal schnell die deutschen Windows 7 ADMX-Dateien aus c:\windows\PolicyDefinitions kopiert, wird in der Verwaltungskonsole auf einem englischen Server viele Fehler wegklicken müssen, da die passenden Strings in der alten englischen Sprachdatei nicht da sind.

Die GPOs erkennen eine langsame Verbindung nun nicht mehr durch einen PING-Mechanismus, sondern durch die Abfrage der NLA (Network Local Awareness), die auch für Active Directory Standorte und Dienste genutzt wird. Bis Windows XP wurden GPOs beim Start und in Intervallen angewendet. Bei Vista wird auch bei einer Änderung der Netzwerkverbindung geprüft, was sich hierbei ändert. Das hilft z.B. wenn ein VPN aufgebaut wird, dass dann die entsprechenden Richtlinien sofort angewendet werden.

Insofern ist eine Weiterentwicklung der GPOs bei Vista/7 und 2008 erkennbar.

Client Side Extensions (CSE) mit Windows 2008

Wer schon mal die neue Konsole zur Verwaltung von Gruppenrichtlinien von Windows Vista, Windows 7 oder Windows 2007 gestartet hat, wird sich erst einmal überrascht zeigen, welche "neue" Funktionen hier sichtbar werden. Durch den Zukauf von Desktop Central und deren Erweiterungen können nun alle Windows Administratoren auch die neuen Funktionen nutzen um z.B. lokal Benutzer anzulegen, Gruppen zu verwalten, Drucker zu verwalten und vieles mehr.

Allerdings ist der entsprechende Code erst bei Windows 7/Windows 2008R2 schon von Hause aus installiert. Für Windows XP, 2003 oder Vista müssen sie die entsprechenden "Client Side Extensions" installieren die aber sowohl über die bisherigen Gruppenrichtlinien als MSI-Datei oder über Windows Update/WSUS verteilt werden können. Hier daher zur der Vollständigkeit halber der Downloadlink:

Windows Vista,
64bit http://www.microsoft.com/downloads/details.aspx?FamilyId=B10A7AF4-8BEE-4ADC-8BBE-9949DF77A3CF
32bit http://www.microsoft.com/downloads/details.aspx?FamilyId=AB60DC87-884C-46D5-82CD-F3C299DAC7CC
Windows Server 2003
64bit http://www.microsoft.com/downloads/details.aspx?FamilyId=29E83503-7686-49F3-B42D-8E5ED23D5D79
32bit http://www.microsoft.com/downloads/details.aspx?FamilyId=BFE775F9-5C34-44D0-8A94-44E47DB35ADD
Windows XP
64bit http://www.microsoft.com/downloads/details.aspx?FamilyId=249C1AED-C1F1-4A0B-872E-EF0A32170625
32bit http://www.microsoft.com/downloads/details.aspx?FamilyId=E60B5C8F-D7DC-4B27-A261-247CE3F6C4F8

GPOs per VBScript

Viel interessanter für versierte Administratoren ist aber die COM-Schnittstelle der GPMC. Damit kann per VBScript direkt die GPMC angesprochen und genutzt werden. Die meisten Scripte fangen mit diesen Zeilen an.

Set GPM = CreateObject("GPMgmt.GPM")
Set Constants = GPM.GetConstants()

Allerdings müssen Sie fast kaum mehr selbst entsprechende Skripte schreiben, weil Sie mit der Installation der GPMC schon jede Menge Beispielskripte auf ihren PC bekommen haben. Schauen Sie dazu einfach im Programmverzeichnis von GPMC unter C:\Programme\GPMC\Scripts\ nach. Sie finden hier über 30 vorgefertigte einsatzbereite Skripte, z.B.:

Mit diesen Skripten lassen sich problemlos auch eigene Lösungen zusammenstellen. folgendes Skript baut z.B. Textdatei auf, in der die OUs mit den darauf gebundenen Gruppenrichtlinien aufgezeigt werden:

cscript.exe ListSOMPolicyTree.wsf /v /Domain:msxfaq.local > gpoliste.txt

Hier die entsprechenden weiterführenden Links:

Tools rund um Gruppenrichtlinien

Bei Fehlern um Gruppenrichtlinien (und SYSVOL) gibt es mittlerweile einige Tools, die dem Administrator bei der Suche helfen.

Ein sehr guter Artikel zu Fehlern ist auch "887303 Userenv errors occur and events are logged after you apply Group Policy to computers that are running Windows Server 2003, Windows XP, or Windows 2000"

Der Speicherplatz

Der Speicherort der Gruppenrichtlinien liegt wider den meisten Vorstellungen nicht im Active Directory. Im Active Directory sind nur die Verweise auf die Richtlinien enthalten. Dazu gibt es bei jeder OU das Feld "gPLink", in welchem die Verweise auf die Gruppenrichtlinien liegen.

Dieser Verweis zeigt auf einen Eintrag in der OU "System" der Domäne

Die eigentlichen Einstellungen der Gruppenrichtlinie liegen aber im Dateisystem und sind normalerweise für jedermann auch einsehbar.

Unter dem DFS-Pfad der Domäne sind im Verzeichnis "Policies" alle Richtlinien mit ihrer GUID aufgelistet (Im Bild ist nur eine Richtlinie dargestellt). Dort sind in weiteren Unterverzeichnissen die ADM-Vorlagen und die Einstellungen für Benutzer und Maschinen hinterlegt.

Damit ist aber auch klar, dass diese Einstellungen nur innerhalb einer Domäne mittels FRS repliziert werden und eine Verknüpfung aus anderen Domänen entsprechende Zugriffe erfordern. Dies ist bei der Planung der Aufstellorte für Domänencontroller zu beachten.

Da Sie nun wissen, so eigentlich die Richtlinien liegen, können Sie diese auch einfach exportieren und importieren. Allerdings sollten Sie dabei die Datei GPT.INI aussparen, da Sie eine Versionsnummer enthält, die mit der Versionsnummer im Active Directory übereinstimmen muss. Wenn Sie daher eine Richtlinie wieder importieren, sollten sie danach einmal mit der MMC diese Richtlinie verändern, damit die Version erhöht wird und die Clients diese neue Richtlinie auch erneut anwenden.

Das Gesamtbild

Ganz schön komplex wird schon das vereinfachte Bild, welches die Zusammenhänge grob erläutert:

Kurze Erklärung zum Bild:

Warnung zu Gruppenrichtlinien

Bei all den Vorteilen und Erleichterungen durch Gruppenrichtlinien sollten Sie einige Dinge beachten:

Es ist daher immer sinnvoll, sich mit der Materie ausreichend zu beschäftigen und alle Einstellungen in einer Test-OU mit einem Test-PC und einem Testbenutzer zu überprüfen, ehe Sie diese vielleicht auf die gesamte Domäne anwenden.

Gruppenrichtlinien debuggen

Meist funktionieren Gruppenrichtlinien "einfach so". Wäre das nicht der Fall, dann hätten auch Domain Controller Probleme, da viele Einstellungen auch hier über die "Default Domain Policy" und die "Default Domain Controller Policy" kommen. Aber oft sind es einzelne Systeme, die nicht korrekt arbeiten. Hier kann ein Debugging der Anmeldungen 

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics]
"RunDiagnosticLoggingGroupPolicy"=dword:00000001
"RunDiagnosticLoggingIntellimirror"=dword:00000001
"RunDiagnosticLoggingAppDeploy"=dword:00000001
"GpMgmtTraceLevel"=dword:00000002
"UserEnvDebugLevel"=dword:00010002

gpodebug.reg.txt

Es kann auch sinnvoll sein, den kompletten Anmeldevorgang zu debuggen. Auch hier helfen ein paar Einträge in der Registrierung:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"UserEnvDebugLevel"=dword:00010002

Vergessen Sie danach aber nicht die Werte wieder auf "0" zu stellen.

Outlook per Gruppenrichtlinien steuern

Für Outlook gibt es von Microsoft nun mehrere ADM-Dateien, welche in die Konfiguration von Outlook eingreifen. Dazu dienen z.B. die OUTLK9.ADM, welche im Office 2002 Ressource Kit enthalten ist. Schauen Sie sich diese einfach mal an.

GPOs für Entwickler

Bei allen Funktionen von Windows können Gruppenrichtlinien nichts bewirken, wenn die Anwendung nicht darauf hört. Weder das Windows Betriebssystem noch die Gruppenrichtlinien steuern oder beschränken die Anwendung. Die GPOs erlauben dem Admin einfach nur zentrale bestimmte Werte in der Registrierung zu setzen (alle 90 Minuten) oder Skript zu starten, die z.B. INI und XML-Dateien kopieren oder anpassen (nur beim Anmelden des Users). Aber es obliegt ihrer Anwendung, diese Werte auch zur richtigen Zeit auszulesen und den Administrator dabei zu unterstützen, dass er eben die Einstellungen vornehmen kann.

ADM-Vorlage oder Doku der möglichen Einstellungen

Damit der Administrator die Einstellungen vornehmen kann, wäre eine ADM-Vorlage natürlich der ideale Weg. Da auch die Zeit von Entwicklern begrenzt ist, kann ein Administrator dies auch selbst machen. Aber er braucht die Information, welcher Wert an welcher Stelle was bewirkt. Es gibt Hilfsmittel, mit denen ein Administrator sich selbst eine ADM-Datei erstellen kann. weiter oben auf dieser Seite ist der Prozess beschrieben.

GPO mit .NET

GPOs und .NET ist ein anderes Thema: .NET Anwendungen speichern ja anwendungsspezifische Einstellungen gerne in der programmname.exe.config,  application.config oder Usereinstellungen in den Userpreferences, die ebenfalls XML-Dateien sind. Leider können Gruppenrichtlinien nicht sehr elegant XML-Dateien verändern. Letztlich kann ein Admin nur eine bestehende XML-Vorlage kopieren lassen (bei jedem Anmelden) oder mit einem selbst zu erstellenden Skript anpassen. Aber das kostet Zeit bei der Anmeldung ist ist keine "richtige" Richtlinien. Da die XML-Datei nicht per ACLs zu sichern ist, kann ein Anwender die gemachten Einstellungen wieder Ändern und damit die "Richtlinie" aushebeln. Daher sollten Sie auch bei der Nutzung von .NET zumindest die Beschränkungen aus den passenden Registrierungsschlüsseln auslesen.

Einstellungen lesen

Die Registrierung ist unter Windows der zentrale Speicher für Einstellungen. Für Entwickler und Richtlinien sind dabei vier Pfade relevant, welche die Anwendung auch in dieser Reihenfolge von oben nach unten ablaufen sollte, um eine Einstellung zu finden:

Pfad Beschreibung
HKLM\Software\Policies\Firmenname\Applikation\Einstellung Enthält Richtlinien, die Rechnerabhängig sind und zentral verwaltet werden
HKLM\Software\Firmenname\Applikation\Einstellung Enthält Einstellungen, die Rechnerabhängig sind aber meist nicht zentral verwaltet werden.
HKCU\Software\Policies\Firmenname\Applikation\Einstellung Enthält Richtlinien, die Benutzerabhängig sind, zentral verwaltet werden und durch den Benutzer NICHT geändert werden können.
HKCU\Software\Firmenname\Applikation\Einstellung Benutzerabhängige Einstellungen, die der Anwender auch selbst ändern kann, d.h. ein idealer Platz zum permanenten Speichern von Einstellungen des Anwenders

Der Trick der Richtlinien ist, dass es neben dem "Software"-Schlüssel auch den Unterschlüssel "Policies" gibt, in dem die Gruppenrichtlinien (Teil des Winlogon-Process) Werte ändern, die vom Benutzer aber nur gelesen werden können. Wenn ein Entwickler seine Anwendung "GPO"-tauglich ausstatten will, muss er die gemachten Einstellungen an den richtigen Stellen (Registrierung) auslesen.

Das Auslesen selbst sollte das Programm auch nicht nur einmalig beim Start machen, sondern entweder vor dem Anzeigen einer Option prüfen, ob (ausblenden) oder wie (ausgegraut) diese angezeigt werden soll oder indem es sich das Programm bei Änderungen in den fraglichen Schlüsseln informieren lässt., um dann die Konfiguration neu einzuladen. Alternativ könnte ein Programm mit einem Timer die Konfiguration regelmäßig frisch einlesen, was aber auf vielen Notebooks dann wieder negative Effekte (Strom) haben kann.

GPO Best Practice

Im Laufe des Einsatzes von Gruppenrichtlinien haben sich die Berücksichtigung einiger Regeln als hilfreich herausgestellt:

Ansonsten bietet es sich sicher an, entweder eine der Schulungen zu Gruppenrichtlinien zu besuchen oder in einem Testfeld vorab

Gruppenrichtlinien mit DCGPOFIX zurücksetzen

Manchmal ist viel auch zu viel des Guten. Bei Gruppenrichtlinien kann es schon passieren, dass eine Änderung auch etwas kaputt machen. Wenn sie dann nicht sauber dokumentiert haben, was Sie geändert haben, dann ist ein "Undo" schwer möglich. Es gibt aber einen Weg, wie man zumindest die essentiellen Gruppenrichtlinien der Domäne und der Domänencontroller wieder auf "Default" zurücksetzen kann.

Achtung:
Diverse Programme addieren in den Richtlinen Einstellungen (z.B. wer das Recht hat, sich als Dienst anzumelden). Die sind dann auch wieder zurück gestellt. Es ist daher eher eine Funktion, die für ein Testfeld gedacht ist.

Mit der GPMC können Sie Richtlinie exportieren, dokumentieren und wieder importieren. Ehe Sie in der Produktion daher einen solche radikalen Schritt durchführen, sollten Sie sich die alten Einstellungen sichern.

Um die Standardeinstellungen wieder herzustellen ist das Programm DCGPOFIX einzusetzen

dcgpofix [/Target: Domain | DC | BOTH]
Domain   - Default Domain Policy
DC           - Default Domain Controllers Policy
BOTH      - beide Policies werden zurückgesetzt

Nach der Änderung sollten Sie die Replikation des Active Directory und vor allem auch des SYSVOL-Verzeichnisses überprüfen. Erst wenn die nun neuen Richtlinien auch auf allen DC vorliegen, sollten Sie den nächsten Schritt zun.

Zudem ist es ratsam, aber aus meiner Sicht nicht zwingend erforderlich) die folgenden Schlüssel auf den Servern zu löschen und dann den Server durchzustarten:

HKEY_USERS\.DEFAULT\Software\Policies\
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies
HKEY_CURRENT_USER\Software\Policies
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies
HKEY_LOCAL_MACHINE\SOFTWARE\Policies

Nach dem Reboot werden die Schlüssel bei der Anwendung der Richtlinien dann wieder aufgebaut. 

Weitere Links

Keywords:Gruppenrichtlinien GPO ADM Policies