Device configuration workload for MDM policy and SCCM co-management

In this post I will be discussing on device configuration workload and its impact to target the policies via Intune, Group Policy and SCCM policies. Device configuration workload is responsible for applying the MDM policies via Intune for Microsoft Entra hybrid joined devices when SCCM client is installed along with Co-management settings enabled.

What is Device Configuration workload

When Configuration Manager is configured to use co-management, it allows the organizations to switch various workloads. These workloads help organizations to do a smooth migration / transition from on-premises infrastructure to Intune.

These workloads are part of Co-management configuration which can be verified by launching Configuration manager console and navigating to \Administration\Overview\Cloud Services\Cloud Attach. Click on the properties and go to Workloads tab. It will show list of all workloads including Device configuration. If each workload is switched to Pilot Intune, it allows us to specify collection for each by clicking on Staging tab.

Keep in mind the 2 workloads Endpoint Protection and Resource access policies are part of device configuration workload. What it means? If the workload for Device configuration workload is switched from Configuration Manager to Pilot Intune, other two workloads will also shift towards Pilot Intune. However, if you have set the separate collection for each workload (in staging tab), you can separate the impact of these other workloads and can just apply Device configuration workload to the device.

As this post is more about discussion on Device configuration, we will just focus on this topic.

Question: What will happen when a device is added to the specific collection associated with Device configuration workload?

You can deploy the Configuration profiles (or we can say MDM policies via Intune). Does it mean only Intune policies are going to be applied? No

As the devices will be domain joined with co-management enabled, we can have flexibility to apply the policies from both the worlds. The device will still get the group policy applied along with MDM policies targeted via Intune.

How to verify if Device configuration workload is applied correctly

You can verify this either via Intune console or on device itself. The easiest way would be to logon to Microsoft Intune admin center > Devices, search for the device and click on it. With Overview option selected, look for Intune managed workloads which will be last option, it will show you all the workloads applied for that specific device. We can see the Device Configuration is listed along with other workloads.

On client side, we can check the workload is applied by going to Configuration Manager Properties and click on Configurations tab. This will show all the assigned configuration baselines including list of all workloads applied. We can see the CoMgmtSettingsPilotDC listed which is an indication of Device configuration workload applied correctly.

What if there is contradicting policies applied to device via Intune vs Group Policy?

If there is a setting in group policy which enables something, while Intune policy is trying to disable it. Which policy is going to win? In ideal scenario, Group policy will win. However, we can change this behaviour by using Policy CSP – ControlPolicyConflict. If we deploy this MDM policy to device, it will override the group policies. The setting name is MDMWinsOverGP. OMA-URI for the policy is ./Device/Vendor/MSFT/Policy/Config/ControlPolicyConflict/MDMWinsOverGP.

For more details check how to resolve Intune and group policy conflict.

The policy can be easily created via Intune portal by creating a device configuration using settings catalog with the category to choose as Control Policy Conflict > MDM Wins Over GP with the value “The MDM policy is used and the GP policy is blocked”

With usage of MDMWinsOverGP, will MDM policy override all group policy?

No, MDMWinsOverGP will only override GPO when the MDM policy is part of Policy CSP. In other words, MDM policies consist of various Configuration service providers (CSPs) and Policy CSP is one of them. There are other CSP’s as well such as AppLocker CSP, BitLocker CSP, CloudDesktop CSP, LAPS CSP, NetworkProxy CSP and others. Check the Policy CSP areas to get complete details on it.

Even though Policy CSP consists of lots of policies, it doesn’t cover all areas of other CSP’s. If you are creating MDM policies from other CSP area, it won’t override the group policy and GPO will always win.

There is another limitation for MDMWinsOverGP (Control Policy Conflict). It doesn’t override the Update Policy CSP and Defender CSP. The latter one we under, it is a separate CSP (Defender CSP), hence it doesn’t qualify to be overwritten by MDMWinsOverGP.

However, Update Policy CSP is part of Policy CSP, but still MDMWinsOverGP will not override this policy. This means, any update policy set via Group Policy will always takes the precedence and MDM policy won’t be able to override it.

To explain this, one of the example is: If you have a group policy for Specify source service for the following classes of Windows updates set to Windows Update and Windows Server Update services for few of the class:

• Feature Updates: Windows Server Update Services
• Quality Updates: Windows Update
• Driver Updates: Windows Server Update Services
• Other Updates: Windows Server Update Services

Now, you are trying to enable Feature Update to start utilizing Windows Update. And you created MDM policy to override Feature Update with the setting:
Set Policy Driven Update Source For Feature Updates: Detect, download and deploy Feature Updates from Windows Update

Ideally, we might expect Policy CSP should honour the MDMWinsOverGP and Intune policy to apply, however because of the exception I explained earlier that Update policy even though part of Policy CSP won’t honour the MDM policy and Group policy will still apply.

In few scenarios, I have found the missing keys for these values if there are having contradicting values, and that might be happening because of 2 authorities trying to make the changes, resolving conflict at the same time. There is so much happening on the device because of these 2 authorities.

Hence, I would highly recommend not to have any kind of conflicting policies (specifically Update Policy) targeted via Intune if there are policies set via Group Policy.

SCCM Policy

SCCM policies are considered as local policies. These policies will always be overwritten by Group policies if there is any conflict settings. Setting up software update point (SUP role) points to a specific WSUS server. This policy is applied via SCCM, hence treated as local policy. In the event, if there is no group policy, eventually SCCM policy will apply to set the WSUS server.

MDMWinsOverGP (Control Policy Conflict) still needs to be taken into consideration for local policy. Update Policy will still be the exception, hence, SCCM policy will always takes the precedence specifically related to update policies. For all other policies, the behaviour remains the same as explained previously.

To summarize what we discussed in this post, here are the points to remember:

• Device configuration workloads allows the device to get the policies targeted via Intune.
• Microsoft Entra hybrid joined devices will still get the policies from Group Policy even though added to Device Configuration workload.
• By default Group policy takes the precedence of MDM policy.
• Deploy MDMWinsOverGP (Control Policy Conflict CSP) to block Group policy so as MDM policy takes the precedence.
• MDMWinsOverGP only applies for Policy CSP area, hence for any other CSP area there won’t be any changes and Group policy will always win.
• MDMWinsOverGP doesn’t apply MDM policy for Update Policy CSP, this is an exception which always needs to be taken care of.