Fix Windows LAPS Not Applying During Autopilot Pre-Provisioning Technician Flow

If you expect Windows LAPS to finish during Windows Autopilot pre-provisioning technician flow and the local admin password never appears in Intune or Microsoft Entra ID before handoff, stop treating it like a broken policy assignment first.

Microsoft documents this as a known issue: during Windows Autopilot pre-provisioning technician flow, a LAPS policy targeted to the device or user is not applied until the user phase begins. That matters because many enterprise teams now depend on LAPS as part of bench validation, break-glass recovery, and remote-hands workflows. If you are checking for a rotated local admin password before reseal or before the first user signs in, you can misclassify normal known-issue behavior as an Intune outage.

Quick Fix Checklist

Use this order before you rebuild the policy or wipe the device again:

1. Confirm the device is in Windows Autopilot pre-provisioning technician flow, not a normal user-driven sign-in.
2. Confirm the expected failure is specifically that LAPS did not apply yet or the password is missing from Intune or Microsoft Entra ID.
3. Check whether the device has actually reached the user phase. If not, do not expect final LAPS backup yet.
4. Review the local Windows LAPS event log for policy-processing evidence.
5. Confirm the LAPS policy itself is otherwise valid: correct backup directory, one effective policy, correct account target.
6. After the first user phase begins, force a sync and rerun LAPS policy processing.
7. Only escalate into policy-conflict or join-type troubleshooting if LAPS is still missing after user phase starts.

If you skip step three, you can spend an hour “fixing” a known platform limitation that has not actually cleared its expected processing point yet.

What Microsoft Says Is Broken

Microsoft’s current Windows Autopilot known issues page states:

During Windows Autopilot pre-provisioning technical flow, if a LAPS policy is targeted to the device or user, it isn't applied until the user phase begins.

That sentence is short, but it changes the whole troubleshooting tree.

It tells you:

• this is a Microsoft-known issue, not just a lab rumor
• device targeting does not save you here
• user targeting does not save you either
• the timing boundary is the start of user phase

So if your bench checklist says “verify LAPS password exists before reseal” or “confirm LAPS rotated before the user touches the laptop,” the checklist is wrong for affected pre-provisioning scenarios.

Why This Happens in Real Rollouts

Microsoft’s pre-provisioning documentation explains that technician flow is the device-side phase that happens before the user takes over. That flow is designed to get the device through the heavy lifting early, but not every policy lands on the timetable admins want.

LAPS is especially sensitive because admins expect three things to happen cleanly:

1. the local administrator account is identified or created
2. the password is rotated locally
3. the new password is backed up to the configured directory

When Microsoft says LAPS does not apply until the user phase begins, the practical meaning is simple: your pre-user validation window is too early for this control.

That is why the symptom often looks confusing:

• Autopilot pre-provisioning succeeds
• Intune policy assignment looks healthy
• the device reseals normally
• LAPS password data is still missing
• help desk assumes the LAPS policy is broken

In this branch, the policy may be fine. The timing is the problem.

Root Cause in Plain English

The root cause is not usually “the LAPS CSP failed forever.” The root cause is that Windows Autopilot pre-provisioning technician flow does not complete LAPS application until the user phase begins.

That means you need to separate two questions:

1. Did the platform defer LAPS because of the known issue?
2. Or is LAPS still broken after the user phase begins?

If you do not split those questions, you end up mixing a timing issue with true policy failures like:

• backup directory mismatch
• overlapping LAPS policies
• non-existent managed local account
• disabled or deleted device object
• unsupported directory target for the join type

Those are real failures. They just are not the first branch to chase when the device is still sitting in technician flow.

Logs and Where to Check First

1. Windows LAPS operational log

Microsoft’s Windows LAPS event-log documentation says the primary log is here:

Applications and Services Logs > Microsoft > Windows > LAPS > Operational

Start there before touching assignments.

Useful events from Microsoft’s documentation:

• 10003 — LAPS policy processing is starting
• 10004 — LAPS policy processing succeeded
• 10005 — LAPS policy processing failed
• 10021 — current LAPS policy is configured for Active Directory backup
• 10022 — current LAPS policy is configured for Microsoft Entra ID backup
• 10018 — LAPS successfully updated Active Directory with the new password
• 10029 — LAPS successfully updated Microsoft Entra ID with the new password
• 10020 — LAPS successfully updated the managed local account

Pull the log with PowerShell:

Get-WinEvent -LogName 'Microsoft-Windows-LAPS/Operational' -MaxEvents 100 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message |
  Format-List

If you do not see the success events that correspond to your backup target yet, and the device has not entered user phase, the known issue is still the leading explanation.

2. Check the active LAPS policy on the device

Microsoft’s Windows LAPS policy documentation says CSP-managed LAPS settings live under:

HKLM\Software\Microsoft\Policies\LAPS

Quick local check:

Get-ItemProperty -Path 'HKLM:\Software\Microsoft\Policies\LAPS' |
  Format-List *

This helps answer a narrower question: did the device receive a LAPS policy at all?

If the policy is present but the password is not yet backed up during technician flow, that again points toward timing rather than assignment failure.

3. Confirm the backup target makes sense

Microsoft’s Intune and Windows LAPS docs are clear on this:

• BackupDirectory = Microsoft Entra ID is for Entra-backed scenarios
• BackupDirectory = Active Directory is for on-premises AD-backed scenarios

