Defender for Endpoint client analyzer: run it, read the results and fix connectivity

Symptoms to confirm

• The device inventory shows a sensor health state of Impaired Communications, No Sensor Data or Inactive for a device you know is online.
• Onboarding reports success locally, but the device never appears in the portal, or alerts and timeline events arrive late.
• The analyzer's Check Results Summary shows errors or warnings, or URL tests in its text output don't return (200):

Testing URL : https://xxx.microsoft.com/xxx
1 - Default proxy: Succeeded (200)
2 - Proxy auto discovery (WPAD): Succeeded (200)
3 - Proxy disabled: Succeeded (200)
4 - Named proxy: Doesn't exist
5 - Command line proxy: Doesn't exist

That block is healthy: one (200) on any method means the sensor can reach that URL that way.

Likely causes

• The sensor doesn't use the user's proxy. The SENSE service runs as Local System, so it relies on the system (WinHTTP) proxy, WPAD or a static proxy in TelemetryProxyServer. A browser that works proves nothing. With TelemetryProxyServer set, the sensor falls back to a direct connection if it can't reach that proxy.
• The proxy or firewall blocks service URLs, or demands authentication the system account can't provide.
• TLS inspection or revocation checks fail. A proxy that re-signs traffic, or blocked certificate revocation lists, breaks the sensor's connections.
• The sensor itself is unhealthy: SENSE or Defender Antivirus processes aren't running, or the device was onboarded with a package for another (or expired) organization ID.
• The analyzer is blocked: it uses Sysinternals PsExec to run its cloud checks as Local System, and the ASR rule Block process creations originating from PSExec and WMI commands stops that.

Checklist

1. 1

   Run the analyzer

   Download the MDE Client Analyzer from the Microsoft Learn page in the references, extract MDEClientAnalyzer.zip, and run it from an elevated Command Prompt:

   cmd

   C:\Tools\MDEClientAnalyzer\MDEClientAnalyzer.cmd
   C:\Tools\MDEClientAnalyzer\MDEClientAnalyzer.cmd -o "C:\Tools\<onboarding script>.cmd"

2. 2

   Or collect it remotely with live response

   For a device you can't reach, collect the analyzer support logs through a live response session in the Defender portal, following Microsoft's live response steps for the analyzer, then download the result package. Live response in Defender for Endpoint covers sessions, the library and downloading files.

3. 3

   Read the HTML report

   Unpack MDEClientAnalyzerResult.zip and open MDEClientAnalyzer.htm:

   • Device Information identifies the device, so you know you're reading the right report.
   • Endpoint Security Details lists the sensor and Defender Antivirus processes; anything that should run but doesn't is shown in red.
   • Check Results Summary counts errors, warnings and informational findings, and Detailed Results lists them by severity with Microsoft's guidance for each.
4. 4

   Fix the connectivity findings

   Find each Testing URL block in the text output (Microsoft's connectivity page calls the file MDEClientAnalyzerResult.txt; current packages also keep a verbose log in SystemInfoLogs\MDEClientAnalyzer.txt). Then compare with the proxy the sensor really uses:

   cmd

   netsh winhttp show proxy
   reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\DataCollection" /v TelemetryProxyServer
   sc.exe query sense

   • Every method fails for a URL: allow that URL (or the streamlined domain set) on the proxy and firewall. The required list depends on the region in the onboarding package; see moving to streamlined connectivity.
   • Only "Proxy disabled" works: traffic can go direct, but your proxy blocks it. Fix the proxy rules, or configure WinHTTP or TelemetryProxyServer deliberately.
   • An authentication error: exempt the Defender URLs from proxy authentication, because the system account can't answer a user prompt.
   • TLS or revocation problems: check SystemInfoLogs\CertValidate.log (the certificate revocation check), SCHANNEL.txt and SSL_00010002.txt, then exclude the Defender URLs from TLS inspection.
5. 5

   macOS and Linux

   Microsoft publishes separate versions of the analyzer for macOS and Linux, linked from the overview page in the references; run them as described on those pages. On those platforms, mdatp health and mdatp connectivity test give a quick first answer, and mdatp diagnostic create builds a log package; see mdatp health errors on Linux.

6. 6

   When to collect for support

   If the report has no clear cause, or Microsoft support asks for traces, attach MDEClientAnalyzerResult.zip in the case's Attachments section; for files over 25 MB the engineer provides a secure workspace. The analyzer doesn't send anything automatically, but the package can contain device names, IP addresses and usernames, so handle it as sensitive.

Verify

• Rerun the analyzer: every tested URL has at least one (200), and Check Results Summary shows no errors.
• sc.exe query sense shows RUNNING.
• The device's sensor health returns to Active in the device inventory, and new timeline events arrive. Inactive and No sensor data explains each state.

Prevent it next time

• Run the analyzer with -o on a pilot device before proxy, firewall or TLS inspection changes, and before onboarding a new site.
• Download a fresh copy of the analyzer for each investigation, because Microsoft updates its checks.
• Plan an ASR exclusion process for the analyzer, so diagnostics don't wait for a policy change.