In [3.2] I made the argument about whether you should hybrid join at all. This is the other article: how the join actually works, what has to be true before it can, and how to read a device that refuses. Hybrid Entra ID Join is a machine process with a handful of moving parts and a sync cycle sitting in the middle of it, and nearly every failed join I have ever been called about traces back to one of five causes. None of them are exotic.
What actually happens
The join is not a user action and it is not an enrollment. It is a background registration performed by the device itself, and it runs in a fixed order. A domain-joined Windows device periodically fires a scheduled task, Automatic-Device-Join under the Workplace Join folder, triggered at user sign-in. The task’s first job is discovery: it looks for a Service Connection Point in the configuration partition of your Active Directory forest. The SCP is a small object holding exactly two facts, your tenant ID and a verified tenant domain name, and Entra Connect writes it during device-option configuration. If the device finds a valid SCP (or a client-side override, more on that below), it knows which tenant it belongs to.
The device then generates a key pair and writes a certificate to its own computer object in AD. Entra Connect picks that computer object up on its next sync cycle and creates a matching device object in Entra ID. Only after that object exists can the device complete registration against the Device Registration Service and finish the join. That middle step is the part people forget: in a managed domain (password hash sync or pass-through authentication, which is almost everyone now) the join cannot complete faster than your sync cycle. A freshly provisioned machine sitting in a “pending” state for half an hour is not broken. It is waiting for Connect to run. Federated domains with AD FS can complete the join immediately without waiting for sync, which is one of the few remaining arguments federation has left, and not a good enough one.
Once joined, the payoff arrives at the next sign-in: the device gets a Primary Refresh Token. The PRT is what turns the join into single sign-on for Entra-protected resources, what feeds device identity into Conditional Access, and what makes the whole exercise worth doing. A hybrid-joined device without a PRT is a registration that succeeded and an outcome that failed.
Prerequisites, honestly
Entra Connect Sync is required. Cloud Sync, the newer lightweight agent, does not synchronize device objects, so it cannot carry hybrid join; if you are mid-migration from Connect to Cloud Sync, hybrid join is one of the workloads that keeps Connect alive. Inside Connect, two configuration details do the quiet damage. OU filtering must include the OUs where your computer objects actually live, because a computer object outside the sync scope never becomes a device object and the join waits forever. And the default device attributes must not be excluded from the sync rules; trimmed-down custom configurations occasionally strip them and produce joins that fail with nothing obviously wrong.
The network side is short but strict. In system context, not user context, devices need to reach three endpoints.
| Endpoint | Purpose | Note |
|---|---|---|
| enterpriseregistration.windows.net | Device Registration Service | Must be excluded from TLS inspection |
| login.microsoftonline.com | Authentication | |
| device.login.microsoftonline.com | Device authentication | Must be excluded from TLS inspection |
The TLS inspection exclusions are not a nicety. Device registration uses client certificate authentication, and a proxy that breaks and inspects those two endpoints breaks the certificate exchange with it. If your security stack inspects everything by default, this is the exception request to file before you touch anything else.
The two questions everyone asks
Do you need Seamless SSO? No. Seamless SSO is an optional Entra Connect feature aimed at older scenarios and browser SSO from domain-joined devices that are not hybrid joined. A hybrid-joined device gets its single sign-on from the PRT, natively, with nothing extra deployed. If hybrid join is rolling out across the estate, Seamless SSO is not a prerequisite and for current Windows it is not even particularly useful. Configure it if you have a specific legacy population that needs it; do not treat it as part of this design.
Do you need Group Policy? Not for the join itself, in the normal case. With a forest-wide SCP in place, current Windows joins on its own with no policy pushed at all. GPOs enter this story in exactly two places. The first is controlled rollout, covered next. The second is the handoff to Intune, and it matters because hybrid join and MDM enrollment are two different events that people persistently conflate. The join gives the device an identity in Entra. It does not enroll the device in Intune. For that, the Enable automatic MDM enrollment using default Azure AD credentials policy, delivered by GPO to the pilot OUs you choose, tells the device to enroll using its user’s credential, and the MDM auto-enrollment scope in Entra decides which users that applies to. The scoping mechanics are in [3.2.2], and where this method sits among the enrollment paths is [3.2.1].
Rolling it out on purpose
A forest-wide SCP means every domain-joined, sync-scoped device in the forest starts joining as soon as it can. Sometimes that is fine. In an estate with Conditional Access policies keyed to device state, or multiple tenants in play after an acquisition, it is not, and Microsoft’s documented answer is a targeted deployment: leave the forest-wide SCP unset (or remove it), and deliver the tenant pointer to a chosen OU through registry values instead. The device checks its local registry before it queries AD, so this works cleanly.
Path: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD
TenantId REG_SZ <your tenant GUID>
TenantName REG_SZ <verified domain, e.g. contoso.com>Deploy both values with a GPO preference linked to the pilot OU, expand the link scope as rings pass, and cut over to the forest-wide SCP when you are done piloting, or simply keep the GPO as the permanent mechanism if you prefer the explicitness. One AD FS-specific caveat from the documentation: if you are federated, apply the same client-side values to the AD FS servers themselves, otherwise AD FS considers itself the source of device objects and will eventually clean up devices it thinks are inactive.
Reading a device that will not join
Everything you need is in two places on the device. The first is dsregcmd /status, run elevated. The top of the output answers the state question in three lines.
| Field | Healthy hybrid join | What a wrong value means |
|---|---|---|
| DomainJoined | YES | NO means this is not a hybrid join candidate at all |
| AzureAdJoined | YES | NO means the registration has not completed; read the Diagnostic Data section |
| WorkplaceJoined | NO | YES means a user added a personal work account; not the same thing, and worth cleaning up |
| AzureAdPrt | YES | Joined but NO here means sign-in is not producing a token; the join worked, SSO did not |
When AzureAdJoined is NO, the same output includes a Diagnostic Data section that names the phase that failed, precheck, discover, authenticate, or join, and gives you client and server error codes. That phase name is the fastest routing decision in the whole exercise. The second place is the event log, under Applications and Services, Microsoft, Windows, User Device Registration, which carries the same story with timestamps.
| Error | Phase | What it actually is |
|---|---|---|
| 0x801c001d | Discover | SCP missing or malformed; the device cannot learn its tenant. Check the SCP, or the CDJ\AAD registry values in a targeted rollout. |
| 0x801c0021 | Discover | Discovery failed generically; almost always network reachability to enterpriseregistration.windows.net in system context. |
| 0x80072efd / 0x80072ee2 | Discover | Cannot connect or timed out; proxy in the way. System context does not inherit user proxy settings, and an authenticating proxy that returns an HTML challenge page breaks the flow. |
| 0x801c03f2 | Join | Device not found in Entra. The computer object has not synced yet. Usually transient; if it persists, the object is outside your Connect OU scope. |
| 0x80090016 | Join | TPM keyset error, typically after a TPM clear. Recent Windows recovers on its own; otherwise dsregcmd /leave and let the task rejoin. |
And a field note that outranks the table: when several devices fail the same way at the same time, stop debugging devices. The most common root cause of fleet-wide hybrid join trouble I have walked into is not on any endpoint. It is Entra Connect quietly unhealthy: a server left in staging mode after a migration, export errors accumulating unread, or a sync scope that silently stopped covering a renamed OU. Check Connect Health, or the Synchronization Service console, before you touch a third device. The devices are usually telling the truth about a directory problem.
Where this leaves you
A working hybrid join gets you device identity, Conditional Access participation, and SSO on an estate that still needs its domain. That is real value, and it is still a stopgap, for all the reasons in [3.2]. Build it cleanly, monitor Connect like the tier-zero dependency it is, and let every hardware refresh move devices to Entra join instead. The best hybrid join deployments are the ones designed to shrink.
Intune Deployment Guide · Phase 3: Device Entry
‹ Previous: [3.2.2] Configuring Automatic Enrollment Scope
Next: [3.3] MacOS Enrollment ›
