Operations keeps Configuration Manager for on-premises workloads while piloting Intune for cloud-managed PCs. What is the purpose of co-management in that modernization path?
Select an answer to reveal the explanation.
Short Explanation
Modernization is a bridge, not a cliff. Co-management lets ConfigMgr keep covering on-premises workloads while Intune pilots grow. That's the purpose—not wiping tenants or bolting AI Foundry onto every enrollment.
Full Explanation
Operations keeping Configuration Manager for on-premises workloads while piloting Intune for cloud-managed PCs should understand that co-management’s purpose is to bridge Configuration Manager and Intune so both can participate while the estate modernizes. Co-management is the gradual on-ramp: municipalities keep ConfigMgr where it still earns its keep and shift selected workloads to Intune without a politically impossible overnight rip-and-replace.
Deleting Entra ID tenants whenever ConfigMgr clients check in fails catastrophically and has nothing to do with co-management. Forcing every workload onto Azure AI Foundry before any PC can enroll invents an unrelated AI prerequisite. Replacing Teams collaboration with ConfigMgr software center chat rooms fails both management and collaboration design.
Exam caveat: co-management means ConfigMgr and Intune work together during modernization—not that Cloud PCs alone replace every server role overnight, and not that Teams Phone or Loop uninstalls site servers.
Operational check: enable co-management for a pilot collection, choose early workloads to move to Intune (for example compliance or update policies), communicate the bridge strategy to ConfigMgr-centric admins, keep AI Foundry myths out of the plan, and measure success by stable dual management—not by deleting identity.