Arbeiten mit administrativen Vorlagen

Transkript

1 Kapitel 5 Arbeiten mit administrativen Vorlagen In diesem Kapitel: Einführung in administrative Vorlagen 212 Administrative Vorlagen und ADMX-Dateien 218 Erweitern der Standardvorlagen 224 Zusammenfassung

2 212 Kapitel 5: Arbeiten mit administrativen Vorlagen Die wohl umfangreichsten Komponenten in den Gruppenrichtlinien sind die administrativen Vorlagen, welche es sowohl in der Benutzer- als auch Computerkonfiguration gibt. Die Hauptaufgabe von den administrativen Vorlagen ist dabei die gezielte Änderung von Betriebssystem-Einstellungen und Windows-Komponenten. Dabei kann es sich um kleine Einstellungen, wie den zu verwendenden Bildschirmschoner handeln, aber auch um umfangreiche Konfigurationen, wie die Angabe von Wechselmedien, auf die schreibend zugegriffen werden kann. Im Prinzip verbergen sich hinter den Einstellungen der administrativen Vorlagen jeweils ein oder mehrere Registrierungsschlüssel, die auf den kontrollierten Systemen gesetzt werden. Auf diesem Wege ist es sehr einfach, einen sehr hohen Standardisierungsgrad in der Umgebung zu erreichen und die Arbeit der Benutzer und Administratoren optimal zu unterstützen. Microsoft hat mit Windows Server 2008 und Windows Vista umfangreiche Änderungen an den administrativen Vorlagen vorgenommen. Dies bezieht sich nicht nur auf die Quantität, immerhin sind in den Windows Server 2008-Gruppenrichtlinien über 800 neue Einstellungen hinzugekommen (keine Sorge, diese werden in diesem Kapitel nicht alle im Detail vorgestellt), sondern auch oder gerade auf die zugrunde liegenden Techniken. So hat Microsoft sich von den altbewährten textbasierten ADM-Dateien zur Beschreibung der zur Verfügung stehenden Einstellungen verabschiedet und setzt nun mit den neuen ADMX-Dateien auf das flexiblere XML-Format. Auch viele administrative Probleme hat Microsoft adressiert: So kam es in der Vergangenheit immer wieder zu Problemen bei der Verwaltung von administrativen Vorlagen in gemischten oder multilingualen Umgebungen. Durch die Einführung des Central Store in Windows Server 2008 zur Speicherung der ADMX-Dateien im Netzwerk ist es nun deutlich einfacher, ADMX-Dateien zentral zu verwalten und auch dezentrale Administrationsmodelle für Gruppenrichtlinien umzusetzen. Einführung in administrative Vorlagen Wirft man das erste Mal einen Blick auf den Bereich der administrativen Vorlagen in einer Gruppenrichtlinie, könnte einen schnell das Gefühl beschleichen, von der Masse an Einstellungen erschlagen zu werden. Immerhin werden Einstellungen in der Computer- und Einstellungen in der Benutzerkonfiguration out-of-the-box angeboten, die zur Anpassung der System- und Benutzerumgebung eingesetzt werden können. Jede dieser Einstellungen dient dabei direkt der Konfiguration eines oder mehrerer Registrierungsschlüssel, abhängig von der Komplexität der Richtlinie. Die Richtlinien teilen sich dabei in Einstellungen der Computer- und der Benutzerkonfiguration innerhalb der Gruppenrichtlinien auf. Richtlinien, die im Bereich der Computerkonfiguration gesetzt werden, gelten dabei für alle Systeme unter der Kontrolle der Gruppenrichtlinie, unabhängig von dem angemeldeten Benutzer. Dagegen sind die Richtlinien der Benutzerkonfiguration für Benutzereinstellungen verantwortlich und wirken immer unabhängig von dem System, an dem sich der Benutzer anmeldet.

3 Einführung in administrative Vorlagen 213 Über 800 neue Einstellungen eine Übersicht Ich denke, es ist sowohl in Ihrem als auch unserem Interesse, wenn wir an dieser Stelle auf die Beschreibung aller neuen Einstellungen im Bereich Administrative Vorlagen verzichten. Allerdings möchten wir Ihnen an dieser Stelle eine kurze Übersicht über die einige neue Bereiche geben: System/Geräteinstallation Über diesen Container können Sie steuern, welche Geräte auf einem System installiert bzw. nicht installiert werden können. So können Sie beispielsweise erreichen, dass auf Systemen in der Kontrolle der Gruppenrichtlinie keine oder nur bestimmte USB-Sticks oder USB-Festplatten installiert werden können. Dieser Container steht nur in der Computerkonfiguration zur Verfügung. System/Wechselmedienzugriff An dieser Stelle können Sie steuern, auf welche Geräteklassen, wie z.b. CD/DVD, Disketten oder Wechselmedien schreibend oder lesend zugegriffen werden kann. Über die Richtlinien Benutzerdefinierte Klassen: Lesezugriff verweigern bzw. Schreibzugriff verweigern können Sie anhand der Geräteklassenkennung auch individuelle Einschränkungen vornehmen. Diese Einstellungen gibt es sowohl in der Computer- als auch Benutzerkonfiguration. Windows-Komponenten In diesem Bereich hat Microsoft die etwas sperrige und unübersichtliche Struktur von Windows Server 2003 durch klar strukturierte Unterkategorien entschlackt. Zusätzlich sind vielfältige Unterkategorien für neue Funktionen in Windows Vista und Windows Server 2008 entstanden, die der direkten Konfiguration der entsprechenden Funktionen dienen. Hierzu zählen beispielsweise: Windows-Sidebar Windows-SideShow Windows-PowerShell BitLocker-Laufwerksverschlüsselung Tablet-PC Windows-Defender Anlagen-Manager Finden der gewünschten Richtlinie Ein großes Problem bei der Arbeit mit administrativen Vorlagen war immer die gewünschte Einstellung zu finden. Microsoft begegnet diesem Problem bei Windows Server 2008 und Windows Vista auf zwei Wegen: Zum einen wurden die Kategorien innerhalb der administrativen Vorlagen erweitert, so dass diese einfacher bestimmten Funktionen zugeordnet werden können. Auf der anderen Seite wurde die Filterfunktion mit einer Volltextsuche ausgestattet, so dass jetzt gezielt nach Schlüsselwörtern gesucht werden kann. Im neu hinzugekommenen Ordner Alle Einstellungen haben Sie entsprechend der Abbildung 5.1 eine Übersicht über alle vorhandenen Richtlinien innerhalb der Computer- bzw. Benutzerkonfiguration.

4 214 Kapitel 5: Arbeiten mit administrativen Vorlagen Abbildung 5.1 Alle Richtlinien der Benutzerkonfiguration an einem Ort Über das Kontextmenü des Ordners Alle Einstellungen können Sie nach Auswahl des Befehls Filteroptionen Kriterien definieren, nach denen Sie die Richtlinien filtern möchten. Im in Abbildung 5.2 dargestellten Dialogfeld können Sie die angezeigten Richtlinien nach folgenden Aspekten einschränken: Typ Hier können Sie zwischen verwalteten, nicht verwalteten und beiden Arten von Richtlinien filtern. Unter verwalteten Richtlinien versteht man Einstellungen, die nicht den originalen Registrierungswert verändern, sondern solche, die die Einstellung in einem alternativen präferierten Registrierungspfad speichern. Hierzu zählen nahezu alle standardmäßig im System vorhandenen Einstellungen. Zusätzlich können Sie sich nur verwendete (konfigurierte) Richtlinien anzeigen und solche, in denen Kommentare hinzugefügt worden sind. Schlüsselwortfilter aktivieren Sehr nützlich ist auch die Suche nach Schlüsselwörtern. Um beispielsweise alle Richtlinien zu finden, die im weitesten Sinne mit Wechselmedien zu tun haben, können Sie nach diesem Schlüsselwort suchen. Über die Kontrollkästchen können Sie zudem wählen, ob das Schlüsselwort im Namen, in den Erklärungstexten oder den benutzerdefinierten Kommentaren der Richtlinie vorkommen soll.

5 Einführung in administrative Vorlagen 215 Anforderungsfilter aktivieren Alternativ können Sie auch nach unterstützten Plattformen und Applikationen filtern. Wenn Sie beispielsweise in Ihrem Unternehmen Windows 2000 SP4 als Client einsetzen, können Sie die angezeigten Richtlinien auf alle einschränken, die mindestens auch von Windows 2000 SP4 unterstützt werden. Abbildung 5.2 Definieren von Filtern zur Anzeige von bestimmten Richtlinien Sie können die zu verwendenden Filter beliebig miteinander kombinieren, um so schnell zu den gesuchten Richtlinien zu gelangen. Nachdem die Filter angewendet worden sind, werden alle zutreffenden Richtlinien zum einen im Container Alle Einstellungen angezeigt. Zum anderen werden aber auch die Kategorien und Richtlinien im allgemeinen Part der administrativen Vorlagen auf die Bereiche eingeschränkt, die zu den Filtern passen. In der Abbildung 5.3 sehen Sie zur Veranschaulichung das Filterergebnis zur Suche nach dem Wort»Wechselmedien«. Unabhängig davon, ob Sie die Filter auf dem Ordner Alle Einstellungen der Computer- oder Benutzerkonfiguration definiert haben, wirkt er sich immer auf beide Bereiche aus. Über das Kontextmenü von Alle Einstellungen können Sie durch einen Klick auf Filter aktivieren wieder zur normalen Ansicht zurückkehren.

6 216 Kapitel 5: Arbeiten mit administrativen Vorlagen Abbildung 5.3 Anzeige der gefilterten Richtlinien Wie sich Richtlinien auswirken Nachdem die gewünschte Richtlinie lokalisiert wurde, stellt sich natürlich noch die Frage: Wie wirkt sich diese bei Aktivierung aus und wird sie überhaupt von den gewünschten Systemen unterstützt? Gerade in heterogenen Systemumgebungen, in denen sowohl Windows 2000-, Windows XP- und Windows Vista- Clients im Einsatz sind, sollte bei der Verwendung von Richtlinien beachtet werden, auf welche Systeme sich diese auswirken. Microsoft stellt zu jeder Richtlinie ausführliche Erklärungen bereit, in denen sowohl die unterstützten Systeme bzw. Applikationen als auch die Auswirkungen bei Aktivierung bzw. Deaktivierung der Richtlinie aufgeführt werden. Diese finden Sie zum einen direkt in der Oberfläche des Gruppenrichtlinienverwaltungs- Editors links neben der eigentlichen Richtlinie selbst (Abbildung 5.3). Zum anderen können Sie diese auch in den Eigenschaften der Richtlinie auf der Registerkarte Erklärung einsehen (Abbildung 5.4). Allerdings finden Sie dort lediglich die Auswirkungen der Richtlinie, nicht die unterstützten Systeme.

7 Einführung in administrative Vorlagen 217 Abbildung 5.4 Erklärung in der Richtlinie selbst HINWEIS Die Erklärungen direkt in der MMC werden nur in dem standardmäßig verwendeten erweiterten Ansichtsmodus verwendet. In welchem Modus Sie sich befinden, können Sie am unteren Bildrand über die entsprechenden Reiter sehen. Auch wenn Ihnen bei der Konfiguration der Richtlinien klar ist, warum Sie diese verwenden, könnte dies nach einiger Zeit bzw. bei Kollegen eventuell nicht der Fall sein. Aus diesem Grund empfiehlt es sich, vorgenommene Änderungen an den Gruppenrichtlinien direkt zu dokumentieren. Auf diesem Weg ist sichergestellt, dass auch nach langer Zeit nachzuvollziehen ist, warum Einstellungen gemacht worden sind. Microsoft bietet mit dem überarbeiteten Gruppenrichtlinienverwaltungs-Editor von Windows Server 2008 für jede Richtlinie die Möglichkeit, direkt in der Richtlinie Kommentare zu hinterlegen (Abbildung 5.5). Hier könnten Sie beispielsweise die der Änderung zugrunde liegende Ticketnummer, eine kurze Erklärung oder einen Ansprechpartner für den Hintergrund der Einstellung hinterlegen. Allerdings ersetzt die Kommentar-Funktion nicht eine detaillierte Dokumentation der Gruppenrichtlinieninfrastruktur, sondern kann diese höchstens unterstützen.

