Co-management lets you hand Windows management to Intune one workload at a time, but a slider moved too early can silently drop settings that only ever lived in Configuration Manager. In this post I'll explain what each workload covers, walk through a pilot-first switch, and show how to confirm on the client which tool is in charge.
How it works#
Every workload has its own slider with three positions:
- Configuration Manager: Configuration Manager stays the authority. This is the default.
- Pilot Intune: Intune takes over only for devices in that workload's pilot collection.
- Intune: Intune takes over for every co-managed device.
The current workloads, and what to know before moving each one:
| Workload | Worth knowing |
|---|---|
| Compliance policies | Co-managed devices only report Intune compliance once this is on Pilot Intune or Intune. |
| Windows Update policies | After switching, change the Configuration Manager client settings to turn off the software update workflow for those devices. |
| Resource access policies | No longer supported since version 2203 and part of device configuration. From 2403 the slider is forced to Intune, and upgrades are blocked while old policies remain. |
| Endpoint Protection | Configuration Manager policies stay on the device until Intune policies overwrite them. |
| Device configuration | Also moves resource access and Endpoint Protection. Settings catalog policies follow this slider whatever they contain. |
| Office Click-to-Run apps | A built-in global condition stops Configuration Manager's Microsoft 365 Apps deployments installing on switched devices. |
| Client apps | Available apps from Intune show in Company Portal; Configuration Manager apps stay in Software Center. |
Prerequisites#
- Co-management enabled through Cloud Attach, with devices Microsoft Entra joined or hybrid joined (registered-only devices aren't supported) and enrolled in Intune.
- Duplicate Entra ID device objects cleaned up, because they can stop devices enrolling.
- The Intune equivalent of each workload built and assigned before you move its slider.
Step-by-step#
1. Build the Intune side first#
Recreate what Configuration Manager delivers today: compliance policies, update rings, endpoint security policies, configuration profiles and apps. Assign them to groups that contain your pilot devices. Microsoft's guidance is that every workload should always be managed by one of the two tools, never neither.
2. Choose pilot collections#
In the Configuration Manager console, go to Administration › Cloud Services › Cloud Attach, select the co-management object and choose Properties. On the Staging tab, pick a pilot collection for each workload. They can differ per workload, and a pilot can run as long as you need.
3. Move one slider to Pilot Intune#
On the Workloads tab, move a single workload to Pilot Intune and apply. Co-managed devices sync MDM policy from Intune automatically when a workload changes.
4. Validate on pilot devices#
The client logs in %WinDir%\CCM\logs tell you who's in charge:
| Log | What it shows |
|---|---|
CoManagementHandler.log | Co-management settings and the merged workload value |
ComplRelayAgent.log | Compliance workload state |
CIAgent.log | Configuration items skipped because another authority owns the workload |
WUAHandler.log | Windows Update workload state |
Workloads are stored as bit flags. You'll see lines such as Verifying if workload 2 is enabled in workloadFlags 7, and the result of that bitwise check tells you whether the workload belongs to Intune on this device (2 is compliance, 4 resource access, 16 Windows Update).
5. Expand to Intune#
When the pilot behaves, move the slider to Intune, then tidy up the Configuration Manager side, such as the software update client settings for the Windows Update workload.
6. Repeat in a sensible order#
Microsoft's co-management FAQ notes that after compliance, the workloads organisations most commonly move are Office Click-to-Run apps, client apps and Windows Update policies. My suggested order, from least to most disruptive:
- Compliance policies: low risk, and it unlocks Conditional Access.
- Client apps: additive, because Software Center keeps working.
- Office Click-to-Run apps.
- Windows Update policies, together with the client settings change.
- Endpoint Protection, once Intune antivirus, firewall and encryption policies are proven.
- Device configuration last, because it takes resource access and Endpoint Protection with it.
Note: Windows Autopatch requires the Windows Update, device configuration and Office Click-to-Run workloads to be managed by Intune.
Verify#
- In the console, Monitoring › Cloud Attach shows a Workload transition chart with the number of devices moved per workload.
- In the Intune admin center, Endpoint security › All devices shows co-managed devices as MDM/ConfigMgr Agent in the Managed by column.
- On the site server, the
SMS_Client_ComanagementStateclass inROOT\SMS\site_<site code>reports a device as co-managed when bothMDMEnrolledandComgmtPolicyPresentare 1.
Tips & gotchas#
- Rollback isn't a clean undo. You can move a slider back, but Windows and Office stay at any later version Intune installed.
- Pilot Intune doesn't remove policies. For Endpoint Protection and device configuration, Intune only removes an unassigned policy once the workload is fully on Intune, and removing tattooed Endpoint Protection settings also needs the device configuration workload switched.
- Keep an escape hatch. For settings Intune can't deliver yet, enable Always apply this baseline even for co-managed clients on a Configuration Manager configuration baseline.
- Move one workload at a time. When something changes on a pilot device, you'll know which slider caused it.