Kann Microsoft 365 klassische Gruppenrichtlinien (GPO) ersetzen – und wo bleiben Windows Server und Active Directory überlegen?

Was klassische Gruppenrichtlinien in Active Directory technisch leisten: Scope, Vererbung, CSEs, Verarbeitung und typische Einsatzfelder

GPOs als Domänenmechanismus: Objektbindung, Scope und Sicherheitsfilterung

Klassische Gruppenrichtlinien (Group Policy Objects, GPOs) sind ein Domänenfeature von Active Directory, das Konfigurationen zentral verwaltet und auf Computer- und Benutzerobjekte ausrollt. Technisch besteht ein GPO aus zwei Teilen: einem Active-Directory-Objekt (Metadaten, Versionen, Links) und einer Dateistruktur im Sysvol (die eigentlichen Richtliniendateien). Die Verknüpfung (Link) eines GPOs erfolgt mit Sites, Domänen oder Organisationseinheiten (OUs) und bestimmt damit den Geltungsbereich (Scope). Die Richtlinie wirkt nicht „auf die OU“, sondern auf die darin enthaltenen Benutzer- und Computerobjekte, die die Verarbeitung durchführen.

Über Sicherheitsfilterung lässt sich zusätzlich steuern, welche Sicherheitsprinzipale ein verknüpftes GPO tatsächlich anwenden dürfen. Dafür sind zwei Berechtigungen entscheidend: Lesen und Anwenden der Gruppenrichtlinie. In der Praxis bildet dies die Grundlage für gestaffelte Rollouts, differenzierte Härtungsniveaus oder Ausnahmen für Testgeräte, ohne die OU-Struktur zu fragmentieren. WMI-Filter können den Scope zur Laufzeit anhand von Systemmerkmalen einschränken, etwa Betriebssystemversion, Hardwareklasse oder installierte Features; sie erhöhen jedoch die Komplexität und können die Verarbeitung verlangsamen.

Vererbung und Priorität: LSDOU, Enforced, Block Inheritance und Konfliktauflösung

Die Verarbeitungslogik klassischer GPOs folgt dem bekannten LSDOU-Prinzip: Local, Site, Domain, OU. Dabei werden mehrere verknüpfte GPOs innerhalb einer Ebene anhand ihrer Linkreihenfolge verarbeitet. Treffen mehrere Einstellungen auf dasselbe Ziel (etwa derselbe Registry-Wert), gewinnt grundsätzlich die später angewendete Richtlinie („last writer wins“). Diese deterministische Konfliktauflösung ist ein Kernmerkmal, weil sie gezielte Baselines plus abgeleitete Spezialregeln ermöglicht.

„Enforced“ (früher „No override“) und „Block Inheritance“ verändern das Standardverhalten: Eine OU kann Vererbung blockieren, um unerwünschte Domänenlinks zu unterdrücken; umgekehrt kann ein als „Enforced“ markierter Link nicht durch Blockieren oder durch widersprechende Einstellungen nachgelagerter OUs ausgehebelt werden. Damit lassen sich Sicherheitsvorgaben mit hoher Priorität absichern, allerdings steigt das Risiko, dass Betriebsanforderungen (z. B. Applikationsausnahmen) später nur noch über zusätzliche technische Umwege lösbar sind. Für saubere Designs ist daher eine restriktive Nutzung von „Enforced“ üblich, kombiniert mit klarer OU-Topologie und dokumentierten Ausnahmewegen.

