cuong do

Posted on Oct 20 Originally published at gitlab.com

Device not onboarding to Defender for Endpoint? Check the network first (and Intune)

#azure #security #cybersecurity #microsoft

My Day 5 notes on Defender for Endpoint, rewritten as a troubleshooting guide and checked against Microsoft Learn (October 2026).
Day 4 was about hunting and the portal (MDE Day 4: advanced hunting). Day 5 is about the thing that ruins more afternoons: a device you "onboarded" never shows up.

Here's a problem I have run into more than once. The onboarding policy says success, the device is online, the browser opens every website, and the Defender portal still shows nothing. Everyone blames Defender. Nine times out of ten it's the network: a proxy that wants a password, a firewall that only opened port 443, or a TLS inspection box quietly breaking the connection. Defender never got a chance.

All screenshots come from my own lab tenant. Account names and address bars are cropped out.

TL;DR

The Defender sensor talks through WinHTTP as LocalSystem. "The browser works" proves nothing.
Allow *.endpoint.security.microsoft.com. Don't inspect it and don't ask for proxy authentication. Remember CRL and update URLs too.
Intune onboarding needs two switches and one policy: the connector on both sides, then an EDR policy with Auto from connector that is actually assigned.

1. Open the firewall for the right URLs
2. Tell the device about your proxy
3. Prove it with the Client Analyzer
4. Onboard through Intune
5. How to tell what is broken
Gotchas
Day 5 checklist
Sources

1. Open the firewall for the right URLs

Microsoft splits network setup into three steps: configure the environment, configure the proxy on devices, then verify connectivity. Same order here: no point testing a road you haven't built.

Streamlined connectivity: one domain to remember

New tenants onboard with streamlined connectivity by default (since May 2024). Instead of a long list of regional URLs, most Defender traffic goes to one consolidated domain:

What	Value
Consolidated domain (commercial)	`*.endpoint.security.microsoft.com`, port 443
What it covers	Cloud-delivered protection, sample submission, AutoIR storage, command and control, cyber data
Still needed outside it	Certificate revocation (CRL, port 80), Windows Update and security intelligence updates, SmartScreen / network protection
No wildcards allowed?	Azure service tags `MicrosoftDefenderForEndpoint` and `OneDsCollector` (the second one is not inside the first)

Two notes that save time:

Streamlined connectivity only applies to newly onboarded devices. Devices onboarded with the old package keep working on the standard URLs until you migrate them, and that migration needs a reboot.
Older systems still on the MMA agent (Windows 7, 8.1, Server 2008 R2) are not supported by streamlined connectivity. They stay on the standard list.

The full lists, including the CRL and update URLs, live on Learn. Don't copy URL lists from blog posts (including this one).

Sources: Configure network connectivity · Onboarding using streamlined connectivity · Streamlined URL list (commercial)

The two rules people break

No SSL/TLS inspection for these URLs. The service uses certificate pinning, so your inspection box looks exactly like an attacker to the sensor. Exclude *.endpoint.security.microsoft.com from HTTPS interception.
No proxy authentication for these URLs. The connections come from a Windows service, not from a user. Nobody is there to type a password.

2. Tell the device about your proxy

If devices can reach the internet directly, skip this section and go have a coffee. If they go through a proxy, the device needs to know about it, and here is the trap: the EDR sensor uses WinHTTP, not the browser's (WinINet) proxy settings. Your users' browsers work fine. The sensor sits in the corner with no internet.

You have three options for the EDR sensor:

Method	When to use it
Auto-discovery (transparent proxy or WPAD)	Best if your network already does it. Nothing to set per device
Static proxy for the sensor, by Group Policy	Administrative Templates > Windows Components > Data Collection and Preview Builds > Configure connected user experiences and telemetry, value `server:port`. It lands in `TelemetryProxyServer` under `HKLM\Software\Policies\Microsoft\Windows\DataCollection`
System-wide WinHTTP proxy	`netsh winhttp set proxy proxy.contoso.com:8080` in an elevated prompt. Affects every service that uses WinHTTP, so it fits devices that don't move around

Things that bite:

Don't push TelemetryProxyServer through MDM. Learn says the sensor reads it only from the Group Policy registry location.
Microsoft Defender Antivirus has its own proxy setting (Group Policy Define proxy server for connecting to the network, or Set-MpPreference -ProxyServer). The EDR sensor and the antivirus can disagree, and then half of Defender works. Great fun to debug.
Defender for Endpoint needs IPv4. On an IPv6-only network you need something like DNS64/NAT64.
Linux is simpler: mdatp config proxy set --value http://proxy.contoso.com:8080, or the proxy key under cloudService in the managed JSON file.

Sources: Configure device proxy and internet connectivity settings · Configure Defender for Endpoint on Linux for static proxy discovery

3. Prove it with the Client Analyzer

Don't guess. Test from the device itself, before you onboard it.

Download the MDE Client Analyzer from Microsoft's official link on the Learn page (Verify client connectivity). Get it from there, not from a file share someone found in 2021.
Extract it and open Command Prompt as administrator in that folder.
On a device that isn't onboarded yet, run it with your onboarding script so it tests the right (streamlined) URLs: MDEClientAnalyzer.cmd -o <path to your onboarding .cmd>
Open MDEClientAnalyzerResult.txt in the result folder.

