Troubleshooting Intune / Windows Device Configuration Issues

When OneClickComply deploys security policies to your devices through Microsoft Intune, you may see "Conflict" or "Error" statuses on some settings. This guide explains why these occur, how to identify the root cause, and what information to provide so we can get your device fully compliant.

Why Conflicts Happen

OneClickComply deploys a comprehensive set of security policies covering BitLocker encryption, Windows Defender, firewall rules, SmartScreen, device security hardening, and Windows Update management. These are delivered through several Intune policy types including Device Configuration profiles, Security Baselines, Endpoint Security policies, and Settings Catalog profiles.

A conflict occurs when the same Windows setting is configured by more than one policy source. This can happen when:

• Your organisation had existing Intune policies before OneClickComply was deployed, and those policies configure some of the same settings.

• A third-party security tool (such as a pre-existing MDM, group policy, or endpoint management platform) is also managing the same settings.

• Local Group Policy on the device has settings that overlap with what Intune is trying to apply.

• A Microsoft Security Baseline was previously applied and has not been removed.

When Intune detects that two policies are trying to set the same value, it reports a conflict — even if both policies are setting the same value. The setting may not be enforced reliably until the conflict is resolved.

The fix is always the same: identify the other policy source that is competing with OneClickComply, and either remove it or exclude the overlapping settings so that OneClickComply is the single source of truth.

Identifying OneClickComply Policies

All policies deployed by OneClickComply follow a consistent naming convention:

[OneClickComply] - Policy Name 

For example:

• [OneClickComply] - Defender Configuration

• [OneClickComply] - Device Security (Windows)

• [OneClickComply] - Firewall Policy (Windows)

• [OneClickComply] - Security Baseline

• [OneClickComply] - Smart Screen Settings

• [OneClickComply] - SmartScreen Policy

• [OneClickComply] - Local Account Password & Screen Lock Policy

• [OneClickComply] - Windows Group Policy Settings

• [OneClickComply] - Default Update Policy for Windows

These are your compliant policies. They represent the security configuration you have opted for through OneClickComply, tailored to your compliance requirements. Any policy in your Intune tenant that does not have the [OneClickComply] prefix is not managed by us and is a potential source of conflicts.

When reviewing your device configuration in the Intune portal, look at the policy names carefully. If a OneClickComply policy shows "Conflict," the competing policy will be one without the [OneClickComply] prefix. That competing policy is what needs to be removed or adjusted.

Ghost Policies — The Most Common Cause of Conflicts

A ghost policy is a policy that is no longer actively assigned in Intune but is still enforced on the device. Ghost policies are the single most common reason devices show conflicts after OneClickComply is deployed, and they can be difficult to spot because they do not always appear in the Intune portal even though they are still active on the machine.

How Ghost Policies Happen

Deleted Intune policies that were never unapplied. When an Intune policy is deleted from the admin centre, Intune is supposed to send a removal command to devices on their next sync. However, this does not always happen reliably. If the device was offline, had sync issues, or the removal command failed, the policy settings remain tattooed in the device's registry. The policy no longer exists in Intune, but the device still has the values applied — and those values now conflict with OneClickComply.

Unassigned policies that left settings behind. Similar to deletion, if a policy was unassigned from a group rather than deleted, the removal process can fail silently. The settings stay on the device indefinitely until something actively removes them.

Previous MDM or management tool enrolment. If the device was previously managed by a different MDM provider, a different Intune tenant, or a management tool like SCCM/ConfigMgr, settings from that previous enrolment may still be present in the registry.

Manual Local Group Policy edits. If someone has ever opened gpedit.msc on the device and configured settings manually — even temporarily for testing — those settings are written to the local Group Policy registry hive and persist across reboots and Intune syncs. Intune does not manage or clean up local Group Policy. These manual edits will conflict with any Intune policy that tries to set the same value.

Domain Group Policy from a previous domain join. If the device was previously joined to an Active Directory domain and had Group Policies applied, those settings can survive even after the device is removed from the domain and joined to Azure AD. The registry values from the old domain GPOs remain unless explicitly cleaned up.

Security Baselines that were removed but not cleaned up. Microsoft Security Baselines configure hundreds of settings. If a baseline was assigned, applied, and then removed, many of those settings remain on the device. Each one is a potential conflict with OneClickComply.

How to Detect Ghost Policies

Ghost policies are visible in the diagnostic data even when they are invisible in the Intune portal.

Check the MDM Diagnostic Report (step 2). In the MDMDiagReport.html file, look at the "Managed policies" section. Each setting shows a Config Source ID. If you see a Config Source ID that does not match any currently assigned policy, you have a ghost policy.

