Deploying Microsoft Defender for Endpoint: Onboarding, ASR Rules, and EDR in Block Mode

Microsoft Defender for Endpoint (MDE) is the EDR/EPP that backs the Microsoft Defender XDR portal. Buying the license does almost nothing on its own — the value comes from getting devices onboarded, hardening the attack surface, and letting the platform respond automatically. This guide walks the rollout I run on Windows fleets: onboard via Intune, tune ASR in audit-first, then enable EDR in block mode and AIR.

1. Licensing and the two plans

MDE ships in two SKUs, and the difference matters for what you can actually configure:

Capability	Plan 1	Plan 2
Next-gen antivirus, ASR rules, device control	Yes	Yes
Manual response (isolate, restrict, AV scan)	Yes	Yes
EDR with behavioral detections	Limited	Full
Automated Investigation & Response (AIR)	No	Yes
Threat & Vulnerability Management (Defender TVM)	No	Yes
Advanced hunting, custom detections	No	Yes

Plan 2 is included in Microsoft 365 E5, E5 Security, and Windows E5. ASR rules and tamper protection work on Plan 1, but EDR in block mode, AIR, TVM, and custom detection rules — most of this article — require Plan 2. Confirm your entitlement before you design around features you can’t enforce.

2. Onboarding paths

Every device sends telemetry only after it’s onboarded. There are three mechanisms; pick by how the device is managed.

Path	Best for	Mechanism
Intune / MDM	Cloud-managed Windows clients	Endpoint security policy or auto-onboard via Defender connector
Group Policy / Config Mgr	Domain-joined, on-prem servers	Onboarding script + scheduled task or ConfigMgr collection
Local script	Pilots, test rings, one-offs	WindowsDefenderATPOnboardingScript.cmd from Settings

Connect Intune to Defender first

In the Microsoft Defender portal (security.microsoft.com) go to Settings -> Endpoints -> Advanced features and turn on Microsoft Intune connection. Mirror it in Intune at Endpoint security -> Microsoft Defender for Endpoint by setting Allow Microsoft Defender for Endpoint to enforce Endpoint Security Configurations to On. This lets Intune push onboarding without distributing a script.

Onboard Windows clients via Intune

Create an EDR policy under Endpoint security -> Endpoint detection and response:

Intune admin center -> Endpoint security -> Endpoint detection and response -> Create Policy
  Platform: Windows
  Profile:  Endpoint detection and response
  Settings:
    Microsoft Defender for Endpoint client configuration package type: Auto from connector
    Sample sharing for all files: All
    Expedite telemetry reporting frequency: Yes (for high-value devices)
  Assign: your "MDE - Pilot Ring" device group

With the connector live, the onboarding blob is injected automatically — you don’t paste a package. Devices appear in the Defender portal device inventory within minutes of the policy applying.

Onboard servers

Windows Server 2019/2022/2025 onboard like clients through Intune, Defender for Cloud, or the script. For Server 2012 R2 / 2016, use the modern, unified MDE solution (the standalone installer md4ws.msi) rather than the legacy MMA/SCEP agent, which is retired:

# Run elevated on Windows Server 2012 R2 / 2016
msiexec /i md4ws.msi /quiet

# Then onboard with the server-specific local script from
# Defender portal -> Settings -> Endpoints -> Onboarding -> "Windows Server 2012 R2 and 2016"
.\WindowsDefenderATPLocalOnboardingScript.cmd

The cleanest path for Azure VMs is to let Microsoft Defender for Cloud auto-provision the MDE extension when you enable the Servers plan — no per-VM script.

Verify onboarding from the host

# Connectivity + onboarding state (run elevated)
Get-MpComputerStatus | Select-Object AMRunningMode, AMServiceEnabled, RealTimeProtectionEnabled

# Onboarding flag in the registry (1 = onboarded)
Get-ItemPropertyValue 'HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status' -Name OnboardingState

AMRunningMode should read Normal (Defender is the active AV) or EDR Block Mode once that’s enabled. If you see Passive, a third-party AV is primary — that’s fine for EDR but ASR and next-gen protection won’t fully enforce until Defender is in active or block mode.

