The Microsoft Defender portal shows one or more devices with an unhealthy sensor status:
Sensor health state: Misconfigured
- No sensor data
- Impaired communications
Both statuses mean the device is onboarded but not fully protected in practice. This is worse than a device that has clearly failed, because the device list still shows it as present and managed.
Why This Happens
Defender for Endpoint classifies devices as active, inactive or misconfigured, and misconfigured splits into two distinct conditions:
Impaired communications — communication between the device and the service is limited. The practical consequence is that response actions requiring device communication may not work: sending files for deep analysis, blocking files, and isolating the device from the network.
No sensor data — the device can communicate with the service, but only reports partial sensor data. Telemetry you expect to query is incomplete or absent.
Separately, a device is marked Inactive after seven days without signals. That is not always a fault: the device may simply be unused, may have been reinstalled or renamed (which creates a new device entity and leaves the old one inactive), or may have been offboarded. A device that was misconfigured and then stopped reporting altogether will also end up here.
The underlying causes cluster into three areas: the network path, the services on the device, and antivirus policy.
Fix 1: Confirm the Device Has a Working Network Path
The Defender for Endpoint sensor requires Windows HTTP (WinHTTP) to report sensor data and communicate with the service. WinHTTP has its own proxy configuration, independent of the per-user Internet Explorer or Edge proxy settings — this catches people out constantly, because a device that browses the web fine can still fail here.
Check the current WinHTTP proxy configuration:
netsh winhttp show proxy
If it shows a direct connection but your environment requires a proxy, import the system proxy:
netsh winhttp import proxy source=ie
Or set it explicitly:
netsh winhttp set proxy proxy-server="http=proxy.contoso.com:8080" bypass-list="<local>"
Then confirm the proxy actually permits traffic to the Defender for Endpoint service URLs. Verifying client connectivity to those URLs is a documented remediation step for both misconfigured states — a proxy that is reachable but blocks the service endpoints produces exactly this symptom.
Fix 2: Verify the Sensor and Diagnostic Data Services
Two services matter on a Windows device.
The Sense service is the sensor itself:
sc query sense
STATE should be RUNNING. If it is stopped:
sc config sense start= auto
net start sense
The Windows diagnostic data service must be set to start automatically and must be running — the sensor depends on it to report. If devices are not reporting correctly, verify both:
sc query diagtrack
sc config diagtrack start= auto
net start diagtrack
A diagnostic data service that has been disabled by a privacy-hardening policy or a third-party "debloat" script is a frequent and easily missed cause of No sensor data. If a Group Policy or configuration baseline is disabling it, that policy needs to be amended rather than the service simply restarted, or it will revert.
Fix 3: Check Microsoft Defender Antivirus Is Not Disabled by Policy
If your devices run a third-party anti-malware client, Defender for Endpoint still requires the Microsoft Defender Antivirus Early Launch Anti-Malware (ELAM) driver to be enabled. A policy that disables Microsoft Defender Antivirus outright removes telemetry the sensor depends on.
Check whether a policy is disabling it:
Get-MpComputerStatus | Select-Object AMRunningMode, AntivirusEnabled
With a third-party AV installed, the expected running mode is passive mode — not disabled. If a Group Policy sets Turn off Microsoft Defender Antivirus, remove that setting; passive mode is the supported coexistence configuration, and it is what keeps ELAM and the sensor telemetry intact.
Do not resolve this by uninstalling the third-party product on a whim. Coexistence is supported; the fix is the policy, not the other vendor's agent.
Fix 4: Run the Client Analyzer
The Microsoft Defender for Endpoint Client Analyzer is purpose-built for these states — it is the recommended tool when diagnosing sensor health or reliability issues on devices showing Inactive, No sensor data or Impaired communications.
Download it from the Defender portal, run it elevated on the affected device, and review the resulting report. It checks connectivity to the service URLs, service state, onboarding configuration and proxy settings in a single pass, which is considerably faster than working through them individually.
Keep the output — it is the first thing Microsoft support will ask for if you end up opening a case.
Fix 5: Re-Onboard the Device
If onboarding state itself is damaged, re-run the onboarding package. Confirm the current state first:
Get-Service -Name sense
reg query "HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status" /v OnboardingState
OnboardingState should be 1. If it is 0 or missing, re-run the onboarding script from Settings → Endpoints → Onboarding in the Defender portal.
Offboard and re-onboard only when re-onboarding alone does not help. Offboarding leaves the device without EDR coverage until onboarding completes, so schedule it rather than doing it ad hoc, and confirm the device comes back healthy afterwards. See how to onboard devices for the full process across platforms.
Verify the Fix
Device health does not update instantly. After making a change:
- Confirm services are running:
sc query senseandsc query diagtrack. - Confirm
netsh winhttp show proxyreflects the intended configuration. - Re-run the Client Analyzer and check it now reports clean.
- Wait — allow time for the portal to reflect the new state rather than concluding the fix failed after five minutes.
- Check the device in the Defender portal and confirm the health state has moved to Active.
- Confirm telemetry is genuinely arriving by running an advanced hunting query against recent events for that device.
That last step is the real test. A device showing Active but producing no events is still a coverage gap.
If the device remains misconfigured after all corrective actions, Microsoft's guidance is to open a support ticket.
Prevention
- Deploy WinHTTP proxy settings centrally, so devices do not depend on per-user browser configuration that the sensor never reads.
- Allow the Defender service URLs explicitly on proxies and firewalls, and re-check the allow-list when the network team changes egress rules.
- Protect the diagnostic data service from privacy-hardening baselines and third-party optimisation scripts. Document that it is a dependency so it is not disabled by a well-meaning change.
- Use passive mode during AV migrations rather than disabling Microsoft Defender Antivirus by policy.
- Monitor sensor health continuously. Build a report or alert on devices in misconfigured or inactive states so they surface within days rather than at the next audit.
- Expect the Monday Mac cluster. macOS devices that sleep over a weekend legitimately show this state and clear on their own once used again.