8 218 Kapitel 5: Arbeiten mit administrativen Vorlagen Abbildung 5.5 Dokumentation von Änderungen direkt in den Richtlinien HINWEIS Informationen zur Dokumentierung einer Gruppenrichtlinieninfrastruktur finden Sie in Kapitel 9. Administrative Vorlagen und ADMX-Dateien Alle Richtlinien, Erklärungen, Anforderungen und Oberflächeninteraktionen, die in den administrativen Vorlagen mit einem Gruppenrichtlinienverwaltungs-Editor definiert werden können, sind in ADMX- Dateien hinterlegt. Die Einstellungen selbst, die im Bereich der administrativen Vorlagen vorgenommen werden, werden nicht in den ADMX-Dateien, sondern in so genannten Registry.pol-Dateien gespeichert, die in den entsprechenden Ordner im SYSVOL-Verzeichnis der Domäne abgelegt und den Systemen der Domäne zugänglich gemacht werden. Ebenso wird aus den Registry.pol-Dateien beim Öffnen einer Gruppenrichtlinie im Editor ausgelesen, welche Richtlinien konfiguriert sind und die Einstellungen entsprechend dargestellt. HINWEIS Dateien«. Weitere Informationen zu Registry.pol-Dateien finden Sie später in diesem Kapitel im Abschnitt»Registry.pol- Während Microsoft vor Windows Vista bzw. Windows Server 2008 noch einfache Textdateien, so genannte ADM-Dateien, zur Definition der Richtlinien verwendet hat, wurde nun auf ein sehr viel flexibleres XML- Format umgeschwenkt. Auch die Struktur wurde entzerrt. Während früher lediglich fünf ADM-Dateien standardmäßig verwendet worden sind (wobei nahezu 95% der Einstellungen in der system.adm hinterlegt waren), werden nun sehr viel mehr aber dafür kleinere und übersichtlichere ADMX-Dateien verwendet, die leicht den Kategorien im Gruppenrichtlinienverwaltungs-Editor zugeordnet werden können. Zusätzlich zu jeder ADMX-Datei gibt es eine entsprechende ADML-Datei, welche ebenfalls das XML-Format verwendet und die entsprechende Lokalisierung der Richtlinien und Texte der ADMX-Datei enthält. Microsoft hat also gegenüber den vorherigen Versionen die technische Seite von den textlichen Aspekten getrennt und so eine deutlich größere Unabhängigkeit zwischen der Client-Sprache und den angezeigten Gruppenrichtlinien

9 Administrative Vorlagen und ADMX-Dateien 219 geschaffen. So enthält beispielsweise die ADMX-Datei logon.admx die Richtlinien, die im Pfad Benutzerkonfiguration/Richtlinien/Administrative Vorlagen/System/Anmelden zu sehen sind. In dieser Datei sind lediglich Variablen definiert, welche dann in der korrespondierenden Datei logon.adml ihre ausführliche textliche Erklärung finden. Die zur Verfügung stehenden Sprachen richten sich dabei nach dem Betriebssystem. Ein deutsches Windows Vista besitzt beispielsweise nur die deutschen ADML-Dateien, während ein englisches System diese in englischer Sprache mitbringt. Sie finden die ADMX-Dateien im Ordner %WinDir%\Policy Defnitions und die entsprechenden ADML- Dateien in einem Unterordner benannt mit dem Ländercode der zugrunde liegenden Sprache. Für die Sprache Deutsch wäre dies der Order de-de. Hier zeigt sich schon die größte Stärke der Trennung von technischen und textlichen Aspekten. Da diese nun unabhängig voneinander sind, werden Inkompatibilitäten in multilingualen Organisationen vermieden. Ein Client, auf dem die deutsche Sprache aktiviert ist, lädt entsprechend zu den allgemein gültigen technischen ADMX-Dateien die lokalisierten Texte aus dem Unterordner de-de. Ein englischer Client hingegen würde zwar die gleiche ADMX-Datei laden, aber aufgrund der anderen Sprachversion die entsprechenden Texte aus dem Ordner en-en, und würde so alle Richtlinien im Gruppenrichtlinienverwaltungs-Editor in englischer Sprache angezeigt bekommen. In welcher Sprache sie also die Richtlinien in den administrativen Vorlagen angezeigt bekommen, hängt zum einen von den installierten Sprachen und zum anderen von der aktivierten Systemsprache ab. Verarbeitung von administrativen Vorlagen Wer die Vorteile der neuen ADMX- bzw. ADML-Dateien verstehen will, sollte zunächst noch einmal einen Blick auf die Besonderheiten der ADM-Dateien von Windows Server 2003 und Windows XP werfen. Ein Blick in die Vergangenheit Windows Server 2003 hat standardmäßig bei einer Gruppenrichtlinie mit konfigurierten administrativen Vorlagen die fünf Standard-ADM-Dateien in das Verzeichnis der Gruppenrichtlinie innerhalb der Sysvol- Freigabe auf den Domänencontrollern kopiert. Wurde anschließend eine Gruppenrichtlinie im Gruppenrichtlinienobjekt-Editor geöffnet und auf den Zweig Administrative Vorlagen zugegriffen, hat das System die lokalen ADM-Dateien des Administrations-PCs im Verzeichnis %WinDir%\Inf mit den ADM-Dateien auf dem SYSVOL-Verzeichnis verglichen. Waren die Dateien auf dem lokalen PC aktueller, wurden diese zur Anzeige der Einstellungen verwendet und in die Sysvol-Freigabe kopiert, so dass sich dort auch die aktuellste Version befand. Dieses Verfahren konnte in manchen Organisationen zu administrativen Problemen führen: In Umgebungen mit vielen Gruppenrichtlinien wuchs der Replikationsverkehr unnötigerweise zwischen den Domänencontrollern stark an. In der Regel hatte nahezu jede Gruppenrichtlinie die fünf Standard- ADM-Dateien, die zusammen ca. 4,5 MB Speicherplatz belegten. Klingt nicht viel, aber bei 100 Gruppenrichtlinien summiert sich dies schon auf knapp ein halbes Gigabyte an Daten, die identisch sind, repliziert werden und Festplattenplatz belegen. Die Einstellungen der administrativen Vorlagen wurden immer in der Sprache angezeigt, welche die zugrunde liegenden ADM-Dateien hatten. In multinationalen Unternehmen konnte so auch schnell mal eine französische Gruppenrichtlinie entstehen, wenn der erstellende Client die französische Sprache verwendete. Dies war zwar für den Franzosen sehr angenehm, konnte aber den deutschen, englischen oder asiatischen Kollegen die Administration deutlich erschweren.

10 220 Kapitel 5: Arbeiten mit administrativen Vorlagen Durch das automatische Aktualisieren der ADM-Dateien im SYSVOL-Verzeichnis durch aktuellere Client-Dateien konnte es ebenfalls zu Problemen kommen. So hat beispielsweise das SP2 von Windows XP große Änderungen an den ADM-Dateien und dem Gruppenrichtlinienverwaltungs-Editor vorgenommen. Wurde nun eine Gruppenrichtlinie mit einem Windows XP SP2-Client geöffnet, wurden die neuen ADM-Dateien hochgeladen. Hat anschließend ein Benutzer mit einem Windows XP SP1-Client diese Gruppenrichtlinie geöffnet, hagelte es Fehlermeldungen, da die neuen Einstellungen von SP2 nicht in der alten Version des Gruppenrichtlinienverwaltungs-Editors angezeigt werden konnten. Manche dieser Probleme konnten durch Anpassungen an der Verarbeitung der ADM-Dateien gelöst werden. Allerdings hat dies dann zu anderen Einschränkungen geführt, so dass es eigentlich nie die optimale Lösung gab. Häufig konnte diesen Problemen lediglich durch administrative Disziplin vorgebeugt werden. Die Gegenwart Durch den Wechsel von ADM zu ADMX- bzw. ADML-Dateien hat Microsoft die Probleme der ADM- Dateien für Windows Server 2008 und Windows Vista gelöst. Durch die Zweiteilung treten keine sprachlichen Verwirrungen mehr auf, Benutzer sehen Gruppenrichtlinien in der Sprache ihres Clients, unabhängig von der Sprache des Systems, der diese erstellt hat. Standardmäßig werden keine Vorlagen mehr in die Sysvol-Freigabe geladen, wodurch der Replikationsverkehr für Gruppenrichtlinien minimiert wird. Auch Aktualisierungen und Überschreibungen finden nicht mehr statt, wodurch auch diese Problemquelle beseitigt wurde. Registry.pol-Dateien Wie bereits beschrieben, handelt es sich bei Registry.pol-Dateien um Unicode-Dateien, in denen die Einstellungen, die innerhalb der administrativen Vorlagen einer Gruppenrichtlinie vorgenommen worden sind, gespeichert werden. Die Dateien befinden sich direkt im SYSVOL-Verzeichnis der Domäne. Für die Computerkonfiguration im Ordner SYSVOL\domain\Policies\<GUID>\Maschine; für Benutzer analog im Verzeichnis \User. Bei der Konfiguration von Gruppenrichtlinien werden Registry.pol-Dateien nach folgendem Verfahren erstellt: Wird der Gruppenrichtlinienverwaltungs-Editor geöffnet, erzeugt das System einen temporären Registrierungsbaum mit den Schlüsseln MACHINE und USER. Wird anschließend im Gruppenrichtlinienverwaltungs-Editor der Ordner Administrative Vorlagen erweitert oder selektiert, werden dynamisch die zu verwendenden ADMX-Dateien ausgelesen und auf dem System zwischengespeichert. Wird eine Richtlinie in der Detailansicht des Gruppenrichtlinienverwaltungs-Editors ausgewählt, wird eine Abfrage der temporären Registrierung durchgeführt, um festzustellen, ob dieser Richtlinie bereits Werte zugeordnet sind. Ist dies der Fall, werden diese in der Richtlinie dargestellt. Andernfalls wird der Status angezeigt, wie er von den ADMX-Dateien oder der Snap-In-Erweiterung der administrativen Vorlagen vorgegeben ist. In der Regel ist dies der Status Nicht konfiguriert. Wird eine Richtlinie der administrativen Vorlagen editiert, wird diese Änderung in die temporäre Registrierung in den korrespondierenden MACHINE- oder USER-Schlüssel eingetragen. Wenn schließlich die Änderung der Richtlinie bestätigt wird, werden die Einstellungen der temporären Registrierungsdatei in eine entsprechende Registry.pol-Datei übernommen und im passenden Ordner im SYSVOL-Verzeichnis Machine oder User gespeichert.

11 Administrative Vorlagen und ADMX-Dateien 221 HINWEIS Registry.pol-Dateien werden nur erzeugt, wenn auch Einstellungen in den jeweiligen Richtlinien der administrativen Vorlagen durchgeführt werden. Wenn beispielsweise nur die Benutzerkonfiguration vorgenommen wurde, existiert keine Registry.pol-Datei für die Computerkonfiguration im Ordner Machine. Wird später eine Gruppenrichtlinie mit konfigurierten Einstellungen in einem Gruppenrichtlinienverwaltungs-Editor geöffnet, werden zunächst die vorhandenen Registry.pol-Dateien in die temporäre Registrierung geladen. Der Gruppenrichtlinienverwaltungs-Editor stellt also den aktuellen Stand der Gruppenrichtlinie dar. Zentrale Verwaltung von administrativen Vorlagen über den Central Store In der Standardkonfiguration werden ADMX-Dateien lediglich lokal verwaltet, und nicht wie bei Windows Server 2003 nach SYSVOL kopiert. Dies hat zur Folge, dass jeder Client nur die Einstellungen in einer Gruppenrichtlinie sehen kann, für die auch entsprechende ADMX-Dateien auf dem Rechner vorhanden sind. Gerade wenn man den Standardumfang von ADMX-Dateien erweitern möchte, kann dies sehr anstrengend werden, da man dafür sorgen muss, dass die neu hinzugekommenen administrativen Vorlagen auf jedem potentiellen Administrations-PC in der gleichen Version vorhanden sind. Um dieses Problem zu umgehen, wird mit Windows Server 2008 der Central Store (zentraler Speicher) eingeführt. Der Central Store dient dabei als zentrale Quelle für alle ADMX- und ADML-Dateien, die zur Bearbeitung der Gruppenrichtlinien zur Verfügung stehen. Ist dieser einmal erstellt, werden lediglich die zu verwendenden ADMX-Dateien sowie zu unterstützenden ADML-Dateien in den Central Store kopiert. Der Central Store befindet sich im SYSVOL-Verzeichnis der Domänencontroller und wird automatisch zwischen allen Domänencontrollern der Domäne repliziert. Der Vorteil gegenüber Windows Server 2003 ist dabei, dass die ADMX- und ADML-Dateien nur einmal im SYSVOL-Verzeichnis veröffentlicht werden und nicht für jede Gruppenrichtlinie einzeln. Auf diesem Weg wird der Replikationsverkehr auf das Minimum reduziert. Zudem können Erweiterungen der Vorlagen einfach über den Central Store verteilt werden, da lediglich die ADMX- und die zu unterstützenden Sprachen über die korrespondierenden ADML-Dateien in den Central Store kopiert werden müssen. Windows Vista und Windows Server 2008 Systeme prüfen beim Öffnen einer Gruppenrichtlinie mit dem Gruppenrichtlinienverwaltungs-Editor, ob ein Central Store auf den Domänencontrollern existiert und verwenden diesen automatisch. Nur wenn sie keinen, finden wird auf die lokalen administrativen Vorlagen zurückgegriffen. So erstellen Sie einen Central Store: 1. Navigieren Sie zu dem Pfad \\<Domänencontrollername>\SYSVOL\<Domänenname>\Policies. 2. Erstellen Sie hier den Ordner PolicyDefinitions und kopieren Sie die ADMX-Dateien aus dem lokalen Ordner %WinDir%\PolicyDefinitions in diesen Ordner. Kopieren Sie zusätzlich die Ordner und lokalisierten ADML-Dateien, z.b. de-de für die deutschen Dateien, in diesen Pfad. Dies können Sie für jede zu unterstützende Sprache wiederholen. Die Abbildung 5.6 zeigt einen Central Store, der sowohl englische als auch deutsche Vorlagen enthält.

