Device shows "Inactive" or "No sensor data" in Microsoft Defender: how to troubleshoot

A device marked Inactive or Misconfigured in the Defender device inventory is either a blind spot, where the sensor isn't sending the telemetry you're paying for, or a stale record cluttering your reports. In this post I'll explain what each sensor health state means, then walk through the checks that tell you whether to fix the device, fix the network, or simply let an old record age out.

Symptoms#

• In Assets › Devices, the Sensor health state column shows Inactive, or Misconfigured with the detail Impaired communications or No sensor data.
• The device timeline has gaps, and alerts you'd expect never appear.
• The same computer name shows up twice: one Active record and one Inactive.
• Intune still reports the EDR onboarding policy as Succeeded.

Why it happens#

Inactive isn't automatically a fault. An offboarded device stays in the inventory, turns Inactive after seven days, and its profile (without data) can remain for up to 180 days.

How to fix it#

1. Rule out a stale or duplicate record#

Search the inventory for the device name. If a newer Active record exists, the device was most likely reinstalled or renamed and the Inactive entry is just history. With Plan 2, this advanced hunting query lists names that map to more than one device ID:

DeviceInfo
| where Timestamp > ago(30d)
| summarize LastReport = max(Timestamp), Records = dcount(DeviceId) by DeviceName
| where Records > 1
| order by LastReport desc

If the device you care about has a single record and it's Inactive or Misconfigured, move on to the device itself.

2. Check the sensor and onboarding state#

From an elevated PowerShell session on the device:

Get-Service -Name Sense, DiagTrack | Select-Object Name, Status, StartType
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status' |
    Select-Object OnboardingState

• Sense should be Running and OnboardingState should be 1. If the value is missing or 0, the device isn't onboarded: check the EDR policy assignment and make sure no offboarding policy targets it.
• DiagTrack is the Windows diagnostic data service. Microsoft's guidance for No sensor data is to confirm it starts automatically and is running; sc qc diagtrack shows the start type.

Then open Applications and Services Logs › Microsoft › Windows › SENSE › Operational. Event IDs 5 (couldn't connect to the server) and 15 (couldn't start the command channel) confirm a connectivity problem.

3. Check the proxy the sensor actually uses#

The sensor communicates through WinHTTP in the system context, independently of the user's browser proxy. See what WinHTTP is configured with:

netsh winhttp show proxy

"Direct access" is only right if devices reach the internet without a proxy or your proxy is discovered automatically. Then compare your proxy and firewall allow lists with the connectivity model the device was onboarded with:

• Streamlined connectivity consolidates the core services under *.endpoint.security.microsoft.com, plus supporting endpoints such as certificate revocation and Windows Update. Devices only use it after onboarding with a streamlined onboarding package.
• Standard connectivity uses the longer, region-specific URL list.

Microsoft is explicit that these service connections use certificate pinning, so TLS inspection isn't supported, and that they're made by the device rather than a user, so a proxy that demands user authentication breaks them.

4. Run the MDE Client Analyzer#

Download the analyzer from the Microsoft Learn page in the references, extract MDEClientAnalyzer.zip, and run it from an elevated Command Prompt (adjust the path to wherever you extracted it):

C:\Tools\MDEClientAnalyzer\MDEClientAnalyzer.cmd

It produces MDEClientAnalyzerResult.zip; open MDEClientAnalyzer.htm inside it for the findings. The connectivity results test each service URL through several methods (default proxy, WPAD, proxy disabled, named proxy). A (200) on any method means that route works; failures across the board give you the exact URLs to take to the network team.

5. Make sure Defender Antivirus isn't disabled by policy#

On devices running third-party antivirus, the sensor still depends on Defender Antivirus components such as its early-launch antimalware (ELAM) driver. Look under HKLM\SOFTWARE\Policies\Microsoft\Windows Defender for leftover policies that disable Defender, and never change the start type of the Defender or Sense services; Microsoft treats that as unsupported.

Verify the fix#

Health states aren't real time, so give the device a while online after the fix. Then re-check Assets › Devices: the sensor health state should return to Active, and new events should appear on the device's Timeline tab. For full confidence, run Microsoft's detection test from the onboarding documentation and confirm an alert shows up for the device.

Prevent it next time#

• Filter the device inventory on Sensor health state regularly, and use the device health report under Reports › Endpoints for a fleet view.
• Offboard devices before retiring them, and expect a new record every time a device is reimaged or renamed.
• Keep Defender for Endpoint destinations out of TLS inspection and user-authenticated proxy rules.
• Next time you revisit onboarding, consider streamlined connectivity; a shorter allow list is easier to keep right.

References#

• Fix unhealthy sensors in Microsoft Defender for Endpoint
• Verify client connectivity to Microsoft Defender for Endpoint service URLs
• Run the client analyzer on Windows