Configuration Manager and co-management

This hub is for administrators who still run a Configuration Manager site and have co-management switched on, or are about to. The estate is usually mixed: some devices built by task sequence years ago, some arriving through Autopilot, and a ConfigMgr client on most of them. The recurring question is not “Intune or ConfigMgr?” in the abstract. It is “which service is supposed to own this setting, on this device, today?”

Answer that before you open a ticket queue. Most co-management incidents are ownership incidents: two services both believe they are in charge, or neither is, and the portal on each side reports success.

Microsoft documents seven co-management workloads: compliance policies, Windows Update policies, resource access policies, Endpoint Protection, device configuration, Office Click-to-Run apps and client apps. Each slider can sit at Configuration Manager, Pilot Intune or Intune, and each Pilot Intune setting points at a pilot collection. Write down the current value and the pilot collection for every workload before anyone changes a policy on either side.

Then answer these questions for the device in front of you:

A common shortcut is to take a ConfigMgr application that fails on some clients, export the source, wrap it as an .intunewin file and hope Intune does better. Sometimes the failure genuinely was ConfigMgr-specific: a boundary group with no distribution point, or content that never reached the DP the client was told to use. Intune Win32 content is delivered by the Intune service rather than located through ConfigMgr boundary groups, so that particular problem does not travel.

Everything else does. A detection method that lies moves with the package: if the ConfigMgr rule looks at the installer cache, the wrong registry view or a bootstrapper product code, the Intune detection rule copied from it will report the same false result. A non-silent install command, an unmapped return code or a user-context install quietly turned into a device-context assignment will fail the same way under the Intune Management Extension.

So classify first. Decide whether the ConfigMgr failure is a content miss or a detection lie, fix it on one clean client, and only then export the source for an Intune pilot. If you cannot get the package to install and detect correctly under ConfigMgr, you do not yet have a package to migrate.

Operating system deployment is not one of the seven workloads. Moving every slider to Intune does not retire task sequences, boot media or PXE, and it does not give Autopilot a device it has never seen. Treat provisioning as its own architecture decision.

Task-sequence OSD still earns its place for bare-metal builds of unregistered hardware, wipe-and-reload recovery, in-place refreshes that need drivers injected before Windows Setup, and rebuild rooms where a technician needs repeatable offline media. Autopilot is the better fit for user-driven provisioning of registered devices shipped straight to the user, where the Enrollment Status Page and Win32 apps carry the payload after Entra join.

The two coexist. Plenty of estates use Autopilot for new devices and keep a task sequence for recovery and repurposing. The decision to make is which rebuild jobs still need boot media, who owns drivers and BitLocker recovery for each path, and what evidence would let you retire the OSD path later.