• LSDOU-Reihenfolge: Lokale Richtlinien, dann Site-Links, dann Domänenlinks, zuletzt OU-Kette von oben nach unten; die effektive Sicht lässt sich clientseitig prüfen mit gpresult /r oder gpresult /h C:\Temp\gp.html.
• Linkreihenfolge innerhalb einer OU: Mehrere Links werden in der festgelegten Reihenfolge verarbeitet; die effektive Resultierende lässt sich u. a. im Resultant Set of Policy (RSOP) nachvollziehen.
• Block Inheritance: Unterdrückt vererbte GPO-Links aus übergeordneten Containern; „Enforced“-Links bleiben davon unberührt.
• Enforced: Erzwingt die Anwendung gegenüber nachgelagerten Konflikten und Vererbungsblockaden; geeignet für wenige, besonders kritische Vorgaben (z. B. Basishärtung).

Client Side Extensions (CSEs): Wie Einstellungen tatsächlich auf dem Gerät landen

GPOs „wirken“ nicht magisch, sondern über Client Side Extensions (CSEs) auf den Endpunkten. Jede CSE ist für eine Richtlinienkategorie verantwortlich, interpretiert die Richtliniendaten und setzt sie lokal um. Typische CSEs sind u. a. Sicherheitsrichtlinien (Security), Administrative Vorlagen (Registry-basierte Policies), Ordnerumleitung, Laufwerkszuordnungen und geplante Aufgaben über Group Policy Preferences. Die CSE-Architektur erklärt, warum GPOs in sehr unterschiedliche Betriebssystembereiche eingreifen können: Sie nutzen jeweils das native Windows-Konfigurationsmodell (Registry, Local Security Authority, Dienstkonfiguration, Dateisystem, Scheduled Tasks und weitere).

Für die Diagnose ist relevant, dass jede CSE ihren eigenen Status und Fehlermuster besitzt. Replikationsprobleme im Sysvol, fehlende Berechtigungen, ein langsamer Link oder fehlerhafte Erweiterungen führen nicht zwangsläufig zu einem Totalausfall, sondern oft zu Teilanwendungen. In der Praxis liefern die Ereignisprotokolle unter Applications and Services Logs\Microsoft\Windows\GroupPolicy\Operational sowie das klassische System-Log eine deutlich bessere Ursachenklärung als die reine Anzeige „Richtlinie wurde angewendet“.

Verarbeitung, Refresh und Hintergrundaktualisierung: Timing, Caching und Netzwerkbedingungen

Die Verarbeitung erfolgt getrennt für Computer- und Benutzerteil. Der Computerteil wird beim Systemstart angewendet, der Benutzerteil bei der Anmeldung; zusätzlich laufen Hintergrundaktualisierungen in Intervallen, die durch Richtlinien steuerbar sind. Viele Einstellungen sind „tattooing“-frei, also als echte Policies umgesetzt und beim Entfernen der Richtlinie rückgängig. Andere Kategorien, insbesondere Group Policy Preferences, schreiben häufig persistente Konfigurationen und erfordern explizite Gegenmaßnahmen, wenn ein späterer Rückbau garantiert sein muss.

Aus technischer Sicht spielt Caching eine wichtige Rolle: Der Client merkt sich GPO-Versionen und lädt nur Änderungen nach. Bei langsamen Verbindungen greifen Optimierungen wie „Slow Link Detection“, wodurch bestimmte CSEs standardmäßig nicht ausgeführt werden oder in einen reduzierten Modus wechseln. Das Verhalten ist nicht nur Komfortfunktion, sondern schützt auch Anmeldezeiten und WAN-Strecken. Umgekehrt kann eine falsche Einstufung als „slow link“ zu überraschenden Abweichungen führen, etwa wenn Ordnerumleitung oder Softwareinstallation ausbleibt.

• Manuelles Aktualisieren: gpupdate /force aktualisiert Computer- und Benutzerteil; für bestimmte CSEs sind Neustart oder Abmeldung erforderlich, was gpupdate entsprechend signalisiert.
• Resultierende Einstellungen prüfen: gpresult /scope computer /v
gpresult /scope user /v
• Richtlinienanalyse per MMC: rsop.msc zeigt eine modellierte Sicht auf die tatsächlich angewendeten Einstellungen (hilfreich bei Konflikten und Vererbung).

