Sektion 14: MDM Bridge: Von Legacy zu Modern Management

Warning: Unknown toolsets: messaging
# ## Einführung: Die Realität hybrider Umgebungen

Die meisten Enterprise-Umgebungen existieren nicht in einem sauberen Greenfield-Zustand. Sie sind gewachsene Organismen aus 15+ Jahren IT-Infrastruktur: Group Policy Objects, die seit Windows 7 unverändert sind, SCCM/ConfigMgr-Clients, die noch aus der Windows 10-Einführung stammen, und lokale Active Directory-Domänen, die als Single Source of Truth fungieren.

Die MDM Bridge in Microsoft Intune ist kein Migrationswerkzeug im klassischen Sinne. Sie ist eine **Koexistenz-Schicht**, die es ermöglicht, Modern Management schrittweise einzuführen, ohne bestehende Investitionen zu obsoletieren. Dieser Artikel behandelt die technische Architektur, Implementierungsmuster und Fallstricke der MDM Bridge aus der Perspektive eines Admins, der Production-Umgebungen mit 10.000+ Devices verwaltet.

—

## Technische Architektur der MDM Bridge

### Das Grundprinzip: Co-Management als Übergangszustand

Die MDM Bridge ermöglicht es, dass ein Device **gleichzeitig** von Configuration Manager (SCCM) und Microsoft Intune verwaltet wird. Dies ist kein Bug, sondern ein Feature. Die Architektur basiert auf einem klar definierten **Workload-Split**:

„`
┌─────────────────────────────────────────────────────────────────┐
│ Device (Windows 10/11) │
├─────────────────────────────────────────────────────────────────┤
│ Workload │ Management Authority │
│ ──────────────────────┼────────────────────────────────────── │
│ Windows Update │ Intune OR ConfigMgr (wahlweise) │
│ Office Updates │ Intune OR ConfigMgr │
│ Security Policies │ Intune (empfohlen) │
│ Compliance Policies │ Intune (exklusiv) │
│ Resource Policies │ ConfigMgr (legacy) │
│ Apps │ Split nach Typ │
│ Endpoint Protection │ Intune (Defender ATP Integration) │
└─────────────────────────────────────────────────────────────────┘
„`

### Der technische Mechanismus: Registrierung und Token-Flow

Wenn ein Device in Co-Management konfiguriert wird, passiert Folgendes im Hintergrund:

1. **MDM-Autorität wechseln**: Die MDM-Autorität wird von „None“ oder „ConfigMgr“ auf „Intune“ gesetzt. Dies erfolgt über einen WMI-Provider: `root\cimv2\mdm\dmmap`.

2. **Device-Registrierung**: Das Device registriert sich bei Intune über den **Device Enrollment Service (DES)**. Dabei wird ein Zertifikat ausgestellt, das für die authentifizierte Kommunikation verwendet wird.

3. **Token-Austausch**: ConfigMgr und Intune tauschen über die **Cloud Management Gateway (CMG)** Verbindung oder über **Direct Internet Communication** Tokens aus, um Workload-Zuordnungen zu synchronisieren.

4. **Policy-Auflösung**: Bei konfliktären Policies gilt die **Intune-Policy** als prävalent, da MDM-Befehle auf Protokollebene (OMA-DM) höher priorisiert werden als Group Policy.

### Die WMI-Schicht: Programmatischer Zugriff

Für Automatisierungsszenarien ist der Zugriff über WMI essenziell. Hier ein reales Beispiel aus einer Production-Umgebung:

„`powershell
# MDM-Autorität abfragen
$mdmAuthority = Get-WmiObject -Namespace root\cimv2\mdm\dmmap -Class MDM_DevDetail_Ext01 -Filter „InstanceID=’Ext‘ AND ParentID=‘./DevDetail'“
$mdmAuthority.MDMVendorID # Erwartet: „Microsoft“

# Co-Management Status prüfen
$coMgmtStatus = Get-WmiObject -Namespace root\ccm\clientSDK -Class CCM_CoManagementState
$coMgmtStatus.CoManagementState # 0=Not enabled, 1=Enabled, 2=Error

# Workload-Details abrufen
$workloads = Get-WmiObject -Namespace root\ccm\clientSDK -Class CCM_CoManagementPolicy
$workloads | Select-Object PolicyName, ManagementAuthority
„`

Dieser Zugriff ist kritisch für **Pre-Flight-Checks** vor der Migration und für **Post-Deployment-Validation**.

