Migration von Group Policy Objects (GPO) zu Microsoft Intune

Migrationsleitfaden für 2nd-Level-IT-Admins im MSP-Kontext

Version: 1.0 | Datum: Juli 2026 | Zielgruppe: 2nd-Level-IT, MSP

Executive Summary

Die Migration von GPOs zu Microsoft Intune ersetzt die OU-basierte, domänenzentrische Geräteverwaltung durch cloudbasiertes MDM und ermöglicht die Verwaltung auch ohne VPN und DC-Erreichbarkeit. Das Kernwerkzeug ist Group Policy Analytics im Intune Admin Center, das GPO-Backups importiert und bewertet, welcher Prozentsatz der Einstellungen direkt in den Settings Catalog migriert werden kann. Der größte Einzelrisikofaktor ist die falsche Deployment-Reihenfolge: Wird Conditional Access vor der Compliance Policy mit Grace Period aktiviert, werden sofort alle Geräte ausgesperrt. Geräte, die nicht enrolled sind (On-Prem-only, Server, Air-gapped), empfangen niemals Intune-Policies und müssen dauerhaft per GPO verwaltet bleiben; ein vollständiges Geräteinventar vor Projektstart ist daher keine Option, sondern Pflicht. Der Nutzen nach erfolgreicher Migration: zentrale Sichtbarkeit aller Endpunkte, Conditional Access auf Basis echter Compliance-Daten, und ein Geräteverwaltungsmodell das keinen lokalen Domänencontroller mehr voraussetzt.

1. Voraussetzungen & Entscheidungsgrundlagen

1.1 Lizenzvoraussetzungen

Lizenzcheck vor Projektstart:

Connect-MgGraph -Scopes "Organization.Read.All", "Directory.Read.All"
$subscribedSkus = Get-MgSubscribedSku
$intuneSkus = $subscribedSkus | Where-Object { $_.ServicePlans.ServicePlanName -like "*INTUNE*" }
$intuneSkus | Select-Object SkuPartNumber,
    @{N='Lizenzen-Gesamt'; E={$_.PrepaidUnits.Enabled}},
    @{N='Lizenzen-Genutzt'; E={$_.ConsumedUnits}}

1.2 Gerätestatus (Hybrid-Join vs. Entra-Join)

Drei Geräteklassen im MSP-Alltag:

Geräteinventar erstellen (Pflichtschritt vor Projektstart):

# AD-Inventar
Import-Module ActiveDirectory
Get-ADComputer -Filter * -Properties Name, OperatingSystem, OperatingSystemVersion, LastLogonDate |
    Select-Object Name, OperatingSystem, OperatingSystemVersion,
        @{N='LastLogon'; E={[DateTime]::FromFileTime($_.LastLogonTimeStamp)}} |
    Export-Csv -Path "C:\Migration\Inventar_AD_Computer.csv" -NoTypeInformation -Encoding UTF8

# Entra-ID-Inventar (Join-Status)
Connect-MgGraph -Scopes "Device.Read.All"
Get-MgDevice -All | Select-Object DisplayName, TrustType, OperatingSystem, OperatingSystemVersion |
    Export-Csv -Path "C:\Migration\Inventar_Entra_Devices.csv" -NoTypeInformation -Encoding UTF8

# Join-Status auf dem einzelnen Gerät prüfen
dsregcmd /status | Select-String "AzureAdJoined|DomainJoined|EnterpriseJoined"

Auswertungsschlüssel:
- TrustType = ServerAd → Hybrid Joined (GPO + Intune gleichzeitig, hohes Konfliktpotenzial)
- TrustType = AzureAd → Entra Joined (nur Intune)
- Nur in AD vorhanden, nicht in Entra → On-Prem-only (bleibt per GPO verwaltet)

1.3 Co-Management-Überlegungen

Wenn Configuration Manager (MECM/SCCM) im Einsatz ist:

Bei Co-Management steuern Workload-Schieberegler, welches System (MECM oder Intune) für welchen Bereich zuständig ist. Relevante Workloads für die GPO-Migration:

Grundregel für Workload-Switching: Erst vollständig in Intune konfigurieren, dann Workload umschalten — niemals umgekehrt. Beim Workload-Switch bleiben MECM-Konfigurationen auf den Geräten, bis Intune-Policies greifen — das schützt während der Transition.

Pilot-Approach: Workload-Switch zuerst auf eine MECM-Collection mit 20–30 Testgeräten anwenden, bevor der breite Rollout erfolgt.

2. Microsoft-Tools für die Migration

2.1 Group Policy Analytics

Was ist das Tool?
Group Policy Analytics ist ein Tool im Intune Admin Center, das importierte GPO-XML-Backups analysiert und bewertet, welcher Prozentsatz der Einstellungen durch Intune (MDM) abgedeckt werden kann. Es erlaubt außerdem die direkte Migration eines analysierten GPOs in ein Settings-Catalog-Profil.

Quelle: https://learn.microsoft.com/en-us/intune/device-configuration/import-group-policy-analytics

Vorbereitung: GPOs als XML exportieren (auf dem GPMC-Server):

Import-Module GroupPolicy

# XML-Reports erzeugen (werden für den Import in Group Policy Analytics benötigt)
$XmlPath = "C:\Migration\GPO_XML"
New-Item -ItemType Directory -Path $XmlPath -Force | Out-Null

