Entra hybrid join not working: find the phase that is failing

Entra hybrid join not working is a reporting problem before it is a configuration problem. The instinct is to rejoin the device or rerun Microsoft Entra Connect, which destroys the only evidence that names the cause. Windows already knows which phase failed and with which error code, and it will tell you in one command. Below is how to read that output, what each phase actually depends on, and the three failures that survive a correct configuration. Device trust is the whole point of the exercise, which makes this a prerequisite for Conditional Access policy design.

Read the join state before you change anything

Open a command prompt as an administrator and run dsregcmd /status. Microsoft’s guide to troubleshooting Microsoft Entra hybrid joined devices names three fields in the Device State block and the value each one should carry.

1# The three fields that classify the problem, from dsregcmd /status.
2# Run it elevated. Un-elevated, the key sign test is skipped and the
3# diagnostic section is less useful.
4DomainJoined     : YES
5WorkplaceJoined  : NO
6AzureAdJoined    : YES

DomainJoined at NO means the device is not joined to on-premises Active Directory and cannot do Microsoft Entra hybrid join at all. AzureAdJoined at NO means the join has not finished, which is the case you are here to diagnose. WorkplaceJoined at YES is the field people misread: it means a work or school account was added to the device as a personal registration before the hybrid join completed. On Windows 10 1607 and later Microsoft states that account is ignored, so it is a symptom of sequencing rather than the blocker itself.

The field reference for every other line in that output is in Microsoft’s dsregcmd command reference. Read it before you interpret anything unusual, because several fields are expected to be empty on a healthy hybrid joined device.

Entra hybrid join not working: the four phases

Registration runs in four phases, and each one fails for a different reason. Precheck confirms the device can see a domain controller. Discover reads the service connection point and fetches metadata from the device registration service. Authentication acquires a token, and applies only to federated domains. Join writes the device object.

On Windows 10 1803 and later, the answer is in the Diagnostic Data section of the same output. The Previous Registration block carries Error Phase and Client ErrorCode, which together tell you the phase and the fault. Above it sits a row of named tests, and the first one that reads FAIL is your phase.

1# The Diagnostic Data block. The first FAIL is the phase to investigate.
2# The bracketed pair is error code and sub-error code.
3AD Connectivity Test    : PASS
4AD Configuration Test   : PASS
5DRS Discovery Test      : FAIL [0x801c0021/0x80072ee2]
6DRS Connectivity Test   : SKIPPED
7Token acquisition Test  : SKIPPED
8Fallback to Sync-Join   : ENABLED

On builds earlier than 1803 there is no Diagnostic Data block. Use Event Viewer instead, under Applications and Services Logs, Microsoft, Windows, User Device Registration. Event IDs 304, 305 and 307 carry the join failures, 201 carries the discovery sub-error, and 204 carries the join phase error.

Precheck and discover: line of sight and the service connection point

Precheck fails for one reason. The device has no network line of sight to an on-premises domain controller, so it must be on the internal network or on a VPN that provides one. A laptop failing at precheck in a coffee shop is behaving correctly.

Discover is where most real faults live, and most reports of Entra hybrid join not working resolve to one of four codes Microsoft documents here:

• 0x801c001d, DSREG_AUTOJOIN_ADCONFIG_READ_FAILED. The service connection point object cannot be read, so the device never learns which tenant to register with.
• 0x801c0021, DSREG_AUTOJOIN_DISC_FAILED. Generic discovery failure. The sub-error in the brackets is the useful half, and 0x80072ee2 there is a network timeout.
• 0x801c001f, DSREG_AUTOJOIN_DISC_WAIT_TIMEOUT. Discovery timed out reaching enterpriseregistration.windows.net.
• 0x801c003a, DSREG_DISCOVERY_TENANT_NOT_FOUND. The service connection point carries the wrong tenant ID, or the tenant has no active subscriptions.

That last one is worth sitting with. A service connection point that exists, is readable, and points at the wrong tenant produces a failure that looks like a network problem and is not. The configuration steps, including which credentials write the object, are in Microsoft’s guide to configuring Microsoft Entra hybrid join, which also lists the endpoints the device must reach: enterpriseregistration.windows.net, login.microsoftonline.com, device.login.microsoftonline.com, and autologon.microsoftazuread-sso.com if seamless single sign-on is in use.