12 222 Kapitel 5: Arbeiten mit administrativen Vorlagen Abbildung 5.6 Central Store mit deutschen und englischen Lokalisierungen Ob der Gruppenrichtlinienverwaltungs-Editor die administrativen Vorlagen aus dem lokalen Verzeichnis oder vom Central Store abruft, können Sie entsprechend der Abbildung 5.7 direkt in der Konsole sehen. Der jeweilige Hinweis wird zum einen in der Navigationsleiste am linken Bildschirm direkt hinter dem Container Administrative Vorlagen als auch bei ausgewähltem Container Administrative Vorlagen am oberen Rand des Inhaltsfensters angezeigt. Abbildung 5.7 Verifizieren, ob der Central Store verwendet wird

13 Administrative Vorlagen und ADMX-Dateien 223 Und was ist mit Windows XP? Durch den Wechsel von ADM- zu ADMX-Dateien stellt sich zwangsläufig die Frage, wie es sich in heterogenen Umgebungen mit Clients vor Windows Vista und Windows Server 2008 verhält. Windows XP und Windows Server 2003 sind nicht in der Lage, mit den neuen ADMX- und ADML-Dateien zu interagieren. Wird also eine Gruppenrichtlinie im Bereich der administrativen Vorlagen mit diesen Systemen angeschaut oder editiert, werden die zur Verfügung stehenden Richtlinien anhand der im Ordner %WinDir%\Inf vorhandenen ADM-Dateien erzeugt und anschließend in die Gruppenrichtlinienvorlage (Group Policy Template, GPT) im SYSVOL-Verzeichnis kopiert, inklusive aller damit verbundenen und bereits beschriebenen Einschränkungen. Sie können sich die zusätzlich geladenen ADM-Dateien in der Gruppenrichtlinie, wie in Abbildung 5.8 zu sehen, durch Auswahl des Eintrags Vorlagen hinzufügen/entfernen im Kontextmenü des Ordners Administrative Vorlagen anzeigen lassen. Abbildung 5.8 Klassische ADM-Dateien in einer Gruppenrichtlinie ACHTUNG Wenn Sie hier eine Vorlage entfernen, wird diese auch aus dem Ordner ADM der Gruppenrichtlinie im SYSVOL- Verzeichnis gelöscht. Administrationsdisziplin Auch wenn durch die Wechsel von ADM- zu ADMX-Dateien viele technische und organisatorische Probleme gelöst worden sind, ist gerade in gemischten Umgebungen mit Windows XP und Windows Server 2003 weiterhin Disziplin bei der Administration von Gruppenrichtlinien gefordert. Grundsätzlich sollten Gruppenrichtlinien nur auf einer Windows-Generation verwaltet werden, um Inkonsistenzen zu vermeiden. Aufgrund der neuen und vereinfachten Verwaltung mit ADMX-Dateien ist hierbei Windows Vista oder Windows Server 2008 deutlich vorzuziehen, zumal hiermit auch Einstellungen für ältere Systeme verwaltet werden können. Die ADM-Dateien von Windows XP und Windows Server 2003 bieten hingegen keine Vista und Windows Server 2008-exklusiven Funktionen.

14 224 Kapitel 5: Arbeiten mit administrativen Vorlagen Erweitern der Standardvorlagen Auch wenn Microsoft bereits etliche Richtlinien im Bereich der administrativen Vorlagen mitliefert, kann bei weitem noch nicht alles kontrolliert werden. Die standardmäßigen administrativen Vorlagen beziehen sich dabei primär auf systeminterne Komponenten und mitgelieferte Windows-Komponenten und Programme. Aber wenn man schon die Verwaltung der eigenen Umgebung über Gruppenrichtlinien zentralisiert und standardisiert, kommt schnell der Wunsch auf, auch weitere Einstellungen und Applikationen über Gruppenrichtlinien zu steuern. Dabei können die Möglichkeiten von Gruppenrichtlinien leicht über zusätzliche ADMX- und ADML- Dateien erweitert werden. Diese müssen lediglich in den entsprechenden Ordnern entweder lokal oder, bei Verwendung, im Central Store abgelegt werden. Der Gruppenrichtlinienverwaltungs-Editor zeigt diese dann automatisch beim nächsten Öffnen einer Gruppenrichtlinie an. Die Dateien müssen also nicht mehr, wie bei den ADM-Dateien früher, manuell in eine Gruppenrichtlinie hinzugefügt werden. Windows Server 2008 und Windows Vista zeigen auch automatisch alle administrativen Vorlagen im Verzeichnis PolicyDefinitions an. Es gibt verschiedene Wege, neue administrative Vorlagen zu erhalten. Der einfachste Weg ist natürlich, wenn der Hersteller der Applikationen diese direkt zur Verfügung stellt, wie Microsoft es beispielsweise regelmäßig für das Office-Paket macht. Alternativ können Sie natürlich auch selbst ADMX- und ADML-Dateien erstellen und diese anschließend in Ihrer Umgebung zur Verfügung stellen. Mit etwas Glück hat sich bereits jemand die Mühe gemacht und eine entsprechende Vorlage erstellt und im Internet verfügbar gemacht. HINWEIS Unabhängig davon, auf welchem Weg Sie neue administrative Vorlagen erhalten haben, sollten Sie diese jeweils ausgiebig in Ihrer Umgebung testen, um etwaige Wechselwirkungen mit anderen Applikationen und Systemen auszuschließen. Importieren von Herstellervorlagen Anhand der administrativen Vorlagen für Microsoft Office 2007 möchten wir Ihnen zeigen, wie Sie diese in Ihre Umgebung portieren und verwenden. CD-ROM Sie finden die ADMX- und ADML-Dateien für Microsoft Office 2007 innerhalb des Archivs AdminTemplates.exe. auf der CD-ROM zum Buch im Ordner \Software\Office 2007-Administrative Vorlagen. Sie müssen lediglich die AdminTemplates.exe-Datei entpacken, indem Sie diese über einen Doppelklick aufrufen. Anschließend geben Sie einen Pfad an, in dem die Ordner ADM, ADMX und Admin entstehen (Abbildung 5.9).

15 Erweitern der Standardvorlagen 225 Abbildung 5.9 Office 2007-ADMX-Vorlagen Nun können Sie die ADMX-Dateien aus dem Ordner ADMX in das entsprechende Verzeichnis kopieren. Abhängig davon, ob Sie einen Central Store verwenden oder nicht, ist dies entweder lokal auf den Clients, von dem Gruppenrichtlinien verwaltet werden sollen, der Ordner %WinDir%\PolicyDefinitions oder, bei Einsatz des Central Store, das Verzeichnis \\<Domänencontrollername>\SYSVOL\<Domänenname>\Policies\PolicyDefinitions. Verfahren Sie anschließend analog mit den zu unterstützenden Sprachen. Die Admin Templates unterstützen standardmäßig die Sprachen Deutsch, Englisch, Französisch, Italienisch, Japanisch, Koreanisch, Chinesisch und Taiwanesisch. Um die deutsche Übersetzung zu erhalten, kopieren Sie die ADML-Dateien aus dem Unterordner de-de der entpackten Admin Templates in das entsprechende Pendant entweder auf dem lokalen Client oder, wenn vorhanden, den Central Store. Von nun an stehen die Einstellungen für Microsoft Office 2007 in allen Gruppenrichtlinien zur Verfügung (siehe Abbildung 5.10). Die Vorlagen müssen also nicht, wie noch die ADM-Dateien von Windows Server 2003, selektiv in Gruppenrichtlinien geladen werden, sondern werden lediglich einmal global zur Verfügung gestellt.

16 226 Kapitel 5: Arbeiten mit administrativen Vorlagen Abbildung 5.10 Microsoft Office 2007-Vorlagen in einer Gruppenrichtlinie Erstellen eigener Vorlagen Wenn Sie nicht auf bereits existierende Vorlagen zurückgreifen können, können Sie auch eigene administrative Vorlagen bauen. Microsoft stellt zwei Wege zur Erstellung eigener ADMX-Datei zur Verfügung. Sie können diese manuell über einen Text- oder XML-Editor erstellen, alternativ können Sie auch den ADMX- Migrator verwenden. Der ADMX-Migrator bietet eine grafische Oberfläche zur Erstellung von administrativen Vorlagen und ist eine Gemeinschaftsentwicklung von Microsoft und der Firma Fullarmor, die in den letzten Jahren immer wieder spezielle Werkzeuge zur Verwaltung von Gruppenrichtlinieninfrastrukturen bereitgestellt hat. Beschäftigen wir uns aber zunächst mit einigen allgemeinen Überlegungen bei der Kreation eigener administrativer Vorlagen.

17 Erweitern der Standardvorlagen 227 Identifizieren der richtigen Einstellungen Das Hauptproblem bei der Entwicklung von eigenen ADMX-Dateien liegt nicht in der Erzeugung der Datei selbst. Viel schwieriger ist die konzeptionelle Vorarbeit. Bevor Sie die ADMX-Datei schreiben, müssen zunächst die Registrierungsschlüssel identifiziert werden, die später über Gruppenrichtlinien geändert werden sollen. Grundsätzlich können Einstellungen der folgenden Hauptschlüssel konfiguriert werden: HKEY_LOCAL_MACHINE (im Folgenden mit HKLM abgekürzt) HKEY_CURRENT_USER (im Folgenden mit HKCU abgekürzt) Bei den Richtlinien, die für die administrativen Vorlagen erstellt werden können, muss zwischen vollständig verwaltbaren und festen Einstellungen unterschieden werden. Vollständig verwaltbare Einstellungen Die Richtlinien der administrativen Vorlagen führen in der Regel kein Tattooing der Registrierung durch. Dies hat zur Folge, dass die Änderung einer Einstellung nicht zu einer dauerhaften Änderung der Registrierung führt, wodurch sichergestellt ist, dass der Originalwert der Registrierung nach der Löschung der Gruppenrichtlinie wieder zur Verfügung steht. Microsoft verwendet für die Standardrichtlinien folgende spezielle Pfade der Registrierung, deren Einstellungen eine höhere Priorität gegenüber dem Originalwert haben: HKLM\SOFTWARE\Policies (Bevorzugter Pfad) HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies HKCU\Software\Policies (Bevorzugter Pfad) HKCU\Software\Microsoft\Windows\CurrentVersion\Policies Der Vorteil dieser alternativen Pfade ist, dass keine Änderungen an den Originalwerten gemacht werden müssen. Wird eine Gruppenrichtlinie gelöscht oder steht einem Client nicht mehr zur Verfügung, werden die Werte aus den alternativen Pfaden entfernt, was zur Folge hat, dass lediglich der Originalwert zur Verfügung steht. Problematisch bei der Entwicklung eigener ADMX-Dateien ist, dass voll verwaltbare Einstellungen nur dann verwendet werden können, wenn die entsprechende Anwendung dies auch unterstützt. Soll beispielsweise ein Registrierungsschlüssel für den Adobe Reader in einer ADMX-Datei zur Verfügung gestellt werden, so können nur Feste Einstellungen verwendet werden, da die Applikation für die Verwendung mit alternativen Pfaden nicht konzipiert ist. Unterstützt eine Anwendung die Verwendung von alternativen Pfaden, so sollten diese bei der Entwicklung von ADMX-Dateien den Originalwerten vorgezogen werden. Im folgenden Beispiel soll zur Verdeutlichung das Hintergrundbild eines Benutzers durch die Verwendung einer voll verwaltbaren Einstellung konfiguriert werden. Das Hintergrundbild des aktiven Users ist im folgenden Registrierungswert gespeichert: HKCU\Control Panel\Desktop\Wallpaper Soll nun das Hintergrundbild über eine ADMX-Datei verändert werden, empfiehlt es sich, folgenden Pfad zu verwenden: HKCU\Software\Policies\Microsoft\Windows\Control Panel\Desktop\Wallpaper Wird anschließend ein Hintergrundbild über diese Einstellung in einer Gruppenrichtlinie definiert, wird dieses dem Benutzer angezeigt. Der Originalwert, in dem das vorherige Hintergrundbild des Benutzers gespeichert ist, wird durch diesen Wert nicht geändert. Dies hat zur Folge, dass das vorherige Bild für den

