The ticket says the laptop is domain-joined and Intune-ready, but in Microsoft Entra admin center > Devices the record sits on Pending for days. Outlook starts prompting. Conditional Access that requires a hybrid joined device fails. Someone suggests dsregcmd /leave and a reboot.
Pending means the device has not finished registering with Entra ID yet. Until that finishes, there is no working device identity for Conditional Access, and there is usually no primary refresh token either. This post is a read-first order for that state. Every step only reads until you decide a change is justified.
TL;DR
- Confirm the join type the device thinks it has:
DomainJoined : YESandAzureAdJoined : NO(or YES with a failed Previous Registration) is the hybrid-pending pattern. - Read Previous Registration / Diagnostic Data in
dsregcmd /statusbefore you touch sync. The error and timestamp usually point at SCP, network, or the computer object. - On the sync side: is the computer in an OU that Entra Connect syncs, and does the device object exist in Entra at all?
- On the client side: can the computer account reach
login.microsoftonline.comthrough your proxy, and is the Service Connection Point (SCP) discoverable? - Do not leave/rejoin until BitLocker recovery keys are escrowed and you have confirmed the registration error, not just the Pending label.
What "Pending" actually means
In Entra ID, a hybrid joined device usually moves through:
- The computer object syncs from Active Directory (or is created by the join flow).
- The device registers its keys with Entra ID.
- The join completes and the device shows as Microsoft Entra hybrid joined with a recent activity time.
Pending means step 1 may have happened (or a stub exists), but step 2 has not succeeded yet. The Devices blade is describing cloud state. The laptop's local state is in dsregcmd /status. You need both.
Related symptom on the same device: AzureAdPrt : NO. That is often a result of a failed or incomplete hybrid join. Fix registration first; then re-check the PRT.
Step 1: Read dsregcmd the right way
On the affected laptop, open a Command Prompt or PowerShell window and run:
dsregcmd /status
For registration diagnostics, an elevated prompt is fine. For the SSO / PRT section later, run it again as the signed-in user without elevation.
Focus on these sections first:
| Section / field | What you want | What Pending usually looks like |
|---|---|---|
AzureAdJoined |
Eventually YES
|
NO, or briefly YES after a partial attempt |
DomainJoined |
YES for hybrid |
YES (if this is NO, you are not on a hybrid path) |
WorkplaceJoined |
Usually NO for a clean hybrid join |
YES can mean a personal/work registration sitting beside a failed hybrid attempt |
| Previous Registration / Diagnostic Data | A successful registration | Error code, timestamp, and phase of the last attempt |
ClientTime / server time skew |
Closely aligned | Large skew breaks token and registration flows |
Copy the Previous Registration block into the ticket. That is the single most useful paste for hybrid-pending cases.
A trimmed failure often looks like:
+----------------------------------------------------------------------+
| Diagnostic Data |
+----------------------------------------------------------------------+
Previous Registration : 2026-10-13 18:04:22.000 UTC
Error Phase : discover
Client ErrorCode : 0x801c001d
Server ErrorCode : ...
Server ErrorDescription : ...
Error Phase tells you where it died (discover, precheck, join, and similar). Treat that as the branch label for the rest of this post.
Step 2: Confirm the computer actually syncs
Open Entra admin center > Devices and search by device name and by device ID from dsregcmd if one exists.
| What you see | Likely meaning | Next read-only check |
|---|---|---|
| No device object at all | Computer not in scope for Entra Connect, or sync has not run | OU path of the computer in AD; Entra Connect sync rules / OU filtering |
| Object exists, Join type empty or Pending, no activity | Sync created or stubbed the object; client registration never finished | Previous Registration error on the client |
| Object exists as Microsoft Entra registered only | Workplace join path, not hybrid |
WorkplaceJoined on the client; user may have added a work account |
| Duplicate names, different Device IDs | Stale object from a rebuild or reimage | Compare local DeviceId to each cloud record |
A read-only Graph check (needs Device.Read.All or equivalent) once you have a device ID:
# Read-only: look up one device by its dsregcmd DeviceId (GUID)
Connect-MgGraph -Scopes 'Device.Read.All'
$deviceId = 'PUT-DEVICE-ID-FROM-DSREGCMD-HERE'
Get-MgDevice -Filter "deviceId eq '$deviceId'" |
Select-Object DisplayName, DeviceId, ApproximateLastSignInDateTime,
TrustType, AccountEnabled, ProfileType, OperatingSystem
TrustType of ServerAd is the hybrid join trust. Missing object or wrong trust type keeps you in Pending-land no matter what you reboot.
Also confirm in Active Directory:
- The computer object is enabled.
- It sits in an OU included by Entra Connect (not in a filtered OU, and not excluded by an attribute filter).
- A delta sync has run since the computer was created or moved. Pending that lasts "forever" is often "we never synced that OU."
Step 3: Service Connection Point and discovery
Hybrid join discovery uses a Service Connection Point (SCP) in the on-premises AD configuration partition so the client knows which Entra tenant to register with.
If Error Phase is discover-related, check:
- That the SCP exists and points at the correct tenant.
- That the client can read it (site connectivity / AD replication to the DC the client uses).
- That you did not configure a client-side discovery override that points somewhere else (less common, but worth knowing exists).
You do not need to change the SCP to verify it. Have someone with AD read rights confirm the object and tenant ID match the tenant you are looking at in the portal. A wrong-tenant SCP produces some of the most confusing Pending tickets: the device may register somewhere your helpdesk is not watching.
Step 4: Network path for the computer account
User browser access to Microsoft 365 is not enough. Hybrid join registration is a device operation. The computer must reach Entra ID endpoints, often before any user signs in.
Common blockers:
| Blocker | Why it breaks Pending | What to verify (read-only) |
|---|---|---|
| Proxy requires interactive user auth | Computer account cannot authenticate silently | Proxy logs for the device name / machine account; WPAD / PAC behavior at startup |
| TLS inspection on login endpoints | Registration HTTPS fails or returns garbage | Whether login.microsoftonline.com and related endpoints are bypassed for inspection |
| Firewall allows users but not device subnets | Labs or VLANs never complete join | Egress from the device subnet to required Microsoft endpoints |
| Time sync skew | Tokens and registration fail intermittently | Client vs DC vs NTP |
If Previous Registration shows network-class errors (timeouts, name resolution, connection failures), fix the path before you touch Entra Connect again.
Step 5: Client event logs when dsregcmd is thin
When Previous Registration is empty or unhelpful, use Event Viewer:
- Applications and Services Logs > Microsoft > Windows > User Device Registration > Admin
- Applications and Services Logs > Microsoft > Windows > AAD > Operational
A read-only pull of recent registration errors:
# Read-only: recent User Device Registration errors/warnings
Get-WinEvent -LogName 'Microsoft-Windows-User Device Registration/Admin' -MaxEvents 100 |
Where-Object { $_.LevelDisplayName -in 'Error','Warning' } |
Select-Object TimeCreated, Id, LevelDisplayName, Message |
Format-List
Correlate the timestamps with Previous Registration and with the last Entra Connect sync. A pattern of "fails every 30–60 minutes" usually means the scheduled task is retrying and hitting the same discover/network/SCP problem each time.
Step 6: Workplace join sitting beside hybrid
If WorkplaceJoined : YES and hybrid is Pending, the user (or a previous setup) may have added a work account that created an Entra registered device object. That object is not a hybrid join. Conditional Access that requires hybrid joined will still fail.
Read-only response:
- Note both device records in Entra (registered vs hybrid / Pending).
- Decide which identity the CA policy actually requires.
- Do not delete cloud objects until you know which one the laptop's
DeviceIdmatches and that recovery keys / Intune enrollment are safe.
When leave/rejoin is justified
dsregcmd /leave plus a rejoin is a real fix for a corrupted local registration state. It is a poor first step for Pending caused by OU filtering, SCP, or proxy.
Before you leave/rejoin:
- You have a concrete registration error (Previous Registration or event log), not only the Pending label.
- BitLocker recovery passwords are visible in Intune or Active Directory for this device.
- You know whether Autopilot, GPO, or a scheduled task will bring the device back, and how long the user can be without a working join.
- You have written the change down for the ticket.
If the computer was never synced, leave/rejoin will not invent sync scope. Fix filtering and wait for a sync cycle first.
FAQ
Why does Entra show Pending when the PC has been domain-joined for weeks?
Domain join and hybrid join are separate. Domain join only creates the AD computer account. Hybrid join also needs sync (or the join flow) plus a successful device registration with Entra ID. Weeks of Pending usually means the client never completed registration, or the object is filtered from sync.
AzureAdJoined is NO but DomainJoined is YES. Is that Pending?
That is the local view of an incomplete hybrid join. Check Previous Registration and whether a device object exists in Entra. The portal may show Pending, or it may show nothing if sync never created the object.
Do I need Intune for hybrid join?
No. Hybrid join is an Entra ID + AD / Entra Connect concern. Intune enrollment is separate. You can have hybrid joined devices that are not yet enrolled, and enrolled devices that are not hybrid joined.
Will fixing hybrid join fix AzureAdPrt NO?
Often yes, once registration succeeds and the user signs in (or locks/unlocks) so Windows can request a PRT. If the device still shows AzureAdPrt : NO after a healthy hybrid join, switch to a PRT-focused triage.
Can Conditional Access require hybrid join while devices are Pending?
It can, and that is how Monday lockouts happen. Keep those policies in report-only until Pending volume is low and PRT issuance looks healthy in sign-in logs.
Related posts
- AzureAdPrt : NO in dsregcmd /status: A Read-First Primary Refresh Token Triage
- Company Portal can't connect / device not syncing: a 10-minute triage order for Intune admins
- Conditional Access Report-Only Results: Logs vs On
- Intune compliance "Not applicable", "Is active" and minimum OS
Free checklist
If you are about to enforce "require Microsoft Entra hybrid joined device," Pending devices and missing PRTs are exactly what report-only mode is for. The free Conditional Access pre-enforcement checklist puts device join, pilot groups and report-only review on one page:
If you triage a lot of enrollment and join tickets, the Intune & M365 Admin Starter Pack includes enrollment hygiene notes, break/fix cards and a read-only local enrollment snapshot built around the same dsregcmd fields: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=hybrid-azure-ad-join-pending
Admin Pack Studio; not affiliated with Microsoft. The scripts above only read. Test any change to device registration or Entra Connect scope in a pilot OU or lab first.
Top comments (0)