Co-Management with Configuration Manager and Intune: The Complete Guide · CloudEngineerHub
SCCM / MECM12 min read11 views
Co-Management with Configuration Manager and Intune: The Complete Guide
Enable Microsoft Configuration Manager and Intune co-management: prerequisites, workload switching, pilot rings, CMG, licensing, and a production rollout plan.
A
Anuradha Kumari
Published: September 9, 2026· Last Updated: October 25, 2026·12 min read
Co-Management with Configuration Manager and Intune: The Complete Guide
Most large Windows estates did not start in the cloud. They grew up on Microsoft Configuration Manager with on-premises distribution points, task sequences, and a Software Center that users actually liked. Moving all of that to Microsoft Intune in one jump is neither realistic nor necessary. Co-management lets a single Windows device be simultaneously managed by Configuration Manager and Intune, so you can shift each management workload to the cloud at your own pace while keeping what works on premises.
Visual Walkthrough
Switch authority one workload at a time; keep a rollback for each.
A
Anuradha Kumari
Author
Endpoint management specialist focused on Microsoft Intune, Windows Autopilot and modern EUC. Writes practical deployment, compliance and troubleshooting guides for IT teams.
Compliance policies first — least invasive, fastest feedback.
switch 2
3
Switch device config
Intune becomes authority for configuration profiles.
switch 3
4
Switch updates & endpoint security
WUfB + Defender policies move under Intune authority.
switch 4
5
Switch apps & Office
Win32 + Click-to-Run complete the migration surface.
6
Steady state
Both consoles live; reports show which authority owns what.
Continuous cycle
Co-Management — Workload by Workload. 1. Enable co-management: SCCM agent + Entra hybrid identity + license verified. — 2. Pilot workloads: Compliance policies first — least invasive, fastest feedback. — 3. Switch device config: Intune becomes authority for configuration profiles. — 4. Switch updates & endpoint security: WUfB + Defender policies move under Intune authority. — 5. Switch apps & Office: Win32 + Click-to-Run complete the migration surface. — 6. Steady state: Both consoles live; reports show which authority owns what.
This guide covers the full production path: prerequisites, the two enrollment flows, how workload authority actually works, a phased workload-switching plan, monitoring, and the operational details that decide whether co-management feels seamless or fragile.
Co-management workload transition. Full text: ConfigMgr client assets
Prerequisite assessment (MMAT / GPA)
Azure AD hybrid join
Co-management enablement
Workload sliders (Intune pilot)
Full workload cutover
Configuration Manager current branch, ideally 2203 or later, with clients patched to a recent client version.
Microsoft Entra identity: devices must be Microsoft Entra joined or Entra hybrid joined (Microsoft Entra Connect syncs the identity seam for hybrid estates).
Internet-based management: the Cloud Management Gateway (CMG) with a matching management point and distribution point, or Enhanced HTTP for environments without a PKI-issued server authentication certificate.
Microsoft Intune licenses for the users of the devices you intend to co-manage, with MDM authority set to Intune.
HTTPS-enabled management points (or Enhanced HTTP) so clients can communicate securely for enrollment.
Azure public endpoints reachable from clients: the CMG service, Entra ID authentication endpoints, and Intune service endpoints.
A pilot collection in Configuration Manager that mirrors your intended Intune assignment group.
How It Works
Co-management is a per-workload authority model. The device keeps the Configuration Manager client and remains fully visible in the ConfigMgr console, while Intune enrollment — driven by auto-enrollment — adds a second management plane. For each of the supported workloads, exactly one product is the authority:
Compliance policies — first workload to switch; unlocks Conditional Access backed by ConfigMgr inventory.
Device configuration — Intune policy replaces ConfigMgr configuration baselines for the device.
Windows Update policies — deferral policy authority moves to Intune (feature update and quality update ring control).
Endpoint protection — Defender AV and firewall policy authority moves to Intune.
Resource access — certificates, Wi-Fi, and VPN profiles move to Intune.
Client apps and Office Click-to-Run apps — Intune becomes the installation authority for targeted apps.
Everything that is not a switchable workload — operating system deployment, task sequences, software inventory, software metering, remote control, third-party updates — remains with Configuration Manager. Enrollment itself has two paths: existing ConfigMgr clients auto-enroll into Intune (driven by Entra device identity plus CMG or intranet HTTPS), and Intune-enrolled devices can install the ConfigMgr client automatically when co-management enrollment is enabled from the Intune side.
Step-by-Step Implementation
Step 1: Prepare Identity and Network
Verify hybrid join with dsregcmd /status (look for AzureAdJoined: YES and DomainJoined: YES), confirm Microsoft Entra Connect is syncing, and stand up CMG with the cloud management service or enable Enhanced HTTP. Without internet-based client management, remote and home-office devices will not enroll.
Step 2: Prepare Configuration Manager
Upgrade the site to a supported current branch version, patch clients, and enable Enhanced HTTP or bind HTTPS-enabled management points. Run client health checks on the pilot collection — co-management amplifies whatever client hygiene problems already exist.
Step 3: Enable Co-Management in ConfigMgr
In the Configuration Manager console go to Administration > Cloud Services > Co-management > Configure co-management. Sign in with your Entra tenant credentials, choose auto-enrollment in pilot, and select the pilot collection. This creates the co-management settings object that ConfigMgr evaluates for enrollment.
Step 4: Verify Enrollment in Both Consoles
Pilot devices should appear in Intune (Devices > Windows) and remain fully functional in ConfigMgr. In Intune, co-managed devices report a management agent type that reflects dual management. Check the Co-management dashboard (Monitoring > Co-management) for enrollment progress and workload distribution.
Step 5: Switch Workloads in Phases
Start with compliance policies (lowest risk, highest conditional-access value), then Windows Update policies, then endpoint protection. Move device configuration only after configuration baselines are migrated or retired in Intune terms. Move client apps last, once the application catalog is available in the Company Portal. Use the sliding scale: pilot, validate, expand rings.
Step 6: Operationalize
Document the authority matrix, align pilot collections with Intune assignment groups, and review the co-management workload reports weekly during rollout. Establish a rollback runbook — any workload can be flipped back to Configuration Manager.
Configuration Deep Dive
Three configuration areas decide the quality of your co-management experience:
Enrollment policy: auto-enrollment in pilot uses the Entra device identity; devices outside the pilot collection simply never enroll. Internet-based enrollment through CMG requires the cloud management gateway health to be green — a red CMG is the most common silent enrollment killer.
Workload authority semantics: when you switch the device configuration workload to Intune, ConfigMgr configuration baselines stop evaluating on those devices. Inventory and console visibility remain, but compliance for those settings now comes from Intune. The same logic applies to endpoint protection: Defender policy from Intune wins, while ConfigMgr's role becomes reporting.
Conditional access coupling: once the compliance policies workload is switched, compliance state for those devices flows from Intune into Entra Conditional Access. ConfigMgr-era compliance data no longer gates access, so validate your compliance rules in Intune before the switch, not after.
Real-World Enterprise Scenario
An 8,000-seat insurance group with a mature ConfigMgr hierarchy wanted Conditional Access for all Windows devices without a risky platform migration. The team enabled co-management with auto-enrollment in a 300-device pilot, switched the compliance policies workload first, and within a week had CA protecting Exchange Online and SharePoint for pilot users. They then moved Windows Update policies to Intune rings, which immediately simplified deadline management, and endpoint protection after aligning Defender for Endpoint policy with the security team. Device configuration was the hardest: they inventoried 140 configuration baselines, retired 60, rebuilt 30 as Intune settings catalog policies, and deliberately left 50 running under ConfigMgr authority by not switching the workload until the migration finished. Total time to full workload switch: seven months, with zero enrollment incidents after the CMG was hardened.
PowerShell for Co-Management
Report co-managed population and manage the co-management settings object:
PowerShell
1
2
3
4
5
6
Connect-MgGraph -Scopes'DeviceManagementManagedDevices.Read.All'# Inventory devices by management agent type — co-managed devices report configurationManagerClientMdmEas$devices = Invoke-MgGraphRequest -Method GET -Uri"https://graph.microsoft.com/beta/deviceManagement/managedDevices?`$select=deviceName,managementAgentType,complianceState&`$top=999"$devices.value | Group-Object managementAgentType | Sort-Object Count -Descending | Format-Table Name, Count
# Expected output: a 'configurationManagerClientMdmEas' row whose count equals your co-managed fleet
PowerShell
1
2
3
4
5
6
7
8
9
10
# Create a co-management settings object from the Configuration Manager module
Import-Module 'C:Program FilesMicrosoft Configuration ManagerAdminConsoleinConfigurationManager.psd1'
Set-Location 'C01:'
New-CMCoManagementPolicy -AutoEnroll$true -EnableCompliancePolicy$true -EnableDeviceConfiguration$true -Name'Co-management Pilot'# Expected output: the new co-management policy object; deploy it to the pilot collection in the console# Monitor pilot collection membership from ConfigMgr
Get-CMCollection -Name'Pilot - Co-managed' | Select-Object Name, CollectionID, MemberCount
# Expected output: Name, CollectionID (for example C0100014), MemberCount
Troubleshooting
Symptom
Likely Cause
Fix
Pilot devices never appear in Intune
Device not Entra joined, or CMG/HTTPS not reachable
Verify dsregcmd /status, test CMG connectivity, confirm the device is in the pilot collection
Enrolled but no workloads switched
Co-management policy not deployed or pilot collection empty
Deploy the co-management settings object and confirm collection membership
"Device limit reached" during Intune enrollment
User hit the MDM device cap in Intune
Raise the device limit in Devices > Enrollment > Windows > Enrollment restrictions
Compliance state flips after workload switch
Intune compliance rules differ from ConfigMgr baselines
Validate and align Intune compliance policies before switching the workload
Software Center apps stop installing after client apps switch
Intune is now the install authority for user-targeted apps
Publish LOB apps to Intune before flipping the workload; keep task-sequence-driven apps in ConfigMgr
Remote users cannot enroll after CMG maintenance
CMG service unhealthy
Check Administration > Cloud Services > Cloud Management Gateway health and Azure service status
Visual Walkthrough
Where every classic GPO behavior lives in modern management.
Side-by-SideGPO → Intune — Translation Map6/6
Group Policy
on-prem AD
Intune
cloud authority
ADMX templates + GPP
Settings Catalog + ADMX ingestion
Domain membership required
Entra identity, anywhere check-in
VPN/line-of-sight refresh
Push notification + 8h cycle
gpresult / RSoP reporting
Per-setting reports in portal
Scripts via GPO preferences
Platform scripts / remediations
GPO → Intune — Translation Map. Group Policy vs Intune. Group Policy: ADMX templates + GPP · Intune: Settings Catalog + ADMX ingestion — Group Policy: Domain membership required · Intune: Entra identity, anywhere check-in — Group Policy: VPN/line-of-sight refresh · Intune: Push notification + 8h cycle — Group Policy: gpresult / RSoP reporting · Intune: Per-setting reports in portal — Group Policy: Scripts via GPO preferences · Intune: Platform scripts / remediations
Common Errors
0x80180018 during Intune enrollment: the MDM user device limit is reached. Raise the limit or free device records before retrying.
"Device is not Azure AD registered": hybrid join failed silently. Re-run Entra Connect sync, verify the SCP points to the correct tenant, and check the device's dsregcmd output.
Auto-enrollment silently skipped: the device is not in the pilot collection or client version is below the supported floor. Confirm collection membership and upgrade clients.
Compliance "unknown" in Conditional Access: the compliance policies workload is not yet switched, or Intune compliance policy has no assignment covering the device.
Best Practices
Switch compliance policies first — it is low risk and immediately enables Conditional Access.
Never switch the device configuration workload while live ConfigMgr baselines still matter; migrate or retire them first.
Keep pilot collections and Intune assignment groups structurally identical so workload evaluation is predictable.
Watch the Co-management dashboard and the CoManagementHandler.log during rollout waves.
Enable auto-enrollment for new devices early; new builds should land co-managed by default.
Document a per-workload rollback runbook — the model is designed for two-way switching, so use it.
Security Considerations
CMG is an internet-facing endpoint: use a valid server authentication certificate (or Enhanced HTTP) and keep the site patched to avoid exposing known vulnerabilities.
Conditional Access now depends on Intune compliance for co-managed devices — restrict who can edit compliance policies and assignment filters.
Separate administrative planes: ConfigMgr full administrators and Intune application administrators should be distinct roles with scoped rights.
Review the Entra sign-in and device registration logs for unexpected co-management enrollment from unmanaged networks.
FAQ
Q: Can a device really be managed by both products at once?
A: Yes — that is the design. The client stays installed and ConfigMgr keeps its non-switched workloads, while Intune owns whichever workloads you switch.
Q: Which authority wins when both target the same setting?
A: The workload authority wins by definition: only the authoritative product evaluates that workload for the device, which is why phased workload switching matters.
Q: Do I need CMG if my users are always on VPN?
A: Enrollment and management can work over intranet HTTPS, but CMG (or equivalent internet access) removes the VPN dependency and is strongly recommended for a hybrid workforce.
Q: Can I reverse a workload switch?
A: Yes. Workloads can be flipped back to Configuration Manager at any time, which is what makes the co-management rollout inherently low risk.
Q: How do Windows 365 Cloud PCs fit in?
A: Cloud PCs enroll directly into Intune — no ConfigMgr client — and are managed as regular Intune devices alongside your co-managed fleet.
Conclusion
Co-management is the most pragmatic migration path in the Microsoft endpoint stack: it preserves a decade of ConfigMgr investment while making every workload independently movable to Intune. The teams that succeed treat it as a program — identity and network readiness, a disciplined pilot collection, a documented authority matrix, and one workload at a time. Do that, and the ConfigMgr-to-Intune journey becomes a sequence of low-risk, reversible steps instead of a big-bang cutover.
Comments
0No comments yet — be the first to share your thoughts.