Gruppenrichtlinien nach Intune migrieren mit Group Policy Analytics (2026)

Aktualisiert: 18. Juli 2026

Gruppenrichtlinien nach Intune migrieren bedeutet, bestehende GPOs als XML aus der Gruppenrichtlinienverwaltung zu exportieren, sie über Group Policy Analytics im Intune Admin Center zu importieren und die unterstützten Einstellungen mit einem Klick in ein Settings-Catalog-Profil zu überführen. In der Praxis ist das ein „Best-Effort"-Prozess: rund 60–80 % Ihrer typischen GPO-Sammlung lassen sich sauber übertragen, der Rest braucht OMA-URI-Profile, PowerShell-Remediations oder gehört ehrlich gesagt gelöscht statt migriert. Dieser Leitfaden zeigt Ihnen den kompletten Weg, inklusive der Fallstricke, über die ich in meinen letzten drei Migrationsprojekten gestolpert bin.

• Group Policy Analytics ist in Microsoft Intune allgemein verfügbar und übersetzt importierte GPO-XMLs automatisch in Settings-Catalog-Profile, inklusive einer MDM-Support-Kennzahl je GPO.
• Standardmäßig gewinnt die Domänen-GPO gegenüber Intune. Erst mit der CSP-Einstellung MDMWinsOverGP=1 setzt Intune sich bei Policy-CSP-Konflikten durch. Für BitLocker, Defender und Windows Update for Business gilt das jedoch nicht.
• Group Policy Preferences (GPP), also gemappte Laufwerke, Druckerbereitstellung, Verknüpfungen und geplante Aufgaben, werden von Group Policy Analytics nicht abgedeckt. Diese müssen über PowerShell-Skripte oder Proactive Remediations neu abgebildet werden.
• Für die Migration ist ein Microsoft 365 E3/E5- oder Intune-Suite-Lizenzpaket sowie Microsoft Entra ID P1 zwingend erforderlich. Die maximale XML-Dateigröße pro GPO beträgt 4 MB und die Datei muss Unicode-kodiert sein.
• Rollen Sie neu migrierte Profile immer zuerst an eine Pilot-Sicherheitsgruppe aus. Ein MDMDiagReport.html zeigt Ihnen im Abschnitt „Blocked Group Policies", welche CSP welche GPO tatsächlich blockiert.

Warum jetzt der richtige Zeitpunkt zum Migrieren ist

Ich sag's mal ganz direkt: Gruppenrichtlinien sind großartig, solange Ihre Geräte im Büro stehen, im Firmennetz hängen und einen Domain Controller sehen. Für alles andere sind GPOs 2026 einfach das falsche Werkzeug. Die typische mittelständische IT-Landschaft, die ich derzeit auf dem Tisch habe, sieht so aus: rund 40 % der Endgeräte sind Notebooks, die entweder gar nicht mehr oder nur noch sporadisch im Büro andocken. Für diese Geräte greifen klassische GPOs entweder gar nicht mehr oder nur noch mit stundenlanger VPN-Verbindung. Intune schert das nicht, die Policy wird über HTTPS ausgeliefert, sobald das Gerät im Internet ist.

Dazu kommt eine harte Deadline: Microsoft hat auf der Ignite 2025 klargestellt, dass alle neuen Sicherheitsbaselines primär als Settings-Catalog-Profile veröffentlicht werden. Die Security Baseline für Windows 11, Version 25H2, ist bereits Intune-first; die entsprechende GPO-Backport-Version erscheint mit rund sechs Wochen Verzögerung. Wer 2026 sicherheitstechnisch aktuell bleiben will, arbeitet zwangsläufig mit Intune-Profilen.

Der dritte Treiber ist Compliance. Sowohl NIS2 als auch die neuen ISO 27001:2022-Kontrollen A.8.19 und A.8.20 verlangen den Nachweis, dass Sicherheitseinstellungen tatsächlich auf jedem Endgerät angewendet werden, nicht nur, dass sie theoretisch in einer GPO stehen. Intune liefert diesen Nachweis pro Gerät und pro Einstellung auf Knopfdruck; GPO-basierte Umgebungen brauchen dafür Zusatztools wie Tenable oder Configuration Manager Compliance-Baselines. Wer heute noch nicht mit der Migration begonnen hat, hat in 24 Monaten ein Auditproblem. Ich sehe das gerade wöchentlich bei Kunden, die genau deshalb Feuer unterm Hintern haben.

