14.1 Onboarding Devices to Defender for Endpoint

Onboarding Devices to Microsoft Defender for Endpoint

Quick Answer: Onboarding is the act of connecting a device to your Defender for Endpoint tenant so it starts reporting sensors, detections, and inventory data. You download an onboarding package (a script or configuration blob) from the Microsoft Defender portal and deploy it through Intune, Group Policy, Configuration Manager with tenant attach, a local script, or a VDI golden-image procedure.

Plan 1 vs Plan 2

Microsoft Defender for Endpoint ships in two tiers. Knowing which features come from which plan matters because licensing drives what you can configure.

The headline distinction to memorise: Plan 1 is prevention, Plan 2 adds detection and response. EDR, automated investigation and remediation, vulnerability management, device discovery, and advanced hunting are all Plan 2 — a scenario that needs any of them rules Plan 1 out.

Plan 2 is what most MS-102 candidates deploy. It is included with Microsoft 365 E5 and Microsoft 365 E5 Security, or with Microsoft 365 E3 plus the Defender for Endpoint Plan 2 add-on. Plan 1 is included with Microsoft 365 E3/A3 and is also sold standalone. Note the small-business trap: Microsoft 365 Business Premium includes Microsoft Defender for Business, not Defender for Endpoint Plan 1 or Plan 2 — Defender for Business is a separate SKU with its own feature set, and a tenant cannot mix it with Defender for Endpoint licensing.

---

Prerequisites Before You Onboard

Before any device can report in, three things must be true:

1. The workspace is provisioned. Sign in to the Microsoft Defender portal (security.microsoft.com) and complete the initial setup wizard. The portal becomes the single pane of glass for incidents, alerts, vulnerability management, and onboarding.
2. Licensing is assigned. Each onboarded device needs a license that includes MDE P2 (or P1 for the reduced feature set). Plan 2 comes from Microsoft 365 E5, Microsoft 365 E5 Security, Microsoft 365 E3 plus the MDE Plan 2 add-on, or a standalone MDE Plan 2 SKU; Plan 1 is included in Microsoft 365 E3. Microsoft 365 Business Premium licenses Defender for Business, which is a different product from Defender for Endpoint.
3. Network connectivity is in place. Endpoints must reach the Defender for Endpoint service URLs over HTTPS (for example *.endpoint.security.microsoft.com and the telemetry endpoints documented in Microsoft Learn). If you route through a proxy, allow these domains and disable SSL inspection for them.

---

Onboarding Methods

Microsoft supports six onboarding paths. The right choice depends on your management plane and operating system.

Intune (recommended)

For Microsoft-managed endpoints the recommended path is an Intune device configuration profile. You create a profile under Devices → Configuration profiles → Create profile, pick Defender for Endpoint as the template on Windows, or use the Microsoft Defender for Endpoint mobile threat defense connector for iOS and Android. The profile pushes the onboarding blob silently; no user interaction is required. macOS onboarding uses the same Intune profile plus the standalone MDE installer package (.pkg) distributed through Intune required apps.

Group Policy

In a classic on-prem AD environment you download a Group Policy Object (GPO)-formatted onboarding package (a ZIP containing an Onboarding.xml script and a WindowsDefenderATPOnboardingScript.cmd) and import it into a GPO linked to an OU containing the target machines. Group Policy writes the onboarding blob into HKLM\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection\Onboarding. On next GP refresh the sensor starts and reports within minutes.

Configuration Manager with tenant attach

If you already manage devices with Microsoft Endpoint Configuration Manager (MECM), tenant attach syncs your MECM devices into the Defender portal without requiring Intune enrollment. You enable tenant attach in the MECM console, then deploy the MDE client as an application. Collections become device groups in the portal.

Local script

For a pilot or a single laptop with no management system, download the local script (a 10 KB PowerShell or bash file) from the onboarding page and run it elevated. It writes the onboarding blob to the same registry key (Windows) or /etc/opt/microsoft/mdatp (Linux/macOS). This is fine for tens of devices; it does not scale.

VDI onboarding

Non-persistent virtual desktops need a different procedure because each session starts from a clean image. The Microsoft-published approach is:

1. Optimize the golden image — run the VDI optimization script (or the WindowsDefenderATPOnboardingScript with the -vdi flag) on the master image to set the OnboardingInfo registry key and the SenseId placeholder.
2. Set up the onboarding completion method — use a GPO or Intune policy that runs a small script at logon to generate a unique sensor identity for each session. Microsoft supports both single-session (one user per VM, persistent identity) and multi-session (AVD, Citrix MCS/PVS) scenarios.
3. Offboard at logoff (optional) — for strict non-persistence, run the offboarding script at logoff so each session's machine object cleans up in the portal.

Onboarding Linux and macOS servers

Linux servers use the mdatp package deployed through yum, apt, or zypper, with the onboarding blob pushed via Puppet, Ansible, Chef, or Intune. macOS servers use the .pkg installer plus the onboarding blob via Intune, Jamf, or Microsoft's own script.

---

The Onboarding Package

Regardless of method, every onboarding relies on the onboarding package downloaded from Settings → Endpoints → Onboarding in the Defender portal. The package contains:

• A workspace ID / onboarding blob that identifies your tenant
• The script or MSI that writes the blob to the device and starts the sensor
• The service URLs the sensor uses for telemetry and portal communication

The blob is tenant-specific. Never copy a blob from one tenant into another — devices will report to the wrong workspace and you will not be able to offboard them cleanly.

---

Device Discovery

Once you have a few onboarded devices, Device Discovery turns them into network sensors. Each onboarded Windows or macOS endpoint scans the local subnet (and any configured scan ranges) for other devices: servers, printers, IoT, and unmanaged laptops. Discovered devices appear in the Device inventory tagged Discovered rather than Onboarded. You can then prioritize onboarding the high-value discovered assets.

Device discovery is a Plan 2 capability. Within it, Standard discovery (the default) actively probes unmanaged devices using techniques the Microsoft Learn documentation describes as "non-intrusive," while Basic discovery is passive — it only listens to the traffic onboarded devices already see. Configure the mode under Settings → Endpoints → Advanced features → Device discovery.

---

Verifying Onboarding

After deployment, verify onboarding in three places:

• On the device: run Get-MpComputerStatus (Windows) or mdatp health (Linux/macOS) and confirm AMServiceEnabled / OnboardingState shows the device is managed and reporting.
• In the Defender portal: open Assets → Devices and confirm the device appears with a green check under Onboarding status.
• In the Sensor health report: under Reports → General → Sensor health, look for No sensor data or Impaired communication and remediate any devices that are not checking in.