Best Practice bezüglich aktueller ADMX / ADML Dateien

Best Practice bezüglich aktueller ADMX / ADML Dateien

  • Comments 4
  • Likes

Hi, Fabian hier. Windows 2000 / XP / 2003 ADM-Dateien als auch die unter Windows Vista / 2008 eingeführten ADMX-Dateien stellen eine Vorlage für die möglichen Einstellungen eines Client-Registrierungswertes dar, wenn Gruppenrichtlinien im Einsatz sind. Bei Auswahl eines entsprechenden Wertes bzw. einer konkreten Einstellung über die Unterpunkte der „Administrativen Vorlagen“ („Administrative Templates“) im Gruppenrichtlinieneditor, werden diese Werte dann in die Datei „Registry.pol“ der jeweiligen Richtlinie entweder im Maschinen- oder Benutzerbereich des SYSVOL Eintrags der Policy geschrieben. Von dort aus wendet ein Client diese Registrierungseinstellungen beim Group Policy Processing an.

Wie erwähnt wurden vor Windows Vista / Windows Server 2008 administrative Vorlagen über sogenannte ADM-Dateien konfiguriert, nicht über die neuen ADMX / ADML Dateien. Die dafür eingebundenen ADM-Dateien wurden in den jeweiligen Gruppenrichtlinienordner, also dem Group Policy Template (GPT), im SYSVOL geschrieben. Damit fielen allein mit den standardmäßig mitgelieferten ADM-Dateien schon ca. 4,5 MB an. Bei 100 Policies einer Domäne hatte man somit rund ein halbes Gigabyte an Daten, die „mal eben“ mittels FRS auf die anderen DCs der Domäne repliziert werden mußten. Bei (lokalen) Aktualisierungen der ADM-Dateien wurden diese automatisch ins SYSVOL der jeweiligen bearbeiteten Policy geschrieben, was wiederum Replikation nach sich zog und ggf. zu unerwünschten Effekten führte (etwa, wenn die lokale Sprachversion der ADM-Datei eine andere war, als die im SYSVOL liegen sollte). Anders herum (SYSVOL nach lokal) fand die Aktualisierung ebenfalls statt.

Zusätzliche Informationen dazu finden sich zum Beispiel hier:

Ab Vista / 2008 hat sich hier einiges geändert – so sind die Vorlagedateien nun viel modularer und damit wartbarer geworden, zusätzlich ist streng nach Sprache und Inhalt getrennt worden. Auch werden die Vorlagedateien nun nicht mehr automatisch in jeder Policy im SYSVOL abgelegt und ggf. aktualisiert, sondern liegen entweder nur lokal oder in einem zentralen Speicher auf dem SYSVOL („central store“) nur einmal vor. Eine große und wichtige Verbesserung.

Wer sich in das Thema einlesen möchte, kann z.B. hier vorbei schauen:

Aber hey, es soll hier in diesem Blog Eintrag bewußt nicht um die Vergangenheit oder um jede Einzelheit der alten ADM-Dateien und neuen ADMX / ADML Aufteilung gehen, sondern lediglich um einen ganz konkreten Punkt:

Wie oben schon gesagt werden die ADMX / ADML Dateien nicht automatisch mit neueren Versionen aktualisiert. Weiterhin kommen aufgrund der modularen Gestaltung der Vorlagen etwa in Vista nicht alle Vorlagen mit, die etwa unter Windows Server 2008 verfügbar sind. Daraus ergibt sich die Frage, was hier „Best Practice“ ist, um die Vorlagen etwa in einem zentralen Speicher („central store“) auf dem neuesten und kompletten Stand zu halten.

Grundsätzlich würde ich empfehlen, immer die aktuellsten Templates etwa auf einem zentralen Speicher zur Verfügung zu stellen. Zum jetzigen Zeitpunkt sind das die Windows Server 2008 RTM Templates. Diese sind grundsätzlich mit den Vista SP1 Templates inhaltlich identisch, jedoch bringt der Windows Server 2008 RTM / SP1 einige zusätzliche Templates mit, die etwa Funktionen wie NAP oder andere Server-relevatente Funktionen verwaltbar machen.

