The onboarding article mapped the doors a device can take into Defender and argued which one to use for which population. This is the build for the door most estates start with, the Intune channel, taken from an empty connection to a device that has reported in and passed its checks. None of it is difficult. The parts worth slowing down for are the ones where a wrong choice stays quiet: a connector half-enabled, a package with the wrong connectivity type baked in, or a fleet tagged from two authorities at once. Get those right and the sensor is standing on ground you can reason about.
Two consoles, one connection
Before a single policy is authored, the Intune and Defender tenants have to know about each other, and the connection is two-sided. In the Defender portal the switch lives under Settings, Endpoints, Advanced features, where you enable the Intune connection and save. In Intune the same relationship appears under Endpoint security, Microsoft Defender for Endpoint, where the connection status needs to read as enabled, and it is mirrored under Tenant administration among the connectors. Microsoft has renamed these toggles more than once, so confirm the exact label in your own tenant rather than trusting a screenshot from a year ago, but the state you are checking for is unambiguous: both sides agree the connection is live, and the portal gives itself up to fifteen minutes to say so.
This connection is doing more than lighting a status indicator. It is the thing the onboarding policy will reach back through in a moment to pull the package, so a policy authored before the connection is live will simply have nothing to retrieve. The Windows, Android, and iOS compliance toggles that sit in the same Intune blade are a separate concern, the risk-into-compliance path, and they belong to the last build in this block rather than this one. Here you need only the connection itself.
The policy that pulls the package
Onboarding through Intune is a single endpoint security policy, and the settings that matter are few. The trap is the platform choice at the top. Author the policy against the platform named simply Windows, not the older Windows 10 and later platform, which Microsoft retired in 2022 and which still carries deprecated setting names like the onboarding blob that will mislead anyone who finds them. On the current platform the work reduces to four decisions.
| Setting | Value | Why |
|---|---|---|
| Platform | Windows | The legacy Windows 10 and later platform is deprecated and its profile carries stale setting names. Everything current lives on Windows. |
| Profile | Endpoint detection and response | The profile that carries onboarding. A Configuration Manager variant exists for tenant-attach estates; use it only where ConfigMgr owns the device. |
| Client configuration package type | Auto from connector | Intune retrieves the onboarding package from the tenant connection you just confirmed. Nothing to paste by hand, and nothing to go stale when Microsoft rotates the package. |
| Assignment | A pilot device group | The policy offers a one-click deploy to every applicable device. Decline it. Onboard a ring, watch it report, then widen in stages. |
Choosing Auto from connector over the manual onboarding option is the choice that pays off quietly for years. The manual path pastes a static onboarding blob into the policy, which works and then slowly rots, because the blob is a point-in-time artifact and the policy becomes a place stale configuration hides. Auto from connector makes the tenant connection the source of truth and the policy a pointer to it. Sample sharing can stay at its default, which submits samples and keeps Block at First Sight working; the protection engine’s tuning, including what that setting does and does not affect, is the next build’s subject, not this one.
Connectivity type is not in the policy
Here is the detail that surprises people, because it breaks the assumption that everything about onboarding lives in the onboarding policy. The connectivity type, streamlined or standard, is not a setting in the endpoint detection and response profile at all. It is chosen once, from a dropdown on the Defender portal onboarding page, and it is baked into the package the moment you generate it. The policy you just built inherits whatever the tenant onboarding page was set to, which means the connectivity decision is made in a different console from the policy that delivers it, and is easy to leave on a default nobody chose.
For a new build, choose streamlined. It collapses the old sprawling service-URL allow-list down to a single consolidated wildcard endpoint plus a short residual set for certificate revocation, updates, and SmartScreen, and it is the posture worth carrying forward on modern clients and servers. It is not the default, and the legacy URLs are not being deprecated, so nothing forces the choice, which is exactly why it gets missed. The one real constraint is that changing an already-onboarded device’s connectivity type is not a toggle. It means generating a fresh package with the new type, delivering it through a new onboarding policy to a test group, and rebooting the device, after which you can confirm the result in advanced hunting by reading the connectivity type off the device record. Decide streamlined at the start and you never have to run that migration.
For the machines Intune cannot reach
Some machines will never take an Intune policy in time to matter: a down-level server, a workgroup box inherited in an acquisition, a fleet that needs a sensor reporting this afternoon while enrollment is still weeks out. For those, Microsoft now ships a dedicated Defender deployment tool, generated from the same Defender onboarding page and managed as a deployment package. It produces a single executable that installs both the antivirus platform and the sensor, handles the prerequisites, and reaches all the way back to Windows 7 SP1 and Server 2008 R2 on the modern agent through to Server 2025. Two guardrails matter in a build: it can carry a deployment key so the package is not a loose artifact anyone can run, and its expiry is configurable up to a year, which Microsoft advises keeping as short as the rollout allows.
The important architectural note is that this tool is its own onboarding methodology and does not integrate with the others. A device onboarded by the deployment tool is onboarded by the deployment tool, not by Intune, and that distinction is the same channel-ownership rule the whole series turns on. Reach for it deliberately, for the populations that genuinely need it, and do not let it become a second uncoordinated path onto machines Intune already manages.
Tag once, from one place
Device tags drive grouping, role-based scoping, and later the enforcement scoping that the security settings build depends on, so they are worth setting deliberately. There are four ways to apply one: manually in the portal, through a registry value under the Advanced Threat Protection policy key, through an Intune custom OMA-URI, and through dynamic asset rules that tag by attribute. What Microsoft does not document is any precedence among them, which is the whole point. Because nothing arbitrates when two methods disagree, the discipline is to choose a single tagging authority per class of device and stay with it. A fleet tagged half from the registry and half from a dynamic rule is a fleet whose grouping you can no longer predict.
Proving it actually onboarded
A policy that reports success in Intune means the policy was delivered, not that the sensor is healthy. Those are different claims, and the gap between them is where silent onboarding failures live. Verify the device itself. The sensor service should be running, and its onboarding state should read as onboarded in the registry.
sc query sense
reg query "HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status" /v OnboardingStateThe service should return a running state, and OnboardingState should return 1. When either is wrong, the SENSE operational event log carries the specific failure, and the Microsoft Defender for Endpoint Client Analyzer, downloaded from Microsoft and run on the device, produces a full report that names the cause rather than leaving you to guess. In the portal, the device inventory under Assets carries an onboarding status column and a sensor health state column, and a healthy device reads as onboarded and active in both. A device that never appears there did not onboard, whatever Intune claimed.
To confirm the sensor is not just present but detecting, Microsoft publishes a scripted endpoint detection and response test on its client detection-test page. Run it against a pilot device and confirm an alert surfaces in the portal within a few minutes. I point to the current page rather than reproduce the script here, because the exact command and its prerequisites have shifted between doc revisions and a build sheet should send you to the version that is live when you read it. The check you are making is simple: a controlled action on the device produces a visible alert, end to end, which is the only proof that onboarding did what it was for.
The short version of the whole build, to run down before you widen the ring:
- Both consoles agree the Intune connection is enabled.
- The onboarding policy is on the Windows platform, set to Auto from connector, assigned to a pilot group.
- The tenant onboarding page is set to streamlined connectivity before the package is generated.
- Each device shows the sensor service running and an onboarding state of 1.
- The device appears in the portal inventory as onboarded and active.
- A detection test produces an alert end to end.
Where this goes next
Onboarding puts the sensor on the device and nothing more. It does not configure anything, and on the populations you deliberately did not enroll in Intune it leaves an open question the anchor already named: how do you configure a device that Intune does not manage? That is the security settings management channel, and standing it up end to end is the next build.
Defender XDR
‹ Previous: [D 2.1] Onboarding Defender for Endpoint: Every Path and When to Use It
Next: [D 2.2] Security Settings Management: Configuring MDE Without Enrollment ›
