Microsoft Defender for Endpoint Setup Guide for IT Admins

You've been tasked with rolling out Microsoft Defender for Endpoint (MDE) across your organization. The marketing pages make it sound simple—"just deploy and protect." Anyone who's actually done this knows better. Between onboarding methods, policy configurations, exclusions that break production apps, and the maze of Azure AD prerequisites, there's plenty of room to get this wrong.

This guide walks through a real-world MDE deployment from zero to operational. No hand-waving, no screenshots of the security center—actual configurations, actual PowerShell, actual gotchas.

Prerequisites That Will Block You If You Skip Them

Before touching a single endpoint, verify your licensing and Azure AD setup. MDE requires one of: Microsoft 365 E5, Microsoft 365 E5 Security, Microsoft Defender for Endpoint P1/P2 standalone, or Windows 10/11 Enterprise E5.

Check your current licenses in the M365 admin center or via PowerShell:

Connect-MgGraph -Scopes "Organization.Read.All"
Get-MgSubscribedSku | Select-Object SkuPartNumber, ConsumedUnits, PrepaidUnits | Format-Table

# Look for these SKU part numbers:
# ENTERPRISEPREMIUM (M365 E5)
# IDENTITY_THREAT_PROTECTION (M365 E5 Security)
# WIN_DEF_ATP (Standalone MDE)

Your Azure AD tenant needs to be the same tenant where you'll manage MDE. Sounds obvious, but I've seen organizations with historical M&A baggage running multiple tenants—MDE won't span them without additional architecture.

Enable the MDE service in the Microsoft 365 Defender portal (security.microsoft.com) under Settings > Endpoints > Advanced features. Turn on:

• Live Response (you'll need this for incident response)
• Automated Investigation (set to Semi or Full depending on your risk appetite)
• EDR in block mode (critical for non-Microsoft AV coexistence)
• Custom network indicators (if you're doing IOC blocking)

Device Onboarding: Choose Your Path

MDE supports multiple onboarding methods. Your choice depends on your existing management stack:

Environment	Recommended Method
Intune-managed	Endpoint security policies
SCCM/MECM	Co-management or SCCM package
Domain-joined, no MDM	GPO deployment
Linux servers	Package manager + onboarding script
Non-domain workgroup	Local script

For Intune (the cleanest path), create an Endpoint Detection and Response policy:

1. Intune admin center > Endpoint security > Endpoint detection and response
2. Create a profile for Windows 10/11
3. The only required setting is pointing to your tenant—Intune handles the rest

For environments without Intune, grab the onboarding package from security.microsoft.com > Settings > Endpoints > Onboarding. Here's a GPO deployment approach using the WindowsDefenderATPOnboardingScript.cmd:

# Create a GPO that runs the onboarding script once
# Store the script on a network share accessible to SYSTEM context

$gpoName = "MDE-Onboarding"
$scriptPath = "\\contoso.com\NETLOGON\MDE\WindowsDefenderATPOnboardingScript.cmd"

# Create new GPO
New-GPO -Name $gpoName | New-GPLink -Target "OU=Workstations,DC=contoso,DC=com"

# Add the startup script via GPMC or:
$gpo = Get-GPO -Name $gpoName
$gpoId = $gpo.Id.ToString()

# Script registration (run from a domain controller or RSAT workstation)
$machineScriptsPath = "\\contoso.com\SYSVOL\contoso.com\Policies\{$gpoId}\Machine\Scripts\Startup"
New-Item -Path $machineScriptsPath -ItemType Directory -Force
Copy-Item -Path "C:\MDEOnboarding\WindowsDefenderATPOnboardingScript.cmd" -Destination $machineScriptsPath

# The scripts.ini needs manual creation in Machine\Scripts\scripts.ini
@"
[Startup]
0CmdLine=$scriptPath
0Parameters=
"@ | Out-File -FilePath "\\contoso.com\SYSVOL\contoso.com\Policies\{$gpoId}\Machine\Scripts\scripts.ini" -Encoding ASCII

Verify onboarding by checking the MDE service status:

# On the endpoint
Get-Service -Name "Sense" | Select-Object Name, Status, StartType
# Should return: Running, Automatic

# Check onboarding state
$regPath = "HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status"
Get-ItemProperty -Path $regPath | Select-Object OnboardingState, OrgId
# OnboardingState = 1 means successfully onboarded

Linux Server Onboarding

Production Linux servers need MDE too. Here's a RHEL/CentOS deployment:

#!/bin/bash
# MDE onboarding for RHEL 8/9

# Add Microsoft repository
sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc
sudo cat > /etc/yum.repos.d/microsoft-prod.repo << 'EOF'
[microsoft-prod]
name=Microsoft Packages
baseurl=https://packages.microsoft.com/rhel/8/prod/
enabled=1
gpgcheck=1
gpgkey=https://packages.microsoft.com/keys/microsoft.asc
EOF

# Install MDE
sudo yum install -y mdatp

# Apply onboarding package (download from security.microsoft.com)
# The JSON file contains your tenant-specific configuration
sudo mdatp config --onboard /tmp/MicrosoftDefenderATPOnboardingLinuxServer.py

# Verify
mdatp health --field org_id
mdatp health --field healthy

# Configure real-time protection (disabled by default on Linux)
sudo mdatp config real-time-protection --value enabled

# Set scan exclusions for high-IO paths
sudo mdatp exclusion folder add --path /var/lib/docker
sudo mdatp exclusion folder add --path /var/log
sudo mdatp exclusion process add --name postgres

Attack Surface Reduction Rules That Actually Work

ASR rules are where MDE goes from "expensive antivirus" to actual threat prevention. But deploy them wrong and you'll break legitimate applications.

Start in audit mode. Always:

# Deploy ASR rules via Intune configuration profile or local PowerShell
# These GUIDs are Microsoft-defined, don't change them

$asrRules = @{
    # Block executable content from email client and webmail
    "BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550" = "AuditMode"
    
    # Block Office apps from creating child processes
    "D4F940AB-401B-4EFC-AADC-AD5F3C50688A" = "AuditMode"
    
    # Block Office apps from injecting into processes
    "75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84" = "AuditMode"
    
    # Block JavaScript/VBScript from launching downloaded content
    "D3E037E1-3EB8-44C8-A917-57927947596D" = "AuditMode"
    
    # Block credential stealing from LSASS
    "9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2" = "AuditMode"
    
    # Block untrusted/unsigned processes from USB
    "B2B3F03D-6A65-4F7B-A9C7-1C7EF74A9BA4" = "AuditMode"
}

foreach ($rule in $asrRules.GetEnumerator()) {
    Add-MpPreference -AttackSurfaceReductionRules_Ids $rule.Key `
                     -AttackSurfaceReductionRules_Actions ($rule.Value -eq "Enabled" ? 1 : 2)
}

Run audit mode for 2-4 weeks. Review events in security.microsoft.com > Reports > Attack surface reduction rules. You'll see exactly what would have been blocked. Create exclusions for legitimate business applications before switching to block mode.

Common exclusions needed:

• Chrome/Firefox updaters triggering child process rules
• Internal PowerShell automation scripts
• PDF software spawning temp processes
• Legacy LOB applications with unusual behaviors

Tuning Alert Fatigue

Out of the box, MDE generates noise. A fresh deployment will flag PowerShell scripts, IT tools like PSExec, and admin activities as suspicious—because they often are, just not malicious in your context.

Create suppression rules in security.microsoft.com > Settings > Endpoints > Alert suppression. Target specific combinations:

• IOC type + specific device groups: Suppress alerts for known admin tools on IT workstations only
• File hash + action: Allow specific scripts by hash rather than broad path exclusions
• User + activity: Your SCCM service account will trigger alerts constantly

Don't suppress broadly. If you're suppressing "All devices" for common alert types, you're creating blind spots. Use device groups to scope suppression tightly.

Validation and Operational Readiness

Before declaring victory, validate the deployment actually works:

# Generate a test detection (EICAR equivalent for EDR)
# This command triggers a benign alert in MDE
powershell.exe -NoExit -ExecutionPolicy Bypass -WindowStyle Hidden $ErrorActionPreference= 'silentlycontinue';(New-Object System.Net.WebClient).DownloadFile('http://127.0.0.1/1.exe', 'C:\\test-WDATP-test\\invoice.exe');Start-Process 'C:\\test-WDATP-test\\invoice.exe'

You should see an alert in the security portal within 15 minutes. If you don't, check: proxy configurations blocking connectivity to *.securitycenter.windows.com, certificate inspection breaking TLS, or the Sense service not running.

Set up your notification workflow. Integrate MDE alerts into your SIEM via the streaming API or configure email notifications in Settings > Endpoints > Email notifications for high-severity alerts.

Build your first hunting query to get familiar with the data:

// Devices not reporting in last 24 hours
DeviceInfo
| summarize LastSeen = max(Timestamp) by DeviceName
| where LastSeen < ago(24h)
| project DeviceName, LastSeen, DaysSilent = datetime_diff('day', now(), LastSeen)
| order by DaysSilent desc

The deployment is done when you have: 95%+ endpoint coverage, ASR rules in block mode with validated exclusions, alert workflows routing to your SOC or managed service, and a documented exception process for future exclusions. Now start hunting.

---

Tools & Resources

Tools relevant to this post. Some links are affiliate links — they cost you nothing and help keep geekoncloud.com running.

• Datadog — cloud monitoring and observability platform
• Snyk — developer-first security and vulnerability scanning
• DigitalOcean — simple and affordable cloud hosting