18 228 Kapitel 5: Arbeiten mit administrativen Vorlagen Benutzer automatisch wieder zur Verfügung steht, wenn die Gruppenrichtlinie gelöscht oder auf den Wert Nicht konfiguriert geändert wird. Voll verwaltbare Einstellungen werden entsprechend der Abbildung 5.11 im Gruppenrichtlinienverwaltungs-Editor mit einem einfachen Listensymbol gekennzeichnet. Feste Einstellungen Feste Einstellungen führen ein so genanntes Tattooing der Registrierung durch, d.h. die Einstellungen werden in den Originalwert geschrieben. Geht in diesem Fall die Richtlinie verloren oder wird auf den Wert Nicht konfiguriert gesetzt, bleiben die Einstellungen in der Registrierung erhalten. Einstellungen, die nicht voll verwaltbar sind, werden im Gruppenrichtlinienverwaltungs-Editor über einen kleinen Abwärtspfeil am Symbol gekennzeichnet (Abbildung 5.11). Abbildung 5.11 Voll verwaltbare und feste Einstellungen in einer Gruppenrichtlinie Zusammenspiel von festen und vollständig verwaltbaren Einstellungen Die folgende Tabelle zeigt das Zusammenspiel von festen und vollständig verwaltbaren Einstellungen.

19 Erweitern der Standardvorlagen 229 Szenario Vollständig verwaltbare Einstellung vorhanden Sinnvolle Einstellungen für ADMX-Dateien Feste Einstellung vorhanden 1 Nein Nein Standard Resultierendes Verhalten 2 Nein Ja Feste Einstellung bestimmt das Verhalten 3 Ja Nein Vollständig verwaltbare Einstellung bestimmt das Verhalten 4 Ja Ja Vollständig verwaltbare Einstellung bestimmt das Verhalten Tabelle 5.1 Zusammenspiel von festen und vollständig verwaltbaren Einstellungen Es gibt eine Reihe von Möglichkeiten, Änderungen an der Registrierungsdatenbank von Clientsystemen durchzuführen. Neben der Verwendung von Gruppenrichtlinien können auch REG-Dateien oder VB- Skripts eingesetzt werden. Es liegt in der Hand der Administratoren, für welche Möglichkeit er sich entscheidet. Es gibt eine Reihe von Situationen, in denen administrative Vorlagen die beste Wahl darstellen: Zentrale Verwaltbarkeit Gruppenrichtlinien haben den Vorteil, dass Änderungen sehr schnell an einer zentralen Stelle durchgeführt werden können. Deaktivierbarkeit Gruppenrichtlinien haben den Vorteil, dass Einstellungen aktiviert und deaktiviert werden können, wie z.b. bei der Frage, ob ein bestimmtes Symbol auf dem Desktop angezeigt werden soll. Ist eine derartige»lichtschalterfunktionalität«gewünscht oder sinnvoll, sind Gruppenrichtlinien eine hervorragende Wahl. Statische Auswahlmodi Gruppenrichtlinien haben den Vorteil, dass verschiedene Modi definiert werden können. Stellen Sie sich vor, sie möchten eine Gruppenrichtlinie zur Verfügung stellen, welche die Sprache der Clients steuert. Mittels Gruppenrichtlinien könnte dies durch ein einfaches Dropdownlistenfeld realisiert werden. Interaktivität Gruppenrichtlinien ermöglichen es Administratoren, zu einem gewissen Grad mit dem System zu interagieren. So können Pfade eingegeben, Häkchen aktiviert oder Zahlenwerte konfiguriert werden. So kann zum Beispiel das Hintergrundbild über eine einfache Eingabemaske konfiguriert werden. Kontrollelemente Sie haben mit ADMX-Dateien die Möglichkeit, folgende Kontrollelemente zur Steuerung einer Einstellung einzubinden: Aktiviert/Deaktiviert Statischer Text Editierbarer Text Kontrollkästchen Dropdownlistenfeld Numerische Felder Listenfeld Richtiger Wertetypus Mithilfe von ADMX-Dateien können die folgenden Registrierungswerte konfiguriert werden: REG_DWORD

20 230 Kapitel 5: Arbeiten mit administrativen Vorlagen REG_SZ REG_EXPAND_SZ HINWEIS REG_BINARY- und REG_MULTI_SZ-Werte werden nicht von den administrativen Vorlagen unterstützt und müssen auf alternativen Wegen implementiert werden. Diese können aber über die Gruppenrichtlinieneinstellungen verteilt werden. Ausführliche Informationen hierzu finden Sie in Kapitel 6. Kommentare Hilfreich bei der Erstellung von ADMX-Dateien sind Kommentare, welche die möglichen Einstellungen direkt in der Datei dokumentieren und so eine spätere Überarbeitung erleichtern. Kommentarzeilen werden in einer ADMX-Datei über»<!--«eingeleitet und mit»-->«geschlossen. Die Kommentare in ADMX- Dateien dienen lediglich zur Erklärung der Syntax bzw. zur Strukturierung der Vorlage. Sie sollten nicht zur Erklärung der einzelnen Einstellungen verwendet werden. Zur Erklärung der einzelnen Werte, die später mit der ADMX-Datei in Gruppenrichtlinien konfiguriert werden können, empfiehlt sich die Verwendung von explaintext-anweisungen innerhalb der policy-definition. Testen der Einstellung Um erfolgreich ADMX-Dateien in Active Directory zur Verfügung zu stellen, sollten ausführliche Tests der neu erstellten Richtlinien durchgeführt werden. Ein möglicher Testplan sollte folgende Eigenschaften dokumentieren: Wie ist das Standardverhalten der Einstellung, wenn die Richtlinie nicht aktiviert ist? Was passiert, wenn die Richtlinie Aktiviert, Deaktiviert oder auf den Status Nicht konfiguriert zurückgesetzt wird? Welche Werte kann eine Einstellung annehmen, und welches Verhalten ist an die einzelnen Einstellungen gekoppelt? Welche Änderungen können bei Aktivierung, Deaktivierung und ändern des Status auf Nicht konfiguriert beobachtet werden? Sollte eine Richtlinie mit der Eingabe von Informationen arbeiten, was passiert, wenn falsche Informationen eingegeben werden? Zum Beispiel bei der Eingabe eines Hintergrundbildes: Was passiert, wenn kein Pfad eingegeben wird? Was passiert, wenn ein falscher Pfad eingegeben wird? Was passiert, wenn ein Dateityp eingegeben wird, der in diesem Zusammenhang nicht unterstützt wird, wie z.b. eine WAV-Datei? Was passiert, wenn versehentlich ein lokaler Pfad statt eines Netzwerkpfades verwendet wird? Falls konfiguriert, ist der Standardwert richtig eingetragen? Testen Sie zunächst alle Richtlinien einzeln. Prüfen Sie allerdings auch Wechselwirkungen von Ihren neuen Richtlinien mit Richtlinien, die bereits existieren und unter Umständen ähnliche Funktionalitäten nutzen, z.b. wenn Sie ein Hintergrundbild konfigurieren, prüfen Sie die Wechselwirkungen mit den Einstellungen bezüglich des Active Desktops.

21 Erweitern der Standardvorlagen 231 Schreiben von ADMX-Dateien im XML-Format Alternativ können Sie auch ADMX- und ADML-Dateien direkt im XML-Format schreiben. Voraussetzung hierfür ist natürlich ein gewisses Grundverständnis der XML-Sprache. Sie können XML-Dateien mit jedem beliebigen Texteditor wie beispielsweise Notepad erstellen. Zu empfehlen ist allerdings ein entsprechender XML-Editor, wie beispielsweise XML Notepad 2007 von Microsoft, der Sie bei der Erstellung unterstützt. Wer schon für frühere Windows-Versionen ADM-Dateien erstellt hat, wird sich, nachdem er sich an das neue XML-Format gewöhnt hat, schnell wieder zurechtfinden, da die Elemente, die verwendet werden können, vergleichbar sind. CD-ROM Sie finden XML Notepad 2007 auf der CD-ROM zum Buch im Ordner \Software\XML-Notepad. Um eine funktionierende administrative Vorlage zu erstellen, muss sowohl die sprachunabhängige ADMXals auch die lokalisierte ADML-Datei erstellt werden. Zunächst aber erstmal ein paar allgemeine Informationen, die bei der Erstellung von eigenen ADMX- Dateien beachtet werden sollten: XML achtet auf Groß- und Kleinschreibung. Beachten Sie daher die Verwendung der genauen Syntax innerhalb Ihrer Dateien. In XML werden für Ausdrücke Tags verwendet. Jeder Tag, z.b. <policy>, muss am Ende über einen schließenden Tag </policy> geschlossen werden. Befinden sich alle relevanten Informationen in einer Zeile, muss kein expliziter Abschluss-Tag definiert werden. In diesem Fall wird das Ende des Tags mit einem»/«gekennzeichnet, wie z.b. <resources minrequiredrevision="1.0" />. Um doppelte Kategorien innerhalb der Gruppenrichtlinien zu vermeiden, sollten Sie sich in selbst erstellten Vorlagen nicht auf vorgegebene Kategorien beziehen. Stattdessen empfiehlt es sich, einen eigenen Kategorienamen, beispielsweise Eigene Einstellungen oder den Firmennamen zu verwenden. Auch sollten Sie alle Richtlinien, die Sie für eine Kategorie erstellen, in einer Vorlage zusammenfassen. Alternativ können Sie auch eine ADMX-Basisdatei erstellen, auf die sich weitere selbst erstellte ADMX-Dateien beziehen. Weitere Informationen hierzu finden Sie später in diesem Kapitel im Abschnitt»Erstellen einer Basisdatei«Verzichten Sie auf die Verwendung von Verweisen zwischen multiplen ADMX-Dateien, da ansonsten die Gefahr besteht, Kreis-Verweise zu produzieren. Auch hier empfiehlt sich stattdessen die Erstellung einer ADMX-Basisdatei. Jeder verwendete Namensraum einer Richtlinie innerhalb einer ADMX-Datei muss eindeutig sein. CD-ROM Sie finden eine sehr detaillierte und ausführliche Beschreibung der ADMX-Syntax (in englischer Sprache) in dem 170 Seiten starken Group Policy ADMX Syntax Reference Guide auf der CD-ROM zum Buch im Ordner \Buch\Kap05.

22 232 Kapitel 5: Arbeiten mit administrativen Vorlagen Struktur der sprachunabhängigen ADMX-Datei Betrachtet man die ADMX-Datei schematisch, sieht diese wie folgt aus: Head (XML Declaration) Body (policydefinitions) policynamespaces-element resources-element supportedon categories-element policies-element Abbildung 5.12 Schematische Darstellung von ADMX-Dateien Im Kopf (Head) der ADMX-Datei befindet sich die allgemeine XML-Deklaration zur verwendeten Version und dem zugrunde liegenden Schema. Die Richtlinien, welche die ADMX-Datei enthalten soll, werden im Body in einem Paket policydefinitions zusammengefasst. Innerhalb der policydefinitions gibt es fünf zentrale Teile: policynamespaces Hier wird der Namensraum der ADMX-Datei definiert. Zusätzlich werden hier externe ADMX-Dateien aufgeführt, auf die später in der Datei verwiesen werden soll. resources Hier befindet sich der Verweis auf die assoziierte ADML-Datei supportedon In diesem optionalen Bereich können Ausdrücke für unterstützte Systeme hinterlegt werden, auf die später in den Richtlinien verwiesen werden kann. categories In diesem Bereich wird die Darstellungsstruktur, also Ordner und Unterordner, der Richtlinien im Gruppenrichtlinienverwaltungs-Editor festgelegt. policies Hier werden die eigentlichen Richtlinien definiert, die im Gruppenrichtlinienverwaltungs-Editor konfiguriert werden können. Die Struktur stellt sich syntaktisch wie folgt dar: <?xml version="1.0" encoding="utf-16"?> <policydefinitions revision="1.0" schemaversion="1.0"> <policynamespaces> </policynamespaces> Listing 5.1 Struktur von ADMX-Dateien

