Microsoft Defender for Endpoint (MDE) is part of Microsoft Defender XDR and can be deployed via multiple configurations. During my experience with the product, I deployed/ reviewed and evaluated many Defender for Endpoint instances and configured new instances for many customers around the world; from small companies to larger enterprises and a couple of million endpoints. This blog will explain the common mistakes/ configuration mistakes around Defender for Endpoint deployments.
Blog updated: 05-07-2024: Added new mistakes and renewed the blog with more information. |
Background – Components of Defender for Endpoint
Microsoft Defender for Endpoint or MDE is the grouping of 3/4 main items. MDE is the logical grouping of the following items:
- TVM (Threat Vulnerability Management)
- EDR (Endpoint Detection and Response)
- AV (Defender Antivirus)
- ASR (Attack Surface Reduction)
Defender for Endpoint (MDE) in general is part of Defender XDR which correlates with other products and services in the Defender XDR ecosystem.
Microsoft Defender for Endpoint is a key component of the Microsoft 365 Defender architecture and part of the Microsoft 365 Defender platform. It shares data/ signals and architecture with the following products;
- Microsoft Defender for Endpoint (MDE)
- Microsoft Defender for Office 365 (MDO
- Microsoft Defender for Cloud Apps (MDA)
- Microsoft Defender for Identity (MDI)
- Azure AD Identity Protection (AADIP)
- Azure Defender (Preview)
Defender for Endpoint relies on multiple system components and integrations. In this blog, I will explain the common mistakes when using and deploying Defender for Endpoint.
Blog tip: MDE blog series (from what is Defender for Endpoint to configuration using Intune)
Common mistakes
When deploying Defender for Endpoint it all starts with preparation. It is important to investigate the current environment to avoid policy conflicts and design the solution perfectly for the used management methods/ systems/ network configuration in the environment. What are the common mistakes? I know the list can be long. (;
- No structure in Defender for Endpoint
- Service settings not correctly enabled
- No plans for the onboarding mechanism
- No “design” around policies/ deployment (results in policy conflicts)
- Exclusions migrated from other AV solutions
- Defender AV not configured correctly
- No whitelisting in the network
- Deploying it in production without understanding all the features
- Audit mode is doing protection in MDE
- Updates are not needed in passive mode
- Not using the portal (waiting for incidents/alerts)
- Not using Threat Analytics
- Deploy to unpatched systems
- Defender for Servers is fully automated including AV configuration
- Misconfiguration of block at first sight (BAFS)
- Emergency (real-time) updates with cloud protection.
- Running in passive mode
- And many more
No structure in Defender for Endpoint
The portal looks simple; there is an onboarding method/ device inventory and a set of features on top of the collected data. For larger enterprises with multiple environments/ geo-locations/ companies device groups are important for assigning more in-depth RBAC controls and for giving visibility in the reporting. When different IT teams are responsible for a smaller set of devices it is a must to configure a well-structured grouping structure.
It is heavily recommended to design a proper RBAC/ device group structure in Defender for Endpoint. Since a good structure is efficient in the use and reporting of features. Indicators can be scoped to device groups, and permissions can be limited to specific groups.
Since it is not only Defender for Endpoint, my recommendation is to start with the Unified RBAC experience and grant permissions across the Defender XDR product, since this helps more with defining the roles.
Permissions to everyone
Did you know there is a risk when onboarding devices (Domain Controllers/ Tier-0 servers) to Azure Arc/ Defender for Endpoint (MDE) – the risk can generate a huge impact when the access model is not configured correctly and allows potential a take-over of the machine. Let me explain why and how to design a good structure without risk.
The risk with Azure Arc
After enabling Azure Arc on Domain Controllers or other Tier-0 servers there is the option to do a server takeover via the Arc agent and policies/scripts. You can easily run PowerShell scripts (Custom script extension) for generating local accounts or changing critical settings on the domain controllers via the available extensions. When enrolled in MDE there is a detection capability of the EDR for malicious performed actions; all not for all performed actions.
If you were to deploy a domain controller/other Tier-0 assets and manage the servers using Azure Arc, then the Azure Arc admins and all other sufficient roles who can become an Azure ARC admin in that tenant are effectively a Domain Admin for that AD forest.
What can we do?
When designing Azure Arc it is needed to define a good RBAC/ subscription model and define only permissions for a specific set of people. Syncing Azure Arc to one subscription/ resource group? Each member with sufficient roles can manage the servers via Azure Policies/ scripts.
– Design a good RBAC/ Azure/ IAM structure
– Give limited access to Tier-0 and Domain Controllers
– Dedicated Resource Group for Tier-0 with limited access
– Check who has control over the Azure Arc resources
The risk with Defender for Endpoint
When using Defender for Endpoint without Azure Arc there is even a risk. For all MDE onboarded devices there is a risk of a complete take-over via Live Response. With the use of Live Response, it is possible to upload custom PowerShell scripts and run scripts on any onboarded machine when there are permissions. Check always the permissions and who can use live response.
For MDE consider a good device structure and limited access to the Tier-0/ Domain Controller assets to a specific group of people.
What can we do?
Tag devices and assign them to a specific device group in MDE. Limit access to the device group in MDE with only access from a specific group of people. With the use of permissions, it is possible to allow only a specific group to have access.
– Tag machines
– Create separate device groups for T0/ critical assets
– Grant limited permissions to the device group
– Review live response activity
– Disable Live Response unsigned script execution when possible in the Advanced features.
Did you know you can review all performed live response sessions? Go to M365D – Actions & Submissions – Action Center and open the History tab. Filter here for the action; Live Response command. 30 days of history is visible.
Service settings not correctly enabled
Customers started onboarding Defender for Endpoint without full protection enabled. Defender for Endpoint works based on a couple of features (Advanced Features) – without features enabled there is less protection or weakness in the product. Before starting with any onboarding of a machine, make sure the service settings are correctly enabled.

Not following new configurations/ features
Microsoft released rapidly new features around Defender for Endpoint. Defender for Endpoint is a story, important to follow the new developments. A good example is the ASR rule; “Block vulnerable drivers” This ASR rule is not available via the MECM policies or old Intune policies – it is always needed to follow the new developments and improve the Defender for Endpoint instance.
Another good example is when still using the Microsoft Monitoring Agent (MMA) for 2012R2/ 2016 systems. Microsoft released a new unified agent with more support and better protections.
Using the device configuration profile in Intune? Good idea to migrate them to the new Endpoint Security profiles – since Endpoint Security profiles are supported for MDE Configuration Management and upcoming features rely on this policy framework.
Update releases:
Below URLs includes the what’s new in Defender for each OS platform/ version:
What’s new in Defender for Endpoint on Windows
What’s new in Defender for Endpoint on macOS
What’s new in Defender for Endpoint on Linux
What’s new in Defender for Endpoint on Android
What’s new in Defender for Endpoint on iOS
No plans for the onboarding mechanism
Onboarding is a different topic – currently, many solutions are available for onboarding Defender for Endpoint. Intune, GPO, PowerShell, Configuration Manager, Azure Arc, Defender for Servers. There are many options; my tip here is don’t focus only on Defender for Endpoint – check if more is possible. For example; Defender for Servers/ Azure Arc and Microsoft Intune support way more features for a better security landscape.
When using Azure Arc/ Defender for Cloud make sure to align the specific teams with a focus on Azure and start with a well-designed Azure landing zone. Another common mistake is related to the Azure Arc agent updates.
The Azure Connected Machine agent is updated regularly to address bug fixes/ stability enhancements and new functionalities. The agent update recommendations are visible via Azure Advisor. There is no automatic update based on the agent itself; it requires changes in the update process.
No “design” around policies/ deployment (results in policy conflicts)
GPO, Intune, Configuration Manager, Local Policy, PowerShell, and more. There are many tools available for configuring settings on Windows. Avoid conflicts and document the configured policies.
Before starting Defender for Endpoint projects, analyze the current configuration landscape. Common mistakes:
- Defender AV disabled via GPO/ Local GPO
- Microsoft Security GPO baseline conflicts with Intune
- Configuration Manager Endpoint Protection site role conflicts with Intune
When using Intune and GPO; it can be useful for the deployment of a configuration for making the MDM policy a higher order. Without any configuration, GPO is always the highest configuration when there is a conflict. With the use of a custom policy, it is possible to define the MDM policy over GPO.
MDMWinsOverGP is available via the following OMA-URI setting:
OMA-URI | ./Device/Vendor/MSFT/Policy/Config/ControlPolicyConflict/MDMWinsOverGP |
Data type | Integer |
Value | 1 |
The setting is also available via the settings catalog with the name: MDM Wins over GP

Exclusions migrated from other AV solutions
This one is quite often visible in environments. Organizations used other third-party AV solutions for many years, resulting in many legacy exclusions. Never migrate the entire list from any other AV in Defender AV. Each AV works differently – add only exclusion when there is a critical need (performance issues/ compatibility issues).
When using exclusion make sure it is documented (ticket number, reason, troubleshooting details). Defining exclusions lowers the protection offered by Microsoft Defender Antivirus, so use exclusions only in situations when there is no other solution.
Defender AV not configured correctly
Common misunderstanding; we have the Defender for Endpoint sensor onboarded and all is good and protected. The sensor is reporting “healthy/active” in Defender for Endpoint and Defender AV is running. This is not correct

Defender AV/ NGP/ ASR is part of Defender for Endpoint and must be configured. Without Defender AV correctly configured, there is a lack of protection; Cloud Protection, ASR, Network Protection, and many more settings depend on the AV component. See the following blogs:
- Microsoft Defender for Endpoint series – Configure AV/ next-generation protection – Part4
- Microsoft Defender for Endpoint series – Define the AV policy baseline – Part4A
- Microsoft Defender for Endpoint series – Attack Surface reduction and additional protection – Part4B
Tip: Use the security recommendation part of Defender for Endpoint
The first step in enrolling MDE is confirming that all configurations are compliant. Using Microsoft Defender Vulnerability Management it is possible to check the configured security controls for Antivirus, Application Guard, ASR, Bitlocker, Credential Guard, EDR, Exploit Guard, Firewall, SmartScreen, and the general onboarding state of MDE.
Use security recommendation data often and make it part of the IT process.
View via the portal: Go to recommendations and filter on the related component “Security controls” for viewing the compliance of all security controls policies.

For Attack Surface Reduction Rules – the recommendation insights are visible based on user impact information. User impact calculation is collected in the past 45 days and based on collected sensor telemetry.
Important: Recommendation is based on the enablement/disabled state of the feature. Specific settings (MAPS level, timeout) are not part of the result/ check. Always confirm the baseline and correct MAPS settings with in-depth testing of the machines (simulations/ validation) See:
Microsoft Defender for Endpoint series – Defender Vulnerability Management – Part5
Tip: Use advanced hunting to find incorrect devices
The TVM data can be extracted easily via hunting. With the use of hunting it is possible to show all devices where a specific TVMcheck is not compliant. An example is to show all devices where Defender AV is disabled. (SCID-2010)
DeviceInfo
| summarize arg_max(Timestamp, *) by DeviceId
| project DeviceId,Timestamp,DeviceName,ClientVersion,OnboardingStatus,DeviceType,MachineGroup
| project-rename LatestDeviceData = Timestamp
| join kind = inner (
DeviceTvmSecureConfigurationAssessment
| where ConfigurationId == "scid-2010"
| project DeviceId,Timestamp,ConfigurationId,ConfigurationSubcategory, IsApplicable,IsCompliant,Context
| project-rename TimeStampTVMEval = Timestamp
| join kind = inner (
DeviceTvmSecureConfigurationAssessmentKB
| project ConfigurationId,ConfigurationName, ConfigurationDescription
) on ConfigurationId
) on DeviceId
| where IsApplicable == 1 and IsCompliant == 0
Another example; show all devices where MAPS/ Cloud Protection is disabled (SCID-2016):
DeviceInfo
| summarize arg_max(Timestamp, *) by DeviceId
| project DeviceId,Timestamp,DeviceName,ClientVersion,OnboardingStatus,DeviceType,MachineGroup
| project-rename LatestDeviceData = Timestamp
| join kind = inner (
DeviceTvmSecureConfigurationAssessment
| where ConfigurationId == "scid-2016"
| project DeviceId,Timestamp,ConfigurationId,ConfigurationSubcategory, IsApplicable,IsCompliant,Context
| project-rename TimeStampTVMEval = Timestamp
| join kind = inner (
DeviceTvmSecureConfigurationAssessmentKB
| project ConfigurationId,ConfigurationName, ConfigurationDescription
) on ConfigurationId
) on DeviceId
| where IsApplicable == 1 and IsCompliant == 0
As you can see; there are multiple ways to view incorrect devices and validate the status of Defender for Endpoint and the specific components. More useful queries in the following blog: How works Microsoft Defender Vulnerability Management (MDVM) (jeffreyappel.nl)
Deploying it in production without understanding all the features
Essential for the IT teams to understand the features part of Defender for Endpoint. Based on real experiences by organizations there is often knowledge by the full IT team. Train users and make sure all features are explained (including service desk teams). Examples:
- What is EDR in Block Mode
- What is MAPS/ Cloud Protection
- What is PUA protection
- How to exclude feature xx in the portal or configuration
- How works Tamper Protection
- What is audit mode/ block mode
Most of the weakness starts with IT knowledge (Excluding complete folders; disabling AV features, offboard machines, not knowing the detection logic/ agent features) – make sure the team is informed and “knows” the products in-depth including all sub-features.
Recommended: View/ read all content part of the Defender for Endpoint Ninja show/ Ninja blog for in-depth knowledge.

Audit mode is doing protection in MDE
Common situation; we have some components (ASR/ Network Protection, PUA) in audit mode and are safe. Nope, audit mode is not doing any protection in MDE. It collects in some cases audit events, all there is no actual block.
Attack Surface Reduction (ASR) is always tricky and requires some fine-tuning. Don’t use audit mode for months; after configuring audit mode review the events and plan the enablement in block mode. Don’t use audit mode for years when not needed, since ASR is enabling additional protection controls.
In cases for ASR where the rule is not compatible with the environment; enable always audit mode instead of disabling the rule. With the use of audit mode, all data is collected and available via Advanced Hunting, this can be useful in terms of further investigations.
Updates are not needed in passive mode
When using Defender for Endpoint/ Defender AV in passive mode/ EDR in block mode it is still required to update the agent with the correct updates. Make sure the signature updates/ platform updates and Sense updates are deployed.
Not using the portal (waiting for incidents/alerts)

Defender for Endpoint is installed on all machines and up and running, there is no need to use the portal – only in cases when there is an alert. Not true; When Defender for Endpoint is correctly deployed there are many insights. After deploying it is important to use all data, start with hunting,/ exploring events, and use the data in Defender Vulnerability Management for patching all systems. More information later in this blog for the usage and insights
Not using Threat Analytics
The threat analytics part of Defender for Endpoint is important. Threat analytics is a feature with in-depth information from Microsoft security research and automated insights for possible impacted assets and available mitigations. In the Analyst report section, there is a detailed expert write-up available with in-depth information about the attack techniques and used KQL queries for hunting.

Deploy to unpatched systems
When starting with the deployment of Defender for Endpoint – make sure all systems are correctly updated to one of the latest updates. Based on experience there are many possible issues when systems are not on the correct level.
When the Servicing Stack Update (SSU) and Latest Cumulative Update (LCU) are correctly updated it will result in easier onboarding. Based on experience; Server 2016 gives a couple of issues when the SSU/ LCU is not updated to a specific version.
Tip; when doing deployments to Server 2012R2 and Server 2016, use the mdefordownlevelserver script provided by Microsoft.
Defender for Servers
When using Defender for Servers there is still configuration needed for the Defender for Endpoint configuration. Defender for Servers starts only the onboarding via provisioning – it is still needed to configure additional components (AV, ASR, Firewall e.d). Ideally, use the new MDE security settings management for managing servers centralized via Intune.
Blog tip: Manage Defender for Endpoint for Windows, macOS, and Linux via Security settings management
Not updating the unified agent
For 2012R2 and 2016 with the unified agent installed, it is needed to update the sense component. The SENSE component requires to update KB5005292 for improvements related to the EDR sensor component.
When using WSUS or Microsoft Endpoint Configuration Manager it is important to include the updates part of the “Microsoft Defender for Endpoint” category.
Misconfiguration of block at first sight (BAFS)
Block at first sight (BAFS) is a threat protection feature of the Defender AV/ NGP component and detects new malware and blocks it within seconds. BAFS relies on a couple of configurations.
- Cloud protection
- Sample submissions (Send all samples automatically/ send safe samples automatically)
- Cloud extended timeout period (recommended to use 50)
The combination of the above three settings enables block at first sight (BAFS). Block at first sight detects new malware and blocks it within some seconds. To get BAFS enabled it is needed to configure the above configuration. When all items are configured Block at first sight is correctly enabled.
Emergency updates
Microsoft Defender Antivirus uses cloud-delivered protection/ MAPS) to periodically download dynamic security intelligence updates to provide more protection. These dynamic updates are pushed automatically. Microsoft can push emergency updates via MAPS. Make sure that cloud-delivered protection is correctly enabled.
Knowing the unknown with device discovery
Ideally, there is a CMDB where all assets are available and correctly registered. In almost all environments, there are “unknown” devices. New onboarded machines outside the process/ test machines or playgrounds are often. For Defender for Endpoint and the threat landscape, it is critical to make sure all devices are covered by Defender for Endpoint.
With the use of Defender for Endpoint Device Discovery it is possible to discover the unmanaged part of the network. Microsoft Defender for Endpoint provides a device discovery capability based on onboarded endpoints to collect, probe, and scan the network to discover unmanaged devices.
The logic detects corporate networks and excludes private networks automatically. It is possible to manually exclude networks or devices from scanning.

Currently, it supports:
- Endpoints
- Network devices (Routers/ switches)
- IoT devices (printers, cameras, scanners)
Defender for Endpoint supports two configurations of discovery (Basic discovery and Standard discovery).

Standard discovery is recommended. This method is based on smart active probing to discover additional information. Standard discovers minimal information using the SenseNDR.exe.
All devices are visible in the device inventory – filter for can be onboarded/Unsupported/Insufficient info state for MDE-related devices.

Use KQL for getting all machines part of the discovery
DeviceInfo
| summarize arg_max(Timestamp, *) by DeviceId
| where isempty(MergedToDeviceId)
| where OnboardingStatus != "Onboarded"
Authenticated scans

Microsoft Defender for Endpoint device discovery can scan the network based on endpoints. With the use of the authenticated network device discovery more in-depth scanning is possible based on dedicated MDE devices and SNMP authentication for deeper analysis. Authenticated scans will be explained in a separate blog.
The device discovery feature is critical for the Automatic Attack Disruption feature.
With the leverage of Defender for Endpoint device discovery and containment, it is possible to detect unmanaged devices and block incoming/outgoing communication with the suspected device. With this approach the contain action is way more powerful, since attackers can use unmanaged devices as part of the network.
Attackers leverage mostly unmanaged devices for performing advanced attacks. With the use of device contain it is possible to contain the unmanaged devices, even when the machine is not onboarded to Defender.
For the contain and attack disruption functionality it is needed to configure the standard discovery mode. This discovery is active and based on common discovery protocols/ multicast with smart active probing.
Using the portal and all available data/ insights
Defender for Endpoint is not an “install, roll-out, and completed” product. The main work starts when all devices are onboarded and data is collected. I have seen many organizations rolling it out quickly and forgetting all the features part of Defender for Endpoint.
Maintaining Defender daily is critical and needed for getting most of the benefits out of the product. It starts with a couple of main parts:
- New incidents/ Alerts
- New Vulnerabilities
- New threat reports
- Responding to incidents
- Patch vulnerabilities
Vulnerability management
With the use of the Defender for Endpoint sensor it collects vulnerabilities. There are many vulnerabilities, and managing them all is not possible. Prioritizing the work based on the impact score. MDE knows the number of CVEs and the exploit that is being actively exploited in the wild.

Tip: Create an update/vulnerability process; ideally create a team for reviewing the vulnerabilities daily/ weekly and update all software/ perform actions. Try to make the exposure score lower by patching the most critical recommendations. |
Focus not only on software vulnerabilities, all software configurations are useful for making the endpoint baseline more strict. When there are device groups configured it is easy to give separate insights based on the device groups (Servers/ Linux/ Windows Endpoints e.d)

Review automated actions and portal activities
Automated investigation/ device quarantine and some other AV-related actions can be useful. In some cases, Defender for Endpoint detects and remediates automatically files. When alerts are automatically resolved it is not always visible. With the use of the action center, there are more insights available.
The action center is not only scoped on “new” actions; all historic actions are available via the History tab. Action center is available via Actions & submissions:

History contains all performed actions. This view contains for example the isolated device feature/ quarantine file action part of the automated investigation or AV quarantine items:

The quarantine file action contains all related information and allows the security team to restore the quarantine file actions for specific actions or all instances.

For quarantine file actions there is a “devices by” field. When the field is filled in with Automation the file is automatically quarantined. Microsoft Defender AV is scoped on items quarantined by the Defender AV process.

Live response auditing?
The action center contains auditing for the live response feature. When opening the investigation page for a live response command action it shows the complete historical view and performed commands:

The investigation page contains an image snapshot of the console and command log including all performed actions and commands. All data is visible; including the session started/ session ended and total duration.

Common mistake; No tamper protection
There are still organizations not enabling tamper protection for the following reasons;
- We need to manage devices
- Developers are allowed to add/ change settings
- Performance issues
There is no reason for disabling tamper protection; each machine needs to be protected with tamper protection against malicious changes in the Defender AV/ EDR solution. Without Tamper Protection it is easy to bypass core protection features.
As already mentioned in the series; there are for Windows a couple of ways of enabling tamper protection:
- Via Defender for Endpoint portal – advanced features
- Via Microsoft Endpoint Manager Intune
Advanced features: Enabled via advanced features part of security.microsoft.com

Intune: Using Microsoft Defender Antivirus profile in the Endpoint Security – Antivirus blade

Recently Microsoft announced the new tamper protection feature for exclusions. If you manage exclusions exclusively through Intune with both tamper protection and DisableLocalAdminMerge enabled, there is protection for exclusions where exclusions are managed by Intune. Exclusions are managed when configuring:
- DisableLocalAdminMerge
- Tamper Protection is deployed using Intune
Tip: Deploy tamper protection using the Intune configuration and Defender for Endpoint service settings. Deploy both so exclusions are protected and there is always a fallback when the cloud protection service is not available. Tamper protection via security.microsoft.com requires cloud protection to be fully enabled. |
Based on my opinion tamper protection must be always enabled. The new troubleshooting mode can be used during troubleshooting situations to disable the features for troubleshooting. Sometimes customers like to disable Microsoft Defender during troubleshooting and not configure tamper protection, which makes a security cap. The new troubleshooting mode is fixing this request, where teams have more flexibility. View the in-depth troubleshooting blog here.
Local admin
When using an endpoint with local admin permissions it is recommended to restrict the following registry location: ( to avoid policy changes)
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender\Policy Manager

This registry location can be restricted with a custom policy in Intune/ GPO or other systems. For Intune use a custom OMA-URI profile or settings catalog and configure the following value:
OMA-URI | ./Device/Vendor/MSFT/Defender/Configuration/HideExclusionsFromLocalAdmins |
Data type | Integer |
Value | 1 |
OMA-URI | ./Device/Vendor/MSFT/Defender/Configuration/HideExclusionsFromLocalUsers |
Data type | Integer |
Value | 1 |
HideExclusionsFromLocalAdmins restricts the view. If the value is set to 1, it blocks all access to the policy location in the policy manager:

Common mistake; No updates deployed
Defender for Endpoint requires a couple of monthly/daily updates to get new features and updates. Important to make sure the updates are working correctly and are accepted.
When using WSUS/ Configuration Manager; try to move to more modern solutions – based on real experience all issues start with WSUS/ Configuration Manager and corrupt update packages. Issues with syncing the catalog, corrupt databases, and no maintenance. Try to move to a cloud-managed distribution (MicrosoftUpdate) for at least the signature updates.
Defender for Endpoint/ Defender AV needs to be updated with recent updates. The following updates are important. Don’t forget KB5005292 which is required for the 2012R2/ 2016 EDR sensor part of the unified agent.
Update | KB | Description |
---|---|---|
Update for Defender antimalware platform (AmProductVersion) | KB4052623 | It is critical to make sure Defender platform is updated with the latest version, to get the latest technology and features |
Security Intelligence updates | KB2267602 | Defender AV requires Security Intelligence Updates/ Signature updates |
Update for EDR sensor (2012R2/ 2016) | KB5005292 | This update includes updates and fixes to the EDR sensor that is used by MDE for 2012R2/ 2016 |
I still see many environments where the Update for EDR sensor (2012R2/ 2016) is not deployed in the environment. It is needed to deploy the update since SENSE requires new updates
Common mistakes; not changing installation files
When installing Defender via GPO or another management system the source files are used. A good example is when installing Defender on 2012R2/ 2016 machines. It requires MSI files/ updates and onboarding files.
When deploying it is recommended to update the source files a couple of times a year. Microsoft improves the installers and onboarding packages – when updating the source files the known bugs are solved and the monthly Defender platform version and sense version are already included in the MSI.
Common mistake; Exclusions
Before starting with deploying Defender for Endpoint make sure the preventions as already explained are correctly configured:
- DisableLocalAdminMerge
- Tamper Protection
- HideExclusionsFromLocalAdmins (when users are local admin)
In Intune, DisableLocalAdminmerge can be configured using the setting “Disable Local Admin Merge” Configure the setting to the following: (I know it is a bit confusing with the name convention in Intune)

When configured on “Disable Local Admin Merge” the local exclusion list added via local Group Policy, PowerShell UI is not merged with the effective policy.
For exclusions, it is recommended to hide the exclusions, as already explained above. This is possible via the settings catalog in Intune or a custom OMA-URI setting:
OMA-URI | ./Device/Vendor/MSFT/Defender/Configuration/HideExclusionsFromLocalAdmins |
Data type | Integer |
Value | 1 |
OMA-URI | ./Device/Vendor/MSFT/Defender/Configuration/HideExclusionsFromLocalUsers |
Data type | Integer |
Value | 1 |
Each vendor shares most of the time a large list of exclusions. A good example of Veaam advice; excluding the complete C:\Program Files\Veeam\ folder. Good job!! All it is great for running malware directly from a folder (-;
Even when the vendor shares a large list of exclusions review each exclusion, based on experience most of the applications run well without the vendor-recommended exclusions. When needed use procmon/ performance analyzer or more in-depth toolings for checking specific paths. More information:
Add only exclusion when there is a critical need (performance issues/ compatibility issues). And never, never migrate old exclusions!!
When using exclusion make sure it is documented (ticket number, reason, troubleshooting details). Defining exclusions lowers the protection offered by Microsoft Defender Antivirus.
Explanation of the exclusions is not part of the MDE series with a reason. Fabian Bader published an in-depth exclusions guide with almost all related information. Must read!!!
Fabian Bader/ Cloudbrothers.info: The Hitchhiker’s Guide to Microsoft Defender for Endpoint exclusions
Common mistake; Only network protection configured without SmartScreen
Network protection is critical in combination with Defender for Endpoint network indicators and web content filtering. For blocking indicators the Network protection feature must be enabled in block mode. Network protection is an attack surface reduction capability, and prevents access to dangerous domains or custom-blocked indicators.
The network protection component of Defender for Endpoint identifies and blocks connections to C2 infrastructures used in ransomware attacks. Blocking C2 attacks makes Network Protection more important.
Enable SmartScreen for Edge and include the SmartScreen potentially unwanted app feature (removes the yellow warning of Defender). Don’t forget to enable SmartScreen for all components (Windows Explorer)
For Microsoft Edge browsers Defender SmartScreen must be enabled.
Always test and confirm the protection state – this validates that the actual configuration is working correctly on the endpoints.
Common mistake; disabling auto-remediation
Currently, 5 different levels of remediation are available. Full automation is recommended and has been configured by default since 2021 for new tenants. I still see environments where the automated investigation is completely disabled for all machines.

When AIR is disabled (No automated response) there is no automated investigation. Full automation has proven to be reliable, efficient, and safe, and is recommended for all customers. Full automation frees up your critical security resources so they can focus more on your strategic initiatives.
When full automated response is not possible – configure at least one of the semi-levels. Avoid disabling AIR completely, since this lacks in the protection and attack disruption capabilities.
Attack Disruption
Attack Disruption relies on the auto-remediation feature for a couple of flows. It is recommended to use full automated response when possible since this improves the 24/7 protection posture.
More information: Automatic attack disruption in Microsoft Defender XDR and containing users during Human-operated Attacks
Common mistake; Running in passive mode
Passive mode is completely fine, based on experience seeing so many examples where Defender is running in passive mode without any other AV. This means; Defender is the only AV that is installed and running in passive mode.
Don’t focus only on the health state of the sensor; since this is only applicable to the SENSE sensor and not the Defender AV component.

Use Advanced Hunting or TVM Security Recommendation to view devices that are inactive/ disabled. Overview of all devices and detected AV mode (Active, Passive, EDR block)
let avmodetable = DeviceTvmSecureConfigurationAssessment
| where ConfigurationId == "scid-2010" and isnotnull(Context)
| extend avdata=parsejson(Context)
| extend AVMode = iif(tostring(avdata[0][0]) == '0', 'Active' , iif(tostring(avdata[0][0]) == '1', 'Passive' ,iif(tostring(avdata[0][0]) == '4', 'EDR Blocked' ,'Unknown')))
| project DeviceId, AVMode;
DeviceTvmSecureConfigurationAssessment
| where ConfigurationId == "scid-2011" and isnotnull(Context)
| extend avdata=parsejson(Context)
| extend AVSigVersion = tostring(avdata[0][0])
| extend AVEngineVersion = tostring(avdata[0][1])
| extend AVSigLastUpdateTime = tostring(avdata[0][2])
| project DeviceId, DeviceName, OSPlatform, AVSigVersion, AVEngineVersion, AVSigLastUpdateTime, IsCompliant, IsApplicable
| join avmodetable on DeviceId
| project-away DeviceId1
Common mistake; Not using Advanced Hunting/ Custom detections
Advanced Hunting is powerful. Out of the box Defender for Endpoint is not alerting for all activities. Advanced Hunting is powerful enough to create additional detection and close the detection caps. Since a lot of data can be found in the Advanced Hunting dataset.

With custom detections, you can proactively monitor for and respond to various events and system states, including suspected breach activity and misconfigured endpoints, and automate response actions. With the availability of data, there are many use cases to use the customs detection capabilities.
Common mistake; Not using Defender for Cloud Apps
Defender for Cloud Apps is integrated into Defender XDR. With the use of Defender for Cloud Apps it is possible to enrich more data in the Advanced Hunting dataset for free without the need to onboard Microsoft Sentinel.
Via the Cloud App settings in Microsoft Defender XDR it is possible to configure additional App Connectors, by default nothing is configured.
My recommendation is to use at least the following connectors:
- Microsoft Azure
- Microsoft 365
This will result in more data in Advanced Hunting, which can be useful in the relation of Defender for Endpoint data. All is part of the Microsoft E5 license, and there is no additional cost required for the ingested data. Data is available in the CloudAppEvents table in Advanced Hunting

Common mistake; Attack Disruption not correctly configured
Attack Disruption is powerful in Defender XDR, it works out of the box. This feature is extremely powerful and helps to limit the impact during attacks. In the past months, I have seen personally quite some attacks in larger environments prevented further by the Attack Disruption capabilities.

Make sure to configure the features and prerequisites in all the related products.
misread the MS page, my error
I find this article very interesting and well written. I can relate and contribute to the things you point out here. Thanks for sharing! 🙂
Amazing article.
We have everything on-prem at the moment.
We use Sccm and group policy, but want to use endpoint manager portal to manage all the settings for antivirus, attack surface reduction etc..
Ive seen there is more settings in GPO then in SCCM, but want to do it all within endpoint for security portal. Can this be done and be assigned to registered on prem ad servers/desktops or do they need to be hybrid aad joined?
We do have azure arc but only for esu 2012 sql servers atm.
Whats the best approach to have everything and managed in one place?
Best practisch is to move slowly to Intune for the devices.
For servers view this blog to manage with MDE Management, this is without a fully Intune join requirement, and possible for servers.
https://jeffreyappel.nl/manage-mde-for-windows-macos-and-linux-via-security-settings-management/
Hi Jeffrey,
we are facing some issue regarding defender after migrating the tenant.
we offboarded servers from old tenant and onboarded them to the new tenant, but error shows that “TenantMismatch”
https://prnt.sc/4IHQGr_S9khs
Is the device still connected to the old EntraID tenant, looks like the AAD registration is still in relation with the old tenant.
One object can be registrered once in EntraID, so expect you need to migrate the devices also from EntraID/ AzureAD.
yes, it was. I checked with “dsregcmd /status” found old tenant ID. so I left the tenant by using “dsregcmd /leave”
two options to join hybrid:
GPO:
Computer Configuration > Administrative Templates > Windows Components > Device Registration: “Specify the authentication service for hybrid Azure AD joined devices.”
https://enterpriseregistration.windows.net/
or
with Registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin
Create or modify the following registry value:
Name: TenantUrl
Type: REG_SZ (String Value)
Value: https://enterpriseregistration.windows.net/
Offboarded (in new tenant) and onboarded again and it worked!
Note: restart not required.
*Corrected*
yes, it was. I checked with “dsregcmd /status” found old tenant ID. so I left the tenant by using “dsregcmd /leave”
two options to join hybrid:
GPO:
Computer Configuration > Administrative Templates > Windows Components > Device Registration: “Specify the authentication service for hybrid Azure AD joined devices.”
https://enterpriseregistration.windows.net/
or
with Registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin
Create or modify the following registry value:
Name: TenantUrl
Type: REG_SZ (String Value)
Value: https://enterpriseregistration.windows.net/
Offboarded (in new tenant) and onboarded again and it worked!
Note: restart not required.
in registry the correct value is
Value: https://enterpriseregistration.windows.net/YourTenantID