Microsoft Defender for Endpoint onboarding troubleshooting starts with one question: did the device appear in the Microsoft Defender XDR portal within an hour of policy assignment, and is its sensor health Active? If not, the failure lives in one of five layers: the SENSE service, the onboarding package, network connectivity to *.endpoint.security.microsoft.com, the SenseCM enrollment channel, or a tenant/identity mismatch. Honestly, I've spent more hours than I'd like to admit chasing "impaired" sensors that turned out to be a single missing URL in a proxy allowlist. In this guide I walk through the exact diagnostic order I use in production: portal check, sensor state, event logs, MDE Client Analyzer (MDECA), and registry keys.
A device is only truly onboarded when it appears in Defender XDR with sensor health Active. A successful onboarding script return code isn't proof of enrollment.
Sensor states break into four failure modes: Inactive (no heartbeat >7 days), Misconfigured, ImpairedCommunication (network/proxy block), and NoSensorData (SENSE runs but sends no telemetry).
The MDE Client Analyzer (MDECA) is the single most useful tool. It validates URL connectivity, proxy behavior, ELAM driver state, and SENSE event health from an elevated PowerShell prompt.
Onboarding errors 577 and 1058 almost always trace back to a missing Early Launch Antimalware (ELAM) driver when a third-party AV owns real-time protection.
SenseCM registry key HKLM\SOFTWARE\Microsoft\SenseCM\EnrollmentStatus reveals why a device never appears in Intune as "Managed by MDE". A value of 0x4 means SCCM still owns Defender configuration.
The SENSE operational event log (Applications and Services Logs\Microsoft\Windows\SENSE) filtered on Critical/Error/Warning is where every real onboarding failure surfaces first.
What the four MDE sensor health states actually mean
Before touching a broken device, understand what the portal is telling you. In my experience most tickets escalate because someone read "Onboarded: Yes" and assumed the endpoint was protected. The Onboarded attribute only records whether the onboarding script or MDM policy ran successfully. The Sensor health state is what tells you whether telemetry is actually flowing to the Defender cloud.
There are four unhealthy states you'll run into, each pointing at a distinct failure domain:
Inactive: the sensor hasn't reported to the Defender for Endpoint service for more than seven days. This is almost always a device that's been offline, decommissioned, or has stopped running the SENSE service after a Windows update.
Misconfigured: the sensor is partially reporting, but a configuration setting (cloud protection off, tamper protection interfering, wrong onboarding blob) is corrupting the telemetry stream.
ImpairedCommunication: the MsSense.exe process is running and healthy locally, but it can't reach its Command-and-Control (CnC) URLs. This is a networking problem: proxy, firewall, VPN split-tunnel, or SSL inspection breaking cert pinning.
NoSensorData: the sensor sends heartbeats but no event telemetry. This usually means ETW providers are being blocked, the disk is full, or the sensor's local queue is corrupted.
Never trust a single signal. On any Windows endpoint I confirm five things in sequence before I decide onboarding is working. Run these from an elevated PowerShell prompt on the target machine (they take under thirty seconds combined) and they will tell you exactly where enrollment broke.
# 1. Is the SENSE service running?
Get-Service -Name Sense | Format-List Name, Status, StartType
# 2. Is Defender AV in the correct mode? Look for AMRunningMode = 'Normal' or 'Passive'
Get-MpComputerStatus | Select-Object AMRunningMode, AntivirusEnabled, `
AntispywareEnabled, RealTimeProtectionEnabled, IsTamperProtected
# 3. Is the onboarding blob installed and marked complete?
$key = 'HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status'
Get-ItemProperty -Path $key | Select-Object OnboardingState, OrgId, LastConnected
# 4. Is the CnC endpoint reachable? Anything other than 200 is a red flag.
Test-NetConnection -ComputerName winatp-gw-eus.microsoft.com -Port 443
# 5. Has the sensor reported recently? Check the SENSE operational log.
Get-WinEvent -LogName 'Microsoft-Windows-SENSE/Operational' -MaxEvents 20 |
Where-Object { $_.LevelDisplayName -in 'Critical','Error','Warning' } |
Format-Table TimeCreated, Id, LevelDisplayName, Message -Wrap
OnboardingState = 1 means the onboarding blob was accepted and the device registered with the tenant. OrgId is a GUID; if it's empty or all zeros, the onboarding script never ran with SYSTEM privileges. LastConnected older than a couple of hours combined with a running SENSE service almost always means ImpairedCommunication, not a dead sensor.
If you've configured Intune to manage Defender via the security configuration management (SCM) channel, also confirm the SenseCM service is running and that the device appears as "Managed by MDE" in the Intune admin center. If it doesn't, jump straight to the SenseCM enrollment status registry key covered below.
Using the MDE Client Analyzer (MDECA) end to end
The MDE Client Analyzer is the tool I reach for the moment a device stays unhealthy after the basic PowerShell checks. It ships as a signed script bundle and generates a single MDEClientAnalyzerResult.htm report that consolidates connectivity checks, SENSE event log analysis, ELAM state, tamper protection state, and antivirus mode into one file you can attach to a ticket. Grab the current build from the Microsoft Learn MDE Client Analyzer overview page; that URL always points at the latest signed release.
Running MDECA on Windows
Copy the extracted folder to C:\Temp\MDEClientAnalyzer on the affected device. Open an elevated PowerShell window and run:
# Full analyzer with connectivity checks and log collection
cd C:\Temp\MDEClientAnalyzer
.\MDEClientAnalyzer.cmd -v
# Output lands in MDEClientAnalyzerResult\ — open the .htm file first.
# For connectivity-only diagnosis (faster, no log collection):
.\MDEClientAnalyzer.cmd -o
The analyzer calls PsExec.exe to run the connectivity checks under the LocalSystem account, which is what SENSE itself runs as. This matters, because a user-context proxy check will pass while SYSTEM-context traffic dies at the proxy. That's a very common false-negative in enterprises using WPAD or per-user authenticated proxies.
Reading the report
Open MDEClientAnalyzerResult.htm and go directly to the Detailed results section. Any entry marked Error is a definite failure. Warning entries often expose the root cause of intermittent issues: a proxy that requires authentication, a certificate on the transparent proxy replacing Microsoft's cert pin, or a DNS resolver returning stale addresses. The General Device Details section confirms whether the OS build, licensing SKU, and antivirus mode are actually in scope for MDE onboarding.
Running MDECA on Linux and macOS
The Linux and macOS analyzers ship as separate downloads. On macOS, run ./MDEClientAnalyzer from Terminal with sudo. The report lands in the same folder. On Linux, use ./mde_support_tool.sh diagnostic, which is really the same analyzer with different packaging. Both produce the same htm report format so your triage runbook stays consistent across platforms.
Reading the SENSE event log
SENSE is the internal codename for the Defender for Endpoint sensor process (MsSense.exe). Every meaningful state change (service start, onboarding blob acceptance, cloud connection failure, tamper protection interference) writes an entry to the SENSE operational log. The path in Event Viewer is Applications and Services Logs → Microsoft → Windows → SENSE → Operational.
Filter aggressively. The default view is noisy. Filter on Critical, Error, and Warning only. The event IDs that matter most in an onboarding failure are:
Event ID 5: the sensor failed to start. Often paired with error codes 577 or 1058 (see the ELAM section below).
Event ID 6: the sensor successfully started. If you never see this after an onboarding attempt, the onboarding blob wasn't applied.
Event ID 25: the sensor cannot connect to a required Defender for Endpoint URL. Message text names which URL failed.
Event ID 84: the tenant ID in the onboarding blob doesn't match the Microsoft Entra tenant. Rebuild the onboarding package from the correct tenant.
Pull the same view remotely across a fleet with PowerShell. This is my go-to when I need to triage more than one or two devices:
# Collect SENSE errors/warnings from a list of computers into a single CSV
$computers = Get-Content .\devices.txt
$results = foreach ($c in $computers) {
try {
Get-WinEvent -ComputerName $c -FilterHashtable @{
LogName = 'Microsoft-Windows-SENSE/Operational'
Level = 1,2,3 # Critical, Error, Warning
StartTime = (Get-Date).AddDays(-1)
} -MaxEvents 50 -ErrorAction Stop |
Select-Object @{n='Computer';e={$c}}, TimeCreated, Id, LevelDisplayName, Message
} catch {
[pscustomobject]@{ Computer=$c; TimeCreated=Get-Date; Id=0
LevelDisplayName='Unreachable'; Message=$_.Exception.Message }
}
}
$results | Export-Csv .\sense-triage.csv -NoTypeInformation
Common Defender for Endpoint onboarding errors and fixes
Here are the failure modes I see repeatedly at the helpdesk tier, along with the actual fix (not the copy-paste "check the docs" answer).
Error 577 or 1058: "The Windows Defender ATP service failed to start"
This is the number-one MDE onboarding error I see when a third-party antivirus is still installed. I hit this exact bug last quarter on a batch of Autopilot-provisioned laptops that still had a Symantec agent from the old image. The SENSE service depends on the Early Launch Antimalware (ELAM) driver from Windows Defender. If Symantec, CrowdStrike, or SentinelOne is registered as the primary antivirus, Windows Defender's ELAM driver may be disabled and SENSE refuses to start. Fix: put Defender AV into passive or EDR block mode explicitly, then reboot. The Microsoft Learn troubleshoot-onboarding article has the exact registry values, but the important part is that ELAM must be enabled for SENSE to load.
Onboarding blob applies but device never appears in the portal
Nine times out of ten this is either a tenant ID mismatch (the onboarding package was generated in a sandbox tenant and deployed to production), or SENSE never started because OOBE was skipped. On a fresh Windows Autopilot device, SENSE waits for the first interactive logon before starting. If the machine is imaged and shelved, it'll show as onboarded in the deployment tool but never in the portal.
Sensor status flips between Active and Inactive daily
This pattern points at a laptop that goes offline overnight and takes more than a few minutes to reconnect in the morning. It's benign, most of the time. But if the same pattern happens on desktops, look for a scheduled task killing MsSense.exe, a broken WMI repository, or a group policy that periodically clears the OrgId registry value.
Sensor is Active but no alerts show up in the portal
This is a NoSensorData variant. The sensor is up but ETW providers are either not registered or being blocked by tamper protection. Reinstall the sensor via a repair onboarding package, and verify tamper protection isn't being switched off by a conflicting policy. If you use both Intune and Group Policy to configure Defender, one will overwrite the other and cause exactly this symptom.
Security Configuration Management flow failures
Security Configuration Management (SCM) is the flow that lets Intune push endpoint security policies to devices that are onboarded to MDE but not enrolled in Intune. Think of the classic "servers that are Entra-joined but not MDM-managed" scenario. When this flow breaks, the device shows as onboarded, but the "Managed by MDE" object never appears in Intune, and policies never apply. Check HKLM\SOFTWARE\Microsoft\SenseCM\EnrollmentStatus. That single DWORD tells you exactly why:
EnrollmentStatus value
Meaning
Fix
0x0
Not enrolled (SenseCM hasn't tried yet)
Restart the SenseCM service, then check event log
0x1
Enrollment in progress
Wait 15 minutes; if stuck, check outbound access to *.dm.microsoft.com
0x2
Successfully enrolled
Device should appear as Managed by MDE in Intune within 30 minutes
0x3
Enrollment failed (generic error)
Run MDECA; check SENSE event log for Event ID 84 (tenant mismatch)
0x4
Managed by SCCM/ConfigMgr
Turn off "Manage security setting using Configuration Manager" in Defender settings, or set the co-management workload slider
0x5
Hybrid Entra join failed
Fix hybrid join first; MDE can't enroll a device that isn't a valid Entra identity
0x6
Prerequisites not met
OS version, licensing SKU, or Entra Connect Sync misconfigured
The 0x4 value is the trap that catches most enterprises during their Intune migration. Even after you flip the workload slider in ConfigMgr, the SenseCM cache doesn't refresh automatically. Restart the SenseCM service after any co-management change, then re-check the registry key. If you're already deep in Intune, our guide on Intune device enrollment troubleshooting covers the co-management slider settings in more depth. For the underlying hybrid-join dependency, the Entra Connect sync troubleshooting guide is the fastest path to fixing an 0x5 result.
Connectivity URLs, proxy, and WinHTTP
ImpairedCommunication is the sensor state I get paged on most. The root cause is nearly always network: the device runs SENSE, but SENSE can't reach the Defender cloud. There are three things to check before you blame the sensor.
Required Microsoft URLs
Defender for Endpoint publishes two connectivity models: streamlined (a small list of consolidated URLs, recommended since 2024) and standard (the older, longer list). If you have any commercial-grade firewall or SSL inspection appliance in path, insist on the streamlined URL set and confirm the appliance treats them as pass-through, with no SSL break-and-inspect. Certificate pinning inside MsSense.exe means an inspected cert will terminate the connection with no useful error.
WinHTTP proxy vs. system proxy
SENSE runs as LocalSystem and reads WinHTTP proxy settings, not the per-user Internet Explorer / Edge proxy settings. Every time I see a device that "has internet, but MDE won't connect," the answer is that the desktop team configured the proxy in Internet Options and never mirrored it to WinHTTP. Verify with:
# Show the current WinHTTP proxy — this is what SENSE sees
netsh winhttp show proxy
# Import from IE proxy settings (fast fix for a single machine)
netsh winhttp import proxy source=ie
# Or set explicitly with a bypass list
netsh winhttp set proxy proxy-server="proxy.corp.local:8080" `
bypass-list="*.dm.microsoft.com;*.endpoint.security.microsoft.com;<local>"
Distribute the WinHTTP proxy setting via Group Policy or Intune. Don't rely on end-users to configure it. If your network stack routes MDE through a VPN, the traffic must exit through a network path that trusts Microsoft's public certificates, which for many split-tunnel VPNs means excluding the MDE URLs from the tunnel entirely. Our Global Secure Access troubleshooting guide covers the tunnel exclusions in detail for Microsoft's own SSE stack.
Static proxy for the sensor
If WinHTTP doesn't fit your topology, MDE supports a sensor-only static proxy via HKLM\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection\TelemetryProxyServer. Set this as a string value pointing at proxy.corp.local:8080. The sensor reads it on startup; a service restart is required after changes. Verify with MDECA that the correct proxy method is being used for cloud checks.
Windows Server, Linux, and macOS onboarding differences
Cross-platform onboarding is where I see the most confused tickets. The rules differ per OS, and treating them all like Windows 11 clients is why so many onboardings fail silently.
Windows Server 2016 and 2019
These are onboarded with the unified solution package. The old MMA-based agent is retired. The unified installer package must be pushed with the correct onboarding blob for the tenant, and the server reboots twice during install: once for ELAM registration, once for the SENSE service to bind. If you skip the second reboot, sensor health reports Inactive indefinitely.
Windows Server 2022 and 2025
The sensor is built in. Onboarding is just running the onboarding script or applying the Intune policy (no installer required). But on Server 2025, tamper protection is on by default in some Cloud Solution Provider deployments; if you're pushing Defender settings via Group Policy, tamper protection will block the settings from applying. Manage settings via Intune SCM or via Defender's tenant attach flow instead.
macOS
On macOS, MDE requires two system extensions and one network extension approved via MDM. If those approvals are missing, mdatp health will report healthy: false with reason rtp_service_not_started. The fix is to push the JAMF, Kandji, or Intune configuration profile with the correct team ID and bundle identifiers. Our macOS Platform SSO troubleshooting guide covers the same configuration profile mechanics for a related scenario.
Linux
The mdatp package installs cleanly on RHEL, Ubuntu, SLES, and Amazon Linux. Onboarding is a single Python script; validate with mdatp health --field healthy. The common failure is that auditd isn't running, or has been reconfigured by a hardening baseline. MDE on Linux uses auditd for behavioral telemetry, and if it's disabled, the device shows healthy but detects nothing.
Monitoring MDE sensor health at scale with KQL
Fixing one broken device is a ticket. Fixing them proactively is a program. Once you've cleaned up the current inventory, monitor sensor health continuously in the Defender advanced hunting console. This KQL query is the one I run daily to catch drift before end-users notice:
// Devices unhealthy for more than 24 hours, grouped by root cause
DeviceInfo
| where Timestamp > ago(1d)
| summarize arg_max(Timestamp, *) by DeviceId
| where OnboardingStatus == "Onboarded"
and SensorHealthState != "Active"
| extend RootCauseHint = case(
SensorHealthState == "ImpairedCommunication", "Network / proxy",
SensorHealthState == "Inactive", "Offline >7d or SENSE stopped",
SensorHealthState == "Misconfigured", "AV mode / tamper protection",
SensorHealthState == "NoSensorData", "ETW / disk / tenant mismatch",
"Other")
| project DeviceName, OSPlatform, OSVersion, SensorHealthState,
RootCauseHint, LastSeen = Timestamp
| order by SensorHealthState asc, LastSeen desc
Wire this into a Sentinel workbook or an automated ticket-creation flow. Pair the query above with an alert on the number of ImpairedCommunication devices per subnet; a spike in a single subnet almost always means a firewall change broke a URL somewhere. When triaging network-side failures, our network diagnostics toolkit guide covers the traceroute and DNS steps you'll need next.
Frequently Asked Questions
Why is my Defender for Endpoint device showing as inactive?
An Inactive state means the sensor hasn't reported for more than seven days. The most common causes are the device being offline (laptop shelf-stored), the SENSE service being disabled by a policy, or a Windows update having reset onboarding registry values. Start with the SENSE event log and confirm the service starts on boot.
What ports and URLs does Microsoft Defender for Endpoint require?
MDE requires outbound HTTPS on port 443 to the streamlined Defender for Endpoint URL set, primarily *.endpoint.security.microsoft.com, *.wd.microsoft.com, and for SCM enrollment *.dm.microsoft.com. No SSL inspection is supported; certificate pinning inside MsSense.exe will terminate any inspected connection.
How long does MDE onboarding take to complete?
Devices appear in the Defender portal within 1 to 2 hours of the first sensor check-in after the onboarding blob is applied. Full policy assignment can take up to 24 hours. If a device hasn't appeared after two hours and the SENSE service is running, treat it as a connectivity or tenant-mismatch failure and run the MDE Client Analyzer.
Can I run Defender for Endpoint alongside a third-party antivirus?
Yes, but Defender AV must be set to passive mode or EDR block mode, and the Early Launch Antimalware (ELAM) driver must be enabled. Without ELAM, the SENSE service fails to start with error 577 or 1058, and no EDR telemetry reaches the cloud regardless of what the third-party AV is doing.
Why is my device not appearing as "Managed by MDE" in Intune?
Read the DWORD at HKLM\SOFTWARE\Microsoft\SenseCM\EnrollmentStatus. Value 0x4 means Configuration Manager (SCCM) still owns Defender settings; disable that in Defender configuration management enforcement scope. Value 0x5 means hybrid Entra join failed; fix the identity first. Any other non-0x2 value points at prerequisites or connectivity.
Passkeys in Microsoft Entra ID keep failing over the same three things: Authenticator version, AAGUID allowlist, and Conditional Access. Here's the 2026 helpdesk runbook, with PowerShell diagnostics, cross-device QR fixes, and a passkey-vs-FIDO2-vs-Windows Hello comparison.
The five-check DHCP triage every helpdesk needs on Windows Server 2025: service and AD authorization, scope health, failover state, relay agents, and the KB5060842 service hang, all with paste-ready PowerShell.
A helpdesk-grade checklist for Windows 10 ESU in 2026: fix missing enroll buttons, 'Something went wrong' errors, COMMERCIAL_DEVICE blocks, MAK activation and Intune rollout.
