Microsoft Entra Hybrid Join Troubleshooting: Find the Failed Phase

Microsoft Entra hybrid join troubleshooting: find the failed phase

Originally published 16 July 2021 · Reviewed 4 November 2026

A hybrid-join error is a symptom, not a complete diagnosis. The most useful first question is where registration stopped: before discovery, while discovering the tenant, during authentication, or when creating the device registration. This guide follows that order and uses Microsoft's current guidance as the source of truth.

Microsoft renamed Azure Active Directory to Microsoft Entra ID. Windows still prints the state field AzureAdJoined; keep that exact field name when reading command output. Microsoft Entra hybrid join applies to a domain-joined Windows device that is also joined to Microsoft Entra ID.

1. Capture status in the right context

In a normal Command Prompt opened by the signed-in domain user, run:

dsregcmd /status

Use this non-elevated view to inspect the current user's state and normal device status. The Device State section includes AzureAdJoined, DomainJoined, and EnterpriseJoined. Microsoft documents these combinations:

WorkplaceJoined is a separate user-state field for Microsoft Entra registered accounts. Do not use it as a substitute for the device join fields.

For pre-join diagnostics, use an elevated Command Prompt when appropriate. Microsoft's dsregcmd guidance says this runs the diagnostic in SYSTEM context, which is closest to the context used by the actual join. Elevation can affect user-specific values such as WAM state, so return to the signed-in user's normal session when reviewing user and PRT state. Some post-join diagnostics, including KeySignTest, require elevation; follow the instruction for that diagnostic rather than elevating every check.

The output can contain tenant and device identifiers, account names, endpoint URLs, correlation IDs, and certificate-related details. Review and redact it before sharing. Synthetic examples in this article do not represent a real tenant.

2. Find the failed phase before choosing a fix

On supported Windows versions, inspect Diagnostic Data and Previous Registration. The Error Phase helps separate pre-check, discover, auth, and join. Record the client error code and, if present, server code, server message, HTTP status, and request ID. On older versions or when these fields are absent, use the event logs described below.

This is a navigation aid, not a one-code/one-fix chart. The same broad phase can contain different causes. Use the suberror and server response before changing configuration.

3. Work through pre-check and discovery

Pre-check: can the device reach its domain?

For hybrid join, the device needs line of sight to an on-premises domain controller. Test from the organization's network or a VPN that provides the required domain connectivity. A device connected only to the public internet may not be able to complete the on-premises checks.

Discover: can it read the right tenant configuration?

Confirm that the service connection point is present, readable from the relevant forest, and configured for the intended verified Microsoft Entra domain. Then check discovery connectivity from the device in SYSTEM context. Microsoft's guide calls out https://enterpriseregistration.windows.net for registration discovery and, on applicable Windows versions, https://login.microsoftonline.com for user-realm discovery.

If an outbound proxy is required, test the computer account's ability to discover and silently authenticate through it. Success in a browser as the signed-in user does not prove that SYSTEM-context traffic works. Don't bypass the proxy or weaken its controls as a diagnostic shortcut; involve the network administrator and use the URL and suberror in the event data.

Microsoft documents 0x801c001d as an SCP-read/configuration problem and 0x801c0021 as a generic discovery failure whose suberror should be examined. These codes help select the next evidence source; they do not tell you to rewrite the SCP without checking the actual tenant and forest design.

4. Treat authentication errors according to join type

The authentication phase in Microsoft's hybrid-join troubleshooting flow applies to federated domain accounts. Windows uses the federation service and an active WS-Trust endpoint in that scenario. If the domain is managed rather than federated, do not assume that an AD FS or WS-Trust repair applies.

Microsoft lists 0xcaa90014 (ERROR_ADAL_WSTRUST_REQUEST_SECURITYTOKEN_FAILED) as a WS-Trust response fault that prevented assertion acquisition. Check the federation service configuration and its authentication logs for the underlying server error. The client code alone does not identify which federation setting is wrong.