23 Erweitern der Standardvorlagen 233 <resources minrequiredrevision="1.0" /> <supportedon> <definitions> <definition> </definition> <definition> </definition> </definitions> </supportedon> <categories> <category> </category> <category> </category> </categories> <policies> <policy> </policy> <policy> </policy> </policies> </policydefinitions> Listing 5.1 Struktur von ADMX-Dateien (Fortsetzung) Struktur der sprachabhängigen ADML-Datei Die ADML-Datei ist ähnlich wie die ADMX-Datei aufgebaut. Head (XML Declaration) Body (policydefinitionresources) resources stringtable presentationtable Abbildung 5.13 Struktur der ADML-Datei Auch hier haben wir zunächst einen Header mit der allgemeinen XML-Deklaration. Im eigentlichen Body, dem policydefinitionresources-teil, befinden sich die eigentlichen Inhalte. Zum einen ein stringtable, in dem lokalisierte Texte für alle in der ADMX-Datei verwendeten Zeichenfolgen hinterlegt sind, und der presentationtable, in der die Texte und Strukturen für die erweiterten policy-elemente wie Listenfelder, Drehfelder und Kontrollkästchen definiert sind.

24 234 Kapitel 5: Arbeiten mit administrativen Vorlagen Die Struktur stellt sich syntaktisch wie folgt dar: <?xml version="1.0" encoding="utf-8"?> <policydefinitionresources revision="1.0" schemaversion="1.0"> <resources> <stringtable> <string> </string> <string> </string> </stringtable> <presentationtable> <presentation> </presentation> <presentation> </presentation> <presentation> </presentation> </presentationtable> </resources> </policydefinitionresources> Listing 5.2 Struktur einer ADML-Datei Der Header Jede ADMX- und ADML-Datei verfügt über einen Header, in dem allgemeine XML-Informationen hinterlegt werden. Dieser ist für administrative Vorlagen zwar nicht zwingend erforderlich, da die Dateien auch ohne Header vom Gruppenrichtlinienverwaltungs-Editor verarbeitet werden. Dennoch empfiehlt es sich einen Header zu verwenden, da dieser die Datei eindeutig als XML-Dokument identifiziert. Die Syntax für die XML-Deklaration ist: <?xml version="<version>" encoding="<zeichensatz>"?> version Hier wird die verwendete XML-Version angegeben. Da es im Moment lediglich die Version 1.0 gibt, ist dies auch der zu verwendende Wert. encoding Gibt den verwendeten Zeichensatz an. ADMX- und ADML-Dateien verwenden in der Regel den UTF-8-Zeichensatz. Der Header sieht also wie folgt aus: <?xml version="1.0" encoding="utf-8"?> Der Body Der Body wird über den entsprechenden <policydefinitions>- (ADMX) bzw. <policydefinitionsresources>- Tag eröffnet. Beide Tags enthalten einen Eintrag bezüglich der Revisionsnummer und der verwendeten ADMX-Schema-Version. Beide sind in der Regel»1.0«. Der letzte Tag der ADMX- und ADM-Datei schließt den Body über einem entsprechenden </policydefinitions>- bzw. </policydefinitionsresources>-tag. Für ADMX-Dateien sieht der Tag wie folgt aus: <policydefinitions revision="1.0" schemaversion="1.0"> </policydefinitions> Für ADML-Dateien sieht der Tag entsprechend wie folgt aus:

25 Erweitern der Standardvorlagen 235 <policydefinitionresources revision="1.0" schemaversion="1.0"> </policydefinitionresources> policynamespaces Eigener Name und externe ADMX-Dateien Mit policynamespaces-objekten wird zum einen ein eindeutiger Namensraum für die ADMX-Datei definiert, zum anderen Verweise auf andere ADMX-Dateien initialisiert. Generell dienen Namensräume der Navigation zwischen den ADMX-Dateien und werden in Verweisen zwischen diesen aufgegriffen. Den eigenen Namen legen Sie über einen target prefix fest. Der Präfix selbst könnte dabei auch als Kurzname bezeichnet werden, welcher eindeutig sein muss und für Verweise innerhalb des Dokuments verwendet werden kann. Der globale Namensraum, welcher über das Element namespace definiert wird, dient hingegen als langer Name und muss im gesamten System eindeutig sein. Für eigene ADMX-Dateien empfiehlt sich ein namespace in der Form Prefix.policies.ID. Die ID wäre in diesem Fall ein eindeutiger Wert, welcher beispielsweise der Firmenname oder eine Nummer sein könnte. Ein Beispiel für eine eigene ADMX-Datei wäre: <policynamespaces> <target prefix="acrobat" namespace="acrobat.policies.lmag" /> </policynamespaces> Zusätzlich können über das Element using prefix Verbindungen zu anderen ADMX-Dateien hergestellt werden, auf die in der ADMX-Datei über entsprechende Verweise referenziert werden kann. Gerade, wenn Sie beabsichtigen mehrere ADMX-Dateien für Ihre Umgebung zu erstellen, empfiehlt sich der Einsatz einer Basisdatei in der grundlegende Strukturen festgelegt werden und auf die dann in den entsprechenden weiteren ADMX-Dateien referenziert werden kann. Ebenso können Sie so auf bereits existierende Standard- ADMX-Dateien verweisen, um beispielsweise die Richtlinien direkt in dem entsprechenden Container zu erstellen. Eine Verbindung besteht aus zwei Teilen. Das Attribut using prefix enthält den Kurznamen, welcher innerhalb des Dokuments für Verweise verwendet wird. Zusätzlich muss der namespace angegeben werden, welcher den vollständigen Namen bzw. Pfad der Quell-ADMX-Datei enthält. Anhand der ADMX-Datei für Outlook 12 soll gezeigt werden, wie der eigene Name und Referenzen definiert werden können: <policynamespaces> <target prefix="outlk12" namespace="outlk12.office.microsoft.policies.windows" /> <using prefix="windows" namespace="microsoft.policies.windows" /> </policynamespaces> In diesem Beispiel könnte nun innerhalb der ADMX-Datei durch Verwendung des Schlüsselwortes windows auf die Elemente der Microsoft Windows Standard-Basis-ADMX-Datei Microsoft.Polcies.Windows (windows.admx) verwiesen werden, in der die Standard-Kategorien sowie die Ausdrücke für unterstützte Systeme und Applikationen hinterlegt sind. HINWEIS Am einfachsten können Sie dies aus der ADMX-Datei, auf die Sie referenzieren möchten, durch Kopieren des target prefix-objekts erreichen. Sie müssen anschließend in Ihrer ADMX-Datei lediglich den Ausdruck target prefix durch using prefix ersetzen.

26 236 Kapitel 5: Arbeiten mit administrativen Vorlagen resources Zusammenspiel mit der ADML-Datei Im resources-element werden die Anforderungen an die zugeordnete ADML-Datei definiert. Im speziellen handelt es sich um die Mindestversion. Aktuell verwendet Windows Vista die Version 1.0. Zukünftige Aktualisierungen können die Mindestversion erhöhen. Am Beispiel der administrativen Vorlage für Outlook 12 wäre dies: <resources minrequiredrevision="1.0" /> In der ADML-Datei sind die lokalisierten Texte zur Anzeige im Gruppenrichtlinienverwaltungs-Editor hinterlegt. In der ADMX-Datei selbst werden lediglich Platzhalter anstelle von ausformulierten Texten verwendet. Die Verweise auf die entsprechende ADML-Datei werden über entsprechende Verweise und Variablen vorgenommen. Ein typisches Beispiel aus der administrativen Vorlage für Outlook 12: <category name="l_toolsoptions" displayname="$(string.l_toolsoptions)"> Hier dient der Eintrag name="l_toolsoptions" als Sprungmarke auf die innerhalb der Datei verwiesen werden kann. Der Text, der im Gruppenrichtlinienverwaltungs-Editor angezeigt werden soll, wird im Element displayname definiert. Hier befindet sich ein Verweis auf den entsprechenden Eintrag in der assoziierten ADML-Datei. Ein typischer Verweis hat dabei die Form: $(typ.id) Das»$«-Zeichen leitet dabei den Verweis ein. In Klammern befindet sich die genaue Position des Textes. ADML-Dateien kennen zwei Typen von Elementen, auf die verwiesen werden kann: strings und presentation- Objekte. strings werden dabei für alle normalen Texte verwendet. Hierzu zählen Ordnernamen, Richtliniennamen, Erklärungstexte und Mindestanforderungen. presentation-objekte hingegen dienen der Definition von erweiterten Richtlinieneinstellungen, wie z.b. Listenfelder und Kontrollkästchen. typ Verweist auf den Bereich der ADML-Datei, in dem sich der entsprechende Eintrag befindet. string verweist zum Beispiel auf den Bereich stringtable. <id> Identifiziert den Eintrag innerhalb des Bereiches. Im Beispiel würde der entsprechende Text der <string id="l_toolsoptions"> angezeigt. Der entsprechende Eintrag in der stringtable der ADML-Datei zu dem category-beispiel sieht wie folgt aus: <string id="l_toolsoptions">extras Optionen...</string> Die id entspricht der Sprungmarke, wie sie auch in der ADMX-Datei verwendet wird. Zwischen den beiden Tags wird dann der anzuzeigende Text definiert. Anders als noch bei ADM-Dateien benötigen Sie keine besonderen Steuerzeichen um Zeilenumbrüche einzubauen. Stattdessen wird der Text genauso in der Richtlinie dargestellt wie dieser in ADML-Datei eingegeben worden ist. Problematisch stellen sich Sonderzeichen und Umlaute dar. Diese können standardmäßig nicht dargestellt werden und führen beim Einlesen der ADML-Datei in den Gruppenrichtlinienverwaltungs-Editor zu Fehlern. Um diese zu verwenden, müssen Sie entsprechende Formatierungen verwenden. Die Tabelle 5.2 zeigt, auf welche Weise Sie Zeichen angeben müssen, damit diese korrekt dargestellt werden:

27 Erweitern der Standardvorlagen 237 Gewünschtes Zeichen & ' XML-Formatierung & &apos < < > > " " Ä Ö Ü Ä Ö Ü ß Ä Ö Ü ä ö ü ß Tabelle 5.2 Sonderzeichen und deren XML-Entsprechung HINWEIS Ausführliche Informationen zu presentationtable- und presenation-elementen finden Sie im Abschnitt»Erweiterte Oberfläche zur Konfiguration der Richtlinie«später in diesem Kapitel. supportedon Definieren der Anforderungen In diesem Bereich können Sie Anforderungen für Richtlinien vordefinieren, auf welche Sie später in den Richtlinien selbst verweisen können. Die supportedon-informationen haben informativen Charakter und helfen bei der Verwaltung von Richtlinien zu identifizieren, ob die Richtlinie auch für meine Systeme gültig ist. Microsoft verwendet das supportedon-element (siehe Abbildung 5.14 oben links), um beispielsweise zu kennzeichnen, von welchen Betriebssystemen Einstellungen übernommen werden. Abbildung 5.14 Richtlinie mit supportedon-eintrag

28 238 Kapitel 5: Arbeiten mit administrativen Vorlagen Der Bereich dient der Definition von eigenen Texten, auf die Sie in den Richtlinien verweisen können. Innerhalb des supportedon-bereichs werden alle Definitionen hinterlegt, auf die Sie verweisen möchten. Die Syntax sieht wie folgt aus: <supportedon> <definitions> <definition name="<name>" displayname="$(string.id)"/> </definitions> </supportedon> Die Tags <supportedon> und </supportedon> öffnen bzw. schließen diesen Bereich der ADMX-Datei. Die Anforderungen selbst werden im Bereich definitions zusammengefasst. Auch dieser wird durch einen einleitenden <definitions>- und einen schließenden </definitions>-tag gekennzeichnet. Jede Anforderung wird über einen <definition>-tag definiert. Dabei besteht ein <definition>-tag aus den beiden Werten: name Definiert den Namen, welcher auch als Sprungmarke fungiert displayname Enthält den Verweis auf das entsprechende Element in der StringTable der korrespondierenden ADML-Datei Alternativ können Sie auch direkt auf die vorgegebenen Microsoft Standard-Texte innerhalb der windows.admx-datei verweisen oder auf entsprechende Einträge einer eigenen Basis-Datei. In diesen Fällen benötigen Sie keinen eigenen supportedon-bereich in der ADMX-Datei. HINWEIS Nähere Informationen zur Erstellung einer Basisdatei finden Sie im Abschnitt»Erstellen einer Basisdatei«später in diesem Kapitel. categories Erstellen einer Struktur für Richtlinien Bei den Kategorien handelt es sich um die Ordner, die in einem Gruppenrichtlinienobjekt unterhalb der administrativen Vorlagen angezeigt werden. Sie können eigene Kategorien erstellen oder sich auf die von Microsoft vorgegebenen beziehen. Es empfiehlt sich allerdings, eigene Richtlinien im Bereich der administrativen Vorlagen auch durch eine eigene Kategorie als Selbstersteller zu kennzeichnen. Im Bereich categories werden alle Ordner und Unterordner erstellt, welche Sie in den Richtlinien verwenden möchten. Im Bereich der Richtlinien selbst werden lediglich Verweise auf die entsprechenden Ordner im categories-teil verwendet. Sollten Sie beabsichtigen mehrere eigene ADMX-Vorlagen zu erstellen, in denen gleiche Kategorien verwendet werden, empfiehlt sich der Einsatz einer eigenen ADMX-Basisdatei, auf die in den entsprechenden Richtlinien referenziert wird. Die Definition der Ordner wird durch einen einleitenden <categories> und einen schließenden </categories> Tag eingeschlossen. Am Beispiel der administrativen Vorlage für Outlook 2007 gestaltet sich dies so: <categories> <category name="l_microsoftofficeoutlook12" displayname="$(string.l_microsoftofficeoutlook12)"/> <category name="l_toolsoptions" displayname="$(string.l_toolsoptions)"> <parentcategory ref="l_microsoftofficeoutlook12" /> </category> </categories>