Typische Einsatzfelder: Sicherheitsbaseline, Systemhärtung, Benutzerumgebung und Betriebsvorgaben

Klassische GPOs sind besonders stark, wenn eine Windows-domänenbasierte Umgebung konsistent und eng geführt werden soll. Dazu gehören Passwort- und Kontorichtlinien (in modernen Designs häufig über Fine-Grained Password Policies ergänzt), lokale Sicherheitsoptionen, Kerberos- und NTLM-Vorgaben, Windows-Firewall-Profile, Audit- und Eventlog-Konfiguration sowie Dienst- und Treibereinstellungen. In der Benutzerumgebung spielen GPOs ihre Stärken bei der Steuerung des Shell-Verhaltens, beim Sperren von Systemfunktionen, bei Proxy- und Browserkonfigurationen, beim Setzen von Zertifikaten sowie bei standardisierten Laufwerks- und Druckerzuordnungen aus.

Für den Betrieb sind zudem Mechanismen wie Skripte (Start/Shutdown, Logon/Logoff) und Softwareverteilung über MSI (mit den bekannten Einschränkungen) relevant. Auch wenn nicht jede dieser Funktionen in modernen Endpoint-Ansätzen als Best Practice gilt, zeigt sich hier der technische Charakter von GPOs: Sie koppeln Verwaltung und Durchsetzung eng an die Domänenmitgliedschaft, die Erreichbarkeit eines Domänencontrollers und die Windows-spezifische CSE-Verarbeitung. Genau diese Eigenschaften machen sie in klassischen AD-Topologien präzise und verlässlich, zugleich aber schwer außerhalb dieses Modells zu übertragen.

GPO-Kategorien im Vergleich: vollständig ersetzbar, nur teilweise abbildbar oder nicht sinnvoll in Microsoft 365/Intune umsetzbar

Klassische GPOs wirken in einer Domäne zustandsorientiert und eng am Betriebssystem: Einstellungen werden am Client beim Start, bei Anmeldung oder per Hintergrundaktualisierung ausgewertet und bei Abweichungen erneut erzwungen. Microsoft-365-Mechanismen (Intune/MDM, Security Baselines, Conditional Access) arbeiten dagegen überwiegend deklarativ über CSPs, mit asynchroner Richtlinienzustellung und ohne vollständige Feature-Parität zu ADMX/GPP. Der Vergleich gelingt deshalb nur sauber, wenn Kategorien nach Steuerungsprinzip, Reichweite und Durchsetzungsgrad getrennt werden.

Vollständig oder nahezu vollständig ersetzbar: sicherheitsnahe Client-Konfiguration

Am besten migrieren Kategorien, die ohnehin über moderne Windows-Management-Schnittstellen (CSPs) abgebildet werden. Dazu zählen viele Einstellungen aus „Security Options“, Windows Defender, Firewall, BitLocker sowie ein großer Teil der Hardening-Vorgaben. Intune liefert hierfür konsistente Policy-Typen (Endpoint Security, Settings Catalog) und vorgefertigte Security Baselines. Wichtig bleibt die Konfliktvermeidung: Ein Gerät sollte für dieselbe Einstellung nicht parallel über GPO und MDM gesteuert werden, wenn der effektive Gewinner unklar ist oder das Ergebnis zwischen „tattooing“ und „stateful enforcement“ divergiert.

• Defender Antivirus: Intune Endpoint Security Policy „Antivirus“ (statt GPO unter Computerkonfiguration\Richtlinien\Administrative Vorlagen\Windows-Komponenten\Microsoft Defender Antivirus)
• Firewall-Regeln und Profile: Intune Endpoint Security Policy „Firewall“ (statt GPO unter Computerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\Windows Defender Firewall)
• BitLocker (Client): Intune Endpoint Security Policy „Disk Encryption“ (statt GPO unter Computerkonfiguration\Richtlinien\Administrative Vorlagen\Windows-Komponenten\BitLocker-Laufwerkverschlüsselung)
• Baseline-Hardening: Intune Security Baselines für Windows sowie Microsoft Defender for Endpoint Security Baseline (statt vieler Einzel-GPOs; Auswahl und Abweichungen dokumentieren)