Microsoft lists 0xc000023c as STATUS_NETWORK_UNREACHABLE. Its troubleshooting guidance associates this class of result with an error response from the Microsoft Entra authentication service or a WS-Trust endpoint, or with connectivity to a required endpoint. Inspect the surrounding event data: event 1022 can identify the URL being accessed, while event 1084 contains a network suberror in the documented PRT flow. Do not treat the status as proof that the whole network is down.

5. Read join-phase responses and verify sync state

For a join-phase error, note the registration type and the complete server response. 0x801c03f2 is documented as a directory failure; Microsoft's example reports that the device object identified by the request was not found. In a sync-join flow, the device object might not yet be available because synchronization has not completed. Verify the intended object and sync status with the administrator responsible for Microsoft Entra Connect before attempting cleanup.

For AADSTS50155, Microsoft describes device authentication failure while Microsoft Entra ID is trying to issue a primary refresh token. One documented possibility is that the device was deleted or disabled. Verify its state in the tenant and follow Microsoft's re-registration procedure for the device's actual join type. Do not respond to this code by disconnecting every work account, deleting unrelated device records, or clearing the TPM.

6. Separate device join from primary refresh token health

A successful device join does not prove that a user's primary refresh token (PRT) was acquired. Check AzureAdJoined under device state and AzureAdPrt under the signed-in user's SSO state separately. If PRT acquisition failed, inspect AcquirePrtDiagnostics or RefreshPrtDiagnostics when present. The attempt status, credential type, endpoint, HTTP status, server error code, and server description provide more context than the short error alone.

On shared devices, Microsoft notes that diagnostic details can relate to another user's login attempt. Confirm the User Identity and attempt time before connecting the error to the person currently signed in. For AADSTS50155, use the device management FAQ and device-type-specific re-registration guidance; do not assume the local device is healthy just because a command returns some successful fields.

7. Use Event Viewer when status output is not enough

For older Windows versions, Microsoft directs administrators to Applications and Services Logs > Microsoft > Windows > User Device Registration. Its current hybrid-join guide maps events 304, 305, and 307 to join troubleshooting on earlier versions. On newer versions, Previous Registration includes phase and error details.

For PRT acquisition, inspect the Microsoft Entra Operational and Analytic logs under Applications and Services Logs > Microsoft > Windows > AAD. Microsoft documents events 1006 and 1007 as the start and end of the PRT acquisition flow; the events between them provide context, and event 1007 records the final error. For server errors, the documented operational events 1081 and 1088 can contain Microsoft Entra and WS-Trust errors respectively. Use Microsoft's current instructions for the Windows build and scenario; event IDs and available fields vary by version and diagnostic path.

A safe order of operations

1. Run dsregcmd /status in the signed-in user's normal session and identify the device join state.
2. Find Error Phase, Client ErrorCode, and any server response from the failed registration.
3. Check domain-controller line of sight for pre-check; SCP and discovery for discover; federated authentication only for auth; sync and object state for join.
4. Use Event Viewer when the command output lacks the phase or suberror. Keep the event time and correlation information for the administrator who needs to correlate server-side logs.
5. Make one evidence-backed change at a time, under the tenant's change process, then rerun the same relevant check.

Do not publish diagnostic output without reviewing it for names, tenant/device IDs, request IDs, endpoint URLs, and other identifying values. Keep original logs in the approved secure support channel; replace values with synthetic placeholders in public discussion.

Microsoft references

• Troubleshoot devices by using the dsregcmd command — command context, join state, pre-join and post-join diagnostics, reviewed 4 November 2026.
• Troubleshoot Microsoft Entra hybrid joined devices — phase flow, discovery, authentication, event logs, and error codes, reviewed 4 November 2026.
• Verify Microsoft Entra hybrid join — verification context, reviewed 4 November 2026.
• Microsoft Entra authentication and authorization error codes — AADSTS descriptions, including 50155, reviewed 4 November 2026.

This article was originally published on 16 July 2021. It was reviewed on 4 November 2026 to update product naming and align troubleshooting guidance with the linked Microsoft pages. Follow Microsoft's live documentation for changes after this review.