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.

  • Gruppenrichtliniens auf Clients
    Über Gruppenrichtlinien können Einstellungen für Outlook und das System selbst eingestellt werden. Auch Funktionen wie Windows Update, die Verfügbarkeit von Diensten und Berechtigungen auf Dateien und Registrierungsschlüssel sind einstellbar.
  • Gruppenrichtlinien auf Server
    Auch auf Servern sind Gruppenrichtlinien hilfreich, um z.B.: die Größe des Eventlog, Bildschirmhintergründe, Windows Update oder SNMP Einstellungen zu konfigurieren.
  • Gruppenrichtlinien auf User
    Benutzerkonten können über Gruppenrichtlinien im Bezug auf den Explorer und andere Programme konfiguriert werden.

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.

Intune und Cloud

Gruppenrichtlinien funktionieren nur in einem lokalen Active Directory. Immer mehr Clients sind aber gar nicht mehr Mitglied einer Domain sondern nur noch "AzureAD Joined" oder sie sind "Hybrid Joined" und damit beiden Vorgaben unterworfen.

Diese Seite beschäftigt sich nur mit den Richtlinien im lokalen AD und Clients, die dort Mitglied sind. Abhängigkeiten zu einer paralllelen Verwaltung per AzureAD und Intune gibt es natürlich dennoch

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:

  • Die Gruppenrichtlinie selbst
    Dies ist eine Verzeichnisstruktur auf \\domäne.tld\sysvol\domäne.tld\policies\, in der unter der GUID der Policy mehrere Dateien liegen.
  • ADM-Vorlagen
    Hier ist hinterlegt, welche Einstellungen durchgeführt werden können. Dies ist die Handlungsanweisung für den Gruppenrichtlinieneditor. Diese Dateien werden mit in die Gruppenrichtlinien kopiert, damit bei einer späteren Änderung immer die gleichen Vorlagen genutzt werden.
  • Gruppenrichtlinieneditor
    Hiermit werden die Einstellungen durchgeführt. Dieses Programm liest die ADM-Dateien ein und bietet ihnen die Einstellung der Werte an.
  • MMC für Benutzer und Computer
    Die Gruppenrichtlinien sind in der Domäne definiert, aber können überall im Forrest verknüpft werden. Hierzu dient die Management Console für Benutzer und Gruppen und die MMC für Standorte und Dienste.

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 OU's und liest 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:

  • Server und Domaincontroller
    Angenommen ein Benutzer mit Administratorrechten meldet sich an solche einem Server an, dann wirken wie gehabt die Computerrichtlinien des Computerobjektes aber zusätzlich auch die Richtlinien des Benutzer aus dessen Organisationsstruktur. Das Problem ist, dass in Richtlinien auch Skripte enthalten sein können, die Programme starten oder Dateien kopieren. Das mag auf Arbeitsplätzen sinnvoll sein, aber auf einem Server katastrophale Auswirkungen haben. Daher sollte es einen Weg geben, die Anwendung der Benutzerrichtlinien auf bestimmten Systemen zu verhindern.
  • Terminal Server und öffentliche Systeme
    Ein Anwender kann auf seinem Arbeitsplatz gerne eine relativ offene Konfiguration haben, aber es gibt spezielle Arbeitsplätze, die besonders zu schützen sind. Das sind in der Regel "Terminal Server" aber auch öffentlicher Internetplätze in der der Kantine, Kassensysteme, Produktionssysteme etc. Diese Systeme sollen nur bestimmte Anwendungen ausführen. Demnach müssen hier zusätzliche Richtlinien gelten, die die sowieso geltenden Benutzereinstellungen verschärfen oder sogar außer kraft setzen

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:

  • Ersetzen
    Hierbei werden bei der Anmeldung des Anwenders nicht die Benutzereinstellungen anhand der Position des Benutzerobjekts sondern anhand des Benutzerteils in den Computereinstellungen angewendet
  • Verbinden
    Hier werden die Einstellungen des Benutzer sowohl aus der Position des Computers und des Benutzers zusammen angewendet. Die Einstellungen des Computers sind dominant.

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.

  • 231287 Loopback Processing of Group Policy
  • 260370 Base How to Apply Group Policy Objects to Terminal Services Servers

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 Rictlinien 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 deaktivieren oder überschreiben. Details hier finden Sie z.B. auch auf:

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 Gruppenrichtlinien1 wird anteilig zweimal angewendet.