For every URL, the tool tries five ways to connect: default proxy, WPAD, no proxy, named proxy and command-line proxy. The rule is simple: one (200) per URL is enough. Here is a made-up sample from my imaginary lab device, in the format Microsoft documents:

First URL: the proxy path works and the direct path fails. That's normal in a locked-down network.
Second URL: no (200) anywhere, and a 407 means "proxy authentication required". Go back to section 1, rule 2.

Two more things from Learn: the analyzer's cloud checks clash with the ASR rule Block process creations originating from PSExec and WMI commands (exclude it while testing), and on Linux the equivalent check is mdatp connectivity test. Every line should say [OK].

The rest of the analyzer report gets its own post later in the series. Today we only care about connectivity.

Sources: Verify client connectivity to service URLs · Troubleshoot cloud connectivity issues on Linux

4. Onboard through Intune

Network sorted? Now the easy part. Intune onboarding is two switches and one policy. Most failures I've seen came from one of the three being half done.

Prerequisites: devices enrolled in Intune, a Windows edition that supports it (Pro, Enterprise or Education), and an admin with the Endpoint Security Manager role or similar.

Switch 1: in the Defender portal

Settings > Endpoints > Advanced features > Microsoft Intune connection = On, then Save preferences. People forget the save button more often than you'd think.

Switch 2: in the Intune admin center

Endpoint security > Microsoft Defender for Endpoint. Connection status should say Enabled. That can take up to 15 minutes, so don't hit refresh every five seconds like I did. Under Compliance policy evaluation, turn on Connect Windows devices ... to Microsoft Defender for Endpoint, then save.

The policy: an EDR policy

Endpoint security > Endpoint detection and response > Create policy, platform Windows. The key setting is Microsoft Defender for Endpoint client configuration package type:

Auto from connector: the recommended one. Intune fetches the onboarding package from Defender for you.
Onboard: you paste the onboarding blob yourself. For disconnected setups.

If the connector isn't working, Auto from connector won't even be offered. That's a free health check.

Look at the bottom of my screenshot: 0 groups assigned. A policy assigned to nobody onboards nobody. My lab policy list shows the same thing. Both policies say Assigned: No, and the onboarding report says 0 of 0.

After deployment, devices should show up in the Defender portal within 15 to 30 minutes. Check the EDR Onboarding Status tab in the same Intune page for "Successfully onboarded".

Sources: Onboard Windows devices using Intune · Configure Defender for Endpoint in Intune

Servers in Azure: Defender for Cloud

My notes end with servers. If you turn on Defender for Servers in Defender for Cloud, it can provision the Defender for Endpoint sensor on supported Windows and Linux machines for you (the MDE.Windows and MDE.Linux extensions). The network rules above still apply: an extension can't fix a proxy. Also note that your Defender for Endpoint data location is set when the tenant is created and can't be changed later.

Source: Defender for Endpoint integration in Defender for Cloud

5. How to tell what is broken

Learn's rule of thumb: if a device isn't in the device list an hour after onboarding, start digging. On the device:

Look at	What it tells you
Event Viewer > Applications and Services Logs > Microsoft > Windows > SENSE > Operational	Event 5 (can't connect to the server) and 15 (can't start the command channel) both mean network. Event 6 means no onboarding parameters were found: the package never arrived
Event Viewer > Windows Logs > Application, source WDATPOnboarding	Errors from the onboarding script itself, such as event 65 (not enough privileges)
`sc query sense`	Is the SENSE service actually running?
`Microsoft\Windows\DeviceManagement-EnterpriseDiagnostics-Provider` (Admin)	Intune side. Error `0x87D101A9` usually means an unsupported Windows edition
`MDEClientAnalyzer.cmd`	Which URL fails, and with which proxy method

My order is always the same: SENSE events first (network or package?), then the analyzer (which URL?), then Intune (did the policy even land?).

Source: Troubleshoot onboarding issues

Gotchas

"Internet works on that PC." In the browser, as a user. The sensor is LocalSystem on WinHTTP. Test with the analyzer, not with Edge.
Port 80 is not dead. CRL checks still use it. Block it and certificate validation can fail in strange ways.
Two proxies, one product. The EDR sensor and Defender Antivirus have separate proxy settings. Set both.
Service tags come in pairs. MicrosoftDefenderForEndpoint alone misses the cyber data that goes through OneDsCollector.
Old package, new firewall rules. Devices onboarded before streamlined connectivity still use the standard URLs. If you tighten the firewall to the single domain, migrate them first.
A policy with 0 groups looks perfect in the portal and does nothing.

Day 5 checklist

[ ] Firewall allows *.endpoint.security.microsoft.com (443) plus CRL (80) and update URLs
[ ] No TLS inspection and no proxy authentication for Defender URLs
[ ] Proxy set for the EDR sensor (WPAD, GPO or netsh winhttp) and for Defender Antivirus
[ ] Client Analyzer run with -o, at least one (200) per URL
[ ] Defender: Microsoft Intune connection On and saved
[ ] Intune: connector Enabled, Windows toggle on
[ ] EDR policy with Auto from connector, assigned to a real group
[ ] Device visible in the portal within an hour, or SENSE events checked

What's the weirdest reason a device refused to onboard for you? Mine was a proxy that wanted a password from a Windows service.

DEV Community