Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Geleitwort zu diesem Buch
Inhalt des Buchs
1 Warum eine neue Server-Version?
2 Editionen und Lizenzen
3 Hardware und Dimensionierung
4 Protokolle
5 Was überhaupt ist .NET?
6 Installation
7 Core-Installationsoption
8 Active Directory-Domänendienste
9 Netzwerkdienste im AD-Umfeld
10 Active Directory Lightweight Directory Services (AD LDS)
11 Active Directory-Verbunddienste (Federation Services)
12 Active Directory-Zertifikatdienste
13 Active Directory-Rechteverwaltungsdienste (AD RMS)
14 »Innere Sicherheit«
15 Dateisystem und Dateidienste
16 Drucken
17 Webserver (IIS)
18 SharePoint (Windows SharePoint Services, WSS)
19 Remotedesktopdienste (Terminaldienste)
20 Hochverfügbarkeit
21 Datensicherung
22 Servervirtualisierung mit Hyper-V
23 Windows PowerShell
24 Windows 7 und Windows Server 2008 R2
Stichwort
Ihre Meinung?

Spacer
<< zurück
Windows Server 2008 R2 von Ulrich B. Boddenberg
Das umfassende Handbuch
Buch: Windows Server 2008 R2

Windows Server 2008 R2
geb., 1.410 S., 59,90 Euro
Rheinwerk Computing
ISBN 978-3-8362-1528-2
Pfeil 8 Active Directory-Domänendienste
Pfeil 8.1 Aufbau und Struktur
Pfeil 8.1.1 Logische Struktur
Pfeil 8.1.2 Schema
Pfeil 8.1.3 Der globale Katalog (Global Catalog, GC)
Pfeil 8.1.4 Betriebsmasterrollen/FSMO-Rollen
Pfeil 8.1.5 Verteilung von Betriebsmasterrollen und Global Catalog
Pfeil 8.1.6 Schreibgeschützte Domänencontroller, Read Only Domain Controller (RODC)
Pfeil 8.2 Planung und Design des Active Directory
Pfeil 8.2.1 Abbildung des Unternehmens
Pfeil 8.2.2 Übersichtlichkeit und Verwaltbarkeit
Pfeil 8.2.3 Standorte
Pfeil 8.2.4 Replikation
Pfeil 8.2.5 Gruppenrichtlinien
Pfeil 8.3 Ein neues Active Directory einrichten
Pfeil 8.3.1 Den ersten Domänencontroller einrichten
Pfeil 8.3.2 Zusätzliche Domänencontroller einrichten
Pfeil 8.4 Gruppenrichtlinien
Pfeil 8.4.1 Anwendungsbeispiel
Pfeil 8.4.2 Richtlinien für Computer und Benutzer
Pfeil 8.4.3 Verteilung über Domänencontroller
Pfeil 8.4.4 Vererbung
Pfeil 8.4.5 Sicherheit und Vorrang
Pfeil 8.4.6 Filter
Pfeil 8.4.7 Abarbeitungsreihenfolge, Teil II
Pfeil 8.4.8 Lokale GPOs (ab Windows Vista und Windows Server 2008)
Pfeil 8.4.9 Starter-Gruppenrichtlinienobjekte/Starter-GPOs
Pfeil 8.4.10 ADM vs. ADMX
Pfeil 8.4.11 Zuweisen und Bearbeiten von Gruppenrichtlinien
Pfeil 8.4.12 WMI-Filter
Pfeil 8.4.13 Softwareverteilung mit Gruppenrichtlinien
Pfeil 8.4.14 Loopback-Verarbeitung
Pfeil 8.4.15 Gruppenrichtlinien-Voreinstellungen (Preferences)
Pfeil 8.5 Diverses über Gruppen
Pfeil 8.6 Delegierung der Verwaltung
Pfeil 8.7 Das Active Directory aus der Client-Perspektive
Pfeil 8.7.1 DNS-Einträge oder »Wie findet der Client das Active Directory?«
Pfeil 8.7.2 Das Active Directory durchsuchen
Pfeil 8.7.3 Individuelle Erweiterungen
Pfeil 8.8 Zeitdienst
Pfeil 8.8.1 Grundkonfiguration der Zeitsynchronisation
Pfeil 8.8.2 Größere Umgebungen
Pfeil 8.9 Upgrade der Gesamtstruktur auf Active Directory-Domänendienste (AD DS) 2008
Pfeil 8.9.1 Schemaerweiterung und Anpassung der Domänen durchführen
Pfeil 8.9.2 Windows Server 2008 R2 Domänencontroller installieren
Pfeil 8.9.3 Kurze Überprüfung
Pfeil 8.9.4 FSMO-Rollen verschieben
Pfeil 8.9.5 Alte Domänencontroller deinstallieren und einheitlichen Modus wählen
Pfeil 8.9.6 Real-World-Troubleshooting – ein Beispiel
Pfeil 8.10 Umstrukturieren
Pfeil 8.11 Werkzeugkiste
Pfeil 8.12 Windows Server 2008 R2-Domänencontroller
Pfeil 8.12.1 Schema-Erweiterung
Pfeil 8.12.2 2008 R2-Domänencontroller installieren
Pfeil 8.12.3 2008-Domänencontroller auf R2 migrieren
Pfeil 8.13 Active Directory Best Practice Analyzer"
Pfeil 8.14 Der Active Directory-Papierkorb
Pfeil 8.14.1 Voraussetzungen
Pfeil 8.14.2 Active Directory-Papierkorb aktivieren
Pfeil 8.14.3 Gelöschte Objekte anzeigen und wiederherstellen
Pfeil 8.14.4 Wiederherstellen mit der PowerShell
Pfeil 8.15 Active Directory-Verwaltungscenter
Pfeil 8.15.1 Kennwort zurücksetzen
Pfeil 8.15.2 Benutzer suchen und Attribute anzeigen und modifizieren
Pfeil 8.15.3 Navigieren und filtern
Pfeil 8.15.4 Neuanlegen von Objekten
Pfeil 8.15.5 Navigationsknoten und mehrere Domänen
Pfeil 8.15.6 Technik im Hintergrund / Voraussetzungen
Pfeil 8.16 Active Directory-Webdienste (Active Directory Web Services, ADWS)
Pfeil 8.17 Active Directory-Modul für Windows-PowerShell
Pfeil 8.18 Offline-Domänenbeitritt


Galileo Computing - Zum Seitenanfang

8.4 Gruppenrichtlinien Zur nächsten ÜberschriftZur vorigen Überschrift

Mit Gruppenrichtlinien (GPO, Group Policy Object) können Sie diverse Konfigurationen für Benutzer oder Computer vornehmen – und zwar in Abhängigkeit von dem Standort, der Domäne und der Organisationseinheit (OU), in der sich der Computer oder der Benutzer befindet. Gruppenrichtlinien sind das Administrationswerkzeug für die Windows-Umgebung.

Letztendlich werden bei der Anwendung von Gruppenrichtlinien Werte in der Registry modifiziert – und zwar genauer gesagt Werte in den Zweigen HKEY_CURRENT_USER und HKEY_LOCAL_MACHINE. Mit den Gruppenrichtlinien werden also Einschränkungen für Benutzer konfiguriert, können aber auch Einstellungen für Computer vorgenommen werden, z. B. zur Sicherheitskonfiguration für drahtlose Netzwerke.

In den Gruppenrichtlinien konfigurieren Sie übrigens auch die Login-Skripts, die angewendet werden sollen.

Gruppenrichtlinien wirken auf alle Betriebssysteme ab Windows 2000 aufwärts. Mit ihnen können Einstellungen sowohl auf den Client- als auch auf den Serverbetriebssystemen angepasst werden.

Neben der Möglichkeit, Einstellungen anzupassen, kann mittels Gruppenrichtlinien eine Verteilung von Software realisiert werden. Diese Art der Softwareverteilung erreicht nicht die Leistungsfähigkeit spezieller Systeme wie beispielsweise von Microsoft SMS (Systems Management Server), ist aber in vielen Fällen durchaus ausreichend.

Die bereits in Windows Server 2008 enthaltenen Einstellmöglichkeiten für Gruppenrichtlinien decken bei Weitem nicht alles ab:

  • Für die Administration von Anwendungen liefern viele Hersteller, so auch Microsoft selbst, Vorlagen für Gruppenrichtlinien mit. Auf diese Weise können Sie beispielsweise das Office-Paket sehr weitgehend anpassen.
  • Bei Bedarf können auch eigene Gruppenrichtlinien erstellt werden, so dass man als Administrator die Freiheit hat, alles über Gruppenrichtlinien zu konfigurieren, was über die Registry eingestellt werden kann.

Galileo Computing - Zum Seitenanfang

8.4.1 Anwendungsbeispiel Zur nächsten ÜberschriftZur vorigen Überschrift

Falls Sie bisher nicht mit Gruppenrichtlinien in Berührung gekommen sind, zeige ich Ihnen zum Einstieg ein Anwendungsbeispiel.

In Abbildung 8.87 ist das Startmenü eines Windows Vista-Clients zu sehen. Viele Unternehmen möchten die Möglichkeiten der Anwender mehr oder weniger stark einschränken. Da das Startmenü der primäre Weg ist, um Applikationen oder Konfigurationsdialoge aufzurufen, läge es also nahe, das Startmenü entsprechend zurechtzustutzen. Auf der Wunschliste stehen weiterhin folgende Punkte:

  • Die Einstellungen sollen nicht an jedem PC einzeln vorgenommen werden müssen.
  • Die Änderungen müssen auf bestimmte Teilmengen von Benutzern und Computern zu beschränken sein. Es wäre schlecht, wenn die Administratoren ebenfalls nur ein eingeschränktes Startmenü hätten.

In Abbildung 8.88 sehen Sie, wie ein Gruppenrichtlinienobjekt mit der Organisationseinheit Vertrieb verknüpft wird. Es können beliebig viele Gruppenrichtlinienobjekte mit einer OU verknüpft werden. Ein Gruppenrichtlinienobjekt kann mit beliebig vielen OUs verknüpft werden.

Abbildung 8.87 Das »normale« Startmenü eines Vista-Clients

Abbildung 8.88 Ein Gruppenrichtlinienobjekt wird mit der OU »Vertrieb« verknüpft.

Ein Gruppenrichtlinienobjekt enthält jeweils beliebig viele Einstellungen. Man könnte prinzipiell alle anzuwendenden Einstellungen in einem Gruppenrichtlinienobjekt vornehmen. Erfahrungsgemäß ist es zur Administration übersichtlicher, die vorzunehmenden Einstellungen in Gruppen zusammenzufassen und auf mehrere Gruppenrichtlinienobjekte zu verteilen.


Hinweis

Die Arbeit mit der Gruppenrichtlinienverwaltung wird ein wenig später vorgeführt.

Bereits hier wäre anzumerken, dass in den Dialogen eigentlich nur Verknüpfungen auf Gruppenrichtlinienobjekte angezeigt werden – doch dazu später mehr!


Das Bearbeiten des Gruppenrichtlinenobjekts, also das Vornehmen der gewünschten Einstellungen, ist eine Arbeit, die viel mit »Suchen« zu tun hat. Der Grund hierfür ist, dass es eine enorme Vielfalt an Einstellmöglichkeiten gibt – Windows ist ein komplexes System, und es ist sehr weitgehend über Gruppenrichtlinien zu steuern. Dementsprechend vielfältig geht es im Gruppenrichtlinienobjekt-Editor zu (Abbildung 8.89).

Abbildung 8.89 Bei der Erstellung der Gruppenrichtlinie können Sie aus vielen Hundert Einstellungen auswählen.

Meldet sich der Benutzer das nächste Mal am System an, werden die vorgegebenen Einstellungen angewendet. In Abbildung 8.90 ist zu sehen, dass der Eintrag Alle Programme nicht mehr angezeigt wird.

Mit Gruppenrichtlinien kann nicht nur das optische Erscheinungsbild angepasst werden; im Grunde genommen können Sie all das, was in der Systemsteuerung einzustellen ist, mit Gruppenrichtlinien bequem von Ihrem Schreibtisch aus konfigurieren – und noch viel mehr, denn es gibt in Windows-Systemen viel mehr zu konfigurieren, als in den grafischen Werkzeugen angezeigt wird.

Abbildung 8.90 Die erstellte Richtlinie entfernt »Alle Programme« aus dem Startmenü.


Galileo Computing - Zum Seitenanfang

8.4.2 Richtlinien für Computer und Benutzer Zur nächsten ÜberschriftZur vorigen Überschrift

Ein Gruppenrichtlinienobjekt ist immer zweigeteilt. Es gibt einen Bereich Computerkonfiguration und einen weiteren namens Benutzerkonfiguration. Abbildung 8.91 zeigt einen Blick in die Computerkonfiguration. Sie erkennen dort diverse Sicherheitseinstellungen, die Möglichkeit zur Konfiguration der Windows Firewall, Zugriff auf die Einstellungen für die Network Access Protection und vieles andere mehr. Interessant ist auch der Knoten Softwareinstallation; Mit dieser Funktion kann ein Windows Installer-Paket an Computer verteilt werden. Mehr dazu folgt im weiteren Verlauf dieses Abschnitts.