Check the Group Policy Results (step 3). In gpresult.html, look at the "Settings" sections under both Computer and User details. If you see settings defined here on an Azure AD-joined device that should only be managed by Intune, those are remnants from local Group Policy edits or a previous domain join.

Check the registry directly. Common locations where ghost policies hide:

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender" /s reg query "HKLM\SOFTWARE\Policies\Microsoft\WindowsFirewall" /s reg query "HKLM\SOFTWARE\Policies\Microsoft\FVE" /s reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /s reg query "HKLM\SOFTWARE\Policies\Microsoft\Internet Explorer" /s 

If you see values in these locations that do not correspond to any currently assigned Intune policy, they are ghost values.

How to Clear Ghost Policies

Important: Do not attempt to clear ghost policies yourself unless instructed by OneClickComply support. Deleting the wrong registry key can cause unintended side effects.

If you have been asked to clear ghost policies, the general process is:

For ghost Intune policies (deleted/unassigned policies that left settings behind):

Open Command Prompt as Administrator and run:

"%ProgramFiles(x86)%\Microsoft Intune Management Extension\Microsoft.Management.Services.IntuneWindowsAgent.exe" /resetMDM 

This triggers a re-evaluation of all MDM policies. Follow it with a sync (see "How to Force an Intune Sync" below).

For local Group Policy edits (gpedit.msc remnants):

Open Command Prompt as Administrator and run:

RD /S /Q "%WinDir%\System32\GroupPolicyUsers" RD /S /Q "%WinDir%\System32\GroupPolicy" gpupdate /force 

This removes all local Group Policy settings. It does not affect Intune policies.

For specific registry remnants:

We may ask you to delete specific registry keys. For example:

reg delete "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender" /f 

Only run these commands when specifically instructed by support, as the correct key to delete depends on which ghost policy is causing the conflict.

After clearing ghost policies, force an Intune sync and then re-run the sync error log (step 1) to confirm the conflicts have resolved.

Gathering Diagnostic Information

Before contacting support, please collect all of the following. Having everything upfront allows us to resolve most issues in a single response.

Step 1 — Sync Error Logs

Open PowerShell as Administrator and run:

Get-WinEvent -LogName "Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin" -MaxEvents 100 | ForEach-Object { "$($_.TimeCreated.ToString('MM/dd/yyyy HH:mm:ss')) | ID: $($_.Id) | $($_.LevelDisplayName) | $($_.Message -replace '[\r\n]+', ' ' -replace '\s+', ' ')" } | Out-File C:\intune-errors.txt 

Send us intune-errors.txt.

Step 2 — MDM Diagnostic Report

Open Command Prompt as Administrator and run:

mdmdiagnosticstool.exe -out C:\MDMDiag 

Send us MDMDiagReport.html from the C:\MDMDiag folder. This contains every policy applied to the device by Intune, the configuration source IDs, and their current values.

Step 3 — Group Policy Results

Open Command Prompt as Administrator and run:

gpresult /h C:\gpresult.html 

Send us gpresult.html. This reveals whether any local or domain Group Policies are competing with Intune.

Step 4 — BitLocker Status

Open Command Prompt as Administrator and run:

manage-bde -status C: > C:\bitlocker-status.txt 

Send us bitlocker-status.txt.

Step 5 — BitLocker Registry Values

Open Command Prompt as Administrator and run:

reg query "HKLM\SOFTWARE\Policies\Microsoft\FVE" /s > C:\bitlocker-registry.txt 

Send us bitlocker-registry.txt.

Step 6 — Defender and Firewall Configuration

Open PowerShell as Administrator and run:

Get-MpPreference | Out-File C:\defender-config.txt Get-NetFirewallProfile | Format-List | Out-File C:\firewall-config.txt 

Send us both files.

Step 7 — Device Information

Open Command Prompt as Administrator and run:

hostname > C:\device-info.txt systeminfo | findstr /B /C:"OS Name" /C:"OS Version" /C:"System Type" >> C:\device-info.txt 

Send us device-info.txt, or simply send a screenshot of winver.

How to Identify the Root Cause of a Conflict

If you have access to the Intune admin centre (intune.microsoft.com), you can identify exactly which policies are clashing.

Finding Conflicting Policies on a Device

1. Go to Devices → Windows → select the device showing conflicts.

2. Click Device configuration.

3. Look for any policy showing "Conflict" or "Error" status.

4. Click into the policy, then click on the specific setting that is in conflict.

