Enabling co-management on existing Configuration Manager clients: pilot and verification

Co-management lets a Windows device keep its Configuration Manager client (the product many people still call SCCM or MECM) while also enrolling in Microsoft Intune, so you can move workloads to the cloud one at a time. In this post I'll switch it on for existing clients the careful way: prerequisites first, then a small pilot collection, then the checks that prove a device really is co-managed.

Prerequisites#

Most co-management problems start with a skipped prerequisite:

Step-by-step#

1. Make sure devices are hybrid joined#

Hybrid join relies on Microsoft Entra Connect: Configure device options › Configure Microsoft Entra hybrid join in its wizard sets up the service connection point for each forest. Then have the Configuration Manager client trigger registration. Under Administration › Overview › Client Settings, open the client settings your devices use, select Cloud Services and set Automatically register new Windows 10 domain joined devices with Microsoft Entra ID to Yes.

On a pilot device, check both join states in one go:

dsregcmd /status | findstr /i "AzureAdJoined DomainJoined"

You want AzureAdJoined : YES and DomainJoined : YES. If the Entra join is missing, fix it first using my dsregcmd troubleshooting guide. Co-management can't enroll a device that isn't joined.

2. Configure automatic MDM enrollment#

In the Microsoft Entra admin center, open Entra ID › Mobility (MDM and MAM) › Microsoft Intune. Set MDM user scope to Some (choosing a group that contains your pilot users) or to All, leave the default URLs and save. Co-managed devices enroll with their Entra device token rather than a user token, but Microsoft still requires the MDM user scope to be set.

Because enrollment uses the device token, only the default Intune enrollment restriction applies. If that default restriction blocks the Windows (MDM) platform, co-management enrollment fails, however your other restrictions are configured.

3. Build a pilot collection#

Create a device collection such as Co-management pilot, limited to All Desktop and Server Clients, and add a handful of workstations with a mix of hardware models, sites and user types. Then check that they also appear in the built-in Co-management Eligible Devices collection, which lists clients that meet the prerequisites.

This collection becomes your Intune Auto Enrollment collection. Treat it as a superset: every device you later add to a workload's pilot collection must also be in this one, or it never enrolls.

4. Run the Cloud Attach Configuration Wizard#

1. Go to Administration › Overview › Cloud Services › Cloud Attach and select Configure Cloud Attach on the ribbon.
2. Choose the Azure environment (AzurePublicCloud for most tenants), select Sign In and authenticate.
3. Choose Customize settings. The recommended defaults enroll every eligible device automatically, which isn't a pilot.
4. Confirm the Microsoft Entra application registration when you're prompted.
5. On Configure upload, decide whether to upload devices to the Intune admin center. That's tenant attach, which is separate from co-management and covered in my tenant attach post.
6. On Enablement, set Automatic enrollment in Intune to Pilot and select your pilot collection as the Intune Auto Enrollment collection. If you already run a cloud management gateway, this page also shows a client install command line for internet-based devices that are already in Intune. Save it.
7. Complete the wizard.

With the wizard in version 2111 and later, every workload stays with Configuration Manager. You move workloads later from the properties of the co-management policy, which is called CoMgmtSettingsProd by default. That process is covered in Moving co-management workloads from Configuration Manager to Intune.

5. Let the pilot enroll#

Clients get the co-management settings at their next machine policy cycle. Configuration Manager deliberately spreads enrollment out in large estates, where it can take several days, but on a pilot device you can speed things up:

# Request machine policy now
Invoke-CimMethod -Namespace root\ccm -ClassName SMS_Client -MethodName TriggerSchedule `
  -Arguments @{ sScheduleID = '{00000000-0000-0000-0000-000000000021}' }

Device-token enrollment doesn't need anyone to be signed in.

Verify#

Check from three angles: the device, Intune and the Configuration Manager console.

• CoManagementHandler.log (in %WinDir%\CCM\Logs) records the co-management policy, each enrollment attempt and its result. While a device is still waiting you'll see Device is not MDM enrolled yet. All workloads are managed by SCCM. After the next policy cycle, that message should be gone.
• Event log: look in Applications and Services Logs › Microsoft › Windows › DeviceManagement-Enterprise-Diagnostics-Provider › Admin. Event ID 75 (Auto MDM Enroll: Succeeded) means enrollment worked. Event ID 76 means it failed, and the event includes the error code.
• Windows: Settings › Accounts › Access work or school lists the work account, and its Info page lets you run a sync. Task Scheduler gets a folder for the enrollment under Microsoft › Windows › EnterpriseMgmt.
• Intune admin center: under Devices › Windows, the device shows Co-managed in the Managed by column, with a recent check-in time.
• Configuration Manager: the Monitoring › Co-management dashboard shows how many devices have enrolled, how many are still pending and how many have failed, and the error codes behind the failures.

Tips & gotchas#

• Don't accept the defaults by accident. Default settings enable enrollment for every eligible device. If you want a pilot, choose Customize settings.
• Enrollment comes back. If a user unenrolls a pilot device, the policy re-enrolls it at its next evaluation. To take a device out, remove it from the collection first.
• Watch for dual state. Devices that were Entra registered before they were hybrid joined can end up with two device objects. Clean them up as described in my dual state guide.
• Check MFA early. Legacy per-user MFA, or Conditional Access that requires MFA for all resources, can block enrollment or the first MDM sync. The symptoms and fixes are in my co-management troubleshooting post.
• Enrolling isn't switching. Configuration Manager still manages everything on a co-managed device until you move a workload.

References#

• Tutorial: Enable co-management for existing Configuration Manager clients
• How to enable co-management in Configuration Manager
• Enable cloud attach for Configuration Manager