Gruppenrichtlinien2: 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 Gruppenrichtlinien4 die Benutzereinstellungen beim Benutzer angewendet werden, obwohl dort nicht die Loopback Option aktiv ist.

Ebenso wird die Richtlinie Gruppenrichtlinien3 des Benutzers überhaupt nicht angewendet, da die Betriebsart "Ersetzen" gewählt ist.

Gruppenrichtlinien2: 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 Gruppenrichtlinien4 die Benutzereinstellungen beim Benutzer angewendet werden, obwohl dort nicht die Loopback Option aktiv ist.

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

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

Das kann zu Verwirrungen führen, da Sie davon ausgehen, dass die Gruppenrichtlinien3 die Gruppenrichtlinien1 überstimmt, wenn Sie bei der Gruppenrichtlinien1 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 Gruppenrichtlinien2 aktiv

Sie könnten auf den Gedanken kommen, dass bei einem Ersetzen einfach die Benutzerrichtlinien übergangen und die fragliche Richtlinie Gruppenrichtlinien2 eingesetzt wird. Entsprechend würde die Gruppenrichtlinien4 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 Gruppenrichtlinien2 aktiv

Wenn Loopback auf der Gruppenrichtlinien2 aktiv ist, dann könnten Sie auf den Gedanken kommen, dass damit nur die Gruppenrichtlinien2 im "Loopback Mode" konfiguriert ist, d.h. der Anwender weiterhin "seine" Richtlinien bekommt und zusätzlich der Benutzeranteil der Richtlinie Gruppenrichtlinien2 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

  • Vererbung deaktivieren
    Sie können auf Ous die Vererbung deaktivieren, so dass die Gruppenrichtlinien nicht mehr "tiefer" wirken
  • Betriebsart "überschreiben"
    Als Admin können Sie ihrer Richtlinie aber einstellen, dass auch eine unterbrochene Vererbung nicht wirkt, d.h. dass eine Richtlinie trotzdem durchschlägt
  • WMI Filterung
    Ab Windows XP und Windows 2003 können Richtlinien an WMI-Abfragen gebunden werden, z.B. nur auf System anwendbar zu machen, die z.B.. mit WiFi Netzwerkarte, bestimmter Festplattengröße, bestimmter Grafikarte, bestimmte Software etc. ausgestattet sind.
  • Filterung mittels Berechtigungen
    Die "Lesbarkeit" einer Richtlinie kann über ACLs gesteuert werden. So können Sie z.B.: über Windows Sicherheitsgruppen die Anwendung von Richtlinien feiner steuern.

Gruppenrichtlinien und mehrere Forests

Solange sich Anwender und Computer im gleichen Forest bewegen, ist die Funktion der Gruppenrichtlinien überschaubar. Aber natürlich kann es auch passieren, dass ein Benutzer in einer Domäne und der Computer, auf dem er sich anmelden, in einer anderen Domäne in einem anderen Forest ist. Natürlich kann das nur funktionieren, wenn es einen Trust zwischen den beiden Forests bzw. Domänen gibt. Nur dann kann sich der Benutzer einer anderen Domäne überhaupt auf einem PC anmelden.

Seit Windows 2003 ist es aber nun auch möglich, Gruppenrichtlinien über die Grenzen eines Forest hinaus anzuwenden. Wenn Forest1\User1 sich an Forest2\PC2 anmeldet, dann kommen zuerst die Gruppenrichtlinien für den Computer aus Forest2 zur Anwendung und mit der Anmeldung des Anwender Forest1\User2 dessen Benutzerabhängigen Richtlinien aus Forest 1.