Nur teilweise abbildbar: Domänenlogik, Benutzerumleitung, „GPP-Komfort“ und Timing

Teilweise abbildbar sind GPO-Kategorien, deren Nutzen aus der engen Kopplung an Domänenressourcen, aus synchronen Logon-/Startup-Phasen oder aus der Flexibilität der Group Policy Preferences entsteht. Intune kann zwar viele dieser Ergebnisse erreichen, aber häufig mit anderer Semantik: statt „Beim Anmelden sofort und garantiert“ eher „zeitnah nach Check-in“, statt „eine GPP mit Item-Level Targeting“ eher „mehrere Profile, Zuweisungsgruppen und ggf. Remediations“.

Beispiele sind Laufwerkszuordnungen, Druckerzuweisung, Registry-„Tattooing“ über GPP, komplexe Targeting-Regeln und klassische Folder Redirection. Für Ordnerumlenkung bietet sich im Cloud-Modell meist Known Folder Move (KFM) via OneDrive an. Das entspricht funktional dem Ziel (Benutzerdaten in einen verwalteten, synchronisierten Speicher), ersetzt aber nicht jedes Detail der GPO-Umleitung (z. B. spezifische Pfadlogik, Offline Files-Interaktion oder Roaming-Profile-Kombinationen).

• Known Folder Move statt Folder Redirection: OneDrive-Richtlinien im Intune Settings Catalog (typische Steuerung über Silently move Windows known folders to OneDrive und Prevent users from redirecting their Windows known folders to their PC)
• Drive Maps als Workaround: Zuweisung per PowerShell über Intune-Skripte oder Remediations (z. B. Aufruf von New-PSDrive oder net use; Ausführungskontext und Wiederholungslogik sauber festlegen)
• Softwareverteilung statt MSI-GPO: Paketierung als Intune Win32 App mit Install-/Uninstall-Commandlines und Detection Rules (anstatt „Assigned MSI“ über Computerkonfiguration\Richtlinien\Softwareeinstellungen\Softwareinstallation)
• Targeting statt WMI-Filter: Entra ID Gerätegruppen (dynamisch), Filter for device assignment und getrennte Profile (WMI-Logik oft nur durch Gruppensegmentierung oder Skript-Checks ersetzbar)

Nicht sinnvoll in Microsoft 365/Intune: AD-spezifische Richtlinien und GPO-only Mechanismen

Ein Teil klassischer GPO-Funktionalität ist technisch an Active Directory, Kerberos/LDAP und die GPO-Verarbeitungsengine gebunden. Dazu gehören domänenweite Kontorichtlinien (im Sinne von AD-Domänenkennwortrichtlinien und Account Lockout), viele Aspekte der Benutzerrechtezuweisung auf Domänenebene sowie Konfigurationen, die auf serverseitige Rollen oder auf klassische Windows-Logon-Infrastruktur (z. B. Loopback-Verarbeitung) angewiesen sind. In Cloud-only Umgebungen existiert dafür bewusst kein identisches Konzept, weil Identität, Gerätestatus und Zugriff über andere Kontrollpunkte modelliert werden.

Auch bestimmte „GPO-only“ Muster lassen sich zwar technisch umgehen (Skripte, eigene Agenten, Dritttools), gelten aber als unsaubere Ersatzkonstruktion, wenn sie lediglich die alte Kopplung in die Cloud verschieben. In der Praxis bleibt die bessere Option Koexistenz: AD-basierte Richtlinien dort belassen, wo Domänenbindung zwingend ist, und moderne Steuerung für mobile, internetnahe Endpunkte und Zero-Trust-Zugriffsmodelle über Intune und Conditional Access etablieren.

