Co-management not working? CoManagementHandler.log, enrollment errors and workload status

You've enabled co-management and filled the pilot collection, yet Intune shows nothing. Or it shows the device, but your Intune policies never take effect. In this post I'll follow the co-management chain on a Windows client (policy, join, MDM enrollment, workload flags) and show what CoManagementHandler.log and the enrollment events tell you at each step.

Symptoms#

• A pilot device is missing from the Intune admin center, or shows ConfigMgr (tenant attach) rather than Co-managed under Managed by.
• The Monitoring › Co-management dashboard shows devices pending or failed, with enrollment errors.
• The device logs event ID 76: Auto MDM Enroll: Failed (Unknown Win32 Error code: 0x...).
• Access work or school says Sync wasn't fully successful because we weren't able to verify your credentials.
• The device is co-managed, but Intune policies for one area never apply.

Why it happens#

A device is only co-managed when every link in this chain holds:

Microsoft notes that most issues come from a setup step that was skipped or not completed, so check configuration before you blame the device.

How to fix it#

1. Prove the client has the co-management policy#

Open %WinDir%\CCM\Logs\CoManagementHandler.log in CMTrace or OneTrace. A device that has the policy but hasn't enrolled yet logs entries like these:

Auto enrollment agent is initialized.
Device is not enrolled.
AAD-Join Info: type = 1 DeviceId = '<device ID>' TenantId = '<tenant ID>' ... EnrollmentUrl = 'https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc'
Device is not MDM enrolled yet. All workloads are managed by SCCM.
Value of CoManagementFlags retrieved: 0x2001
There is no scheduled tasks under "EnterpriseMgmt"

No recent auto-enrollment entries means the client hasn't received the policy. Check that the device is in the collection you chose as Intune Auto Enrollment, that automatic enrollment isn't set to None, and then run a machine policy cycle. The settings arrive as a baseline whose name starts with CoMgmtSettings. You'll find it on the Configurations tab of the Configuration Manager control panel applet, where Evaluate runs it again. In large environments enrollment is staggered, so a device may simply be queued.

2. Confirm the device is hybrid joined#

Run dsregcmd /status. You need AzureAdJoined : YES as well as DomainJoined : YES. A common join failure is 0x801c03f2: Microsoft Entra ID can't find the device's public key because the computer object hasn't synced yet. My dsregcmd guide covers the fixes. Also check that the client setting Automatically register new Windows 10 domain joined devices with Microsoft Entra ID is Yes.

3. Read the MDM enrollment events#

The real error code is in Applications and Services Logs › Microsoft › Windows › DeviceManagement-Enterprise-Diagnostics-Provider › Admin, where event 75 means a successful automatic enrollment and event 76 a failure. Token problems appear alongside them in Microsoft › Windows › AAD › Operational.

Get-WinEvent -LogName 'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin' -MaxEvents 300 |
  Where-Object Id -in 75, 76 | Format-List TimeCreated, Id, Message

If enrollment works but sync fails with the verify your credentials message, the Admin log shows MDM Session: Failed to get Microsoft Entra Token for sync session with 0xcaa2000c. Per-user MFA, or Conditional Access requiring MFA for all cloud apps, is blocking the token. Microsoft's documented fixes are to turn off legacy per-user MFA for those users, or to exclude the Microsoft Intune app (0000000a-0000-0000-c000-000000000000) from the MFA policies. Weigh that exclusion against your security baseline first.

4. Re-trigger enrollment#

Nothing needs rebuilding: the policy retries at its next evaluation. To hurry a test device along, request machine policy, evaluate the CoMgmtSettings baseline and watch the log:

Invoke-CimMethod -Namespace root\ccm -ClassName SMS_Client -MethodName TriggerSchedule `
  -Arguments @{ sScheduleID = '{00000000-0000-0000-0000-000000000021}' }
Get-Content "$env:WinDir\CCM\Logs\CoManagementHandler.log" -Tail 30 -Wait

5. Check which authority owns the workload#

If a co-managed device ignores an Intune policy, check the workload first. In the co-management properties, each workload is set to Configuration Manager, Pilot Intune or Intune. With Pilot Intune, only devices in that workload's collection on the Staging tab switch.

• A device must be enrolled and in the workload's pilot collection. If it's in a staging collection but not in Intune Auto Enrollment, it never switches.
• Value of CoManagementFlags retrieved is a bitmask of the workloads handed to Intune. Don't decode it by hand: compare it with a healthy pilot device. If it doesn't change after you move a slider, the device hasn't picked up the new policy yet.
• Exception: a baseline set to Always apply this baseline even for co-managed clients keeps applying after device configuration moves to Intune.

For planning the switch itself, see my workloads guide.

Verify the fix#

• Event 75 (Auto MDM Enroll: Succeeded) is logged and no new event 76 follows.
• CoManagementHandler.log no longer reports Device is not MDM enrolled yet, and Task Scheduler has an enrollment folder under Microsoft › Windows › EnterpriseMgmt.
• Sync on the work account's Info page completes without a credentials error.
• Intune shows the device as Co-managed with a fresh check-in.

Key takeaways#

• Check the chain in order (policy, join, enrollment, workloads) and fix the first broken link.
• CoManagementHandler.log shows what the client is attempting. Event 76 shows why enrollment failed.
• Before you widen the pilot, confirm the default enrollment restriction allows Windows (MDM) and the MDM user scope covers your users.
• Keep Intune Auto Enrollment as the superset collection, and build each workload's pilot collection from it.

References#

• Troubleshoot co-management: Auto-enroll existing Configuration Manager-managed devices into Intune
• Tutorial: Enable co-management for existing Configuration Manager clients