Co-management. What is it? What is it not? While there are plenty of blog posts on the how-to of enabling and moving workloads, I wanted to share my own journey of wrapping my brain around the ins-and-outs of the different co-management workloads and what they mean for administrators. I’ll be honest that when I first heard about “moving workloads to Intune” my first thought was “why would I cripple my ConfigMgr client by moving a workload like client applications to full time Intune?” As I came to learn and as you’ll come to see in this series, co-management really does live up to its prefix of “co(operative).”
Through the series I will cover each of the workloads individually, and I’ll add more as more workloads are enabled. This first post assumes that you are running ConfigMgr version 1910 or later and is going to cover Compliance Policies.
Frequently Asked Questions (FAQ)
Q: If I move the compliance policies workload to Intune, am I limited to
compliance policies built into Intune?
No. Both ConfigMgr and Intune compliance policies are summarized as part of an Intune compliance policy when configured for Require device compliance from Configuration Manager. Additionally, through the “Include custom configuration baselines as part of a compliance policy assessment” mechanism introduced in ConfigMgr version 1910 you gain the ability to include the results of assigned configuration baselines into consideration for Intune compliance.
Q: Can I use ConfigMgr compliance policies for Conditional Access?
Yes. While compliance policies will continue to evaluate in their respective platforms, the Intune client will gather the compliance status from a ConfigMgr client provided the compliance policy is configured for Require device compliance from Configuration Manager.
Q: What happens if I have overlapping policies?
If the overlapping policies return different results (one is complaint and the other non-compliant) the device will be marked as Not Compliant. In theory, this is only possible for custom configuration baselines being evaluated as part of a compliance policy assessment where the baseline was making remediating changes to the system that are different than the Intune compliance policy.
What Happens When I Move the Slider?
ConfigMgr instructs the client that Intune should now be allowed to evaluate Intune compliance policies on the workstation. However, this doesn’t mean that you necessarily lose the functionality of ConfigMgr in favor of Intune if you move the slider toward Intune, as I noted in the FAQ.
Client Side Changes
After enabling the workload for a collection or for all systems, any co-managed devices upon their next machine policy refresh will update their co-management configuration to enable the workload. You can see this happen in the CoManagementHandler log.
How do we know that “merging workload flags 3” is enabling the Compliance Policies workload? Well this goes back to something I talked about in a previous blog – bitwise operators. In short, the idea is you want to store a set of “on/off” values in a single parameter/value (imagine a row of light switches). The nice thing about binary math is that each bit has a unique value, so a value of 1, 2, 4, 8, 16… can never be replicated by a combination of the other bits (e.g. 1 + 2 can never equal 4). If each of our “light-switches” is represented by a bit, then we can create a unique value for each conceivable combination of switch states by adding different combinations of bits together.
Ben Whitmore has a great blog post outlining the capability matrix for co-management features. I’ve recreated the table here for brevity.
|Capability (Bit Value)||Workload|
|1 (0x00000001)||Co-Management Enabled (Not a workload)|
|2 (0x00000010)||Compliance Policies|
|4 (0x00000100)||Resource access Policies|
|8 (0x00001000)||Device Configuration|
|16 (0x00010000)||Windows Update Policies|
|32 (0x00100000)||Endpoint Protection|
|64 (0x01000000)||Client Apps|
|128 (0x1000000)||Office Click-to-Run Apps|
To enable a workload we always have to enable co-management, so effectively enabling the Compliance Policies workload (2^1 – 0x00000010) would also involve the Co-Management Enabled flag (2^0 - 0x00000001). By adding these two values together we get a value of 3 (I am good at math) – this gets just a tiny bit more complicated when you have multiple values, but Ben covers that in his post.
ConfigMgr Side Changes
In your ConfigMgr console under Monitoring > Co-management you should see some devices enabled for compliance policy workloads after the dashboard summarizes:
Additionally, in WMI under the SMS_Client_ComanagementState class, the device(s) in question should reflect the new workloads under the MDMWorkloads property:
Intune/Microsoft Endpoint Manager Admin Center Changes
One notable change in the MEMAC is that the device should now show a state for compliance evaluation, rather than “See ConfigMgr”
The reason for this is obvious – Intune is now the authority for compliance policies rather than ConfigMgr!
While the following is not a change after enabling the workload per-se, it’s important to note that you have the ability to use ConfigMgr compliance as a setting for your compliance policies in Intune.
By requiring device compliance from ConfigMgr, you are telling Intune to gather the ConfigMgr compliance state from the workstation and use that to measure compliance in addition to any other compliance settings you enable in the Intune policy. There is a special consideration with configuration baselines however, that I have listed in the “What Do I Need to Consider” section.
What Do I Lose?
If you choose to enable the ConfigMgr Compliance requirement in your Intune compliance policies, you do lose the single pane of glass for managing compliance as you now have two locations which could potentially affect Intune compliance. However, it is easy to determine which platform is causing the failure as the Intune device compliance pane will tell you:
As you can see though, Intune will only tell you whether or not the ConfigMgr client has deemed itself “Compliant” but will not tell you the specifics of what is “Not Compliant” if any of your ConfigMgr configuration baselines or compliance policies fail. So, you may still have two separate locations to check when determining why a device is “Not Compliant.”
What Do I Gain?
First and foremost, you gain the ability to use ConfigMgr compliance policies and configuration baselines as a condition for Conditional Access policies in Azure Active Directory! You’re no longer limited by what is available in Intune to determine device compliance. Want to create a script that detects if a user left their cd tray open (old school) and kick them out of Office 365? Go for it!
You also gain notifications! If a device falls out of compliance with your ConfigMgr configuration baselines, you can send an e-mail directly to the user of that device to let them know:
What Do I Need to Consider?
There are relatively few considerations for this workload in my opinion – it’s a fairly straightforward and easy win for your environment.
As noted in the docs, if you wish to use custom configuration baselines as part of a compliance policy assessment, you need to:
Create a ConfigMgr compliance policy deployed to a user collection containing co-managed users that includes the rule Include configured baselines in compliance policy assessment.
Enable your custom configuration baselines for evaluation by ticking the Evaluate this baseline as part of compliance policy assessment checkbox on the baseline.
Martin Bengtsson mentions in his blog post that there are timing considerations for evaluation of configuration baselines and compliance policies. The short answer is, you want to make sure your configuration baseline evaluates before the compliance policy containing the Include configured baselines in compliance policy assessment rule. I personally think this is simply solved by running the compliance policy more frequently than your configuration baselines are run, although he suggests running the compliance policy on a less frequent basis. However often you choose to evaluate your policies, just know that the compliance policy will not be marked as non-compliant until it runs after a configuration baseline has been marked non-compliant and therefore your device may not be marked as non-compliant in Intune immediately.
I hope this has given you some insight on whether it would be beneficial to “move” this workload to Intune – moreso, I hope that you can see that you’re not necessarily “moving” anything… you’re really just gaining additional functionality!