HomeNewsletterCommunityMVP FeedToolsArchiveBlogToday's NewsAboutServicesQuick Links Subscribe free
← Back to Blog
Windows Hello for Business WHfBdsregcmdPRTReferenceTroubleshootingEntra ID

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

IA
Imran Awan
31 July 2026

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 forty-plus fields with almost no explanation, and most admins read only the three lines they already recognise. This is the field-by-field reference - every section, what each line means, and which values are "good" - so you can read the whole picture instead of guessing at it.

Note: Run dsregcmd /status as the signed-in user, not elevated. Several of the most useful fields - NgcSet, AzureAdPrt, OnPremTgt - only populate in the user context. Run it from an elevated prompt and those read blank or wrong, which sends you chasing problems that are not there.

The problem: forty 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.

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

The command dumps Device State, Device Details, Tenant Details, User State, SSO State, Diagnostic Data and the NGC Prerequisite Check back to back, with no descriptions. Each section answers a different question, and the fields you need for Windows Hello for Business (WHfB) are scattered across three of them.

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:

AzureAdJoinedEnterpriseJoinedDomainJoined= Device state
YESNONOMicrosoft Entra joined
NONOYESDomain joined (on-prem only)
YESNOYESMicrosoft Entra hybrid joined
NOYESYESOn-premises DRS joined
Command Prompt — Device State
AzureAdJoined : YES EnterpriseJoined : NO DomainJoined : YES # AAD=YES + Domain=YES = hybrid joined DomainName : CONTOSO

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. The fields that matter for WHfB security:

Section 3 - 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 and how it can be reset:

Command Prompt — User State
NgcSet : YES # a Hello key exists for this user NgcKeyId : {aaaaaaaa-0b0b-...} # its key ID CanReset : DestructiveAndNonDestructive # non-destructive PIN reset is live WorkplaceJoined : NO WamDefaultSet : YES

Section 4 - 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):

Command Prompt — SSO State
AzureAdPrt : YES # cloud PRT present (SSO to M365/Entra apps) AzureAdPrtExpiryTime : 2026-08-14 ... # when it expires if not renewed EnterprisePrt : NO # PRT from on-prem AD FS (hybrid can have both) OnPremTgt : YES # cloud Kerberos ticket for ON-PREM resources CloudTgt : YES # cloud Kerberos ticket for CLOUD resources
Gotcha: Before Windows 11 version 23H2, the on-prem ticket field in the NGC Prerequisite Check section was named CloudTGT; from 23H2 it is OnPremTGT. If you are reading older runbooks or comparing across OS versions, that rename trips people up - they are the same thing.

Section 5 - 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:

Command Prompt — Ngc Prerequisite Check
IsDeviceJoined : YES IsUserAzureAD : YES PolicyEnabled : YES # is the WHfB policy on? PostLogonEnabled : YES # native post-login provisioning? DeviceEligible : YES # meets hardware (TPM) requirement? SessionIsNotRemote : YES # not an RDP session (Hello won't provision over RDP) PreReqResult : WillProvision

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.

Watch out: SessionIsNotRemote : NO is the answer to a very common false alarm. Hello will not provision inside a Remote Desktop session - so an admin testing WHfB over RDP will see it "fail" every time. Test provisioning at the physical console, not through RDP.
Tip: Read dsregcmd /status top to bottom in order: join type → device key/TPM → NgcSet → PRT/TGT → (if Hello is missing) the prerequisite check. Each section narrows the problem. The prerequisite check in particular is self-diagnosing - the first NO from the top is almost always the root cause, and it names itself.

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, and the NGC Prerequisite Check names the first failing prerequisite for you. Section by section, top to bottom, the output diagnoses itself.

References

PowerShell Scripts — dsregcmd Report

Script for this post is in Daily-Tasks.

Get-DsRegCmdReport.ps1 — read-only: parses dsregcmd /status into a structured object and highlights the join type, Hello, PRT and TGT fields with plain-English verdicts
View all scripts on GitHub
Share this post
LinkedIn X / Twitter Reddit Bluesky

More from EndpointWeekly

Windows Hello for Business
The Complete Windows Hello for Business Event ID Catalog (Across…
WHfB logs to three different places with cryptic IDs and no index. This catalog maps…
Windows Hello for Business
Windows Hello Signs In Fine but File Shares Prompt: Fixing…
The user signs in with their PIN and cloud apps work, but a file share throws a…
Windows Hello for Business
Key Trust vs Certificate Trust vs Cloud Kerberos Trust: Which…
Three trust models, and most admins cannot say for certain which one a given device is…