Get-GPO -All | ForEach-Object {
    $safeName = $_.DisplayName -replace '[\\/:*?"<>|]', '_'
    Get-GPOReport -Guid $_.Id -ReportType Xml -Path "$XmlPath\$safeName.xml"
    Write-Host "XML exportiert: $($_.DisplayName)"
}

# Vollständige GPO-Backups für Rollback (separat von XML-Reports)
$BackupPath = "C:\Migration\GPO_Backups"
New-Item -ItemType Directory -Path $BackupPath -Force | Out-Null
Get-GPO -All | ForEach-Object {
    Backup-GPO -Guid $_.Id -Path $BackupPath
    Write-Host "Backup erstellt: $($_.DisplayName)"
}

Wichtig: Die XML-Reports (aus Get-GPOReport -ReportType Xml) sind nicht identisch mit den Backup-Ordnern aus Backup-GPO. Für Group Policy Analytics werden die XML-Reports benötigt. Maximale Dateigröße pro XML: 4 MB.

Import in Intune (manuell im Admin Center):
1. Intune Admin Center (intune.microsoft.com) → "Devices" → "Manage devices" → "Group Policy analytics"
2. "Import" → XML-Dateien auswählen (Mehrfachauswahl möglich)
3. Scope Tags vergeben → "Next" → "Create"
4. Analyseergebnisse erscheinen nach ca. 20 Minuten

Ergebnisse per Graph API abrufen:

Connect-MgGraph -Scopes "DeviceManagementConfiguration.Read.All"

$uri = "https://graph.microsoft.com/beta/deviceManagement/groupPolicyMigrationReports"
$reports = Invoke-MgGraphRequest -Method GET -Uri $uri

$reports.value | Select-Object displayName, migrationReadiness, totalSettingsCount,
    supportedSettingsCount, unsupportedSettingsCount |
    Export-Csv -Path "C:\Migration\GP_Analytics_Ergebnis.csv" -NoTypeInformation -Encoding UTF8

# MDM-Kompatibilitätsprozentsatz ausgeben
$reports.value | ForEach-Object {
    $pct = if ($_.totalSettingsCount -gt 0) {
        [math]::Round(($_.supportedSettingsCount / $_.totalSettingsCount) * 100, 1)
    } else { 0 }
    Write-Host "$($_.displayName): $pct% MDM-kompatibel ($($_.unsupportedSettingsCount) nicht migrierbar)"
}

Interpretation der Ergebnisse:

Bekannte Einschränkung: Non-ADMX-Einstellungen werden nur in englischer Sprache korrekt analysiert. GPOs mit Einstellungen in anderen Sprachen liefern ungenaue MDM-Support-Prozentangaben. Empfehlung: GPMC immer auf einem englischsprachigen Windows betreiben.

Direkte Migration im Admin Center:
- GPO in der Liste auswählen → "Migrate" → Neue Settings-Catalog-Richtlinie wird automatisch erstellt
- Einschränkungen: AppLocker- und Firewall-Einstellungen sind im Migrate-Dialog ausgegraut und müssen manuell über Endpoint Security konfiguriert werden.

2.2 Settings Catalog

Was ist der Settings Catalog?
Der Settings Catalog ist die zentrale Konfigurationsoberfläche in Intune. Er listet tausende Einstellungen aus Windows Configuration Service Providers (CSPs), kategorisiert und durchsuchbar. Er ist der offizielle Nachfolger des älteren "Administrative Templates"-Profiltyps, der von Microsoft nicht mehr für neue Richtlinien freigegeben wird.

Quelle: https://learn.microsoft.com/en-us/intune/intune-service/configuration/settings-catalog

Profil erstellen:
1. Intune Admin Center → "Devices" → "Manage devices" → "Configuration" → "Create" → "New policy"
2. Plattform: "Windows 10 and later", Profiltyp: "Settings Catalog"
3. In "Configuration settings" → "Add settings" → Suche nach Kategorie oder Schlüsselwort

GPO-Äquivalente im Settings Catalog finden:
- Der CSP-Name und die OMA-URI-Pfade aus Group Policy Analytics (z.B. ./Device/Vendor/MSFT/BitLocker/RequireDeviceEncryption) sind direkte Suchbegriffe im Settings Catalog.
- Scope beachten: Device-Scope-Einstellungen schreiben in HKLM, User-Scope in HKCU — entspricht der Unterscheidung Computer Configuration / User Configuration in GPOs.

Unterschied Administrative Templates (Legacy) vs. Settings Catalog:

Wichtiger Hinweis zum Loopback-Verhalten: Wenn eine User-Scope-Einstellung im Settings Catalog einer Gerätegruppe (statt einer Benutzergruppe) zugewiesen wird, wirkt sie auf alle Benutzer dieses Geräts. Das entspricht funktional dem GPO-Loopback-Merge-Modus — es ist jedoch kein konfigurierbarer Modus, sondern das Standardverhalten.

2.3 ADMX-Ingestion

