Freigeben über

Best Practice bezüglich aktueller ADMX / ADML Dateien

  • Artikel

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 https://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

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    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?

  • Anonymous
    January 01, 2003
    The comment has been removed