Autopilot into co-management: the ConfigMgr client handshake that has to happen in order

A co-managed Windows device is one that two management authorities look after at the same time. Microsoft Intune owns some workloads. Microsoft Configuration Manager owns the rest. That split only works if both sides agree on the map. On a device built by Windows Autopilot, that agreement has to be reached during provisioning, while the device is still in the out-of-box experience (OOBE) and nobody is watching.

When it goes wrong, it does not look like a failure. The device finishes OOBE. It appears in the Intune admin center. It has a Configuration Manager client folder on disk. Software Center even opens. But the client never registered with the site, so it never received the co-management policy, so it never learned which workloads it owns. Some workloads are now owned by nobody in practice. That is the failure this post is about, and the cause is almost always ordering.

The problem: a device that is enrolled, has a client, and obeys neither

Start with what a half-managed device actually looks like, because the symptoms are quiet.

The device completed Autopilot. It is Microsoft Entra joined. It has an Intune managed-device record. It reports a compliance state. On disk it has a C:\Windows\CCM folder and a running CcmExec service. Everything an inventory report checks is green.

Now look at behaviour. Windows Update policies from Intune are not applying, because the client believes Configuration Manager owns that workload. Configuration Manager is not applying anything either, because the client never registered with the site, so it has no policy to apply. The device sits in a gap. Nothing errors. Nothing patches.

The same gap opens in the other direction. A Configuration Manager configuration baseline that used to apply stops applying, because Intune is now the device configuration authority. But the Intune profile that was supposed to replace it was never assigned, because the device group used for the co-management settings policy is not the group used for configuration profiles. Two authorities, one uncovered workload.

There are three distinct ways this ends up half-managed, and they are worth naming separately because the fix differs for each.

Why it happens: three handshakes, one ordering constraint

Autopilot into co-management is not one operation. It is three handshakes, and each one depends on the one before it. Understanding the dependency chain is the whole game, so here it is in order.

Handshake one: identity and MDM

The device joins Microsoft Entra ID and enrolls in Intune. Microsoft documents that this happens first, before anything Configuration Manager related. In user-driven mode the device has already completed the join and the enrollment by the time the enrollment status page appears.

Handshake two: client install and registration

This is the step people get wrong, and it has two halves that are easy to conflate.

The install half is that the device downloads CCMSetup.msi, a small bootstrap file, from the Intune service. It runs that bootstrap with the command-line parameters you supplied. Those parameters tell it where the cloud management gateway is. It then downloads the full client installation content from the gateway. That content is the site's production client version.

The registration half is separate. Once installed, the client communicates through the gateway, registers with the site, and only then requests policy. Registration is what mints a client GUID and assigns a site code. A client that installed but did not register is a client that will never ask for co-management policy.

Handshake three: workload authority

Only after registration does the client request policy and receive the co-management policy that tells it which workloads Intune owns. Microsoft describes the Intune side of this as setting the management authority on the device during the device preparation phase of the enrollment status page, based on the co-management settings policy. If that policy names Configuration Manager as the authority, the service does not apply Intune policies. It waits for policy from Configuration Manager to determine the workload configuration.

That word "waits" is the ordering constraint. Miss handshake two and handshake three never happens, and the device sits waiting for an authority that never speaks.

Why the old Win32 app approach was replaced

For years the accepted method was to package ccmsetup.msi as an Intune Win32 app and assign it. Microsoft's own documentation is unusually blunt about why that was a problem: installing the Configuration Manager client as a Win32 app "introduces component timing and policy delays". The Win32 app is delivered by the Intune Management Extension, which is a different policy provider with its own schedule. Nothing coordinates it with the enrollment status page.

The replacement is the co-management settings policy in Intune. Microsoft states plainly that you no longer need to create and assign an Intune app to install the client. The Intune enrollment policy installs the client as a first-party app, and the device gets the client content from the cloud management gateway, so you do not manage client content in Intune at all. You still supply the command-line parameters.

The Windows 11 default that catches everyone

This one deserves its own paragraph because it is the single most common cause of "the client is there but Intune owns everything".

Microsoft documents that on a Windows 11 device that has not been targeted with a co-management settings policy, the management authority is set to Microsoft Intune during the Autopilot process. Installing the Configuration Manager client as a Win32 app afterwards does not change the management authority. Intune continues to manage all the co-management workloads regardless of what the Configuration Manager slider says.

