Sektion 09: Co-Management: SCCM + Intune Hybrid Setup

Einleitung: Warum Co-Management der Brückenschlag in die Cloud ist

Die meisten Unternehmen stehen nicht vor der Frage „SCCM oder Intune?“, sondern vor der Realität: „Wir haben seit zehn Jahren Configuration Manager im Haus — und müssen trotzdem jetzt in die Cloud.“ Genau hier setzt Co-Management an. Es ist Microsofts offizielles Migrationskonzept, mit dem Windows-10/11-Geräte gleichzeitig von Configuration Manager (ConfigMgr/SCCM/MECM) und Microsoft Intune verwaltet werden können.

Co-Management ist kein Kompromiss, sondern ein strategisches Werkzeug: Sie verschieben Workloads — Stück für Stück, kontrolliert, reversibel — von der On-Premises-Infrastruktur in die Cloud. Compliance-Richtlinien testen, während das Imaging noch lokal läuft? Kein Problem. Windows Update for Business über Intune steuern, aber Software weiter per SCCM verteilen? Auch möglich. Diese Sektion ist der technisch anspruchsvollste Teil der gesamten Masterclass-Reihe, weil Sie hier zwei komplette Management-Stacks gleichzeitig verstehen und orchestrieren müssen.

Am Ende dieser Sektion können Sie: Cloud Attach (Tenant Attach) einrichten, Clients per Co-Management an Intune binden, die sieben Co-Management-Workloads bewusst verteilen, die typischen Fallstricke (State-Message-Konflikte, Zertifikatsprobleme, CMG-Anforderungen) identifizieren und beheben — und einen realistischen Migrationsfahrplan für Ihre Organisation erstellen.

Grundkonzepte: Die Architektur von Co-Management verstehen

Was Co-Management technisch tut — und was nicht

Ein Co-managed Gerät hat zwei Management-Agents auf derselben Maschine:

• Den Configuration Manager Client (ccmexec) — kommuniziert mit dem lokalen Management Point, oft über die Cloud Management Gateway (CMG) auch für internetbasierte Geräte
• Das Intune Management Extension (IME) — der Win32-Sidecar von Intune, der PowerShell-Skripte, Win32-Apps und Remediations ausführt

Beide Agents melden sich an ihren jeweiligen Backends. Co-Management konflikt-frei zu halten, funktioniert über sogenannte Workloads: Für jede Verwaltungsfunktion existiert genau ein „Authority Slider“, der festlegt, ob ConfigMgr, Intune oder (bei manchen Workloads) Pilot-Gruppen zuständig sind. Der Schalter lebt in der ConfigMgr-Konsole unter Administration → Cloud Services → Cloud Attach, wird aber letztlich in Intune bzw. Microsoft Endpoint Configuration Manager synchronisiert.

Voraussetzungen — die unverhandelbare Checkliste

Vor dem ersten Client-Enrollment müssen diese Punkte grün sein:

• ConfigMgr-Version: Mindestens ConfigMgr 2111 oder neuer (empfohlen: aktueller Support-Zweig, da Microsoft Co-Management-Features nur in den letzten Releases wartet). Ältere Versionen haben fehlende Workload-Optionen und veraltete Entra ID-Token-Handling-Logiken.
• Microsoft Entra ID (ehemals Azure AD): Hybrid-Join für On-Premises-AD-Joined-Geräte oder reine Entra-Joined-Geräte. Hybrid Azure AD Join ist der klassische Pfad — Geräte erscheinen sowohl im lokalen AD als auch in Entra ID.
• Lizenzen: Intune-Lizenz (teil von Microsoft 365 Business Premium, Enterprise E3/E5 oder Standalone) für jeden Benutzer bzw. jede Geräte-Lizenz.
• Tenant Attach / Cloud Attach: Der ConfigMgr-Site Server muss über Cloud Attach mit Ihrem Intune-Tenant verbunden sein. Das erfordert die Rolle „Company Administrator“ oder „Intune Administrator“ in Entra ID.
• Cloud Management Gateway (CMG) oder zumindest Enhanced HTTP (eHTTP): Damit Co-Management-Clients im Internet (VPN-aus) mit ConfigMgr weiter sprechen können. Ohne CMG können im Homeoffice Co-managed Geräte ihre ConfigMgr-Richtlinien nicht mehr empfangen — aber Intune-Workloads funktionieren weiterhin.
• AD-Schema-Erweiterung nicht zwingend: Die moderne Co-Management-Registrierung läuft über die Tenant-Attach-Vernetzung, nicht mehr klassisch über AD Schema-Erweiterung für MDM.
• OS-Support: Windows 10 1709+ oder Windows 11. Ältere OS-Versionen können kein Modern-MDM-Enrollment.
• Nicht unterstützt: Server-OS (kein Co-Management), Mac (kein ConfigMgr-Client), Geräte in Air-Gap-Umgebungen ohne Internet.