3. Next-gen protection settings

Before hardening the attack surface, get the antivirus engine configured correctly. Push these through an Antivirus policy in Endpoint security -> Antivirus -> Windows.

The settings that actually move the needle:

• Cloud-delivered protection (MAPS): Enabled — this is the cloud backend behind most modern detections. Without it you lose the bulk of MDE’s signal.
• Cloud block timeout extension: raise to 50 seconds so the cloud has time to verdict a suspicious file before it executes.
• Cloud protection level: High or High plus for high-value rings.
• Submit samples consent: Send safe samples automatically (the common balance) or Send all samples for hardened rings. Avoid Never send — it blinds the cloud.
• Tamper protection: Enabled — prevents malware (and local admins) from disabling Defender. Manage it from Intune or the Defender portal, not local registry edits.

# Equivalent local config (Intune is the source of truth in production)
Set-MpPreference -MAPSReporting Advanced
Set-MpPreference -SubmitSamplesConsent SendSafeSamples
Set-MpPreference -CloudBlockLevel High
Set-MpPreference -CloudExtendedTimeout 50
# Tamper protection is enforced via Intune/portal, not Set-MpPreference

Tamper protection is non-negotiable. Turn it on tenant-wide early. Once on, attackers can’t Set-MpPreference -DisableRealtimeMonitoring $true their way past you, and neither can a curious admin.

4. Attack Surface Reduction rules — audit first

ASR rules block the behaviors malware relies on: Office spawning child processes, credential theft from LSASS, script-launched executables, and more. Each rule has three states — Not configured (0), Block (1), and Audit (2) — plus Warn (6) for a subset.

The cardinal rule: deploy in Audit first. ASR rules can break legitimate line-of-business apps and macros. Run audit for one to two weeks, review what would have been blocked, exclude the false positives, then flip to Block.

Configure ASR via Endpoint security -> Attack surface reduction -> Create Policy -> Attack Surface Reduction Rules. Start with this high-value set, all in Audit:

Rule	GUID	Notes
Block credential stealing from LSASS	9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2	High value, low breakage
Block Office apps creating child processes	d4f940ab-401b-4efc-aadc-ad5f3c50688a	Watch macro-heavy apps
Block Office from creating executable content	3b576869-a4ec-4529-8536-b80a7769e899
Block executable content from email/webmail	be9ba2d9-53ea-4cdc-84e5-9b1eeee46550
Block JS/VBS from launching downloaded content	d3e037e1-3eb8-44c8-a917-57927947596d
Block process creations from PSExec and WMI	d1e49aac-8f56-4280-b9ba-993a6d77406c	Can hit ConfigMgr/RMM tooling
Block persistence via WMI event subscription	e6db77e5-3df2-4cf1-b95a-636979351e5b	No audit mode; deploy as Block
Block untrusted/unsigned processes from USB	b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4

The same rules can go through PowerShell for a pilot box:

# Set the LSASS rule to Audit (2). 1 = Block, 6 = Warn, 0 = Off
Add-MpPreference -AttackSurfaceReductionRules_Ids 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 `
                -AttackSurfaceReductionRules_Actions Enabled   # Enabled = Block

# Confirm current rule states
Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids
Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Actions

A handful of rules (WMI persistence is the classic example) have no audit mode. Validate those on a small pilot ring before broad deployment, since you can’t preview their impact passively.

Reviewing audit results

After a week, query what the rules caught using advanced hunting in the Defender portal:

DeviceEvents
| where Timestamp > ago(7d)
| where ActionType startswith "Asr"
| summarize Count = count() by ActionType, FileName, FolderPath
| order by Count desc

ActionType ending in Audited is what would have been blocked. Add path or certificate exclusions for the legitimate hits, then change those rules to Block.

5. Web content filtering, controlled folder access, network protection

Three more attack-surface controls, all in the Attack surface reduction policy area.

Network protection must be enabled (block mode) for web content filtering and web threat protection to enforce — in audit mode they only log. Set it via the ASR policy or:

Set-MpPreference -EnableNetworkProtection Enabled   # Disabled | AuditMode | Enabled

Web content filtering is configured in the portal at Settings -> Endpoints -> Web content filtering: build policies that block categories (gambling, malware, newly registered domains) and scope them to device groups. It rides on Network protection, so enable that first.

Controlled folder access (CFA) is targeted ransomware protection — it blocks untrusted processes from writing to protected folders (Documents, Desktop, and any you add). Like ASR, start in Audit, because CFA frequently blocks legitimate apps that write to user folders:

Set-MpPreference -EnableControlledFolderAccess AuditMode
Add-MpPreference -ControlledFolderAccessAllowedApplications "C:\Apps\lob-tool.exe"

Review CFA audit events, allow the legit apps explicitly, then move to Enabled.

6. EDR in block mode and AIR

EDR in block mode

EDR in block mode lets MDE remediate post-breach artifacts that the primary antivirus missed — even when a third-party AV is your active product and Defender is in passive mode. It is not a replacement for real-time protection; it’s the safety net behind it. Enable it once, tenant-wide:

Defender portal -> Settings -> Endpoints -> Advanced features
  Enable EDR in block mode: On

After it applies, Get-MpComputerStatus reports AMRunningMode: EDR Block Mode on passive-AV machines. On machines where Defender is already the active AV, you get the protection inherently.

Automated Investigation & Response

AIR is the force multiplier: when an alert fires, MDE automatically investigates the device, correlates artifacts, and can remediate (quarantine files, kill processes, remove persistence) without an analyst. Configure the automation level per device group:

Defender portal -> Settings -> Endpoints -> Device groups -> (group) -> Edit
  Automation level: Full - remediate threats automatically

Levels run from No automated response up to Full - remediate threats automatically. Start pilot/server groups at Semi - require approval for any remediation so you can see AIR’s reasoning, then graduate well-understood client groups to Full. Review the work under Incidents & alerts -> Investigations, where each automated investigation shows the entities examined and the verdict.

7. Device discovery and Defender TVM

Device discovery uses your onboarded endpoints as sensors to find unmanaged devices on the same network — the rogue NAS, the unpatched printer, the shadow-IT laptop. Set it to Standard discovery under Settings -> Endpoints -> Device discovery; unmanaged devices then surface in the inventory so you can onboard or isolate them.

Threat & Vulnerability Management (Defender TVM, Plan 2) continuously inventories software and surfaces CVEs and misconfigurations, rolled up into an exposure score (lower is better) and a Microsoft Secure Score for Devices. The actionable view is Vulnerability management -> Recommendations, sorted by exposure impact. From there you can push a remediation request straight into Intune as a task — closing the loop between “you have this CVE” and “here’s the deployment that fixes it.”

8. Custom detection rules and live response

Custom detection rules turn an advanced-hunting KQL query into a scheduled detection that raises alerts and can trigger response actions. Example — flag LSASS access by an unusual process:

DeviceProcessEvents
| where Timestamp > ago(1h)
| where InitiatingProcessFileName !in~ ("lsass.exe", "MsMpEng.exe", "csrss.exe", "wininit.exe")
| where FileName =~ "rundll32.exe" and ProcessCommandLine has "comsvcs.dll"
| project Timestamp, DeviceId, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine

Save it via Advanced hunting -> (run query) -> Create detection rule: set frequency, severity, the impacted entities, and an automated action such as Isolate device or Collect investigation package.

Live response gives an analyst a remote shell to the device for hands-on triage. Enable it under Advanced features (and Live response for servers separately). The session is fully audited:

# In a live response session (Defender portal -> device -> Initiate live response)
getfile C:\Users\Public\suspicious.exe     # pull an artifact to the portal
processes                                  # list running processes
analyze file C:\Users\Public\suspicious.exe  # detonate/inspect
remediate file C:\Users\Public\suspicious.exe

Enterprise scenario

A logistics company moved its ASR set from Audit to Block for a 9,000-seat fleet and within an hour the service desk was buried: the warehouse management thick client and a finance VBA add-in both stopped launching. The culprit was d4f940ab-401b-4efc-aadc-ad5f3c50688a (Block Office apps from creating child processes) and 3b576869-a4ec-4529-8536-b80a7769e899 (Block Office from creating executable content). The team had run audit, but only queried the last 7 days — month-end finance macros that triggered the add-in had never executed during the audit window, so the breakage was invisible until enforcement.

The fix was twofold. First, widen the audit lookback and pivot on the rule GUID, not just ActionType, to catch low-frequency offenders before flipping anything:

DeviceEvents
| where Timestamp > ago(45d)
| where ActionType == "AsrOfficeChildProcessAudited"
| summarize Hits = count(), Devices = dcount(DeviceId), Last = max(Timestamp)
    by FolderPath, InitiatingProcessFileName
| order by Hits desc

Second, instead of disabling the rules, they scoped a per-app exception with the dedicated ASR exclusion setting (not the AV exclusion list, which ASR ignores for these rules), keeping the rules in Block everywhere else:

Add-MpPreference -AttackSurfaceReductionOnlyExclusions "C:\Apps\WMS\wms.exe"

The lesson the platform team wrote into their runbook: an ASR audit is only as good as its longest business cycle. For anything finance- or quarter-end-driven, audit through at least one month-end close before enforcing, and review by GUID and folder path rather than eyeballing aggregate counts.

Verify

Validate the rollout end to end before declaring it done:

1. Onboarding — device shows Active in the Defender portal inventory; OnboardingState = 1 on the host.
2. EICAR (antivirus) — drop the harmless EICAR test string into a file and save. Defender should quarantine it instantly and raise an alert.

   # This WILL be detected/quarantined — that's the point
   'X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' |
     Out-File -FilePath "$env:TEMP\eicar.com" -Encoding ascii
   

3. WICAR (web protection) — browse to a WICAR test page from a device with Network protection in block mode; the connection should be blocked and logged under web protection.
4. ASR — trigger an audited rule (e.g., have Word launch cmd.exe on a pilot box) and confirm the Asr...Audited/Blocked event in advanced hunting.
5. Device timeline — open the device in the portal, go to the Timeline tab, and confirm the test events (EICAR, ASR, web block) appear in chronological order with full process context.
6. AIR — confirm an automated investigation kicked off for the EICAR alert under Investigations.

Rollout checklist

• Plan 2 entitlement confirmed for EDR/AIR/TVM features
• Intune <-> Defender connector enabled both directions
• Pilot ring onboarded via Intune; servers via unified MSI / Defender for Cloud
• Cloud-delivered protection + sample submission on; tamper protection enforced
• ASR high-value set deployed in Audit, reviewed, then enforced to Block
• Network protection, web content filtering, CFA enabled (CFA audited first)
• EDR in block mode on tenant-wide
• AIR automation level set per device group (semi -> full as confidence grows)
• Device discovery set to Standard; unmanaged devices triaged
• TVM recommendations reviewed; remediation tasks pushed to Intune
• Custom detection rules created; live response enabled and access-controlled
• EICAR/WICAR validated and visible in the device timeline

Pitfalls and next steps

• Skipping audit mode for ASR/CFA is the fastest way to break production and lose stakeholder trust. Audit, review, exclude, then block — every time.
• Forgetting tamper protection leaves every other control one Set-MpPreference away from being disabled. It’s the foundation, not an extra.
• Network protection left in audit silently no-ops web content filtering. It must be in block mode to enforce.
• EDR block mode is not real-time AV. If a third-party product is primary, keep it healthy; block mode only cleans up what slips past.
• Legacy server agents (MMA/SCEP) are retired — always onboard older servers with the unified MDE solution.

Once the baseline is stable, wire MDE alerts and the device timeline into Microsoft Sentinel, then expand the ring rollout from pilot to broad. From there, graduate AIR to full automation on well-understood client groups and let TVM drive your patch priorities — that’s when MDE stops being an agent on a box and starts being an operating model.