5. Intune will display which other policy is setting the same value, including the policy name and the value each one is pushing.

This is the fastest way to find the competing policy. Once identified, either remove the setting from the competing policy or remove the competing policy entirely so OneClickComply is the sole source.

Common Competing Policy Sources

Common Conflicts and How to Resolve Them

Security Hardening Conflicts

These settings are part of the OneClickComply security hardening baseline. Conflicts mean another policy on your tenant is also configuring these same Windows security settings.

Settings commonly affected:

• Allow Basic authentication

• Allow unencrypted traffic

• Always prompt for password upon connection

• Apply UAC restrictions to local accounts on network logons

• Boot-Start Driver Initialization Policy

• Configure SMB v1 client driver / server

• Configure Solicited Remote Assistance

• Disallow WinRM from storing RunAs credentials

• Do not allow drive redirection

• Do not allow passwords to be saved

• Enable Structured Exception Handling Overwrite Protection (SEHOP)

• Hardened UNC Paths

• MSS: DisableIPSourceRouting (IPv4 and IPv6)

• MSS: EnableICMPRedirect

• MSS: NoNameReleaseOnDemand

• Require secure RPC communication

• Restrict Unauthenticated RPC clients

• Set client connection encryption level

• Turn on PowerShell Script Block Logging

• User Account Control Behavior of the Elevation Prompt for Administrators

• WDigest Authentication

Root cause: These are almost always caused by a pre-existing Security Baseline or Device Configuration profile that was deployed before OneClickComply. Microsoft's own Security Baselines configure many of these same settings.

How to resolve:

1. In the Intune admin centre, go to Devices → select the affected device → Device configuration.

2. Click into the OneClickComply policy showing "Conflict."

3. Click on any conflicting setting — Intune will show you the name of the other policy.

4. Either remove the overlapping settings from the other policy, or unassign the other policy from the device/group if it is fully redundant with OneClickComply.

Firewall Conflicts

Settings commonly affected:

• Disable Inbound Notifications

• Firewall profile settings (Domain, Private, Public)

• Inbound connections blocked

• Unicast responses to multicast broadcasts

Root cause: Firewall settings configured in both a OneClickComply Firewall Policy and a Security Baseline, Device Security profile, or a pre-existing Endpoint Security Firewall policy.

How to resolve: Identify the other firewall policy using the device configuration view. Remove firewall settings from whichever policy is not the intended source, leaving OneClickComply as the single firewall policy.

SmartScreen Conflicts

Settings commonly affected:

• Allow Smart Screen

• SmartScreen override settings

• App Install Control

Root cause: SmartScreen is one of the most commonly conflicted settings because it can be configured in Device Restrictions, Security Baselines, Endpoint Security, Windows Group Policy Settings profiles, and Edge browser policies. If any two of these are assigned to the same device, a conflict occurs.

How to resolve: Consolidate SmartScreen settings into a single policy. Remove SmartScreen configuration from all other profiles.

Defender and Antivirus Conflicts

Settings commonly affected:

• Submit Samples Consent / Prompt users before sample submission

• Allow Behavior Monitoring

• Cloud Block Level

• Attack Surface Reduction rules

Root cause: Defender settings configured in both a OneClickComply Defender Configuration profile and a Security Baseline, Endpoint Security Antivirus policy, or pre-existing Device Restrictions profile.

How to resolve: Identify the competing Antivirus or Defender policy. Remove Defender settings from the non-OneClickComply policy, or unassign it from the device group.

AutoPlay and Removable Media Conflicts

Settings commonly affected:

• Disallow Autoplay for non-volume devices

• Set the default behavior for AutoRun

• Turn off Autoplay

Root cause: These settings are commonly configured in both Security Baselines and device hardening profiles.

How to resolve: Remove the AutoPlay settings from whichever policy is not OneClickComply.

Remote Desktop and Remote Management Conflicts

Settings commonly affected:

• Allow Basic authentication (WinRM)

• Allow unencrypted traffic (WinRM)

• Do not allow drive redirection

• Do not allow passwords to be saved

• Always prompt for password upon connection

• Set client connection encryption level

• Require secure RPC communication

Root cause: Remote Desktop and WinRM settings are hardened by both Security Baselines and OneClickComply. If both are assigned, every RDP/WinRM setting will show a conflict.

How to resolve: If OneClickComply is your intended security baseline, remove the Microsoft Security Baseline or remove the RDP/WinRM settings from it.

Power Management Conflicts

Settings commonly affected:

• Allow standby states (S1-S3) when sleeping (on battery)

• Allow standby states (S1-S3) when sleeping (plugged in)

