A
step-by-step technical blog explaining what the scripts do, why they are
effective, and how the user enrollment flow looks in practice.
Audience: Endpoint administrators, Intune
engineers, service desk leads, and project teams supporting Windows 11
migration or Windows Hello for Business adoption.
Executive summary
The
solution automates one of the most common Windows Hello for Business adoption
problems: users are eligible to enroll, but they
have not completed PIN setup yet. The scripts check the device registration
state, confirm that the user has a valid Azure AD Primary Refresh Token,
identify whether Windows Hello for Business is already configured, and then
guide the user directly to the correct Windows Settings page to complete
enrollment.
|
File |
Purpose |
|
Detect-WHFBEnrollment.ps1 |
A lightweight Intune detection script. It returns compliant when
NgcSet is YES and non-compliant when WHfB is missing. |
|
Invoke-WHFBEnrollmentCheck.ps1 |
The main user-facing script. It reads dsregcmd /status, logs the
result, prompts the user, opens Windows Sign-in options, expands PIN (Windows
Hello), and tries to click Set up automatically. |
|
Register-WHFBScheduledTask.ps1 |
Registers a per-user scheduled task that runs at logon with a
60-second delay so the PRT has time to refresh before the check runs. |
The problem this solves
During Windows 11 migration or modern
authentication rollout, a device can be Azure AD joined, a user can be signed
in, and the user can have a valid PRT, but Windows Hello for Business may still
not be provisioned. In dsregcmd output, that usually appears as AzureAdPrt =
YES and NgcSet = NO.
For an administrator, that state means the
user is ready for enrollment, but needs a clean prompt and a guided path.
Without automation, the service desk normally has to explain where to go in
Settings, which button to click, and how to complete the MFA flow. This script
removes most of that manual guidance.
High-level workflow
1.
Run dsregcmd /status in the
logged-on user context.
2.
Parse key values:
AzureAdJoined, WorkplaceJoined, AzureAdPrt, and NgcSet.
3.
Exit successfully when NgcSet
is YES because WHfB is already enrolled.
4.
Exit with a warning code when
the device is not joined or the user does not have a PRT yet.
5.
When AzureAdPrt is YES and
NgcSet is NO, show the user an enrollment prompt.
6.
Open ms-settings:signinoptions
and locate the PIN (Windows Hello) area.
7.
Use UI Automation first, then
fall back to a real Win32 mouse click because Windows 11 Settings is built on
modern WinUI controls.
8.
Launch the Set up flow and
guide the user through Okta FastPass and PIN creation.
Step-by-step: what the main script is doing
1. Starts with safe execution settings
The script uses PowerShell 5.1, sets
ErrorActionPreference to Stop, and enables strict mode. This is good
engineering practice because failed commands become visible quickly instead of
silently continuing.
2. Writes a local log
Write-Log creates timestamped entries in
the configured log path. This is helpful for troubleshooting user devices
because admins can see exactly which state was detected and which action the
script attempted.
3. Reads dsregcmd /status
Get-DsRegStatus executes dsregcmd /status
and parses lines in the format Key : Value into a PowerShell ordered hashtable.
This gives the script a simple way to check Azure AD join state, PRT state, and
WHfB provisioning state.
4. Confirms device registration
The script checks AzureAdJoined or
WorkplaceJoined before continuing. That prevents it from trying to start WHfB
enrollment on a device that is not in the right identity state.
5. Confirms the user has a PRT
AzureAdPrt = YES means the user has a valid
Azure AD Primary Refresh Token. The script correctly treats this as a gate
before launching enrollment because WHfB enrollment depends on the user being
properly authenticated.
6. Checks whether WHfB is already enrolled
NgcSet = YES means Windows Hello for
Business is provisioned. In that case, the script exits with code 0 and does
not bother the user.
7. Prompts only when action is needed
When PRT is present but NgcSet is NO, the
script displays a friendly enrollment prompt. This is the right balance: the
user is only interrupted when the device is ready and enrollment is actually
missing.
8. Opens the correct Settings page
The script launches
ms-settings:signinoptions, which takes the user directly to Accounts >
Sign-in options instead of requiring manual navigation through Windows
Settings.
9. Automates the PIN setup area
The script searches for PIN (Windows
Hello), attempts ExpandCollapsePattern or InvokePattern, and then uses a Win32
mouse-click fallback. This is important because Windows 11 Settings controls do
not always expose traditional automation patterns reliably.
10. Provides fallback instructions
If full automation is not possible, the
script does not fail silently. It shows clear manual steps so the user can
still complete enrollment.
User experience screenshots
The following screenshots were extracted
from the provided video and show the user journey from detection through final
PIN creation.
Screenshot 1: The script detects that WHfB is missing
and prompts the user to enroll.
Screenshot 2: The enrollment flow starts and hands the
user into the identity verification process.
Screenshot 3: Okta FastPass verification is triggered
as part of the Windows Hello enrollment journey.
Screenshot 4: Windows confirms the user is ready to
configure Windows Hello.
Screenshot 5: Windows validates that the user is
intentionally adding a Windows Hello PIN.
Screenshot 6: Identity verification completes and the
account is ready for PIN creation.
Screenshot 7: The user creates and confirms the
Windows Hello PIN.
Screenshot 8: Sign-in options now show that the PIN
has been successfully created.
How the Intune detection script works
Detect-WHFBEnrollment.ps1 is intentionally
simple. It checks two values from dsregcmd /status:
·
NgcSet: confirms whether
Windows Hello for Business is already configured.
·
AzureAdPrt: confirms whether
the user has a valid cloud authentication token.
if
($ngcSet) { exit 0 } elseif ($prt) { exit 1 } else { exit 1 }
This makes the script suitable for Intune
Proactive Remediations. A compliant device exits 0. A device that still needs
enrollment exits 1 so remediation can run.
Why the scheduled task is useful
Register-WHFBScheduledTask.ps1 creates a
scheduled task that runs at user logon, delayed by 60 seconds. That delay is a
strong design choice because the PRT can take a short period to become
available after sign-in. Running too early can create false negatives.
The task runs as the interactive user
rather than SYSTEM. That matters because dsregcmd /status returns user-context
information for PRT and WHfB status. Running this check as SYSTEM would not
reliably represent the signed-in user state.
Once NgcSet becomes YES, the scheduled task
may still launch at logon, but the main script exits cleanly without prompting.
From the user perspective, the reminders stop after enrollment is complete.
Why this is a great script
·
User-context aware: It understands that
WHfB enrollment is a user-state problem, not just a device-state problem.
·
Low service desk overhead: It sends
users directly to the correct setup screen and reduces manual instructions.
·
Intune friendly: It supports silent mode
and exit codes that work well with detection/remediation logic.
·
Resilient Windows 11 automation: It
handles the reality that WinUI Settings controls may not support normal
automation patterns and includes a mouse-click fallback.
·
Safe prompting model: It only prompts
when the user is ready to enroll: registered device, PRT present, and NgcSet
missing.
·
Good operational logging: The log makes
it easier to troubleshoot without asking the user to repeat the full enrollment
attempt.
·
Strong adoption pattern: The scheduled
task design keeps reminding users at logon until enrollment is complete without
requiring repeated admin intervention.
Recommended deployment approach
9.
Upload
Detect-WHFBEnrollment.ps1 as the Intune detection script.
10.
Use
Invoke-WHFBEnrollmentCheck.ps1 as the remediation or user-facing script.
11.
Deploy
Register-WHFBScheduledTask.ps1 once as admin if you want the enrollment check
to continue at every user logon.
12.
Confirm the main script runs in
the logged-on user context when the goal is to read PRT and WHfB user state.
13.
Pilot first with IT users, then
expand to a controlled Windows 11 migration group before broad deployment.
Main script exit code behavior
|
Exit code |
Meaning |
Admin action |
|
0 |
WHfB enrolled, or the user accepted enrollment and the setup flow
was launched. |
No immediate action required. |
|
1 |
Enrollment is required, or the user deferred enrollment. |
Prompt again later through remediation or scheduled task. |
|
2 |
Device is not Azure AD joined or workplace registered. |
Check join/registration state before WHfB enrollment. |
|
3 |
No valid Azure AD PRT was found. |
Confirm user sign-in, network, Entra ID join, and token refresh
state. |
Optional improvements before production rollout
·
Add company branding to the
prompt text and title so users recognize it as a trusted internal enrollment
workflow.
·
Write logs to a standard
enterprise path such as ProgramData when running under remediation, while
keeping user-context logs for interactive troubleshooting.
·
Add a maximum reminder count or
grace period if your organization wants a softer rollout.
·
Send remediation results to Log
Analytics or a central reporting location for adoption tracking.
·
Test across Windows 11 builds
because the Settings UI can change, and UI Automation selectors may need small
adjustments over time.
Final takeaway
This solution is strong because it combines
proper identity-state detection with a user-friendly enrollment experience. It
does not blindly force Windows Hello setup. It first confirms that the user and
device are in the right state, then opens the correct Windows 11 page, starts
the setup flow where possible, and gives clear fallback instructions when UI
automation cannot complete every click. For Windows 11 migration projects, this
is exactly the type of automation that improves compliance while reducing service
desk tickets.
Review and test the scripts in a pilot
group before using them in production.
https://github.com/Imran76Awan/WHFB
The PowerShell scripts used in this
walkthrough are available on GitHub:
View the scripts on GitHub
0 Comments