Intune Policy Conflicts

Introduction

When dealing with day-to-day Intune activities, setting up and maintaining profiles are standard activities. Dealing with Policy Conflicts is also part of everyday activities. You will hopefully not get to deal with them every day, but every once in a while. Or maybe it is when too many admins try to set up policies. This article looks at some of the basics of Intune Policy Conflicts and how you can avoid them for smoother policy implementation and maintenance.

What will I be discussing? 👇🏽

1. What is the Root Cause of a Conflict?
2. CSP – Configueration Service Provider
3. A Real-life Example
4. Few Tips to Avoid Policy Conflicts
5. Drill in to identify and resolve conflicts
6. Policy Refresh Cycles
7. Microsoft Graph Help
8. Check For Assignment Failures
9. Wrapping Up

What is the Root Cause of a Conflict?

To start with, you may apply a Configuration Profile or a Security Policy using Intune to a set of users or devices. You may later realize that the policies haven’t been or maybe some settings in the policy haven’t been acquired by the device. The main reason behind this is (as you know) that the same policy setting has been applied with a different option to the same device.

Configueration Service Provider (CSP)

When you talk about Intune policies, you have to talk about the CSPs. This is where the Intune Settings are coming from. The issue is? Most of the setting wordings look the same, but they connect to the same Intune CSP (Configuration Service Provider), which then sends that signal to the correlating setting in the device, thus the root cause for a conflict.

I took the liberty of asking ChatGPT about CSPs and how does it work. I got the answer below.

The backend of an Intune policy setting is a Configuration Service Provider (CSP). A CSP is a component of the Windows operating system that provides a unified way to configure settings and policies on Windows devices.

CSPs work by exposing a set of configuration settings that can be managed using the OMA-DM protocol. Intune uses the OMA-DM protocol to communicate with the CSP and apply the settings and policies to the devices.

When you create an Intune policy, you select the CSPs that it should use to apply settings to the devices. You can then specify the settings and values that should be applied to each device using the CSP.

Example. How a backend CSP might work?

Here’s an example of how a backend CSP might work.

Let’s say you want to configure the lock screen image on Windows 10 devices using Intune. You create a policy in Intune and select the Personalization CSP, which contains the settings for the lock screen image.

Within the Personalization CSP, you specify the setting for the lock screen image by setting the value of the “LockScreenImage” setting to the URL of the image you want to use.

When you assign the policy to devices in Intune, the OMA-DM protocol is used to communicate with the Personalization CSP on each device. The CSP applies the settings specified in the policy to the device, including the lock screen image specified in the “LockScreenImage” setting.

Overall, the backend of an Intune policy setting is a CSP, which provides a standard way to configure settings and policies on Windows devices. Intune uses the OMA-DM protocol to communicate with the CSP and apply the settings to the devices.

~ ChatGPT

More on Policy CSP - https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-configuration-service-provider?WT.mc_id=EM-MVP-5004964

From Microsoft Text

Conflicts happen when two profile settings are the same. For example, you configured two MAM policies that are identical except for the copy/paste setting. In this scenario, the copy/paste setting is set to the most restrictive value. The rest of the settings apply as configured.

A policy is deployed to the app and takes effect. A second policy is deployed. In this scenario, the first policy takes precedence and stays applied. The second policy shows a conflict. If both are applied at the same time, meaning that there isn’t a preceding policy, then both are in conflict. Any conflicting settings are set to the most restrictive values.

Compliance and device configuration policies that conflict

When two or more policies are assigned to the same user or device, then the setting that’s applied happens at the individual setting level:

Compliance policy settings always have precedence over configuration profile settings.

If a compliance policy evaluates against the same setting in another compliance policy, then the most restrictive compliance policy setting applies.

If a configuration policy setting conflicts with a setting in another configuration policy, this conflict is shown in Intune. Manually resolve these conflicts.

• https://learn.microsoft.com/en-us/mem/intune/configuration/device-profile-troubleshoot#compliance-and-device-configuration-policies-that-conflict

A Real-life Example

Now that you have an idea of the CSPs and how it works, let’s walk through a quick example related to Defender SmartScreen.

Take the policy setting in the Security Baseline policy under SmartScreen – Turn on Windows SmartScreen (Yes/ Not Configured)

And look at the setting in Settings Catalog for SmartScreen Enable SmartScreen in Shell (Disable/ Enable)

Now, they both talk to the same CSP EnableSmartScreenInShell. The CSP path is as

./Vendor/MSFT/Policy/Config/SmartScreen/EnableSmartScreenInShell

If I turn both policies with contradictory switches, that will lead to a conflict. Very easy to understand.

Below is something I wrote some time ago related to Defender SmartScreen, and I discussed how different settings point to the same CSP from the backend.

Now that we explored how and why a policy conflict will occur let’s see how to avoid them and some proactive ways of staying on top of the policies.

Few Tips to Avoid Policy Conflicts

