Microsoft Defender for Endpoint – Most common onboarding issues on Windows assets

Dear readers, welcome to my first blog article. I hope you enjoy reading it and find some useful insights along the way.

Introduction

Today, let’s talk about Microsoft Defender for Endpoint (MDE), but instead of focusing on its features, we’ll dive into the most common onboarding issues that can occur in real-world scenarios.

If you’re planning to deploy Microsoft’s EDR or if you already in the middle of it, chances are you’ll face a situation where some devices don’t show up in the security console Let’s go through the basics of onboarding and how to troubleshoot these issues.

---

1. Microsoft Defender for Endpoint – Onboarding methods

Deploying Microsoft Defender for Endpoint on Windows assets is usually straightforward. There are different onboarding methods depending on your environment.

To get started, go to the security console : https://security.microsoft.com (shortcut: aka.ms/de)

Then navigate to: System > Settings > Endpoints > Onboarding

Select the target OS (depending on the OS type you may also need to download an installation package). Then choose the connectivity method:

• Standard : Uses multiple Microsoft cloud endpoints (URLs) for communication
• Streamlined: Uses a single Microsoft cloud endpoint (URL) for communication

Then, choose your preferred onboarding method:

• Local Script: For small group of devices
• GPO: For larger deployment
• Microsoft Endpoint Configuration Manager: for SCCM deployment
• Mobile Device Management / Microsoft Intune
• VDI : for non-persistent devices

Once you’ve made your selection, click on “Download onboarding package”.

For the first two methods (Local script and GPO) it’ll generate a ZIP archive containing a script to run with administrator rights on the target device.

But what if some devices don’t show up as “Onboarded” (in the Defender Portal)?

You’ve deployed the onboarding script to your Windows environment using your preferred deployment tool but … some devices are still missing in the Defender portal.

You check your inventory and yep … they’re running fine. So, what’s going on?

Let’s troubleshoot!

2. Your Best Friend: MDE Client Analyzer

Before diving into specific issues, download the official MDE Client Analyzer tool. It’s essential for understanding onboarding failures and you will also gain a new temporary best friend.

Download MDE Client Analyzer: https://learn.microsoft.com/en-us/defender-endpoint/run-analyzer-windows

You’ll see two options :

• Option 1: Live response (collect the Defender for Endpoint analyzer logs remotely) – this option is not considered here as Live Response is not available for non-onboarded devices
• Option 2: Run MDE Client analyzer locally – use this method, two versions will be available for download:
  • MDE Client Analyzer tool (stable version) – recommended
  • MDE Client Analyzer tool (preview) à contains experimental checks, only use it if Microsoft Support asks you to or if the stable version does not give you entire satisfaction

Once downloaded:

1. Extract the archive
2. Run “MDEClientAnalyzer.ps1” or “MDEClientAnalyzer.cmd” locally as administrator. (prefer running directly the Powershell script as the .cmd just makes a call of the .ps1)
3. Wait for end of execution (from my experience, execution times vary from 2 to 40 minutes depending on the machine specifications)

When it finishes, it’ll generate a ZIP file like this: MDEClientAnalyzerResult_DateHour.zip in the same folder.

Inside, you’ll find :

• Defender AV configuration & logs
• Windows Event logs
• Several logs related to MDE and the system
• And most importantly: a beautiful HTML report summarizing the key information

The first thing to do is to start with this HTML report and go to the “Detailed Result” section and look for lines marked as “Error” in the “Severity” column.

3. Common issues and fixes:

It’s always the network, isn’t it ? 😊

A very common issue is that the device can’t reach Microsoft’s cloud endpoints, so onboarding fails. It will mostly affect servers with restricted internet access. Generally user workstations have a large access to internet through a proxy.

For example, the error below can reveal that the device can’t communicate with Microsoft cloud endpoints (URLs) over TCP/443 (HTTPS):

Checks can be also done in the following log file:

MDEClientAnalyzer.txt log file

