Defender Antivirus settings not applying from Intune: a troubleshooting checklist

An Intune antivirus policy that reports success while Get-MpPreference on the device says something else is one of the more confusing Defender problems, because several layers can quietly override or hide a setting. In this post I'll walk through a checklist that narrows it down: how the device is managed, whether policies conflict, what actually reached the device, and which Defender behaviours change the result.

Symptoms#

• The antivirus policy shows Succeeded, Conflict, Error or Not applicable in Intune, but the setting isn't in effect on the device.
• Get-MpPreference returns a different value from the one you configured, or shows no exclusions at all.
• Exclusions that admins added locally have stopped working.
• A policy that turns off real-time or cloud protection for testing has no effect.
• The policy works on some devices, such as cloud-native laptops, but not on co-managed PCs or servers.

Why it happens#

1. The wrong management channel. Co-managed devices follow Configuration Manager unless the Endpoint Protection workload points to Intune. Devices managed through Defender for Endpoint security settings management only pick up policies assigned to device groups.
2. Conflicting Intune policies. In antivirus policies only three settings merge across policies: excluded paths, extensions and processes. Anything else conflicts when two policies disagree, and a conflict can leave the device with no value at all.
3. Another tool writes the same setting. Group Policy, Configuration Manager or local scripts. Microsoft notes that MDMWinsOverGP doesn't apply to the Defender CSP.
4. Defender isn't the active antivirus. On Windows clients with a third-party product, Defender runs in passive mode if the device is onboarded to Defender for Endpoint, and is usually disabled if it isn't. Cloud protection, network protection, ASR rules and PUA protection don't work in passive mode.
5. Tamper protection. Protected settings stay at secure values, and attempts to change them can look successful while being blocked.
6. Exclusion handling. Policies can hide exclusions from local admins or stop local exclusions from merging.

How to fix it#

1. Confirm how the device is managed#

In the Microsoft Intune admin center, open Endpoint security › All devices and check the Managed by column:

• MDM: enrolled in Intune; continue with step 2.
• MDM/ConfigMgr Agent: co-managed. Move the Endpoint Protection workload slider to Intune or Pilot Intune.
• MDE: security settings management. Assign policies to Microsoft Entra device groups and confirm Allow Microsoft Defender for Endpoint to enforce Endpoint Security Configurations is on under Endpoint security › Defender for Endpoint.

2. Look for conflicts setting by setting#

Select the device, open Device configuration under Monitor, then open the antivirus policy to see each setting's state. Conflict means another policy sets the same thing: typically a security baseline, a Settings Catalog profile, an older endpoint protection or device restrictions profile, or a second antivirus policy. Pick one owner for the setting and remove it from the rest.

3. Prove the policy reached the device#

On the device, go to Settings › Accounts › Access work or school, select the work account, then Info › Create report and Export. The HTML report is saved in C:\Users\Public\Documents\MDMDiagnostics and lists the policies and values the device received. If your setting isn't there, it's a targeting or delivery problem; check Applications and Services Logs › Microsoft › Windows › DeviceManagement-Enterprise-Diagnostics-Provider › Admin for errors.

4. Read Defender's effective state#

Get-MpComputerStatus |
    Select-Object AMRunningMode, RealTimeProtectionEnabled, IsTamperProtected

Get-MpPreference |
    Select-Object DisableRealtimeMonitoring, MAPSReporting, PUAProtection, ExclusionPath

AMRunningMode should be Normal. Passive or EDR Block Mode means another antivirus is primary, and settings for active-mode features won't do anything until that changes.

5. Remove competing channels#

Run gpresult /h gpresult.html or look under HKLM\SOFTWARE\Policies\Microsoft\Windows Defender for Group Policy values. Because MDMWinsOverGP doesn't cover the Defender CSP, the dependable fix is to stop applying Defender GPOs to Intune-managed devices. If you can't untangle every channel quickly, look at the preview Controlled Configuration (Device) setting in the Windows Security experience antivirus profile. Set to Controlled Configuration (On), it makes settings from Intune antivirus and ASR policies win over Group Policy, Configuration Manager and local changes. Settings you don't configure fall back to secure defaults, so make sure your policies cover everything you rely on. It doesn't cover Settings Catalog policies; overlapping settings there report as Not applicable.

6. Account for tamper protection#

With tamper protection on, settings such as real-time protection, behaviour monitoring, cloud protection and security intelligence updates stay locked, and a change from any tool can appear to work while being blocked. Look for event 5013 in Microsoft › Windows › Windows Defender › Operational; it names the setting that was refused. For a temporary change on one device, use troubleshooting mode. In Intune, tamper protection lives in the Windows Security experience profile; where the controlled configuration preview is available, it's the Tamper Protection (On) value of that same setting. It shows Not applicable until the device is onboarded to Defender for Endpoint.

7. Check exclusion behaviour#

• Exclusions from every assigned policy merge into one list, so an unexpected exclusion usually comes from a policy you forgot.
• With HideExclusionsFromLocalAdmins set, exclusions still apply but don't appear in Get-MpPreference or the registry.
• With Disable local admin merge set in the Microsoft Defender Antivirus profile, exclusions added locally through PowerShell or Windows Security are ignored and only policy lists count.

Verify the fix#

Sync the device and re-run the PowerShell checks. You should see the configured value in Get-MpPreference, an event 5007 (settings changed) in the Defender Operational log, and the setting reported as Succeeded in the device's policy view. For the fleet, Reports › Antivirus › Antivirus agent status and Endpoint security › Antivirus › Unhealthy endpoints show which devices still need attention.

Key takeaways#

• Check AMRunningMode first; nothing else matters if Defender isn't active.
• Give each Defender setting exactly one owner; only the three exclusion lists merge.
• Keep Defender GPOs away from Intune-managed devices.
• Use device groups for anything managed through security settings management.
• Tamper protection and hidden exclusions can make a working policy look broken.

References#

• Antivirus policy for endpoint security in Microsoft Intune
• Troubleshoot problems with tamper protection
• Microsoft Defender Antivirus compatibility with other security products