Forum Discussion
co-managed Working flow
Hi SCCM Expert,
I would like to understand how co-management works in a multi-tenant scenario.
Currently, my SCCM environment manages devices from two different domains:
- abc.com → Integrated with ABC Intune Tenant
- xyz.com → Integrated with XYZ Intune Tenant
To enable co-management, we configured the Cloud Attach/Co-Management settings in SCCM using a Global Administrator account from the abc.com tenant. We then created a pilot collection and added devices from both abc.com and xyz.com domains.
My questions are:
- Since co-management was configured using credentials from the abc.com tenant, how can devices belonging to the xyz.com tenant successfully become co-managed and receive Intune workloads from their respective tenant?
- During the co-management enrollment process, what determines which Intune tenant a device enrolls into?
- Is the SCCM co-management configuration tied to the tenant used during setup, or does the device use its own Azure AD/Entra ID registration information to identify the target tenant?
- What is the actual trigger point for the transition from SCCM management to co-management/Intune enrollment?
- If devices from multiple tenants exist in the same SCCM hierarchy, how does SCCM ensure that each device is enrolled into the correct Intune tenant?
Could you please help clarify the architecture and enrollment flow in this scenario?
1 Reply
The short version, as far as I understand it: co-management is tied to one Entra tenant per Configuration Manager hierarchy, not to each device's domain. So the setup you describe, with two tenants against one hierarchy, will not give each domain its own tenant.
To your questions:
- Which tenant is used. The tenant is whichever one you configured under Cloud Attach / Azure Services (the abc.com Global Admin you used). The hierarchy talks to that one tenant for co-management and for the automatic Intune enrollment it triggers.
- What a device needs. For a domain-joined device to enroll, it must be hybrid joined to that same tenant (it has to show up in that tenant's Entra devices, which depends on which Entra Connect syncs that domain). Devices from xyz.com are joined to or synced with the XYZ tenant, so they do not match the abc.com tenant and will not enroll into it correctly, or they will fail the enrollment.
- The trigger. The transition starts when the device is in a collection that has the co-management client setting enabled, it is hybrid joined to the tenant, the user is in the MDM user scope with an Intune licence, and the automatic enrollment setting is on. Then the Configuration Manager client starts the Intune enrollment and the workload sliders decide who manages what.
- Multiple tenants in one hierarchy. There is no mapping that sends each device to a different tenant. The usual options are a separate Configuration Manager hierarchy or site per tenant, or leave those xyz.com devices out of co-management and enroll them in the XYZ tenant directly with Intune.
Check the CoManagementHandler.log and the enrollment results on a pilot xyz.com device, and the Entra device list of each tenant, and you will see where they land. Test the plan on a small pilot collection first.
