dsregcmd /status Decoded: The Complete Field Reference for WHfB and PRT

If you troubleshoot Windows Hello for Business (WHfB), Entra join, or on-premises single sign-on, one command answers more questions than any portal: dsregcmd /status. The problem is that its output is a wall of sixty-plus fields across seven sections with almost no explanation, and most admins read only the three lines they already recognise. This is the complete field-by-field reference - every section, every line, the registry keys the values actually come from, the services and scheduled tasks that keep the whole thing running, and which Event IDs to check when a field looks wrong - so you can read the whole picture instead of guessing at it.

The problem: sixty-plus fields and no legend

Most admins read only the three lines of dsregcmd /status they already recognise and guess at the rest. That is how a device with a clear answer in front of you still takes an hour to diagnose - the information is there, unlabelled, spread across seven sections most people have never scrolled past.

Why it happens: the output spans seven sections with no explanation

The command dumps Device State, Device Details, Tenant Details, User State, SSO State, Diagnostic Data and (conditionally) the NGC Prerequisite Check back to back, with no descriptions. Each section answers a different question, the fields you need for Windows Hello for Business (WHfB) are scattered across four of them, and the values themselves are read live from a handful of registry keys and populated by services most admins have never had a reason to look at.

How to verify: run it in the user context first

Run dsregcmd /status as the signed-in user, not elevated - NgcSet, AzureAdPrt and OnPremTgt only populate in the user context. From an elevated prompt they read blank and send you chasing problems that do not exist.

The fix: read it section by section

Section 1 - Device State: what kind of join is this?

The top block answers "how is this device registered?" Three booleans combine into the join type, and this truth table is worth memorising because half of all WHfB questions start with getting the join type right:

• Virtual Desktop - NOT SET on a physical PC. On an Azure Virtual Desktop or Windows 365 session host this reads AVD or W365 - useful for confirming a WHfB policy is actually landing on the host type you expect.
• Device Name - the fully-qualified name this device presents to Entra. If HostNameUpdated further down reads NO, this can lag the real hostname after a rename.

Note: the Microsoft Entra registered (Workplace Joined) state is not shown here - it appears in the User State section under WorkplaceJoined.

Section 2 - Device Details: the device identity and its key

Shown only for Entra joined / hybrid joined devices. This whole block is a live read of the device's certificate, stored in HKLM:\SYSTEM\CurrentControlSet\Control\CloudDomainJoin\JoinInfo\<thumbprint> - more on that registry key below.

• DeviceId - the device's unique ID in the tenant (this is what you search for in the Entra portal).
• Thumbprint - the device certificate's thumbprint. This is also the name of the registry subkey under CloudDomainJoin\JoinInfo that everything in this section reads from.
• DeviceCertificateValidity - the device cert's own lifetime, separate from the Hello key. A device stuck re-registering every few weeks with no policy change is worth checking against this window - a cert nearing expiry that fails to auto-renew (usually a connectivity problem to enterpriseregistration.windows.net) reads as device auth failures with no obvious cause.
• KeyProvider - Microsoft Platform Crypto Provider (TPM-backed) or Microsoft Software Key Storage Provider (software). Where the device key lives - not the user's Hello key, which is reported separately under NgcKeyId.
• TpmProtected - YES means the device private key is in the TPM. NO is a flag worth chasing.
• DeviceAuthStatus - SUCCESS means the device is present and enabled in Entra ID. FAILED. Device is either disabled or deleted explains a whole class of sudden sign-in failures - and correlates to Event 362 in the User Device Registration log (see the event-log section below).

Section 3 - Tenant Details: the endpoints this device is actually talking to

This section is almost always skipped, but it is where connectivity and Cloud Kerberos Trust questions get answered. Every URL here is a real endpoint the device calls during join, key registration, or Kerberos ticket requests - if one of these is unreachable through a proxy or firewall, that specific function breaks silently.

