An Intune Settings Catalog conflict is rarely a random endpoint problem. It usually means two management paths are trying to write different values to the same Windows setting, or the setting does not apply to the device that received it. The symptom is familiar: the policy looks assigned, the device is checking in, but the status sits at Conflict, Error, or Not applicable while the service desk waits for a fix.
This guide gives desktop engineers and Intune admins a practical workflow for fixing Settings Catalog policy conflicts without wiping devices or rewriting every baseline. It focuses on Windows devices, Microsoft Intune reporting, assignment scope, CSP support, and duplicate configuration paths.
Why Settings Catalog Conflicts Happen
Microsoft’s Intune documentation defines a conflict as a condition where an existing setting on the device cannot be overwritten, or where two policies deploy the same setting with different values. That definition matters because it keeps the investigation focused. A conflict is not the same as a slow sync. It is not fixed by repeatedly pressing Sync unless one of the conflicting inputs has changed.
The Settings Catalog makes this easier to create by accident. Admins can configure thousands of settings that map to Windows Configuration Service Providers, security baselines, ADMX-backed policy areas, browser policy, Office policy, and feature controls. Different teams may manage different profiles, but the device receives the final result as overlapping settings.
Common causes include:
- A Settings Catalog policy and a security baseline both configure the same Windows hardening value.
- A legacy device configuration profile remains assigned after the equivalent setting was moved into Settings Catalog.
- A user-scope setting and device-scope setting target the same pilot group.
- A custom OMA-URI policy writes a CSP value that another profile also controls.
- A policy targets Windows editions or builds that do not support the chosen setting.
- Dynamic groups changed membership and pulled production devices into a test profile.
- Group Policy still applies on co-managed or hybrid-joined devices.
Do not start by editing the policy that has the loudest error count. Start by proving which specific setting is failing and which policy path owns the competing value.
Read the Intune Status Correctly
Open the affected policy in the Intune admin center:
Devices → Manage devices → Configuration → Policies → select the Settings Catalog policy
From there, check three views before making changes.
First, open the device status summary. Intune reports whether assigned users or devices are Succeeded, Error, Conflict, Pending, or Not applicable. Microsoft notes that Pending can mean the device has not checked in yet or has not reported status back. That is different from Conflict, where the device received competing configuration.
Second, use per-setting status. This is the most important view for Settings Catalog. A policy may contain 80 settings, but only one setting may be in conflict. Per-setting status tells you which exact setting is successful, in conflict, or in error. If you skip this view, you will waste time comparing whole profiles instead of the one setting that matters.
Third, check Devices → Monitor → Assignment failures. Microsoft documents this report as the place where failed Settings Catalog deployments appear when there is an error or conflict. Export the report when multiple devices are affected. A CSV lets you sort by setting name, device, user, profile, and status instead of clicking through the portal one device at a time.
For a single device, also open:
Devices → All devices → select device → Device configuration
This view shows the configuration policies assigned to that device. If the expected policy is missing, you do not have a conflict yet. You have an assignment problem. Check group membership, filters, exclusions, and whether the policy targets users or devices.
Step-by-Step Fix Workflow
Use this workflow when a Settings Catalog profile reports Conflict, Error, or unexplained Not applicable across a pilot or production group.
1. Confirm the device has checked in
Look at the device’s last check-in time in Intune. If the device has not checked in since the policy was changed, wait for the next sync or trigger a device sync from the admin center. Microsoft documents that devices receive policy through change-based sync, client-initiated sync, and single-device sync. Reporting can still lag after the endpoint receives policy, so do not treat a stale report as proof of a current failure.
If the last check-in is old, solve connectivity first:
- Confirm the device is online and can reach Intune network endpoints.
- Ask the user to sync from Settings → Accounts → Access work or school.
- Use the Intune remote Sync action.
- Check whether Conditional Access, proxy, or VPN changes are blocking management traffic.
Only continue once you have a recent check-in or a repeatable sync failure.
2. Identify the exact setting in conflict
Open the Settings Catalog policy and use per-setting status. Record:
- Setting display name
- Category
- Scope, such as user or device
- Status
- Error code if shown
- Affected devices and users
- Profile name
Then check Assignment failures for the same setting. If multiple profiles show the same setting name, export the data. The export becomes your comparison list.
Be careful with friendly names. Two settings may have similar display names but different backing CSP paths. The reverse is also true: one CSP-backed value may appear in multiple profile types. When in doubt, open each policy and compare the setting’s category, configured value, and scope.
3. Find duplicate policy owners
Search Intune for the setting across these policy areas:
- Settings Catalog profiles
- Endpoint security baselines
- Security baseline versions in pilot and production
- Device restrictions profiles
- Administrative Templates profiles
- Custom OMA-URI profiles
- Endpoint security account protection, disk encryption, firewall, and attack surface reduction policies
- Imported Group Policy analytics objects
The fix is not always to delete a policy. In many tenants, the safer repair is to pick one policy owner per setting family. For example, use an endpoint security baseline for broad Microsoft Defender settings, and use a separate Settings Catalog profile only for values not covered by the baseline. If both configure the same value, document which one wins and remove the duplicate from the other policy.
For production repairs, avoid bulk edits. Remove or change one conflicting setting, sync a small test group, and verify per-setting status before touching the wider assignment.
4. Check user scope versus device scope
Microsoft’s Settings Catalog documentation calls out an easy trap: some settings exist in both user scope and device scope. If the same setting is assigned in both places, user scope can take precedence over device scope. During early device activity, before a user hive exists, some user-scope settings may also appear as Not applicable.
This is common during Autopilot and first sign-in. A device-targeted policy may apply during ESP, while a user-targeted policy waits until the first user context is available. If you assign both versions to the same population, the report can look inconsistent until the user signs in and the next check-in completes.
Use this rule: settings needed before the first user sign-in should be device-scoped when the setting supports it. Settings that are truly user-experience preferences should be user-scoped and should not be duplicated in a device policy.
5. Validate Windows version, edition, and CSP support
A Not applicable result is often correct. Microsoft documents that Windows settings can report Not applicable when the device’s OS version or edition does not support the setting. A policy intended for Windows Enterprise may not apply to Windows Pro. A setting introduced in a newer Windows release will not apply to older builds.
Check the affected device inventory:
- Windows edition: Pro, Enterprise, Education, or multi-session
- OS build and release version
- Enrollment type
- Ownership and management state
- Whether the device is co-managed
- Whether the setting is user-scope or device-scope
Then compare that inventory with the setting’s requirements in the Settings Catalog and the Windows CSP documentation. If the setting is unsupported, do not keep retrying sync. Split the assignment with filters or separate groups so unsupported devices stop receiving the setting.
6. Account for hybrid and co-management
For hybrid or co-managed devices, Intune may not be the only authority. Group Policy, Configuration Manager compliance settings, local scripts, provisioning packages, OEM tools, or security products may change the same value.
Run gpresult /h C:\Temp\gpresult.html on a sample device and inspect whether a domain GPO owns the same policy area. For MDM state, use MDMDiagReport.html from Windows diagnostics and Event Viewer under DeviceManagement-Enterprise-Diagnostics-Provider.
If Group Policy and MDM both configure the same Windows policy, decide the management authority before changing Intune. A clean Intune profile cannot win consistently if a domain GPO rewrites the value on the next background refresh.
Practical Example: Security Baseline Overlap
A common pattern looks like this:
- The security team deploys a new Windows security baseline to a pilot group.
- The desktop engineering team already has a Settings Catalog profile for the same Defender or firewall setting.
- Devices check in and report a conflict on one setting.
- The admin center shows the profile as partially failed, even though most settings succeeded.
The wrong fix is to clone the whole baseline or remove the device from management. The better fix is to compare the two configured values, decide which policy family owns the setting, and remove the duplicate value from the other profile. Then sync one or two devices, generate the policy report again, and confirm the setting moves from Conflict to Succeeded.
For audit purposes, record the decision in the policy description. Example: “Firewall inbound default action managed by Endpoint Security baseline. Do not configure in Settings Catalog.” That note prevents the same conflict from returning during the next baseline refresh.
Caveats That Waste Time
There are a few reporting behaviors worth knowing before you declare the fix failed.
Intune reports may not update instantly. Microsoft notes that policy reporting can take time to reflect recent assignment or group membership changes, especially in larger environments. Verify device check-in time and generate a fresh report before reopening the change.
Dynamic group membership is not immediate. If you fixed an Azure dynamic device group rule, the device may not leave the assignment instantly. Check the device’s group membership directly instead of assuming the rule has processed.
Not every Error is a conflict. Some errors are CSP failures, licensing problems, edition support problems, malformed OMA-URI payloads, or network issues. Per-setting status and Assignment failures help you separate these from duplicate-value conflicts.
Copilot in Intune can help summarize policies and identify potential conflicts, but it should not be the only source of truth for production remediation. Use it to speed investigation, then confirm the actual setting, scope, and assignments in the Intune reports.
Prevention Checklist
Use this checklist before moving Settings Catalog changes from pilot to production:
- One owner per setting family: baseline, endpoint security, Settings Catalog, or custom OMA-URI.
- Separate user-scope and device-scope settings unless there is a documented reason to combine them.
- Use assignment filters for OS version, edition, ownership, and enrollment type.
- Keep policy names explicit: platform, scope, owner, and purpose.
- Put ownership notes in the policy description.
- Export Assignment failures before and after major baseline updates.
- Test with devices that match real production builds, not only fresh lab devices.
- Retire old profiles after migration instead of leaving them assigned forever.
Conclusion
Intune Settings Catalog conflicts are fixable when you reduce the problem to the exact setting, exact scope, and exact assignment path. Use per-setting status first, Assignment failures second, and the device’s policy list third. Then remove duplicate policy ownership, split unsupported Windows devices with filters, and validate with a fresh sync on a small test group.
The key is discipline. Do not wipe devices to solve a policy design problem. Do not edit every baseline because one setting failed. Find the setting, find the competing owner, choose the source of authority, and verify the report changes from Conflict or Error to Succeeded.