Gruppenrichtlinien vs. Intune Settings Catalog: der ehrliche Vergleich

Bevor Sie irgendetwas migrieren, sollten Sie die technischen Unterschiede der beiden Systeme verinnerlichen. Beide erfüllen ähnliche Zwecke, funktionieren aber grundlegend anders, und das führt bei Migrationen immer wieder zu unangenehmen Überraschungen. Die folgende Tabelle fasst die Punkte zusammen, die in meinen Projekten wirklich relevant geworden sind:

Merkmal	Gruppenrichtlinie (GPO)	Intune Settings Catalog
Standard-Präzedenz bei Konflikten	Gewinnt	Verliert (bis MDMWinsOverGP=1 gesetzt ist)
Konnektivitätsanforderung	Sichtverbindung zum Domain Controller (LAN/VPN)	HTTPS ins Internet
Anwendungsreihenfolge	LSDOU (Local, Site, Domain, OU)	Keine Hierarchie, Konflikt = keine Anwendung
Zielgruppen	Computer- und Benutzer-OUs	Microsoft Entra Security Groups (Benutzer/Geräte)
Berichterstattung / Compliance	gpresult, RSoP, externe Tools	Pro Gerät und Einstellung im Admin Center
Änderungshistorie	AGPM oder Drittanbieter	Integrierte Audit-Logs
Group Policy Preferences (GPP)	Vollständig unterstützt	Nicht unterstützt (Ersatz via PowerShell/Remediations)
ADMX-Ingest für Drittanbieter	Nativ (zentraler Store)	Manueller Import pro ADMX/ADML

Der wichtigste Punkt für die Migration ist die letzte Zeile: Konflikte werden in Intune nicht durch Präzedenz, sondern durch Nicht-Anwendung gelöst. Wenn Sie versehentlich zwei Profile mit widersprüchlichen Werten derselben Gerätegruppe zuweisen, wird die Einstellung schlicht nicht angewendet, und Intune meldet den Konflikt. Für uns Windows-Admins, die jahrelang mit „OU sticht Domain sticht Site sticht Local" gedacht haben, ist das eine echte Umstellung. Wer bereits mit modernen Identitätswerkzeugen wie Passkeys in Microsoft Entra ID arbeitet, kennt diese Logik allerdings schon: Zuweisung über Sicherheitsgruppen, nicht über eine Vererbungshierarchie.

Voraussetzungen und Lizenzierung

Bevor Sie das Intune Admin Center überhaupt sinnvoll nutzen können, brauchen Sie die passende Lizenzierung. Group Policy Analytics ist Teil von Microsoft Intune und benötigt daher eine der folgenden Lizenzen: Microsoft 365 E3 oder E5, Microsoft 365 Business Premium, ein eigenständiges Intune-Plan-1-Abonnement oder (wenn Sie erweiterte Funktionen wie Proactive Remediations für Windows 11 Pro nutzen wollen) die Intune Suite. Dazu kommt Microsoft Entra ID Plan 1 (in Microsoft 365 E3/E5 bereits enthalten).

Für die eigentliche Migration brauchen die Konten, die den Import durchführen, mindestens die Rolle Intune Administrator oder eine benutzerdefinierte Rolle mit den Rechten Device configurations - Assign/Create/Delete/Read/Update. In Umgebungen mit RBAC-Scope-Tags gilt: Nur Administratoren, deren Scope Tag dem importierten GPO zugewiesen ist, können daraus später ein Settings-Catalog-Profil erstellen. Klingt kleinteilig, ist aber der Grund, warum in großen Umgebungen die Migration oft an einer scheinbar sinnlosen „Access denied"-Meldung scheitert.