—

## Implementierungsmuster in der Praxis

### Pattern 1: Phasenweise Migration (Empfohlen für Enterprise)

**Szenario**: 12.000 Devices, davon 8.000 Windows 10, 4.000 Windows 11. Bestehende SCCM-Infrastruktur mit 200+ Applications.

**Phase 1: Pilot (Woche 1-4)**
– 50 IT-Pro-Devices als Canary-Gruppe
– Workloads: Compliance Policies + Windows Update for Business
– Monitoring über Intune Device Compliance + ConfigMgr Dashboard
– **Exit-Kriterium**: < 2% Error-Rate bei Policy-Application **Phase 2: Early Adopters (Woche 5-12)** - 500 Devices aus verschiedenen Abteilungen - Zusätzliche Workloads: Security Policies, Office Updates - App-Migration beginnt (MSI → Win32/Intune) - **Exit-Kriterium**: 95% Compliance-Rate über 14 Tage **Phase 3: General Availability (Woche 13-24)** - Batch-Migration in Wellen von 1.000 Devices - Vollständige Workload-Übernahme durch Intune - ConfigMgr wird zum **Legacy-Fallback** (nur noch Reporting) **Phase 4: Decommission (Woche 25+)** - ConfigMgr-Client Deinstallation über Intune Win32 App - MDM-Autorität auf "Intune" gesetzt (kein Co-Management mehr) ### Pattern 2: Greenfield mit Legacy-Anker **Szenario**: Neue Company-Acquisition mit 2.000 Devices, bestehende Intune-Umgebung soll übernommen werden, aber lokale GPOs müssen temporär bleiben. ```powershell # GPOs identifizieren, die mit MDM kollidieren $gpoReport = Get-GPOReport -All -ReportType Xml -Path "C:\GPOReport.xml" [xml]$gpoXml = Get-Content "C:\GPOReport.xml" # MDM-konfliktäre Settings extrahieren $conflicts = $gpoXml.SelectNodes("//Extension[@name='Group Policy']") | Where-Object { $_.Name -match "Password|Lockout|Firewall|BitLocker" } # Diese GPOs in "Audit Mode" setzen (nicht entfernen, nur loggen) $conflicts | ForEach-Object { Set-GPLink -Guid $_.Id -Target "ou=Legacy,dc=company,dc=local" -LinkEnabled No } ``` Dieses Pattern erlaubt es, **GPOs schrittweise zu dekommissionieren**, ohne die Security-Posture zu gefährden. --- ## Real-World Example: Windows Update Migration ### Ausgangszustand (ConfigMgr) ``` - WSUS-Server: 2x (Primary + Replica) - Update Groups: 15 (nach Abteilung) - Deployment Rings: 4 (Test, Pilot, Broad, Critical) - Maintenance Windows: 200+ Collections - Komplexität: Hoch (manuelle Approval pro Group) ``` ### Zielzustand (Intune + WUfB) ``` - Update Rings: 3 (Fast, Broad, Critical) - Quality Updates: Automatisch über Intune - Feature Updates: Über Windows Update for Business Policies - Active Hours: User-configured (8:00-18:00 Default) - Komplexität: Niedrig (Policy-basiert) ``` ### Migrationsschritte **Schritt 1: Parallel-Betrieb konfigurieren** Im ConfigMgr Console: ``` Administration > Cloud Services > Co-management > Co-management Settings
→ Create Configuration
→ Workloads: „Windows Update Policies“ auf Intune setzen
→ Pilot-Collection: „COG-WindowsUpdate-Pilot“ (50 Devices)
„`

**Schritt 2: Intune Update Rings erstellen**

„`json
{
„displayName“: „WinUfB – Broad Ring“,
„description“: „Standard ring for 80% of devices“,
„qualityUpdatesPauseStartDate“: null,
„featureUpdatesPauseStartDate“: null,
„qualityUpdatesPauseExpiryDate“: null,
„featureUpdatesPauseExpiryDate“: null,
„qualityUpdatesPauseInDays“: 0,
„featureUpdatesPauseInDays“: 0,
„qualityUpdatesDeferralInDays“: 3,
„featureUpdatesDeferralInDays“: 30,
„qualityUpdatesActiveHoursStart“: 8,
„qualityUpdatesActiveHoursEnd“: 18,
„featureUpdatesActiveHoursStart“: 8,
„featureUpdatesActiveHoursEnd“: 18,
„qualityUpdatesWeeksUntilForcedReboot“: 2,
„featureUpdatesWeeksUntilForcedReboot“: 2,
„qualityUpdatesScheduleRestartWarning“: 24,
„featureUpdatesScheduleRestartWarning“: 24,
„qualityUpdatesDisablePausedUpdateState“: false,
„featureUpdatesDisablePausedUpdateState“: false,
„qualityUpdatesAutoRestartNotification“: true,
„featureUpdatesAutoRestartNotification“: true,
„qualityUpdatesAutoRebootNotification“: true,
„featureUpdatesAutoRebootNotification“: true,
„qualityUpdatesRebootWarning“: 4,
„featureUpdatesRebootWarning“: 4,
„qualityUpdatesRebootReminder“: 2,
„featureUpdatesRebootReminder“: 2,
„qualityUpdatesRebootDelay“: 2,
„featureUpdatesRebootDelay“: 2,
„qualityUpdatesRebootReminderOffset“: 1,
„featureUpdatesRebootReminderOffset“: 1,
„qualityUpdatesRebootWarningOffset“: 2,
„featureUpdatesRebootWarningOffset“: 2,
„qualityUpdatesRebootDelayOffset“: 1,
„featureUpdatesRebootDelayOffset“: 1,
„qualityUpdatesRebootReminderOffsetInHours“: 24,
„featureUpdatesRebootReminderOffsetInHours“: 24,
„qualityUpdatesRebootWarningOffsetInHours“: 48,
„featureUpdatesRebootWarningOffsetInHours“: 48,
„qualityUpdatesRebootDelayOffsetInHours“: 24,
„featureUpdatesRebootDelayOffsetInHours“: 24,
„qualityUpdatesRebootReminderOffsetInMinutes“: 1440,
„featureUpdatesRebootReminderOffsetInMinutes“: 1440,
„qualityUpdatesRebootWarningOffsetInMinutes“: 2880,
„featureUpdatesRebootWarningOffsetInMinutes“: 2880,
„qualityUpdatesRebootDelayOffsetInMinutes“: 1440,
„featureUpdatesRebootDelayOffsetInMinutes“: 1440
}
„`

**Schritt 3: Monitoring und Fallback**

„`powershell
# Co-Management Status aller Devices exportieren
$devices = Get-CMDevice -CollectionName „All Systems“
$report = $devices | ForEach-Object {
$coMgmt = Get-WmiObject -Namespace root\ccm\clientSDK -Class CCM_CoManagementState -ComputerName $_.Name -ErrorAction SilentlyContinue
[PSCustomObject]@{
DeviceName = $_.Name
CoMgmtState = $coMgmt.CoManagementState
UpdateWorkload = $coMgmt.UpdateWorkload # 0=ConfigMgr, 1=Intune
LastSync = $coMgmt.LastPolicySync
}
}
$report | Export-Csv „C:\CoMgmt-WindowsUpdate-Report.csv“ -NoTypeInformation
„`

**Ergebnis nach 90 Tagen**:
– 94% der Devices erfolgreich auf Intune Windows Update migriert
– 6% Fallback auf ConfigMgr (hauptsächlich ältere Hardware mit TPM 1.2)
– Reduktion der Update-Zyklen von 21 Tagen auf 7 Tage
– Admin-Overhead reduziert von 8h/Woche auf 2h/Woche

—

## Kritische Fallstricke und Lösungen

### Problem 1: Policy-Konflikte zwischen GPO und MDM

**Symptom**: Devices zeigen „Error 0x87D1FDE8 – Retryable Error“ in Intune.

**Ursache**: Eine lokale GPO (z.B. „Password Length“) kollidiert mit einer Intune Compliance Policy.

**Lösung**:
„`powershell
# Konfliktäre GPOs identifizieren
$gpoConflicts = Get-GPO -All | ForEach-Object {
$report = Get-GPOReport -Guid $_.Id -ReportType Xml
[xml]$xml = $report
$settings = $xml.SelectNodes(„//Name[text()=’Password‘ or text()=’Lockout‘]“)
if ($settings) {
[PSCustomObject]@{
GPOName = $_.DisplayName
ConflictingSettings = $settings.Count
}
}
}

# GPOs auf „Not Configured“ setzen (nicht löschen!)
$gpoConflicts | ForEach-Object {
Set-GPRegistryValue -Name $_.GPOName -Key „HKLM\SOFTWARE\Policies\Microsoft\Windows“ -ValueName „Placeholder“ -Type String -Value „Migrated to Intune“
}
„`

**Best Practice**: GPOs niemals löschen, sondern auf „Not Configured“ setzen und in eine OU „Legacy-Migrated“ verschieben. Das erlaubt Rollback innerhalb von 24h via GPO-Link-Reenable.

### Problem 2: ConfigMgr Client bleibt nach Migration aktiv

**Symptom**: Device ist in Intune registriert, aber ConfigMgr Client sendet weiterhin Heartbeats.

**Ursache**: Co-Management wurde nicht sauber beendet; MDM-Autorität steht noch auf „Co-Management“.

**Lösung**:
„`powershell
# MDM-Autorität auf Intune setzen (kein Co-Management mehr)
$mdmAuthority = Get-WmiObject -Namespace root\cimv2\mdm\dmmap -Class MDM_DevDetail_Ext01 -Filter „InstanceID=’Ext‘ AND ParentID=‘./DevDetail'“
$mdmAuthority.MDMVendorID = „Microsoft“
$mdmAuthority.Put()

# ConfigMgr Client deinstallieren
$ccmSetup = [WMIClass]“\\localhost\root\ccm:CCMSetup“
$ccmSetup.Uninstall()

# Validation
$coMgmt = Get-WmiObject -Namespace root\ccm\clientSDK -Class CCM_CoManagementState
if ($coMgmt.CoManagementState -eq 0) {
Write-Host „Co-Management erfolgreich beendet“ -ForegroundColor Green
}
„`

### Problem 3: Win32 Apps funktionieren nicht im Co-Management

**Symptom**: Intune Win32 Apps werden nicht installiert, obwohl Device compliant ist.

**Ursache**: ConfigMgr Client blockiert die Intune Management Extension (IME).

**Lösung**:
„`powershell
# IME Service neu starten
Restart-Service -Name „IntuneManagementExtension“ -Force

# IME Log prüfen (häufigste Fehlerquelle)
$imeLog = „C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log“
Get-Content $imeLog -Tail 100 | Select-String „Error|Failed“

# ConfigMgr Client temporär stoppen (wenn IME blockiert wird)
Stop-Service -Name „CcmExec“ -Force
Start-Service -Name „IntuneManagementExtension“
Start-Service -Name „CcmExec“
„`

—

## Performance-Metriken und Success-KPIs

Für eine erfolgreiche MDM Bridge-Migration sollten folgende Metriken überwacht werden:

| Metrik | Target | Critical Threshold | Messung |
|——–|——–|——————-|———|
| Policy Application Time | < 15 Min | > 60 Min | Intune Device Configuration > Device Status |
| Compliance Rate | > 95% | < 85% | Intune Devices > Monitor > Compliance |
| Co-Management Error Rate | < 2% | > 5% | ConfigMgr Dashboard > Co-management |
| Win32 App Success Rate | > 90% | < 80% | Intune Apps > Win32 > Install Status |
| User Disruption Incidents | 0 | > 3 pro Woche | Service Desk Tickets |

—

## Zusammenfassung

Die MDM Bridge ist kein technisches Feature, sondern ein **strategisches Werkzeug** für Enterprise-Migrationen. Sie ermöglicht:

1. **Risikominimierung**: Durch schrittweise Migration in kontrollierten Wellen
2. **Koexistenz**: Legacy-Investitionen (SCCM, GPOs) bleiben funktionsfähig
3. **Flexibilität**: Workloads können je nach Business-Anforderung verschoben werden
4. **Rollback-Fähigkeit**: Jeder Schritt ist innerhalb von 24h reversibel

**Kritische Erfolgsfaktoren**:
– **Pilot-First**: Niemals ohne 50-Device Pilot in Production gehen
– **Monitoring vor Migration**: Baseline-Metriken erfassen, um Erfolg messbar zu machen
– **GPO-Hygiene**: Konfliktäre GPOs identifizieren und auf „Not Configured“ setzen
– **User Communication**: End-User über Changes informieren (besonders bei Update-Rings)
– **Fallback-Plan**: Für jede Phase einen dokumentierten Rollback-Pfad haben

Die MDM Bridge ist der technisch sauberste Weg, von Legacy zu Modern Management zu migrieren. Sie erfordert Planung, aber sie belohnt mit einer Architektur, die sowohl Stabilität als auch Agilität bietet.
session_id: 20260814_000848_45c51e