In the previous post for this series, we looked at “What is Co-management?”. In this part of the series we will look at the different paths to co-management.
- Part 1: What is Co-management?
- Part 2: Paths to Co-management
- Part 3: Co-management Prerequisites
- Part 4: Configuring Hybrid Azure AD
- Part 5: Enabling Co-management
- Part 6: Switching Workloads to Intune
- Part 7: Co-management Capabilities
- Part 8: Monitoring Co-management
- Troubleshooting
Microsoft Edge stops receiving updates after the Windows Update workload is moved to Intune
Using MEMCM to fix legacy GPO settings that prevent co-managed clients getting updates from Intune
Office 365 updates stop working when workloads are switched to Intune
Paths to Co-management
What scenarios qualify us to consider Co-management in our environment? We mentioned this briefly in the introduction to the series. Let me ask the questions below:-
- Do you have existing SCCM clients and want to move some workloads to Intune?
- Do you have existing SCCM clients and want to just enroll the devices into Intune to get MDM features like device wipe, factory reset and remote control*?
- Do you have existing Internet based clients, managed by Intune and joined to Azure AD, and you want to install the SCCM client to have some workloads managed by SCCM?
- Do you want to install the SCCM client during an Autopilot enrollment and manage some workloads with SCCM?
If you have answered yes to either of the above, then you qualify!
*Remote Control requires Teamviewer

We can summarize the posed questions into two main categories or “Pathways”:-
1 . Existing Configuration Manager clients: You have Windows 10 devices that are already Configuration Manager clients. You set up hybrid Azure AD, and enroll them into Intune.
2 . Internet Enrolled Clients: You have new Windows 10 devices that join Azure AD and automatically enroll to Intune. You then install the Configuration Manager client to reach a co-management state.
One of the more common scenarios we encounter is pathway 1 “Existing Configuration Manager Clients” and this is where this series will focus.
Series Focus: Existing Configuration Manager clients
We can further split our chosen pathway for this series down into a further two categories

Existing SCCM managed devices that auto-enroll into Intune
This pathway, sees us taking an existing SCCM Client, performing a Hybrid Azure AD Join and then enrolling it into Intune
Modern Provisioning bootstrap SCCM agent
This pathway would be used during Autopilot. We take a device, perform a Hybrid Azure AD Join or Azure AD Join during the Autopilot process. We then enroll the client into Intune and install the SCCM client
Joining things up
The different pathways to co-management require our device identity to be registered in Azure AD (we talk more about this in Part 3 and 4 of this series). We can achieve this by either performing a Hybrid Azure AD Join for existing SCCM clients or an Azure AD Join for existing internet based clients. If the device identity is not present, we cannot enroll our devices into Intune to leverage Co-management. Remember, for Pathway 1, Co-management requires us to install the Intune agent and this occurs during the Intune enrollment process.
Summary
This was the shortest part in the series and I just wanted to make some distinctions between the different pathways to Co-management. We will talk more about the requirements for these pathways in Part 3 of the series “Prerequisites”
Pingback: Co-management Series "Merging the perimeter" - Part 1: What is Co-management?
Pingback: Co-management Series "Merging the Perimeter" – Part 3: Co-management Prerequisites
Pingback: Co-management Series “Merging the Perimeter” – Part 4: Configuring Hybrid Azure AD
Pingback: Co-management Series “Merging the Perimeter” – Part 5: Enabling Co-management
Pingback: Co-management Series “Merging the Perimeter” – Part 6: Switching Workloads to Intune