The documented remedy is counter-intuitive. To set the management authority to Configuration Manager, you create a co-management settings policy with both advanced settings set to No: Automatically install the Configuration Manager client set to No, and Override co-management policy and use Intune for all workloads set to No. You create a policy that installs nothing, purely to hand authority back.

Provisioning mode: the client that is present and deliberately deaf

If you use PROVISIONTS to run a task sequence, provisioning mode enters the picture. Microsoft documents that during an operating system deployment task sequence the client is placed in provisioning mode, and in that state the client does not process policy from the site. This is deliberate: it stops other deployments running while the task sequence works.

The problem is what happens when the task sequence fails in a way it cannot recover from, for example a restart mid-processing. The client is left in provisioning mode. It is installed, it is registered, and it is ignoring the site. An administrator has to identify and fix it manually. Microsoft documents a 48-hour default timeout after which the client exits provisioning mode by itself and restarts its process, and a documented way to adjust that timer.

How to verify: proving which authority owns each workload

Verification comes before the fix here, because on a half-managed device you cannot tell which handshake failed without looking. Each handshake has its own documented surface.

The registry surfaces

Everything below sits under one parent key:

Here is the same thing as a Registry Editor panel, so you know what you are looking at when you open it during OOBE with Shift and F10.

The WMI surfaces

On the device, the client's own namespace answers handshake two. Microsoft documents the SMS_Client class with a ClientVersion property, and documents reading the client's unique identifier from the CCM_Client class in the root\ccm namespace. A present client version with an absent client GUID is the exact signature of install-without-registration.

The enrollment status page tracking surface

The log surfaces, and why there is no Event ID catalog

This topic has no numbered Windows event catalog. Microsoft documents the diagnostic surface for Autopilot into co-management as two things: Configuration Manager log files, and CloudExperienceHost ETW entries in the Shell-Core logs collected by the MDM diagnostics tool. There are no documented Event Viewer event IDs for the co-management handshake, so this post does not invent any. Use the logs.

All the client logs below live in one folder:

The interesting part is that the component logs show the client doing the bitwise arithmetic itself. Microsoft's own sample lines look like this.

This is the definitive per-workload answer. The client states the workload bit it is testing, states the flags value it is testing against, states the result of the bitwise AND, and then states its verdict in plain English: Intune managed, or SCCM managed. You do not have to decode anything.

The fix: the documented Autopilot into co-management sequence

Three configurations, in this order. Do not reverse them.

Step 1: get the command line out of the Configuration Manager console

1. In the Configuration Manager console, go to the Administration workspace, expand Cloud Services, and select the Cloud Attach node. On version 2103 and earlier this node is called Co-management.
2. Select the co-management object and choose Properties in the ribbon.
3. On the Enablement tab, copy the command line. Paste it somewhere safe.
4. If the tab says the prerequisites are not installed, you do not have a cloud management gateway. Microsoft documents that the command line only appears once all prerequisites, including the gateway, are met. Stop here and build the gateway first.

Then decide which properties you actually need. Microsoft's guidance on this is refreshingly short.

Step 2: create the co-management settings policy in Intune

1. Go to the Microsoft Intune admin center. Select Devices, then Enroll devices, then Windows enrollment.
2. Select Co-management settings, then select Create.
3. On the Basics page, give the policy a name and an optional description.
4. On the Settings page, select Yes to automatically install the Configuration Manager client.
5. Paste the client installation command-line parameters you copied in step 1.
6. In the Advanced area, leave Override co-management policy and use Intune for all workloads at No unless you genuinely want Intune to own everything and the client to exist only for app delivery.
7. On the Assignments page, target a device group. Microsoft is specific about this: a device group, not a user group.
8. Review and create.

If you assign more than one such policy, Microsoft documents that Intune pre-computes which policy it serves to the device, and that the Co-management authority pane in the admin center lists the policy settings so you can set a priority per setting.

Step 3: assign an enrollment status page profile to the same group

1. In the admin center, select Devices, expand Device onboarding, and select Enrollment.
2. On the Windows tab, under Windows Autopilot, select Enrollment Status Page, then Create.
3. Name the profile on the Basics page.
4. On the Settings page set Show app and profile configuration progress to Yes. Microsoft documents this as a requirement for Autopilot into co-management, not an option.
5. Review Show an error when installation takes longer than specified number of minutes. The documented default is 60 minutes. That is the same 60 minutes the client install and any PROVISIONTS task sequence have to finish inside.
6. Assign the profile to the same device group as the co-management settings policy, and assign the Autopilot deployment profile there too.

