Automating Windows Hello for Business Enrollment with PowerShell and Intune

If you've deployed Windows Hello for Business at scale, you've almost certainly hit this scenario: a device is Azure AD joined, the user has a valid Primary Refresh Token, conditional access is enforcing passwordless — and yet Windows Hello is still not set up. The user gets a prompt they don't understand, calls the service desk, and the engineer walks them through five screens they'll forget by next week.

This post walks through the three-script solution I built to detect that gap and guide users through enrollment automatically — no service desk involved.

Why this happens

The Windows Hello provisioning flow requires the device to be registered, the user to have an active PRT, and a specific UI sequence to be completed in Settings. None of those steps are difficult individually, but the combination creates a silent failure state that standard Intune compliance policies don't surface cleanly. You can have AzureAdJoined = YES and AzureAdPrt = YES sitting alongside NgcSet = NO — and nothing in the console will flag it as a problem.

The solution: three scripts, one clean flow

The automation is built around three PowerShell scripts that work together as an Intune detection/remediation pair with a persistent scheduled task:

• Detect-WHFBEnrollment.ps1 — runs as the Intune detection script, checks NgcSet and PRT status, returns exit code 0 (compliant) or 1 (needs remediation)
• Invoke-WHFBEnrollmentCheck.ps1 — the main user-facing script that parses device state, prompts the user when appropriate, and launches the correct Settings page directly
• Register-WHFBScheduledTask.ps1 — registers a per-user scheduled task that fires at logon with a 60-second delay, running the enrollment check persistently until Hello is provisioned

Detection logic

The detection script runs dsregcmd /status and parses four key values from the output into a hashtable: AzureAdJoined, WorkplaceJoined, AzureAdPrt, and NgcSet. The logic is deliberately simple:

if ($ngcSet)  { exit 0 }   # Already enrolled — compliant
elseif ($prt) { exit 1 }   # PRT present, Hello missing — remediate
else          { exit 1 }   # No PRT — device not ready

Exit code 0 tells Intune the device is compliant. Exit code 1 triggers the remediation script. This keeps the Intune compliance picture accurate without any custom inventory or external tooling.

Why user context matters

Both the PRT and the NgcSet values are per-user — they don't exist at SYSTEM level. Running these scripts in SYSTEM context (the Intune default for many script deployments) will always return empty values and break the detection logic. The scheduled task runs explicitly in user context to get accurate results, with a 60-second startup delay to allow the PRT to refresh after logon.

The user experience

When the script detects a missing Windows Hello enrollment on a ready device, it shows the user a clear, friendly prompt explaining what needs to happen and why. It then launches ms-settings:signinoptions directly to the PIN setup area — no navigating through Settings manually.

Exit codes at a glance

Deployment steps

1. Upload Detect-WHFBEnrollment.ps1 as an Intune detection script
2. Deploy Invoke-WHFBEnrollmentCheck.ps1 as the remediation script
3. Run Register-WHFBScheduledTask.ps1 once as admin to register the logon task
4. Ensure all scripts execute in user context — not SYSTEM
5. Pilot with your IT team before rolling out to the broader Windows 11 estate

Get the scripts

All three scripts are available on GitHub. Clone the repo, review the comments, and adapt the prompts to match your company branding before deploying.

🔗 View on GitHub — Imran76Awan/WHFB

Tip: Test on a device where you can manually reset NgcSet by removing the NGC folder at C:\Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\Ngc — this lets you validate the full detection and remediation flow without needing a freshly enrolled machine.