Wann ist ADMX-Ingestion nötig?
Nur wenn eine Anwendung oder ein Dienst eigene ADMX-Richtlinien mitbringt, die nicht nativ im Settings Catalog enthalten sind. Wichtig: Viele gängige ADMX-Einstellungen (Microsoft Edge, Google Chrome, Windows-interne Settings) sind bereits eingebaut und erfordern keine separate Ingestion.

Quelle: https://learn.microsoft.com/en-us/intune/device-configuration/settings-catalog/import-custom-admx-templates

Variante A — Import über Intune-Portal (empfohlen):

Pfad: Intune Admin Center → "Devices" → "Configuration" → Tab "Import ADMX" → "Import"

1. ADMX-Datei hochladen
2. Zugehörige ADML-Datei hochladen (nur en-us unterstützt)
3. Review + Create
4. Nach Import: Profil erstellen unter "Templates" → "Imported Administrative templates (Preview)"

Grenzen: Max. 20 ADMX-Dateien, je max. 1 MB. Combo-Box-Einstellungstyp nicht unterstützt. Abhängigkeiten (z.B. firefox.admx benötigt zuerst mozilla.admx) müssen vorab importiert werden. Windows-eigene ADMX-Dateien aus C:\Windows\PolicyDefinitions nicht importieren — diese werden über CSPs konfiguriert.

Variante B — Policy CSP / Graph API (für Win32-App-Richtlinien):

# ADMX ingesten
./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/{AppName}/{SettingType}/{FileUid}

# Einstellung setzen
./Device/Vendor/MSFT/Policy/Config/{AppName}~{SettingType}~{CategoryPath}/{PolicyName}

Hinweis: Ingested Policies dürfen nur in bestimmte Registry-Bereiche schreiben. Schreibzugriff auf Software\Microsoft und Software\Policies\Microsoft ist generell gesperrt (mit explizit erlaubten Ausnahmen für Office, Edge, Internet Explorer, OneDrive, Visual Studio).

3. Migrationsplan

Gesamtübersicht

Gesamtdauer: 14–16 Wochen (bei ~100 Geräten; skalierbar)

Phase 1: Ist-Analyse & Vorbereitung (Woche 1–2)

1.1 Geräteinventar (siehe Abschnitt 1.2 — Befehle dort aufgeführt)

Ziel: Tabelle mit Spalten Gerätename | AD-Domäne | Hybrid-Join | Entra-Join | OS-Version | Letzter Login | Migrationskandidat

1.2 GPO-Bestandsaufnahme

Import-Module GroupPolicy

# GPO-Liste exportieren
Get-GPO -All | Select-Object DisplayName, GpoStatus, CreationTime, ModificationTime |
    Export-Csv -Path "C:\Migration\GPO_Bestand.csv" -NoTypeInformation -Encoding UTF8

# GPO-Links pro OU exportieren
Get-GPO -All | ForEach-Object {
    $gpo = $_
    [PSCustomObject]@{
        Name   = $gpo.DisplayName
        Status = $gpo.GpoStatus
        Links  = ((Get-GPOReport -Guid $gpo.Id -ReportType Xml) | Select-String 'SOMPath' | ForEach-Object { $_.Line.Trim() }) -join '; '
    }
} | Export-Csv -Path "C:\Migration\GPO_Links.csv" -NoTypeInformation -Encoding UTF8

Backup- und XML-Export: siehe Abschnitt 2.1.

1.3 Group Policy Analytics auswerten

Nach dem Import (Abschnitt 2.1) GPOs nach MDM-Support klassifizieren:
- > 80%: Direktmigration in Phase 2/3
- 50–80%: Mit Nacharbeit in Phase 2/3
- < 50%: Preferences-Migration als Sonderprojekt (parallel ab Phase 3, siehe Anhang A)
- "Not supported": Workaround-Tabelle in Abschnitt 5

1.4 Entra-Join-Readiness prüfen

# SCP (Service Connection Point) für Hybrid-Join prüfen
$scp = Get-ADObject -Filter {
    objectClass -eq 'serviceConnectionPoint' -and
    name -eq 'Windows Azure AD Automatic Device Registration'
} -Properties keywords
if ($scp) {
    Write-Host "SCP vorhanden — Hybrid-Join konfiguriert" -ForegroundColor Green
    $scp.keywords
} else {
    Write-Host "SCP NICHT vorhanden — Hybrid-Join nicht konfiguriert" -ForegroundColor Red
}

# AAD-Connect-Synchronisierung prüfen (auf dem AAD-Connect-Server)
Get-ADSyncScheduler | Select-Object SyncCycleEnabled, NextSyncCyclePolicyType, NextSyncCycleStartTimeInUTC

1.5 AAD-Gruppen-Konzept

Prinzip: Nicht die OU-Struktur kopieren, sondern Funktion abbilden.

Connect-MgGraph -Scopes "Group.ReadWrite.All"

# Dynamische Gruppe — Beispiel: alle Windows-11-Geräte
$dynamicGroupBody = @{
    displayName     = "GRP-Intune-Windows11-Alle"
    description     = "Alle Windows-11-Geräte — Intune-Migration"
    mailEnabled     = $false
    mailNickname    = "GRP-Intune-Win11-Alle"
    securityEnabled = $true
    groupTypes      = @("DynamicMembership")
    membershipRule  = '(device.operatingSystemVersion -startsWith "10.0.22") and (device.deviceOSType -eq "Windows")'
    membershipRuleProcessingState = "On"
}
New-MgGroup -BodyParameter $dynamicGroupBody