29 Erweitern der Standardvorlagen 239 Grundsätzlich wird entsprechend der Abbildung 5.15 zwischen zwei category-typen unterschieden: Hauptkategorien und Unterkategorien. Eine Hauptkategorie besteht grundsätzlich aus den Informationen name und displayname: name Definiert das eindeutige Präfix des Containers, welcher in anderen Tags der ADMX-Datei als Sprungmarke verwendet werden kann. displayname Definiert den Anzeigenamen des Containers im Gruppenrichtlinienverwaltungs-Editor. Hier wird ein Verweis zum entsprechenden Objekt der ADML-Datei verwendet. Eine Unterkategorie enthält zusätzlich einen Tag parentcategory, wo ein Verweis auf die Kategorie eingefügt wird, unter der die Kategorie angezeigt werden soll. Der Parameter ref dient dabei der Angabe der Sprungmarke. Innerhalb der gleichen Datei wird lediglich der Name des Präfixes angegeben. Befindet sich diese in einer anderen ADMX-Datei, muss zusätzlich das Präfix der Zieldatei mit angegeben werden. Beispielsweise windows:network. Verweise werden immer in Anführungszeichen gesetzt. Wenn Sie Verweise auf externe ADMX-Dateien vornehmen, beachten Sie bitte, dass Sie diese auch in dem Bereich policynamespaces angegeben haben. Abbildung 5.15 Haupt- und Unterkategorien der Outlook 2007-Vorlage ACHTUNG Wenn Sie Richtlinien in den Original-Ordnern der Gruppenrichtlinien erstellen möchten, verweisen Sie auf die entsprechenden Kategorien der Original-Dateien. Wenn Sie die gleichen Namen in einer individuellen Datei selbst verwenden, erhalten Sie doppelte Ordner. policies Die eigentlichen Richtlinien Im policies-part der ADMX-Datei befinden sich die eigentlichen Richtlinien und Einstellungen, die über den Gruppenrichtlinienverwaltungs-Editor geändert werden können. Der Gruppenrichtlinienverwaltungs-Editor unterstützt eine ganze Reihe von unterschiedlichen Elementen, die in einer Richtlinie verwendet werden

30 240 Kapitel 5: Arbeiten mit administrativen Vorlagen können, wie z.b. Listenfelder, Textfelder, Drehfelder und Kontrollkästchen. Diese sind allerdings optional und werden später in diesem Abschnitt beschrieben. Zunächst werfen wir einen Blick auf die Standardelemente. Alle Richtlinien werden von einem einleitenden <policies> und einem schließenden </policies> Tag umfasst. Innerhalb dieses Bereiches können dann die einzelnen Richtlinien angegeben werden. Jede Richtlinie wird über einen <policy>-tag definiert. Der <policy>-tag selbst enthält die folgenden Optionen: <policy name="<präfix>" class="<klasse>" displayname="$(typ.id)" explaintext="$(typ.id)" key="<registrypath>" valuename="<registrykey>"> präfix Eindeutiger Name der Richtlinie, welcher auch als Sprungmarke dient class Zuordnung der Richtlinie zu Computer- bzw. Benutzerkonfiguration. Legt außerdem den Registrierungspfad für die Richtlinie auf HKEY_LOCAL_MACHINE bzw. HKEY_CURRENT_USER fest. explaintext Verweis auf den entsprechenden Erklärungstext in der ADML-Datei. Über die Erklärungstexte können Hintergründe für die Richtlinie gegeben werden. Zudem dienen sie der Nachhaltigkeit von Änderungen. Die Verwendung von explaintext ist optional. Eine gute Erklärung sollte über folgende Informationen verfügen: Welchen Zweck hat die Richtlinie? Was passiert, wenn die Richtlinie auf Aktiviert, Deaktiviert und wieder auf den Status Nicht konfiguriert gesetzt wird? Welche Besonderheiten gibt es bei der Richtlinie zu beachten? Welche Ansprechpartner können eventuell hilfreich sein? key Registrierungsschlüssel, welcher über die Richtlinie geändert werden soll. Die Angabe erfolgt ohne HKLM bzw. HKCU, da diese bereits durch die Klasse vorgegeben sind. valuename Registrierungswert, welcher innerhalb des Schlüssels durch die Richtlinie konfiguriert werden soll. Ein entsprechender Eintrag aus der administrativen Vorlage von Outlook 12 würde beispielsweise wie folgt aussehen: <policy name="l_newmaildesktopalert" class="user" displayname="$(string.l_newmaildesktopalert)" explaintext="$(string.l_newmaildesktopalertexplain)" key="software\policies\microsoft\office\12.0\outlook\preferences" valuename="newmaildesktopalerts"> Damit die Richtlinie in einem Ordner des Gruppenrichtlinienverwaltungs-Editors angezeigt werden kann, muss eine entsprechende Zuordnung über einen <parentcategory>-tag erfolgen. Die Syntax ist wie folgt: <parentcategory ref="<zielkategorie>" /> Zielkategorie Über die Zielkategorie verweisen Sie über einen entsprechenden Eintrag in derselben ADMX- oder in einer anderen ADMX-Datei. Befindet sich der Eintrag im categories-bereich der gleichen Datei, geben Sie lediglich den Namen dieser an, wie zum Beispiel L_MicrosoftOfficeOutlook12. Ist die Kategorie in einer anderen Datei definiert, müsste zudem das Präfix der Quelle mit angegeben werden, beispielsweise windows:l_microsoftofficeoutlook12.

31 Erweitern der Standardvorlagen 241 Möchten Sie der Richtlinie einen Hinweis auf unterstützte Systeme hinzufügen, können Sie dies über einen <supportedon>-tag erreichen. Die Syntax ist wie folgt: <supportedon ref="<zieltext> " /> Zieltext Über den Zieltext verweisen Sie über einen entsprechenden Eintrag im supportedon-bereich in derselben ADMX- oder einer anderen ADMX-Datei. Befindet sich der Eintrag in der gleichen Datei, geben Sie lediglich den Namen der entsprechenden Definition an, wie Z.B SUPPORTED_WindowsVista. Ist die Kategorie in einer anderen Datei definiert, müsste zudem das Präfix der Quelle mit angegeben werden, beispielsweise windows:supported_windowsvista. Damit haben Sie alle benötigten Informationen in der ADMX-Datei zusammen, um eine einfache Richtlinie zu erstellen, die entsprechend der Abbildung 5.16 über die Optionen Nicht konfiguriert, Aktiviert und Deaktiviert verfügt. Wird diese auf den Wert Aktiviert gesetzt, wird der definierte Registrierungsschlüssel auf den Wert 1 gesetzt. Wenn Sie die Richtlinie deaktivieren, wird der Registrierungswert wieder gelöscht. Abbildung 5.16 Einfache Richtlinie zum Aktivieren und Deaktivieren Vorgeben von Werten für Aktivierungen und Deaktivierungen Sie können in der ADMX-Datei auch abweichendes Verhalten für das Aktivieren und Deaktivieren der Richtlinie definieren. Hierzu stehen Ihnen die Tags <enabledvalue> und <disabledvalue> zur Verfügung. Mit jedem dieser Tags kann eine bestimmte Aktion konfiguriert werden. Es müssen nicht beide Tags verwendet werden, wenn nur eine der beiden Aktionen vom Standard abweichen soll. Werte für das Aktivieren der Richtlinie werden über den enabledvalue definiert. Dieser hat die Syntax: <enabledvalue> <delete /> <decimal> </decimal> <string> </string> </enabledvalue>

32 242 Kapitel 5: Arbeiten mit administrativen Vorlagen Analog verhält es sich mit disabledvalue für das Deaktivieren der Richtlinie: <disabledvalue> <delete /> <decimal> </decimal> <string> </string> </disabledvalue> Bei der Konfiguration von enabledvalue und disabledvalue entscheiden Sie sich zwischen den Optionen: <delete /> Löscht den zu konfigurierenden Wert aus der Registrierung. <decimal> </decimal> Der Wert wird als Zahlenwert in die Registrierung geschrieben. Standardmäßig wird dieser als REG_DWORD gespeichert. Der folgende Eintrag würde beispielsweise den Registrierungswert auf 5 setzen: <decimal value="5"/>. <string> </string> Dient der Angabe einer Zeichenfolge, welche als REG_SZ in die Registrierung geschrieben wird. So würde beispielsweise der folgende Ausdruck den Registrierungswert mit»hallo«füllen: <string>hallo</string>. Konfigurieren von multiplen Werten durch Aktivierung/Deaktivierung einer Richtlinie Wenn Sie mehr als einen Registrierungswert auf einmal ändern möchten, können Sie dies durch Verwendung des enabledlist- bzw. disabledlist-tags. Diese bieten im Gegensatz zum enabledvalue die Möglichkeit, mehrere Aktionen miteinander zu kombinieren, wenn Sie die Richtlinie aktivieren bzw. deaktivieren. Die Verwendung von enabledlist erzwingt nicht gleichzeitig auch die Verwendung von disabledlist. Die Syntax von enabledlist bzw. disabledlist ist wie folgt: <enabledlist defaultkey="<platzhalter für Registry-Pfad>"> <item> </item> <item> </item> </enabledlist> <disabledlist defaultkey="<platzhalter für Registry-Pfad>"> <item> </item> <item> </item> </disabledlist> Das entscheidende Element hier ist die Itemlist. Innerhalb der Items werden die zu verändernden Registrierungsschlüssel definiert. Befinden sich alle zu verändernden Registrierungsschlüssel im gleichen Registrierungspfad, können Sie im enabledlist- bzw. disabledlist-element einen defaultkey mitgeben. Andernfalls empfiehlt sich die Angabe der zu verändernden Schlüssel direkt in den item-objekten. Die Syntax eines item- Elements lautet wie folgt: <item key="<platzhalter für Registry-Pfad>" valuename="<platzhalter für Registry-Wert"> <value> <delete /> <decimal> </decimal> <string> </string> </value> </item>

33 Erweitern der Standardvorlagen 243 Innerhalb des item-tags selbst kann sowohl der Pfad und Wert, der verändert werden soll, angegeben werden. Den Wert selbst konfigurieren Sie analog zu enabledvalue über einen value-tag. Im folgenden Beispiel sind alle Teile zusammengebracht: <enabledlist key="software\policies\testlist"> <item key="software\policies\testlist" valuename="testliste1"> <value> <string>listenwert1</string> </value> </item> <item key="software\policies\testlist" valuename="testliste2"> <value> <decimal value="11" /> </value> </item> <item key="software\policies\testlist2" valuename="testliste2wert"> <value> <string>neue Liste</string> </value> </item> </enabledlist> Listing 5.3 Auslösen mehrerer Aktionen beim Aktivieren einer Richtlinie Erweiterte Oberfläche zur Konfiguration der Richtlinie In den meisten Fällen reichen die bisher gezeigten Parameter für die Erstellung von ADMX-Dateien für die eigene Umgebung aus. Allerdings bieten Richtlinien weit mehr Optionen zur Darstellung und Konfiguration von Richtlinien. So können Sie neben einfachen Aktivieren-/Deaktivieren-Richtlinien auch Texteingaben, Listenfelder, Drehfelder und Kontrollkästchen einbauen. Alle zusätzlichen Oberflächenelemente werden über das presentations-element gesteuert, welches wir Ihnen im Detail vorstellen möchten. Das presentations-element besteht grundsätzlich aus zwei Komponenten in der ADMX-Datei und einer zugeordneten Komponente in der ADML-Datei. Die Verwendung der erweiterten Oberflächenoptionen erfolgt über einen Aufruf innerhalb des <policy>-tags. Hier wird über den folgenden Eintrag die Zuordnung der verwendeten Oberflächenoption(en) zu einem entsprechenden Eintrag der ADML-Datei, dem so genannten presentationtable, vorgenommen. <policy name="<präfix>" class="<klasse>" displayname="$(typ.id)" explaintext="$(typ.id)" key="<registrypath>" valuename="<registrykey>" presentation="$(presentation.id)> Der entscheidende Eintrag hier ist presentation="$(presentation.id), wobei die»id«durch den entsprechenden Namen des presentation-objekts in der ADML-Datei zu ersetzen ist. Die eigentliche Konfiguration erfolgt über eigenständige Elements-Objekte. <elements> <boolean> </boolean> <decimal> </decimal> <text> </text> <enum> </enum> <list> </list> </elements>