Auf der Client-Seite müssen die Geräte in Intune registriert sein, entweder über Microsoft Entra Join (voll cloud-nativ) oder als Hybrid Entra Join (parallel zur klassischen AD-Domäne). Für Hybrid-Umgebungen ist das gleichzeitig der Standardpfad, weil Sie GPOs und Intune-Profile parallel betreiben können, während Sie migrieren. Ich empfehle in praktisch allen Projekten diesen Ansatz. Der harte Cut von GPO auf Intune „übers Wochenende" endet ziemlich zuverlässig im Wochenend-Support-Tsunami.

Wie migriere ich Gruppenrichtlinien nach Intune? Schritt für Schritt

Der Migrationsablauf besteht aus fünf Phasen: Export, Import, Analyse, Migration und Zuweisung. Ich gehe jede Phase mit den konkreten Befehlen und Klicks durch. Führen Sie den Export idealerweise nicht manuell aus, sondern per PowerShell. So haben Sie eine reproduzierbare Baseline und können vor jeder größeren Migrationsrunde einen frischen Snapshot ziehen.

Schritt 1: GPOs als XML exportieren

Öffnen Sie eine PowerShell-Konsole auf einem Domain Controller oder auf einem Client mit installierten RSAT-Tools. Das folgende Skript exportiert alle GPOs der Domäne als einzelne XML-Dateien in einen Zielordner:

# GPO-Export für Intune Group Policy Analytics
# Erzeugt eine XML pro GPO, Unicode-kodiert, max. 4 MB je Datei
# Ausfuehren mit einem Konto, das Read-Rechte auf alle Ziel-GPOs hat

Import-Module GroupPolicy

$exportPath = "C:\Temp\GPOExport"
if (-not (Test-Path $exportPath)) { New-Item -ItemType Directory -Path $exportPath | Out-Null }

# Alle GPOs der Domaene sammeln (auch nicht verlinkte, damit nichts verloren geht)
$gpos = Get-GPO -All

foreach ($gpo in $gpos) {
    # Ungueltige Zeichen aus dem Dateinamen entfernen
    $safeName = ($gpo.DisplayName -replace '[\\/:*?"<>|]', '_')
    $file    = Join-Path $exportPath "$safeName.xml"

    # Export als XML-Bericht (Unicode ist Standard bei Get-GPOReport)
    Get-GPOReport -Guid $gpo.Id -ReportType Xml -Path $file

    $sizeMb = [math]::Round((Get-Item $file).Length / 1MB, 2)
    if ($sizeMb -ge 4) {
        Write-Warning "$($gpo.DisplayName) ist $sizeMb MB gross - Intune-Import schlaegt fehl (Limit: 4 MB)."
    } else {
        Write-Host "OK  $($gpo.DisplayName) ($sizeMb MB)"
    }
}

Ergebnis ist ein Ordner voller XML-Dateien, mit denen Sie zum Intune Admin Center wechseln. Die Warnung für Dateien ab 4 MB ist wichtig, denn solche GPOs sind praktisch immer historisch gewachsene Sammelbecken, die Sie ohnehin vor dem Import aufteilen sollten.

Schritt 2: Import in Group Policy Analytics

Navigieren Sie im Intune Admin Center zu Devices → Manage devices → Group Policy analytics. Klicken Sie auf Import, wählen Sie die XML-Dateien aus dem Export-Ordner aus und vergeben Sie bei Bedarf Scope Tags. Für einen ersten Test genügen 3–5 GPOs; ein Massenimport aller 200 Domänen-GPOs macht die Analyseansicht später unübersichtlich.

Schritt 3: Analyse der MDM-Support-Quote

Nach dem Import sehen Sie in der Liste jeden GPO mit einer Prozentzahl in der Spalte MDM Support. Diese Zahl gibt an, wie viele der Einstellungen im GPO ein direktes Äquivalent im Settings Catalog haben. Klicken Sie auf eine Zahl, um die Einstellungen im Detail zu sehen. Jede Einstellung ist einer von drei Kategorien zugeordnet:

• Yes: Migration möglich, direktes Äquivalent im Settings Catalog vorhanden
• No: Kein Äquivalent, muss über OMA-URI, PowerShell-Skript oder Remediation abgebildet werden
• Deprecated: Veraltete Einstellung (z. B. für Internet Explorer 8), sollte nicht migriert, sondern gelöscht werden

