← all posts 2026-04-25 // laps · entra 12 min read

When LAPS silently refuses to escrow on hybrid Entra devices.

Five PCs in a hybrid Intune tenant. All enrolled, all compliant, LAPS policy applied. Not one of them escrowing. No alerts. No errors in any portal. The diagnostic signal is one Graph beta endpoint field that the Entra UI does not show, and it stays empty until you run the right two commands on the device itself. Then you wait 15 hours and do nothing. Here is the full chain.

why this matters

Hybrid Entra registration is a two-stage process. Most engineers only ever see Stage 1.

Stage 1: Entra Connect does its thing on the server. Entra Connect (the on-prem sync agent) reads the AD computer object and creates a matching device record in Entra. The device appears in the portal with TrustType: ServerAd. Tick.

Stage 2: the device proves it owns that record. A Windows scheduled task called Automatic-Device-Join runs on the device. It authenticates to Entra, exchanges cryptographic keys, and writes two fields on the Entra object: registrationDateTime and alternativeSecurityIds. Without those, the device cannot prove its identity to Entra.

When Stage 2 fails, Stage 1 still looks healthy. The portal shows the device. The AD computer object has its userCertificate. Intune happily enrols it through MDM auto-enrolment. The device is "joined" by every visible measure. But it cannot authenticate as itself to Entra. Windows LAPS cannot escrow without that authentication.

Because the symptom is silence rather than an error, you only notice when someone asks why the recovery portal has no entry for that machine.

what the broken state actually looks like

On the device, dsregcmd /status tells you the truth in three lines:

// output (dsregcmd /status excerpt)
  AzureAdJoined    : YES
  DomainJoined     : YES
  DeviceAuthStatus : FAILED. Device is either disabled or deleted
  KeySignTest      : PASSED

What this means line by line:

  • AzureAdJoined: YES. The device thinks it is joined.
  • DomainJoined: YES. The on-prem AD side is fine.
  • DeviceAuthStatus: FAILED. When the device tried to authenticate to Entra, Entra rejected it. This is the smoking gun.
  • KeySignTest: PASSED. The local cryptographic keys exist and are valid. The device is not the problem; Entra is rejecting it.

Look in the LAPS event log for the matching rejection message. It usually reads:

// output (LAPS event log excerpt)
  Server ErrorSubCode : error_missing_device
  Https Status        : 400
  Server Message      : The device object by the given id is not found.

What this means in plain English: the device id does exist in Entra. The portal will happily show it. But the cryptographic keys the device is presenting do not match anything the directory accepts, because the matching alternativeSecurityIds field was never written during Stage 2 registration. As far as Entra is concerned, this device is a stranger.

the diagnostic signal

There is exactly one field that confirms this state, and the Entra portal does not display it. You have to query Microsoft Graph beta:

// run this
$u = "https://graph.microsoft.com/beta/devices/$objectId" + `
     "?`$select=displayName,trustType,registrationDateTime," + `
     "alternativeSecurityIds,accountEnabled,createdDateTime"
Invoke-MgGraphRequest -Method GET -Uri $u
// output
  displayName            : CORP-PC-001
  trustType              : ServerAd
  createdDateTime        : 4/15/2026 10:29:34 AM
  registrationDateTime   : (empty)
  alternativeSecurityIds : (empty)
  accountEnabled         : True

Two empty fields. Object enabled, trust type correct, created recently, but never registered and no security identifiers. Compare against a healthy hybrid device: both fields populated, last sign-in recent. The shape is unmistakable once you have seen it twice.

before you touch anything

  • Confirm the device is on a supported Windows 11 build. 23H2 (10.0.22631) at minimum. 24H2 (10.0.26100) for full Automatic Account Management. Pre-production builds are not LAPS-eligible.
  • Confirm the AD computer object is healthy. Right OU, userCertificate populated, member of the MDM enrolment GPO security group. If it is in CN=Computers, AADC may not be syncing it at all.
  • Confirm AADC delta sync is running. If Entra Connect is paused or in staging mode, none of this works regardless.
  • Have local admin on the affected device, ideally during a maintenance window. The procedure requires two restarts.

step 1 · find the broken devices via Graph

Pull all Entra devices with pagination, then for each device-in-scope check registrationDateTime and alternativeSecurityIds. The beta endpoint surfaces both. The v1.0 endpoint does not surface alternativeSecurityIds at all.

// run this
$all = @()
$u = "https://graph.microsoft.com/v1.0/devices"
do {
    $r = Invoke-MgGraphRequest -Method GET -Uri $u
    $all += $r.value
    $u = $r.'@odata.nextLink'
} while ($u)
$all.Count
// output
  2676

Then for each device name on the broken list, get the detail and inspect:

// run this
$targets = @("CORP-PC-001","CORP-PC-002","CORP-PC-003","CORP-PC-004","CORP-PC-005")
$matching = $all | Where-Object { $_['displayName'] -in $targets }
foreach ($d in $matching) { Get-EntraDeviceDetail -ObjectId $d['id'] }
// output
  Name         TrustType  Registered    HasAltSec  Enabled
  ----         ---------  ----------    ---------  -------
  CORP-PC-001  ServerAd   NO-PENDING    NO         True
  CORP-PC-002  ServerAd   NO-PENDING    NO         True
  CORP-PC-003  ServerAd   NO-PENDING    NO         True
  CORP-PC-004  ServerAd   NO-PENDING    NO         True
  CORP-PC-005  ServerAd   NO-PENDING    NO         True

Five devices, identical signature. The remediation is the same for all of them.

Watch out for $matches. If you ever see $matching.Count return 35 when you know there are 5 devices, you used $matches as the variable name. $matches is a reserved PowerShell automatic populated by the -match operator. Use anything else.

step 2 · the two-restart fix on the device

The fix is to wipe the local registration state and force the Automatic-Device-Join task to start from scratch.

dsregcmd /leave tells Windows to forget that it is hybrid joined. It clears the local registration cache. Then a restart, and a fresh sign-in. Then dsregcmd /join tells Windows to register again from a clean state. Then one more restart to let the background process settle.

The user can keep working through the second restart; they do not need to be signed out beyond the leave step. Two restarts feels excessive but each one matters: the first ends the session that was using the broken state, the second lets the background Automatic-Device-Join task start fresh.

// run this (as local administrator)
dsregcmd /leave
// output
  Successfully left.

Restart the device. Sign in normally. Then run:

// run this (as local administrator)
dsregcmd /join
// output
  Computer is pre-joined to Azure AD.
  Join completed: 0x00000000

Restart the device one more time. Done.

step 3 · do nothing for 15 to 24 hours

This is the bit that catches people out. After the second restart, dsregcmd /status will show AzureAdJoined: NO. The error log will show error_missing_device from the foreground attempt. You will be tempted to re-run the procedure. Do not.

The Automatic-Device-Join scheduled task retries in the background on its own schedule. In the engagement this fix was validated against, every device completed registration within roughly 15 hours of the second restart. Re-running dsregcmd /leave + /join resets that retry clock and delays recovery.

// run this (immediately after /join + restart, on the device)
dsregcmd /status
// output (this is normal, walk away)
  AzureAdJoined : NO
Do not re-run the procedure. Every time you re-run leave plus join, the retry counter resets. The device gets stuck in a permanent not-quite-joined state because background reconciliation never gets enough uninterrupted time to complete.

step 4 · verify the next morning

From the admin workstation, against Graph, check whether the device is now escrowing. The device name appearing in the escrow list with a recent lastBackupDateTime is the only proof you need.

// run this
$response = Invoke-MgGraphRequest -Method GET `
    -Uri "https://graph.microsoft.com/v1.0/directory/deviceLocalCredentials"
$response.value | Where-Object { $_['deviceName'] -eq 'CORP-PC-001' }
// output
  deviceName        : CORP-PC-001
  lastBackupDateTime: 4/22/2026 1:10:23 AM

Confirmed. The Entra portal will also now show the device as hybrid joined with a populated registrationDateTime. Same diagnostic query as step 1, but the two empty fields are now populated.

common gotchas

  • You re-ran the leave-join sequence because it "did not work". Already covered above, worth saying again here. Why it matters: every re-run resets the background retry clock. Fix: run the procedure once, then leave it alone. Verify 15 to 24 hours later. A fix that should take 15 hours ends up taking three days when you keep retrying.
  • Multiple Entra objects share the same display name. Usually an old Workplace (BYOD-style) or pure AzureAd (cloud-only) registration coexisting with the correct ServerAd (hybrid) one. Why it matters: the leave-join sequence will not help while stale objects exist; they keep blocking registration. Fix: identify duplicates first using a duplicate detection script, delete the stale ones in the Entra portal, then run the leave-join sequence.
  • Your "all devices" pull returns ~100 results. Why it happens: you forgot @odata.nextLink. Fix: follow the pagination link in a loop until it stops returning. Anything you build on a partial result is unreliable.
  • You trust the Entra portal more than it deserves. The portal shows the device object whether or not it is properly registered. Why it matters: the portal cannot tell you that the device cannot authenticate. Fix: check alternativeSecurityIds via the Graph beta endpoint as shown in Step 1. That is the only field that confirms registration is complete.
  • Connect-MgGraph prompts you for credentials twice. Why it happens: WAM (Web Account Manager) is enabled by default on PowerShell 5.1 and adds an extra prompt step. Fix: run Set-MgGraphOption -DisableLoginByWAM $true once, then Connect-MgGraph at session start with every scope you will need.

when not to use this fix

The leave-join procedure only fixes broken registration. Use a different approach if any of these apply:

  • Device has not synced with Intune in weeks. The device is offline or dormant, not broken. Fix: find out where the device is and power it on, or contact the user.
  • OS build is below Windows 10 KB5025221 (April 2023) or Windows 11 22H2. LAPS is not supported on those builds. Fix: upgrade the OS or rebuild the device.
  • Multiple Entra objects exist for the same device name. The leave-join sequence has nothing valid to register against. Fix: delete the stale objects first using a duplicate detection script, then run leave-join.
  • No devices in the tenant are escrowing at all. Tenant-level toggle problem. Fix: in the Entra portal, go to Devices > Device settings and turn on "Local administrator password solution (LAPS)". That is a one-click fix; no device-side work will help until that toggle is on.
Hybrid Entra is full of these "everything looks fine, nothing works" failure modes. The diagnostic toolset for this specific one is on GitHub, sanitized and ready to run. If you would rather hand the diagnostic and remediation to someone who has done it on a live tenant, book a 30-minute call and we can talk through the right approach for your environment.
← all posts // himanshu @ aroramsp