34 244 Kapitel 5: Arbeiten mit administrativen Vorlagen Texteingabefelder <text> Sie können auf der Registerkarte Einstellung der Richtlinie eine Texteingabe hinzufügen. Die Eingabe wird dann im assoziierten Registrierungswert abgelegt. Die Syntax für Textfelder ist: <text id="<platzhalterid>" clientextension="<guid>" key="<regkey>" valuename="<regwert>" required="true false" maxlength="<maxlength>" expandable="true false" soft="true false" /> id Dieser Wert entspricht dem assoziierten Eintrag in der ADML-Datei auf den hier verwiesen wird. (Erforderlich) clientextension Dient der Referenzierung an andere clientseitige Erweiterungen, die für die Verarbeitung der Richtlinie herangezogen werden. Die clientseitige Erweiterung wird über ihre GUID angegeben. (Optional) Weitere Informationen zu clientseitigen Erweiterungen finden Sie in Kapitel 7. key Definiert den Registrierungsschlüssel, in dem sich der zu ändernde Wert befindet. (Optional) valuename Definiert den Registrierungswert, in dem die Eingabe gespeichert wird. Texteingaben führen zu REG_SZ-Registrierungsschlüsseln. (Erforderlich) required Definiert, ob bei Aktivierung der Richtlinie ein Wert eingegeben werden muss. Standardmäßig werden auch leere Eingaben zugelassen. (Optional) maxlength Mit diesem Attribut kann eine maximale Anzahl von Zeichen festgelegt werden, die in das Textfeld eingegeben werden kann. (Optional) expandable Bei Angabe des Parameters true wird der Registrierungswert als REG_EXPAND_SZ gespeichert, wodurch auch erweiterte Einträge, wie beispielsweise Umgebungsvariablen, unterstützt werden. (Optional) soft Über den Wert true kann erreicht werden, dass ein bereits existierender Wert in der Registrierung nicht durch diese Richtlinie überschrieben werden kann. Standardmäßig ist dies möglich. (Optional) In der assoziierten ADML-Datei müssen Sie zudem die Darstellung des Elements definieren. Die Syntax in der ADML-Datei ist wie folgt: <textbox refid="<platzhalterid>"> <label> </label> <defaultvalue> </defaultvalue> </textbox> refid Textmarke, auf die in der ADMX-Datei verwiesen wird label Zwischen den label-tags können Sie den Text angeben, der vor dem Eingabefeld angezeigt wird defaultvalue Dient der Angabe eines angezeigten Standardwerts. Die Verwendung ist optional. Das in Abbildung 5.17 dargestellte Textfenster wird über folgende Syntax erzeugt:

35 Erweitern der Standardvorlagen 245 <policy name="test" class="machine" displayname="$(string.test_dis)" explaintext="$(string.test_exp)" key="software\policies\test" presentation="$(presentation.testtextbox)> <parentcategory ref="cat_own" /> <supportedon ref="windows:supported_windowsvista" /> <elements> <text id="testtextbox" valuename="textfeld" required="true" /> </elements> </policy> In der ADML-Datei sehen die Entsprechungen wie folgt aus: <presentation id="testtextbox"> <text>dies ist eine Einleitung</text> <text></text> <textbox refid="testtextbox"> <label>eingabe: </label> </textbox> </presentation> Listing 5.4 Erstellen eines Textfeldes HINWEIS Die string-variablen sind in diesem Beispiel von untergeordnetem Interesse und daher nicht aufgeführt. Abbildung 5.17 Richtlinie mit Texteingabe-Feld Zahlenfelder <decimal> Mithilfe des <decimal>-elements können Sie Zahlenfelder zur Konfiguration der Richtlinie erzeugen. Die Syntax für Zahlenfelder ist analog zu den Textfeldern: <decimal id="<platzhalterid>" clientextension="<guid>" key="<regkey>" valuename="<regname>" required="true false" minvalue="<minvalue>" maxvalue="<maxvalue>" storeastext="true false" soft="true false" />

36 246 Kapitel 5: Arbeiten mit administrativen Vorlagen Zusätzlich zu den bereits von der Texteingabe bekannten Objekten können bei Zahlenfeldern folgende Attribute definiert werden: maxvalue Mit diesem Attribut kann eine Obergrenze für den Zahlenwert festgelegt werden. (Optional) minvalue Mit diesem Attribut kann ein Unterwert für den Zahlenwert festgelegt werden. (Optional) stroreastext Bei Angabe des Parameters true wird der Registrierungswert als REG_ SZ und nicht als REG_DWORD gespeichert. (Optional) In der assoziierten ADML-Datei müssen Sie zudem die Darstellung des Elements definieren. Die Syntax in der ADML-Datei ist wie folgt: <decimaltextbox refid="<platzhalterid>" defaultvalue="<standardwert>" spin="true false" spinstep="<drehintervall>">anzeigename:</decimaltextbox> Zusätzlich zu den bereits von der Texteingabe bekannten Objekten können bei Zahlenfeldern folgende Attribute definiert werden: spin Wird der Wert auf true gesetzt, wird in der Richtlinie ein Drehfeld zur Eingabe angezeigt. Andernfalls wird eine Texteingabe verwendet. (Optional) spinstep Über spinstep kann ein Intervall definiert werden, welches bei Verwendung eines Drehfeldes die Sprünge nach oben und unten bestimmt. (Optional) Anzeigename An dieser Stelle kann der Text definiert werden, der vor dem Eingabefeld angezeigt wird. (Optional) Das in Abbildung 5.18 dargestellte Drehfeld wird über folgende Syntax erzeugt: <policy name="test" class="machine" displayname="$(string.test_dis)" explaintext="$(string.test_exp)" key="software\policies\test" presentation="$(presentation.testnumericelement)"> <parentcategory ref="cat_own" /> <supportedon ref="windows:supported_windowsvista" /> <elements> <decimal id="testnumericelement" valuename="numeric" required="true" /> </elements> </policy> Die Entsprechung in der ADML-Datei sieht dann wie folgt aus: <presentation id="testnumericelement"> <text>dies ist eine Einleitung</text> <text></text> <decimaltextbox refid="testnumericelement" spin="true" spinstep="5">geben Sie den Zahlenwert hier ein: </decimaltextbox> </presentation> Listing 5.5 Erstellen eines Drehfeldes

37 Erweitern der Standardvorlagen 247 Abbildung 5.18 Richtlinie mit Drehfeld Kontrollkästchen <boolean> Mithilfe des <boolean>-elements können Sie Kontrollkästchen in der Richtlinie erzeugen. Die Syntax für Kontrollkästchen lautet: <boolean id="<platzhalterid>" clientextension="<guid>" key="<regkey>" valuename="<regwert>"> <truevalue> </truevalue> <falsevalue> </falsevalue> <truelist> </truelist> <falselist> </falselist> </boolean> Die Werte id, clientextension, key und valuename sind analog zu Texteingabefeldern. Soll über das Kontrollkästchen lediglich ein Registrierungswert editiert werden, verwenden Sie truevalue bzw. falsevalue. truevalue definiert den Wert, wenn das Kontrollkästchen aktiviert wird. Die Syntax der beiden ist analog zueinander: <truevalue> <delete /> <decimal> </decimal> <string> </string> </truevalue> Bei der Konfiguration von truevalue und falsevalue entscheiden Sie sich zwischen den Optionen: <delete /> Löscht den zu konfigurierenden Wert aus der Registrierung. <decimal> </decimal> Der Wert wird als Zahlenwert in die Registrierung geschrieben. Standardmäßig wird dieser als REG_DWORD gespeichert. Der folgende Eintrag würde beispielsweise den Registrierungswert auf 5 setzen: <decimal value="5"/>

38 248 Kapitel 5: Arbeiten mit administrativen Vorlagen <string> </string> Dient der Angabe einer Zeichenfolge, welche als REG_SZ in die Registrierung geschrieben wird. So würde beispielsweise der folgende Ausdruck den Registrierungswert mit»hallo«füllen: <string>hallo</string> Möchten Sie hingegen mehrere Registrierungsänderungen über das Kontrollkästchen vornehmen, können Sie truelist bzw. falselist verwenden. Die Syntax lautet wie folgt: <truelist defaultkey="<regkey>"> <item> </item> <item> </item> </truelist> Das entscheidende Element hier ist die Itemlist. Innerhalb der Items werden die zu verändernden Registrierungsschlüssel definiert. Befinden sich alle zu verändernden Registrierungsschlüssel im gleichen Registrierungspfad, können Sie im truelist- bzw. falselist-element einen defaultkey mitgeben, andernfalls empfiehlt sich die Angabe der zu verändernden Schlüssel direkt in den item-objekten. Die Syntax eines item-elements ist wie folgt: <item key="<regkey>" valuename="<regwert"> <value> <delete /> <decimal> </decimal> <string> </string> </value> </item> In der assoziierten ADML-Datei müssen Sie zudem die Darstellung des Kontrollkästchens definieren. Die Syntax in der ADML-Datei ist wie folgt: <checkbox refid="<platzhalterid>" defaultchecked="true false">anzeigename:</ checkbox > Zusätzlich zu den bereits von der Texteingabe bekannten Objekten können bei Kontrollkästchen folgende Attribute definiert werden: defaultchecked Gibt an, ob das Kontrollkästchen bei Aktivierung der Richtlinie bereits aktiviert ist. Standardmäßig sind Kontrollkästchen deaktiviert. (Optional) Anzeigename An dieser Stelle kann der Text definiert werden, der vor dem Kontrollkästchen angezeigt wird. (Optional)

39 Erweitern der Standardvorlagen 249 Das in Abbildung 5.19 dargestellte Kontrollkästchen wird über folgende Syntax erzeugt: <policy name="test" class="machine" displayname="$(string.test_dis)" explaintext="$(string.test_exp)" key="software\policies\test" valuename="checkboxpol" presentation="$(presentation.checkbox)"> <parentcategory ref="cat_own" /> <supportedon ref="windows:supported_windowsvista" /> <elements> <boolean id="testcheckbox" valuename="checkbox"> <truevalue> <decimal value="5" /> </truevalue> <falsevalue> <decimal value="10" /> </falsevalue> </boolean> </elements> </policy> Die Entsprechung der ADML-Datei ist dann wie folgt: <presentation id="checkbox"> <text>dies ist eine Einleitung</text> <text></text> <checkbox refid="testcheckbox" defaultchecked="true">bitte klicken Sie hier: </checkbox> </presentation> Listing 5.6 Erzeugen einer Richtlinie mit Kontrollkästchen HINWEIS Beachten Sie den Eintrag valuename="checkboxpol" direkt im policy-tag. In diesem Beispiel wird dieser Registrierungswert verwendet, um den Status der Richtlinie zu speichern. Würde dieser nicht existieren und lediglich der Registrierungswert im boolean-tag verwendet, würde die Richtlinie bei Aktivierung und nicht gesetzten Häkchen im Kontrollkästchen automatisch auf Deaktiviert springen. Dies hat zwar keine funktionale Auswirkung, kann aber zu Verwirrung führen. Abbildung 5.19 Richtlinie mit Kontrollkästchen

