How to Set Up Microsoft Defender for Endpoint on Windows Server 2025

Microsoft Defender for Endpoint (MDE) is Microsoft’s cloud-powered extended detection and response (EDR) platform. While Windows Defender Antivirus provides local antimalware protection, MDE adds a powerful layer of behavioral analysis, threat intelligence correlation, live response capabilities, and centralized investigation through the Microsoft 365 Defender portal. Windows Server 2025 is a supported MDE target and benefits from native integration with the Windows Security Center — making the onboarding process significantly cleaner than on older server operating systems. This guide covers the complete MDE deployment journey: from downloading the onboarding package to configuring attack surface reduction rules, building device groups, and running your first advanced hunting queries in KQL.

Prerequisites

Windows Server 2025 (any edition) with internet access or proxy configured for MDE endpoints
Microsoft Defender for Endpoint Plan 2 or Microsoft 365 E5 / E5 Security license
Access to the Microsoft 365 Defender portal (security.microsoft.com) with Security Administrator role
Local Administrator privileges on each server to be onboarded
Windows Defender Antivirus running in Normal or Passive mode (not fully disabled)
PowerShell 5.1 or later
Required MDE service endpoints whitelisted in your firewall (see Microsoft documentation for the full URL list)

Step 1: Download the MDE Onboarding Package

The onboarding package is generated in the Microsoft 365 Defender portal and is specific to your tenant. It embeds the tenant ID and workspace credentials needed to associate your server with your MDE instance.

Sign in to security.microsoft.com with a Security Administrator account.
Navigate to Settings → Endpoints → Device Management → Onboarding.
From the operating system dropdown, select Windows Server 2019 and 2022 and 2025.
Select Local Script as the deployment method (for individual servers) or Group Policy for fleet deployment.
Click Download onboarding package and save the ZIP file securely — it contains credentials specific to your tenant.

# On the target server — extract the onboarding package
Expand-Archive -Path "C:MDEOnboardingWindowsDefenderATPOnboardingPackage.zip" `
    -DestinationPath "C:MDEOnboardingExtracted" -Force

# Navigate to the extracted folder and run the onboarding script
Set-Location "C:MDEOnboardingExtracted"
dir  # Confirm WindowsDefenderATPOnboardingScript.cmd is present

Step 2: Run the Onboarding Script

The WindowsDefenderATPOnboardingScript.cmd configures the local Windows Sense service, sets registry keys pointing to your tenant’s MDE workspace, and starts the initial data sync. Run it from an elevated command prompt or PowerShell session.

# Run the onboarding script from elevated PowerShell
Start-Process -FilePath "cmd.exe" -ArgumentList `
    "/c C:MDEOnboardingExtractedWindowsDefenderATPOnboardingScript.cmd" `
    -Verb RunAs -Wait

# Alternative: run directly from an elevated CMD prompt
# WindowsDefenderATPOnboardingScript.cmd

# Verify the SENSE service started successfully
Get-Service -Name Sense | Select-Object Name, Status, StartType

# Confirm the service is running
(Get-Service -Name Sense).Status -eq "Running"

The SENSE service (Windows Defender Advanced Threat Protection Service) should show as Running within 30 seconds of the script completing. If it fails to start, check the event log at Applications and Services Logs → Microsoft → Windows → SENSE for diagnostic information.

Step 3: Verify Successful Onboarding

After running the onboarding script, the server should appear in the Microsoft 365 Defender portal within 5–30 minutes. You can also verify onboarding status locally using PowerShell before checking the portal.

# Check that MDE's EDR component is active
Get-MpComputerStatus | Select-Object `
    AMRunningMode, `
    AMServiceEnabled, `
    OnboardingState

# The AMRunningMode will show "Normal" (WDA is primary AV) or
# "EDR Block Mode" if a third-party AV is installed

# Check the onboarding registry key directly
$mdePath = "HKLM:SOFTWAREMicrosoftWindows Advanced Threat ProtectionStatus"
if (Test-Path $mdePath) {
    Get-ItemProperty -Path $mdePath | Select-Object OnboardingState, OrgId
} else {
    Write-Warning "MDE onboarding registry key not found — onboarding may not have completed"
}

