Co-management Series “Merging the Perimeter” – Part 5: Enabling Co-management

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.

  1. Create Device collections for workloads and Intune Auto Enrollment
  2. Deep Diving Workloads
  3. Configure Co-management
  4. Review Client Logs
  5. Review Client Intune Status
  6. Review Client Co-management capabilities

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
Device Collections for each Co-management Workload in 1906

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
Workload Relationships

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.

Stop – Hammer Time!

You CAN move Resource Access Policy and Endpoint Protection workloads to Intune or Pilot Intune without moving Device Configuration.

Moving Resource Access Policies and Endpoint Protection Workloads independent of 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:-

Always apply this baseline even for co-managed clients

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.

Configuration Baselines deployed to each of the Workload Collections

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.

Enabling Co-management Lab

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.

Successful Intune MDM Enrollment using the Azure AD Device Credentials

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.

Intune MDM Enrollment Client Status

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

Lab Client Collection Membership

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

Co-management Capability values merged to 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:-

SCCM 1906 Co-management Capabilities Matrix

Summary

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:-

https://docs.microsoft.com/en-us/sccm/comanage/how-to-enable

In the next Part of our Series we will demonstrate how to switch individual workloads across to Intune

5/5 - (1 vote)

5 thoughts on “Co-management Series “Merging the Perimeter” – Part 5: Enabling Co-management”

  1. Pingback: Co-management Series "Merging the perimeter" - Part 1: What is Co-management?

  2. Pingback: Co-management Series "Merging the Perimeter" - Part 2: Paths to Co-management

  3. Pingback: Co-management Series "Merging the Perimeter" – Part 3: Co-management Prerequisites

  4. Pingback: Co-management Series “Merging the Perimeter” – Part 4: Configuring Hybrid Azure AD

  5. Pingback: Co-management Series “Merging the Perimeter” – Part 6: Switching Workloads to Intune

Leave a Comment

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.

 

This site uses Akismet to reduce spam. Learn how your comment data is processed.