Die sieben Co-Management-Workloads im Detail

Jede Workload kann unabhängig auf „ConfigMgr“, „Pilot Intune“ oder „Intune“ gesetzt werden — bis auf Compliance policies und Resource access policies, die zusammenhängen (Compliance setzt Konfigurationsprofile voraus).

• Compliance policies (Konformitätsrichtlinien): Gerätekonformität (BitLocker aktiv, OS-Version, Secure Boot) — die Basis für Conditional Access. Hier ist der erste sinnvolle Move, weil Sie mit Intune Compliance direkt auf Entra Conditional Access zugreifen.
• Windows Update policies: Steuerung von Update-Rings, Feature-Update-Verzögerungen, Treiber-Updates über Windows Update for Business statt WSUS/SUP.
• Resource access policies: Wi-Fi-, VPN- und Zertifikatsprofile — sehr praxisrelevant, wenn Standorte per SCEP-Machine-Zertifikate versorgt werden sollen.
• Endpoint Protection: Defender AV, ASR-Rules, Firewall — seit dem Wechsel zu Security baselines und Endpoint Security Policies ist dieser Workload fast immer zuerst auf Intune zu ziehen (Moderner Security-Stack, Tamper Protection etc.).
• Device configuration: Konfigurationsprofile (Settings Catalog) statt klassischer GPO-Inhalte.
• Office Click-to-Run apps: Office-Installation und -Updates via Intune-App-Distribution.
• Client apps: Win32-App-Bereitstellung über Intune statt SCCM-Application-Modell, inklusive Intune Management Extension.

Cloud Attach vs. Tenant Attach vs. Co-Management — Begriffsklärung

Die Begriffe werden oft durcheinandergeworfen, aber sie sind Schichten aufeinander:

• Tenant Attach (seit ConfigMgr 2002 im Portal umbenannt teils zu „Cloud Attach“): Der ConfigMgr-Server lädt Geräteinformationen in das Intune-Admin-Center hoch. Sie sehen ConfigMgr-Geräte in endpoint.microsoft.com und können einzelne Aktionen (Restart, Sync, Script) auslösen. Noch kein Client-Enrollment in Intune.
• Co-Management: Zusätzlich zum Tenant Attach werden die Geräte auch in Intune enrolled — das eigentliche Dual-Management. Der Client kommuniziert jetzt aktiv mit beiden Backends.
• Cloud Attach (seit 2203 umbenannt): Der Oberbegriff für den Onboarding-Prozess in der ConfigMgr-Konsole (früher „Co-Management“).

Faustregel: Tenant Attach ist lesen & remote steuern, Co-Management ist echtes Dual Management mit geteilten Workloads. In der Praxis konfigurieren Sie beides zusammen in einem Wizard.

Praxis-Implementierung: Schritt für Schritt

Phase 0: Assessment & Vorbereitung

Bevor Sie den Wizard starten, klären Sie den Ist-Zustand:

• Welche Geräte sind SCCM-managed? (ConfigMgr-Console: Alle Systeme mit Active Directory-Standortfiltering)
• Sind die Geräte bereits Hybrid-Azure-AD-Joined? Prüfen Sie mit dsregcmd /status auf einem Testgerät: AzureAdJoined : YES und DomainJoined : YES müssen beide true sein.
• Gibt es eine CMG? Wenn nicht: Enhanced HTTP aktivieren in der Site-Konfiguration (Administration → Site Configuration → Sites → Eigenschaften → Communication Security → „HTTPS oder Enhanced HTTP“).

Erstellen Sie eine dedizierte AD-Gruppe bzw. Entra-Gruppe für Pilotgeräte, z. B. SG-Intune-CoMgmt-Pilot. Diese Gruppe steuert später, welche Clients den Co-Management-Token erhalten.

Phase 1: Cloud Attach (Tenant Attach) einrichten

In der ConfigMgr-Konsole:

1. Navigieren Sie zu Administration → Cloud Services → Cloud Attach und wählen Sie „Configure Cloud Attach“.
2. Melden Sie sich mit einem Entra-Account an, der die Berechtigung Intune Administrator (oder Global Admin) besitzt. Die App-Registrierung für ConfigMgr wird automatisch erstellt.
3. Wählen Sie „Azure Public Cloud“ (außer Sie sind in GCC/DoD).
4. Aktivieren Sie „Enable automatic client enrollment for co-management“ — hier wählen Sie zwischen „Pilot“ (nur definierte Collection) und „All“ (alle Geräte, mit Staging-Collection).
5. Cloud Management Gateway: Wenn vorhanden, verlinken Sie Ihr CMG. Wenn nicht vorhanden, lassen Sie das Feld leer — Co-Management funktioniert auch ohne, aber Geräte hinter VPN-aus haben dann keine ConfigMgr-Erreichbarkeit.
6. Device Upload: Standardmäßig werden alle Geräte in den Tenant hochgeladen — das ist für Tenant-Attach-Sichtbarkeit sinnvoll und schadet nicht.
7. Rollen-Sicherung: ConfigMgr erstellt Apps in Entra ID. Notieren Sie sich den App-Namen (meist „ConfigMgrSvc“), um später das Token-Expiry zu überwachen.

Nach dem Abschluss zeigt ConfigMgr unter Monitoring → Cloud Attach den Status. In endpoint.microsoft.com erscheinen nach wenigen Minuten erste Geräteinträge mit dem Flag „Managed by ConfigMgr“.

Phase 2: Pilot-Collection für Co-Management definieren

Erstellen Sie eine Pilot-Collection in ConfigMgr, z. B. „Pilot Co-Management (10 Devices)“:

# PowerShell: Pilot-Collection anlegen und Query setzen
$SiteCode = Get-PSDrive -PSProvider CMSITE
Set-Location "$($SiteCode.Name):"

New-CMDeviceCollection -Name "Pilot Co-Management" `
    -LimitingCollectionName "All Systems" `
    -Comment "Pilotgruppe für Co-Management-Rollout"

# Mitglieder per Query hinzufügen (Beispiel: Bestimmte OU)
$Query = "SELECT * FROM SMS_R_System WHERE SMS_R_System.SystemOUName LIKE '%CONTOSO/PILOT%'"
Add-CMDeviceCollectionQueryMembershipRule -CollectionName "Pilot Co-Management" `
    -QueryExpression $Query -RuleName "Pilot-OU"

Diese Collection referenzieren Sie im Co-Management-Properties-Fenster unter Staging → Pilot groups für jede Workload, die Sie im Pilot testen wollen.

Phase 3: Workloads konfigurieren — der strategische Kern

Nun öffnen Sie die Eigenschaften des Co-Management-Objekts (Cloud Attach → Eigenschaften → Workloads). Hier beginnt die eigentliche Architekturarbeit. Empfehlung für den Einstieg:

• Wave 1 (erste 2-4 Wochen): Compliance policies → Pilot Intune. Damit können Sie Conditional-Access-Scoping testen, ohne Produktivgeräte zu gefährden.
• Wave 2: Windows Update policies → Pilot Intune. Definieren Sie einen Update-Ring „Pilot“ mit 7-tägiger Verzögerung.
• Wave 3: Endpoint Protection → Pilot Intune (Defender ASR, Firewall, Tamper Protection).
• Wave 4: Device configuration → Pilot Intune (Settings Catalog für typische Härtungen).
• Wave 5: Resource access → Pilot (Wi-Fi, Zertifikate über SCEP, wenn vorhanden).
• Wave 6: Client apps → Pilot (erste Win32-Apps parallel zu SCCM verteilen, Migration mit Migrations-Dashboard).
• Wave 7: Office Click-to-Run → Intune (sobald Update-Rings stabil sind).

Jede Wave mindestens 1-2 Wochen im Pilot validieren, dann auf „Intune“ für alle oder erweiterte Staging-Collections stellen. Dokumentieren Sie jede Änderung in Ihrem Change-Log.

Phase 4: Client-Enrollment verifizieren

Auf einem Pilotgerät prüfen Sie den Erfolg:

# 1. Entra ID Join Status
dsregcmd /status

# Erwartete Werte:
# AzureAdJoined : YES
# DomainJoined : YES
# WorkplaceJoined : NO

# 2. Intune Management Extension Status
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps" -ErrorAction SilentlyContinue
# sollte existieren, wenn IME installiert wurde

# 3. Co-Management-Status in der Registry
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\DeviceManageabilityCSP\Provider\MS DM Server\FirstSync" -ErrorAction SilentlyContinue

# 4. Letzte Sync-Zeit Intune prüfen
Get-ScheduledTask -TaskName "PushLaunch" -TaskPath "\Microsoft\Windows\EnterpriseMgmt\*" `
    | Select-Object Name, State

