In this part of the series we will look at enabling Co-management. We will split this part of the series into 6 sections for easy navigation.
- 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:-
- Create Device collections for workloads and Intune Auto Enrollment
- Deep Diving Workloads
- Configure Co-management
- Review Client Logs
- Review Client Intune Status
- Review Client Co-management capabilities
- Part 6: Switching Workloads to Intune
- Part 7: Co-management Capabilities
- Part 8: Monitoring Co-management
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
1. Create Device collections for workloads and Intune Auto Enrollment ⏏
Before 1906, we only had a single collection we could use to pilot all co-management workloads. Now we can assign a different collection to each of the 7 workloads making it easier to transition workloads to Intune for different groups of devices.
In our lab for this series, we created the following Collections:-
- Co-mgmt – Client Apps
- Co-mgmt – Compliance Policies
- Co-mgmt – Device Configuration
- Co-mgmt – Endpoint Protection
- Co-mgmt – Office Click-to-Run apps
- Co-mgmt – Resource Access Policies
- Co-mgmt – Windows Update Policies
and we also created a collection for Intune Auto Enrollment
- Co-mgmt – Intune Auto Enrollment
2. Deep Diving Workloads ⏏
Collections are a great way to move workloads to Intune. When we move a workload to Intune or Pilot Intune, we are essentially saying ONLY the Intune agent can handle that workload and the SCCM client/agent should not apply any setting that falls into scope for that workload. We have to caveat this behaviour for some workloads..lets do that now.
One thing to be wary of is the relationship between the following Workloads
- Device Configuration
- Resource Access Policies
- Endpoint Protection
As you can see in the graphic above, Endpoint Protection and Resource Access Policies are subordinate to Device Configuration. This means if we move the Device Configuration workload to Intune or Pilot Intune, both Endpoint Protection and Resource Access Policy workloads will also move. You also cannot move Resource Access Policy or Endpoint Protection workloads back to SCCM while Device Configuration is set to Pilot Intune or Intune.
You CAN move Resource Access Policy and Endpoint Protection workloads to Intune or Pilot Intune without moving Device Configuration.
We can add another caveat to the Device Configuration Workload. You can still allow Configuration Baselines to be evaluated when the workload for the client is set to Pilot Intune or Intune, you just need to select the following box on the baseline:-
Another workload which bucks the normal behaviour is Client apps. When we move the workload to Intune or Pilot Intune we are enabling apps to be deployed from Intune AS WELL AS SCCM. We will demonstrate this later on in Part 6 of the series “Switching Workloads to Intune”
How are Workload assignments changing the configuration on the Clients?
When we assign a workload to a client we are effectively applying a Configuration Baseline. The Baseline is deployed to the collections and ultimately clients that we assign to each of the workloads in Co-management settings.
3. Configure Co-management ⏏
Now that we have created the collections for our workloads and Intune Auto Enrollment Pilot group, we are ready to enable co-management.
4. Review Client Logs ⏏
Once Co-management has been enabled our clients need to be enrolled into Intune before workloads will move. Let’s review the client logs to understand what is going on during Intune enrollment.
5. Review Client Intune Status ⏏
When we look at the log file above we can see the device enrolled with the device credentials and not the user credentials. This is an improvement introduced in SCCM 1906. Previously, MDM enrollment could not happen until an Intune licenced user logged on to the client. Now, the device enrolls to Intune without waiting for a licenced user. The first licenced user who logs into the device becomes the owner.
In the following lab we will review how you can determine a successful Intune MDM enrollment.
6. Review Client Co-management capabilities ⏏
As we enroll our clients into Intune we can get an idea from the CoManagementHandler.log what the Co-management capabilities are. We will go into a lot more detail about capabilities in the next part of the series but for now lets review the logs to get a better understanding of “Capabilities”.
Earlier on we talked about “Workloads”. Each time a client is added to one of our Workload collections and performs a subsequent policy refresh it receives new capabilities. In our lab above you may have noticed in the CoManagamentHandler.log that the capabilities value was set to 3. What is this number?
Our Windows 10 lab clients were in both the “CoMgmt – Intune Auto Enrollment” and “CoMgmt – Compliancy Policies” collections. Lets have another look at that
When Co-management is enabled for a device, the device gets a capabilities value of 1. The capabilities value of 2 is given to the client for the Compliance Policies workload. 2 + 1 = 3
We go into a lot more detail on capabilities in Part 7 of this series.
I have also published a separate post outside of this series on Co-management capabilities here:-
In this part of the series we discussed Enabling Co-management. We also looked in more detail at the Workloads concept. More reading can be found for enabling co-management here:-
In the next Part of our Series we will demonstrate how to switch individual workloads across to Intune