Das bedeutet, daß man von Zeit zu Zeit (etwa bei neuen Service Pack Versionen von Windows Vista / Windows Server 2008 oder neuen Betriebssystem Versionen, falls nicht anders angegeben) die ADMX und ADML Templates auf dem zentralen Speicher im SYSVOL aktualisieren sollte. So werden ggf. neue Vorlagen verfügbar gemacht oder Fehler in alten Vorlagen beseitigt. Die Microsoft Product Teams, die für die jeweiligen ADMX / ADML Dateien der entsprechenden Komponente selbst verantwortlich sind, werden im Normalfall nur Änderungen vornehmen, die rückwärtskompatibel sind (siehe unten).

Um eine Aktualisierung vorzunehmen, kopiert man die Dateien und Sprachordner eines z.B. mittels Service Pack aktualisierten Systems unterhalb von "%SYSTEMROOT%\PolicyDefinitions" auf den zentralen Speicher.

Robocopy etwa kopiert in den Standardeinstellungen nur neuere, zusätzliche oder geänderte Dateien - wenn man also die ADMX / ADML Dateien von einem aktuellen Windows Server 2008 System in den zentralen Speicher der PolicyDefinitions mittels Robocopy kopiert, sollte dies keinerlei Probleme verursachen und ist von uns empfohlen.

Es ist natürlich nie auszuschließen, daß sich doch einmal ein Problem oder ein Fehler einschleicht - daher die generelle Empfehlung, die zentralen Templates vor dem Ersetzen der Dateien an einen anderen Ort zu sichern bzw. ein Backup durchzuführen, so daß man im Fall der Fälle zurück auf die alten Templates gehen kann. Dies ist jedoch wie angesprochen im Normalfall nicht notwendig und sollte wenn überhaupt äußerst selten der Fall sein.

Wie ebenfalls oben schon erwähnt sollten die ADMX / ADML Vorlagen im Regelfall kumulativ bzw. rückwärts kompatibel sein, so daß keine alten Einstellungen in neuen Templates „verschwinden“. Dies gilt übrigens nicht nur innerhalb des Betriebssystems (z.B. Vista / 2008), sondern auch für ältere Systeme (wie XP / 2003). Ist dies doch der Fall, kann es sich schlimmstenfalls um einen Fehler handeln. Ggf. schafft in solchen Fällen eine Nachfrage bei uns Klarheit.

Die XP / 2003 ADM-Vorlagen und das Vorgehen zur Policy Bearbeitung unter XP / 2003 bleiben von der Umstellung auf ADMX / ADML erst einmal vollkommen unberührt. Empfehlenswert ist jedoch, immer die „höchste“ Betriebssystemversion zu verwenden, wenn Policies bearbeitet werden. D.h. nicht XP Policies mit XP anpassen oder Vista GPOs mit Vista, sondern in beiden Fällen Windows Vista SP1 plus RSAT Tools oder ein Windows Server 2008 zu verwenden. Somit ist die korrekte Funktionalität und die Sichtbarkeit aller Einstellungen gewährleistet.

Für alle Skeptiker noch der Hinweis, daß sich vor einem Kopiervorgang der aktuellsten Templates recht einfach prüfen läßt, ob Änderungen in den Dateien stattgefunden haben oder zusätzliche Dateien vorhanden sind: Die Windows Server 2003 Support Tools bringen beispielsweise das Programm WINDIFF mit, siehe 159214 How to Use the Windiff.exe Utility http://support.microsoft.com/default.aspx?scid=kb;EN-US;159214

Mit diesem oder anderen Programmen lassen sich Unterschiede in Ordnern und Dateien problemlos anzeigen, bevor man dann zur großen Aktualisierung ansetzt.

Zusätzliche Links


Viele Grüße
Fabian

