Zentralen Windows ADMX-Store sichern und aktualisieren

Windows[English]Ich kippe mal ein Thema hier in den Blog, welches Administratoren von Windows-Systemen in Unternehmen tangiert. Wie stellt ihr eigentlich sicher, dass der zentrale ADMX-Store für Windows-Gruppenrichtlinien immer aktuell bleibt und bei Beschädigungen restauriert werden kann? Ohne aktuelle ADMX-Dateien im Store lassen sich die Gruppenrichtlinien nicht wirklich effizient nutzen.


Anzeige

Es ist imho ein Problem, welches es vor Windows 10 und Microsofts As-a-Service-Ansatz bei weiteren Produkten wie Office oder Edge etc. so nicht gegeben hat. Man musste die ADM(X)-Dateien nur in großen Zeitabständen aktualisieren. Die ständigen Windows 10/11 Funktionsupdates und Updates anderer Microsoft-Produkte bewirken, dass sich die ADMX-Dateien ständig ändern. Ohne aktuellen ADMX-Store stehen Gruppenrichtlinien, die neu mit einem Funktionsupdate oder einer neuen Software-Version eingeführt wurden, nicht zur Verfügung.

Bei deutschen Nutzern kommt als weiteres Problem noch hinzu, das Microsoft selbst mit seiner Schlagzahl nicht mehr mithalten kann. Denn die ADMX-Richtlinienvorlagen müssen ja lokalisiert werden. Aktuell habe ich keinen direkten Überblick über den Stand, da ich nicht praktisch als Administrator in einer Unternehmensumgebung arbeite. Aber von Consultants im Microsoft-Umfeld weiß ich aus persönlichen Mitteilungen im letzten Jahr, dass mit der Lokalisierung der ADMX-Datei einiges im Argen lag oder ggf. sogar liegt.

Backup und Aktualisierung des Windows ADMX-Store

Blog-Leser Karl hat mich auf Twitter auf das Thema für diesen Blog-Beitrag gebracht. Karl betreut verschiedene Business-Kunden mit Windows-Systemen. Da ist es wichtig, schnell einen aktualisierten ADMX-Store für Windows zentral vorzuhalten. Und um bei einem Desaster schnell reagieren zu können, sind auch Backups zur Wiederherstellung wichtig. Karl stellt das in nachfolgendem Tweet zur Debatte.

Backup your admx centralized store and Update it

Die kurze Botschaft ist eigentlich recht unspektakulär: Denkt daran, den zentralisierten ADMX-Store regelmäßig zu aktualisieren und versäumt es nicht, alle ADMX-Dateien auf dem aktuellen Stand zu halten. Nur so könnt ihr das Potential der neuesten Gruppenrichtlinien nutzen.

Eigentlich selbstverständlich, wenn man so darüber nachdenkt. Aber es ist ein undankbarer Job, denn für Microsoft ist das ein weißer Fleck, es gibt meines Wissens keinen Mechanismus, der die ADMX-Store-Dateien aktuell hält und ggf. ein Backup anfertigt. Wie löst ihr das eigentlich so?

Wolfgang Sommergut hat auf 4sysops.com diesen Artikel veröffentlicht, der sich damit beschäftigt, wie man einen zentralen ADMX-Store anlegt und ggf. aktuell hält. Von Ali Tarjan gibt es diesen Beitrag mit Hinweisen zum Aufbau eines "Central Store" für Gruppenrichtlinien-Vorlagen (ADMX). Und auf deploywindows.com findet sich dieser Artikel mit Hinweisen zur Aktualisierung der GPO-Vorlagedateien. Sind wohl Basics für Systemadministratoren. Aber da sieht mir vieles nach "Handarbeit" aus.

Karl hat mir dann noch eine Ergänzung geschickt. Um das Ganze noch komplexer zu machen, strickt bei Microsoft wohl jeder sein Zeugs, wie er denkt, sich fühlt oder welches Gras er geraucht hat. Dazu kritisiert Karl:

Es macht bei Microsoft jeder [das mit den ADMX-Dateien] wie er will. Der Eine als Download über MS Seite, der Andere auf Github, der Eine als selbstextrahiernde .exe, der Andere als Setup, wieder ein anderer als zip. Wieder andere packen es bei Micrsoft in eine Installationsverzeichnis.