Voraussetzung ist natürlich, das per Forest2\PC2 auch an das SYSVOL-Share des Forest1 kommt, um die Richtlinien zu lesen. Zudem gibt es auch hier natürlich mit Loopback etc. Umfangreiche Rechte, damit ein Administrator von Forest2\PC2 durchaus steuern kann, was en Anwender eines anderen Forest durch eine nicht vom Forrest2-Admin verwaltete Gruppenrichtlinien darf.

Wie wirken GPOs?

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:

  • Nicht konfiguriert
    Die aktuellen Einstellungen beim Benutzer werden nicht verändert, d.h. früher gemachte Einstellung bleiben.
  • Aktiviert
    Die Einstellungen werden übernommen.
  • Deaktiviert
    Die Einstellungen werden aktiv entfernt.

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.

  • HKLM\Software\Polices
  • HKLM\Software\Microsoft\Windows\CurrentVersion\Polices
  • HKCu\Software\Polices
  • HKCu\Software\Microsoft\Windows\CurrentVersion\Polices

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.

  • Windows Standardvorlagen
    Microsoft Windows installiert einige ADM-Vorlagen in das Verzeichnis C:\WINDOWS\INF, welche per Default angezeigt und importiert werden können. Dies sind folgende Dateien
    SYSTEM.ADM, CONF.ADM INETRES.ADM, WMPLAYER.ADM
  • Windows Update
    Wird auf dem PC der Windows Update Dienst installiert so erhalten wir wieder eine weitere Vorlage WuAA.ADM, in der dieser Dienst konfiguriert werden kann
  • Office Resource Kit
    Für Microsoft Office gibt es ebenfalls jede Menge ADM-Vorlagen, welcher bei der Installation des Office Ressource Kit ganz stillschweigend in das ADM-Verzeichnis kopiert werden.
  • Internet Quellen
    Viele weitere freie Autoren haben mehr oder weniger ihre eigenen ADM-Vorlagen erstellt
  • Eigene Entwicklung
    Natürlich können Sie mit dem Wissen um den Aufbau der ADM-Vorlagen auch eigene Richtlinienvorlagen entwickeln. Notepad, Programmers Notepad, Proton und andere Editoren eignen sich dazu hervorragend.
  • REG-Dateien zu ADM konvertiert
    Oftmals haben Sie vielleicht schon eine REG-Datei mit den Einstellungen, die sie gerne importieren wollen. Dann können Sie Programme wie PTFE oder REG2ADM nutzen um diese zu einer ADM-Datei zu konvertieren. So können Sie einfach Werte sehr früh importieren. Allerdings sind diese Dateien oftmals noch manuell nach zu arbeiten.

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 Gruppenrichtlinien 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 den Policy Analyzer

New tool: Policy Analyzer
http://blogs.technet.com/b/secguide/archive/2016/01/22/new-tool-policy-analyzer.aspx

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 Gruppenrichtlinien bearbeiten, dann werden alle ADM-Vorlagen durch die aktuellen Vorlagen ersetzt. Das ist nicht besonders schlimm, wenn Sie dieses Verhalten können 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 Gruppenrichtlinien als Kopie abzulegen

ADMX: %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 Gruppenrichtlinien 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 Gruppenrichtliniens 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 Gruppenrichtliniens 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 Gruppenrichtliniens 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

Gruppenrichtliniens 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.:

  • Listing All Gruppenrichtliniens in a Domain
  • Generate Reports für all Gruppenrichtliniens
  • Listing Gruppenrichtlinien Information

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 > Gruppenrichtlinienliste.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.

Verwaltung delegieren

Es ist ein Irrglaube, dass nur der Domänen-Administrator die Gruppenrichtlinien verwalten können. Es gibt eigens unter Windows eine Gruppe "Group Policy Creator Owners" hierfür:

Die Mitglieder dieser Gruppe bekommen das Recht, Gruppenrichtlinien anzulegen und zu verwalten. Allerdings habe ich festgestellt, dass die Personen dann nur "ihre eigenen" Gruppenrichtlinien verwalten können aber keine anderen. Das liegt wohl daran, dass der anlegende Admin auch als "Besitzer eingetragen wird.

Die Gruppenrichtlinien-MMC legt auf SYSVOL zum einen die Gruppenrichtlinie an. Die Rechte dazu hat er, wie ein Blick auf das SYSVOL-Verzeichnis zeigt:

\\%domain.fqdn%\SYSVOL\%domain.fqdn%

Allerdings fällt bei einer Gruppenrichtline als Verzeichnis direkt auf, dass der anlegende User die Rechte und auf dem Verzeichnis die Vererbung abgeschaltet ist.

Analog dazu gibt es den Link im Active Directory natürlich den Pointer auf die Gruppenrichtlinie

Wer hier auf "Policies" schaut, findet die Gruppe in der Berechtigungsliste. Schaut man sich aber dann die Rechte auf der GUID der Gruppenrichtlinie an, dann sieht man die explizit vergebenen Rechte:

Der anlegende Benutzer ist hier explizit addiert worden. Aber auch alle anderen Rechte wurden explizit vergeben. Die "Vererbung" ist auch hier per Default deaktiviert.

Damit ist nun klar, dass alle "Group Policy Creator Owners" solche Gruppenrichtliniens anlegen können, aber neben Administratoren nur der Ersteller der jeweiligen Richtlinie diese auch weiter bearbeiten kann. Andere "Group Policy Creator Owners" können die Gruppenrichtlinien nicht bearbeiten. Das kann natürlich durch einen Domänen-Administratoren" manuell gefixt" werden.

Version/Backup/Restore

Gruppenrichtlinien unterliegen einer Versionsverwaltung. Bei jeder Änderung wird die "Version" um 1 erhöht und sowohl ins Active Directory als auch in die gpt.ini im SYSVOL-Verzeichnis geschrieben. Die GPMC-MMC zeigt dies bei jeder Richtlinien auch an.

Damit ist aber keine Versionierung verbunden sondern es wird immer nur die aktuellste Version gespeichert. Wer eine Änderung rückgängig machen oder vergleichen möchte, muss eine frühere Version zurückholen. Es reicht nun nicht einfach die Dateien in SYSVOL aus einem Backup zu restaurieren, da dann die Versionsnummern nicht mehr passt. Sie können in der MMC aber sowohl einzelne Richtlinien als auch alle Richtlinien sichern.

Als Ziel geben sie ein Verzeichnis und eine Beschreibung an. Jede Richtlinie wird in einem Verzeichnis mit einer GUID abgelegt. Das ist aber nicht weiter schlimm, denn beim Restore zeigt der Dialog jede Richtlinie mit der Beschreibung und Version an.

Es bietet sich an, ab und an solche Backups anzufertigen.

Das Gesamtbild

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

Kurze Erklärung zum Bild:

  • Die Funktion des Active Directory
    Im Active Directory selbst sind die Gruppenrichtlinien aufgeführt. Dabei handelt es sich aber nur um einen "Link" auf die eigentlichen Richtlinien.
  • Sysvol
    Die Gruppenrichtlinien selbst liegen als Dateien in der SYSVOL-Freigabe. Unter Policies gibt es für jede Gruppenrichtlinien ein Verzeichnis mit dem Namen der GUID.
  • ADM Vorlagen
    Die Vorlagen, damit der Administrator in der grafischen Oberfläche die Einstellungen verstehen kann, liegen seit Windows 2000 ebenfalls in den Richtlinien. Allerdings können mit der MMC auch neue Vorlagen eingebunden werden, die dann automatisch zu den Vorlagen der Richtlinien kopiert werden. So haben später alle Administratoren immer die gleichen aktuellen Vorlagen. Problematisch hierbei ist, dass Windows auch die ADM-Vorlagen automatisch aktualisiert, wenn lokal eine neuere Datei zu finden ist. So sind die Vorlagen von Windows XP neuer als diese von Windows 2000 Server.
    Bei Windows NT4 und POLEDIT war es hingegen so, dass der Administrator selbst dafür sorgen musste, dass er die passenden ADM-Vorlagen immer parat hatte, da POLEDIT ihm sonst nur einen Teil der Einstellungen angezeigt hat. Das konnte sehr verwirrend sein.
  • Client
    Der PC bezieht dann die Richtlinien entsprechend der Hierarchie (Lokal, Standort, Domäne, Ou) und wendet diese an. Beachten Sie dabei die Feinheiten von echten und falschen Richtlinien und die Effekte, wenn Sie immer noch eine NTCONFIG.POL von NT4 im NETLOGON-Verzeichnis haben.