What this buys you is the ordering guarantee. Microsoft documents that when the device is targeted with an enrollment status page policy, the device waits for the Configuration Manager client to be installed; the client installs, registers with the site, and applies the production co-management policy; and only then does the enrollment status page continue. That is handshake two and handshake three completing before the user reaches the desktop, which is exactly what the Win32 app approach could not promise.

The limitations you must design around

Microsoft documents these as unsupported for Autopilot into co-management. Check them before you build.

There is also a separate, older documented limitation worth knowing even outside this feature: you cannot deploy the Configuration Manager client while provisioning a new computer in Autopilot user-driven mode for Entra hybrid join, because the device identity changes during the hybrid join process. Deploy the client after Autopilot finishes in that case.

Proof it worked: three handshakes, all landed

The companion script for this post reports all three handshakes separately, so you can see which one is missing rather than guessing. It is read-only. It reads the documented registry values, the documented WMI classes and the documented log surfaces, decodes the workload map, and clearly labels which bit values Microsoft actually publishes and which are community-derived.

The script was run on a real co-managed client during writing, and the registry, WMI and log parsing all resolved correctly. The block above is sanitised: site code, client version and the capabilities number are replaced with placeholder or documented-sample values, because raw output from these logs can contain the device's Entra device ID and tenant ID. Bear that in mind before you paste a log tail into a ticket.

For the failures themselves, Microsoft documents the specific signatures. Error 0x800705b4 during device preparation means the enrollment status page timed out waiting for the client to install; the documented default timeout is 60 minutes. In the Shell-Core logs collected by the MDM diagnostics tool, the corresponding entry names CommercialOOBE_ESPDevicePreparation_PolicyProvidersInstallation_TimedOut. If instead the device setup phase shows an error for Apps, the entry names CommercialOOBE_BootstrapStatusCategory_SubcategoryProcessing_Failed and the task sequence log at %WinDir%\CCM\Logs\SMSTS\smsts.log has the reason.

Collect logs during OOBE with Shift and F10, then the documented MDM diagnostics command. Note the documented caveat: that tool does not collect the CCMSetup and client logs, so gather %WinDir%\ccmsetup\Logs and %WinDir%\CCM\Logs by hand.

One last piece of advice that comes straight from Microsoft's recommendations rather than from experience: when you run a task sequence after client installation, do not fill it with application installs. Many apps delay the process and risk the enrollment status page timeout. Include only critical apps that are needed immediately, and deliver the rest through separate deployments or user self-service. A 60-minute budget shared between a client download, a client install, a registration round trip and a task sequence is tighter than it looks.

References

Microsoft official documentation:

• How to enroll with Windows Autopilot — Configuration Manager — the process, requirements, limitations, configuration steps and troubleshooting for Autopilot into co-management.
• Co-manage internet-based devices — Configuration Manager — where the client command line comes from, and which properties are required.
• Client installation parameters and properties — CCMSETUPCMD, CCMHOSTNAME, SMSSITECODE, SMSMP, AADCLIENTAPPID, AADRESOURCEURI, PROVISIONTS, UPGRADETOLATEST.
• Provisioning mode — Configuration Manager — the CcmExec registry values, the 48-hour timeout and the supported way out.
• Troubleshooting Intune and Configuration Manager co-management workloads — the component logs and the documented workloadFlags sample lines.
• Monitor co-management — Configuration Manager — the SMS_Client_ComanagementState WMI class and its fields.
• Log file reference — Configuration Manager — the documented purpose of each client log named above.
• Co-management workloads — Configuration Manager — the exact workload names and what each one covers.
• SMS_Client class — the client WMI class and its ClientVersion property.
• Set up the Enrollment Status Page — the profile settings, the 60-minute default timeout and what each phase tracks.
• Co-management settings: Windows Autopilot with co-management — the Microsoft Intune blog post referenced from the docs for the Windows 11 management authority default.

Community deep-dives worth reading alongside the docs:

Companion script for this post: Get-CoManagementHandshakeState.ps1. Read-only, ASCII-only, runs on Windows PowerShell 5.1 and PowerShell 7, prompts before installing anything, and aborts loudly rather than reporting a clean co-management state it could not actually prove.