Tracking Defender Policy Deployment with Logs

When deploying Defender policies like Real-Time Protection, ASR Rules, or Scheduled Scan via Intune, GPO, or the Defender Portal, we want an assurance that those settings actually reached the endpoint. In this guide, we’ll walk through how to use MpRegistry.txt — a powerful local Defender log file — to verify if a policy was received and applied, and how to troubleshoot common policy delivery issues.

This guide will be focused at explaining Defender logs called MpRegistry.txt, that will show you how Defender is receiving the policy, and applied policy.

This guide will help you troubleshoot the following scenarios:

• You have applied Defender Policy (such as Real Time Protection, Cloud Protection, or ASR Rules), but aren’t sure if the device received it.
• You have applied Defender Policy , but it is not being enabled/disabled per your config.
• You’re getting errors like “This setting is managed by your administrator”
• MDE still shows Security Recommendations even after you’ve applied fixes

Scope of this guide:

• Windows Client and Windows Server running Windows Defender

Step 1: Has the Defender policy reached the device?

Our goal here is to make sure that policy arrived on the endpoint, before a policy can be applied, it must first be successfully delivered to the device. Before Defender receive and apply it.

graph LR;
  managementTools["Management Tools"] --> Device --> Defender

We can reverse the policy flow to check logs at each point: Defender, the local system, and the management tools. In this guide, we will focus on the Defender side troubleshooting.

graph RL;
  managementTools["Management Tools"] --> device["Device<br>(GPResult/MDM Logs/etc)"] --> defender["Defender<br>(MpRegistry logs)"]

Step 2: Collecting Defender MpRegistry.txt logs

You can collect Defender logs, locally using the following command:

"%programfiles%\Windows Defender\mpcmdrun.exe" -getfiles

Once collection finish, you will see the output path. Extract the cab file to find the MpRegistry.txt

Step 3: Analyzing MpRegistry.txt - What to Look For

MpRegistry logs have 4 main sections, you can see them in the screenshot:

1. Effective policy -> Policy that is currently applied
2. System Policy -> Policy from GPO/SCCM/Defender Portal
3. MDM Policy -> Policy from Intune
4. Preferences -> Policy set up locally (Set-MpPreference or UI)

Next, you will need to know what is the registry name of the policy you are applying.

In my example here, I will be checking ASR Rules that I set from the Defender portal - Block Adobe Reader from creating child processes with GUID 7674ba52-37eb-4a4f-a9a1-f0f9a1619a2c.

Then use Notepad++ to search the following, with “Regular Expression” option:

effective policy|system policy|mdm policy|preferences|7674ba52-37eb-4a4f-a9a1-f0f9a1619a2c

You will find the search result, showing the policy is indeed under effective policy + system policy. This means, from system policy (GPO/SCCM/Defender Portal), Defender received the policy. And successfully applied the configuration (to effective policy) :

Wrapping Up: Know What is Applied and What is Not

With this knowledge, now you should be able to verify what configuration/policy is active on the Defender local side. Whether or not there are policy conflict coming from different sources.

MpRegistry.txt troubleshooting is only useful, if the configuration from Management Tools reached the endpoint. Meaning, you should be able to see them in system policy or mdm policy. If you are unable to see them under system policy/mdm policy, it means the configuration/policy is not delivered successfully into the endpoint. We will cover more on this scenario troubleshooting in the future.

There are very rare scenario you will see configuration in either system policy, mdm policy or preferences, however you don’t see it under the effective policy. In this scenario always remember to make sure Defender Platform is up to date, and open a Support Ticket to MS.