Nicht mal die auf die Ordnerbenennung und Ordnerstrukturen, die für dieses gelten, werden eingehalten. Hier insb. "junge Teams" wie Teams, oder OneDrive [arbeiten frei nach Gusto]. Es ist ein Graus.

Karl hat in der Techcommunity den Beitrag Reorganize Onedrive ADMX template folders to match MSFT standards for Policydefnitions als Diskussion eingestellt, wo man noch ein paar Details festklopft.


Anzeige

Ein Lösungsvorschlag

Das Twitter ein hilfreiches Mediums ein kann, erweist sich auch in diesem Fall. Dennis Mohrmann weist in diesem Tweet auf ein Script (EverGreenAdmx) hin, welches die ADMX-Dateien zumindest aktuell halten soll.

EverGreenAdmx script to update Admx files

Msfreaks hat das betreffende Script auf GitHub bereitgestellt und schreibt:  Nachdem ich mehrere virtuelle Windows-Desktop-Umgebungen eingerichtet hatte, beschloss ich, dass ich die benötigten Admx-Dateien nicht mehr manuell herunterladen wollte, und ich wollte eine Möglichkeit, sie auf dem neuesten Stand zu halten.

Das betreffende Skript löst beide Probleme: Es prüft, ob neuere Versionen der vorhandenen Admx-Dateien vorhanden sind, und verarbeitet die neue Version, falls gefunden Kopiert optional die neuen Admx-Dateien in den Ordner Policy Store oder Definition oder in einen Ordner der Wahl. Das PowerShell-Script kann in einen beliebigen Ordner heruntergeladen und ausgeführt oder über die PowerShell-Galerie mit folgendem Befehl installiert werden:

Install-Script -Name EvergreenAdmx

Auf GitHub schreibt msfreaks, dass er das Script täglich laufen lässt und gibt den betreffenden Befehl an. Dort werden auch die Microsoft-Produkte aufgeführt, deren ADMX-Dateien vom Script aktualisiert werden. Ich kann aber nicht beurteilen, ob das Script das leistet, was Karl oder ihr benötigt. Vielleicht hilft das Thema aber dem einen oder anderen von euch weiter.


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Windows abgelegt und mit verschlagwortet. Setze ein Lesezeichen auf den Permalink.

