Autopilot into co-management: installing the Configuration Manager client during the ESP

If new Windows devices should end up co-managed, the Configuration Manager client (still SCCM or ConfigMgr to many people) has to arrive during Windows Autopilot. Pushing ccmsetup as an ordinary Intune app races the Enrollment Status Page (ESP) and doesn't control which tool owns the workloads. In this post I'll set up Microsoft's supported route, Windows Autopilot into co-management, cover the older Win32 app method, and show how to check each stage.

How it works#

The feature is driven by a co-management settings policy in Intune. When an Autopilot device enrolls and has one assigned, the ESP gets extra work:

1. In Device preparation, Intune registers Configuration Manager as an ESP policy provider and sets the management authority from the policy.
2. The device downloads the small CCMSetup.msi bootstrapper from Intune and runs it with your command line, which points at your cloud management gateway (CMG). ccmsetup downloads the site's production client from the CMG, so no client content lives in Intune.
3. The client registers through the CMG and receives the production co-management policy, which decides the workloads. The ESP waits on Preparing your device for mobile management meanwhile.
4. In Device setup, a PROVISIONTS property makes the client run that task sequence, which the ESP tracks as an app, restarts included. Account setup has no integration.

The supported scenario is narrow:

Step-by-step#

1. Get the site ready#

Confirm the CMG is healthy and the site is onboarded to Microsoft Entra ID through cloud attach. Entra joined devices also need the site to use enhanced HTTP or HTTPS (see my enhanced HTTP vs HTTPS deep dive). Then settle the workload positions in the production co-management policy, which is what new devices receive.

2. Copy the client command line#

In the Configuration Manager console, go to Administration › Overview › Cloud Services › Cloud Attach, open the properties of the co-management object (CoMgmtSettingsProd by default) and switch to the Enablement tab. Copy the command line rather than typing it. It looks like this:

CCMSETUPCMD="CCMHOSTNAME=<CMG FQDN>/CCM_Proxy_MutualAuth/<ID> SMSSiteCode=<site code>"

To run a task sequence during device setup, add PROVISIONTS=<task sequence ID> inside the quotes alongside the other client properties.

3. Create the co-management settings policy#

1. In the Microsoft Intune admin center, go to Devices › Device onboarding › Enrollment, stay on the Windows tab, select Co-management Settings and then Create.
2. On the Settings page, set automatic installation of the Configuration Manager client to Yes and paste the command line.
3. Under Advanced, decide on Override co-management policy and use Intune for all workloads. No, the default, lets the Configuration Manager co-management policy decide. Yes suits cloud-first devices that keep the client only for some apps. Decide once: Microsoft warns that changing it later also hits devices already provisioned, with unpredictable timing.
4. Assign the policy to a device group, for example a dynamic group built from an Autopilot group tag:

(device.devicePhysicalIds -any (_ -eq "[OrderID]:CoMgmt"))

If several co-management settings policies can reach a device, set their priority: each device gets only one.

4. Line up the ESP and the Autopilot profile#

Assign a user-driven, Microsoft Entra joined deployment profile and an ESP profile to the same group. The ESP profile needs Show app and profile configuration progress set to Yes, and Show an error when installation takes longer than specified number of minutes (60 by default) must cover the client download plus your task sequence. Keep that task sequence to day-one apps; the rest can follow through normal deployments.

Don't also make Intune Win32 apps blocking in the same ESP. Microsoft says to use either the Configuration Manager provider or the Intune Management Extension provider, not both, because neither knows about the other. If installation order matters, use the task sequence.

5. If you still deploy ccmsetup as a Win32 app#

The older method packages ccmsetup.msi (in bin\i386 under the site server's Configuration Manager installation folder) as a blocking Win32 app with the same CCMSETUPCMD command line. Two catches:

• The MSI is only a bootstrapper. ccmsetup keeps downloading and installing the client afterwards, so "installed" in the ESP doesn't mean registered.
• On Windows 11, a device without a co-management settings policy gets Intune as its management authority during Autopilot, and a Win32 client install doesn't change that. To give Configuration Manager the authority, assign a co-management settings policy with automatic installation and the override both set to No.

Packaging basics are in my Win32 app guide, but for new builds I'd use the policy.

Verify#

During OOBE, press Shift+F10, type powershell and check what the ESP is tracking:

$base = 'HKLM:\SOFTWARE\Microsoft\Windows\Autopilot\EnrollmentStatusTracking\Device'
# Configuration Manager client (Device preparation)
Get-ItemPropertyValue -Path "$base\DevicePreparation\PolicyProviders\ConfigMgr" -Name InstallationState
# Task sequence (only when you use PROVISIONTS)
Get-ItemPropertyValue -Path "$base\Setup\Apps\Tracking\ConfigMgr\Provisioning_TS" -Name InstallationState

Good looks like 3 (complete) for both. For the client, 1 means ccmsetup never downloaded or started and 4 means it failed. For the task sequence, 2 means it's still running.

• %WinDir%\ccmsetup\Logs\ccmsetup.log ends with CcmSetup is exiting with return code 0.
• In %WinDir%\CCM\Logs, LocationServices.log shows the management point found through the CMG, ClientIDManagerStartup.log shows registration completing and CoManagementHandler.log shows the co-management policy and workloads.
• Off the corporate network, the Configuration Manager Control Panel applet shows the connection type Currently internet.
• The Intune admin center lists the device as Co-managed under Managed by.

Tips & gotchas#

• Error 0x800705b4 at "Preparing your device for mobile management" means the ESP timed out waiting for the client. Check the registry value above, then ccmsetup.log for CMG or authentication failures. My ESP timeout guide covers the general method.
• Collect the Configuration Manager logs yourself. Run from a command prompt, mdmdiagnosticstool.exe -area Autopilot;DeviceEnrollment -cab C:\autopilot.cab skips %WinDir%\ccmsetup\Logs and %WinDir%\CCM\Logs (where smsts.log also lands), so copy those too.
• Plan the end state. If these devices are heading for cloud-native management, read my phased migration plan before investing in provisioning task sequences, and my workload guide for moving sliders later.

References#

• How to enroll with Windows Autopilot (Configuration Manager co-management)
• Windows Autopilot with co-management
• How to enable co-management in Configuration Manager