Schritt 4: Migration in ein Settings-Catalog-Profil

Setzen Sie das Häkchen neben einem GPO mit hoher MDM-Support-Quote und klicken Sie auf Migrate. Der Assistent zeigt alle Einstellungen mit ihrem Status. Wählen Sie nur die als Ready for migration markierten aus. Vergeben Sie einen sprechenden Namen (mein bewährtes Schema: W11_<Zweck>_<Ring>, also z. B. W11_EdgeSecurity_Pilot). Nach dem Speichern erstellt Intune ein Settings-Catalog-Profil, das Sie im normalen Konfigurationsprofil-Editor weiterbearbeiten können, inklusive vorbelegten Werten aus der GPO-XML.

Schritt 5: Zuweisung an eine Pilotgruppe

Weisen Sie das neue Profil zwingend zuerst einer Pilot-Sicherheitsgruppe zu, die maximal 5–10 Testgeräte enthält. Ich habe in einem Projekt einmal miterlebt, wie ein migriertes Edge-Profil versehentlich die gesamte Belegschaft von jeglichen Downloads abgeschnitten hat: 2.400 Nutzer, 15 Minuten. Das war keine schöne Kaffeeküchengesprächsgrundlage. Nach 48 Stunden ohne Support-Tickets aus dem Pilot erweitern Sie in Ringen (Pilot → Early Adopters → Broad → All).

Was ist MDMWinsOverGP und wie löse ich GPO/Intune-Konflikte?

Standardmäßig gewinnt bei einem Konflikt zwischen einer Domänen-GPO und einer Intune-Policy die GPO, auch wenn beide dieselbe Einstellung mit unterschiedlichen Werten setzen. Das ist historisch bedingt und war bis Windows 10 Version 1709 hartkodiert. Ab Version 1803 hat Microsoft die CSP-Einstellung ControlPolicyConflict/MDMWinsOverGP eingeführt, mit der Sie diese Präzedenz umdrehen können. Für jede Migration, die parallel zu bestehenden GPOs läuft, ist das Setzen dieser Einstellung Pflicht. Sonst wundern Sie sich, warum Ihre migrierten Profile scheinbar nichts bewirken.

MDMWinsOverGP im Settings Catalog aktivieren

Erstellen Sie im Intune Admin Center unter Devices → Configuration → Create → Settings catalog ein neues Profil für Windows 10 and later. Suchen Sie im Settings Picker nach „Control Policy Conflict" und fügen Sie die Einstellung MDM Wins Over GP hinzu. Setzen Sie den Wert auf The MDM policy is used and the GP policy is blocked. Weisen Sie dieses Profil allen Geräten zu, die sowohl von GPO als auch von Intune verwaltet werden.

Alternativ als benutzerdefiniertes OMA-URI-Profil

# Name: MDMWinsOverGP
# OMA-URI: ./Device/Vendor/MSFT/Policy/Config/ControlPolicyConflict/MDMWinsOverGP
# Datentyp: Integer
# Wert:    1

Nach dem Umschalten prüfen

Erzwingen Sie auf einem Testgerät eine MDM-Synchronisation über Einstellungen → Konten → Auf Arbeits- oder Schulkonto zugreifen → Info → Synchronisieren. Anschließend sollten Sie im Registry-Pfad HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\ControlPolicyConflict den Wert MDMWinsOverGP=1 sehen. Ab diesem Moment gewinnen Ihre Intune-Profile bei Policy-CSP-Konflikten.

Umgang mit nicht migrierbaren Einstellungen (GPP, ADMX, Skripte)

Die unbequeme Wahrheit: Selbst bei einer sauberen Migration bleiben typischerweise 20–40 % der GPO-Einstellungen im Analytics-Bericht als „Not supported" liegen. Der Umgang damit hängt vom Einstellungstyp ab. Für uns Windows-Admins bedeutet das: Wir tauschen einen bekannten Werkzeugkasten (GPMC + Scripts) gegen einen neuen Werkzeugkasten (Settings Catalog + Remediations + OMA-URI). Der neue Kasten ist mächtiger, aber weniger vertraut, und genau da entsteht der Migrationsaufwand.