# Statische Pilot-Gruppe
$pilotGroupBody = @{
    displayName     = "GRP-Intune-Pilot-Geraete"
    description     = "Pilot-Gruppe: 15 Testgeräte"
    mailEnabled     = $false
    mailNickname    = "GRP-Intune-Pilot"
    securityEnabled = $true
}
$pilotGroup = New-MgGroup -BodyParameter $pilotGroupBody

# Geräte zur Pilot-Gruppe hinzufügen (IDs aus Inventar)
$deviceIds = @("device-object-id-1", "device-object-id-2")  # Aus Inventar befüllen
foreach ($id in $deviceIds) {
    New-MgGroupMember -GroupId $pilotGroup.Id -DirectoryObjectId $id
}

Empfohlene Gruppen-Taxonomie für MSPs:
- GRP-Intune-Pilot — 10–15 Testgeräte (manuell)
- GRP-Intune-Windows11-Alle — dynamisch, alle Win11-Geräte
- GRP-Intune-Abteilung-<Name> — dynamisch aus HR-Attribut Department
- GRP-Intune-Legacy-Ausnahmen — Geräte die dauerhaft per GPO verwaltet bleiben

1.6 Rollback-Strategie

# GPO-Backup wiederherstellen
$BackupPath = "C:\Migration\GPO_Backups"
$backups = Get-GPOBackup -Path $BackupPath
$backups | Select-Object DisplayName, Id, BackupId, Timestamp | Format-Table

# Einzelnes GPO wiederherstellen
Restore-GPO -BackupId "<BackupId-GUID>" -Path $BackupPath

# Alle GPOs aus Backup wiederherstellen (Notfall)
Restore-GPO -All -Path $BackupPath

Go/No-Go Phase 1:
- [ ] Geräteinventar vollständig: Hybrid/Entra/On-Prem-Verteilung bekannt
- [ ] Alle GPOs als XML exportiert und als Backup gesichert
- [ ] Group Policy Analytics abgeschlossen: MDM-Support-% für alle GPOs bekannt
- [ ] Entra ID und AAD Connect: Hybrid-Join funktionsfähig und synchronisierend
- [ ] Intune-Lizenzen vorhanden: Anzahl >= Anzahl zu migrierender Geräte
- [ ] Pilot-Gruppe in Entra ID angelegt und befüllt
- [ ] Rollback-Backup getestet (Test-Restore eines GPOs durchgeführt)

No-Go-Kriterien: Fehlende Intune-Lizenzen, AAD Connect nicht synchronisierend, kein GPO-Backup vorhanden.

Phase 2: Pilot (Woche 3–4)

Umfang: 10–20 Geräte, möglichst heterogen (verschiedene Abteilungen, OS-Versionen, Geräteklassen). Ideal: IT-Mitarbeiter und technikaffine Anwender.

KRITISCHE Reihenfolge — Abweichung führt zu Lockout

1. Security Baseline deployen + manuell synchen + 24h warten
2. Compliance Policy mit 14-tägiger Grace Period deployen
3. Conditional Access im Report-Only-Modus erstellen
4. Weitere Settings-Catalog-Policies deployen
5. [Erst nach 14 Tagen]: CA auf Enforcing umstellen

2.1 Security Baseline deployen

Connect-MgGraph -Scopes "DeviceManagementConfiguration.ReadWrite.All"

# Verfügbare Security Baseline Templates abrufen
$templates = Invoke-MgGraphRequest -Method GET `
    -Uri "https://graph.microsoft.com/beta/deviceManagement/templates?`$filter=templateType eq 'securityBaseline'"
$templates.value | Select-Object id, displayName | Format-Table

# Windows Security Baseline Profil erstellen
$baselineTemplateId = ($templates.value | Where-Object { $_.displayName -like "*Windows*Security*" }).id

$baseline = Invoke-MgGraphRequest -Method POST `
    -Uri "https://graph.microsoft.com/beta/deviceManagement/intents" `
    -Body (@{
        displayName = "SEC-Baseline-Windows-Pilot"
        description = "Windows Security Baseline — Pilot Phase"
        templateId  = $baselineTemplateId
        roleScopeTagIds = @()
    } | ConvertTo-Json -Depth 5)

# Pilot-Gruppe zuweisen
Invoke-MgGraphRequest -Method POST `
    -Uri "https://graph.microsoft.com/beta/deviceManagement/intents/$($baseline.id)/assign" `
    -Body (@{
        assignments = @(@{
            target = @{
                "@odata.type" = "#microsoft.graph.groupAssignmentTarget"
                groupId = "<Pilot-Gruppen-ID>"
            }
        })
    } | ConvertTo-Json -Depth 5)

Write-Host "Security Baseline deployed. Manuellen Sync auslösen und 24h warten."

2.2 Compliance Policy mit Grace Period