Abbildung 8.91 In Bereich »Computerkonfiguration« des Gruppenrichtlinienobjekts nehmen Sie alle systemseitigen Einstellungen vor. Einige Beispiele sind in der Abbildung zu sehen.

Abbildung 8.92 zeigt einen kleinen Ausschnitt der Benutzerkonfiguration. Wenn Sie diese mit der Computerkonfiguration vergleichen, werden Sie erkennen, dass beide grundsätzlich dieselbe Struktur haben, die aus den folgenden drei Gruppen besteht:

  • Softwareinstellungen: Hier wird die Verteilung von Softwarepaketen (nur Windows Installer-Pakete, also *.MSI-Dateien) konfiguriert.
  • Windows-Einstellungen: Hier finden Sie die »Windows-nahen« Einstellmöglichkeiten, beispielsweise für die Ausführung von Skripts, die Sicherheitsrichtlinien und einiges andere mehr.
  • Administrative Vorlagen: Alle anderen Einstellungen finden Sie unter dem Knoten Administrative Vorlagen. Die Konfiguration von zusätzlichen Softwarekomponenten oder des Erscheinungsbilds der Oberfläche nehmen Sie mit den Einstellmöglichkeiten vor, die Sie hier finden. Wenn Sie eigene Gruppenrichtlinien erstellen möchten, werden diese immer unterhalb des Knotens Administrative Vorlagen zu finden sein.

Abbildung 8.92 Der Bereich »Benutzerkonfiguration« des Gruppenrichtlinienobjekts beschäftigt sich primär mit der Fragestellung, auf welche Betriebssystemfunktionen der Benutzer Zugriff hat und wie das optische Erscheinungsbild sein soll.

Sie sollten sich ruhig Zeit nehmen, in dem Wust von Konfigurationsmöglichkeiten zu stöbern. Man findet häufig Optionen mit dem »Könnte-ich-gut-einsetzen«-Effekt.

In dem Gruppenrichtlinenobjekt-Editor von Windows Server 2008 finden sich bereits die für Windows Vista (und alle Vorgängerversionen) benötigten Einstellmöglichkeiten. Windows Server 2008 R2 enthält bereits auch die für Windows 7 benötigten Konfigurationsmöglichkeiten.

Vermutlich wird es irgendwann ein Service-Pack zu Windows 7 und später eine neue Version des Client-Betriebssystems geben. Vermutlich wird es bei diesen Nachfolgeversionen weitere Einstellmöglichkeiten geben, die der heute installierten Windows Server 2008 R2-Version einfach noch nicht bekannt sind und die folglich nicht angezeigt werden. Da weitere Einstellmöglichkeiten über die Administrativen Vorlagen hinzugefügt werden können, können auch zukünftige Features der Clients mit den heute aktuellen Server-Versionen verwaltet werden.

Falls Sie auf den Clients das Betriebssystem in der Version Windows 7 einsetzen und Ihr Active Directory noch auf dem Stand Windows 2000 ist, ist die Vorgehensweise identisch: Die administrativen Vorlagen für Windows 7 werden installiert, und demzufolge stehen in dem Gruppenrichtlinienobjekt-Editor des Windows 2000 Servers die Windows 7-Konfigurationsmöglichkeiten zur Verfügung.

Kleine Warnung: Sie haben durchaus die Möglichkeit, sich selbst auszusperren. Wenn Sie eine domänenweit gültige Gruppenrichtlinie definieren, die sämtlichen Benutzern alle Möglichkeiten auf dem Desktop wegnimmt, gilt das auch für Administratoren. Das ist dann, vorsichtig gesagt, schon sehr, sehr ungünstig.


Galileo Computing - Zum Seitenanfang

8.4.3 Verteilung über Domänencontroller Zur nächsten ÜberschriftZur vorigen Überschrift

Die Gruppenrichtlinien zu erstellen ist zwar schon gut, so richtig sinnvoll wird es aber erst, wenn diese auf den Clients auch zur Anwendung kommen.

Abbildung 8.93 Die Informationen über die angelegten Gruppenrichtlinen finden Sie im Domänennamenskontext, hier mit ADSI-Editor. Zu sehen ist beispielsweise der Displayname und ein Pfad ins Dateisystem.

Im Grunde genommen ist die Vorgehensweise nicht kompliziert. Abbildung 8.93 zeigt einen Blick mit ADSI-Editor in das Active Directory gezeigt, genauer gesagt in den Abschnitt CN=System,CN=Policies des Domänennamenskontexts. Dort finden Sie mehrere mit einer GUID benannte Einträge: Dies sind die Gruppenrichtlinienobjekte. Wenn Sie sich die Attribute eines solchen Objekts anschauen, finden Sie beispielsweise den Anzeigenamen (displayName) der Gruppenrichtlinie und einen Pfad ins Dateisystem (gPCFileSysPath).

Der Pfad ins Dateisystem lässt darauf schließen, dass das eigentliche Regelwerk, also die Information über die zu setzenden Registry-Einstellungen, im Dateisystem gespeichert wird. Genau so verhält es sich: Jeder Domänencontroller verfügt über ein freigegebenes Verzeichnis SYSVOL, das einen Unterordner Policies enthält, in dem wiederum Unterordner vorhanden sind, die mit den GUIDs benannt sind, die Sie bereits in ADSI-Editor gesehen haben. Abbildung 8.94 zeigt den Blick in das entsprechende Verzeichnis einer Gruppenrichtlinie.

Abbildung 8.94 Die Dateien zu den Gruppenrichtlinienobjekten liegen in der Freigabe SYSVOL, die sich auf jedem Domänencontroller befindet.

In dem Verzeichnis der Gruppenrichtlinie befindet sich ein Ordner Machine und ein Ordner User. In Letzterem liegt in diesem Fall eine Datei Registry.pol, die Informationen darüber enthält, was die Gruppenrichtlinie in der Registry einträgt. Je nach Inhalt des Gruppenrichtlinienobjekts können weitere Unterordner, Skriptdateien und dergleichen vorhanden sein. In dem gezeigten Gruppenrichtlinenobjekt-Verzeichnis ist neben Machine und User ein Ordner Adm vorhanden. Hier wird die Datei der verwendeten administrativen Vorlage gespeichert (mehr dazu folgt später in diesem Abschnitt).

Damit alle Domänencontroller einer Domäne die Gruppenrichtlinien bereitstellen können, ist es erforderlich, dass die SYSVOL-Verzeichnisse repliziert werden. Dies wird vom DFS-Replikationsdienst übernommen. Falls die Replikation der SYSVOL-Verzeichnisse nicht funktioniert, ist akut Handlungsbedarf vorhanden. Diese Störung wird zwar nicht zum Stillstand der gesamten Produktionsumgebung führen, trotzdem wird es Beeinträchtigungen geben, weil entweder nicht alle Clients die notwendigen Einstellungen erhalten und/oder Benutzer plötzlich ein anderes optisches Erscheinungsbild als am Vortag vorfinden – in Abhängigkeit von dem Domänencontroller, an dem die Anmeldung erfolgte.

Fehler des DFS-Replikationsdiensts werden im Ereignisprotokoll angezeigt. Unterhalb des Knotens Anwendungs- und Dienstprotokolle befindet sich das benötigte Protokoll (Abbildung 8.95). Da es in einer etwas größeren Umgebung unmöglich sein wird, jederzeit alle Protokolle im Blick zu haben, bietet sich die Einführung eines automatischen Systems an, das solche Meldungen konsolidiert und möglichst auch interpretiert. Ein bewährtes und preislich einigermaßen moderates System ist der Microsoft System Center Operations Manager (SCOM).

Abbildung 8.95 Meldungen und Fehler betreffs der Replikation werden im Ereignisprotokoll, Abschnitt »DFS-Replikation«, angezeigt.

Nachdem Sie nun wissen, wo die Gruppenrichtlinienobjekte angelegt werden, ergibt sich noch die Frage, wie die Zuordnung zu den Domänen, Organisationseinheiten und Standorten erfolgt. In Abbildung 8.96 sehen Sie in ADSI-Editor die Attribute der Organisationseinheit Marketing. Unter anderem ist auch das Attribut gPLink vorhanden, das auf die Gruppenrichtlinienobjekte verweist, die von dieser OU verwendet werden sollen.

Abbildung 8.96 Die Organisationseinheit verfügt über das Attribut »gPLink«, das Verweise auf Gruppenrichtlinienobjekte enthält.

Nachfolgend ist der Inhalt des gPLink-Attributs aus Abbildung 8.96 aufgeführt; es sind zwei Verweise auf Gruppenrichtlinienobjekte. Die GUIDs finden Sie in Abbildung 8.93 und 8.94 (in den Baumansichten zu sehen) wieder.