Group Policy Preferences (GPP): der große weiße Fleck

Group Policy Analytics deckt keine Group Policy Preferences ab. Konkret heißt das: gemappte Netzlaufwerke, Druckerbereitstellung, Registry-Preferences, Verknüpfungen, Umgebungsvariablen und geplante Aufgaben werden ignoriert. Ersatz gibt es je nach Anwendungsfall:

• Netzlaufwerke: PowerShell-Skript unter Devices → Scripts and remediations mit New-PSDrive -Persist oder net use
• Drucker: Universal Print (Microsoft-Cloud-Druckdienst) oder Printer-Provisioning-Skript. Wer noch klassisch druckt, sollte auch unseren Leitfaden Drucker offline unter Windows 11 beheben in die Runbook-Sammlung aufnehmen.
• Geplante Aufgaben: PowerShell mit Register-ScheduledTask, ausgerollt als Platform Script
• Registry-Preferences: Settings Catalog verwendet, wenn möglich, sonst PowerShell mit Set-ItemProperty

Custom ADMX (z. B. Google Chrome, Adobe Reader, FSLogix)

Drittanbieter-ADMX-Dateien müssen im Intune Admin Center manuell importiert werden, und zwar unter Devices → Configuration → Import ADMX. Danach stehen die Einstellungen im Settings Catalog zur Verfügung. Für Microsoft-eigene ADMX (Edge, Office) ist das nicht nötig, die sind bereits eingebaut. Die Google-Chrome-ADMX ist der klassische Kandidat für Ingest, den ich in fast jeder Migration einmal manuell hochlade.

Skripte, die früher via GPO liefen

Für Logon-, Logoff-, Startup- und Shutdown-Skripte gibt es in Intune zwei Wege: Platform Scripts (einmalige Ausführung bei Enrollment, laufen als SYSTEM) und Proactive Remediations (regelmäßige Erkennungs-/Behebungspaare mit Reporting). Für 95 % der klassischen GPO-Skripte sind Platform Scripts der richtige Weg. Nur wenn Sie wiederkehrende Prüfungen mit Compliance-Bericht brauchen, greifen Sie zu Remediations. Ein Beispiel für ein einfaches Platform Script, das die klassische GPO-Aufgabe „SMBv1 deaktivieren" ersetzt:

# SMBv1 deaktivieren - Ersatz fuer klassische GPO-Registry-Preference
# Bereitstellen ueber: Intune Admin Center > Devices > Scripts and remediations
# Ausfuehrungskontext: SYSTEM, 64-bit, keine Signaturpruefung
# Rueckgabewert 0 = Erfolg (Intune wertet Exit-Code aus)

$feature = Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

if ($feature.State -eq 'Enabled') {
    try {
        # SMBv1-Feature deaktivieren, kein automatischer Reboot
        Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart | Out-Null
        Write-Output "SMBv1 wurde deaktiviert. Reboot erforderlich."
        exit 0
    } catch {
        Write-Error "Fehler beim Deaktivieren: $_"
        exit 1
    }
} else {
    Write-Output "SMBv1 bereits deaktiviert - keine Aenderung noetig."
    exit 0
}

Validierung mit MDMDiagReport und PowerShell

Nach jeder Migrationsrunde brauchen Sie eine belastbare Aussage, welche Policy auf dem Endgerät tatsächlich gewinnt. Das klassische gpresult /h zeigt Ihnen nur die GPO-Seite; die Intune-Sicht fehlt komplett. Für die vollständige Analyse gibt es zwei Werkzeuge, die Sie kennen müssen.

MDMDiagReport erzeugen

# MDM-Diagnosereport auf einem Client erstellen
# Erzeugt: %ProgramData%\Microsoft\IntuneManagementExtension\Logs\ und
#          MDMDiagReport.html in dem angegebenen Zielordner
# Ausfuehren in einer administrativen PowerShell oder cmd