# Confirm SENSE service startup type is Automatic
Set-Service -Name Sense -StartupType Automatic

In the portal, navigate to Assets → Devices and search for your server’s hostname. A newly onboarded device may show a status of Onboarding for up to 24 hours as initial telemetry flows in. The First Seen timestamp confirms when MDE first received data from the device.

Step 4: Configure EDR in Block Mode

EDR in Block Mode allows MDE to remediate malicious artifacts detected by the EDR engine even when a non-Microsoft antivirus product is the primary AV. This provides an important safety net for environments where WDA is running in Passive Mode alongside a third-party solution.

# Enable EDR in Block Mode via PowerShell (requires MDE onboarding to be complete)
# This is also configurable in the Defender portal under:
# Settings → Endpoints → General → Advanced Features → EDR in block mode

# Check current EDR block mode status
Get-MpComputerStatus | Select-Object AMRunningMode

# Confirm EDR Block Mode is applied via registry
Get-ItemProperty -Path "HKLM:SOFTWAREPoliciesMicrosoftWindows Advanced Threat Protection" `
    -ErrorAction SilentlyContinue | Select-Object ForceDefenderPassiveMode

Enable EDR in Block Mode through the portal by navigating to Settings → Endpoints → General → Advanced features and toggling EDR in block mode to On. This setting is tenant-wide and applies to all onboarded devices.

Step 5: Configure Attack Surface Reduction Rules

Attack Surface Reduction (ASR) rules block specific behaviors that are commonly exploited by malware — such as Office macros spawning child processes, credential theft from LSASS, and untrusted process execution from USB drives. Windows Server 2025 supports the full ASR rule set.

# Define ASR rules and their modes
# Mode: 0=Disabled, 1=Block, 2=Audit
$asrRules = @{
    # Block executable content from email client and webmail
    "BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550" = 1

    # Block Office applications from creating child processes
    "D4F940AB-401B-4EFC-AADC-AD5F3C50688A" = 1

    # Block credential stealing from LSASS
    "9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2" = 1

    # Block process creations originating from PSExec and WMI commands
    "D1E49AAC-8F56-4280-B9BA-993A6D77406C" = 1

    # Block untrusted and unsigned processes that run from USB
    "B2B3F03D-6A65-4F7B-A9C7-1C7EF74A9BA4" = 1

    # Block abuse of exploited vulnerable signed drivers
    "56A863A9-875E-4185-98A7-B882C64B5CE5" = 1

    # Block JavaScript or VBScript from launching downloaded executable content
    "D3E037E1-3EB8-44C8-A917-57927947596D" = 1
}

# Apply all rules
foreach ($ruleId in $asrRules.Keys) {
    Add-MpPreference -AttackSurfaceReductionRules_Ids $ruleId `
        -AttackSurfaceReductionRules_Actions $asrRules[$ruleId]
}

# Verify configured rules
Get-MpPreference | Select-Object AttackSurfaceReductionRules_Ids, AttackSurfaceReductionRules_Actions

# Start in Audit mode first to identify false positives
# Change all values from 1 (Block) to 2 (Audit) in the hashtable above during testing

Always deploy ASR rules in Audit Mode first on server workloads, as some server applications — particularly legacy line-of-business apps — may exhibit behaviors that ASR rules would block. Review audit events in the MDE portal under Advanced Hunting before switching to Block mode.

Step 6: Organize Servers into Device Groups

Device groups in the MDE portal allow you to segment your server fleet by function, sensitivity level, or business unit, then apply different policies, permissions, and response configurations to each group.

In the Defender portal, navigate to Settings → Endpoints → Permissions → Device groups.
Click Add device group and provide a name (e.g., Production Domain Controllers).
Set the automation level (Full remediation for high-trust servers, Semi — require approval for critical infrastructure).
Define membership rules (e.g., Tag equals DC or OS Platform equals WindowsServer2025).
Assign user groups with access permissions for the device group.