$compliance = Invoke-MgGraphRequest -Method POST `
    -Uri "https://graph.microsoft.com/beta/deviceManagement/deviceCompliancePolicies" `
    -Body (@{
        "@odata.type"            = "#microsoft.graph.windows10CompliancePolicy"
        displayName              = "COMP-Windows-Pilot"
        description              = "Compliance Policy Pilot — 14 Tage Grace Period"
        osMinimumVersion         = "10.0.19041"
        bitLockerEnabled         = $true
        secureBootEnabled        = $true
        activeFirewallRequired   = $true
        defenderEnabled          = $true
        scheduledActionsForRule  = @(@{
            ruleName = "PasswordRequired"
            scheduledActionConfigurations = @(@{
                actionType        = "block"
                gracePeriodHours  = 336  # 14 Tage
                notificationTemplateId = ""
            })
        })
    } | ConvertTo-Json -Depth 8)

# Pilot-Gruppe zuweisen
Invoke-MgGraphRequest -Method POST `
    -Uri "https://graph.microsoft.com/beta/deviceManagement/deviceCompliancePolicies/$($compliance.id)/assign" `
    -Body (@{
        assignments = @(@{
            target = @{
                "@odata.type" = "#microsoft.graph.groupAssignmentTarget"
                groupId = "<Pilot-Gruppen-ID>"
            }
        })
    } | ConvertTo-Json -Depth 5)

Write-Host "Compliance Policy erstellt: $($compliance.id)"

2.3 Conditional Access im Report-Only-Modus

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"

$ca = Invoke-MgGraphRequest -Method POST `
    -Uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" `
    -Body (@{
        displayName = "CA-Pilot-ComplianceRequired"
        state       = "enabledForReportingButNotEnforced"
        conditions  = @{
            users = @{ includeGroups = @("<Pilot-Gruppen-ID>") }
            applications = @{ includeApplications = @("All") }
            platforms = @{ includePlatforms = @("windows") }
        }
        grantControls = @{
            operator        = "OR"
            builtInControls = @("compliantDevice")
        }
    } | ConvertTo-Json -Depth 8)

Write-Host "CA-Policy im Report-Only-Modus erstellt: $($ca.id)"
Write-Host "WICHTIG: Diese ID für Phase 5 notieren. Erst nach 14 Tagen auf 'enabled' umstellen."

2.4 Side-by-Side-Validierung

# GPO-Ergebnis vor der Migration dokumentieren
gpresult /h "C:\Migration\gpresult_vorher.html" /f

# Manuellen Sync auslösen
Connect-MgGraph -Scopes "DeviceManagementManagedDevices.ReadWrite.All"
$deviceId = (Get-MgDevice -Filter "displayName eq '<Gerätename>'").Id
$managedDevice = Get-MgDeviceManagementManagedDevice -Filter "azureADDeviceId eq '$deviceId'"
Invoke-MgDeviceManagementManagedDeviceAction `
    -ManagedDeviceId $managedDevice.Id `
    -Action syncDevice