$out = "C:\Temp\MDMDiag"
if (-not (Test-Path $out)) { New-Item -ItemType Directory -Path $out | Out-Null }

# Vollstaendiger Report inkl. Autopilot-, Enrollment- und Policy-CSP-Daten
MdmDiagnosticsTool.exe -area "DeviceEnrollment;DeviceProvisioning;Autopilot" -zip "$out\MDMDiag.zip"

# Alternativ nur HTML-Report
MdmDiagnosticsTool.exe -out $out

# Report oeffnen und im Browser den Abschnitt "Blocked Group Policies" pruefen
Start-Process "$out\MDMDiagReport.html"

Öffnen Sie den erzeugten MDMDiagReport.html und scrollen Sie zum Abschnitt „Blocked Group Policies". Dort sehen Sie exakt, welche GPO durch welche Policy-CSP-Einstellung blockiert wird. Das ist der ehrlichste Nachweis für eine funktionierende MDMWinsOverGP-Konfiguration und gleichzeitig Ihr wichtigstes Argument gegen den skeptischen Kollegen, der behauptet „aber meine GPO greift doch noch, ich sehe sie in gpresult".

Direktabfrage der angewendeten CSP-Werte

# Alle aktuell angewendeten Policy-CSP-Werte auslesen
# Nuetzlich fuer Vorher-/Nachher-Vergleiche waehrend der Migration

Get-ChildItem -Path 'HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device' -Recurse |
    ForEach-Object {
        # Nur Schluessel mit Werten anzeigen
        $props = Get-ItemProperty -Path $_.PSPath -ErrorAction SilentlyContinue
        if ($props) {
            [PSCustomObject]@{
                Area  = $_.PSChildName
                Path  = $_.PSPath -replace '.*PolicyManager\\current\\device\\',''
                Value = ($props.PSObject.Properties | Where-Object { $_.Name -notmatch '^PS' } |
                         Select-Object -First 1 -ExpandProperty Value)
            }
        }
    } | Format-Table -AutoSize

Dieses Snippet ist mein persönlicher Standard-Diagnoseschritt bei „meine Intune-Policy scheint nicht zu greifen"-Tickets. Man sieht auf einen Blick, welche CSPs Werte gesetzt haben und welche nicht, und kann dann gezielt in den Intune-Reporting-Blade schauen, warum die eigene Zuweisung nicht ankommt.

Meine Fünf-Punkte-Checkliste vor dem Produktiv-Rollout

Nach mittlerweile über einem Dutzend GPO-zu-Intune-Migrationen habe ich mir eine feste Checkliste zurechtgelegt, die ich vor jedem Broad-Rollout durchgehe. Wenn ein Punkt nicht sauber ist, wird nicht ausgerollt, auch wenn der Projektplan brennt.

1. Pilotgruppe hat mindestens 72 Stunden ohne Ticketauffälligkeiten überstanden. Weniger Zeit reicht nicht, um Randfälle wie Kaltstarts am Montagmorgen oder VPN-Reconnects abzudecken.
2. MDMDiagReport.html liegt vor und wurde gelesen. Nicht überflogen, sondern gelesen. Blocked-Group-Policies-Abschnitt muss zu Ihren Erwartungen passen.
3. Rollback-Plan existiert und wurde einmal geübt. Rollback heißt in Intune: Zuweisung entfernen, MDM-Sync erzwingen, Registry-Pfad prüfen. Das dauert bei 1.000 Geräten realistisch 4–8 Stunden.
4. Support-Team hat die Runbook-Version für die neue Policy erhalten. Tier-1-Kollegen müssen wissen, dass ab Freitag eine bestimmte Einstellung nicht mehr über gpresult, sondern über den MDM-Bericht diagnostiziert wird.
5. MDMWinsOverGP ist entweder bewusst gesetzt oder bewusst nicht gesetzt. Die Standardantwort „ist mir egal" ist nie richtig. Wer parallel GPO und Intune fährt, muss sich für eine Präzedenz entscheiden.

