Flip a Co-Management Workload to Intune Too Early and the Policy Gap Is Invisible

A team migrating off ConfigMgr flips the Windows Update policies slider to Pilot Intune for a test collection, on the assumption that "Intune will just take over update management." It doesn't. There's no Windows Update ring assigned to that collection in Intune yet — nobody has built one. For three weeks, those pilot devices receive no deferral policy from either side: ConfigMgr stopped applying its Windows Update client settings the moment the slider moved, and Intune has nothing configured to replace it. No error, no alert, no compliance flag. The devices just quietly update on Microsoft's default cadence instead of the org's, until someone notices patch Tuesday landed on the wrong day for that group.

This is the single most common co-management mistake, and it's dangerous specifically because it produces no failure signal. This post explains what co-management actually is, how the seven switchable workloads work, why switching one before its Intune-side policy exists creates a silent gap rather than an error, how to check who really owns a workload for a given device right now, and how to switch a workload safely — plus a read-only PowerShell script that reports co-management authority state across your fleet using Microsoft Graph.

The problem — a workload switch with nothing behind it on the Intune side

Co-management means a single Windows device is managed by both Configuration Manager and Microsoft Intune at the same time. That's not a transition state — it's a real, ongoing configuration. The Configuration Manager client stays installed and talking to its site. The device is also MDM-enrolled into Intune. Both agents are active simultaneously, and Microsoft's own documentation is explicit that when this happens, "Configuration Manager and Intune balance the workloads to make sure there are no conflicts" — but only for the workloads that actually exist on both sides.

The balancing act works per workload, not per device. Seven workloads can each be individually pointed at ConfigMgr or Intune:

• Compliance policies
• Device configuration
• Endpoint Protection
• Resource access policies
• Client apps
• Office Click-to-Run apps
• Windows Update policies

Every workload you don't switch keeps being managed by Configuration Manager, exactly as before. That part is safe by design. The danger shows up on the other side of the switch: moving a workload's authority to Intune tells the ConfigMgr client to stop applying its side of that workload for the affected devices. It does not check, and cannot check, whether an equivalent Intune policy exists to pick up the slack. If nothing has been configured on the Intune side, that workload simply goes unmanaged for those devices, with no warning from either console.

Why it happens — workload authority is a slider, not a migration wizard

It helps to be precise about what "switching a workload" actually is under the hood. Each of the seven workloads has a slider in the Configuration Manager console (or a policy set in Intune, for pilot groups) with three positions: Configuration Manager, Pilot Intune, and Intune. This slider is a routing instruction, not a content transfer. It tells the co-management client agent which side's policy engine gets to apply settings for that workload on the devices in scope. It does not copy, translate, or validate that a matching policy exists on the destination side.

This is why a workload switch behaves completely differently depending on which one you flip:

• Endpoint Protection is comparatively forgiving. Microsoft's documentation notes that "the Configuration Manager policies stay on the device until the Intune policies overwrite them" — so there's a grace period where the old protection settings remain in force while you get Intune's antivirus policy assigned.
• Windows Update policies and Device configuration are not forgiving in the same way. There's no equivalent "old settings linger" behaviour documented for these — the ConfigMgr client setting for software updates has to be manually adjusted after the fact, and until it is, the workload can be in a genuinely ambiguous state.
• Device configuration is the one with the widest blast radius: switching it also moves the Resource access and Endpoint Protection workloads along with it, whether or not you intended to touch those two.

The mental model that trips people up is thinking of the switch as "migrating" a policy. It isn't. It's closer to unplugging one wire and expecting the other wire to already be plugged in. If it isn't, nothing catches that for you — not the console, not a compliance policy, not an alert. The device simply stops receiving instructions for that workload from ConfigMgr, and Intune has nothing assigned to send instead.

The remaining three workloads have their own quirks worth knowing before you touch a slider:

