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

When a device shows an unhealthy sensor state in the Microsoft Defender portal, or onboarding seems to work but nothing arrives, the Defender for Endpoint client analyzer (MDECA) is the fastest way to see what the sensor sees. It checks the sensor's processes and configuration, tests every service URL the way the sensor would, and packages the logs Microsoft support asks for. In this post I'll show how to run it, how to read the report and the URL tests, and how to fix the usual findings.

Symptoms#

• 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. A failure shows an HTTP error instead.

Why it happens#

• 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.

How to fix it#

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:

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

On an onboarded device it tests with the device's own onboarding parameters. On a device that isn't onboarded yet it tests the US, UK and EU defaults, so for streamlined connectivity pass the onboarding script with -o (the second line) and it uses the region in that script. If the ASR rule blocks it, add a temporary exclusion for the analyzer, switch the rule to audit, or run it through live response, which doesn't need PsExec.

All the analyzer's scripts are Microsoft-signed. If any file was changed, it stops with a signature validation error and issuerInfo.txt explains which file failed; download a fresh copy.

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. 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.

Fix errors before warnings. A finding about the organization ID points to a wrong or expired onboarding package; the onboarding errors guide and the SENSE event ID reference help with the events in EventLogs\sense.evtx.

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:

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. 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. 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. For performance, application compatibility or Endpoint DLP problems, support might ask you to rerun it with the extra collection options on Microsoft's advanced data collection page.

Verify the fix#

• 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.

References#

• Run the client analyzer on Windows
• Verify client connectivity to Microsoft Defender for Endpoint service URLs
• Troubleshoot sensor health using the Microsoft Defender for Endpoint Client Analyzer