Diese Liste hat sich bewährt und verhindert die typischen „Wir haben doch alles getestet"-Katastrophen. Sie funktioniert genauso gut, wenn Sie moderne Endpoint-Security-Komponenten wie BitLocker-Wiederherstellungsschlüssel parallel migrieren. Dort ist die Trennung von GPO- und Intune-Zuständigkeit besonders wichtig, weil MDMWinsOverGP für BitLocker eben nicht gilt.

Wer tiefer in die Materie einsteigen will, findet in der offiziellen Microsoft-Learn-Anleitung zur Settings-Catalog-Migration die vollständige klick-für-klick-Dokumentation, und die Referenz zu Group Policy Analytics beschreibt alle Sonderfälle bei Import und Analyse. Für die MDMWinsOverGP-Details ist die Policy-CSP-Dokumentation ControlPolicyConflict die maßgebliche Quelle.

Häufig gestellte Fragen

Welche Gruppenrichtlinien werden bei der Migration nicht unterstützt?

Group Policy Preferences (GPP) wie Netzlaufwerkzuordnungen, Druckerbereitstellung, Registry-Preferences und geplante Aufgaben werden vollständig ignoriert. Ebenso wenig direkt migrierbar sind AppLocker-Regeln und Windows-Defender-Firewall-Regeln, diese müssen im Endpoint-Security-Blade neu erstellt werden. Custom-ADMX-Dateien (z. B. für Google Chrome) müssen manuell importiert werden.

Sollten GPOs und Intune-Profile parallel bestehen bleiben?

Ja, für die Übergangsphase ist das der empfohlene Ansatz. Behalten Sie die GPOs verlinkt, setzen Sie aber MDMWinsOverGP=1, damit Intune bei Konflikten gewinnt. Erst wenn Sie über MDMDiagReport nachgewiesen haben, dass Intune alle relevanten Einstellungen abdeckt, lösen Sie die GPO-Verlinkung. Ein harter Cut „übers Wochenende" ist selten eine gute Idee.

Brauche ich für Group Policy Analytics eine Microsoft-365-E3-Lizenz?

Microsoft 365 E3 reicht aus, weil dort Intune Plan 1 und Microsoft Entra ID P1 enthalten sind. Alternativ funktionieren Microsoft 365 E5, Microsoft 365 Business Premium oder ein eigenständiges Intune-Abonnement. Nur bestimmte Zusatzfunktionen wie Proactive Remediations auf Windows 11 Pro erfordern die Intune Suite oder ein Windows-Enterprise-E3-Add-on.

Wie erkenne ich, welche Policy tatsächlich auf dem Gerät gewinnt?

Führen Sie MdmDiagnosticsTool.exe -out C:\Temp\MDMDiag auf dem Client aus und öffnen Sie den erzeugten MDMDiagReport.html. Der Abschnitt „Blocked Group Policies" listet exakt auf, welche GPO durch welche Intune-CSP-Einstellung blockiert wird. Ergänzend zeigt gpresult /h die GPO-Seite und der Registry-Pfad HKLM\SOFTWARE\Microsoft\PolicyManager\current\device alle angewendeten CSP-Werte.

Was ist der Unterschied zwischen Settings Catalog und Administrative Templates in Intune?

Administrative Templates sind der ältere, ADMX-basierte Weg mit begrenztem Umfang (überwiegend Office und Edge). Der Settings Catalog ist der moderne, deutlich umfangreichere Ansatz. Er deckt praktisch alle Policy-CSPs ab, hat bessere Suche, sauberere Berichte und ist der von Microsoft empfohlene Standard für neue Profile. Für Neumigrationen sollten Sie ausschließlich den Settings Catalog verwenden.

Kann ich einen Migrationsschritt rückgängig machen, wenn etwas schiefgeht?

Ja. Entfernen Sie die Zuweisung des Settings-Catalog-Profils von der betroffenen Gruppe und erzwingen Sie auf den Clients einen MDM-Sync. Innerhalb von 8 Stunden fällt die Einstellung auf den GPO-Wert zurück (oder auf den Windows-Standard, wenn keine GPO existiert). Für schnellere Rollbacks können Sie parallel ein „Reset"-Profil pflegen, das die problematische Einstellung explizit auf Not configured setzt.