Sektion 17: Administrative Templates: Die klassischen GPOs in der Cloud

Einleitung: Warum Administrative Templates das Rückgrat deiner Intune-Konfiguration sind

Wer von klassischem Active Directory zu Microsoft Intune migriert, stolpert früher oder später über dieselbe Frage: „Wo sind meine Group Policy Objects?“ Die Antwort lautet: Sie sind nicht verschwunden – sie sind in die Cloud gezogen. Administrative Templates in Intune sind die direkte Entsprechung der klassischen GPO-Einstellungen, die du aus der Gruppenrichtlinienverwaltung kennst. Sie basieren auf denselben ADMX-Definitionen, decken tausende Windows-Einstellungen ab und sind der Grund, warum viele Organisationen überhaupt erst komplett auf eine Cloud-native Verwaltung verzichten können.

In dieser Sektion gehen wir extrem in die Tiefe: Wie funktionieren Administrative Templates technisch unter der Haube? Wie unterscheiden sie sich von Settings Catalog und den nativen Device Profiles? Wie baust du eine saubere, wartbare Policy-Struktur auf? Und wo liegen die klassischen Stolperfallen, die in Produktion für stundenlange Troubleshooting-Sessions sorgen? Am Ende dieser Sektion wirst du Administrative Templates nicht nur bedienen, sondern verstehen – und genau das ist der Unterschied zwischen einem Intune-Bediener und einem Intune-Engineer.

Grundkonzepte: ADMX, Registrierung und die Architektur hinter den Kulissen

Was sind ADMX-Dateien eigentlich?

Administrative Templates basieren auf ADMX-Dateien (Administrative Templates XML) – das sind XML-Definitionsdateien, die beschreiben, welche Richtlinien ein Windows-System kennt, wo die zugehörigen Werte in der Registry liegen und welche Wertebereiche gültig sind. Microsoft liefert diese Dateien mit jedem Windows aus (unter C:\Windows\PolicyDefinitions), und die dort definierten Richtlinien decken praktisch den gesamten Konfigurationsumfang des Betriebssystems ab: von Internet Explorer-Kompatibilitätslisten über Microsoft Defender-Einstellungen bis hin zu BitLocker-Verhalten, OneDrive-Konfiguration und Startmenü-Richtlinien.

Der entscheidende Punkt zum Verständnis: Eine Administrative Template-Richtlinie schreibt am Ende nichts anderes als einen Registry-Wert. Die ADMX-Datei ist die „Beschreibung“, die Registry ist das „Ziel“. Wenn du in Intune eine Administrative Template-Richtlinie wie „Block access to the Windows registry tools“ aktivierst, landet auf dem Client ein Registry-Wert unter HKLM\Software\Policies\Microsoft\Windows\System (beispielhaft) – exakt so, wie es auch eine klassische GPO getan hätte.

Wo liegen die Werte: Policy vs. Preference

Hier liegt einer der wichtigsten konzeptionellen Unterschiede, den jeder Intune-Admin verinnerlichen muss. Klassische GPOs unterscheiden zwischen „Richtlinien“ (settings unter HKLM\Software\Policies bzw. HKCU\Software\Policies – gesperrt, nicht vom User überschreibbar) und „Einstellungen“ (Group Policy Preferences, die beliebige Registry-Pfade beschreiben können). Administrative Templates in Intune schreiben ausschließlich echte Richtlinien in die Policy-Zweige der Registry. Das bedeutet:

Werte unter Software\Policies und Software\Microsoft\Windows\CurrentVersion\Policies sind durch Administrative Templates steuerbar und werden vom System als „verwaltet“ behandelt.
Arbiträre Registry-Schlüssel außerhalb der Policy-Pfade (z. B. HKLM\SOFTWARE\MyApp\Config) kannst du mit Administrative Templates nicht setzen. Dafür brauchst du ein Device Profile vom Typ „Templates“ → „Custom“ oder besser noch Win32-App-Tuning oder ein PowerShell-Remediation-Skript.
Der Policy-Zweig hat eine Besonderheit: Werte dort gelten als „managed“ und können von manchen Anwendungen (z. B. Office) als nicht mehr veränderbar durch den Anwender signalisiert werden.