• Prevent enabling lock screen slide show

Root cause: Power and lock screen settings configured in both a Device Restrictions profile and a Security Baseline or Group Policy Settings profile.

How to resolve: Remove the power/lock screen settings from the non-OneClickComply policy.

Windows Update Policy Errors

Settings commonly affected:

• Servicing channel — Error -2016281111

• Deadline for feature updates — Error -2016281111

• Deadline for quality updates — Error -2016281111

• Grace period — Error -2016281111

What error -2016281111 means: This error code (0x87D10009) indicates "Setting not applicable for this edition" or "Conflict with another policy." It most commonly occurs when:

• A Windows Update for Business policy and a Windows Update Ring are both targeting the same device with different update settings.

• The servicing channel setting is trying to set a value that conflicts with the device's current Windows edition or an existing update policy.

• A pre-existing update policy from before OneClickComply is still assigned.

How to resolve:

1. In the Intune admin centre, check Devices → Windows → Update rings for Windows 10 and later and Feature updates for Windows 10 and later.

2. Identify any update policies that are not from OneClickComply.

3. Either unassign the conflicting update policy or remove the overlapping settings.

Note: The "AllowWindows11Upgrade" setting showing "Not applicable" is normal if the device is already running Windows 11 or is not eligible for the upgrade.

Device Installation Conflicts

Settings commonly affected:

• Prevent installation of devices using drivers that match these device setup classes

Root cause: Device installation restrictions configured in both a Security Baseline and a OneClickComply Device Security profile.

How to resolve: Remove the device installation setting from the non-OneClickComply policy.

Licensing and Compatibility Errors

Error 65000 or 0x82b00006 — Virtualization Based Security / HVCI

Settings affected:

• Enable Virtualization Based Security

• Hypervisor Enforced Code Integrity

What this means: These settings require Windows Enterprise or Education edition. If your device is running Windows Pro, these policies will fail with a licensing error every sync.

This does not affect your device's security posture for BitLocker, Defender, firewall, or any other OneClickComply policy. These are advanced hardware security features that are not available on the Pro edition.

How to resolve: Contact OneClickComply support. We will either exclude your device from these policies or assist with upgrading your Windows edition if VBS/HVCI is required for your compliance framework.

Error 0x807c000a — Enterprise Data Protection / WIP

Windows Information Protection has been deprecated by Microsoft. If this error appears, a legacy WIP policy is still assigned. Contact support and we will remove it.

Encrypted Search Index Conflicts

Settings affected:

• Allow Indexing Encrypted Stores Or Items

Root cause: This setting is configured in both a Security Baseline and a OneClickComply profile.

How to resolve: Remove the setting from whichever policy is not OneClickComply.

BitLocker-Specific Troubleshooting

"BitLocker Encryption cannot be applied due to conflicting Group Policy settings"

Two or more BitLocker policies are contradicting each other, typically involving startup authentication and drive write-access restrictions.

Common causes:

• "Deny write access to fixed drives not protected by BitLocker" is enabled while startup authentication requires a USB key.

• "Allow BitLocker without a compatible TPM" is enabled alongside "Require TPM."

What to provide us: BitLocker registry export and MDM diagnostic report (steps 5 and 2).

"The Group Policy settings for BitLocker startup options are in conflict"

Startup authentication settings are contradicting each other. Only one method can be required at a time.

Common causes:

• TPM set to "Required" while "Allow BitLocker without a compatible TPM" is also enabled.

• Multiple startup protectors set to "Required" simultaneously.

What to provide us: BitLocker registry export (step 5).

"TPM+PIN protection not used for OS Drives, but is required by policy"

BitLocker is running with TPM-only but the policy now requires TPM+PIN.

What to provide us: BitLocker status and sync error logs (steps 4 and 1).

Verifying BitLocker is Working

Run manage-bde -status C: and check for:

Conversion Status: Fully Encrypted Percentage Encrypted: 100.0% Encryption Method: XTS-AES 256 Protection Status: Protection On Key Protectors: TPM Numerical Password 

If you see "Fully Encrypted" and "Protection On," your drive is encrypted and secure regardless of any other policy conflicts.

How to Force an Intune Sync

After we make policy changes, you will need to sync your device to pull the updated configuration.

Method 1 — Settings app: Go to Settings → Accounts → Access work or school → click your connection → Info → Sync.

Method 2 — PowerShell (as Administrator):

Get-ScheduledTask | Where-Object {$_.TaskName -eq 'PushLaunch'} | Start-ScheduledTask 

Method 3 — Company Portal: Open Company Portal → Settings → Sync.

