How to Check Microsoft Entra ID (Azure AD) Join Status with dsregcmd on Windows
Read dsregcmd /status output to determine whether a Windows device is Microsoft Entra joined, hybrid joined, domain joined, or Entra registered - plus how to check its Primary Refresh Token and cloud device health. Read-only, no changes made.
- Difficulty
- Beginner
- Time required
- 5 minutes
- Steps
- 7
- Platform
- Windows
- Last tested
- July 5, 2026
Table of contents
Quick Answer
Go to the stepsOpen Windows Terminal or Command Prompt as the signed-in user (not elevated) and run dsregcmd /status. In the Device State section, read AzureAdJoined and DomainJoined together: YES/NO means Microsoft Entra joined, YES/YES means hybrid joined, NO/YES means domain joined only, and NO/NO with WorkplaceJoined YES (in User State) means Microsoft Entra registered.
- Sign in as the affected user and open Windows Terminal or Command Prompt (do not run as administrator).
- Run dsregcmd /status.
- Read AzureAdJoined and DomainJoined in the Device State section to identify the join type.
- Check AzureAdPrt in the SSO State section is YES for working single sign-on.
- Scan Diagnostic Data for any test that is not SUCCESS.
dsregcmd /statusExpected result: A multi-section report; the Device State section shows AzureAdJoined, EnterpriseJoined, and DomainJoined as YES or NO, which together identify the device's join type.
Key takeaways
- How to run dsregcmd /status and read its output to determine a Windows device's Microsoft Entra ID join state, Primary Refresh Token status, tenant details, and registration health.
- Device join state drives single sign-on, Conditional Access, and Intune management. When Teams keeps prompting for credentials or a device won't enroll, dsregcmd /status is usually the fastest first command to isolate whether the problem is device registration, a missing PRT, or connectivity.
- Read AzureAdJoined and DomainJoined together to identify the join type, then confirm AzureAdPrt is YES for working single sign-on.
Introduction
The dsregcmd utility is built into Windows and is the primary way to inspect how a device is registered with Microsoft Entra ID (formerly Azure AD). Running dsregcmd /status is entirely read-only: it reports the current state and changes nothing on the device or in your tenant. The output is organised into readable sections - Device State, Device Details, Tenant Details, User State, SSO State, and Diagnostic Data - so instead of guessing whether a sign-in issue is a missing device object, a broken Primary Refresh Token, or a connectivity failure, you can read the relevant section and narrow the problem before making any change. One important detail up front: run the command as the signed-in user, not from an elevated prompt, because the user-context fields (such as the PRT and Web Account Manager state) only report correctly in the user's own session.
Who this is for: IT admins, help desk technicians, and MSPs troubleshooting Microsoft Entra ID (formerly Azure AD) device identity on Windows 10 and Windows 11 endpoints.
Before you start
- Access
- Local sign-in to the Windows device as the user whose registration you want to inspect. No admin rights and no license are required to read the status.
- Environment
- Windows 10 or Windows 11. dsregcmd is built in - nothing to install.
- Vendor
- Microsoft
- Tested environment
- Verified against Microsoft Learn dsregcmd documentation, July 2026. Field availability noted for Windows 10 21H1 and later.
- Last tested
- Read-only procedure
Field names follow the current Microsoft Learn dsregcmd reference; a few fields (DeviceAuthStatus, the PRT Attempt Status error code) require Windows 10 version 21H1 or later.
About 5 minutes to run and interpret.
This procedure is read-only. dsregcmd /status only reports the device's current registration state and does not modify the device or your tenant.
Note: Run as the user, not elevated
Run dsregcmd /status in the user's own session, not from an elevated prompt. Some user-context fields (for example WamDefaultSet) can show an error when the command runs elevated, which leads to false troubleshooting. Elevation is only needed for a couple of optional device-key tests such as KeySignTest.
Note: Output contains identifying data
dsregcmd output can include the tenant ID, device ID, certificate thumbprints, and user principal name. Sanitize or collect only the specific fields you need before sharing the output outside your support team.
1Open a terminal in the user's own session
Get a command line running in the correct context so the status reflects the affected user.
Sign in to Windows as the user whose device registration you want to check. Open Windows Terminal, Command Prompt, or PowerShell normally - do not choose "Run as administrator". The Primary Refresh Token and Web Account Manager fields are tied to the logged-in user's session, so an elevated prompt can report them incorrectly.
If you are helping a user remotely, have them open the terminal themselves rather than launching it under a different admin account.
Expected result: A command prompt open in the signed-in user's context, with no User Account Control elevation.
Note
Only a few device-level tests (such as KeySignTest) require an elevated prompt; the join state, PRT, and connectivity fields all read correctly as the normal user.
2Run dsregcmd /status
Produce the full device registration report.
Type the command below and press Enter:
dsregcmd /status
The tool prints a report broken into labelled sections inside plus-sign borders: Device State, Device Details, Tenant Details, User State, SSO State, and Diagnostic Data (plus Windows Hello for Business checks). Scroll to the top and work through the sections in order.
dsregcmd /statusExpected result: A multi-section text report. The first block is the Device State section containing AzureAdJoined, EnterpriseJoined, and DomainJoined.
Note
To pull just the join flags into a script, you can filter the output, e.g. dsregcmd /status | findstr /i "AzureAdJoined DomainJoined EnterpriseJoined".
3Read the Device State to identify the join type
Determine whether the device is Entra joined, hybrid joined, domain joined, or Entra registered.
In the Device State section, read these three flags together:
- AzureAdJoined - YES if the device is joined to Microsoft Entra ID.
- DomainJoined - YES if the device is joined to an on-premises Active Directory domain.
- EnterpriseJoined - YES if the device is joined to an on-premises Device Registration Service. A device cannot be both EnterpriseJoined and AzureAdJoined.
The combination of AzureAdJoined and DomainJoined tells you the join type:
- YES / NO - Microsoft Entra joined (cloud-only).
- YES / YES - Microsoft Entra hybrid joined.
- NO / YES - Domain joined only (on-premises).
- NO / NO - not directory-joined here; check WorkplaceJoined in the User State section for Microsoft Entra registered.
Expected result: A clear YES or NO for AzureAdJoined and DomainJoined, mapping to one of the four join states above.
Note
If a device you expect to be joined shows blank or --- values, treat that as a registration problem rather than a specific join state, and move on to the Diagnostic Data section.
4Confirm cloud device health with DeviceAuthStatus
Check that the device object still exists and is enabled in Microsoft Entra ID, not just locally.
Still in the Device State section, find DeviceAuthStatus. This test contacts Microsoft Entra ID under the system context to confirm the cloud device object is healthy:
- SUCCESS - the device is present and enabled in Microsoft Entra ID.
- FAILED - the device is disabled or deleted in the directory.
- ERROR - the test could not run (usually no network connectivity to Entra ID from the system context).
A device can look joined locally while its cloud object has been disabled or deleted, so this field is worth checking whenever sign-in fails despite AzureAdJoined : YES.
Expected result: DeviceAuthStatus reads SUCCESS on a healthy device.
Note
DeviceAuthStatus was added in the Windows 10 May 2021 update (version 21H1). On older builds the field may be absent - that is expected, not an error.
5Check the Primary Refresh Token in the SSO State section
Confirm the device has a valid PRT, which is what enables single sign-on to Microsoft 365.
Locate the SSO State section and read these fields:
- AzureAdPrt - should be YES for working single sign-on. NO means Windows could not acquire the Primary Refresh Token from Microsoft Entra ID.
- AzureAdPrtUpdateTime - when the PRT was last refreshed. If this is more than four hours old, the PRT may not be refreshing correctly.
- AzureAdPrtExpiryTime - when the current PRT expires.
- EnterprisePrt - the equivalent token for AD FS / hybrid scenarios.
If AzureAdPrtUpdateTime looks stale, lock and unlock the device to force a refresh, then run dsregcmd /status again and confirm the time updated.
Expected result: AzureAdPrt : YES with an AzureAdPrtUpdateTime within the last few hours.
Note
On Windows 10 21H1 and later, when AzureAdPrt is NO, an Attempt Status line beneath it shows the error code for the failed PRT acquisition - useful for looking up the specific cause.
6Verify Tenant Details and User State
Confirm the device is registered to the correct tenant and read the per-user registration flags.
In the Tenant Details section, confirm TenantName matches your organisation and TenantId is the expected GUID. These details only appear when the device is Microsoft Entra joined or hybrid joined - they are absent for Entra registered devices.
In the User State section, check:
- WorkplaceJoined - YES means the signed-in user has added a Microsoft Entra registered (Workplace Join) account. This is how you confirm the Entra registered state when Device State shows NO / NO.
- WamDefaultSet - YES means the Web Account Manager account is set for the user. An error here often means the command was run elevated; rerun it as the user.
- NgcSet - YES means Windows Hello for Business is configured for the user.
Expected result: TenantName and a valid TenantId GUID that match your tenant, and User State flags consistent with the device's configuration.
Note
To cross-check the TenantId against the directory, sign in to the Microsoft Entra admin center with at least the Global Reader role and go to Entra ID > Overview > Properties, or use Microsoft Graph PowerShell: Connect-MgGraph -Scopes "Organization.Read.All" then (Get-MgOrganization).Id. The legacy Get-AzureADTenantDetail cmdlet is retired and should no longer be used.
7Scan Diagnostic Data for registration and connectivity errors
Spot the specific test that failed when a device will not register or acquire a token.
The Diagnostic Data section runs a series of connectivity and configuration tests and reports each one. On a healthy device the tests report success and no error block appears. When something is wrong, look for a failed test and its error code - for hybrid join issues you may see a DRS Discovery Test block with a failure code, or a Previous Registration block listing an Error Phase, Client ErrorCode, and Server ErrorCode.
Note the Error Phase (which stage failed) and the error codes, then match them against Microsoft's dsregcmd troubleshooting reference rather than guessing. For deeper analysis, the User Device Registration event log (Event Viewer > Applications and Services Logs > Microsoft > Windows > User Device Registration) records the same failures with event IDs.
Expected result: On a healthy device, the diagnostic tests report success with no error block. On a failing device, a named test and error code point to the failing stage.
Note
Error codes and their meanings are documented in Microsoft's official dsregcmd and hybrid-join troubleshooting articles - treat the codes as a lookup key rather than memorising them.
How to Read dsregcmd Output and Determine Your Device's Join State
Interpret result
dsregcmd doesn't hand you a single verdict - you assemble the picture from a few key fields. Start with AzureAdJoined and DomainJoined in Device State to establish the join type, then use DeviceAuthStatus to confirm the cloud device object is still healthy, and AzureAdPrt in SSO State to confirm single sign-on can work. Tenant Details and User State confirm you are looking at the right tenant and the right per-user flags, and Diagnostic Data is where you go when a device is failing rather than merely misclassified. Because the report is a point-in-time snapshot in the user's context, always interpret it against the scenario you expect: a cloud-only laptop should be Entra joined, while a device that still uses on-premises Group Policy should be hybrid joined.
Normal result: On a correctly registered cloud device: AzureAdJoined YES, DeviceAuthStatus SUCCESS, AzureAdPrt YES with a recent update time, a matching TenantName/TenantId, and Diagnostic Data tests reporting success.
Abnormal result: AzureAdJoined NO on a device you expect to be joined, DeviceAuthStatus FAILED (device disabled or deleted in Entra), AzureAdPrt NO or a stale AzureAdPrtUpdateTime (SSO will prompt repeatedly), or a Diagnostic Data test failing with an error code - each points to a specific area to investigate.
AzureAdJoined YES, DomainJoined NO
Microsoft Entra joined
Cloud-only device, authenticated and managed through Microsoft Entra ID.
AzureAdJoined YES, DomainJoined YES
Microsoft Entra hybrid joined
Device is in both on-premises AD and Entra ID, so it gets Group Policy and cloud SSO/Conditional Access.
AzureAdJoined NO, DomainJoined YES
Domain joined only
Traditional on-premises device with no Entra ID registration.
AzureAdJoined NO, DomainJoined NO, WorkplaceJoined YES
Microsoft Entra registered
Typically a personal or BYOD device with a work account added; Tenant Details will be absent.
Troubleshooting
dsregcmd /status shows an error on WamDefaultSet or blank user fields
Warning
Cause: The command was run from an elevated (administrator) prompt, so the user-context fields cannot be read.
Close the elevated window and rerun dsregcmd /status as the signed-in user without elevation. The User State and SSO State fields will then populate correctly.
AzureAdPrt shows NO even though AzureAdJoined is YES
Warning
Cause: The device is registered but Windows could not acquire a Primary Refresh Token - often network connectivity, a Conditional Access block, or a stale token.
Lock and unlock the device to force a PRT refresh, then rerun dsregcmd /status. Confirm the device can reach login.microsoftonline.com. On Windows 21H1+, read the Attempt Status error code under AzureAdPrt and look it up in the PRT troubleshooting guide.
DeviceAuthStatus reads FAILED
Critical
Cause: The device object has been disabled or deleted in Microsoft Entra ID even though the local device still reports as joined.
Check the device under Microsoft Entra ID > Devices. If it was disabled, re-enable it; if deleted, the device must be re-registered according to its join type. This is a directory-side fix, not something dsregcmd /status changes.
Tenant Details section is missing entirely
Note
Cause: Tenant Details only appear for Entra joined or hybrid joined devices - an Entra registered (Workplace Join) device does not show them.
Check WorkplaceJoined in the User State section. If it is YES, the device is Microsoft Entra registered, and the absence of Tenant Details is expected rather than a fault.
DeviceAuthStatus field is not present in the output
Note
Cause: The field was introduced in Windows 10 version 21H1; older builds do not display it.
Confirm the Windows build with winver. On older builds, rely on the Diagnostic Data section and the Entra admin center to confirm cloud device health instead.
Frequently asked questions
Does dsregcmd /status require administrator rights?
No. dsregcmd /status is read-only and should be run as the signed-in user, not elevated. Running it as administrator can cause user-context fields like the PRT and WamDefaultSet to report incorrectly. Only a few optional device-key tests need elevation.
What does AzureAdJoined YES mean in dsregcmd output?
It means the device is registered and joined to Microsoft Entra ID, so it can be managed in the cloud and can use single sign-on and Conditional Access. Read it together with DomainJoined: YES/NO is Entra joined, while YES/YES is Entra hybrid joined.
How do I tell hybrid joined from Entra registered?
Hybrid joined devices show AzureAdJoined YES and DomainJoined YES in Device State. Entra registered devices show AzureAdJoined NO and DomainJoined NO, but WorkplaceJoined YES in the User State section, and they have no Tenant Details block.
What should AzureAdPrt be, and why does it matter?
AzureAdPrt should be YES. The Primary Refresh Token is what lets Windows sign the user in silently to Microsoft 365 and other Entra apps. If it is NO, users get repeated authentication prompts and single sign-on stops working.
Can running dsregcmd /status change or break anything?
No. The /status switch only reports the current state and makes no changes to the device or the tenant. State-changing operations are separate switches such as /join, /leave, and /forcerecovery, which are not part of a status check.
Conclusion
dsregcmd /status is the quickest read-only way to see how a Windows device is registered with Microsoft Entra ID. Run it as the signed-in user, read AzureAdJoined and DomainJoined together to identify the join type, confirm DeviceAuthStatus and AzureAdPrt for cloud health and single sign-on, and drop into Diagnostic Data when a device is actually failing. Because it changes nothing, it is safe to run first on any sign-in or enrolment issue before you touch registration.
Read AzureAdJoined and DomainJoined together to identify the join type, then confirm AzureAdPrt is YES for working single sign-on.
dsregcmd /statusSources4