• Domänenkennwortrichtlinien/Lockout: AD-Mechanik über Default Domain Policy und Fine-Grained Password Policies (FGPP) bleibt AD-spezifisch; Cloud kann Authentifizierung und Zugriff ergänzen, ersetzt aber nicht die AD-Domänenpolicy
• Loopback-Verarbeitung und klassische Benutzerkontext-Steuerung: GPO-Option User Group Policy loopback processing mode hat kein MDM-Pendant; Cloud-Ansätze steuern eher per Gerätezustand, App-Zugriff und Identität
• GPP-spezifische CSEs und Legacy-Erweiterungen: Einstellungen, die auf Client Side Extensions außerhalb moderner CSPs basieren, sind in Intune nicht sinnvoll nachzubauen (stattdessen: Settings Catalog/ADMX-backed Policies nur dort, wo Windows eine MDM-Abbildung bereitstellt)

Praxisentscheidungen: Schritt-für-Schritt-Umsetzung typischer GPO-Szenarien und saubere Koexistenz- sowie Migrationsstrategien

Praxisentscheidungen scheitern selten an der Frage, ob sich eine einzelne GPO „irgendwie“ in der Cloud nachbauen lässt. Entscheidend sind Wirkmodell (Event- und Login-getrieben vs. MDM-Sync), Zielobjekt (Computer, Benutzer, App, Identität), Durchsetzung (hart erzwungen vs. asynchron/Best Effort je nach Policy-Typ) sowie Abhängigkeiten zu Dateiservices, Zertifikaten, Legacy-Anwendungen und Netzsegmenten. Daraus ergeben sich in hybriden Umgebungen wiederkehrende Muster: Sicherheitskonfigurationen wandern häufig nach Intune/Defender/Conditional Access, klassische Benutzerumleitungen bleiben oft an on-prem File-Services gebunden, und Spezialfälle wie granulare Explorer- oder Shell-Policies erfordern bewusste Alternativen.

Szenario 1: Baseline-Härtung und lokale Sicherheitsrichtlinien (GPO → Intune/Defender)

Für klassische Security-GPOs (UAC, Firewall, BitLocker, LSA/NTLM-Härtung, lokale Sicherheitsoptionen) bietet sich eine Migration in Intune-Mechanismen an, weil diese Einstellungen gerätezentriert, auditierbar und mit Rollback-Strategien kombinierbar sind. Domänenkennwortrichtlinien und Account-Lockout sind davon zu trennen: Diese bleiben in AD DS (bzw. FGPP) verankert und werden in Cloud-only nicht 1:1 ersetzt. Statt „eine große GPO“ zu kopieren, ist eine Zerlegung in Baselines (Security Baselines), gezielte Configuration Profiles und Endpoint-Security-Policies sinnvoll. Vorab sollte ein Ist-Abzug der wirksamen GPOs erfolgen, da viele Umgebungen über Jahre inkrementell gewachsen sind und widersprüchliche Einstellungen enthalten.

Operativ bewährt sich ein zweistufiges Vorgehen: zunächst Audit/Report, dann Durchsetzung. Bei BitLocker und Credential-Protection ist außerdem die Schlüssel- und Recovery-Verwaltung zu klären (z. B. Ablage in Entra ID vs. AD DS) und die Kompatibilität mit Pre-Boot-Auth, Helpdesk-Prozessen und Break-Glass-Szenarien zu prüfen.

• GPO-Wirkstand ermitteln: gpresult /h C:\Temp\gpresult.html
Get-GPResultantSetOfPolicy -ReportType Html -Path C:\Temp\rsop.html
• Richtlinieninventar exportieren: Backup-GPO -All -Path C:\Temp\GPOBackup
Get-GPO -All | Select-Object DisplayName,Id,GpoStatus
• Intune-Zieldefinition: Endpoint security > Security baselines und Devices > Configuration profiles nach Themen (Firewall, BitLocker, Defender, Account protection) trennen
• Stufenweises Rollout: Pilotgruppe in Entra ID, Zuweisung nach Gerätegruppe, begleitendes Monitoring über Device configuration und Microsoft Defender for Endpoint

