Einfache Namen für GPOs
Wenn es um „einfache Namen“ für Dinge in der IT geht, kann man sicherlich tagelang darüber diskutieren – in diesem Artikel will ich ein Beispiel für die Benennung von GPOs vorstellen, welches ich seit einigen Jahren verwende, denn das ist für mich die Definition von „einfach“.
Variante 1: „Sprechende“ Namen
In diesem Beispiel wurde die GPO „Zeige Willkommensnachricht“ angelegt. In dieser GPO soll allen Clients (also nur die Geräte, an denen sich Anwender anmelden werden: Notebooks & PCs) eine Meldung beim Anmelden angezeigt werden.
Möchte nun ein anderer Administrator diese GPO ändern, muss er sich erst in den Settings raussuchen, wo genau die Einstellung gesetzt worden ist.
Unter Umständen wurde die GPO sogar auf mehr Geräten aktiviert als ursprünglich geplant. In meinem Beispiel also für ALLE Geräte in der Domäne anstelle nur für die Clients.
Variante 2: „Logische“ Namen
Ich habe mir angewöhnt in den GPOs durch Kürzel zu beschreiben, wo genau die Einstellung zu finden ist. Anhand des Beispiels heißt die GPO dann also:
-> C-C-PO-WS-SS-LP-SO_InteractiveLogon_Willkommensnachricht_v1.0
Ich sehe also am Namen:
- C -> Client
- C -> Computer Configuration
- PO -> Policies
- WS -> Windows Settings
- SS -> Security Settings
- LP -> Local Policies
- SO -> Security Options
- _ -> Trennung Pfad zur eigentlichen Option bzw. Optionskategorie
- Willkommensnachricht -> frei gewählter & sprechender Name
- _ -> Trennung zwischen Name und Version
- v1.0 -> Versionierung
… und erkenne, dass die GPO gar nicht für die gesamte Domäne gedacht war, sondern nur für die Clients.
Vorteil Versionierung
Möchte man im Laufe er Zeit einige Änderungen an GPOs vornehmen, so empfehle ich, die GPO zu duplizieren und dann als nächsthöhere Version „v2.0″/“v3.0″/… zu benennen und die alte Version erstmal nur zu deaktivieren.
Der Vorteil ist: Bei Fehlern aufgrund der Änderungen muss man sich nicht erst überlegen, was man alles angepasst hat oder gar erst Dokumentationen (sofern man vorher eine erstellt hat 😉) raussuchen, sondern kann direkt die neue fehlerhafte Version deaktivieren und die ältere funktionierende Version aktivieren.
Mögliche Buchstaben an o.g. Stellen
- Stelle: A -> Alle / C -> Clients / S -> Server / T -> Test
- Stelle: C -> Computer Configuration / U -> User Configuration
- Stelle: PO -> Policies / PR -> Preferences
- Stelle: SS -> Software Settings / WS -> Windows Settings / AT -> Administrative Templates / CP(S) -> Control Panel Settings
- Stelle: … usw. … Ich denke, das Schema sollte jetzt erkennbar sein …
Bilder zu den Varianten und Tipps
Weitere Tipps bzgl. Gruppenrichtlinien gibt es bei „Gruppenrichtlinien (GPO)“
Servus, mich würde mal interessieren, wie du bei der Namensgebung verfährst, wenn eine GPO sowohl Einstellungen unter Policies als auch unter Preferences enthält. Ein Beispiel hierfür wäre die Konfiguration des OpenSSH Servers. Ich möchte hier via GPO den Dienst aktivieren, einen Registry Key setzen, um die Standard Shell anzupassen und die Firewall anpassen. Wären das bei dir dann zwei/drei getrennte Richtlinienobjekte oder würdest du diese zu einer zusammenfassen (z.B. S-C_Enable OpenSSH_v1.0)?
Hallo, vielen Dank für deine Frage.
Die vorgeschlagene Namenskonvention wäre für einen Großteil der GPOs, es wird natürlich immer mal Sonderfälle geben, wo diese Konvention nicht 100% passt. Im von dir genannten OpenSSH-Beispiel gäbe es dann zwei Möglichkeiten:
1. Separate GPOs „S-C-PR-…_OpenSSH-Server_v1.0″ & „S-C-PO-…_OpenSSH-Server_v1.0″
2. Eine GPO, in der dann beide Settings gemacht werden: „S-C-PX-…_OpenSSH-Server_v1.0″; hierbei das „X“ als Platzhalter für „R“/“O“ aus „PR“/“PO“
Meines Erachtens ist es vor allem wichtig, dass vermeidet werden sollte, Computer-Settings und User-Settings zu mischen.