• TenantName / TenantId - which Entra tenant this device is joined to. On a device that unexpectedly can't reach WHfB policy, confirm this matches the tenant you think it does - a device joined to the wrong tenant (common after a merger or a re-image against a stale image) silently gets none of the policy you assigned.
• MdmUrl / MdmTouUrl / MdmComplianceUrl - the Intune enrollment, terms-of-use and compliance-portal endpoints. If MDM enrollment itself is failing (not WHfB), this is the first thing to confirm is reachable.
• JoinSrvUrl / KeySrvUrl / WebAuthNSrvUrl / DeviceManagementSrvUrl - all live under enterpriseregistration.windows.net. JoinSrvUrl is device join itself; KeySrvUrl is where the WHfB public key gets registered; WebAuthNSrvUrl backs passkey/FIDO2 registration. If any single one of these times out through a proxy, that specific feature breaks while device join itself can still look healthy.
• KerbSpn / KerbUrl - the Cloud Kerberos Trust ticket endpoint. This is the field that answers "is Cloud Kerberos Trust even in play here?" - it is populated whenever the tenant has cloud Kerberos configured (via Set-AzureADKerberosServer), independent of whether this specific device is currently using it. Pair it with OnPremTgt in the SSO State section below to see whether the exchange is actually succeeding.

Section 4 - User State: is there a Hello credential?

This is the WHfB heart of the output. Run in the user context, it tells you whether Hello is set up, how it can be reset, and which account is brokering sign-in:

• NgcSet - YES if a Windows Hello key is set for the logged-in user. This is the "is Hello provisioned?" answer.
• NgcKeyId - the key's ID. This is not just a label - it is literally the name of the subfolder under the NGC container on disk (see the registry/folder section below), so it is the fastest way to prove which on-disk folder belongs to this user.
• CanReset - DestructiveOnly, NonDestructiveOnly, DestructiveAndNonDestructive, or Unknown. This tells you exactly which PIN-reset experience the user gets - see Windows Hello PIN Reset Done Right for what each value actually changes for the user.
• WamDefaultSet / WamDefaultAuthority / WamDefaultId / WamDefaultGUID - the Web Account Manager's default broker account. WAM is the component that actually hands out the PRT to apps; if this block is missing or WamDefaultSet : NO, expect apps that rely on WAM for SSO (Office, Edge, Teams) to prompt for credentials even when AzureAdPrt below reads YES.

Section 5 - SSO State: the tokens that make SSO work

The single-sign-on block, also user-context. These are the fields you read when "cloud works, on-prem prompts" (or vice versa):

• AzureAdPrt - YES if a Primary Refresh Token is present. No PRT = no SSO, and nothing on-prem works either.
• AzureAdPrtUpdateTime / AzureAdPrtExpiryTime - a PRT that updates on every sign-in is healthy. A PRT with an old UpdateTime and an ExpiryTime approaching is a device that has stopped refreshing silently - look at TokenBroker (below) and network reachability to AzureAdPrtAuthority before assuming a policy problem.
• OnPremTgt / CloudTgt - cloud Kerberos tickets for on-prem and cloud resources respectively. On a Cloud Kerberos Trust device, OnPremTgt : YES is your proof that the partial-to-full TGT exchange succeeded - and it depends entirely on the KerbSpn/KerbUrl endpoints from Tenant Details above being reachable, not on any per-user AD object (that per-user dependency is a Key Trust thing - see the msDS-KeyCredentialLink deep dive).
• KerbTopLevelNames - the set of Kerberos realm suffixes the device treats as belonging to its own cloud Kerberos trust. Useful when diagnosing why a specific resource isn't getting a cloud Kerberos ticket - if its realm isn't in this list, it never will.
• When a PRT acquisition fails, an AcquirePrtDiagnostics : PRESENT block appears with the Attempt Status (an HRESULT), Credential Type (Password or NGC), and the exact Server Error Code - the real reason, in plain sight.

Section 6 - Diagnostic Data: the fields nobody reads

The last section before the (conditional) NGC Prerequisite Check, and the one most consistently skipped - but KeySignTest alone is worth the scroll:

• KeySignTest - Windows actively signs test data with the device key and verifies it, right there in the command. PASSED means the TPM can genuinely sign with this key today. FAILED means every downstream Hello/device-auth field above can read YES while the actual cryptographic operation is broken - this is the one line that catches a TPM going bad before Hello itself starts failing.
• Executing Account Name - the on-prem SAM account plus UPN dsregcmd resolved for this session. A mismatch between the SAM domain here and the tenant in TenantName above is a fast way to spot a device or user object joined against the wrong forest/tenant.
• DisplayNameUpdated / OsVersionUpdated / HostNameUpdated - whether the device successfully wrote these attributes back to Entra ID on last sync. Managed by MDM means Intune owns the value and dsregcmd isn't the one updating it; a stale HostNameUpdated : NO after a rename explains a device search in the Entra portal that won't find the machine by its current name.

