dsregcmd /status on the affected device first — the Diagnostic Data section shows the exact error code and failed phase.Azure AD hybrid join not working is one of the most operationally painful issues in a Microsoft 365 environment. Devices look fine in Active Directory but show as “Pending” or missing in Entra ID, Conditional Access policies block users who should have access, and the failure is entirely silent — no obvious error on the device, no alert from Azure AD Connect.
I have resolved this issue across dozens of Windows 10 and Windows 11 endpoints in environments running Windows Server 2019 and 2022 domain controllers with Azure AD Connect. Every case traces to one of four root causes, and the diagnostic path is completely deterministic once you know where to look. This guide walks through the complete fix workflow from first symptom to verified resolution.
By the end you will be able to diagnose any hybrid Azure AD join failure using dsregcmd /status, fix SCP misconfiguration, force Azure AD Connect sync, resolve devices stuck in pending state, and clear Event ID 304 and 306 errors permanently.
Table of Contents
- Understanding Hybrid Azure AD Join Architecture
- Affected Systems and Error Severity
- Phase 1: Diagnose with dsregcmd /status
- Phase 2: Verify the Service Connection Point
- Phase 3: Check Azure AD Connect Sync
- Phase 4: Verify Network Connectivity to Microsoft Endpoints
- Phase 5: Force Re-registration on the Device
- Troubleshooting: 5 Common Failure Scenarios
- Verification: Confirming Successful Hybrid Join
- Best Practices
- FAQ: People Also Ask
- Conclusion
Understanding Hybrid Azure AD Join Architecture
Hybrid Azure AD join is the process by which a Windows device that is domain-joined to on-premises Active Directory also registers itself with Azure AD (Entra ID), creating a dual-identity device. This dual identity is the prerequisite for Conditional Access policies, Intune co-management, and seamless SSO to Microsoft 365 services.
Registration Flow
On-premises AD (domain joined)
|
Device reads SCP from AD Configuration partition
|
SCP returns Azure AD Tenant ID
|
Device requests auth token via AAD Kerberos or ADFS
|
Device posts to https://enterpriseregistration.windows.net
|
Azure AD Connect syncs computer object to Entra ID
|
Device state: AzureAdJoined = YES
Key Components
- SCP (Service Connection Point): An AD object in the Configuration partition that tells devices which Azure AD tenant to register with. Azure AD Connect creates this during initial setup — a missing or misconfigured SCP is the most common root cause of Azure AD hybrid join not working.
- Azure AD Connect: Syncs computer objects from on-premises AD to Entra ID. The device cannot complete cloud registration until the computer object is synced.
- AAD Kerberos: In ADFS-less environments (password hash sync or pass-through auth), Windows uses AAD Kerberos to obtain the token needed to authenticate to the registration endpoint.
- Enterprise Registration Endpoint:
https://enterpriseregistration.windows.net— must be reachable from the device without SSL inspection intercepting the connection.
Affected Systems
- Windows 10 (build 1803 and later) and Windows 11 — all builds
- Windows Server 2019 / 2022 domain controllers
- Azure AD Connect (all versions — sync must be running and healthy)
- Environments using password hash sync, pass-through auth, or ADFS
Error severity: High. Devices failing hybrid Azure AD join cannot satisfy device-compliance Conditional Access requirements, leaving users locked out of Microsoft 365 resources including Exchange Online, SharePoint, and Teams.
Phase 1: Diagnose with dsregcmd /status
This is always step one. Run on the affected device from an elevated command prompt and read the output carefully before changing anything.
C:> dsregcmd /status
Focus on the Device State section first:
+----------------------------------------------------------------------+
| Device State |
+----------------------------------------------------------------------+
AzureAdJoined : NO <- registration not completed
EnterpriseJoined : NO
DomainJoined : YES <- on-prem domain join is OK
DomainName : CORP.LOCAL
TenantId : <- blank = SCP missing or unreachable
Key fields and what they mean:
| Field | Expected Value | If Wrong — Likely Cause |
|---|---|---|
| AzureAdJoined | YES | Registration not completed — check SCP and network |
| DomainJoined | YES | On-prem domain join missing — fix AD membership first |
| TenantId | Your tenant GUID | SCP missing or pointing to wrong tenant |
| AzureAdPrt | YES | Token acquisition failed — check AAD Kerberos or ADFS |
Then scroll to the Diagnostic Data section for the specific error code:
| Diagnostic Data |
+----------------------------------------------------------------------+
AadRecoveryEnabled : NO
Executing Account Name : CORPusername
Previous Registration : 2025-11-15 08:32:01
Registration error : Phase: Discover, ErrorCode: 0x801c0013
Error code 0x801c0013 means the device could not discover the Azure AD tenant — the SCP is the first thing to check.
Phase 2: Verify the Service Connection Point
Run this PowerShell on a domain controller. If the SCP is absent or contains the wrong tenant ID, every device in the domain will fail hybrid join silently.
# Check SCP exists and contains correct tenant ID
$scp = Get-ADObject `
-Filter {objectClass -eq "serviceConnectionPoint"} `
-SearchBase "CN=Configuration,DC=corp,DC=local" `
-Properties keywords
$scp | Select-Object Name, Keywords
Expected output:
Name Keywords
---- --------
62a0ff2e-97b9-4513-943f-0d221bd30080 {azureADName:yourtenantname.onmicrosoft.com,
azureADId:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
If the SCP is missing or shows the wrong tenant ID, recreate it using Azure AD Connect:
# Run on the Azure AD Connect server
Import-Module ADSync
Initialize-ADSyncDomainJoinedComputerSync `
-AdConnectorAccount "CORPAADConnectAccount" `
-AzureADCredentials (Get-Credential)
Alternatively, open the Azure AD Connect wizard and navigate to Configure Device Options → Configure Hybrid Azure AD join → reconfigure. This recreates the SCP automatically with the correct tenant ID.
Phase 3: Check Azure AD Connect Sync
Even if the device completes local registration, it will show as “Pending” in Entra ID if Azure AD Connect has not synced the computer object to the cloud. Check sync status and force a cycle if needed.
# Check sync scheduler status on the Azure AD Connect server
Import-Module ADSync
Get-ADSyncScheduler
# Expected output:
# SyncCycleEnabled : True
# NextSyncCyclePolicyType : Delta
# CurrentlyRunning : False
# Force an immediate delta sync
Start-ADSyncSyncCycle -PolicyType Delta
# Full sync - use sparingly, takes significantly longer
Start-ADSyncSyncCycle -PolicyType Initial
After the sync completes, verify the device appears in Entra ID:
- Open Entra admin center → Devices → All devices
- Search for the computer name
- Check Join type — should show “Hybrid Azure AD joined”, not “Pending”
- Check Registered date is recent
If the device shows “Pending” even after sync, the computer object is in the cloud but the device has not yet completed the client-side registration task. Proceed to Phase 5.
Phase 4: Verify Network Connectivity to Microsoft Endpoints
The device must reach all of these endpoints during registration. Test from the affected device, not from a server or a different network segment.
# Test all required registration endpoints
Test-NetConnection -ComputerName enterpriseregistration.windows.net -Port 443
Test-NetConnection -ComputerName login.microsoftonline.com -Port 443
Test-NetConnection -ComputerName device.login.microsoftonline.com -Port 443
Test-NetConnection -ComputerName enrollment.manage.microsoft.com -Port 443
# All should return:
# TcpTestSucceeded : True
If any test returns TcpTestSucceeded : False, check proxy and firewall rules. The most commonly missed issue is SSL inspection — if your firewall decrypts and re-signs HTTPS traffic, the Windows device registration service rejects the re-signed certificate and fails silently.
# Check if a proxy is configured
netsh winhttp show proxy
# If proxy is set, ensure these are in the bypass list:
# *.microsoftonline.com
# enterpriseregistration.windows.net
# *.azure.com
# device.login.microsoftonline.com
Phase 5: Force Re-registration on the Device
After confirming SCP, sync, and network are all correct, trigger the registration task manually from an elevated command prompt on the affected device.
# Method 1 - Force recovery (recommended first attempt)
dsregcmd /forcerecovery
# Method 2 - Trigger the scheduled task directly
schtasks /run /tn "MicrosoftWindowsWorkplace JoinAutomatic-Device-Join"
# After running either command, sign out and sign back in with a domain account
# Registration completes in the user context during login
# Method 3 - Leave and re-register (last resort)
dsregcmd /leave
# Reboot, then sign in with a domain account
# The scheduled task runs automatically on the next user login
Verify success immediately after re-login:
C:> dsregcmd /status | findstr AzureAdJoined
AzureAdJoined : YES
Troubleshooting: 5 Common Failure Scenarios
Issue 1: Device Stuck in “Pending” State in Entra ID
Symptoms: Device appears in Entra ID Devices list with Join type “Pending”. dsregcmd /status shows AzureAdJoined: NO.
Root cause: Azure AD Connect synced the computer object but the device has not completed the Automatic-Device-Join scheduled task. Most commonly caused by the device being offline during the task window or a proxy blocking the registration endpoint.
# Check registration event log for failures
Get-WinEvent -LogName "Microsoft-Windows-User Device Registration/Admin" |
Where-Object {$_.Id -in @(304, 306)} |
Select-Object TimeCreated, Id, Message |
Format-List
# Force re-registration
dsregcmd /forcerecovery
Prevention: Test endpoint connectivity with Test-NetConnection from a representative device on every network segment before deploying hybrid join at scale.
Issue 2: Event ID 304 — Token Acquisition Failure
Symptoms: Event ID 304 in the Device Registration admin log with message “Unable to get token for device registration.”
Root cause: The device cannot obtain a Kerberos token. Common in environments that migrated from ADFS to password hash sync without enabling AAD Kerberos on domain controllers.
# Verify AAD Kerberos is configured on domain controllers
Get-AzureADKerberosServer `
-Domain corp.local `
-DomainCredential (Get-Credential) `
-CloudCredential (Get-Credential)
# If not configured, enable it:
Set-AzureADKerberosServer `
-Domain corp.local `
-DomainCredential (Get-Credential) `
-CloudCredential (Get-Credential)
Prevention: When decommissioning ADFS, always enable AAD Kerberos on domain controllers before removing ADFS services. Decommission ADFS last.
Issue 3: SSL Inspection Blocking Registration
Symptoms: Network endpoint tests pass but registration fails. Event log shows certificate or SSL handshake errors.
Root cause: Firewall or proxy performing SSL inspection is re-signing Microsoft’s certificates. Windows device registration rejects re-signed certificates by design.
# On the firewall/proxy - add SSL bypass rules for:
# - enterpriseregistration.windows.net
# - login.microsoftonline.com
# - device.login.microsoftonline.com
# - *.azure.com
# These endpoints must present the original Microsoft certificate.
# SSL inspection must be disabled for these specific destinations.
Prevention: Add all Microsoft authentication and registration endpoints to the SSL inspection bypass list as part of your initial network configuration, before deploying hybrid join.
Issue 4: Computer Object OU Not in Azure AD Connect Sync Scope
Symptoms: Device does not appear in Entra ID at all — not even as Pending.
Root cause: The OU containing the computer object is excluded from Azure AD Connect sync scope, so the object is never synced to the cloud.
# In Azure AD Connect Synchronization Service Manager:
# Operations > check for errors on the AD connector
# Connectors > AD connector > Properties > Configure Directory Partitions
# Verify the OU containing computer accounts is included (ticked)
# After fixing the OU scope, run a full sync:
Start-ADSyncSyncCycle -PolicyType Initial
Prevention: Every time a new OU is created for computer objects, immediately verify it is included in the Azure AD Connect sync scope.
Issue 5: Hybrid Join Fails After Domain or Tenant Changes
Symptoms: Previously working devices suddenly show AzureAdJoined: NO after an AD restructure, tenant migration, or Azure AD Connect reinstallation.
Root cause: The SCP still references the old tenant ID or domain name, invalidating all existing device registrations.
# Remove old SCP and recreate via Azure AD Connect
$oldSCP = Get-ADObject `
-Filter {objectClass -eq "serviceConnectionPoint"} `
-SearchBase "CN=Configuration,DC=corp,DC=local"
Remove-ADObject $oldSCP -Confirm:$false
# Reconfigure in Azure AD Connect wizard:
# Configure Device Options > Hybrid Azure AD join > reconfigure
# This recreates the SCP with the correct tenant ID
Verification: Confirming Successful Hybrid Join
# On the device - confirm full hybrid join state
C:> dsregcmd /status
# Required fields must show:
# AzureAdJoined : YES
# DomainJoined : YES
# AzureAdPrt : YES <- Primary Refresh Token obtained
# TenantId : [your tenant GUID]
# DeviceId : [device GUID registered in Entra ID]
# In Entra admin center - confirm device record:
# Devices > All devices > [device name]
# Join type : Hybrid Azure AD joined (not Pending)
# Registered : [recent date]
# Compliant : Yes (if Intune compliance policy is assigned)
# In Azure AD sign-in logs - confirm device appears in authentication:
# Azure AD > Sign-in logs > [user sign-in]
# Device > Join type : Hybrid Azure AD joined
Best Practices
Pre-deployment
- Test endpoint connectivity before mass deployment. Run
Test-NetConnectionagainst all required Microsoft endpoints from a device on each network segment before rolling out hybrid join. - Verify SCP configuration before imaging devices. A missing SCP means every device deployed will fail registration silently with no error visible to the end user.
- Confirm computer OUs are in Azure AD Connect sync scope. Check this every time a new OU is created for computer objects.
Monitoring
- Monitor Event IDs 304 and 306 via Windows Event Forwarding or your SIEM. These events fire on every failed registration attempt and identify the exact failure phase.
- Review the Entra ID Devices — Pending report weekly. A growing pending list means something systematic is broken in the registration pipeline.
- Configure Azure AD Connect Health alerts for sync failures. A stopped sync cycle causes all new devices to remain as Pending indefinitely.
Security
- Use Conditional Access requiring hybrid join. This creates an operational incentive to keep hybrid join healthy — broken devices will be noticed immediately when users cannot access resources.
- Do not exclude registration endpoints from SSL inspection without compensating controls. If bypass rules are added, ensure those endpoints are monitored by your SIEM for anomalous traffic patterns.
FAQ: People Also Ask
Why is hybrid Azure AD join stuck on pending?
A device shows “Pending” in Entra ID when Azure AD Connect has synced the computer object but the device itself has not yet completed the client-side Automatic-Device-Join scheduled task. The most common causes are the device being offline when the task ran, a proxy blocking enterpriseregistration.windows.net, or SSL inspection stripping Microsoft certificates. Run dsregcmd /forcerecovery and check Event IDs 304 and 306 in the Device Registration admin log.
How do I check hybrid join status with dsregcmd?
Run dsregcmd /status from an elevated command prompt on the affected device. Check AzureAdJoined : YES and AzureAdPrt : YES in the Device State section. If AzureAdJoined is NO, scroll to the Diagnostic Data section — it shows the specific error code and registration phase that failed, which tells you exactly where to focus the fix.
What causes Azure AD hybrid join to fail?
The four most common root causes are a missing or misconfigured Service Connection Point in Active Directory, the computer object OU being excluded from Azure AD Connect sync scope, the device being unable to reach enterpriseregistration.windows.net due to firewall or proxy rules, and SSL inspection stripping Microsoft certificates on the registration endpoint connection.
How long does hybrid join take?
The actual registration process takes under two minutes once all prerequisites are met. End-to-end, from device login to appearing as “Hybrid Azure AD joined” in Entra ID, typically takes 15 to 30 minutes — the bulk of that time is the Azure AD Connect delta sync cycle running and the scheduled task firing on the next user login.
Related Articles
- Microsoft Intune Setup Guide: Complete MDM Configuration 2026
- Active Directory Replication Failed: Complete Fix Guide 2026
- Active Directory Explained: Complete Beginner to Advanced Guide 2026
- Windows Server 2025 Upgrade Guide 2026
Conclusion
Azure AD hybrid join not working always traces to one of four root causes: SCP misconfiguration, Azure AD Connect sync scope, network or proxy blocking the registration endpoint, and SSL inspection breaking certificate validation. The diagnostic path is deterministic — start with dsregcmd /status, read the error code, and work through the phases in this guide in order.
- Always start with dsregcmd /status — it identifies the exact failed phase and eliminates guesswork from troubleshooting.
- Verify the SCP first — a wrong tenant ID causes every device in your domain to fail registration silently.
- Check Azure AD Connect sync scope — a silently excluded OU means devices never appear in Entra ID at all.
- Test all network endpoints before deployment — SSL inspection is the most commonly overlooked blocker in enterprise environments.
- Monitor Event IDs 304 and 306 — these are the early warning system for hybrid join health at scale.
Need Expert Help with Azure AD Hybrid Join or Entra ID?
I provide professional Microsoft 365, Entra ID, and Azure infrastructure consulting for businesses across Pakistan and internationally. Whether you need hybrid join fixed across a fleet of devices, a Conditional Access policy review, or Azure AD Connect health remediation — I can help remotely.
Services
- Azure AD / Entra ID configuration and troubleshooting
- Azure AD Connect deployment and health monitoring
- Microsoft Intune MDM setup and device compliance
- Conditional Access policy design
- Microsoft 365 administration and migrations
Email: itexpert@navedalam.com
WhatsApp: +92 311 935 8005
Website: navedalam.com
Free 30-minute consultation — no obligation.
About the Author
Naveed Alam is a certified Network and Cloud Engineer with deep expertise in Microsoft 365, Azure AD, and hybrid identity infrastructure. He holds CCNA, AZ-900, and CompTIA A+ certifications and has resolved hybrid join, Azure AD Connect, and Conditional Access issues for organisations across Pakistan and internationally.
Connect: LinkedIn · navedalam.com · itexpert@navedalam.com