# Nach 15 Minuten: Policy-Status prüfen
$deviceConfig = Get-MgDeviceManagementManagedDeviceConfigurationState `
    -ManagedDeviceId $managedDevice.Id
$deviceConfig | Select-Object SettingName, State, ErrorCode | Format-Table

# MDMWinsOverGP-Diagnose auf dem Gerät (lokal ausführen):
# Einstellungen > Konten > Auf Geschäfts-/Schulkonto zugreifen > <Konto> > Info
# > Erweiterten Diagnosebericht erstellen
# Im HTML-Bericht nach "MDMWins" suchen

Validierungskriterien Pilot:
- Alle Pilot-Geräte: Compliance-Status "Compliant" in Intune
- CA (Report-Only): < 5% der Anmeldungen würden blockiert
- GPO-Einstellungen und Intune-Einstellungen zeigen konsistenten Wert auf dem Gerät
- Logon-Script-Ersatz läuft fehlerfrei
- Drucker und Netzlaufwerke erreichbar

Go/No-Go Phase 2:
- [ ] Alle 10–20 Pilot-Geräte enrolled und "Compliant"
- [ ] CA (Report-Only) zeigt < 5% potenzielle Blockierungen
- [ ] Security Baseline ohne Fehler-Status auf allen Pilot-Geräten
- [ ] Keine GPO/Intune-Konflikte (gpresult vs. Intune-Bericht konsistent)
- [ ] Benutzer-Feedback: keine Produktivitätseinschränkungen
- [ ] Logon-Script-Ersatz validiert

No-Go-Kriterien: > 10% Geräte mit Policy-Fehlern, Lockouts durch CA, Datenverlust durch Script-Migration.

Phase 3: Stufenweiser Rollout (Woche 5–10)

Rollout-Wellen:

Dauerhaft von Migration ausgenommene Geräte:
- Server (kein MDM-Enrollment vorgesehen)
- Air-gapped / keine Internetverbindung
- Windows < 10 / LTSC-Versionen ohne Intune-Support
- Produktionsmaschinen / Industrie-PCs

# Legacy-OU für dauerhaft ausgenommene Geräte anlegen
Import-Module ActiveDirectory
New-ADOrganizationalUnit -Name "Legacy-GPO-only" `
    -Path "OU=Computer,DC=contoso,DC=local" `
    -Description "Geräte die dauerhaft per GPO verwaltet bleiben"
Write-Host "Legacy-OU angelegt. Geräte manuell hineinverschieben."

3.1 MDMWinsOverGP aktivieren (für Hybrid-Joined Geräte)

Bei Hybrid-joined Geräten empfangen GPO und Intune Policies gleichzeitig. Für Policy-CSP-Einstellungen Intune-Vorrang konfigurieren:

Connect-MgGraph -Scopes "DeviceManagementConfiguration.ReadWrite.All"

$mdmWinsPolicy = Invoke-MgGraphRequest -Method POST `
    -Uri "https://graph.microsoft.com/beta/deviceManagement/deviceConfigurations" `
    -Body (@{
        "@odata.type" = "#microsoft.graph.windows10CustomConfiguration"
        displayName   = "CFG-MDMWinsOverGP"
        description   = "Intune-Richtlinien haben Vorrang vor GPO bei Policy-CSP-Einstellungen"
        omaSettings   = @(@{
            "@odata.type" = "#microsoft.graph.omaSettingInteger"
            displayName   = "MDMWinsOverGP"
            description   = "1 = MDM gewinnt über GPO bei Policy CSP Einstellungen"
            omaUri        = "./Device/Vendor/MSFT/Policy/Config/ControlPolicyConflict/MDMWinsOverGP"
            value         = 1
        })
    } | ConvertTo-Json -Depth 6)

Write-Host "MDMWinsOverGP Policy erstellt: $($mdmWinsPolicy.id)"
Write-Host "HINWEIS: Gilt NUR für Policy CSP. BitLocker CSP, Firewall CSP etc. sind NICHT abgedeckt."

Quelle: https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-controlpolicyconflict
Einschränkung: MDMWinsOverGP wirkt nur auf Einstellungen im Policy CSP. Andere CSPs (BitLocker, Firewall, Defender) werden nicht abgedeckt — dort können Race Conditions entstehen wenn dieselbe Einstellung in GPO und Intune konfiguriert ist. Als Gegenmaßnahme: GPO-Einstellungen für diese Bereiche auf "Not Configured" setzen sobald Intune-Äquivalent greift.

3.2 Monitoring während des Rollouts

Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All", "DeviceManagementConfiguration.Read.All"

$devices = Get-MgDeviceManagementManagedDevice -All
$total = $devices.Count
$compliant = ($devices | Where-Object { $_.ComplianceState -eq "compliant" }).Count
$complianceRate = [math]::Round(($compliant / $total) * 100, 1)

Write-Host "Compliance-Rate: $complianceRate% ($compliant / $total Geräte)"

# Geräte mit Fehlern identifizieren
$errorDevices = $devices | Where-Object { $_.ComplianceState -eq "noncompliant" }
$errorDevices | Select-Object DeviceName, ComplianceState, LastSyncDateTime |
    Export-Csv "C:\Migration\Monitoring_Fehler_$(Get-Date -Format 'yyyy-MM-dd').csv" `
    -NoTypeInformation -Encoding UTF8

Eskalationspfad:

Hinweis Check-in-Verzögerung: Intune-Policies greifen nicht sofort. Standard-Intervall: 8 Stunden. Nach Policy-Änderungen immer manuellen Sync auslösen und Kunden informieren: "Die Policy ist in Intune vorhanden — Wirkung kommt beim nächsten Check-in."

Go/No-Go je Rollout-Welle:
- [ ] Compliance-Rate > 90% nach jeder abgeschlossenen Welle
- [ ] Helpdesk-Tickets < 110% des normalen Volumens
- [ ] Keine ungeplanten Produktionsunterbrechungen
- [ ] On-Prem-Geräte ohne Enrollment in Legacy-OU identifiziert

Phase 4: GPO-Deaktivierung (Woche 11–14)

Grundregel: GPO-Links erst deaktivieren wenn das Enrollment aller betroffenen Geräte in Intune bestätigt ist und Intune-Policies nachweislich greifen. Geräte ohne Enrollment empfangen nach GPO-Deaktivierung gar keine Richtlinien mehr.

4.1 GPO-Links deaktivieren (nicht löschen)

Import-Module GroupPolicy

$ou = "OU=Workstations,DC=contoso,DC=local"
$links = (Get-GPInheritance -Target $ou).GpoLinks

foreach ($link in $links) {
    $gpoName = (Get-GPO -Guid $link.GpoId).DisplayName
    Set-GPLink -Guid $link.GpoId -Target $ou -LinkEnabled No
    Write-Host "Deaktiviert: $gpoName an $ou"
}

# Status prüfen
Get-GPInheritance -Target $ou | Select-Object -ExpandProperty GpoLinks |
    Select-Object DisplayName, Enabled, Enforced

4.2 Beobachtungszeitraum (14 Tage täglich prüfen)

Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All"
$devices = Get-MgDeviceManagementManagedDevice -All
$nonCompliant = $devices | Where-Object { $_.ComplianceState -ne "compliant" }

if ($nonCompliant.Count -gt 0) {
    Write-Warning "WARNUNG: $($nonCompliant.Count) Geräte non-compliant nach GPO-Deaktivierung!"
    $nonCompliant | Select-Object DeviceName, ComplianceState, LastSyncDateTime | Format-Table
} else {
    Write-Host "OK: Alle Geräte compliant" -ForegroundColor Green
}

4.3 GPO-Links endgültig entfernen und GPOs archivieren

Erst nach 14-tägigem fehlerfreiem Beobachtungszeitraum:

# GPO-Links entfernen (GPO-Objekte bleiben erhalten)
$ou = "OU=Workstations,DC=contoso,DC=local"
foreach ($link in (Get-GPInheritance -Target $ou).GpoLinks) {
    $gpoName = (Get-GPO -Guid $link.GpoId).DisplayName
    Remove-GPLink -Guid $link.GpoId -Target $ou
    Write-Host "Link entfernt: $gpoName"
}

# GPO-Objekte in AD umbenennen (NICHT löschen — Backup bleibt als echte Fallback-Ebene)
Get-GPO -All | Where-Object { $_.DisplayName -notlike "[ARCHIV]*" } | ForEach-Object {
    $newName = "[ARCHIV] $($_.DisplayName)"
    Rename-GPO -Guid $_.Id -TargetName $newName
    Write-Host "Archiviert: $newName"
}

Go/No-Go Phase 4:
- [ ] Alle migrierten Geräte: Compliance-Status "Compliant" für 14 Tage stabil
- [ ] Kein Anstieg der Helpdesk-Tickets nach GPO-Deaktivierung
- [ ] Logon-Script-Ersatz läuft zuverlässig
- [ ] Drucker und Netzlaufwerke über Intune-Lösung erreichbar

No-Go-Kriterien: Compliance-Rate fällt unter 85%, kritische Produktivitätseinschränkungen.

Phase 5: Validierung & Abschluss (Woche 15–16)

5.1 Abschluss-Compliance-Report

Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All", "DeviceManagementConfiguration.Read.All"

$devices = Get-MgDeviceManagementManagedDevice -All
$total = $devices.Count
$compliant = ($devices | Where-Object ComplianceState -eq "compliant").Count
$nonCompliant = ($devices | Where-Object ComplianceState -eq "noncompliant").Count

Write-Host "=== Abschluss-Compliance-Report ==="
Write-Host "Gesamt:        $total"
Write-Host "Compliant:     $compliant ($([math]::Round($compliant/$total*100,1))%)"
Write-Host "Non-Compliant: $nonCompliant ($([math]::Round($nonCompliant/$total*100,1))%)"

$devices | Select-Object DeviceName, ComplianceState, OSVersion, EnrolledDateTime, LastSyncDateTime, UserDisplayName |
    Export-Csv "C:\Migration\Abschluss_Report_$(Get-Date -Format 'yyyy-MM-dd').csv" `
    -NoTypeInformation -Encoding UTF8

5.2 Microsoft Secure Score prüfen

Connect-MgGraph -Scopes "SecurityEvents.Read.All"
$secureScore = Invoke-MgGraphRequest -Method GET `
    -Uri "https://graph.microsoft.com/v1.0/security/secureScores?`$top=1"
$latest = $secureScore.value[0]
Write-Host "Secure Score: $($latest.currentScore) / $($latest.maxScore) ($([math]::Round($latest.currentScore / $latest.maxScore * 100, 1))%)"

5.3 CA von Report-Only auf Enforcing umstellen (nur bei > 95% Compliance-Rate)

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"
$caId = "<CA-Policy-ID-aus-Phase-2>"

Invoke-MgGraphRequest -Method PATCH `
    -Uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies/$caId" `
    -Body (@{ state = "enabled" } | ConvertTo-Json)

Write-Host "CA-Policy auf Enforcing umgestellt. Monitoring für 48h intensivieren."

Go/No-Go Phase 5:
- [ ] Compliance-Rate > 95% über alle verwalteten Geräte
- [ ] Microsoft Secure Score gleich oder höher als vor Migration
- [ ] CA auf Enforcing ohne neue Lockouts
- [ ] Abschlussdokumentation fertiggestellt
- [ ] Legacy-GPO-OU und Backup-Pfad dokumentiert
- [ ] Runbook für laufenden Betrieb (neue Geräte, neue Policies) erstellt

4. Fallstricke & Gegenmaßnahmen

Priorisiert nach Risiko (Hoch zuerst):

5. Einstellungen ohne direktes Intune-Äquivalent

6. Abschluss-Checkliste

Phase 1 — Vorbereitung

• [ ] Geräteinventar erstellt: Hybrid-Join / Entra-Join / On-Prem-only-Verteilung dokumentiert
• [ ] Alle GPOs als XML-Report exportiert (für Group Policy Analytics)
• [ ] Alle GPOs als Backup-Ordner gesichert (für Rollback) und Restore getestet
• [ ] Group Policy Analytics Import durchgeführt, Migration Readiness Report ausgewertet
• [ ] GPOs nach MDM-Support klassifiziert (> 80% / 50–80% / < 50% / Not Supported)
• [ ] Entra-Join-Readiness bestätigt: SCP vorhanden, AAD Connect synchronisiert
• [ ] Intune-Lizenzen vorhanden: Anzahl >= Anzahl zu migrierender Geräte
• [ ] Entra-P1-Lizenzen vorhanden (für dynamische Gruppen und CA)
• [ ] AAD-Gruppen-Konzept erstellt: Pilot, Rollout-Wellen, Legacy-Ausnahmen
• [ ] Pilot-Gruppe befüllt (10–20 Geräte)
• [ ] Legacy-OU für dauerhaft ausgenommene Geräte angelegt