In der ConfigMgr-Konsole selbst erscheint das Gerät unter Assets and Compliance → Devices → Co-Management mit dem Status „Co-managed“ oder „Pilot Intune“ für die jeweilige Workload.

Best Practices aus der Praxis

• Niemals alle Workloads gleichzeitig umstellen. Konflikte sind schwer zu debuggen, wenn fünf Slides gleichzeitig bewegt wurden. Eine Workload pro Welle, dokumentieren, Rollback-Pfad beachten.
• CMG ist nicht optional für Remote-Work. Enhanced HTTP reicht für LAN/VPN, aber Homeoffice ohne VPN braucht CMG — sonst verlieren Co-managed Geräte ihre SCCM-Connectivity. Budget: ca. 80-150 €/Monat für eine mittlere CMG mit 2-3 CMG-VM-Instanzen.
• Token-Hygiene: Das ConfigMgr-Service-Principal in Entra ID läuft nach 12 Monaten ab (Client Secret). Erstellen Sie einen Kalendereintrag oder verwenden Sie Managed Identities, wo möglich.
• Workload-Konflikt-Matrix pflegen: Dokumentieren Sie in einem Confluence/Notion-Sheet, welche Workload wann umgezogen ist, wer verantwortlich war, welche Geräte im Pilot sind. Drei Monate später fragen Sie sonst „warum geht BitLocker-Policy nicht mehr auf Gerät X?“.
• Collection-Strategie: Verwenden Sie für jede Wave eigene Pilot-Collections (Pilot-WU, Pilot-Compliance, Pilot-Apps) statt eine große „Pilot-All“-Collection. So können Sie Workloads unabhängig ausrollen.
• Baselines zuerst migrieren: Bevor Sie Device configuration auf Intune ziehen, exportieren Sie Ihre lokalen Security-Baselines (z. B. mit Get-CMBaseline) und importieren Sie sie als Intune Security baseline oder Settings Catalog — sonst verlieren Sie Härtung.
• Boundary Groups: Achten Sie auf Boundary-Group-Konfiguration in ConfigMgr — Co-Managed Clients brauchen weiterhin einen funktionierenden Management Point (oder CMG) für SCCM-Workloads.
• Reporting: Das Co-Management Dashboard in ConfigMgr (Monitoring → Co-Management) zeigt Enrollment-Status, OS-Versionen und Workload-Verteilung. Exportieren Sie wöchentliche Snapshots während der Migration.

Troubleshooting: Die häufigsten Stolpersteine

Problem 1: Client enrolled nicht in Intune

Symptome: Gerät bleibt im ConfigMgr-Status „Co-Managed: No“, Intune zeigt kein Gerät.

Diagnose:

# Co-Management-Handler-Log prüfen (lokal auf dem Client)
Get-Content "C:\Windows\CCM\Logs\CoManagementHandler.log" -Tail 100

# Wichtige Fehler:
# "Failed to enroll device to MDM: 0x80192F00" → Token/Authority Issue
# "User not authorized for MDM enrollment" → Intune License fehlt

Häufigste Ursachen:

• Keine Intune-Lizenz für das Primary User des Geräts (bei User-less-Devices muss Device Enrollment Manager oder Group Policy-Enrollment konfiguriert sein)
• Hybrid-AAD-Join defekt (dsregcmd /status zeigt AzureAdJoined: NO) → dsregcmd /join oder das Hybrid-Join-Skript aus ConfigMgr ausführen
• Veraltetes ConfigMgr-Client-Upgrade: Clients < 5.00.8968 können bestimmte Co-Management-Features nicht

Problem 2: Workload-Konflikt — Richtlinien werden auf beiden Seiten angewendet

Symptome: Z. B. BitLocker-Policy wird sowohl von SCCM-Baseline als auch Intune-Endpoint-Security angewendet, Client zeigt widersprüchlicher Status.

