Getting Windows devices into Microsoft Defender for Endpoint through Intune takes a handful of clicks, but a green "Succeeded" on an Intune policy doesn't prove the sensor is actually talking to the service. In this post I'll walk through connecting the two services, pushing the onboarding package with an endpoint detection and response (EDR) policy, and then checking the result in three places: on the device, in the Microsoft Defender portal, and with Microsoft's own detection test.
Prerequisites#
- Supported devices. Windows 10 or Windows 11 Pro, Business, Enterprise or Education, already enrolled in Intune. Home edition isn't supported by the onboarding CSP that Intune uses.
- Licences. Defender for Endpoint (Plan 1 or Plan 2, standalone or in a suite) and Intune. They're separate products, so confirm both are covered.
- Roles. The Intune Endpoint Security Manager role (or a custom role with Mobile Threat Defense and Endpoint detection and response permissions), plus Security Administrator in Microsoft Entra ID for the Defender portal side.
- Network. The sensor reaches the cloud through WinHTTP in the system context, so the Defender for Endpoint service URLs must be reachable through whatever proxy you use.
Step 1: Connect Defender for Endpoint and Intune#
Turn on the connection in the Defender portal#
In the Microsoft Defender portal (security.microsoft.com), go to System › Settings › Endpoints › General › Advanced features. Switch Intune connection to On and select Save preferences.
Check the connector in Intune#
In the Microsoft Intune admin center (intune.microsoft.com), open Endpoint security › Defender for Endpoint. Connection status should change from Unavailable to Enabled; give it up to 15 minutes. If you plan to use Defender's risk level in compliance policies, also turn on Connect Windows devices to Defender for Endpoint under compliance policy evaluation and select Save.
Note: That toggle shares Defender's risk signal with Intune compliance. It doesn't deploy the sensor configuration; the EDR policy in the next step does that.
Step 2: Deploy the onboarding package with an EDR policy#
Once the connector is enabled, Intune receives an onboarding package from your Defender tenant automatically, so there's no blob to download or paste. You can use it in two ways:
- Quick: Endpoint security › Endpoint detection and response, open the EDR Onboarding Status tab and select Deploy preconfigured policy. It targets all devices, which is fast but leaves no room for a pilot.
- Controlled: Endpoint security › Endpoint detection and response › Create policy, platform Windows, profile Endpoint detection and response. This is the option I'd pick for a first rollout.
| Setting | Value | Why |
|---|---|---|
| Microsoft Defender for Endpoint client configuration package type | Auto from connector | Uses the package Intune received from your tenant. If only the onboard/offboard blob options appear, the connector isn't working yet. |
| Sample Sharing | All | Lets the sensor share suspicious samples for analysis; None reduces detection capability. |
| Telemetry Reporting Frequency | Leave as is | Deprecated; it no longer affects new devices. |
Assign the policy to a device group for your pilot. User group assignments only apply after the user signs in, which slows down validation.
Step 3: Verify on the device#
After the device syncs, check the sensor service and the onboarding state from an elevated PowerShell session:
Get-Service -Name Sense | Select-Object Name, Status
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status' |
Select-Object OnboardingStateGood looks like Status : Running and OnboardingState : 1. Sense is the Defender for Endpoint sensor service, and it writes the onboarding status to HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status the first time it starts; 1 means onboarded.
If either check fails, open Event Viewer at Applications and Services Logs › Microsoft › Windows › SENSE › Operational and filter on errors and warnings. Event IDs 5 and 15 both mean the sensor couldn't reach the service, so start with proxy and firewall rules. If the policy never arrived at all, the DeviceManagement-Enterprise-Diagnostics-Provider › Admin log in the same tree is the place to look.
Step 4: Confirm in the Defender portal#
In the Defender portal, open the device inventory at Assets › Devices and search for the device name. A healthy device shows Onboarding status as Onboarded and Sensor health state as Active. Microsoft's guidance is that devices usually appear within 15 to 30 minutes; if one is still missing after an hour, treat it as an onboarding or connectivity problem rather than waiting longer.
For the fleet view, the EDR Onboarding Status tab in Intune summarises onboarding across devices, and the policy's device status shows whether each device applied it.
Step 5: Run the detection test#
A device that reports in is good; a device that raises an alert is proof. Microsoft publishes a test command that simulates a malicious download-and-run pattern. Open Command Prompt as administrator on the onboarded device and run:
powershell.exe -NoExit -ExecutionPolicy Bypass -WindowStyle Hidden $ErrorActionPreference = 'silentlycontinue';(New-Object System.Net.WebClient).DownloadFile('http://127.0.0.1/1.exe', 'C:\\test-MDATP-test\\invoice.exe');Start-Process 'C:\\test-MDATP-test\\invoice.exe'The window closes by itself. Within about 10 minutes, a new alert for that device should appear in the Defender portal. The command points at the loopback address (127.0.0.1) rather than a real download source; what matters is the behaviour pattern the sensor is built to flag.
Tips and gotchas#
- Never target a device with onboarding and offboarding at the same time. Microsoft warns that the two policies collide unpredictably and leave the device non-compliant.
- Check the proxy WinHTTP uses, not the browser's. Run
netsh winhttp show proxy; the sensor doesn't use user-level browser proxy settings. - Two Intune error codes worth knowing.
0x87D1FDE8(remediation failed) on the onboarding setting points to a bad blob, such as a wrong signature or a missingPreviousOrgIdsfield.0x87D101A9usually means the Windows edition or platform isn't supported. - Close the loop with compliance. Once devices report in, add Require the device to be at or under the machine risk score to a Windows compliance policy so Conditional Access can act on Defender's risk level.