Administrative Templates vs. Settings Catalog vs. Security Baselines

In Intune gibt es drei Wege, ADMX-basierte Einstellungen zu verwalten – und die Verwechslung dieser drei ist die häufigste Unordnung in realen Tenant-Strukturen:

Administrative Templates: Das klassische Interface, aufgeteilt in Kategorien (Computer Configuration, User Configuration) mit jeweils tausenden Einstellungen. Du siehst pro Richtlinie nur die Einstellungen, die du explizit hinzufügst.
Settings Catalog: Die modernere, flexiblere Variante. Alle ADMX-Einstellungen in einer einzigen durchsuchbaren Oberfläche, inklusive Einstellungen, die in den klassischen Administrative Templates fehlen. Der Settings Catalog erlaubt außerdem pro Einstellung, den Modus (Add, Replace, Delete) zu wählen – das macht ihn für Migrationsszenarien und Overrides deutlich mächtiger.
Security Baselines: Fertig kuratierte, von Microsoft getestete Empfehlungspakete, die selbst zu großen Teilen aus ADMX-Einstellungen bestehen. Sie sind ein Ausgangspunkt, kein Endzustand – aber ein exzellenter.

Praxisempfehlung für neue Tenants: Nutze den Settings Catalog als primäres Werkwerkzeug, weil er eine einzige Quelle der Wahrheit schafft und keine Einstellungen versteckt. Administrative Templates bleiben relevant, wenn du vorhandene GPO-Strukturen 1:1 nachbauen willst oder bestehende Dokumentation darauf referenziert. Beide landen technisch im selben OMA-URI-basierten Sync-Format auf dem Client.

Sync-Kanäle: DMClient und die 8-Stunden-Hürde

Administrative Templates werden über den Intune Management Extension-Kanal (bzw. bei reinen ADMX-Policies über das Policy Configuration Service Provider, CSP) an den Client übertragen. Das Timing ist wichtig für dein Troubleshooting-Verständnis:

Intune checkt standardmäßig alle 8 Stunden (plus/minus randomisiert) auf neue Richtlinien.
Ein manuelles „Sync“ aus der Unternehmensportal-App oder Einstellungen → Konten → Zugriff auf Geschäftsbereich erzwingt eine sofortige Übertragung.
Neu erstellte/veränderte Profile werden in der Regel innerhalb von Minuten zugestellt – die 8-Stunden-Logik gilt für den Idle-Zustand.

Praxis-Implementierung: Eine Administrative Template-Richtlinie von null bis Produktion

Schritt 1: Die Richtlinie erstellen

Im Microsoft Intune Admin Center navigierst du zu Devices → Configuration profiles → Create → New Policy, wählst Windows 10 and later als Plattform und Templates → Administrative Templates als Profile Type. Danach vergibst du einen sprechenden Namen – und hier beginnt bereits die Best Practice: Der Name sollte der Namenskonvention deiner Organisation folgen, z. B. WIN – Baseline – Device – Administrative Restrictions. Du wirst diese Profile in zwei Jahren wiederfinden müssen; „Test123“ ist kein Name, sondern ein Verbrechen gegen dein zukünftiges Ich.

Der Editor zeigt dir danach zwei große Bereiche: Computer Configuration (geräteweit, schreibt nach HKLM-basierten Pfaden) und User Configuration (benutzerweit, schreibt nach HKCU-basierten Pfaden). Diese Trennung entspricht exakt der klassischen GPO-Welt.

Schritt 2: Konkrete Beispiele aus dem Alltag

Bauen wir drei typische Szenarien, die in nahezu jeder Migration auftauchen:

Beispiel 1 – OneDrive-Konfiguration (Computer Configuration): Suche im Editor nach „OneDrive“. Aktiviere „Silently move known folders to OneDrive“ und setze die Tenant-ID. Ergänze „Prevent users from moving their known folders to their PC“. Diese Kombination ist der Standard-Baustein für eine saubere OneDrive-Migration ohne User-Interaktion. Wichtig: Die Tenant-ID findest du im Entra Admin Center unter „Overview“ – sie ist nicht der Domainname.

Beispiel 2 – Microsoft Edge-Konfiguration (Computer Configuration): Die Edge-ADMX-Sektion in Intune ist ein eigenes kleines Universum. Typischer Starter: „Configure the home page URL“ setzen, „Disable developer tools“ für Standard-User aktivieren, und die Update-Richtlinien („Update policy override“) so konfigurieren, dass Edge über den eigenen Update-Zyklus verwaltet wird, nicht über Windows Update.

Beispiel 3 – User-Restriktionen (User Configuration): Hier zeigt sich die Besonderheit: User Configuration-Richtlinien greifen auch bei Azure AD-angemeldeten Nutzern, allerdings nur, wenn das Gerät Intune-verwaltet ist – die klassische „Loopback-Verarbeitung“ (Loopback Processing) aus der GPO-Welt gibt es in Intune als eigenständige Administrative-Template-Einstellung, ist aber mit Vorsicht zu genießen, weil sie die Zuweisungslogik verkompliziert.

Schritt 3: Zuweisung und Scope Tags

Nach dem Speichern weist du das Profil einer Gruppe zu. Auch hier gilt: Gruppenbasiert, niemals „All Users“/“All Devices“ für anything other than a true baseline. Für eine feingranulare Steuerung nutzt du dynamische Entra-Gruppen. Ein bewährtes Muster ist die Kombination aus Filtern (Filters in der Zuweisung): Du kannst eine Include-Filter-Regel auf Geräte mit einem bestimmten Gerätetyp anwenden und so z. B. Kiosk-Geräte von normalen Workstations trennen, ohne zusätzliche Gruppen pflegen zu müssen.

Schritt 4: Verifikation auf dem Client

Nach der Zuweisung verifizierst du auf einem Testgerät. Der schnellste Weg führt über die Registry:

# Prüfen, ob die OneDrive-KFM-Richtlinie angekommen ist
Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\OneDrive" |
    Select-Object KFMBlocksOptIn, KFMSilentOptInWithNotification, SilentAccountConfig

# Intune-Verwaltungs-Extension-Logs prüfen
Get-Content "$env:ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log" -Tail 50

# Erzwungenen Sync anstoßen
Get-ScheduledTask -TaskName "PushLaunch" | Start-ScheduledTask

Wenn der Registry-Pfad existiert und die Werte stimmen, ist die Richtlinie technisch angekommen. Falls nicht, geht es an die Diagnose (siehe Troubleshooting).

Migration aus einer bestehenden GPO-Welt

Der Profi-Weg für Migrationen ist nicht „abtippen“, sondern systematisch vorgehen:

Exportiere deine aktuellen GPOs mit Backup-GPO und analysiere die Reports (HTML/XML).
Führe eine GPO-Analyse mit dem Gruppenrichtlinien-Analysetool durch: Prüfe die Einstellungen gegen den Intune-Report „Group policy analytics“ (unter Devices → Policy and compliance → Group policy analytics). Dieses Tool liest deine GPO-Backups ein und sagt dir pro Einstellung, ob sie (a) in Intune als Administrative Template verfügbar ist, (b) über den Settings Catalog verfügbar ist, (c) eine alternative Methode benötigt (CSP, Script, App) oder (d) nicht unterstützt wird.
Migriere zuerst Einstellungen der Kategorien (a) und (b), dokumentiere die Ausnahmen.

Der zugehörige PowerShell-Weg für den Bulk-Export:

# Alle GPOs eines Domänen-Controllers sichern
Backup-Gpo -All -Path "C:\Temp\GPOBackup" -Comment "Pre-Intune-Migration"