Lösung: Workload-Slider korrekt setzen. Sobald eine Workload auf „Intune“ steht, deaktiviert ConfigMgr seinen Anteil automatisch — aber nur, wenn der Client die neue Autorität mitbekommt. Prüfen Sie per CoManagementHandler.log die Zeile „Workload switch received“. Fehlt der Eintrag, forcieren Sie einen Machine-Policy-Retrieval in der ConfigMgr-Client-Actions-Tabelle („Machine Policy Retrieval & Evaluation Cycle“).

Problem 3: CMG nicht erreichbar — Remote-Co-managed-Geräte offline

Symptome: Geräte im Homeoffice zeigen in ConfigMgr „No activity“, Intune-Sync funktioniert aber weiterhin (nur für Intune-Workloads).

Diagnose:

# Auf dem Client: CMG-Verbindung testen
Test-NetConnection -ComputerName "ihr-cmg-name.cloudapp.net" -Port 443

# ConfigMgr CMG-Connector-Logs auf dem Server:
# <InstallDir>\Logs\SMS_CLOUD_PROXYCONNECTOR.log

# CMG-CM-Log:
# <InstallDir>\Logs\CMGService.log

Lösungen: CMG-Kostenplan prüfen (CMG kann bei viel Traffic skalieren), TLS-Zertifikats-Expiry des CMG prüfen, Firewall/Proxy insbesondere für den URL *.cloudapp.net erlauben.

Problem 4: Tenant-Attach zeigt veraltete Daten

Symptome: Im Intune-Portal erscheinen Geräteinformationen mit mehreren Stunden Verzögerung.

Typische Ursachen: Der ConfigMgr Site Server hat keinen Internet-Access zu den erforderlichen Endpoints (management.azure.com, login.microsoftonline.com, graph.microsoft.com), oder das Service Principal Secret ist abgelaufen. Prüfen Sie mit der ConfigMgr-Console: Cloud Attach → Eigenschaften → „Synchronize now“ und schauen Sie in CloudAttachmentService.log auf dem Site Server nach.

Problem 5: Client-Apps-Workload umgezogen, aber Apps kommen doppelt

Symptome: Die gleiche App erscheint aus SCCM-Application und als Intune-Win32-App, Benutzer sehen Double-Icons.

Lösung: Das ist ein Migrationsdesign-Problem. Vermeiden Sie parallele Verteilung derselben App. Nutzen Sie die ConfigMgr-App-Deployment-Überwachung, um erfolgreiche Installationen in Intune-Apps zu „migrieren“: Intune-Erkennungsregel so konfigurieren, dass die bereits von SCCM installierte Anwendung als „bereits installiert“ erkannt wird (Registry-Key oder MSI-Product-Code). Erst danach auf SCCM-Seite deinstallieren bzw. Collection-Membership entfernen.

Fazit: Co-Management als Zwischenschritt, nicht als Endzustand

Co-Management ist Microsofts offizielle Antwort auf Jahrzehnte gewachsener Configuration-Manager-Infrastruktur — und es ist ein ausgezeichnetes Migrationswerkzeug, wenn Sie es strategisch nutzen: Workload für Workload, mit Pilot-Gruppen, dokumentierten Wellen und klaren Rollback-Pfaden. Was Co-Management nicht ist: ein Dauerbetriebszustand. Jedes Jahr im Co-Management kostet doppelte Wartung, doppelte Monitoring-Pfade und doppeltes Troubleshooting-Potenzial.

Ihr Ziel sollte immer sein, in 12-24 Monaten vollständig auf Intune-only zu migrieren. Co-Management ist die Brücke, nicht das Ziel. Nutzen Sie die Zeit, in der beide Stacks laufen, um Ihre Baselines zu modernisieren (Settings Catalog statt GPO), Ihre Win32-Apps sauber nach Intune zu portieren und Ihre Kollegen an das neue Intune-Admin-Center zu gewöhnen. Wenn der letzte Workload-Slider auf „Intune“ steht und das ConfigMgr-Reporting keine aktiven Clients mehr zeigt, ist der Moment gekommen, den Site Server abzuschalten — und die Infrastruktur der Zukunft gehört Ihnen.

In der nächsten Sektion der Masterclass schauen wir uns dann den finalen Schritt an: Wie Sie von Co-Management zu Intune-only wechseln — inklusive sauberer Decommissioning-Strategie für den ConfigMgr-Site-Server.

↑ Zur Kursübersicht: Intune-Kurs (alle Sektionen)