Comments
  • Ich begrüße den zentralen Ansatz des "Central Storage". Das Sicherstellen eines einheitlichen Satzes an ADMX-Files für eine ganze Domäne wird so zum Kinderspiel. Aber eines ist mir noch unklar:

    Der o.a. Hinweis, immer die aktuellsen Files dort abzulegen, ist nicht immer gewünscht. Beispielsweise bei einem OS-Upgrade wie Windows 7, das in einem grossen Unternehmen erst vorsichtig getestet und pilotiert wird. Da benötigt man zwar für eine Untermenge seiner Clients und vielleicht einige ausgewählte Admins die Windows 7 ADMX-Files zur GPO-Pflege, aber allen anderen möchte man diese ganz bewußt noch nicht zur Verfügung stellen.

    Hier ist eine saubere Trennung erforderlich.

    Aber wie soll so ein Szenario mit nur einem zentralen Verzeichnis umgesetzt werden?

  • Hallo pago,

    erst einmal vielen Dank für Dein Feedback.

    Im Normalfall werden bei OS Upgrades die Tests nicht im Produktionsumfeld gemacht, sondern in einer Testumgebung bzw. einem Prä-Produktionsforest. In dem Moment ist die Aktualisierung der Templates in einer zentralen Lokation also kein Thema.

    Werden die Templates danach im Produktionsforest zentral abgelegt, ist im Grunde davon auszugehen, daß diese auch den GPO-Bearbeitern zur Verfügung stehen sollen. Letztendlich ist es eher eine Frage der Delegierung der GPO-Bearbeitungsbrechtigungen, weniger eine Frage der verfügbaren Einstellungen / Templates. Diejenigen Mitarbeiter, die Zugriff auf GPOs haben, sollten so vertrauenswürdig sein, daß sie keine ungewünschten Einstellungen vornehmen. Falls dem nicht so ist, sollte eher das Delegierungskonzept überarbeitet werden.

    Wenn nach der Testphase während einer Pilotierung nur bestimmte Personen im Produktionsforest etwa mit Windows 7 arbeiten bzw. diese Clients verwalten sollen, werden die Client auch meist in eine separate OU verschoben, so daß hier die entsprechenden Berechtigungen dediziert vergeben werden können. Daß die Einstellungen als solches in dem Moment allen anderen Bearbeitern zur Verfügung stehen, würde ich persönlich nicht für ein Problem halten – denn abwärtskompatibel sollten die Einstellungen wie im Blog angesprochen sein und neue Einstellungen für Windows 7 Clients können ja nur für diese „abgeschirmten“ Clients zur Verfügung gestellt werden. In dem Moment, wenn die Windows 7 Clients dann ausgerollt werden, müssen die entsprechenden Policies ja auch schon freigegeben sein und werden nicht erst später entworfen. Das geschieht während der Pilotierung.

    Wenn dies letztendlich nicht gewünscht ist, muß weiterhin mit einem lokalen Speicher gearbeitet werden.

    Viele Grüße
    Fabian

  • Hallo Fabian,

    danke für Deine Antwort.

    Klar, die reine Testphase läuft in einer separaten Umgebung, aber spätestens bei einem Piloteinsatz bewegt man sich im produktiven Umfeld.

    Ich behaupte, dass es so unterschiedliche und z.T. sehr komplexe Umgebungen geben kann, die z.B. eine verteilte Delegation erfordern, daher glaube ich nicht dass man das pauschal über eine Änderung des Delegations-Konzept lösen kann.

    Wie auch immer, was spricht denn z.B. gegen die Option, für eine Teilmenge an Admin-Maschinen einen anderen "Central Store" definieren zu können?

    Sobald man "Poliy Definitions" auf dem SYSVOL angelegt hat, schaut ja jede 2008er GPMC autom. dort nach. Schick fände ich es daher, z.B. eine Policy zu haben, mit der ich den "ADMX-Suchpfad" umlenken könnte. So hätte man maximale Flexibilität. Nach Ende der Pilot-Phase könnte man dann alle neuen ADMX File in den "Standard"-Central Store überführen und die Überganglösung wieder abschaffen.

  • Hallo pago,

    mit den ADM-Dateien gab es in der Vergangenheit die Möglichkeit, nur lokale ADMs zu verwenden und nicht die ADM-Dateien im SYSVOL. Das paßt zwar nicht 100% auf dieses Szenario, ist aber zumindest ähnlich. Daß diese Option nicht auch bei einem „central store“ vorgesehen ist zeigt mir, daß diese Option von unserer Product Group offensichtlich bewußt als Designentscheidung nicht gewählt wurde.

    Du hast schon Recht – es gibt sicher ganz verschiedene Konstellationen, in denen ein „central store“ eingesetzt wird. Mit solchen Konstellationen arbeiten wir hier jeden Tag. Aber so recht erschließen tut sich mir die Anforderung dennoch nicht.

    Aber das ist ganz klar eine Frage der Perspektive, ich möchte Dir also gar nicht widersprechen, daß es für Dich nicht „relevant“ sein kann.

    Ich kann den Hinweis von Dir gern an unsere Product Group weiter geben. Dort wird dann entschieden, ob dieses Design geändert werden kann / soll oder ob es konkrete Gründe gibt, die dagegen sprechen.

    Viele Grüße
    Fabian

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment