Why we went with cloud trust

There's no PKI involved. You don't have DC certificates to issue and renew for Hello, and you don't have to worry about CRL availability.

There's also no key sync delay. With key trust, a new user's public key had to sync to AD before on-premises SSO worked, so the instructions for new staff were basically "set up Hello, then wait up to an hour." With cloud trust it works right after provisioning.

And if you plan to use FIDO2 security keys for hybrid sign-in, the same Entra Kerberos object supports that too.

Create the Entra Kerberos server object

This creates a read-only domain controller-style computer object (AzureADKerberos) in your domain and publishes its key to Entra ID, so your DCs can trust the tickets Entra issues. Run it from an elevated PowerShell session on a domain-joined machine that can reach a writable DC.

# TLS 1.2 for the PowerShell Gallery on older systems
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

$domain = $env:USERDNSDOMAIN            # e.g. CONTOSO.LOCAL
$upn    = "admin@contoso.com"            # Entra Global Admin or Hybrid Identity Admin
$domainCred = Get-Credential             # Domain Admin in the on-prem domain

Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $upn -DomainCredential $domainCred

# Confirm it exists and the key versions match
Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $upn -DomainCredential $domainCred

If your admin account requires MFA, the module supports an interactive sign-in instead of passing the UPN. Check the module's help for the current parameters. In AD you should now see an AzureADKerberos computer object in the Domain Controllers OU and a krbtgt_AzureAD user. Don't delete or move either one. Repeat this for each domain in the forest where users sign in.

The WHfB policy in Intune

Create a Settings catalog profile for Windows and search for Windows Hello for Business. At a minimum, set Use Windows Hello For Business to Enabled (with your PIN complexity and biometric preferences) and Use Cloud Trust For On Prem Auth to Enabled.

Under the hood, the cloud trust setting is this CSP.

./Device/Vendor/MSFT/PassportForWork/<TenantID>/Policies/UseCloudTrustForOnPremAuth = true

Assign it to a pilot device group. If you already have a tenant-wide WHfB configuration under Windows enrollment settings, make sure the two don't conflict. The settings catalog profile is the one we rely on. Without Intune, the equivalent Group Policy setting is "Use cloud Kerberos trust for on-premises authentication" under the Windows Hello for Business administrative templates.

Try it with one user

Sync policy on the pilot device and have the user sign out and back in. After MFA, they should be prompted to set up Windows Hello. Then lock the machine and sign in with the PIN.

dsregcmd /status
klist cloud_debug
klist

One last thing that's easy to forget once everything works. Rotate the Entra Kerberos server key periodically with Set-AzureADKerberosServer -RotateServerKey (using the same domain and credential parameters), and put it on your maintenance calendar so it doesn't depend on somebody remembering.

How the two scripts work together

The detection script runs first. exit 0 means everything's fine and there's nothing to do. exit 1 means it found an issue, and Intune runs the remediation script.

The remediation script does the fix. After it runs, the detection script runs again so Intune can report whether the fix held.

Whatever the scripts write to STDOUT shows up as the detection and remediation output in the portal, and the last line is what you see in reports. Make that line useful to whoever reads the report later, because "ok" doesn't tell them much.

The detection script

This example makes sure the Windows Time service is set to automatic and running.

# Detect-W32Time.ps1
try {
    $svc = Get-Service -Name W32Time -ErrorAction Stop
    if ($svc.StartType -ne 'Automatic' -or $svc.Status -ne 'Running') {
        Write-Output "Issue: W32Time StartType=$($svc.StartType) Status=$($svc.Status)"
        exit 1
    }
    Write-Output "OK: W32Time running"
    exit 0
}
catch {
    Write-Output "Issue: $($_.Exception.Message)"
    exit 1
}

The remediation script

# Remediate-W32Time.ps1
try {
    Set-Service -Name W32Time -StartupType Automatic -ErrorAction Stop
    Start-Service -Name W32Time -ErrorAction Stop
    w32tm /resync /force | Out-Null
    Write-Output "Remediated: W32Time set to Automatic and started"
    exit 0
}
catch {
    Write-Output "Remediation failed: $($_.Exception.Message)"
    exit 1
}

Keep both scripts idempotent, so running the fix twice does no harm. Save them as UTF-8, and keep them small and dependency-free. There's no guarantee any module you rely on exists on the client.

Creating the package

In the Intune admin center, go to Devices, then Scripts and remediations, then Remediations, and create a script package. Upload both scripts and pick the settings.

• "Run this script using the logged-on credentials" should be No (so it runs as SYSTEM) for machine settings like services. Only use Yes for per-user fixes.
• Only turn on "Enforce script signature check" if you sign your scripts.
• Set "Run script in 64-bit PowerShell" to Yes for most things, so you see the real registry and System32.

Assigning and scheduling

Assign it to a pilot group first and choose a schedule of once, hourly or daily (with a time). Daily is a sensible default for drift. Hourly is for things that genuinely need it, since every run is another process on every device. You can also run it on a single device on demand from that device's page with the "Run remediation" action, which is handy for testing.

Here's what we do now.

1. After any create or assign through Graph, open the package in the portal and read back the assignment. Make sure the remediation script is enabled to run, not just detection.
2. If it isn't, fix it in the portal (or re-check your Graph payload against the current API documentation) and read it back again.
3. Before calling the rollout done, wait until at least one device shows "Issues fixed" in the report. If all you ever see is "With issues," the remediation side isn't running.

Other ways these go sideways

• If detection exits 0 when there's a problem, for example because an error got swallowed, the remediation never runs. Always exit 1 in the catch block.
• The post-remediation detection runs right away. If your fix only takes effect after a reboot or a service restart, detection reports "failed" even though it worked. Account for that in the logic or the output.
• Keep scripts and output short. Long output gets truncated in the report.
• Scripts set to run as the logged-on user fail when nobody is logged on, and they can't change machine settings.

I've stopped trusting any automated assignment until I've seen "Issues fixed" in the report myself. It costs a day of waiting, which beats finding out weeks later.

Start with a clean source folder

Put only what the install needs into one folder, like the installer, any transforms or config files, and an optional wrapper script. Everything in that folder ends up in the package, so don't point the tool at your Downloads folder.

C:\Packaging\AcmeApp\Source\
    AcmeApp-5.2.msi
    settings.xml
    Install.ps1
C:\Packaging\AcmeApp\Output\

Test the silent install as SYSTEM

This is the step I'd never skip. Intune installs Win32 apps in SYSTEM context by default, and an installer that works fine when you double-click it can behave completely differently as SYSTEM. There's no user profile, no mapped drives and no HKCU. So test it the way Intune will run it.

# Opens a PowerShell window running as SYSTEM (run from an elevated prompt)
psexec.exe -s -i powershell.exe

# In the SYSTEM window, confirm who you are, then run your exact install line
whoami
msiexec /i "C:\Packaging\AcmeApp\Source\AcmeApp-5.2.msi" /qn /norestart /l*v C:\Windows\Temp\AcmeApp-install.log
$LASTEXITCODE

Write down the exit code, then test the uninstall line the same way. If either one needs anybody to click anything, it'll hang in Intune until the timeout.

Build the .intunewin

.\IntuneWinAppUtil.exe -c "C:\Packaging\AcmeApp\Source" -s "AcmeApp-5.2.msi" -o "C:\Packaging\AcmeApp\Output" -q

-c is the source folder, -s is the setup file (relative to the source folder), -o is the output folder, and -q is quiet mode. When the setup file is an MSI, the tool reads its metadata and Intune can prefill the product code for detection.

Creating the app in Intune

In the Intune admin center, add a Windows app of type "Windows app (Win32)," upload the .intunewin, and fill in the commands and behavior.

• Install command: msiexec /i "AcmeApp-5.2.msi" /qn /norestart, or for a wrapper, powershell.exe -ExecutionPolicy Bypass -File .\Install.ps1.
• Uninstall command: for an MSI, msiexec /x {PRODUCT-CODE-GUID} /qn.
• Install behavior: System or User. Use System unless the app installs per user into the profile.
• Device restart behavior: usually "Determine behavior based on return codes."

The default return codes are 0 (success), 1707 (success), 3010 (soft reboot), 1641 (hard reboot) and 1618 (retry, another install in progress). Add any vendor-specific success codes your installer uses. If you don't, a perfectly good install gets reported as failed, and somebody burns an afternoon chasing it.

Requirement rules decide who gets it

Requirements decide whether the app even applies to a device. You can check OS architecture, minimum Windows version, disk space and RAM, and optionally add a file, registry or script check. If a requirement isn't met, the device reports "Not applicable" instead of failing. We use a script or file requirement to limit apps to a subset of devices, for example only machines with a marker file dropped by a department provisioning step.

Detection rules, where most of the trouble lives

Detection is how Intune decides whether the app is installed, right after the install runs and on every check after that. You've got four options.