# Tag servers for device group assignment using MDE Device Tagging
# Tags are set via registry and synced to the portal automatically

$tagPath = "HKLM:SOFTWAREPoliciesMicrosoftWindows Advanced Threat ProtectionDeviceTagging"
if (-not (Test-Path $tagPath)) {
    New-Item -Path $tagPath -Force | Out-Null
}

# Assign tags (comma-separated for multiple tags)
Set-ItemProperty -Path $tagPath -Name "Group" -Value "Production,DomainController" -Type String

# Verify the tag is set
Get-ItemProperty -Path $tagPath | Select-Object Group

Step 7: Run a Live Response Session

MDE’s Live Response feature gives security analysts a real-time command-line interface into onboarded servers without requiring RDP or direct network access — invaluable for incident response on isolated or remote machines.

In the Defender portal, open the device page for your server.
Click Initiate live response session in the top action bar.
Wait for the secure channel to establish (typically 30–60 seconds).

# Commands available within a Live Response session:

# List running processes
processes

# Collect a file for forensic analysis
getfile "C:WindowsTempsuspicious.exe"

# Run a PowerShell script from the library
run MyForensicScript.ps1

# Upload a script to the Live Response library first via the portal, then:
library upload MyForensicScript.ps1

# Isolate the device from the network (available from portal action bar)
# isolate (portal action — not a PS command)

# Undo isolation when investigation is complete
# unisolate (portal action)

Step 8: Advanced Hunting with KQL

Advanced Hunting allows you to query 30 days of raw endpoint telemetry using Kusto Query Language (KQL) directly from the Microsoft 365 Defender portal.

# Sample KQL queries to run in the Advanced Hunting tab:

# Find all PowerShell executions on Windows Server 2025 devices in the last 7 days
// DeviceProcessEvents
// | where Timestamp > ago(7d)
// | where FileName =~ "powershell.exe"
// | where DeviceId in (
//     DeviceInfo
//     | where OSPlatform == "WindowsServer2025"
//     | project DeviceId
// )
// | project Timestamp, DeviceName, InitiatingProcessFileName, ProcessCommandLine
// | order by Timestamp desc

# Find devices with failed ASR rule events
// DeviceEvents
// | where ActionType startswith "AsrBlock"
// | where Timestamp > ago(24h)
// | summarize count() by DeviceName, ActionType, FileName
// | order by count_ desc

Step 9: Offboard a Server from MDE

When decommissioning a server, follow the proper offboarding process to stop telemetry transmission and remove the device from your tenant. Failure to offboard leaves stale device records in the portal and may consume license seats.

# Download the offboarding script from:
# security.microsoft.com → Settings → Endpoints → Offboarding
# Select: Windows Server 2019 and 2022 and 2025 → Local Script

# Run the offboarding script on the server
Start-Process -FilePath "cmd.exe" -ArgumentList `
    "/c C:MDEOffboardingWindowsDefenderATPOffboardingScript_valid_until_YYYY-MM-DD.cmd" `
    -Verb RunAs -Wait

# Stop and disable the SENSE service
Stop-Service -Name Sense -Force
Set-Service -Name Sense -StartupType Disabled

# Verify the service is stopped
Get-Service -Name Sense | Select-Object Name, Status, StartType

The offboarding script contains an expiry date — download a fresh package if the existing one has expired. After running the script, the device will show as Inactive in the portal after 7 days with no telemetry, and can then be manually deleted from the device inventory.

Conclusion

Deploying Microsoft Defender for Endpoint on Windows Server 2025 transforms your server endpoints from isolated, locally-managed security nodes into participants in a unified, cloud-driven security intelligence platform. The combination of MDE’s behavioral EDR engine, attack surface reduction rules, Live Response capabilities, and 30-day advanced hunting data gives security teams the visibility and control needed to detect and respond to modern threats at enterprise scale. By following this guide — onboarding correctly, staging ASR rules through audit mode, organizing devices into logical groups, and practicing with Live Response before an incident occurs — you build both the technical infrastructure and the operational muscle memory your security team needs to respond confidently when threats emerge.

Links

Newsletter

Contact