After syncing, wait 60 seconds then re-run step 1 to check if errors have cleared.

The Resolution Process

1. You collect the diagnostics listed in this guide and send them to OneClickComply support.

2. We identify the conflicting policy source using the MDM diagnostic report and sync logs.

3. We make the change — either removing the conflicting policy, excluding overlapping settings, or adjusting the OneClickComply configuration for your environment.

4. You sync the device using one of the methods above.

5. You re-run the sync error log (step 1) and confirm errors have cleared.

Most conflicts are resolved in a single change once we can see the competing policy. The diagnostic files make this possible without needing remote access to your device.

What to Send Support — Checklist

FAQ

Q: I see lots of "Conflict" statuses but everything seems to be working. Is my device at risk? Not necessarily. A conflict means Intune cannot confirm it is the sole source enforcing that setting, but the setting may still be applied from a previous sync or through another mechanism. However, conflicts should be resolved because a future policy change or sync could cause the setting to drop. Send us the diagnostic files and we will confirm your actual security state.

Q: Why does the same policy appear twice — once for my account and once for "System account"? Intune applies policies in two contexts: the device context (System account) and the user context (your account). Some settings apply at both levels. If you see a conflict on both, the issue is at the policy level, not specific to your user account.

Q: Can I fix these conflicts myself? If you have access to the Intune admin centre, you can identify the competing policy using the steps in the "How to Identify the Root Cause" section. However, we recommend contacting OneClickComply support before making changes, as removing the wrong policy could leave settings unenforced. If you do not have Intune admin access, send us the diagnostic files and we will handle it.

Q: Will resolving conflicts require a device restart? Most policy changes take effect after a sync without restarting. Some settings — particularly BitLocker startup options, VBS/HVCI, and certain Defender configurations — may require a restart. We will let you know if a restart is needed after making changes.

Q: I see "Not applicable" on some settings. Is that a problem? No. "Not applicable" means the setting does not apply to your device's edition, version, or hardware configuration. For example, "AllowWindows11Upgrade" will show "Not applicable" if your device is already on Windows 11. This is normal and not an error.

Q: What does error -2016281111 mean? This is Intune error code 0x87D10009, which means "Not applicable" or "Remediation failed." It most commonly appears on Windows Update settings when two update policies are competing or when a setting is not supported on the device's Windows edition.

Q: What does error 65000 mean on VBS/HVCI settings? This indicates the policy was rejected because your device is running Windows Pro, which does not support Virtualization Based Security policies. This does not affect any other security settings. Contact support and we will adjust the policy assignment.

Q: What does "Catastrophic failure" in the sync logs mean? The "Getting push alert info for push initiated session failed — Catastrophic failure" message is a transient Intune communication error. It resolves on its own and does not affect policy application.

Q: My device was compliant before and now it shows conflicts after OneClickComply was deployed. Why? This is expected if your organisation had pre-existing Intune policies. OneClickComply deploys a comprehensive security configuration, and any overlap with existing policies will generate conflicts. The resolution is to remove or adjust the pre-existing policies so OneClickComply is the single policy source for each setting. This is a one-time cleanup.

Q: What happens if I lose my BitLocker recovery key? Recovery keys are automatically backed up to Azure AD. Contact support and we can retrieve your recovery key using your device information.

Q: I deleted an old policy from Intune weeks ago but the device still shows conflicts. Why? This is a ghost policy. When policies are deleted from Intune, the removal command does not always reach the device — especially if the device was offline or had sync issues at the time. The old policy settings remain in the device's registry and conflict with OneClickComply. Send us the diagnostic files and we can identify and clear the ghost policy.

Q: Someone used gpedit.msc on this device in the past. Could that be causing conflicts? Yes. Manual Local Group Policy edits persist indefinitely and are not managed or cleaned up by Intune. Even a temporary change made months ago can cause ongoing conflicts. The gpresult.html report (step 3) will reveal any local Group Policy settings, and we can walk you through clearing them.

Q: The device was previously managed by a different MDM / IT provider. Could that cause issues? Yes. Settings from a previous MDM enrolment, SCCM/ConfigMgr management, or a different Intune tenant can survive and conflict with OneClickComply. The MDM diagnostic report will show us these remnant settings, and we can guide you through removing them.

Q: How do I know which policies are from OneClickComply and which are not? All OneClickComply policies are prefixed with [OneClickComply] - in their name. Any policy in your Intune tenant without this prefix was not deployed by us and is a potential source of conflicts. Check the "Identifying OneClickComply Policies" section above for the full list.