If you are chasing this pre-provisioning issue on a device that also has the wrong backup directory, you can have two problems at once. Do not let the known issue hide a bad policy.

4. Capture Autopilot and MDM evidence before reset

Use a standard evidence bundle before you wipe a failing device:

mkdir C:\Temp -Force
Mdmdiagnosticstool.exe -area Autopilot;DeviceEnrollment -cab C:\Temp\autopilot-laps-techflow.cab
mdmdiagnosticstool.exe -out C:\Temp\MDMDiag

This gives you a before-and-after snapshot you can compare once the user phase begins.

The Microsoft-Supported Recovery Path

The correct recovery path is mostly about timing your validation later.

Step 1: Stop expecting final LAPS state during technician flow

If your current runbook requires a LAPS password to exist before reseal, update the runbook. Microsoft’s own wording says that expectation is unreliable in this scenario.

Step 2: Let the device enter user phase

Have the device continue into the first real user phase. That is the gate Microsoft names explicitly.

Step 3: Force policy processing after user phase begins

Once the device is in the user phase and fully online, use a sync plus local processing check.

If the Windows LAPS PowerShell module is available, Microsoft documents this cmdlet:

Invoke-LapsPolicyProcessing

Then recheck the LAPS event log for 10018 or 10029 and 10020.

Step 4: Verify the password backup in the right control plane

For Microsoft Entra-backed devices, Microsoft’s Windows LAPS guidance shows that you can verify backup with the Windows LAPS cmdlet after connecting to Microsoft Graph:

Connect-MgGraph -Environment Global -TenantId '<tenant-id>' -ClientId '<app-id>'
Get-LapsAADPassword -DeviceIds '<device-name>'

If the password appears only after user phase begins, that is fully consistent with the known issue.

Step 5: Only branch into deeper troubleshooting if LAPS is still absent

If the user phase has started and you still do not see success events or password backup, then move into the real failure branches:

• multiple overlapping LAPS policies
• wrong backup directory for the join type
• invalid managed account name
• device disabled or deleted in Microsoft Entra ID
• older OS or unsupported feature mix

That is the right time to treat it as a LAPS configuration problem.

A Practical Remediation Workflow

If I had to clear this during a rollout window, I would use this order:

1. Verify that the incident is actually pre-user

Check whether the complaint was raised before the first user phase even began. If yes, downgrade the urgency until you validate after the proper boundary.

2. Prove whether the policy reached the device

Use the LAPS registry path and 10021/10022 events to confirm the device knows what LAPS policy it is supposed to use.

3. Wait for or trigger the user phase

Do not rebuild policy while the device is still trapped inside the exact timing window Microsoft says is affected.

4. Recheck for success events

After user phase begins, look specifically for:

• 10020 local managed-account update
• 10018 Active Directory password backup
• 10029 Microsoft Entra ID password backup

Those events matter more than a vague “policy applied” status in the portal.

5. Escalate only on post-user evidence

If the device reaches user phase and still logs 10005 or never logs the backup success event, then you have a normal LAPS incident worth deeper repair.

PowerShell Commands Worth Keeping in the Runbook

Review Windows LAPS events

Get-WinEvent -LogName 'Microsoft-Windows-LAPS/Operational' -MaxEvents 100 |
  Sort-Object TimeCreated |
  Select-Object TimeCreated, Id, Message

Review LAPS policy state from the registry

Get-ItemProperty -Path 'HKLM:\Software\Microsoft\Policies\LAPS' |
  Format-List *

Force local LAPS processing after user phase begins

Invoke-LapsPolicyProcessing

Query Microsoft Entra-backed LAPS metadata

Connect-MgGraph -Environment Global -TenantId '<tenant-id>' -ClientId '<app-id>'
Get-LapsAADPassword -DeviceIds '<device-name>'

Caveats and Limitations

A few limits matter here.

First, this known issue does not mean every missing LAPS password during Autopilot is harmless. It means the technician-flow timing branch must be ruled out first.

Second, the known issue can coexist with real LAPS mistakes. A bad backup directory or conflicting policy will still fail after user phase begins.

Third, if your break-glass process depends on a LAPS password existing before a device leaves the bench, this platform behavior is an operational risk even when nothing is technically misconfigured.

Prevention

To keep this from turning into repeat tickets:

1. Remove any bench checklist step that requires LAPS proof before user phase on pre-provisioned devices.
2. Add Windows LAPS event IDs 10020, 10018, and 10029 to your post-enrollment validation checklist.
3. Standardize one LAPS policy per device and verify the correct backup directory ahead of rollout.
4. Keep a post-user validation step for shared troubleshooting or handoff devices where local-admin recovery matters.
5. Capture Autopilot and LAPS logs before reset so you can separate timing problems from real CSP failures.

Bottom Line

When Windows LAPS does not appear to apply during Windows Autopilot pre-provisioning technician flow, the first question is not “Which Intune admin broke policy?”

The first question is whether the device has even reached the user phase that Microsoft says LAPS waits for.

Check the Windows LAPS log, confirm the device’s active policy, let the device cross into user phase, and then look for 10020 plus 10018 or 10029. That sequence turns a vague pre-provisioning scare into a clean, evidence-based decision about whether you are looking at a Microsoft timing limitation or a real LAPS outage.