Warnung zu Gruppenrichtlinien

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

  • Mehrsprachigkeit
    Eine Gruppenrichtlinie besteht aus der ADM-Vorlage für die Konfiguration und die eigentlichen INF-Dateien, die vom PC ausgelesen werden. Die GPMC hat die Eigenschaft, die ADM-Vorlagen auf dem Server ohne Rückfrage zu aktualisieren. Wenn Sie also einen englischen Windows 2000 DC haben und dann von ihrer deutschen Windows XP-Workstation die Gruppenrichtlinien bearbeiten, dann kann es sein, dass Sie plötzlich deutsche Menüs und Einstellungen auf einem englischen Server wieder finden. Fatal ist dies, wenn Einstellungen auf Strings basieren, z.B. "Administrator" statt "Administrators". Es sind Fälle bekannt, wo dies passiert ist.
  • Unsichtbare Einträge
    Wenn Sie eine Gruppenrichtlinien bearbeiten aber nicht alle ADM-Vorlagen importiert haben (oder eine geänderte ADM-Vorlage nicht mehr alle Einstellungen enthält), dann sehen Sie nicht mehr alle aktiven Einstellungen. In der GPMC gibt es die Möglichkeit eben diese aktiven aber nicht mehr zu editierenden Einstellungen zu sehen. Dann können Sie eine ADM-Datei dazu suchen.

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

Gruppenrichtliniendebug.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.

Ein weitere Weg zur Analyse ist die Logdatei, die bei jedem Start der Gruppenrichtliniens angelegt werden kann. Dazu ist folgender Eintrag erforderlich

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics]
"GPSvcDebugLevel"=dword:00030002

Sie sollten noch manuell den Ordner „C:\Windows\debug\Usermode“ anlegen und den Client neu starten. In dem Verzeichnis landet dann ebenfalls eine Logdatei mit umfangreichen Informationen zur Verarbeitung der Gruppenrichtlinien.

GPO Performance