• Compliance policies feed Conditional Access directly. If you switch this workload to Intune before an Intune compliance policy is assigned to the same devices, they can fall out of scope for compliance evaluation entirely — not "noncompliant," just absent from the check, which is easy to miss in a Conditional Access sign-in log unless you're specifically looking for it.
• Office Click-to-Run apps has an extra dependency most people don't expect: a global condition named Microsoft 365 apps managed by Microsoft Intune (or, on older ConfigMgr versions, Are Office 365 applications managed by Intune on the device) is added automatically as a requirement on new Microsoft 365 app deployments. The moment you switch this workload, co-managed clients stop meeting that requirement and no longer install Microsoft 365 apps deployed from ConfigMgr — whether or not an Intune-side Microsoft 365 Apps assignment exists yet to replace it.
• Client apps is the one workload where PowerShell scripts are explicitly exempted from the switch's effect — on Windows 10 version 1903 and later, PowerShell scripts deployed from Intune still run on co-managed devices even if the Client apps slider hasn't been switched. Everything else in that workload (Win32 apps, winget-based Store apps) follows the normal rule: no authority, no delivery.

How to verify — check who actually owns a workload before you touch anything

Before switching, or when troubleshooting a device that seems to be missing a policy it should have, confirm which authority is really in effect. There are two places to look, and they answer slightly different questions.

In the ConfigMgr console, the co-management dashboard (Cloud Services > Co-management > the co-management dashboard tile) shows the current slider position for each workload at the collection level — this tells you the intended configuration.

On the device itself, the ConfigMgr client's own eligibility state is the ground truth. Run this from an elevated PowerShell session on the device, or against it remotely with CIM:

This returns one flag per workload, and the value tells you whether that specific device currently has the workload's authority set to Intune — independent of what the collection-level slider in the console says it should be, which matters because policy evaluation can lag behind a slider change by one client policy cycle.

For a fleet-wide view rather than one device at a time, Microsoft Graph exposes co-management-relevant fields on the managed device record itself, which is what the companion script in this post reads. Two fields matter most:

• managementAgent — confirms the device is genuinely co-managed at all. The values configurationManagerClientMdm and configurationManagerClientMdmEas mean ConfigMgr client and Intune MDM are both active on that device; anything else means it isn't co-managed, and workload sliders are irrelevant to it.
• configurationManagerClientEnabledFeatures — a set of boolean flags (inventory, modernApps, resourceAccess, deviceConfiguration, compliancePolicy, windowsUpdateForBusiness) reported per device.

The fix — switch a workload only after its Intune-side policy exists and is assigned

The safe order is always the same regardless of which workload you're moving: build and assign the Intune-side equivalent first, verify it lands on a pilot device, and only then move the collection-wide slider.

Step 1 — Build the Intune-side policy before touching the slider

Step 2 — Confirm the Intune policy actually applied to at least one pilot device

Step 3 — Only now, move the workload slider

It's also worth being clear about who is even eligible for this dance in the first place, since a surprising number of "co-management isn't working" tickets turn out to be a device that was never eligible to begin with. Microsoft's prerequisites require Microsoft Entra ID P1 or P2 licensing (an EMS subscription covers this plus Intune), at least one Intune license assigned to the administrator account used to sign in, a supported Configuration Manager current branch version, and — critically — the device itself must be either Microsoft Entra hybrid joined or Microsoft Entra joined. A device that's only Microsoft Entra registered (sometimes called workplace-joined) is not supported for co-management at all, full stop, regardless of what the workload sliders say.

Proof it worked — check authority state across the fleet, not just one device

A single manual spot-check tells you about one device. What you actually need after a workload switch is a fleet-wide before-and-after comparison, so you can catch devices that are co-managed but aren't picking up the new authority the way you expect. That's what the companion script below is for — it's read-only, connects to Microsoft Graph, and reports the co-management-relevant fields for every managed Windows device (or a filtered subset) in one pass.

References

• Co-management for Windows devices — Microsoft Learn
• Co-management workloads — Microsoft Learn
• Paths to co-management — Microsoft Learn
• managedDevice resource type — Microsoft Graph v1.0
• managementAgentType enum — Microsoft Graph v1.0