# Report pro GPO generieren
Get-GPO -All | ForEach-Object {
    Get-GPOReport -Guid $_.Id -ReportType HTML `
        -Path ("C:\Temp\GPOBackup\{0}.html" -f $_.DisplayName)
}

Was Administrative Templates NICHT können – und der Brückenweg mit JSON

Ein immer wieder missverstandenes Thema: Viele GPO-Einstellungen existieren zwar „nicht“ in den Administrative Templates, sind aber über den Settings Catalog oder das Custom-Profile (OMA-URI) erreichbar. Beispiel: eine Policy, die nur als CSP verfügbar ist, setzt du über ein Custom Configuration Profile:

Name: LAPS-ADMX-Ersatz (Beispiel OMA-URI)
OMA-URI: ./Device/Vendor/MSFT/Policy/Config/ADMX_MicrosoftEdge/~Setting

Das exakte Format für ADMX-backed CSPs ist: ./Device/Vendor/MSFT/Policy/Config/<ADMX-Bereich>/~<Einstellungsname>, mit dem Wert im JSON-Format <enabled/> bzw. <disabled/> oder mit <data id=... value=.../>. Das ist fortgeschritten, aber genau das braucht man, wenn man 100 Prozent GPO-Parität erreichen will, ohne auf Scripts zu fallen. In der Praxis gilt: Erst Administrative Templates und Settings Catalog prüfen, dann Custom OMA-URI, dann Script – niemals umgekehrt.

Best Practices: Struktur, Wartbarkeit und Betrieb

1. Ein Profil pro logischem Zweck – nicht pro Einstellung, nicht als Riesen-Monolith

Die häufigsten Fehlstrukturen sind Extreme: Ein Profil pro einzelner Einstellung (ergibt 200 Profile, die niemand überblickt) oder ein Profil mit 150 Einstellungen aus 12 Themengebieten (ergibt ein unteilbares Monstrum, das du keinem Teilziel zuweisen kannst). Der Sweet Spot: thematisch kohärente Profile mit 5–30 verwandten Einstellungen, z. B. ein Profil „Edge – Security“, ein Profil „OneDrive – KFM“, ein Profil „Windows – User Restrictions“.

2. Namenskonvention konsequent durchziehen

Empfohlenes Muster: [Plattform] – [Zweck/Layer] – [Scope] – [Beschreibung], also z. B. WIN10 – Baseline – Device – Edge Security. Zusätzlich nutzen: Beschreibungsfeld mit Change-Historie (wer, wann, warum – zumindest das Warum), und Scope Tags für Delegation, wenn mehrere Teams im Tenant arbeiten.

3. Report-Driven Betrieb: Nutze die eingebaute GPO-Analyse

Microsoft investiert massiv in die Konvergenz von GPO und Intune. Der „Group policy analytics“-Report plus die Funktion „Migrate to Intune“ (Export von Settings-Catalog-fähigen Einstellungen als JSON/CSV) sind Pflichtbestandteil eines jeden Migrationsprojekts. Der Export selbst:


GET https://graph.microsoft.com/beta/deviceManagement/groupPolicyMigrationReports

Der Graph-API-Endpunkt liefert dir Migration-Reports im JSON-Format, die du in ein Tracking-Sheet (Excel, Power BI) überführen kannst – so entsteht ein verfolgbarer Migrationsfortschritt statt eines „Gefühls“.

4. Ring-basiertes Rollout

Administrative Template-Profile sind mächtig – und manche Einstellungen können Nutzer sofort sperrig einschränken. Fahre deshalb denselben Rollout wie bei Software: Pilotgruppe (IT-Team) → Early Adopters → Breite Masse. Intune Reports unter Devices → Configuration profiles → [Profil] → Device status zeigen dir Konflikte und Fehler pro Gerät – die solltest du in den ersten 48 Stunden nach jedem Rollout aktiv beobachten.

5. Konflikt-Prävention: Eine Einstellung, eine Quelle

Konflikte entstehen fast nie innerhalb eines Profils, sondern zwischen Profilen: Wenn Profil A „Windows Update auf Semi-Annual“ setzt und Profil B „Windows Update auf Monthly“ – gewinnt der CSP-Prioritäts-Algorithmus nicht vorhersehbar „der stärkere“, sondern es kommt zu einem Konflikt, den Intune als Fehler reportet. Regel: Jede Einstellung existiert in genau einem Profil. Nutze bei Bedarf die „Report“-Funktion von Settings Catalog-Profilen im „Settings“-Preview (Report-only, falls verfügbar) oder dedizierte Testgeräte, um Überschneidungen zu finden.

6. Dokumentation als Teil des Profils

Trage in das Beschreibungsfeld jedes Profils: Zweck, Owner, Datum des letzten Reviews, und Abhängigkeiten. Intune-Profile sind Infrastructure as Code ohne Code – die Dokumentation ist dein einziger Rettungsanker, wenn sechs Monate später die Frage kommt: „Warum hat der Edge hier kein Autoplay?“

7. ADMX-Ingestion für Drittanbieter-Apps

Fortgeschritten, aber für Enterprise-Umgebungen relevant: Apps wie Google Chrome, Adobe Reader oder Zoom liefern eigene ADMX-Dateien mit. Über den Settings Catalog bzw. Win32-Apps und den „Custom“-Kanal kannst du diese ADMX-Dateien per „Ingestion“ in Intune laden (Device → Administrative Templates → Upload, bzw. via Graph). Danach stehen die Richtlinien des Drittanbieters wie native Einstellungen zur Verfügung. Das ist der sauberste Weg, Chrome- oder Adobe-Policies ohne Scripting zentral zu steuern. Der Ingestion-Vorgang kann nicht über die klassische GUI für alle Apps genutzt werden – hier ist der Settings Catalog der zuverlässigste Weg.

Troubleshooting: Wenn die Richtlinie nicht ankommt

Diagnose-Pfad in fünf Schritten

Wenn eine Administrative Template-Einstellung auf dem Client nicht ankommt, gehe systematisch vor:

Schritt 1 – Zuweisung prüfen: Ist das Profil der richtigen Gruppe zugewiesen, und ist das Gerät/den User Mitglied dieser Gruppe? Im Admin Center unter „Assignments“ prüfen, im Entra-Portal die dynamische Gruppenregel testen.
Schritt 2 – Assignment Filter: Hat das Profil einen Include-/Exclude-Filter, der das Gerät ausschließt? Filter-Fehler sind die häufigste Ursache für „das Profil ist zugewiesen, kommt aber nie an“.
Schritt 3 – Profil-Status im Admin Center: Unter Devices → Configuration profiles → [Profil] → Device status: Zeigt das Gerät „Succeeded“, „Error“ oder „Pending“? Error-Details (Fehlercode + Benennung) sind dein erster konkreter Anhaltspunkt.
Schritt 4 – Client-Logs: Auf dem Gerät die Intune-Verwaltungserweiterungs-Logs prüfen (siehe unten). Das Ereignisprotokoll zeigt CSP-Fehler (z. B. „SyncML 500“ oder „403 – invalid parameters“).
Schritt 5 – Registry als Ziel: Prüfe, ob der Registry-Pfad, den die ADMX-Definition beschreibt, tatsächlich geschrieben wurde (siehe oben). Wenn der Pfad existiert, aber die Anwendung sich falsch verhält, liegt das Problem nicht in Intune, sondern in der Anwendungskonfiguration.

# Auf dem Client: Intune Sync-Diagnose

# 1. Aktuelle Intune-Policies abrufen
Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Policies" -Recurse |
    Select-Object PSPath | Out-File C:\Temp\policies.txt

# 2. Agentenstatus prüfen (Management Extension)
Get-Service IntuneManagementExtension | Select-Object Status, StartType

# 3. Diagnostic-Log live mitverfolgen
Get-EventLog -LogName "Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin" `
    -Newest 30 | Format-List TimeGenerated, Id, Message

Typische Fehlerbilder und deren Ursachen

Fehlercode 0x80180018 oder „Error 65000er“-Bereich: Deutet meist auf ein generisches CSP-Problem hin – z. B. ein ungültiger Wert in einer Einstellung. Prüfe den Wertebereich (z. B. erlaubt eine DropDown nur bestimmte Strings, die Registry erwartet aber einen DWORD).
„Pending“-Status für immer: Das Gerät hat lange nicht eingecheckt (offline, VPN-Blocker, DNS-Probleme) oder die Lizenz/Enrollment-Status ist inkonsistent. Ein dsregcmd /status auf dem Client zeigt, ob das Gerät korrekt hybrid-joined ist.
Richtlinie greift, aber die App ignoriert sie: Manche Anwendungen cachen Policies beim Start. Nach Policy-Anwendung: Neustart bzw. Anwendungsneustart erzwingen. OneDrive z. B. liest KFM-Einstellungen erst beim Prozessstart neu.
User Configuration greift nicht: User-ADMX-Richtlinien benötigen eine funktionierende User-Targeting-Logik und funktionieren nicht, wenn nur Device-Assignments existieren. Prüfe, ob das Profil der User-Gruppe (nicht nur der Geräte-Gruppe) zugewiesen ist.
Win-11-Unterschiede: Einige Einstellungen gelten nur für spezifische Windows-Builds – die ADMX-Definition (und das Tooltip im Editor) nennt Requirements. Teste auf einem aktuellen Build, bevor du auf einen Bug schließt.

Der Profi-Trick: Reporting per Graph

Für ein tenantweites Monitoring deiner Profile lohnt sich ein Blick auf die Graph-API:


GET https://graph.microsoft.com/beta/deviceManagement/deviceConfigurations
?$filter=Microsoft.graph.deviceConfiguration/odataType
eq 'microsoft.graph.windows10GeneralConfiguration'
&$expand=assignments

Mit dem zugehörigen deviceStatuses-Endpunkt pro Profil baust du dir in Kombination mit PowerShell ein tägliches Alerting, das dich über fehlerhafte Geräte pro Profil informiert – proaktiv statt reaktiv.

Fazit: Administrative Templates als Fundament, nicht als Krücke

Administrative Templates sind das Bindeglied zwischen der Welt, die du kennst, und der Cloud, in die du migrierst. Sie nehmen dir die Angst vor dem Verlust bewährter GPO-Konfiguration, weil sie technisch dasselbe tun wie ihre On-Prem-Vorbilder: ADMX-basierte Werte in die Policy-Zweige der Registry schreiben. Wer sie versteht – ADMX-Definition, Policy-Pfad, Sync-Kanal, Konfliktlogik – der hat das Fundament für die gesamte Konfigurationsverwaltung in Intune gelegt.

Die Königsdisziplin ist nicht, möglichst viele Einstellungen zu setzen, sondern eine saubere Struktur zu schaffen: thematisch kohärente Profile, konsistente Namenskonventionen, eine einzige Quelle pro Einstellung, dokumentierte Owner und ein Ring-basierten Rollout mit aktiver Beobachtung. Nutze Group Policy Analytics als Migrations-Beschleuniger, den Settings Catalog als modernes Arbeitspferd und Administrative Templates dort, wo Kompatibilität und Übersichtlichkeit zählen.

Damit hast du einen der wichtigsten Bausteine des Intune-Betriebs gemeistert. In den nächsten Sektionen bauen wir darauf auf: Wenn du weißt, wie ADMX-Einstellungen auf den Client kommen, verstehst du auch automatisch, warum Security Baselines so aufgebaut sind, wie sie sind – und warum die Kombination aus Baselines und eigenen Profilen mehr ist als die Summe ihrer Teile. Weiter geht’s.