These are some of my insights from the field and what Microsoft has mentioned in their documentation.

• Test before applying a policy on a scale

  This is self-explanatory due to many facts. Chances are you may apply policies with similar settings with contradictory options selected for a big batch of devices. Policy sync will take time, and if a conflict happens, the rollback will take time too. If you have a test environment, it is best to test the solution beforehand.

• Understanding the end goal

  It is easy to create policies and switch the settings Enabled or Disabled, given the scenario, but determining the end goal will make the policy assignment much easier. You may just want to set up the Endpoint Protection settings, and if you are creating a Baseline Security profile, make sure you set the Endpoint Protection-related settings to Not Configured or visa-versa.

• Not using different Baselines.

  This is a big one. If you have a good strategy of what Security Baseline profile the machine will get, it is OK to have different profiles. Ideally, you may have a stringent profile as the primary and more relaxed profile for a different set of devices. As long as you don’t mix them up, the conflicts won’t take place. However, if you don’t have a clear profile delineation, it’s best to stick with one Baseline Security Profile. This requires planning and collaboration with your IT team and proper documentation afterward.

• Custom iOS/iPadOS or macOS policies that conflict

  When you assign a custom policy, confirm that the configured settings don’t conflict with compliance, configuration, or other custom policies. If a custom policy and its settings conflict, then the settings are applied randomly by Apple.

Drill in to identify and resolve conflicts

1. While viewing the Device configuration report for a device, select a policy to drill in to learn more about the issue that results in a conflict or error status. When you drill in, Intune displays a list of settings for that policy that includes each setting that wasn’t set as Not configured and the status of that setting.
2. To view details about a specific setting, select it to open the Settings details pane. In this pane, you’ll see.
   • Setting: The name of the setting.
   • State: The status of the setting on the device.
   • Source Profiles: A list of each conflicting profile that configures the same setting but with a different value.
3. To reconfigure conflicting profiles, select a record from the Source Profile list to open Overview for that profile. Select the profile Properties, and you can then review and edit the settings in that profile to remove the conflict.

https://learn.microsoft.com/en-us/mem/intune/protect/security-baselines-monitor#drill-in-to-identify-and-resolve-conflicts

Policy Refresh Cycles

The policy refresh cycle determines any changes to be acquired by the device.

At any time, users can open the Company Portal app, Devices > Check Status or Settings > Sync to immediately check for policy or profile updates.

If devices are recently enrolled, then compliance, non-compliance, and configuration check-in runs more frequently. The check-ins are estimated at.

Microsoft Graph Help

As always, Microsoft Graph may come in handy. The beta version has some nice features that, in my opinion, need more improvements. You can use the method deviceConfiguerationConflictSummary to understand the Configuration Profile Conflicts.

What I didn’t see here were the Security Profile conflicts. Even though I had an intentional conflict in understanding the Graph behavior, it didn’t appear.

One more thing I noticed was that the results took a few hours to appear. It is understandable, as this can be due to worker cycles or a beta version that the engineers are still working on.

The HTTP request can be found below.

https://graph.microsoft.com/beta/deviceManagement/deviceConfigurationConflictSummary

Permissions Required

https://learn.microsoft.com/en-us/graph/api/intune-deviceconfig-deviceconfigurationconflictsummary-get?view=graph-rest-beta

Or use the Graph API Powershell module to run the below command

Get-MgDeviceManagementDeviceConfigurationConflictSummary | ForEach-Object ConflictingDeviceConfigurations

https://learn.microsoft.com/en-us/powershell/microsoftgraph/get-started?view=graph-powershell-1.0

Check For Assignment Failures

The Intune portal now has a separate section just for assignment failures. It can be a profile application error or a conflict. You can see some useful information such as the device count, platform, profile source, profile name, etc. This can come in handy when you need to resolve issues quickly rather than jumping on to the policies separately and looking for the devices and individual policy settings.

Intune RBAC to read the reports

To get to the location

Intune Portal > Endpoint security > Assignment failures OR Intune Portal > Devices (Overview) > Configuration profile status

OR if you are using the current Intune devices UI, go to devices > Monitor > Assignment Failures.

When you drill down further on the policy that conflicts with, you will see the devices and the UPNs

Click further on a device to understand the policy that conflicts.

**When a Device Configuration profile and a Settings Catalog Profile conflict, it won’t list the conflicting profiles at the moment.

Now, you can start looking at the conflicting profiles, check the settings, and fix the issue.

Wrapping Up

This is a much-needed report that can help you pinpoint the policies and their conflicting settings straightaway.

What I like to see is the Graph API to give information about any policy conflict including Security Profiles as well. In this way, you can add the HTTP request into a Power Automate Flow or create the Graph API Powershell module into a Logic App to give you a report every morning.

In closing, understanding the policies, the best scenario to use them, and understanding the settings are important when it comes to efficient device management which in return will give you some peace of mind that the devices have successfully acquired the policies.