[LDAP://cn={056D4794-8D77-4D2F-936B-72A2ED08E5E0},cn=policies,cn=system,DC=ubinf,DC=intra;0]
[LDAP://cn={E7048FC3-C2FE-46DC-90B5-C11D7E39A7AE},cn=policies,cn=system,DC=ubinf,DC=intra;0]

Nun wird auch das Gesamtbild klar, das auf der stark vereinfachten Darstellung in Abbildung 8.97 zu sehen ist:

  • Organisationseinheiten, Domänen und Standorte speichern Verweise auf Gruppenrichtlinienobjekte.
  • Eine Organisationseinheit, eine Domäne oder ein Standorte kann auf ein, mehrere oder kein Gruppenrichtlinienobjekt verweisen.
  • Auf ein Gruppenrichtlinienobjekt kann von keiner, einer oder mehreren Organisationseinheiten/Domänen/Standorten verwiesen werden.

Abbildung 8.97 Standorte und Organisationseinheiten speichern Verweise auf Gruppenrichtlinienobjekte.

Es ist wichtig, diese Zusammenhänge zu verstehen – sonst wird man unter Umständen funktionsgleiche Gruppenrichtlinienobjekte doppelt anlegen und sich eventuell über die Formulierung in einigen Konfigurationsdialogen wundern.


Galileo Computing - Zum Seitenanfang

8.4.4 Vererbung Zur nächsten ÜberschriftZur vorigen Überschrift

Wie gesagt können Gruppenrichtlinien an drei »Orten« angelegt werden:

  • Domäne
  • Organisationseinheit
  • Standort

Drei lokale Gruppenrichtlinienobjekte

Wichtig zu erwähnen ist, dass Betriebssysteme ab Windows Vista und Windows Server 2008 zusätzlich über drei lokale Gruppenrichtlinienobjekte verfügen. Insofern gibt es für diese Betriebssysteme vier »Orte«, an denen Gruppenrichtlinien gespeichert werden. Mehr dazu erfahren Sie in Abschnitt 8.4.8.


Die Gültigkeitsbereiche der Gruppenrichtlinie sind einfach zu verstehen:

  • Eine lokale Gruppenrichtlinie gilt verständlicherweise nur auf dem lokalen Computer. Windows Vista/7 und Windows Server 2008/R2 verfügen über drei lokale GPOs, die eine zusätzliche Einschränkung des Gültigkeitsbereichs ermöglichen. Mehr dazu finden Sie in Abschnitt 8.4.8.
  • Eine Standortrichtlinie gilt für alle Computer an einem Standort und alle Benutzer, die sich dort anmelden.
  • Eine Domänenrichtlinie wird auf alle in der Domäne befindlichen Benutzer- und Computer angewendet.
  • Eine Gruppenrichtlinie, die in einer Organisationeinheit definiert ist, gilt für alle dort angesiedelten Objekte, einschließlich denen, die in »Unter-OUs« angelegt sind (und auch für die in der OU in der OU in der OU …).

Es wirken also offensichtlich mehrere Gruppenrichtlinien auf ein Benutzer- oder Computer-Objekt. Daher ist die Reihenfolge nicht uninteressant. Abbildung 8.98 zeigt, in welcher Reihenfolge die Gruppenrichtlinien für den mit einem Pfeil gekennzeichneten Benutzer abgearbeitet werden:

1. Zunächst wird die Gruppenrichtlinie des Standorts abgearbeitet
2. Dann wird die Gruppenrichtlinie der Domäne abgearbeitet.
3. Als Nächstes wird die Gruppenrichtlinie der »äußeren« Organizational Unit abgearbeitet.
4. Zuletzt wird die Gruppenrichtlinie der »inneren« OU verarbeitet.

Abbildung 8.98 Die Reihenfolge, in der die Gruppenrichtlinien abgearbeitet werden


Schritt 0

In einem (nicht in der Zeichnung abgebildeten) Schritt 0 werden bei Betriebssystemen ab Windows Vista und Windows Server 2008 die lokalen GPOs verarbeitet.


Die Gruppenrichtlinien überschreiben sich in der Reihenfolge der Abarbeitung und wirken additiv. Ein »praktisches Beispiel« sehen Sie in der folgenden Tabelle, die auch die genaue Abarbeitungsreihenfolge zeigt:


Richtlinie Konfiguration

Vista/7, WS2008/R2: Lokale GPO

Nicht konfiguriert

Vista/7, WS2008/R2: Lokale GPO für Admin-Konten oder Nicht–Admin-Konten

Nicht konfiguriert

Vista/7, WS2008/R2: Lokale benutzerspezifische GPO

Nicht konfiguriert

Standort

Aktiviert

Domain

Deaktiviert

OU 1 (»äußere«)

Aktiviert

OU2 (»innere«)

Nicht konfiguriert

Resultat

Aktiviert


Ist das so weit einleuchtend? Gut!

In dem Dialog aus Abbildung 8.99 ist eine Option zu erkennen, die die zuvor gezeigte Tabelle nichtig macht – sie heißt Vererbung deaktivieren. Ist diese Option gesetzt, werden übergeordnete Richtlinien eben nicht mehr vererbt. In einer so konfigurierten OU zählen nur deren eigene Richtlinien, die dann aber weiter »nach unten« vererbt werden. Das kleinere Bildschirmfoto im rechten Bereich von Abbildung 8.99 zeigt, dass bei einer OU mit deaktivierter Vererbung ein kleines blaues Aufrufezeichen angezeigt wird.


Gruppenrichtlinienverwaltung

Den Umgang mit dem Konfigurationswerkzeug Gruppenrichtlinienverwaltung zeige ich recht ausführlich in Abschnitt 8.4.11, »Zuweisen und Bearbeiten von Gruppenrichtlinien«. Dort sehen Sie auch, wie man mit dem Werkzeug anzeigt, welche Gruppenrichtlinienobjekte in einer OU tatsächlich angewendet werden.


Abbildung 8.100 zeigt, dass in der Gruppenrichtlinienverwaltung bei einem Standort der Menüpunkt Vererbung deaktivieren nicht vorhanden ist. Der Grund ist, dass es bei Standorten keine Vererbung geben kann:

  • Oberhalb einer OU könnte eine andere OU angesiedelt sein, in jedem Fall ist über einer OU eine Domäne.
  • Im Falle der physikalischen Struktur des Active Directory gibt es keinen übergeordneten Standort oder einen Unterstandort. Daher kann es auch keine Vererbung geben, was wiederum bedeutet, dass die Einstellung Vererbung deaktivieren nicht relevant und darum nicht vorhanden ist.

Abbildung 8.99 Die Vererbung der Gruppenrichtlinien kann deaktiviert werden. Ist für eine OU die Vererbung deaktiviert, wird sie mit einem kleinen blauen Ausrufezeichen versehen (rechts).

Abbildung 8.100 Bei Standorten gibt es kein »Vererbung deaktivieren«.

Ansonsten gilt auch bei Gruppenrichtlinienobjekt-Verknüpfungen für Standorte, dass bei überlappenden Einstellungen die in der Liste höher angeordnete Einstellung »gewinnt«.


Galileo Computing - Zum Seitenanfang

8.4.5 Sicherheit und Vorrang Zur nächsten ÜberschriftZur vorigen Überschrift

Wie alle anderen Objekte im Active Directory hat auch ein Gruppenrichtlinienobjekt Sicherheitseinstellungen. Standardmäßig können Authentifizierte Benutzer ein Gruppenrichtlinienobjekt lesen (Abbildung 8.101). Verweigert man einer bestimmten Person oder einer Gruppe die Leseberechtigung, kann bei diesen das Gruppenrichtlinienobjekt nicht angewendet werden, selbst wenn in der Organisationseinheit bzw. der Domäne oder an dem Standort eine Verknüpfung vorhanden ist. Man könnte sich folgendes Szenario überlegen:

  • Für die Organisationeinheit Vertrieb wird ein Gruppenrichtlinienobjekt angelegt; genauer: Es wird ein Gruppenrichtlinienobjekt angelegt und in der OU Vertrieb eine Verknüpfung auf dieses angelegt.
  • Bei allen Vertriebsmitarbeitern bis auf Naomi Wolf sollen die dort definierten Einstellungen angewendet werden. Naomi Wolfs Benutzerobjekt ist aber in der OU gespeichert und soll dort auch bleiben.
  • Wenn man Naomi gezielt den Zugriff auf dieses Gruppenrichtlinienobjekt verweigert (verweigern ist stärker als vererbter Zugriff), wird es bei ihr nicht angewendet werden.

Abbildung 8.101 Auch die Gruppenrichtlinienobjekte sind mit Sicherheitseinstellungen versehen.

Ich persönlich bin kein Freund dieser Vorgehensweise, weil es irgendwann weitgehend unüberschaubar ist, bei wem welche Gruppenrichtlinie zur Anwendung kommt. Wenn es notwendig ist, bestimmte Benutzer vor einem Gruppenrichtlinienobjekt »zu schützen«, können Sie diesen Weg gehen, es sollte aber eine Ausnahme bleiben.

Denken Sie daran, dass sich das Ändern der Sicherheitseinstellung auf das Gruppenrichtlinienobjekt und nicht auf eine einzelne Verknüpfung bezieht.

Etwas weiter vorn haben Sie die Möglichkeit Vererbung deaktivieren kennengelernt. Es gibt auch das genaue Gegenteil, nämlich die Einstellung Erzwungen (Abbildung 8.102).


Hinweis

Blitzinfo für »alte AD-Hasen«: Früher hieß diese Option Kein Vorrang.


Diese Option bewirkt, dass die in einer Gruppenrichtlinie festgelegten Einstellungen nicht von einer »späteren« Richtlinie überschrieben werden können. Ein kleines Beispiel:

  • Auf der Ebene der Domäne legen Sie mittels einer Verknüpfung auf ein Gruppenrichtlinienobjekt fest, dass der Hintergrund des Bildschirms schweinchenrosa sein muss.
  • Im Normalfall könnte auf der Ebene der Organisationseinheiten festgelegt werden, dass die Hintergrundfarbe Babyblau sein soll. Die OU-Richtlinie überschreibt die Domänenrichtlinie.
  • Wenn auf Domänenebene die Verknüpfungsoption (!) Kein Vorrang gesetzt wird, werden sämtliche Bildschirmhintergründe aller Systeme in der Domäne schweinchenrosa sein.

Erzwungen ist übrigens auch »stärker« als Vererbung deaktivieren. Diese Option ist beispielsweise nicht unpraktisch, wenn in Ihrer Organisation die Verwaltung der OUs inklusive Gruppenrichtlinien an »Unteradministratoren« delegiert ist. Gruppenrichtlinien, die Ihnen wichtig erscheinen, können Sie dann trotzdem durchsetzen, egal ob der Kollege keine Bildschirmhintergründe in Schweinchenrosa mag.

Beachten Sie, dass Erzwungen eine Verknüpfungsoption ist. Mit den vorherigen Erklärungen werden Sie leicht verstehen können, was das bedeutet.

Der Dialog aus Abbildung 8.102 bietet weiterhin die Möglichkeit, eine Verknüpfung zu deaktivieren.

Abbildung 8.102 Ist die Option »Erzwungen« gesetzt, können vererbte Gruppenrichtlinien-Einstellungen nicht mehr überschrieben werden. Eine entsprechend konfigurierte Verknüpfung wird mit einem kleinen Schloss angezeigt.


Galileo Computing - Zum Seitenanfang

8.4.6 Filter Zur nächsten ÜberschriftZur vorigen Überschrift

Eine weitere Möglichkeit, die Anwendung einer Gruppenrichtlinie zu bestimmen, ist die Verwendung von WMI-Filtern. Filterkriterien können über die WMI Query Language formuliert werden und beziehen sich zumeist auf Hardware- und/oder Betriebssystem-Gegebenheiten. Interessant ist das insbesondere bei Richtlinien zur Verteilung von Software: Sie können beispielsweise festlegen, dass die Installation (d. h. die Anwendung der Richtlinie) nur dann erfolgt, wenn mindestens 2 GB freier Plattenspeicher vorhanden sind und das Betriebssystem Windows XP ist.

Die Verwendung von Filtern wird im weiteren Verlauf des Kapitels am Beispiel vorgeführt.


Galileo Computing - Zum Seitenanfang

8.4.7 Abarbeitungsreihenfolge, Teil II Zur nächsten ÜberschriftZur vorigen Überschrift

Weiter vorn habe ich bereits zwei wichtige Sachverhalte genannt:

  • Innerhalb einer Domäne findet eine Vererbung der Gruppenrichtlinien statt, d. h., eine Organisationseinheit (OU) erbt immer die Gruppenrichtlinien der höheren OU, wobei der Vorgang transitiv ist. Die Vererbung kann bei Bedarf deaktiviert werden; durch die Einstellung Erzwungen kann das aber wiederum außer Kraft gesetzt werden.
  • Wenn Sie Einstellungen konfigurieren, ist es in den meisten Fällen günstiger, diese in verschiedene Gruppenrichtlinienobjekte (GPO) aufzuteilen. Hierdurch wird es einerseits übersichtlicher, andererseits verbessert sich auch die Wiederverwendbarkeit des einzelnen GPOs.

Wenn Sie also, wie in Abbildung 8.103 gezeigt, mehrere Verknüpfungen erstellt haben, ist die Verknüpfungsreihenfolge konfigurierbar. Sie sehen die Zahlen in der ersten Spalte: Diese gibt die Abarbeitungsreihenfolge an. Beachten Sie, dass die Verknüpfung mit der niedrigsten Ordnungszahl zuletzt ausgeführt wird und im Zweifelsfall von den »Vorgängern« getroffene Änderungen überschreibt.

Abbildung 8.103 Wenn Sie mehrere Verknüpfungen zu Gruppenrichtlinienobjekten angelegt haben, ist deren Reihenfolge wichtig.

Nun dürfte der »Überschreiben-Fall« eigentlich nie auftreten – wenn er es doch tut, würde ich empfehlen, zunächst dieses organisatorische Problem zu lösen. Auf der Abbildung habe ich drei Verknüpfungen vorgenommen, nämlich zu einem GPO mit Richtlinien für Office Communicator, einem zur Modifikation des Startmenüs und einem für die Konfiguration des WSUS-Clients. Da jeweils gänzlich unterschiedliche Einstellungen vorgenommen worden sind, gibt es kein Überschreiben, so dass die Verarbeitungsreihenfolge letztendlich keine Rolle spielt – man sollte dieses Verfahren aber trotzdem kennen.

Zum Stichwort Abarbeitungsreihenfolge gibt es in der Gruppenrichtlinienverwaltung noch ein wertvolles Mini-Werkzeug, auf das ich Sie an dieser Stelle hinweisen möchte (Abbildung 8.104): Auf der Registerkarte Gruppenrichtlinienvererbung findet sich eine Darstellung der angewendeten Richtlinien nebst Rangfolge. Es gilt, dass das Gruppenrichtlinienobjekt mit der kleinsten Ordnungszahl das zuletzt ausgeführte ist, dessen Einstellungen also »gelten«, sofern nicht zuvor für eine bestimmte Einstellung das Attribut Erzwungen gesetzt worden ist.


Gruppenrichtlinienmodellierung

Wenn Sie intensiver »forschen« möchten, bietet auch die Ansicht Gruppenrichtlinienvererbung zu wenige Details, sondern nur erste Anhaltspunkte. Genauere Informationen liefert die Funktion Gruppenrichtlinienmodellierung, die später vorgestellt wird. Alte AD-Hasen kennen diese Funktion als Richtlinienergebnissatz.


Abbildung 8.104 Auf der Registerkarte »Gruppenrichtlinienvererbung« gibt es einen Schnellüberblick über die Reihenfolge der Abarbeitung.


Galileo Computing - Zum Seitenanfang

8.4.8 Lokale GPOs (ab Windows Vista und Windows Server 2008) Zur nächsten ÜberschriftZur vorigen Überschrift

Die Betriebssysteme ab Windows Vista und Windows Server 2008 kennen vier lokale Gruppenrichtlinienobjekte (GPOs), mit denen erstaunlicherweise Einstellungen des lokalen Computers konfiguriert werden können:

  • das lokale Richtlinienobjekt (Local Policy Object)
  • ein GPO für Administratoren und eines für Nicht-Administratoren
  • ein benutzerspezifisches lokales GPO

Diese GPOs, die übrigens bei der Verarbeitung die niedrigste Rangfolge haben (d. h. ihre Einstellungen werden von den Active Directory-basierten GPOs überschrieben, falls es divergierende Einstellungen gibt), sind beispielsweise dann sinnvoll, wenn Sie in Ihrem Unternehmen »spezielle« Computer haben, für die Sie zusätzliche Einstellungen vornehmen müssen.

Das Konfigurieren der lokalen Gruppenrichtlinien funktioniert letztendlich nicht anders als bei den »normalen« Active Directory-basierten Richtlinien. Natürlich gibt es keine Verknüpfungen, sondern es wird direkt das jeweilige Gruppenrichtlinienobjekt bearbeitet.

Ich zeige Ihnen nachfolgend im Schnelldurchlauf, wie man zur Konfiguration der jeweiligen Richtlinie gelangt. Die Screenshots sind übrigens auf einem Vista-PC entstanden – auf dem Windows Server 2008 sehen die Dialoge aber genauso aus.

Das lokale Richtlinienobjekt bearbeiten

Um das lokale Richtlinienobjekt zu bearbeiten, starten Sie die Management Console (mmc.exe) und wählen das Hinzufügen eines Snap-Ins. In dem Dialog, der sich dann öffnet, fügen Sie das Snap-In Gruppenrichtlinienobjekt-Editor hinzu und wählen in dem sich dann öffnenden Snap-In das vorgegebene Gruppenrichtlinenobjekt Lokaler Computer (Abbildung 8.105). Das war’s schon.

Abbildung 8.105 Um das lokale Richtlinienobjekt zu bearbeiten, öffnen Sie die entsprechende Konsole.

In Abbildung 8.106 sehen Sie die geöffnete lokale Richtlinie. Bezüglich der Konfiguration ist es in der Tat ein »ganz normales« GPO, in dem sowohl Computer- als auch Benutzereinstellungen vorgenommen werden können.

Abbildung 8.106 Das Bearbeiten der »Richtlinien für Lokaler Computer«. Im Grunde genommen ein ganz normales GPO.

GPO für Administratoren und Nicht-Administratoren bearbeiten

Das GPO für Administratoren und Nicht-Administratoren ist insofern eine ganz »pfiffige« Angelegenheit, als dass Sie beispielsweise für lokale Admins weniger restriktive Einstellungen als für Nicht-Admins konfigurieren können.

Das Öffnen dieser Richtlinien funktioniert wie im zuvor beschriebenen Fall über das Gruppenrichtlinienobjekt-Editor-Snap-In. Der einzige Unterschied ist, dass Sie in diesem Fall nicht das vorgegebene Objekt bestätigen, sondern Durchsuchen anklicken und sich im folgenden Dialog entweder für die Gruppe Administratoren oder Nicht-Administratoren entscheiden (Abbildung 8.107).

In Abbildung 8.108 habe ich beide Richtlinien in einer Konsole geöffnet (dazu habe ich einfach zweimal das Snap-In mit unterschiedlichen Einstellungen hinzugefügt). Zu erkennen ist, dass es »nur« Benutzereinstellungen gibt – schließlich handelt es sich hierbei um eine reine Benutzer-GPO.

Abbildung 8.107 In diesem Dialog lassen sich die Gruppen »Administratoren« und »Nicht-Administratoren« sowie einzelne Benutzer auswählen.

Abbildung 8.108 Hier werden die Einstellungen für lokale Administratoren und lokale Nicht-Administratoren zur Bearbeitung angezeigt.

Benutzerspezifische GPOs

Um ein lokales benutzerspezifisches GPO zu erstellen, beginnen Sie wie in dem zuvor gezeigten Fall. In dem Dialog aus Abbildung 8.107 entscheiden Sie sich für den Benutzer, für den die Richtlinie erstellt werden soll.

Zu beachten ist, dass Sie hier lediglich aus lokalen Benutzern auswählen können. Eine spezielle lokale Richtlinie für einen bestimmten Domänenbenutzer können Sie leider nicht erstellen.


Galileo Computing - Zum Seitenanfang

8.4.9 Starter-Gruppenrichtlinienobjekte/Starter-GPOs Zur nächsten ÜberschriftZur vorigen Überschrift

Die Vererbung von Gruppenrichtlinien-Einstellungen ist ohne Zweifel eine sehr leistungsfähige Funktionalität, die aber nicht immer greift:

  • Es könnte Szenarien geben, in denen ähnliche Abteilungen unternehmensweit so über die Domäne verteilt sind, dass die Einstellungen nicht über Vererbung vorgenommen werden können. Dies passiert beispielsweise, wenn das AD nach einem geografischen Modell aufgebaut ist und es an mehreren Standorten OUs mit Vertriebsmitarbeitern gibt.
  • Über Domänengrenzen hinweg gibt es keine GPO-Vererbung. Wenn also alle Vertriebsmitarbeiter eines Konzerns mit mehreren Domänen die gleichen Einstellungen erhalten sollen, muss in jeder Domäne ein Gruppenrichtlinienobjekt angelegt werden.

Mit Windows Server 2008 haben Sie eine Möglichkeit, um das »Immer-Wieder-Abtippen« von bestimmten Einstellungen zu vermeiden – die Lösung lautet Starter-Gruppenrichtlinienobjekte (Starter-GPO). Diese können Sie sich als eine Art »Vorlage« vorstellen, die beim Erstellen von neuen Objekten herangezogen werden kann. Es gibt zwischen dem Starter-GPO und dem daraus erstellten Gruppenrichtlinienobjekt keine Vererbung, vielmehr handelt es sich um einen einmaligen Kopiervorgang.

Wenn Sie in der Gruppenrichtlinienverwaltung einen gezielten Blick in eine Domäne riskieren, werden Sie beim ersten Zugriff den Hinweis erhalten, dass noch kein Ordner für Starter-Gruppenrichtlinienobjekte in der Domäne vorhanden ist (Abbildung 8.109). Der Erstellungsvorgang, den Sie per Mausklick auslösen, läuft ohne weitere Eingaben oder sonstige vom Administrator auszuführende Aktionen ab.

Abbildung 8.109 Beim ersten Anzeigen des Knotens »Starter-Gruppenrichtlinienobjekte« wird das Anlegen eines Ordners angeboten.

Anlegen

Um ein neues Starter-Gruppenrichtlinienobjekt zu erstellen, wählen Sie zunächst im Kontextmenü des Starter-Gruppenrichtlinienobjekt-Containers den Menüpunkt Neu (welche Überraschung). Der sich daraufhin öffnende Dialog ist maximal unspektakulär, denn Sie können nur einen Namen und einen Kommentar eingeben (Abbildung 8.110).

Abbildung 8.110 Das Anlegen eines neuen Starter-GPOs – nicht wirklich spektakulär

Die eigentliche Arbeit beginnt, wenn das neue Objekt angelegt ist. Sie wählen dann in dessen Kontextmenü den Menüpunkt Bearbeiten (Abbildung 8.111).

Abbildung 8.111 Das neu angelegte Starter-GPO-Objekt kann nun bearbeitet werden.

Abbildung 8.112 Das Bearbeiten der Starter-GPOs erfolgt wie gewohnt im Gruppenrichtlinien-Editor. Es gibt allerdings »nur« den Knoten »Administrative Vorlagen«.

Das Bearbeiten der Einstellungen des Starter-Gruppenrichtlinienobjekts geschieht mit einer etwas modifzierten Version des Gruppenrichtlinien-Editors. Sie sehen in Abbildung 8.112 die im Grunde bekannte Applikation, in der sowohl der Knoten Computerkonfiguration als auch der Knoten Benutzerkonfiguration vorhanden ist. Sie können aber »nur« Administrative Vorlagen bearbeiten.

Wenn Sie die gewünschten Einstellungen vorgenommen haben, können Sie den Editor verlassen und das Starter-Gruppenrichtlinienobjekt verwenden.

Anwenden

Um ein neues Gruppenrichtlinienobjekt aus einem Starter-Gruppenrichtlinienobjekt zu erstellen, wählen Sie im Kontextmenü des letztgenannten den entsprechenden Menüpunkt (Abbildung 8.113). Die einzige Eingabe, die nun von Ihnen verlangt wird, ist die Festlegung eines Namens für das neue GPO (Abbildung 8.114).

Abbildung 8.113 So wird ein neuen Gruppenrichtlinienobjekt aus dem Starter-GPO erstellt.

Abbildung 8.114 Bei der Erstellung des neuen Gruppenrichtlinienobjekts muss lediglich der Name angegeben werden.

Einen kurzen Augenblick später wird das neue GPO im Container Gruppenrichtlinienobjekte vorhanden sein. Eine erste kurze Inspektion zeigt, dass die Einstellungen des Starter-Objekts korrekt übertragen worden sind (Abbildung 8.115).

Abbildung 8.115 Et voilà: Alle Einstellungen sind in dem neuen Objekt vorhanden. Es kann nun noch modifiziert und dann einer OU zugewiesen werden.

Nun können Sie bei Bedarf noch die ein oder andere Ergänzung oder Änderung vornehmen und dann die Verknüpfungen mit den OUs (oder der Domäne oder den Standorten) erstellen. Fertig.

Sichern & Co.

Etwas zu sichern ist in der IT immer eine gute Idee – um das zu erfahren, haben Sie aber bestimmt nicht dieses Buch gekauft. Gerade im Zusammenhang mit den Starter-Gruppenrichtlinienobjekten gibt es in der Tat noch einen anderen Anwendungsfall.

Wenn Sie ein Starter-Gruppenrichtlinienobjekt außerhalb »seiner« Domäne verwenden möchten, müssen Sie es sichern und in der zweiten Domäne zurücksichern. Das ist angenehmerweise simpel:

  • Zunächst sichern Sie das Starter-Gruppenrichtlinienobjekt. Sie können dazu die Schaltfläche Als CAB-Datei speichern nutzen, die sich am Fuß des Starter-Gruppenrichtlinienobjekte-Dialogs befindet. Eingegeben wird ein simpler Dateiname, der Speicherort ist beliebig (Abbildung 8.116).
  • Beim Laden des Starter-Gruppenrichtlinienobjekts wird die gesicherte CAB-Datei herangezogen. Der in Abbildung 8.117 gezeigte Dialog ermittelt einige grundlegende Angaben aus der CAB-Datei und kann über die Schaltfläche Einstellungen anzeigen sogar eine Art »Preview« des zu ladenden Objekts ausgeben.

Abbildung 8.116 Das Starter-Gruppenrichtlinienobjekt kann als CAB-Datei gespeichert werden.

Abbildung 8.117 Eine Wiederherstellung des Starter-Gruppenrichtlinienobjekts ist ebenfalls einfach möglich. Vor der Wiederherstellung kann man sich mittels »Einstellungen anzeigen« einen Überblick darüber verschaffen, was überhaupt »drinsteht«.


Galileo Computing - Zum Seitenanfang

8.4.10 ADM vs. ADMX Zur nächsten ÜberschriftZur vorigen Überschrift

Mit administrativen Vorlagen können beliebige Registry-Einstellungen in das »Gruppenrichtlinien-System« eingefügt werden. Der vermutlich häufigste Verwendungsfall sind die Gruppenrichtlinien-Vorlagen für Microsoft Office, die Tausende von Konfigurationsmöglichkeiten bieten, mit denen alle Office-Installationen von einer zentralen Stelle, nämlich vom Administrator-PC aus, konfiguriert werden können.

Seit nunmehr knapp 9 Jahren, genauer gesagt seit Februar 2000 mit der Einführung von Windows 2000, werden die administrativen Vorlagen in *.ADM-Dateien gespeichert. Das funktioniert zwar, hat aber einige entscheidende Nachteile, beispielsweise:

  • Die *.ADM-Dateien bieten keine Mehrsprachigkeit.
  • Es gibt keine zentrale Ablage für die administrativen Vorlagen.
  • In Zeiten, in denen im Wesentlichen alles in XML-Dokumenten gespeichert wird, wirkt das alte ADM-Format etwas »behäbig«.

Mit der Einführung von Windows Vista und Windows Server 2008 hat Microsoft die administrativen Templates in ein neues XML-basiertes Format überführt, nämlich in die ADMX-Dateien.

Bei den ersten Schritten in der Gruppenrichtlinienverwaltungsapplikation haben Sie zunächst vermutlich noch nichts von ADMX-Dateien mitbekommen. Trotzdem sollten und müssen Sie einige Hintergründe kennen, unter anderem deshalb, weil Sie einen zentralen Speicherort einrichten müssen – das ist nichts Dramatisches, aber ein wenig Beschäftigung mit dem Thema ist unvermeidbar.


ADMX-Dateien

Falls Sie die Verwaltungswerkzeuge für das Active Directory auf einem Administrator-PC und nicht auf einem Server laufen lassen, müssen Sie diesen mindestens auf Windows Vista aktualisieren und die dort installierbaren Verwaltungswerkzeuge einsetzen. Für Windows 7 gibt es übrigens eine eigene Version der Remoteserver-Verwaltungswerkzeuge.

Die »alten« Verwaltungswerkzeuge können nicht mit den neuen ADMX-Dateien umgehen.

An dieser Stelle sei noch darauf hingewiesen, dass es sich bei den ADMX-Dateien (genauso wie bei den ADM-Dateien) um Richtlinienvorlagen handelt. Die resultierenden Richtlinien, die dann letztendlich auf PCs und Server angewendet werden, blieben unverändert und finden sich in den *.POL-Dateien (vergleiche Abbildung 8.94).

Ich werde manchmal gefragt, ob die Verwendung von ADMX-Dateien dazu führt, dass Windows 2000- und XP-Clients keine Gruppenrichtlinien mehr empfangen können: Die Antwort ist ganz eindeutig »Nein«, denn es ändert sich »nur« etwas am Vorlagenformat und nichts an den vom Computer geladenen Richtlinien.


Kurze ADMX-Inspektion

Beim Blick in eine ADMX-Datei fällt zunächst auf, dass es sich um ein XML-Dokument handelt. Die meisten Administratoren sind zwar aus irgendwelchen mystischen Gründen von XML-Dokumenten recht wenig begeistert – aber es hilft ja nichts. Unabhängig von eventuellen Ressentiments sind die XML-Dokumente nach meinem Geschmack wesentlich besser zu handhaben als strukturlose Textdateien, was aber auch eine Frage des Werkzeugs ist, mit dem man sie bearbeitet.

Abbildung 8.118 zeigt eine ADMX-Datei, in der lediglich eine Einstellung vorgenommen wird. Der inhaltlich entscheidende Teil findet sich im Abschnitt <policies>, wobei in diesem Fall nur ein <policy>-Objekt vorhanden ist. Folgende Informationen sind in diesem enthalten:

  • Es hat zunächst einen Namen, nämlich DFSDiscoverDC.
  • Es handelt sich um Computerrichtlinie, was man an class="Machine" erkennt. Alternative Werte sind User und Both.
  • Der Anzeigename und die Beschreibung (displayName, explainText) sind in diesem XML-Dokument nicht vorhanden, es sind lediglich Verweise angegeben. Die anzuzeigenden Texte finden sich in einer separaten Datei (*.adml), die in mehreren Sprachversionen vorliegen kann. Der Wert des Attributs presentation verweist ebenfalls auf einen Knoten in der *.adml-Datei; dort werden die lokalisierten Namen der Eingabeelemente hinterlegt.
  • Der Attribut-Wert key definiert den Pfad in der Registry.
  • Unter parentCategory wird angegeben, wo in der Baumdarstellung diese Richtlinie angezeigt werden soll, nämlich unterhalb des Knotens Netzwerk (windows:Network).
  • Weiterhin findet sich unterhalb von supportedOn die Angabe, ab welcher Betriebssystemversion diese Einstellung vorgenommen werden kann.
  • Im Abschnitt <elements> können beliebig viele vom Benutzer anzugebende Werte definiert werden, also die Werte, die dann letztendlich in die Registry geschrieben werden. Auch hierzu werden in der *.adml-Datei lokalisierte Beschreibungen vorgehalten.

Die *.adml-Dateien liegen in einem Ordner unterhalb des eigentlichen Richtlinienverzeichnisses. Wie ein wenig später noch genauer gezeigt wird, gibt es für jede Kultur ein separates Verzeichnis. Die Kultur besteht letztendlich auch zwei Angaben, der Sprache und der Region. Im deutschen Sprachraum gibt es folgende Kulturen:


de-AT

0x0C07

Deutsch (Österreich)

de-DE

0x0407

Deutsch (Deutschland)

de-LI

0x1407

Deutsch (Liechtenstein)

de-LU

0x1007

Deutsch (Luxemburg)

de-CH

0x0807

Deutsch (Schweiz)


Abbildung 8.118 Eine ADMX-Datei, in der eine Einstellung definiert ist

Bei einem deutschsprachigen Windows Server 2008 oder Vista (oder höher) existieren zwei Sprachverzeichnisse, nämlich de-DE und en-US. Abbildung 8.119 zeigt die *.adml-Datei, die die zuvor gezeigte *.admx-Datei um die deutschsprachigen Einträge ergänzt. Sie finden dort die Elemente, auf die in der *.admx-Datei verwiesen wird.

Abbildung 8.119 … und die zugehörige deutsche Sprachdatei

Im Gruppenrichtlinenverwaltungswerkzeug sehen Sie den Konfigurationsdialog der Richtlinie; erwartungsgemäß finden sich alle Elemente, die in der *.admx- und *.adml-Datei vorhanden sind, hier wieder.

Abbildung 8.120 Das Ergebnis in der Gruppenrichtlinienverwaltungsapplikation

Ablageorte und den zentralen Speicherort einrichten

Nun stellt sich die unausweichliche Frage, wo die *.admx- und *.adml-Dateien abgelegt werden. Da häufig eine weitere Forderung ist, dass die Gruppenrichtlinien nicht »nur« auf einem Domänencontroller bearbeitet werden können, sondern auch auf dem unter Vista oder Windows 7 laufenden Administrator-PC, wird diese Frage umso interessanter.

Auf einem Windows Server 2008- oder Windows Vista-Computer (und höher) existiert ein Verzeichnis c:\windows\PolicyDefinitions, in dem die standardmäßigen *.admx- und *.adml-Dateien liegen. Im Klartext bedeutet das, dass das Gruppenrichtlinienverwaltungswerkzeug jeweils auf die lokalen Vorlagen zurückgreift. Solange Sie »nur« mit den Standardvorlagen arbeiten, ist das kein Problem; wenn Sie allerdings zusätzliche Vorlagen (z. B. für Microsoft Office oder »selbst gemachte« Vorlagen) verwenden, wäre es einigermaßen lästig, die Vorlagendateien kopieren zu müssen.


Nur die Vorlagen

Um auch an dieser Stelle Missverständnissen vorzubeugen: Es geht hier »nur« um die Vorlagen. Die eigentlichen Richtlinien (*.pol-Datei etc. – siehe Abbildung 8.94) werden unabhängig vom Vorhandensein der Richtliniendatei zwischen den Domänencontrollern repliziert und finden sich im SYSVOL-Verzeichnis.


Abbildung 8.121 Standardmäßig liegen die *.admx- und *.adml-Dateien auf einem Windows Vista- und einem Windows Server 2008-System (und höher) genau an dieser Stelle im Verzeichnisbaum.

Wesentlich schöner wäre es natürlich, wenn die Richtlinienvorlagen an einem zentralen Speicherort lägen, auf den dann das Gruppenrichtlinienverwaltungswerkzeug zugreift. Dies ist zwar vorgesehen, standardmäßig aber nicht implementiert.

Das Einrichten des zentralen Speicherorts ist schnell erledigt. Kopieren Sie den kompletten PolicyDefinitions-Ordner in das Verzeichnis c:\windows\SYSVOL\domain\Policies. Das Ergebnis muss dann wie in Abbildung 8.122 gezeigt aussehen.

Abbildung 8.122 Um einen zentralen Speicherort für die Vorlagen (ADMX, ADML) einzurichten, legen Sie den »PolicyDefinitions«-Ordner unterhalb des Verzeichnisses »c:\windows\SYSVOL\domain\Policies« an.

Wenn Sie nun zusätzliche Vorlagen installieren möchten, kopieren Sie die zugehörigen Dateien ebenfalls an diesen zentralen Speicherort. Ich führe Ihnen das am Beispiel von Office 2007 vor:

  • Im Microsoft Download-Center erhalten Sie ein knapp 10 MB großes Paket namens Administrative Vorlagendateien (ADM, ADMX, ADML) für 2007 Office System und Office-Anpassungstool Version 2.0.
  • Entpacken Sie das Paket in ein beliebiges (temporäres) Verzeichnis. Es enthält unter anderem den Ordner ADMX, in dem sich sowohl die eigentlichen Vorlagendateien als auch neun Ordner mit Sprachdateien befinden (Abbildung 8.123).
  • Den Inhalt (!) des ADMX-Ordners kopieren Sie an den gemeinsamen Speicherort, wobei Sie natürlich nicht sämtliche Sprachen mitkopieren müssen.
    • Um Missverständnisse zu vermeiden: Vereinfacht gesagt müssen die Office-ADMX-Dateien bei den »ursprünglichen« ADMX-Dateien liegen, und die ADML-Dateien kommen in die bereits vorhandenen Sprachverzeichnisse zu den bereits vorhandenen AMDL-Dateien.

Abbildung 8.123 Das Vorlagenpaket für Office 2007 enthält ADMX-Dateien für die Applikationen nebst ADML-Dateien in neun Sprachen.

Wenn Sie auf einer beliebigen Windows Server 2008-Maschine oder einem Vista-Client (oder höher) den Gruppenrichtlinienverwaltungs-Editor starten, werden Sie zwei Feststellungen treffen können (Abbildung 8.124):

  • Alle an den zentralen Speicherort kopierten Vorlagen werden angezeigt.
  • Beim Knoten Administrative Vorlagen wird angezeigt, dass die Richtliniendefinitionen vom »zentralen Computer« abgerufen worden sind, also aus dem SYSVOL-Verzeichnis des Domänencontrollers, mit dem das Werkzeug arbeitet.

Abbildung 8.124 Der auf einem Vista-Client gestartete Gruppenrichtlinienverwaltungs-Editor zeigt automatisch alle im zentralen Speicherort installierten Vorlagen an (funktioniert natürlich analog auch unter Windows 7).

Aktuelle und vollständige Windows Server 2008-ADMX-Dateien

Wenn Sie eine deutsche Windows Server 2008-Version installiert haben, werden zwar die Sprachverzeichnisse de-DE und en-US vorhanden sein, das englische Verzeichnis ist aber leer. Falls Sie also die englischen oder auch weitere Sprachdateien benötigen, hilft Ihnen das Microsoft Download Center, in dem ein entsprechendes Paket zum Download bereitsteht. Abbildung 8.125 hilft beim Suchen bzw. Finden.

ADM-Dateien migrieren

Wenn Sie eigene ADM-Dateien erstellt haben oder Produkte einsetzen, zu denen solche Vorlagen mitgeliefert worden sind, werden Sie sich fragen, wie nun die weitere Vorgehensweise ist. Sie haben zwei Möglichkeiten:

  • Die »alten« ADM-Dateien werden von den Windows Server 2008-Gruppenrichtlinienverwaltungswerkzeugen unterstützt. Das Einfügen einer auf einer ADM-Datei beruhenden Gruppenrichtlinie erfolgt wie unter Windows Server 2003.
  • Der im Allgemeinen »bessere Weg« ist aber, die ADM-Datei in eine ADMX-Datei umzuwandeln.

Angenehmerweise müssen Sie die ADM-Datei nicht von Hand in eine ADMX-Datei konvertieren, da freundliche Menschen entsprechende Werkzeuge entwickelt haben. Zu diesen freundlichen Menschen gehören die Mitarbeiter der Firma FullArmor, die mit dem ADMX Migrator genau das passende Werkzeug entwickelt haben. Es ist im Microsoft Download Center erhältlich. Sie finden es, wenn Sie nach »ADMX Migrator« suchen.

Abbildung 8.125 Die komplette Sammlung an ADMX- und ADML-Dateien für Windows Server 2008 finden Sie im Download Center.

Die Installation läuft assistentenbasiert ab, es gibt dazu keine weiteren Anmerkungen (Abbildung 8.126). Die Installation ist übrigens auch auf dem Administrator-PC möglich, Sie brauchen also nicht auf Ihrem schönen Domänencontroller zu installieren.

Abbildung 8.126 Den ADMX-Migrator gibt es im Microsoft Download Center.

Um eine ADM-Datei zu konvertieren, starten Sie den ADMX Migrator und wählen im Kontextmenü den Menüpunkt Generate ADMX from ADM (Abbildung 8.127). Es wird sich ein Dialog zur Auswahl der ADM-Datei öffnen. Nach dem Selektieren der Datei beginnt die Konvertierung. Am Ende werden gegebenenfalls einige Warnungen angezeigt, beispielsweise zu nicht korrekt gesetzten Standardwerten oder dergleichen. Zuletzt erscheint der Dialog aus Abbildung 8.128, in dem angegeben wird, wo genau die neu erzeugten Dateien zu finden sind – nämlich in einem zufällig benannten Verzeichnis im temporären Ordner des angemeldeten Benutzers.

Abbildung 8.127 Der Konvertierungsvorgang beginnt im Kontextmenü.

Abbildung 8.128 Die konvertierten Datein werden in einem zufällig benannten Unterordner des Benutzer-Temp-Verzeichnisses angelegt.

Wenn Sie die erzeugte Vorlage in dem ADMX-Editor laden lassen (siehe die Auswahl in Abbildung 8.128), erhalten Sie in etwa die in Abbildung 8.129 gezeigte Ansicht. Sie können die Einstellungen anschauen und gegebenenfalls editieren.

Wenn man ein wenig »hinter die Kulissen« schaut, genauer gesagt in das Verzeichnis, in dem die neue Vorlage angelegt wurde, sieht man das bekannte Bild: Es ist eine ADMX-Datei vorhanden, außerdem befindet sich die zugehörige ADML-Datei in einem gemäß der Sprache benannten Ordner (Abbildung 8.130).

Abbildung 8.129 Ein Blick in die konvertierte Vorlage. Auf Wunsch können Sie sie auch bearbeiten.

Abbildung 8.130 Es wurde übrigens eine ADMX-Datei nebst einer ADML-Datei im »Kultur«-Verzeichnis erzeugt.

Im Kontextmenü der neu erzeugten Vorlage findet sich der Menüpunkt Save As, mit dem Sie die Dateien in einem etwas »benutzerfreundlicheren« Ordner speichern können (d. h. in einem Ordner, der leichter zu finden ist). Der Dialog ermöglicht die Auswahl der Sprache, womit Sie letztendlich den Namen des Ordners der ADML-Datei beeinflussen (Abbildung 8.131).

Abbildung 8.131 Beim Speichern können Sie die Sprache angeben.

Es stellt sich nun noch die Frage, wohin die erzeugten Dateien nun kopiert werden müssen. Die Antwort ist zweigeteilt:

  • Wenn Sie einen zentralen Speicherort für die Vorlagen eingerichtet haben, werden die Dateien dort hineinkopiert (siehe die Ausführungen im vorherigen Abschnitt).
  • Falls Sie aus irgendwelchen Gründen keinen zentralen Speicherort eingerichtet haben, kommen die Dateien in das Verzeichnis c:\windows\PolicyDefinitions.

Das Gruppenrichtlinienverwaltungswerkzeug wird die neue Vorlage direkt anzeigen, und Sie können darauf basierende neue Gruppenrichtlinien anlegen.

Eigene ADMX-Dateien erstellen

Wenn Sie eigene ADMX-Dateien erstellen möchten, können Sie das entweder »zu Fuß« erledigen oder aber Sie verwenden den ADMX Migrator (Abbildung 8.132). Bei der Arbeit mit diesem beginnt das Erstellen einer eigenen Vorlage mit dem Befehl New Template im Kontextmenü (Abbildung 8.132).

Abbildung 8.132 Auch eigene ADMX-Vorlagen können bequem mit dem ADMX Migrator erstellt werden.

Nachdem Sie einen Namen für die neue Vorlage eingegeben haben, befindet sich ADMX Migrator direkt im »Arbeitsmodus« (Abbildung 8.133): Hier können Sie nun zunächst einige grundlegende Einstellungen zur Vorlage vornehmen, beispielsweise auch, für welche Betriebssysteme sie gültig ist (Supported On).

Abbildung 8.133 Und so füllt sich das eigene Template allmählich mit Leben.

Als Nächstes erzeugen Sie Kategorien (New Category) und darin wieder weitere Kategorien und/oder Einstellungen (New Policy Setting).

Da die maximale Seitenzahl für dieses Buch beschränkt ist, möchte ich jetzt nicht in epischer Breite vorführen, wie eine neue ADMX-Datei im ADMX Migrator erzeugt wird. Wenn Sie wissen, welche Registry-Einstellungen die Richtlinie modifizieren soll und sich ein wenig mit ADMX Migrator beschäftigen, werden Sie recht schnell zum gewünschten Erfolg kommen.


Galileo Computing - Zum Seitenanfang

8.4.11 Zuweisen und Bearbeiten von Gruppenrichtlinien Zur nächsten ÜberschriftZur vorigen Überschrift

In Windows 2000 Server und Windows Server 2003 konfigurierte man die Gruppenrichtlinien im Eigenschaftendialog des Objekts (Domäne, OU, Standort) im Active Directory-Benutzer und -Computer-Snap-In (bzw. im Standorte und Dienste-Snap-In für die Standortrichtlinie). Man konnte zwar das gewünschte Ergebnis erreichen, es war aber nicht wirklich komfortabel. Microsoft hat dann die Group Policy Management Console (GPMC) zum Download bereitgestellt – alle, die viel mit Gruppenrichtlinien gearbeitet haben, dürften dieses Werkzeug verwendet haben.

Mit Windows Server 2008 ist der »alte Weg«, also die Verwaltung der Gruppenrichtlinien im Active Directory-Benutzer und -Computer-Snap-In nicht mehr möglich (in den Beta-Versionen ging das übrigens noch). Stattdessen arbeitet man mit dem Nachfolger der Group Policy Management Console (GPMC) – und das Teil heißt jetzt Gruppenrichtlinienverwaltung. Es ist auf einem Windows Server 2008-Domänencontroller standardmäßig vorhanden. Auf einem Vista-PC steht es zur Verfügung, wenn Sie die Windows Server 2008-Administrationswerkzeuge installieren (erhältlich im Microsoft Download Center). Für Windows 7 gibt es eine eigene Version der Remoteserver-Verwaltungstools.

Wenn Sie die vorherigen Seiten des Kapitels durchgearbeitet haben, wird Ihnen die Gruppenrichtlinienverwaltung bereits mehrfach auf Abbildungen begegnet sein; aber, weil es so schön ist, zeige ich sie Ihnen nochmals zum Einstieg in das Thema – also genießen Sie den wunderschönen Anblick in Abbildung 8.134.

Abbildung 8.134 Die Gruppenrichtlinienverwaltung – hier auf einem Windows Vista-PC.


Hinweis zur Abbildung

Die Abbildung ist übrigens auf einem Windows Vista-PC entstanden, den ich als Admin-PC für die Windows Server 2008-Umgebung verwende. Da ich Ihnen alle Schritte dieses Abschnitts auf dieser Maschine zeigen werde, erbringe ich auch gleich noch den Beweis, dass es absolut nicht notwendig ist, sich zu Administrationszwecken auf dem Server anzumelden.


Auch wenn Sie bislang nicht mit der GPMC gearbeitet haben, wird Ihnen die Arbeit mit der Gruppenrichtlinienverwaltung leicht von der Hand gehen – eventuell brauchen Sie eine kleine Eingewöhungszeit, aber die wird nicht sehr schmerzhaft sein.


Bitte beachten

Bei der Arbeit mit der Gruppenrichtlinienverwaltung gibt es letztendlich einen Aspekt, den Sie sich vor Augen halten müssen. Ein Gruppenrichtlinienobjekt »klebt« niemals direkt an einer Domäne, einer OU oder einem Standort. Es gibt »nur« Verknüpfungen zu Gruppenrichtlinienobjekten, wobei ein solches durchaus mit mehreren OUs verknüpft werden kann.

Viele Administratoren von kleineren Umgebungen, die bisher nicht mit der GPMC gearbeitet haben, tun sich mit diesem Zusammenhang schwer und finden die Gruppenrichtlinienverwaltung daher unhandlich. Hilft nix, da müssen Sie durch! Zum Ausschneiden und Über-den-Schreibtisch- oder noch besser Über-das-Bett-Hängen wiederhole ich ausnahmsweise eine Abbildung und zeige Ihnen die Zusammenhänge anhand von Abbildung 8.135.


Abbildung 8.135 Eine Domäne bzw. eine Organisationeinheit oder ein Standort ist mit den Gruppenrichtlinienobjekten »nur« verknüpft.

Gruppenrichtlinienobjekte anlegen und bearbeiten

Der erste Schritt ist das Anlegen eines Gruppenrichtlinienobjekts. Es gibt hierzu prinzipiell zwei Möglichkeiten:

  • Sie navigieren zum Container Gruppenrichtlinienobjekte innerhalb der Domäne. In seinem Kontextmenü finden Sie den Menüpunkt Neu. Beim Neu-Anlegen des Gruppenrichtlinienobjekts können Sie zunächst den Namen auswählen, außerdem kann ein Starter-Gruppenrichtlinienobjekt (eine Art Vorlage, siehe weiter vorn) angegeben werden (Abbildung 8.136).
  • Die zweite Möglichkeit ist, im Kontextmenü einer Organisationseinheit den Menüpunkt Gruppenrichtlinienobjekt hier erstellen und verknüpfen zu wählen. Das Gruppenrichtlinienobjekt wird dabei ebenfalls im Container Gruppenrichtlinienobjekte erstellt, allerdings wird direkt eine Verknüpfung zur Organisationseinheit erstellt. Verknüpfungen zu weiteren OUs können natürlich später ebenfalls angelegt werden.

Abbildung 8.136 Erstellen eines neuen Gruppenrichtlinienobjekts

Das neu angelegte Gruppenrichtlinienobjekt ist bisher absolut wertlos. An diesem Zustand können Sie aber leicht etwas ändern, indem Sie Einstellungen darin vornehmen. Zum Bearbeiten des Gruppenrichtlinienobjekts führen zwei Wege:

  • Sie können im Container Gruppenrichtlinienobjekte den Menüpunkt Bearbeiten im Kontextmenü des jeweiligen Eintrags wählen (Abbildung 8.137).
  • Wenn Sie eine Organisationeinheit ausgewählt haben und die Verknüpfungen zu den Gruppenrichtlinienobjekten vor sich sehen, führt der Menüpunkt Bearbeiten der Verknüpfung ebenfalls zum Gruppenrichtlinienobjekt-Editor und somit zum Bearbeiten der Einstellungen.

Hinweis aus der Praxis

Sie können natürlich sämtliche Einstellungen in einem Gruppenrichtlinienobjekt vornehmen. Kein Problem, das funktioniert; es ist aber nicht sonderlich übersichtlich, und die Wiederverwendbarkeit des Gruppenrichtlinienobjekts ist gering. Ich empfehle meinen Kunden, lieber mehrere Gruppenrichtlinien mit thematisch zusammenhängenden Einstellungen, also eine mit Desktop-Einstellungen, eine mit Word-Einstellungen etc. anzulegen. Auf diese Weise bleibt das einzelne Gruppenrichtlinienobjekt übersichtlich und kann mit verschiedenen Organisationseinheiten verknüpft werden – auch in verschiedenen Kombinationen: Beispielsweise kann das Word-Gruppenrichtlinienobjekt für eine bestimmte Organisationseinheit mit einem weniger restriktiven Desktop-Gruppenrichtlinienobjekt kombiniert werden.

Weiterhin ist es häufig ratsam, getrennte Gruppenrichtlinienobjekte für Computer- und Benutzereinstellungen anzulegen.


Abbildung 8.137 Die Bearbeitung des Gruppenrichtlinienobjekts wird im Kontextmenü aufgerufen.

Das eigentliche Bearbeiten des Gruppenrichtlinienobjekts erfolgt im Gruppenrichtlinienverwaltungs-Editor. Hier finden sich die verschiedenen Einstellungen für Computer und Benutzer. Sie haben bereits standardmäßig die Auswahl aus Tausenden von Einstellungen, und durch administrative Vorlagen können beliebige weitere hinzugefügt werden – beispielsweise für das Office-Paket.

Das Bearbeiten von Einstellungen ist in Abbildung 8.138 gezeigt – das dürfte selbsterklärend sein.

Abbildung 8.138 Konfiguration der Einstellungen im Gruppenrichtlinienverwaltungs-Editor

Wenn Sie den Gruppenrichtlinienobjekt-Editor wieder verlassen (ein explizites Speichern ist nicht notwendig), können Sie auf der Registerkarte Einstellungen der Gruppenrichtlinienverwaltung die Zusammenfassung der konfigurierten Einstellungen einsehen (Abbildung 8.139).

Abbildung 8.139 Eine Zusammenfassung der Einstellungen kann hier angezeigt werden.

Abbildung 8.140 Auf der Karteikarte »Delegierung« wird festgelegt, welche Benutzer Berechtigungen haben.

Natürlich ist es auch interessant, wer ein Gruppenrichtlinienobjekt überhaupt konfigurieren kann – diese Einstellungen finden Sie auf der Registerkarte Delegierung, die in Abbildung 8.140 zu sehen ist. Einträge hinzuzufügen ist kein Problem, es sei aber dringend darauf hingewiesen, dass Sie die Einträge SYSTEM und DOMÄNENCONTROLLER DER ORGANISATION keinesfalls entfernen dürfen.

Verknüpfungen hinzufügen und bearbeiten

Wenn das Gruppenrichtlinienobjekt erstellt ist und die Einstellungen konfiguriert sind, müssen Sie noch dafür sorgen, dass es auch tatsächlich angewendet wird. Dazu verknüpfen Sie es mit Organisationseinheiten, der Domäne und/oder mit Standorten. Um eine Organisationseinheit mit einem vorhandenen Gruppenrichtlinienobjekt zu verknüpfen, wählen Sie im Kontextmenü der OU den Menüpunkt Vorhandenes Gruppenrichtlinienobjekt verknüpfen (Abbildung 8.141).

Abbildung 8.141 Im Kontextmenü der Organisationseinheit wird die Verknüpfung zu einem Gruppenrichtlinienobjekt erstellt.

Daraufhin erscheint eine Auflistung der vorhandenen Gruppenrichtlinienobjekte, und Sie können eines oder mehrere auswählen – und schon ist die Verknüpfung erstellt und aktiv (Abbildung 8.142).

Auf der Registerkarte Verknüpfte Gruppenrichtlinienobjekte einer Organisationseinheit, Domäne oder eines Standorts sind alle Objekte aufgeführt, wobei die Reihenfolge entscheidend ist. Das Objekt mit der kleinsten Zahl wird zuletzt ausgeführt, hat also die höchste Priorität, falls unterschiedliche Werte für dieselbe Einstellung festgelegt worden sind – eine Ausnahme ist, dass eine Verknüpfung als Erzwungen gekennzeichnet ist (Abbildung 8.143).

Abbildung 8.142 Auswahl des zu verknüpfenden Gruppenrichtlinienobjekts

Abbildung 8.143 In der Liste der Verknüpfungen wird auch die Reihenfolge der Anwendung festgelegt.

Eine Verknüpfung verfügt über ein Kontextmenü, aus dem ich drei Menüpunkte speziell erwähnen möchte (Abbildung 8.144):

  • Bearbeiten öffnet das Gruppenrichtlinienobjekt zur Bearbeitung. Die Änderungen gelten dann für sämtliche Verknüpfungen, die auf das Gruppenrichtlinienobjekt verweisen.

Abbildung 8.144 Im Kontextmenü der Verknüpfung können Sie diese unter anderem auch deaktivieren.

  • Wird eine Verknüpfung mit Erzwungen markiert, bedeutet das, dass die von ihr vorgenommenen Einstellungen von später verarbeiteten Gruppenrichtlinienobjekten nicht überschrieben werden können. Dies wurde weiter vorn in Abschnitt 8.4.4 erläutert.
  • Mit dem Menüpunkt Verknüpfung aktiviert können Sie die Verarbeitung der Gruppenrichtlinie für die jeweilige OU oder Domäne bzw. den jeweiligen Standort ein- und ausschalten.

Gruppenrichtlinienmodellierung

In komplexen Szenarien mit vielen Gruppenrichtlinien, die in einer umfangreichen OU-Struktur verarbeitet werden, kann die Übersicht leicht verloren gehen. Angenehmerweise bietet die Gruppenrichtlinienverwaltung Werkzeuge an, mit denen man recht bequem prüfen kann, welche Richtlinien zur Anwendung kommen. Eines davon ist die Gruppenrichtlinienmodellierung.

Das grundsätzliche Konzept dahinter ist, dass mit einem Assistenten Szenarien erstellt werden, die bei Bedarf, also nach Änderungen, neu »errechnet« werden können. Ausgangspunkt ist also die Erstellung eines solchen Szenarios, was Sie wie in Abbildung 8.145 beginnen.

Abbildung 8.145 Aufruf des Gruppenrichtlinienmodellierungs-Assistenten

Die erste Dialogseite sehen Sie in Abbildung 8.146. Sie können hier bestimmen, ob die Simulation auf einem beliebigen DC ausgeführt werden soll oder ob Sie ein bestimmtes System festlegen möchten. Sofern Sie nicht von Replikationsproblemen (oder sehr langsamer Replikation) ausgehen, sollten Sie den DC ruhig automatisch ermitteln lassen, sonst wählen Sie eine Maschine auf der Auswahlliste aus.

Die nächsten Dialogseiten beschäftigen sich damit, Benutzerinformationen und Computerinformationen festzulegen (Abbildung 8.147, links). Sie können entweder einen bestimmten Benutzer/Container auswählen oder sich für Organisationseinheiten entscheiden.

Da auch an Standorten Richtlinien »kleben« können, wählen Sie auf der folgenden Dialogseite (Abbildung 8.147, rechts) einen Standort aus. Weiterhin können Sie eine Loopback-Verarbeitung (sie werden häufig in Terminal Server-Umgebungen verwendet, siehe Abschnitt 8.4.14) und/oder eine langsame Verbindung konfigurieren.

Abbildung 8.146 Der Gruppenrichtlinienmodellierungs-Assistent. Zunächst wird entschieden, auf welchem Domänencontroller die Simulation durchgeführt werden soll.

Abbildung 8.147 In diesen Dialogen wählen Sie Benutzer, Computer und Standort.

Durchaus interessant bei der Gruppenrichtlinienmodellierung sind die WMI-Filter, die auch auf einer dedizierten Dialogseite ausgewählt werden können (Abbildung 8.148). Falls (noch) keine Filter vorhanden sind, brauchen Sie sich keine Gedanken zu machen, es klappt trotzdem. Überhaupt verfügen alle Dialogseiten des Assistenten mit Ausnahme der ersten über die Option Zur letzten Seite des Assistenten wechseln, ohne … Es ist also keinesfalls erforderlich, dass Sie jede einzelne der Dialogseiten (und das sind einige!) durcharbeiten.

Abbildung 8.148 Die auszuführenden WMI-Filter können festgelegt werden.

Ein Ergebnis der Gruppenrichtlinienmodellierung ist auf der Registerkarte Zusammenfassung zu sehen (Abbildung 8.149).

Abbildung 8.149 Ergebnis der Gruppenrichtlinienmodellierung

Unter anderem sehen Sie hier, welche Gruppenrichtlinienobjekte für die Computer- und die Benutzerkonfiguration herangezogen worden sind. Falls Sie die konkret angewendeten Einstellungen sehen möchten, wechseln Sie auf die Registerkarte Einstellungen (Abbildung 8.150).

Abbildung 8.150 Die angewendeten Einstellungen können im Detail betrachtet werden.

Das mit dem Assistenten erstellte Gruppenrichtlinienmodellierungs-Objekt enthält sozusagen eine Momentaufnahme, zeigt also das Verarbeitungsergebnis zu dem Zeitpunkt, als es erzeugt wurde. Im Kontextmenü findet sich der Menüpunkt Abfrage erneut ausführen, womit die Ergebnisse dem aktuellen Zustand angepasst werden (Abbildung 8.151).

Abbildung 8.151 Die Abfrage kann bei Bedarf erneut ausgeführt werden.

Sie können also verschiedene Objekte anlegen, mit denen Sie regelmäßig die Ergebnisse der Gruppenrichtlinienverarbeitung überprüfen können.

Gruppenrichtlinienergebnisse

Ähnlich, aber »etwas anders« als die Gruppenrichtlinienmodellierung verhält sich die Funktion Gruppenrichtlinienergebnisse. Auch können mit einem Assistenten (Sie sehen den Aufruf in Abbildung 8.152), beliebig viele unterschiedliche Einträge erzeugt werden.

Abbildung 8.152 Hier wird der Gruppenrichtlinienergebnis-Assistent gestartet.

Die Computer- und Benutzerauswahl beschränkt sich allerdings auf einen bestimmten Computer und einen konkreten Benutzer. Abbildung 8.153 zeigt die beiden relevanten Screenshots aus dem Gruppenrichtlinienergebnis-Assistenten.

Die Ergebnisse sehen Sie in zwei Abbildungen:

  • Abbildung 8.154 zeigt unter anderem die angewendeten und abgelehnten Gruppenrichtlinienobjekte – übrigens in der Reihenfolge der Verarbeitung.

Abbildung 8.153 Ein Computer und ein Benutzer können für die Simulation können angezeigt werden.

Abbildung 8.154 Dieser Dialog zeigt unter anderem die angewendeten Gruppenrichtlinienobjekte.

  • Abbildung 8.155 zeigt die konkreten Einstellungen, die aus der Verarbeitung der Gruppenrichtlinien resultieren.

Abbildung 8.155 Auch die einzelnen Einstellungen werden gezeigt.


Galileo Computing - Zum Seitenanfang

8.4.12 WMI-Filter Zur nächsten ÜberschriftZur vorigen Überschrift

Ich habe weiter vorn erwähnt, dass man die Abarbeitung von Gruppenrichtlinien durch Berechtigungen steuern kann, habe aber darauf hingewiesen, dass das nur im Ausnahmefall geschehen sollte – es wird einfach zu unübersichtlich.

Eine sehr interessante andere Möglichkeit, um festzulegen, ob eine Gruppenrichtlinie tatsächlich angewendet werden soll, ist die Steuerung mittels WMI-Filtern. WMI steht für Windows Management Instrumentation, einen Ansatz, über den unter anderem auf Konfigurationsinformationen eines Computers zugegriffen werden kann. Mit WMI-Filtern lässt sich beispielsweise steuern, dass ein Gruppenrichtlinienobjekt nur auf Computern mit einem »Genuine Intel«-Prozessor ausgeführt werden soll.

WMI-Filter werden unterhalb der Domäne im Container WMI-Filter gespeichert. Das Anlegen eines neuen Filters geschieht wie erwartet im Kontextmenü (Abbildung 8.156).

Abbildung 8.156 WMI-Filter werden in diesem Container gespeichert. Im Kontextmenü wird das Neu-Erstellen aufgerufen.

Beim WMI-Filter gibt es prinzipiell nur wenig einzustellen: seinen Namen, eine Beschreibung und die Abfragen. Wie Sie in Abbildung 8.157 sehen, verwendet die Abfragesprache eine SQL-ähnliche Syntax. Es handelt sich um die WMI Query Language (WQL).

Abbildung 8.157 Ein WMI-Filter basiert primär auf einer Abfrage.

Ich möchte an dieser Stelle nicht im Detail auf die WQL eingehen, da ich Ihnen ein wenig weiter hinten ein kleines Werkzeug vorstelle, mit dem Sie recht einfach Abfragen erzeugen können. Interessierten Lesern sei aber die Dokumentation in der MSDN empfohlen. Die entsprechende URL lautet: http://msdn.microsoft.com/en-us/library/aa394552.aspx.

Wenn Sie in der Baumdarstellung der Gruppenrichtlinienverwaltung ein Gruppenrichtlinienobjekt auswählen, wird die Registerkarte Bereich angezeigt. Im unteren Abschnitt können Sie einen WMI-Filter auswählen, der mit diesem Gruppenrichtlinienobjekt verknüpft werden soll. Ein WMI-Filter kann übrigens mit mehreren Gruppenrichtlinienobjekten verknüpft werden.

Abbildung 8.158 Im unteren Abschnitt des Dialogs können Sie den Filter einem Gruppenrichtlinienobjekt zuweisen.

Wenn Sie die WMI-Filterung für ein Gruppenrichtlinienobjekt festgelegt haben, können Sie die Gruppenrichtlinienmodellierung starten und die Ergebnisse für eine OU (oder Domäne oder Standort) ermitteln, mit der dieses Gruppenrichtlinienobjekt verknüpft ist. Sie werden sehen, dass das Ergebnis des WMI-Filters berücksichtigt wird (Abbildung 8.159).

Abbildung 8.159 Der Ergebnis des WMI-Filters wird bei der Gruppenrichtlinienmodellierung berücksichtigt.


WMI-Filter

Beachten Sie, dass WMI-Filter nur auf Clients ab Windows XP ausgeführt werden können. Bei Windows 2000 stand diese Funktion noch nicht zur Verfügung.


Obwohl das Werkzeug zur Gruppenrichtlinienverwaltung dem Administrator das Leben schon ziemlich weitgehend vereinfacht, lässt es Sie beim Erzeugen von WMI-Filtern allein. Es gibt nun zwei Möglichkeiten: Entweder Sie wühlen sich durch die Dokumentation und können nach einiger Zeit auch komplexe WMI-Abfragen formulieren – oder Sie lassen sich von einem kleinen Werkzeug helfen.

Ich verwende den WMI Code Creator, der unter diesem Suchbegriff im Microsoft Download Center erhältlich ist. Dieses Werkzeug zielt zwar darauf, komplette Codefragmente zu erzeugen und nicht nur eine »simple« Abfrage, Letztgenannte »fällt« dabei natürlich auch »ab«.

In Abbildung 8.160 sehen Sie den WMI Code Creator in Aktion. Die Vorgehensweise dürfte weitgehend selbsterklärend sein, und auch wenn Sie noch nie eine Zeile C#-Code programmiert haben, werden Sie im Fenster Generated Code ganz problemlos die eigentliche Abfrage finden. Durch einen Klick auf die Schaltfläche Execute Code wird die Abfrage (genauer gesagt der erzeugte Code nebst Abfrage) ausgeführt und das Ergebnis in einem Textfenster angezeigt (Abbildung 8.161).

Abbildung 8.160 Abfragen können bequem mit dem WMI Code Creator erstellt werden.

Abbildung 8.161 Ein Klick auf die Schaltfläche »Execute Code« im WMI Code Creator führt zu diesem Ergebnis.

Die mit dem WMI Code Creator erzeugte Abfrage tragen Sie im WMI-Filter ein – und schon sind Sie fertig.


Galileo Computing - Zum Seitenanfang

8.4.13 Softwareverteilung mit Gruppenrichtlinien Zur nächsten ÜberschriftZur vorigen Überschrift

Mithilfe der Gruppenrichtlinien ist eine »begrenzte Softwareverteilung« möglich. Ich nenne sie deshalb »begrenzt«, weil die Möglichkeiten im Vergleich zu »großen« Lösungen, wie beispielsweise dem System Center Configuration Manager 2007 (vormals SMS), eher bescheiden sind. Ich kenne aber etliche größere mittelständische Unternehmen, die ausschließlich auf Softwareverteilung per Gruppenrichtlinie setzen und damit durchaus erfolgreich sind. Eine wesentliche Einschränkung ist, dass »nur« MSI-Pakete verteilt werden können; in anderen Formaten vorliegende Software muss umgepackt werden.

Wie Sie wissen, gibt es in den Gruppenrichtlinien Einstellungen für Computer und solche für Benutzer. Ebendies gilt auch für die Softwareinstallation. Sie können also Software sowohl an Computer als auch an Benutzer verteilen. Meist geht man ja davon aus, dass man ein Stück Software an die Computer PC1998, PC8837 und PC0007 verteilt, die Verteilung an Benutzer hat aber durchaus auch ihren Charme: Wenn die Vertriebsmitarbeiter beispielsweise Microsoft Dynamics CRM benötigen, verknüpft man die Vertriebs-OU mit der entsprechenden Gruppenrichtlinie, und dann wird auf einem Computer, auf dem ein Vertriebsmitarbeiter sich anmeldet, dieses Paket automatisch installiert. Ein unerwünschter Nebeneffekt könnte allerdings ein Lizenzproblem sein: Wenn Ihre Anwender fröhlich durchs Unternehmen wandern und sich hier und da anmelden, wird ständig das Softwarepaket installiert – und plötzlich haben Sie statt der lizenzierten 40 Installationen 140.

Um eine gruppenrichtlinienbasierte Softwareverteilung durchzuführen, benötigen Sie zunächst ein Gruppenrichtlinienobjekt, in dem der Installationsvorgang definiert ist. Hierzu navigieren Sie zum Knoten RichtlinienSoftWareeinstellungenSoftwareinstallation und wählen in dessen Kontextmenü den Menüpunkt NeuPaket. Abbildung 8.162 zeigt diesen Schritt für die Computerkonfiguration, in der Benutzerkonfiguration sieht es aber identisch aus.

Zunächst wird sich ein Dialog öffnen, in dem Sie das zu verteilende MSI-Paket auswählen können. Achten Sie darauf, dass es auf einer Dateifreigabe liegt und dass der Freigabepfad ausgewählt ist. Im Klartext: An d:\fileshares\softdist kommen die Computer im Netzwerk nicht heran, sondern nur an die entsprechende Freigabe \\ubinfFile1\softdistshare.

Abbildung 8.162 Die Softwareinstallation kann für Computer oder Benutzer konfiguriert werden.

Als Nächstes wählen Sie die Bereitstellungsmethode aus. Dabei stehen zwei Optionen zur Auswahl (Abbildung 8.163):

  • Veröffentlicht: Diese Option steht nur bei der Softwareinstallation in einer Benutzer-Gruppenrichtlinie zur Verfügung. Auf der Abbildung wird eine Computerrichtlinie erstellt, folglich ist sie also dort ausgegraut. Diese Bereitstellungsmethode bewirkt, dass die Software unter SystemsteuerungProgramme (Vista) bzw. SystemsteuerungSoftware (XP) angelegt und vom Benutzer installiert werden kann. Eine automatische Installation erfolgt also nicht.
  • Bei der Methode Zugewiesen wird die Software direkt installiert, also ohne Zutun des Benutzers.

Abbildung 8.163 Auswahl der Bereitstellungsmethode (die Option »Veröffentlicht« steht nur für eine Benutzerrichtlinie zur Verfügung).

Wenn Sie die dritte Option, Erweitert, wählen, gelangen Sie zum Eigenschaftendialog der Einstellung. Letztendlich wählen Sie dort auch zwischen Veröffentlicht und Zugewiesen aus, haben aber direkt zusätzliche Konfigurationsmöglichkeiten (Abbildung 8.164).

Abbildung 8.164 Der Eigenschaftendialog der Einstellung zur Softwareinstallation


WMI-Filter

Wenn Sie eine Softwareverteilung über Gruppenrichtlinien durchführen, werden Sie sehr dankbar für die WMI-Filter sein. Mit diesen haben Sie die Möglichkeit, die Installation etwas feiner zu steuern. So können Sie beispielsweise verhindern, dass Software auf PCs mit weniger als 512 MB Arbeitsspeicher installiert wird, oder dafür sorgen, dass die Installation nur durchgeführt wird, wenn auf dem C-Laufwerk mindestens 2 GB freier Speicherplatz vorhanden ist.



Galileo Computing - Zum Seitenanfang

8.4.14 Loopback-Verarbeitung Zur nächsten ÜberschriftZur vorigen Überschrift

Ein sehr wichtiger Aspekt bei der Gruppenrichtlinienkonfiguration, insbesondere im Terminalserver-Umfeld, ist der Loopback-Verarbeitungsmodus. Die Idee dahinter ist die folgende:

  • Wenn sich ein Benutzer anmeldet, werden die Richtlinien angewendet, die in der OU gelten, in der das Benutzerobjekt angelegt ist (nebst Vererbungen).
  • Beim Loopback-Verarbeitungsmodus verhält sich das System so, als befände sich das Benutzerobjekt in der OU, in der das Computerobjekt (d. h. der Terminalserver) angelegt ist. Es werden also die in den dort gültigen Gruppenrichtlinien vorhandenen Benutzerrichtlinien angewendet.

Kurz gesagt ermöglicht es der Loopback-Verarbeitungsmodus, dass auf Terminalservern für dieselben Benutzerobjekte andere Gruppenrichtlinien zum Einsatz kommen, als wenn sich diese auf einem Desktop-PC anmelden. In Umgebungen, in denen die Benutzer sowohl lokal installierte als auch über Terminaldienste bereitgestellte Anwendungen nutzen, kann dies außerordentlich praktisch sein.

Der Loopback-Verarbeitungsmodus wird mittels einer Gruppenrichtlinie für die entsprechenden Terminalserver aktiviert. Es macht vor diesem Hintergrund also Sinn, die Terminalserver in einer separaten OU anzusiedeln und eine entsprechende Gruppenrichtlinie zu erstellen (Abbildung 8.165).

Abbildung 8.165 Der Loopbackverarbeitungsmodus wird mittels einer Gruppenrichtlinie aktiviert.


Galileo Computing - Zum Seitenanfang

8.4.15 Gruppenrichtlinien-Voreinstellungen (Preferences) topZur vorigen Überschrift

Wenn Sie sich bereits mit Gruppenrichtlinien unter Windows Server 2003 beschäftigt haben, wird Ihnen aufgefallen sein, dass im Gruppenrichtlinienverwaltungs-Editor außer Richtlinien ein zusätzlicher Knoten namens Einstellungen vorhanden ist. Dieser findet sich sowohl in der Benutzer- als auch in der Computerkonfiguration.

Es handelt sich hierbei um die Voreinstellungen, in der englischsprachigen Dokumentation heißen sie Preferences. Im Gegensatz zu den »normalen« Gruppenrichtlinien geht es hierbei weniger darum, bestimmte Einstellungen zu erzwingen, sondern darum, diverse Voreinstellungen bereitzustellen. Auf diese Weise können und sollen die bislang für solche Zwecke verwendeten Login-Skripts eliminiert werden; weiterhin dürfte durch die Möglichkeit, diverse Voreinstellungen zu verteilen, die Notwendigkeit für verschiedene Images bei der PC-Installation entfallen.


Hinweis

Dieses Feature ist neben dem ADMX-Format die wesentliche Neuerung bezüglich der Gruppenrichtlinien in Windows Server 2008.

Die verwendete Technologie hat Microsoft übrigens durch die Akquisition der Firma DesktopStandard im Jahre 2006 erworben.

Als Clients können Windows XP SP2, Windows Server 2003 SP1 und alle späteren Versionen verwendet werden.


Die nachfolgende Tabelle gibt einen Überblick über die Unterschiede zwischen den klassischen Gruppenrichtlinien und den Voreinstellungen:


Kategorie Voreinstellung Richtlinie

Erzwingung

Einstellungen werden nicht erzwungen.

Die Konfigurationsmöglichkeit für den Benutzer bleibt erhalten.

Einstellungen werden entweder einmal angewendet oder regelmäßig erneuert.

Einstellungen werden erzwungen.

Die Konfigurationsmöglichkeit für die Benutzer ist nicht mehr vorhanden.

Einstellungen werden regelmäßig erneuert.

Flexibilität

Es können Einstellungen für Registry-Einstellungen, Dateien etc. vorgenommen werden.

Registry-Einstellungen können importiert werden.

Richtlinien zur Verwaltung von Dateien, Ordnern etc. können nicht erstellt werden.

Registry-Einstellungen müssen über administrative Vorlagen erzeugt werden.

Lokale Gruppenrichtlinie

Voreinstellungen sind in den drei lokalen Gruppenrichtlinien von Vista und Windows Server 2008 (und höher) nicht vorhanden.

Registry

Ursprüngliche Registry-Einstellungen werden überschrieben.

Das Entfernen der Voreinstellungen stellt die ursprünglichen Registry-Einstellungen nicht wieder her.

Ursprüngliche Registry-Einstellungen bleiben erhalten.

Wird eine Richtlinie entfernt, wird die ursprüngliche Registry-Einstellung wiederhergestellt.

Zielgruppenadressierung und Filterung

Die Zielgruppenadressierung auf Ebene der einzelnen Voreinstellung ist vorhanden.

Eine Filterung auf Basis von WMI-Queries ist vorhanden.

Die Filterung wird auf Ebene des Gruppenrichtlinienobjekts unterstützt.

Benutzerinterface

Das aus den »normalen« Einstellungen bekannte Benutzerinterface (d. h. die normalen Konfigurationsdialoge) wird in den meisten Fällen gezeigt.

Bei der Konfiguration der Richtlinien wird das etwas spartanische »Gruppenrichtlinien-Benutzerinface« verwendet.


Abbildung 8.166 zeigt die aufgeklappten Voreinstellungen für die Computer- und die Benutzerkonfiguration. Sie finden dort etliche interessante Aspekte wie das Setzen von Umgebungsvariablen, den Umgang mit INI-Dateien, den Zugriff auf lokale Benutzer und Gruppen und vieles andere mehr.

Abbildung 8.166 In einem Gruppenrichtlinienobjekt können Voreinstellungen definiert werden.

Ein Merkmal der Voreinstellungen ist, dass die Konfiguration zumeist über Dialoge geschieht, die den »Original-Dialogen« nachempfunden sind, die bei der »normalen« Konfiguration verwendet werden. In Abbildung 8.167 sehen Sie das Bearbeiten der Voreinstellungen für das Vista-Startmenü – die Dialoge kommen einem irgendwie bekannt vor.

Abbildung 8.167 Bearbeiten der Voreinstellung für das Startmenü

Zu beachten ist die Registerkarte Gemeinsam im Konfigurationsdialog jeder Voreinstellung. Wie Sie in 1Abbildung 8.168 sehen können, gibt es hier eine Möglichkeit, um festzulegen, ob die Voreinstellungen tatsächlich angewendet werden sollen: die Zielgruppenadressierung.

Abbildung 8.168 Auf der Registerkarte »Gemeinsam« rufen Sie den Dialog zur Konfiguration der Zielgruppenadressierung auf.

In Abbildung 8.169 ist der Zielgruppenadressierungseditor zu sehen. Sie können in einer einfach zu handhabenden grafischen Benutzeroberfläche beispielsweise festlegen, dass die Voreinstellung nur für Tragbare Computer angewendet werden soll. Diverse andere Möglichkeiten sind auf der Abbildung zu sehen.

Abbildung 8.169 Der Zielgruppenadressierungseditor

Abbildung 8.170 zeigt, dass sich hinter den Stichwörtern der Zielgruppenadressierungseinstellungen (z. B. Tragbarer Computer) durchaus noch weitere Einstellmöglichkeiten finden. So können Sie beispielsweise festlegen, dass eine Voreinstellung nur gelten soll, wenn das Notebook gedockt ist.

Abbildung 8.170 Hier wird die Einstellung für den Dockingstatus konfiguriert.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen. >> Zum Feedback-Formular
<< zurück
 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Windows Server 2012 R2






 Windows Server
 2012 R2


Zum Katalog: Office 365






 Office 365


Zum Katalog: Microsoft Hyper-V






 Microsoft Hyper-V


Zum Katalog: Linux-Server






 Linux-Server


Zum Katalog: Vmware vSphere 5






 Vmware vSphere 5


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Rheinwerk Verlag GmbH 2010
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Rheinwerk Computing]

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de