Section 7 - NGC Prerequisite Check: why Hello did (not) provision

This section only appears when Hello has not yet successfully provisioned - which makes it the single most useful block for "why isn't the user getting a PIN prompt?" Each line is a prerequisite, and the first NO is your answer:

The fields decode cleanly: IsDeviceJoined, IsUserAzureAD, PolicyEnabled, PostLogonEnabled (NO here means a custom mechanism, not the platform, triggers enrolment), DeviceEligible (fails when there is no usable TPM and you require one), SessionIsNotRemote (Hello does not provision inside an RDP session), and PreReqResult - WillProvision means Hello enrolment will fire as a post-login task at next sign-in.

Section 8 - Registry keys behind the numbers

Almost every field above is a live read of one of three registry locations. Knowing these turns dsregcmd from a black box into something you can cross-check directly:

• HKLM:\SYSTEM\CurrentControlSet\Control\CloudDomainJoin\JoinInfo\<Thumbprint> - one subkey per device certificate thumbprint (matches Thumbprint in Device Details above). This is the source for the entire Device Details and Tenant Details sections. UserEmail and DnsFullyQualifiedName here are what dsregcmd is really reading when it prints Executing Account Name and Device Name.
• HKLM:\SOFTWARE\Policies\Microsoft\PassportForWork (and the non-Policies mirror under HKLM:\SOFTWARE\Microsoft\Policies\PassportForWork) - the enforced WHfB policy. This is exactly what backs PolicyEnabled and PostLogonEnabled in the NGC Prerequisite Check: a real capture from this series shows RequireSecurityDevice:1, EnablePinRecovery:1, DisablePostLogonProvisioning:1 and UseCloudTrustForOnPremAuth:1 - that last value is the actual on/off switch for Cloud Kerberos Trust, and it is what makes KerbSpn/KerbUrl matter for this specific device.
• C:\Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\Ngc - the NGC container folder itself. On a real device it contains a PregenPool folder (Windows pre-generates a pool of backup key material here, ready to use) plus one folder per provisioned user, named after their NgcKeyId GUID from User State above. This is exactly why deleting the whole folder is destructive for every user - it removes every user's container folder and the shared pregen pool in one shot, where certutil -deletehellocontainer touches only the calling user's own subfolder.

Section 9 - Services and scheduled tasks in play

None of the above updates itself. A handful of services and two background scheduled tasks are what keep dsregcmd's numbers current:

Two scheduled tasks under Task Scheduler › Microsoft › Windows › Workplace Join do the periodic work: Automatic-Device-Join re-runs the join/re-registration check on a timer (this is what recovers a hybrid device after a missed sync, without a user ever running dsregcmd /join by hand), and Device-Sync keeps the on-prem and cloud device attributes aligned. A real capture from this series shows both Ready, and a third task, Recovery-Check, Disabled - that third one is normal to see disabled; it only activates once WHfB recovery (AadRecoveryEnabled in Diagnostic Data) is turned on for the tenant.

Section 10 - Correlating a field to the event log

Once a field above looks wrong, the event log tells you when it went wrong and why. The full catalog is in the WHfB Event ID catalog - here is the direct mapping from what you just read in dsregcmd to what to search for:

Here is a real run of Get-DsRegCmdReport.ps1 from this series, which parses dsregcmd /status into exactly the fields this reference covers and flags anything worth a second look:

Proof it worked: you diagnose from the output, not a guess

You are reading it correctly when a single run turns "Hello is broken" into a specific answer - "hybrid joined, NgcSet YES, AzureAdPrt YES, OnPremTgt NO" points straight at the on-prem ticket exchange (check Netlogon and the on-prem AD key object, or the KerbSpn/KerbUrl endpoints if this is Cloud Kerberos Trust), and the NGC Prerequisite Check names the first failing prerequisite for you. Section by section, top to bottom, the output diagnoses itself - and every field traces back to a registry key, a service, or an event log entry you can independently confirm.

References

• Troubleshoot devices by using the dsregcmd command (full field reference)
• What is a Primary Refresh Token
• How Windows Hello for Business works
• What is a device identity (join types)
• EndpointWeekly: The WHfB Event ID Catalog
• EndpointWeekly: Inside the NGC Container
• EndpointWeekly: Windows Hello PIN Reset Done Right
• EndpointWeekly: The msDS-KeyCredentialLink Deep Dive
• EndpointWeekly: Cloud Kerberos Trust Deployment Guide