Dem Thema "Geschwindigkeit" könnte man eine ganze Seite widmen. Es ist primär falsche oder unpassende Einstellungen in Gruppenrichtlinien, die die Anmeldung an einem PC extrem verzögern können. Ein Sehr hilfreiches mittel ist das Windows Performance Toolkit ( https://msdn.microsoft.com/de-de/library/hh162945.aspx ), welches auf das Windows Assessment and Deployment Kit verweist

Windows Assessment and Deployment Kit
http://go.microsoft.com/fwlink/p/?LinkID=293840
https://msdn.microsoft.com/en-us/library/windows/hardware/dn927310(v=vs.85).aspx

Der Download ist nur ein 1,5 MB Installer, der im Extremfall bis zu 5GB herunter laden würde. Wer aber direkt die Installation wählt, kann bei der Installation die gewünschten Komponenten auswählen und dann mit weniger als 200 MB auskommen:

Das Fenster kommt nach der Auswahl der Installation, der Lizenz, des Zielpfads und der Feedbackabfrage.

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.

Achtung: Ab Office 2013 und höher und damit Outlook unterliegt einigen Beschränkungen, die Microsoft an der Lizenz fest macht.

Ich bin sehr unglücklich über diese unterschiedliche Behandlung, vor allem weil er kaum kommuniziert wird und eine Firma in einer trügerischen Sicherheit wähnt.

Edition Lizenz Gruppenrichtlinien

Office Home & Student

Retail perpetual

Nein

Office Home & Business

Retail perpetual

Nein

Office Professional

Retail perpetual

Nein

Office Standard

Volume License

Ja

Office Professional Plus

Volume License

Ja

Office 365 Home oder Personal

Subscription

Nein

Office 365 Business Standard / Premium

Subscription

Nein

Office 365 Business Essentials

Subscription

Keine Desktopsoftware

Office 365 ProPlus

Subscription

Ja

Office 365 E3,E5,A3,A5,G3,G5

Subscription

Ja

Office 365 E1,F1,F3,A1,G1

Subscription

Keine Desktopsoftware

Gruppenrichtlinien 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 Gruppenrichtliniens 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.

Gruppenrichtlinien mit .NET

Gruppenrichtliniens 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 "Gruppenrichtlinien"-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.

Gruppenrichtlinien Best Practice

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

  • Klare Zuständigkeiten
    Die Erstellung und Anwendung von Gruppenrichtlinien sollte durch wenige entsprechend geschulte Mitarbeiter erfolgen. Es ist kein Problem, wenn einzelne Ou-Administratoren bestehende Gruppenrichtlinien mit ihren Ous verbinden. Aber die Erstellung und Modifikation von Gruppenrichtlinien sollten nur wenige Personen durchführen.
  • Klare Konzeption
    Gruppenrichtlinien sind sehr leistungsfähig und um die Übersicht nicht zu verlieren ist eine klare Konzeption mit der Festlegung von Bezeichnungen, Funktion und umfang notwendig. Diese steht direkt in Verbindung mit dem Konzept zu den Organisationseinheiten und der Verteilung administrativer Funktionen
  • ADM-Pool
    Speziell wenn mehrere Mitarbeiter Gruppenrichtlinien an verschiedenen Systemen erstellen, ist es hilfreich, die Richtlinien an einer zentralen Stelle zu speichern, damit alle Personen immer die gleichen Vorlagen importieren und nutzen.
  • ADM entfernen
    Bei neuen Richtlinien sollten all die ADM-Vorlagen entfernt werden, welche nicht benötigt werden. Fügen Sie dann die gewünschten ADM-Dateien hinzu. Bei einem Nachträglichen Löschen von ADM-Dateien kann es sonst passieren, dass Einstellungen aktiv sind, aber im Editor nicht mehr angezeigt werden. Zum Glück zeigt die GPMC diese unsichtbaren Einstellungen weiterhin an.
  • Gruppenrichtliniens recyclen
    Eine Gruppenrichtlinien kann an mehrere OU's verknüpft werden. Damit kann eine Einstellung in einer Gruppenrichtlinien an mehrere Ziele angewendet werden, ohne dass sie direkt auf der Domäne und mit Sicherheitsgruppen gefiltert angewendet werden müsste. Allerdings bedeutet eine Änderung an der Gruppenrichtlinien dann die Änderung für alle Ous
  • Gezielt Loopback einsetzen
    Speziell um Terminal Server stark abzusichern und sonstige Server von den Auswirkungen von Benutzerrichtlinien frei zu halten, sollte der Loopback Mode auf dieses Systeme angewendet werden
  • Niemals "unkonfiguriert" aktivieren
    Wurde in einer Richtlinie eine Einstellung aktiviert und soll diese wieder entfernt werden, so reicht es nicht immer, diese auf "nicht konfiguriert" zu stellen. Es ist sicherer diese Einstellungen auf "deaktiviert" zu stellen und dort stehen zu lassen. Ansonsten erhalten nicht nicht identische Clients.
  • Finger weg von den Standard Gruppenrichtlinien
    Es gibt die "Default Domain Policy" und die "Default Domain Controller" Policy. Sie sind gut beraten, wenn diese Richtlinien mit Ausnahme der Kennwortrichtlinien nicht angepasst werden. Viele Support Fälle sind auf falsche Einstellungen hier zurückzuführen. So wird hier z.B.: definiert, welche Konten die Anmeldung als Dienst haben. Greift die Richtlinie nicht mehr, wird höchst wahrscheinlich kein einziger Dienst mehr mit einem Usernamen starten.
    Ändern Sie auch nicht die Bindung an die OUs und Domäne und deaktivieren Sie diese nicht.

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

As a best practice, you should configure the Default Domain Policy GPO only to manage the default Account Policies settings, Password Policy, Account Lockout Policy, and Kerberos Policy....

 ....As a best practice, you should configure the Default Domain Controllers Policy GPO only to set User rights and audit policies.
https://technet.microsoft.com/en-us/library/hh875588.aspx

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 Richtlinien 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