Szenario 2: Geräteeinschränkungen und „Hard Lockdown“ (GPO → MDM, teilweise bewusst on-prem)

Klassische Gerätesperren aus GPOs reichen von USB-Blocklisten über Druckereinschränkungen bis zu komplexen AppLocker-/SRP-Designs. In Microsoft-365-Ansätzen verschiebt sich die Kontrolle: Viele Einschränkungen werden über Intune (z. B. Device Restrictions), Microsoft Defender (z. B. Attack Surface Reduction, Device Control) und Windows-Sicherheitsfeatures umgesetzt, während einige „harte“ Controls entweder andere Mechanismen erfordern (WDAC statt AppLocker) oder in Spezialumgebungen weiterhin per GPO besser kontrollierbar bleiben (z. B. RDS/Terminalserver-spezifische User-Policies, Legacy-Kiosk-Setups ohne moderne Managementschnittstellen).

Für Applikationskontrolle ist die strategische Entscheidung zentral: AppLocker ist etabliert, aber WDAC (Windows Defender Application Control) bietet eine modernere Trust- und Signaturlogik und lässt sich über Intune bereitstellen. Der Umstieg erfordert jedoch eine saubere Erfassungsphase (Audit), das Management von Allow-Listen und ein Notfallkonzept, da Fehlkonfigurationen produktive Geräte blockieren können.

Szenario 3: Benutzerumleitung, Netzlaufwerke, Fileservices (GPO → gezielte Alternativen statt 1:1)

Folder Redirection, Roaming Profiles, Drive Maps und Logon Scripts sind klassische GPO-Domänenmuster, die an SMB, DFS-Namespace, NTFS-ACLs und stabile Netzverfügbarkeit gekoppelt sind. Cloud-Richtlinien bieten dafür kein direktes Äquivalent, weil das Identitäts- und Gerätemodell nicht an eine „Always-on“-Domänenbindung gebunden ist. Saubere Alternativen sind je nach Anwendung: OneDrive Known Folder Move (KFM) für Desktop/Dokumente/Bilder, SharePoint/OneDrive statt File-Share für Kollaboration, oder bewusstes Beibehalten von SMB für Fachanwendungen mit Dateisperren und niedriger Latenzanforderung.

Für Netzlaufwerke und Skripte lohnt eine Entkopplung: Wenn Laufwerksbuchstaben weiterhin benötigt werden, ist eine moderne Bereitstellung über Intune-Skripte oder Win32-App-Pakete mit klarer Fehlerbehandlung und Logging meist robuster als „magische“ Logon-Skripte, die über Jahre gewachsen sind. Wo möglich, reduziert der Wechsel auf UNC-Pfade oder applizierte Pfadkonfigurationen in der Anwendung die Abhängigkeit von Laufwerksbuchstaben.

• KFM statt Folder Redirection: OneDrive-Policy in Intune/Cloud Policy setzen und Migration nach Nutzersegmenten planen; relevante Identifikatoren sind Known Folder Move und OneDrive-Adminvorlagen
• Drive Mapping mit kontrolliertem Logging: PowerShell per Intune (Remediation oder Skript) mit New-PSDrive -Persist und Fehlerausgabe in ein Log unter C:\ProgramData
• SMB bewusst behalten, aber modernisieren: Zugriff über Entra Kerberos/Hybrid je nach Architektur prüfen; klassische Abhängigkeiten (z. B. \\dfsroot\share) dokumentieren und mit Netzwerk-/VPN-Design abgleichen