Every one of those must be reachable in the system context, not the user’s. That distinction accounts for a large share of the discover failures that make no sense, and it has its own error code: 0x8007000d, E_INVALIDDATA, which Microsoft explains as the server response failing to parse "likely because the proxy is returning an HTTP 200 with an HTML authorization page". The device asked for JSON and the proxy handed it a sign-in page.

Authentication: federated domains only

If the domain is managed, using password hash sync or pass-through authentication, this phase does not apply and you can skip it. Microsoft’s own position is that most organisations deploy against managed domains.

Federated domains authenticate the device to Entra ID over WS-Trust using integrated Windows authentication, which means the identity provider has to support it. The three configuration failures are 0xcaa90017, the protocol is not WS-Trust at all, 0xcaa9002c, the Metadata Exchange endpoint did not return valid XML, and 0xcaa90023, no username and password endpoint could be discovered. With AD FS, the endpoints under Service, Endpoints need the 2005 and 13 variants of windowstransport, usernamemixed and certificatemixed enabled.

Microsoft attaches a warning to that list which belongs in a security review rather than a troubleshooting one. Both windowstransport endpoints should be intranet facing only and must not be published externally through the Web Application Proxy. Enabling them to fix a join and leaving them exposed is a worse outcome than the broken join.

Join: the device object Entra ID cannot find

The join phase code you will meet most often is 0x801c03f2, DSREG_E_DIRECTORY_FAILURE, with a server error code of DirectoryError and a server message along the lines of "The device object by the given id is not found".

Read the Registration Type field next to it. When it says sync, the device is relying on Microsoft Entra Connect having already synchronised its computer object, and the error is telling you that synchronisation has not happened. This is a directory problem wearing a client error code, and chasing it on the endpoint wastes the afternoon. Three prerequisites decide it: Entra Connect at version 1.1.819.0 or later, the default device attributes left in the sync configuration rather than filtered out, and the organisational units holding those computer objects actually included in scope. Which sync engine you are running changes how you check that, and the difference is covered in Entra Cloud Sync vs Connect Sync.

The other join failure worth knowing is 0x80090016, NTE_BAD_KEYSET, where the Trusted Platform Module keyset does not exist. Microsoft attributes this to the TPM being cleared, in BIOS or in Windows, or to a bad sysprep image, and the guidance is simply not to clear the TPM. Recovery can require removing and re-adding accounts, which is painful on a device carrying several.

The failure modes

Three things break hybrid join on configurations that are, on paper, correct.

TLS break-and-inspect. This is the one I would check first in any organisation running an inspecting proxy, and Microsoft’s warning is unambiguous: traffic to device.login.microsoftonline.com and enterpriseregistration.windows.net must be excluded from TLS break-and-inspect. Failing to exclude them interferes with client certificate authentication and breaks both device registration and device-based Conditional Access. The second half matters more than the first. A device that registered before the proxy rule changed will keep its join and start failing Conditional Access, which presents as an access problem rather than a join problem. If device filters have stopped matching, the Conditional Access device filter is usually innocent.

Proxy authentication in the wrong context. Device registration runs as the machine, so an authenticated outbound proxy has to accept machine-context authentication. A proxy that works perfectly for every signed-in user will fail every registration, and the symptom is a discover timeout rather than an authentication error. Microsoft publishes a Test Device Registration Connectivity script for exactly this, and it is worth running under the system account before touching anything else.

Judging a fresh configuration too early. Sync-join depends on a directory synchronisation cycle, so a device that fails immediately after the service connection point is written has not told you anything yet. Re-running the join repeatedly during that window produces a trail of failures that all have the same meaningless cause.

What I would do differently

I have not run this at scale in production. My tenant is a lab with no enrolled devices, so what follows is judgement about the order of operations rather than a measured result, and the error codes above all come from Microsoft’s current documentation rather than from my own captures.

The change I would make to how most teams approach this is to stop treating Entra hybrid join not working as a device problem. Two of the four phases fail for reasons that live in the directory or the network, and one of them, 0x801c03f2 with Registration Type sync, is almost always a synchronisation gap. Reading the phase first and the error code second costs a minute and routes the ticket to the right team, which is worth more than any individual fix on this page.

I would also treat the proxy exclusions as a standing configuration item rather than a troubleshooting step, because that failure arrives late and disguised. Nothing breaks on the day the rule changes. It breaks on the next registration, and separately it degrades Conditional Access on devices that are already joined, which is the version nobody connects back to the proxy change. If hybrid join sits underneath Intune enrolment in your environment, the same reasoning applies to the wider Intune troubleshooting order.

Last verified: 9 October 2026.