• The MSI product code is the most reliable for MSIs, and you can check the version too.
• A file or folder rule checks that something exists, or compares the version or date on a specific file, for example C:\Program Files\Acme\acme.exe with version greater than or equal to 5.2.
• A registry rule checks that a key or value exists or matches, like the app's entry under the Uninstall key. Pay attention to the "associated with a 32-bit app on 64-bit clients" option, which controls whether Intune looks in the WOW6432Node view.
• A custom PowerShell script decides for itself. I reach for it when the other options can't express the condition.

# Detection script: detected = exit 0 AND something written to STDOUT
$exe = "C:\Program Files\Acme\acme.exe"
if (Test-Path $exe) {
    $ver = [version](Get-Item $exe).VersionInfo.FileVersion
    if ($ver -ge [version]"5.2.0") {
        Write-Output "AcmeApp $ver detected"
        exit 0
    }
}
exit 1

Pilot it

Assign it as Required to a small device group, or as Available to a user group for Company Portal. Sync the test device and watch it.

When a deployment fails, I open AppWorkload.log before I change anything in the portal. It usually shows exactly what ran and what exit code came back.

Make sure hybrid join actually works

Auto-enrollment rides on hybrid join. If the device isn't hybrid-joined, nothing else here matters. On a test PC, signed in as a normal domain user, run this.

dsregcmd /status

Under Device State you want AzureAdJoined : YES and DomainJoined : YES. Under SSO State you want AzureAdPrt : YES. If AzureAdJoined says NO, check that the computer object is in a synced OU, that the service connection point (SCP) is configured, and that the device can reach the Microsoft device registration endpoints. Also look the device up in Entra ID. It should show as "Microsoft Entra hybrid joined" with a registered date, not "Pending."

MDM user scope and licensing

In the Entra or Intune admin center, find the mobility (MDM and WIP) settings for Microsoft Intune and set the MDM user scope to All, or to Some with a group containing the people who sign in to these PCs. Leave the MAM scope alone unless you know you need it. Confirm those users have an Intune license and that your Windows enrollment restrictions allow Windows (MDM) enrollment.

The GPO itself

Create a GPO linked to the OU that holds the computers. Start with a test OU. Then set this.

Computer Configuration
  > Policies
    > Administrative Templates
      > Windows Components
        > MDM
          > Enable automatic MDM enrollment using default Azure AD credentials
              = Enabled
              Select Credential Type to Use: User Credential

"User Credential" is the standard choice here. "Device Credential" exists for specific co-management and ConfigMgr scenarios, so don't pick it just because it sounds more convenient.

When the policy applies, Windows creates a scheduled task under \Microsoft\Windows\EnterpriseMgmt that tries to enroll on a recurring schedule. The next time a licensed, in-scope user signs in, the device enrolls.

Kick it and watch

gpupdate /force
# Confirm the policy landed
gpresult /r /scope computer
# Confirm the enrollment task exists
Get-ScheduledTask -TaskPath "\Microsoft\Windows\EnterpriseMgmt\*" | Select-Object TaskName, State

Sign out and back in as a normal user, give it a few minutes, and then check.

Get-WinEvent -LogName "Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin" -MaxEvents 50 |
  Where-Object { $_.Id -in 75,76 } |
  Format-Table TimeCreated, Id, Message -Wrap

What we did about it

Here are the options in the order I'd pick them.

1. Stop signing in to workstations with admin accounts. Give IT staff a normal daily account for their PC and keep privileged roles on separate accounts. The device then enrolls under the normal user, and your admin accounts keep their MFA requirement. This is the one I push for.
2. If you really have to, make a narrow exclusion. Adjust the CA policy so only the enrollment resource shown in the failed sign-in is excluded, and nothing broader. Don't exclude the admins from MFA entirely. Review the change with whoever owns your CA policies and test it with the What If tool.
3. Enroll the affected devices once with a non-admin user, then change the primary user later if you need to.

If you manage several tenants, check each one for a similar admin-MFA policy before you roll this out. I'd assume it's there until you've looked.

A few smaller ones

• Users with a non-routable UPN like @contoso.local can't authenticate to Entra properly. The UPN has to match a verified domain.
• A device that's already MDM-enrolled somewhere else (another tenant or a previous MDM) will fail until you clean that up.
• A device reimaged with the same name can have a stale Entra object. Delete the stale object and let it re-register.
• Sync cycles, the scheduled task interval and policy refresh all add delay. On a big rollout, give it a day before you start chasing ghosts.