Phase 2 — Pilot

• [ ] Security Baseline deployt (ZUERST) und nach manuellem Sync auf allen Pilot-Geräten ohne Fehler
• [ ] Compliance Policy mit 14-tägiger Grace Period erstellt und der Pilot-Gruppe zugewiesen
• [ ] Conditional Access im Report-Only-Modus erstellt (NICHT Enforcing)
• [ ] CA-Policy-ID notiert (wird in Phase 5 benötigt)
• [ ] GPO-Einstellungen als Settings-Catalog-Profile migriert (via "Migrate"-Button oder manuell)
• [ ] Side-by-Side-Validierung abgeschlossen: gpresult vs. Intune-Bericht konsistent
• [ ] Logon-Script-Ersatz (PowerShell) getestet und validiert
• [ ] Go/No-Go Phase 2 abgenommen

Phase 3 — Rollout

• [ ] MDMWinsOverGP-Policy erstellt und allen Hybrid-Joined-Geräten zugewiesen
• [ ] Rollout-Welle 1 abgeschlossen, Compliance-Rate > 90%
• [ ] Rollout-Welle 2 abgeschlossen, Compliance-Rate > 90%
• [ ] Rollout-Welle 3 abgeschlossen, Compliance-Rate > 90%
• [ ] Preferences-Migration parallel gestartet: Drucker (Universal Print), Laufwerke (SharePoint/OneDrive)
• [ ] Monitoring-Dashboard aufgesetzt (täglicher Compliance-Report)
• [ ] Auf Hybrid-Geräten: GPO-Einstellungen die per Intune abgedeckt sind auf "Not Configured" gesetzt

Phase 4 — GPO-Deaktivierung

• [ ] Enrollment aller Geräte in Intune bestätigt bevor GPO-Link deaktiviert wird
• [ ] GPO-Links deaktiviert (Set-GPLink -LinkEnabled No), nicht gelöscht
• [ ] 14-tägiger Beobachtungszeitraum ohne Compliance-Einbruch und ohne Helpdesk-Eskalation
• [ ] GPO-Links entfernt (Remove-GPLink)
• [ ] GPO-Objekte in AD mit [ARCHIV]-Präfix umbenannt, nicht gelöscht

Phase 5 — Abschluss

• [ ] Abschluss-Compliance-Report: Rate > 95%
• [ ] Microsoft Secure Score gleich oder höher als vor Migration
• [ ] CA auf Enforcing umgestellt (nur bei > 95% Compliance-Rate und nach Rücksprache mit Stakeholdern)
• [ ] CA-Aktivierung 48h intensiv überwacht — kein neuer Lockout
• [ ] Abschlussdokumentation fertiggestellt (migrierte GPOs, Legacy-Geräte, offene Punkte)
• [ ] Runbook für laufenden Betrieb erstellt: neue Geräte onboarden, neue Policies deployen
• [ ] Backup-Pfad und archivierte GPO-Objekte dokumentiert

Quellenverzeichnis

Anhang A: Preferences-Migration (Sonderprojekt, parallel ab Phase 3)

Die Migration von GPO Preferences ist ein eigenständiges Langzeitprojekt, das parallel zum Hauptrollout ab Phase 3 läuft. Es darf nicht auf dem kritischen Pfad des Hauptprojekts liegen.

Anhang B: Rollback-Schnellreferenz

Anhang C: Benötigte Graph-API-Berechtigungen

Fußnoten zu aufgelösten Widersprüchen zwischen Agents

[1] Dual-Management-Dauer: Agent 2 nennt "4–8 Wochen", Agent 3 empfiehlt phasenbasiert 14 Tage Beobachtungszeitraum nach GPO-Deaktivierung. Im Leitfaden wurde die Aussage von Agent 2 als übergeordnetes Prinzip beibehalten (Dual-Management-Phase = Phase 3, Woche 5–10), während der 14-tägige Beobachtungszeitraum von Agent 3 als separate Kontrollschritt nach der eigentlichen Deaktivierung (Phase 4) integriert wurde. Beide Aussagen sind komplementär, nicht widersprüchlich.

[2] MDMWinsOverGP-Einschränkung: Agent 2 schreibt vereinfachend "MDM (Intune) gewinnt über GPO bei CSP-Einstellungen". Agent 1 (Research) präzisiert: MDMWinsOverGP gilt ausschließlich für den Policy CSP — andere CSPs (BitLocker, Firewall, Defender) sind nicht abgedeckt. Die präzisere Formulierung aus Agent 1 wurde übernommen und an allen relevanten Stellen mit Warnhinweisen versehen.

[3] CA-Aktivierungsschwelle: Agent 3 nennt "> 95% Compliance-Rate" als Voraussetzung für CA-Enforcing, Agent 2 nennt "2 Wochen". Im Leitfaden wurden beide Kriterien als UND-Bedingung formuliert: mindestens 14 Tage Wartezeit UND > 95% Compliance-Rate. Das ist die konservativere und damit für MSP-Kunden sicherere Vorgabe.

Erstellt von Agent 4 – Orchestrator & Report | 2026-07-07
Grundlage: Agent 1 (Microsoft-Doku), Agent 2 (Praxis & Fallstricke), Agent 3 (Migrationsplan)