40 250 Kapitel 5: Arbeiten mit administrativen Vorlagen Listenfelder <list> Listenfelder sind, anders als die vorherigen Elemente, in der Lage, beliebige Registrierungseinträge inklusive des Namens und Werts zu erzeugen. Ein Listenfeld verfügt lediglich über eine Anzeigen-Schaltfläche, welche zur Angabe der einzelnen Registrierungswerte dient. Grundsätzlich können in einem Listenfeld REG_SZund REG_EXPAND_SZ-Werte erstellt werden. Die Syntax für Listenfelder ist: <list id="<platzhalterid>" clientextension="<guid>" key="<regkey>" valueprefix="<regname>" additive="true false" expandable="true false" explicitvalue="true false" > </list> Zusätzlich zu den bereits von der Texteingabe bekannten Objekten können bei Zahlenfeldern folgende Attribute definiert werden: explicitvalue Durch diese Option bekommen Sie die Möglichkeit, sowohl den Namen als auch den Wert für die neuen Registrierungseinträge zu definieren. Das Eingabefenster verfügt hierzu über ein zweiteiliges Eingabefenster. valueprefix valueprefix ist neben dem Standard und der Option explicitvalue die dritte Variante, wie Registrierungsinformationen mit einem Listenfeld hinzugefügt werden können. Bei dieser Variante wird über valueprefix ein Wert angegeben, welcher für die einzelnen Registrierungswerte als Name verwendet wird. Zusätzlich wird diesem Namen eine Zahl hinzugefügt, die für jeden Eintrag um eins erhöht wird. Der Eintrag valueprefix="wallpaper" würde beispielsweise die Registrierungseinträge Wallpaper1, Wallpaper2, Wallpaper3, usw. erzeugen. Über das Listenfeld werden lediglich die zu verwendenden Werte für die einzelnen Einträge definiert. valueprefix ergänzt sich nicht mit der Option explicitvalue. additive Die vorhandenen Werte des Registrierungspfades werden nicht gelöscht, bevor neue hinzugefügt werden. Über die Schaltfläche Anzeigen werden nun auch die bereits vorhandenen Werte angezeigt und können auf diesem Wege editiert werden. In der assoziierten ADML-Datei müssen Sie zudem die Darstellung des Elements definieren. Die Syntax in der ADML-Datei ist wie folgt: <listbox refid="<platzhalterid>">anzeigename: </listbox> Das in Abbildung 5.20 dargestellte Listenfeld wird über folgende Syntax erzeugt: <policy name="test" class="machine" displayname="$(string.test_dis)" explaintext="$(string.test_exp)" key="software\policies\test" valuename="listboxpol" presentation="$(presentation.listbox)> <parentcategory ref="cat_own" /> <supportedon ref="windows:supported_windowsvista" /> <elements> <list id="testlistbox" key="software\policies\test" valueprefix="listeintrag" aditive="true" expandable="true" /> </elements> </policy>

41 Erweitern der Standardvorlagen 251 In der ADML-Datei sehen die Entsprechungen wie folgt aus: <presentation id="listbox"> <text>dies ist eine Einleitung</text> <text></text> <listbox refid="testlistbox">bitte klicken Sie hier:</listbox> </presentation> Listing 5.7 Erzeugen einer Richtlinie mit einem Listenfeld Abbildung 5.20 Richtlinie mit einem Listenfeld Dropdownlistenfeld <enum> Mithilfe des <enum>-elements können Sie Dropdownlistenfelder in der Richtlinie erzeugen, in denen aus vorgegebenen Elementen der Liste der gewünschte Wert ausgewählt werden kann. Die Syntax für Dropdownlistenfelder ist: <enum id="<platzhalterid>" clientextension="<guid>" key="<regkey>" valuename="<regwert>" required="true false" > <item> </item> </enum > Zusätzlich zu den bereits von der Texteingabe bekannten Attributen definieren Sie bei Listenfeldern die zur Auswahl stehenden Elemente. Hierzu geben Sie die Objekte wie folgt an: <item displayname="$(string.textmarke)"> <value> </value> <valuelist> <item> </item> <item> </item> </valuelist> </item>

42 252 Kapitel 5: Arbeiten mit administrativen Vorlagen Der displayname verweist auf den entsprechenden Eintrag in der stringtable der zugehörigen ADML-Datei zur Darstellung des Listenelements. Die zu konfigurierenden Werte bei Auswahl des Listenelements werden über value- oder valuelist-elemente konfiguriert. Informationen zur Verwendung dieser Objekte finden Sie im Abschnitt»Vorgeben von Werten für Aktivierungen und Deaktivierungen«in diesem Kapitel. In der assoziierten ADML-Datei müssen Sie zudem die Darstellung des Elements definieren. Die Syntax in der ADML-Datei ist wie folgt: <dropdownlist refid="<placeholderid>" nosort="true false" defaultitem="<placeholdernumericvalue>">anzeigename: </ dropdownlist> Zusätzlich zu den bereits von der Texteingabe bekannten Objekten können bei Zahlenfeldern folgende Attribute definiert werden: nosort Wird der Wert auf true gesetzt, werden die Einträge der Liste nicht alphabetisch sortiert. (Optional) defaultitem Mittels defaultitem kann das Listenelement angegeben werden, das standardmäßig angezeigt wird, wenn die Richtlinie aktiviert wird. (Optional) Anzeigename An dieser Stelle kann der Text definiert werden, der vor dem Eingabefeld angezeigt wird. (Optional) Das in Abbildung 5.21 zu sehende Dropdownlistenfeld wird über folgende Syntax erzeugt: <policy name="test" class="machine" displayname="$(string.test_dis)" explaintext="$(string.test_exp)" key="software\policies\test" presentation="$(presentation.dropdownlist)"> <parentcategory ref="cat_own" /> <supportedon ref="windows:supported_windowsvista" /> <elements> <enum id="testdropdown" valuename="dropdown" required="true"> <item displayname="$(string.listitem1)"> <value> <decimal value="5" /> </value> </item> <item displayname="$(string.listitem2)"> <value> <decimal value="10" /> </value> </item> <item displayname="$(string.listitem3)"> <value> <decimal value="15" /> </value> </item> </enum> </elements> </policy>

43 Erweitern der Standardvorlagen 253 In der ADML-Datei sehen die Entsprechungen wie folgt aus: <string id="listitem1">erster Wert</string> <string id="listitem1">zweiter Wert</string> <string id="listitem1">dritter Wert</string> <presentation id="dropdownlist"> <text>dies ist eine Einleitung</text> <text></text> <dropdownlist refid="testtestdropdown" defaultitem="2">treffen Sie Ihre Wahl: </dropdownlist> </presentation> Listing 5.8 Erzeugen einer Richtlinie mit Dropdownlistenfeld Abbildung 5.21 Richtlinie mit Dropdownlistenfeld Erstellen einer Basisdatei Wenn Sie beabsichtigen mehrere ADMX-Dateien zu erstellen, sollten Sie über den Einsatz einer Basisdatei nachdenken. In der Basisdatei können Sie dann Elemente definieren, die Sie in den eigentlichen ADMX- Dateien durch Referenzieren dann aufrufen. Auf diesem Weg können Sie an einer zentralen Stelle die Ordner und Mindestanforderungen verwalten. Die eigentlichen Richtlinien selbst stehen dann in kleinen individuellen ADMX-Dateien. Auf diesem Wege reduzieren Sie den eigenen Arbeitsaufwand und verhindern, dass Ordner im Gruppenrichtlinienverwaltungs-Editor doppelt angezeigt werden. Zu einer Basis-ADMX-Datei gehört auch eine entsprechende ADML-Datei. Die Basisdatei selbst unterscheidet sich in Syntax und Struktur nicht von anderen ADMX-Dateien außer, dass nicht alle Bereiche verwendet werden. Wichtig für eine Basisdatei ist die Definition der Namensräume. Genau wie bei einer einfachen ADMX-Datei müssen Sie einen eindeutigen Namensraum festlegen, wie z.b.:

44 254 Kapitel 5: Arbeiten mit administrativen Vorlagen <policynamespaces> <target prefix="base" namespace="base.policies.gpo2008" /> </policynamespaces> In den individuellen ADMX-Dateien, in denen Sie auf supportedon- und category-elemente der Basisdatei zugreifen möchten, müssen Sie lediglich zwei Schritte durchführen. Zum einen stellen Sie eine Verbindung in den policynamespaces zu der Basisdatei her. Dies erfolgt über den using-tag, wie im folgenden Beispiel zu sehen: <policynamespaces> <target prefix="<name>" namespace="<name>.policies.gpo2008" /> <using prefix="base" namespace="base.policies.gpo2008" /> </policynamespaces> Anschließend können Sie an den gewünschten Stellen an Inhalte der Basisdatei verweisen. Hierzu verwenden Sie anstelle der lokalen Sprungmarke eine Referenzierung an die Basisdatei. Dies wird über die folgende Syntax erreicht: Ref="Dateiname.Sprungmarke" Einen Verweis auf den String mit der ID»SUP_AcrobatReader«würde in unserem Beispiel wie folgt aussehen: <supportedon ref="base:sup_acrobatreader" /> Erstellen von Vorlagen mit dem ADMX-Migrator Die Firma Fullarmor hat in Zusammenarbeit mir Microsoft den ADMX-Migrator entwickelt, welcher kostenfrei von der Microsoft-Website ( sowie der Internetpräsenz von Fullarmor ( heruntergeladen werden kann. CD-ROM Sie finden den ADMX-Migrator auch auf der CD-ROM zum Buch im Ordner \Software\ADMX-Migrator. Der ADMX-Migrator bietet zwei Kernfunktionalitäten an. Zum einen bietet er die Möglichkeit, mithilfe einer grafischen Oberfläche ohne tief greifendes Verständnis von XML eigene administrative Vorlagen zu erstellen. Zum anderen kann der ADMX-Migrator auch alte ADM-Dateien, die für frühere Windows Versionen erstellt worden sind, in das ADMX-Format umwandeln. Auch bei der Verwendung des ADMX-Migrators ist es hilfreich, ein Grundverständnis der Begrifflichkeiten innerhalb der ADMX-Dateien zu haben, wie diese im vorherigen Abschnitt beschrieben sind. Die Abbildung 5.22 zeigt die Oberfläche des ADMX-Migrators.

45 Erweitern der Standardvorlagen 255 Abbildung 5.22 ADMX-Migrator mit geöffneter ADMX-Datei Eine ausführliche Beschreibung der Handhabung des ADMX-Migrators finden Sie direkt in der Hilfe zu diesem Programm. Neben dem direkten Erstellen von ADMX-Dateien bietet der ADMX-Migrator auch die Möglichkeit, diese direkt aus einer bestehenden ADM-Datei zu erzeugen. Auf diesem Weg ersparen Sie sich das neu Programmieren. Die folgenden Schritte beschreiben, wie Sie aus einer bestehenden ADM-Datei mithilfe des ADMX-Migrators eine ADMX-Datei erstellen können: 1. Öffnen Sie den ADMX-Migrator. 2. Klicken Sie mit der rechten Maustaste in der linken Navigationsleiste auf ADMX Editor und wählen Sie im Kontextmenü den Eintrag Generate ADMX from ADM (siehe Abbildung 5.23).

46 256 Kapitel 5: Arbeiten mit administrativen Vorlagen Abbildung 5.23 Importieren einer ADM-Datei 3. Wählen Sie die zu konvertierende ADM-Datei aus. 4. Anschließend wird die Datei automatisch übersetzt und, sofern vorhanden, eine Liste mit Auffälligkeiten präsentiert (siehe Abbildung 5.24). 5. In der abschließenden Frage des Assistenten können Sie die Datei in den ADMX-Migrator laden, um eventuell gewünschte Anpassungen vorzunehmen und die Datei zu speichern. 6. Um die Datei nutzen zu können, müssen Sie diese speichern. Klicken Sie hierzu mit der rechten Maustaste auf die Vorlage in der linken Navigationsleiste und wählen Sie im Kontextmenü den Eintrag Save As aus. Es erscheint das in Abbildung 5.25 gezeigte Dialogfeld, in dem Sie neben dem Speicherort auch die Sprache der korrespondierenden ADML-Datei angeben.

47 Zusammenfassung 257 Abbildung 5.24 Auffälligkeiten bei der Konvertierung Abbildung 5.25 Speichern der ADMX- und ADML-Datei Zusammenfassung In diesem Kapitel wurden die administrativen Vorlagen von Windows Server 2008-Gruppenrichtlinien ausführlich vorgestellt. Dabei wurde ein besonderes Augenmerk auf die neuen ADMX-Dateien und die Unterschiede zu den ADM-Dateien von Windows Server 2003 gelegt. Zudem wurde gezeigt, wie Sie eigene ADMX- Dateien erstellen können und worauf Sie dabei achten sollten. Im nächsten Kapitel beschäftigen wir uns mit den Gruppenrichtlinieneinstellungen, die wohl zu den leistungsstärksten Neuerungen in den Gruppenrichtlinien von Windows Server 2008 zählen.