Szenario 4: Browser-, Office- und Identitätsrichtlinien (GPO → Cloud Policy, Conditional Access)

Viele Umgebungen pflegen umfangreiche GPO-Sets für Microsoft Edge/Chrome, Office-Konfiguration und Identitätszwang (MFA, Gerätestatus). Hier ist die Trennung zwischen Geräteeinstellung und Zugriffskontrolle entscheidend: Browser-/Office-Policies lassen sich häufig über Cloud Policy oder Intune-Administrative Templates abbilden. Zugriffskontrolle gehört in Conditional Access, weil sie am Identitätssignal ansetzt (Benutzer, Risiko, Gerät konform, Standort, Client-App) und nicht vom „GPO-Timing“ abhängt.

Ein verbreiteter Fehler ist die Vermischung von lokalen Härtungseinstellungen mit Zugriffsregeln. Wenn beispielsweise Legacy-Auth blockiert werden soll, ist dies eine Identitätsentscheidung (Conditional Access und/oder tenantseitige Authentifizierungsrichtlinien), nicht primär eine lokale Geräteeinstellung. Umgekehrt bleibt das Absichern des lokalen Browsers (Extensions, SmartScreen, Download-Verhalten) eine Endpunktkonfiguration, die auch ohne Benutzeranmeldung wirksam sein muss.

Koexistenz- und Migrationsmuster: Zuständigkeiten entwirren, Konflikte verhindern

Koexistenz gelingt, wenn jede Einstellung genau einem Steuerungssystem zugeordnet wird. In hybriden Windows-Umgebungen ist die kritischste Konfliktquelle die doppelte Konfiguration identischer Bereiche über GPO und MDM. Für Windows existiert dafür keine generelle, einheitliche „Konfliktauflösung“ zwischen GPO und MDM; das Zusammenspiel ist je nach Richtlinienbereich unterschiedlich (z. B. Security-/CSP-Settings vs. ADMX/Administrative Templates) und kann zusätzlich durch Co-Management (ConfigMgr/Intune) beeinflusst werden. Praktisch hilft eine klare Regel: Sicherheits- und Compliance-Steuerung entweder konsequent über Intune/Defender oder bewusst in GPO belassen, aber nicht parallel „halb“ konfigurieren.

Migration sollte daher nicht nach Organisationsstruktur (OU-Baum) erfolgen, sondern nach Workloads: Baseline Security, Update-Management, App-Deployment, Identität/Access, Datenablage, Druck, Spezialgeräte. Je Workload entsteht ein Abnahmekriterium (Monitoring, Rückfallplan, Supportprozess). Erst danach folgt die OU-/GPO-Aufräumphase mit konsequentem Entfernen obsoleter Einstellungen, damit keine „Schattenrichtlinien“ erhalten bleiben.

• Konfliktarme Pilotierung: Testgeräte in eine dedizierte OU mit minimalen GPOs verschieben und MDM-Zuweisung über Entra-Gerätegruppe steuern; Validierung mit mdmdiagnosticstool.exe -area DeviceProvisioning -cab C:\Temp\mdm.cab (je nach Windows-Version/Build können andere Areas sinnvoller sein, z. B. DeviceEnrollment oder DeviceManagement)
• GPO-Reduktion statt „Lift-and-Shift“: GPOs thematisch clustern, doppelte Settings entfernen und per Get-GPOReport -Guid <GUID> -ReportType Xml -Path C:\Temp\gpo.xml maschinenlesbar vergleichen
• Rückfallpfad definieren: Für jede migrierte Policy ein Deaktivierungsverfahren in Intune (Assignment entfernen), plus dokumentierte Wiederaktivierung der GPO in der Pilot-OU
• Messbarkeit sicherstellen: Compliance über Intune-Status/Defender-Reports, GPO-Wirkung über gpresult und Ereignisprotokolle; Abnahmekriterien vor dem breiten Rollout festlegen