17 Antworten zu Zentralen Windows ADMX-Store sichern und aktualisieren

  1. 1ST1 sagt:

    Das Script sieht nett aus. Aber, es kopiert auf Wunsch die Sachen direkt ins Sysvol. Das bedeuet meiner bescheidenen Ansicht nach, dass es auf dem Domain-Controller mit Adminrechten laufen muss, wenn es die ADMX-Dateien direkt dort automatisch aktualisieren soll? Das finde ich höchst bedenklich, nicht nur weil ein Domain Admin nicht aufs Internet zugreifen können sollte. Es ist auch ein schönes Einfallstor für Suppy Chain Attacken, kann man nur hoffen, dass microsoft mal nicht selbst gehackt wird (so wie Solarwinds). Trotzdem schaue ich mir das Teil die Woche mal an, vielleicht kann man das auch halbautomatiseren…

  2. LOL sagt:

    Ich lerne gerade GPO und komme aus der Linux-Ecke, und bin mehr als nur
    unerfahren, aber:
    Warum soll ich ADMX überhaupt (noch) auf SYSVOL legen?
    Es handelt sich um Vorlagen, die eingesetzt werden um mit Scripten/GUI GPO
    (vereinfacht: Reg-Keys im SYSVOL) zu erzeugen. IMHO reicht ein zentraler
    Speicherpunkt (ggf. im git) der von den Rechnern/Benutzern erreicht wird,
    die GPO konfigurieren sollen.
    Die Software (GUI, Scripte) die ADMX dazu braucht/lädt, sucht diese sowieso
    bevorzugt aus dem lokalen Verzeichnis "PolicyDefinitions".

    Die viel größere Schweinerei ist IMHO, dass ich ohnehin je eingesetzter
    Software-Version eine eigene ADMX Variante benötige:
    Eine vollständige Auf- und Abwärtskompatibilität wird nicht (mehr)
    garantiert. MS empfiehlt sogar, GPO mit der Software/Windows-Version zu
    erzeugen und zu laden (WMI filter), die auch konfiguriert werden soll.
    Gerade dies ist eine ziemliche Frechheit, denn Tools um GPO sinnvoll zu
    Versionieren und Vergleichen sind als Bordmittel quasi nicht vorhanden.

    Warum sollte ich die ADMX lokalisiert ablegen?
    Die Übersetzungen, die MS sich leistet sind oftmals "interessant", wer
    kann, sollte bei Englisch bleiben. Da kann man wenigstens hoffen, dass
    der Autor wusste was er schrieb weil er mit dem Entwickler Kontakt hatte.
    Die resultierenden GPOs sind, soweit mir bekannt, sprachneutral.

    Quellen:
    https://web.archive.org/web/20210805141817/https://www.ws-its.de/moderne-gpo-versionierung-am-beispiel-von-windows-10-v1909/
    Ab "Das Problem…" und die Problemszenarien. Die Seite ist nicht von mir,
    Google spuckte sie aus als ich Anleitungen zur sinnvollen Verwaltung
    und Strukturierung von GPO und AD suchte.

    • 1ST1 sagt:

      SYSVOL ist ja genau der geforderte zentrale Speicher, in denen die ADMX-Dateien abgelegt werden, \\domain.net\SYSVOL\ liegt auf den DCs, ist nichts andere als eine Ordnerfreigabe von c:\Windows\SYSVOL vom nächsten erreichbaren DC – die DCs replizieren den SYSVOL-Ordner unterinander, und nicht nur das Gruppenrichlinien-Verwaltungstool greift darauf zu, sondern auch alle Server und Clients, welche die Richtlinien letztlich lokal in Registry-Settigs umsetzen.

      Mit zentraler Verteilung der ADMX-Dateien wäre es schöner, wenn die per Windows-Update kämen, insbesondere auf den DCs – die Clients bringen ja bei der Installation immer eine passende lokale Version mit. Dann müsste man nicht mit solchen Skripten basteln.

      • LOL sagt:

        Wie gesagt: Gruppenrichtlinieneditor & Co. laden seit einiger Zeit die ADMX *bevorzugt*/priorisiert aus dem lokalen Ordner "PolicyDefinitions" des Clients und *nicht* aus SYSVOL (weder DC noch lokale Kopie), insofern braucht man definitiv eine Lösung, wie man diese lokalen Ordner "PolicyDefinitions" aktualisiert, damit man nicht aus versehen die falsche ADMX verwendet, ohne es zu merken. Das kann, im einfachsten Fall eine Regel sein, nur einen bestimmten PC zu benutzen, um GPO zu bearbeiten und dort die ADMX vorzuhalten.
        Die Tools und/oder alle PCs so umzukonfigurieren, dass sie SYSVOL bevorzugen kann negative Seiteneffekte haben (bei Versionsumstellungen).

        Je mehr ich über dieses System der Administration lerne, desto weniger Haare habe ich…

      • T Sommer sagt:

        Ähm, unter SYSVOL liegen eigentlich nur die erstellten Gruppenrichtlinien mit ihren Dateien und die Scripte.
        Die ADMX Vorlagen kommen in das Verzeichnis c:\windows\PolicyDefinitions.
        Die Gruppenrichtlinienverwaltung greift auf diese Vorlagen zu und erstellt in SYSVOL die GPOs.
        GGF finden sich die ALTEN "ADM" in den Polices, wenn diese benutzt werden/wurden.
        ADMX erzeugen unicodebasierende INF Dateien.
        Oder sehe ich das auf dem Domaincontroller gerade Falsch?

        • 1ST1 sagt:

          Das stimmt für lokale Richtlinien, aber nicht für die Domäne.

          In dem Guthub-Beispiel wird gezeigt, wie man das in der Domäne automatisch aktualisiert, der Befehl für dieses Script lautet:

          EvergreenAdmx.ps1 -WindowsVersion "21H1" -PolicyStore "C:\Windows\SYSVOL\domain\Policies\PolicyDefinitions"

          Und jetzt schau mal in deiner Domäne in das Verzeichnis, was da liegt…

          Damit das funktioniert, muss das Script zwangsläufig auf einem DC laufen, denn nur von dort wird C:\Windows\SYSVOL ins ganze AD syncronisiert. Würde man es anders machen, würde das AD den Sysvol-Ordner ständig "bereinigen". Auf PCs ohne Domäne gibts das Verzeichnis garnicht.

          Es wäre ja auch doof, wenn man in einer Domäne mit 1000enden PCs die ADMX-Files einzeln auf jeden Rechner kopieren müsste… Wozu gibts den Replikationsdienst des ADs?

          • T Sommer sagt:

            "Und jetzt schau mal in deiner Domäne in das Verzeichnis, was da liegt…"
            NOTHING! NUR DIE GPOs wie oben beschrieben!

            Das mit dem Pfad "-PolicyStore "C:\Windows\SYSVOL\domain\Policies\PolicyDefinitions" hat mich auch etwas gewundert. Denn diesen GIBT es auf meinen Windows Server 2019 Domaincontroller(n) nicht! Folglich wird hier seitens des Scriptes einer gebastelt der als Pool genutzt wird und via AD Replikation dann auf allen DCs verfügbar ist. Ob die Gruppenrichtlinienverwaltung (auf dem DC bzw. VerwaltungsClient) diesen ggf. NUTZT habe ich nicht getestet, wäre aber möglich um nicht zu sagen sinnvoll! Dann wäre aber ein KONFLIKT mit dem PoliceDefinition Ordner im Windows Server Verzeichnis auf dem DC selbst, wenn die GPO Verwaltung das händelt!

            die ADMX File müssen ja nicht auf den PC repliziert werden. Der Client bekommt doch die INF Datei (also die Registry Keys) als GPO zur Laufzeit eingepflanzt.

            Die AD Replikation repliziert das AD und das SYSVOL zwischen DomainControllern.

          • 1ST1 sagt:

            Wundert mich jetzt, ich hab aber jetzt keinen Bock mich mit dem Büro zu verbinden, um nachzusehen, es ist Sonntag. Aber schau mal:

            https://docs.microsoft.com/de-de/troubleshoot/windows-client/group-policy/create-and-manage-central-store

            "Um eine zentrale Store für ADMX- und ADML-Dateien zu erstellen, erstellen Sie einen neuen Ordner mit dem Namen "PolicyDefinitions" am folgenden Speicherort (z. B.) auf dem Domänencontroller:

            \\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions"

            Zitatende.

          • LOL sagt:

            Wie es T Sommer schreibt ist es IMHO richtig, Beispiel:
            – ich betreibe einen AD DC zum testen
            – der hat keine ADMX Dateien im Sysvol
            – die Clients haben auch keine ADMX Dateien
            – die ADMX Dateien liegen wo auch immer ich meinen gpedit verwende, nirgendwo sonst in der Domäne
            – die erzeugten GPO liegen in SYSVOL (inf, registry-hives) und werden repliziert.
            – alles funktioniert

            Das ist genau das, weshalb ich hier die ganze Zeit schreibe:
            SYSVOL braucht man für ADMX nicht, und die GPO funktioniert auch so.

            Microsoft empfiehlt mittlerweile, nicht den zentralen ADMX Speicher auf SYSVOL zu verwenden, sondern ADMX gesondert zu speichern/versionieren. Das ist einer der Gründe, warum ich ursprünglich den Link mit gepostet hatte.

          • 1ST1 sagt:

            In dem MS-Artikel steht, du musst den Ordner selbst anlegen. Dann wird er aber benutzt.

          • Max sagt:

            @LOL:
            Das Problem ist, dass Server 2016 z.B. Version 1607 entspricht und Server 2019 entspricht Version 1809. Wenn du nun aber 1909er oder 21H1er clients in deiner Domäne hast, kannst du diese nicht vollständig mit deinen 1607er oder 1809er ADMX-Dateien verwalten.

            Um das zu machen, müsstest du also die aktuellen ADMX-Dateien entweder von einem aktuellen Windows 10 Client beziehen oder von Microsoft herunterladen und diese dann in den SYSVOL-Ordner eines Domaincontrollers kopieren – das setzt aber voraus, dass du erstmal die NTFS-Rechte anpasst und dem Trusted Installer den Besitz wegnimmst usw.

            Besser ist daher die Lösung, die ADMIX-Dateien im Central Store einzupflegen, siehe die o.g. Links. Und genau hier ist das Problem, die ADMX-Dateien aktuell zu halten. Denn wenn du mal in deinen Gruppenrichtlinien bist und die adminstrativen Vorlagen öffnest, steht dort in Klammern entweder von lokalen Storage oder vom zentralen Stroage abgerufen. Und soweit ich weiß, wird Windows immer den zentralen Storage bevorzugen. Was ich gerade nicht testen kann ist, was passiert, wenn man nur einzelne ADMX-Dateien in den Central Storage packt. Ich vermute, dass man dann auch nur diese konfigurieren kann.

            Immer mal wieder gibt es aber auch Updates für die ADMX-Dateien, so zum Beispiel als MS die WSUS-Zertifikatspflicht eingeführt hat. Dabei wurde die WindowsUpdates.admx-Dateie im lokalen Sysvol-Ordner aktualisiert, die ADMX-Datei im Central Store aber nicht (und darum gehts hier).

    • 1ST1 sagt:

      Mit der Forderung nach gescheiten modernen Tools zur Verwaltung von Gruppenrichtlinien liegst du allerdings vollkommen richtig, da hat sich im Prinzip seit Windows 2000 nichts mehr getan. Aber das wird MS auch in Zukunft stiefmütterlich behandeln, denn wir sollen ja alle ins Azure-AD und da ist alles viel schöner…

      So behelfen wir uns weiterhin mit dem alten Gruppenrichtlinien-Editor und können nur mit rsop.msc rausfinden, welche Richtlinien gerade auf bestimmte Computer und Benutzer wirken… Mühsam ernärt sich das Eichhörnchen…

      • Markus K sagt:

        Erst wenns im SYSVOL "Policydefinitions" gibt und man dann einen Satz von ADMX/ADML Dateien wird domänenweit genau dieser Satz verwendet um GPOs zu erstellen. Gibts den Ordner nicht, wird immer C:\Windows\Policydefinitions verwendet.
        In C:\Windows\Policydefinitions befindet sich immer der aktuellste Satz, ganz egal für welche Windows 10 version. Kann halt passieren, dass Windows 7 möglicherweise mit einer solchen erstellten GPO einfach nichts anfängt, aber das ist wieder ein anderes Thema.
        Nett ist der Central Store dann, wenn man auch noch MS-Office GPOs erstellen möchte, da es die üblicherweise nicht am client gibt, außer man kopiert sie händisch oder via script nach C:\Windows\Policydefinitions.
        Es gibt dann auch wieder Gründe, warum man einen "central store override" einrichtet…
        Das Thema ist ziemlich breit.

  3. AG sagt:

    "Probleme" kann es bei der autom. Aktualisierung dann geben, wenn Einstellungen aus den Vorlagen rausfallen, die in einer älteren Vorlagenversion noch drin waren und auch aktiv gesetzt wurden. Dann entstehen verlorene Registry-Einstellungen, die mittels der aktuellen Vorlagen nicht mehr über den Gruppenrichtlinieneditor gelöscht werden können. Abhilfe schafft hier dann z.B. nur noch ein PowerShell Befehl (https://www.gruppenrichtlinien.de/artikel/bearbeiten-von-zusaetzliche-registry-einstellungen-edit-extra-registry-settings-arbeiten-ohne-gpeditor)

  4. Ich sagt:

    Wenn man einen Central Store möchte, dann kann man ihn anlegen. Der Central Store hat Vor- und Nachteile. Entwickelt wurde er für Multinationale Unternehmen in dem die ADMX-Templates im SYSVOL abgelegt werden können und für Administratoren mit unterschiedlichen Sprachvorlagen. Mark hatte das mal beschrieben: https://www.gruppenrichtlinien.de/artikel/central-store-fuer-administrative-vorlagen

  5. Hans Brender sagt:

    sie sind zwar nicht "normgerecht", aber mit jedem neuen OneDrive-Update kommen auch die u.U. aktualisierten OneDrive admx/amdl Dateien mit.

Schreibe einen Kommentar zu 1ST1 Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.