It contains detailed information about the network request done towards Microsoft URLs :

What you should see in the logs when it works:

Testing URL : https://winatp-gw-cus.microsoft.com/test
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

Note: Any code other than 200 indicates a problem.

---

Well, obviously it’s the network ! 😁

Sometimes HTTPS cloud connectivity is fine, but CRL checks fail.

This can happen on older systems like Windows Server 2012 R2, which use TCP/80 (HTTP) for CRL.

Port	Microsoft CRL URL
TCP/80	http://www.microsoft.com/pkiops/*  http://www.microsoft.com/pki/*
TCP/80	http://ctldl.windowsupdate.com
TCP/80	http://crl.microsoft.com

The error can be found in two different log files:

• MDEClientAnalyzer.txt
• CertValidate.log

See below an extract of logs indicating a connectivity error :

In MDEClientAnalyzer.txt

Testing URL : https://winatp-gw-neu.microsoft.com/commands/test 
1 - Default proxy: Failed (0: SSL error: WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED failed to check revocation status. ) 
2 - Proxy auto discovery (WPAD): Failed (0: SSL error: WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED failed to check revocation status. ) 
3 - Proxy disabled: Failed (0: SSL error: WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED failed to check revocation status. ) 
4 - Named proxy: Doesn't exist 
5 - Command line proxy: Doesn't exist 

In CertValidate.log:

----------------  Certificate AIA  ---------------- 
  Failed "AIA" Time: 0 
    Error retrieving URL: A connection with the server could not be established 0x80072efd (INet: 12029 ERROR_INTERNET_CANNOT_CONNECT) 
    http://www.microsoft.com/pkiops/certs/MicSecSerCA2011_2011-10-18.crt 
  
  ----------------  Certificate CDP  ---------------- 
  Failed "CDP" Time: 0 
    Error retrieving URL: A connection with the server could not be established 0x80072efd (INet: 12029 ERROR_INTERNET_CANNOT_CONNECT) 
    http://www.microsoft.com/pkiops/crl/MicSecSerCA2011_2011-10-18.crl 
  
  ----------------  Certificate OCSP  ---------------- 
  No URLs "None" Time: 0 
  -------------------------------- 
  Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication 
  Application[1] = 1.3.6.1.5.5.7.3.2 Client Authentication 

---

Our antivirus is from the Stone Age…

This kind of issue can be identified in the “AV Component Details” section. You can see below, in red, that the version is not compatible with the current version of MDE.

It can also be shown as an error:

If you get this error, it means you are trying to deploy MDE on a device that is not up-to-date in terms of KBs, especially regarding the Anti-Malware engine/platform version. The minimum version required for the AV platform is 4.18.24090.11. If you are under this this version, onboarding fails.

You can also check it through the following PowerShell command:

Get-MpComputerStatus | Select AMProductVersion,AMEngineVersion

Here is an example of an up-to-date configuration when executing the command above:

---

Defender without Sense… makes no SENSE !

There are some cases where the status of SENSE is in “Stopped” state. The SENSE service (EDR component) is required for MDE. If it’s stopped, onboarding fails.

This can happen when:

• The onboarding script wasn’t executed properly
• Something stopped unexpectedly the service

You can find this information by reading the EDR Component Details part of the MDE Client Analyzer report :

To check if the onboarding is effective, run the following Powershell command :

Get-WinEvent -LogName Application -MaxEvents 5 | Select-Object -Property TimeCreated, Id, ProviderName, Message

The output must display a WDATPOnboarding event :

---

Conclusion

Deploying MDE is usually smooth, but there are always edge cases.
To sum up, if onboarding fails:

• Run the MDE Client Analyzer
• Check network connectivity (especially over TCP/80 for old OS)
• Verify AV platform and Engine versions
• Make sure the SENSE service is running
• Others issues can be identified in the logs generated by the MDE Client Analyzer tool.

I hope this article helps you save time during deployment. Let me know if you encountered issues not listed here.

---