Fix Autopilot Pre-Provisioning Error 0x801C03F3 After the Entra Device Object Was Deleted

If Windows Autopilot pre-provisioning stops on an error screen and the Microsoft-Windows-User Device Registration/Admin log shows HResult error code 0x801C03F3, the problem is usually not TPM, Wi-Fi, or a random Intune delay. Microsoft’s current known-issues guidance ties this failure to a missing Microsoft Entra device object.

That makes this a high-value bench failure for Desktop Engineers and Intune admins. The device can be correctly imported into Autopilot, the technician can still start pre-provisioning, and the workflow still dies because the cloud object Autopilot expects before sign-in is gone.

The right response is not to keep retrying the same laptop. The right response is to verify whether the Entra device object was manually deleted, clean up the remaining records in the correct order, re-register the hardware, and only then rerun pre-provisioning.

Quick Fix checklist

Use this sequence before you wipe and retry again:

Confirm the visible failure happened during Windows Autopilot pre-provisioning.
Check Event Viewer > Applications and Services Logs > Microsoft > Windows > User Device Registration > Admin for 0x801C03F3.
Verify whether the matching Microsoft Entra device object is missing.
Check whether the device still exists in Intune managed devices and Windows Autopilot devices.
If the Entra object was manually deleted, remove the remaining stale records from Intune and Windows Autopilot.
Re-import or re-register the device in Windows Autopilot so the required Entra object is recreated.
Collect Mdmdiagnosticstool.exe output before the next test.
Retry on one pilot device before handing the process back to the bench team.

If you skip step 5 and only reset the machine, you usually just reproduce the same failure.

Root cause

Microsoft’s Windows Autopilot known-issues page is very direct on this one: 0x801C03F3 during pre-provisioning can happen when Microsoft Entra ID can’t find a Microsoft Entra device object for the device that is being deployed. Microsoft says this issue occurs when the object was manually deleted.

That detail matters because many admins delete cloud device records as a cleanup shortcut when they are trying to reuse a device, fix a stale deployment, or force a fresh Autopilot run. The registration overview now warns against doing that casually. Microsoft says the Windows Autopilot deployment process relies on the Microsoft Entra device object, and deleting it can cause enrollment failures.

In practice, the failure usually starts one of these ways:

a tech or admin manually deleted the Entra device object
the device was partially cleaned up from one portal but not the others
a reused bench device still has mismatched Intune and Autopilot records
someone tried to force a fresh deployment by deleting only the cloud object instead of following the documented deregistration order

That is why the same device can keep failing even after local reset. The missing dependency is not on the SSD. It is in the service-side registration chain.

What Microsoft says to do

Microsoft’s known-issues guidance for this exact scenario says to:

remove the device from Microsoft Entra ID
remove the device from Intune
remove the device from Windows Autopilot
re-register it with Windows Autopilot so the Entra device object is recreated

At the same time, Microsoft’s Autopilot registration overview adds an important guardrail: admins should avoid manually deleting the device from Microsoft Entra ID unless a specific scenario requires it, because the deployment process depends on that object.

Put those two points together like this:

If the Entra object is already missing and pre-provisioning is failing with 0x801C03F3, finish the cleanup of the remaining records and then re-register the device.
For future device reuse, do not start by manually deleting the Entra object. Follow the documented Intune and Autopilot deregistration workflow first.

Logs and where to check

User Device Registration log

This is the highest-value log for this failure pattern:

Event Viewer > Applications and Services Logs > Microsoft > Windows > User Device Registration > Admin

If the event log shows HResult error code 0x801C03F3 during the failed pre-provisioning run, treat that as a strong signal that the cloud device object is missing.

Autopilot event log

Microsoft’s troubleshooting FAQ also tells admins to review the Windows Autopilot event log here:

Event Viewer > Applications and Services Logs > Microsoft > Windows > ModernDeployment-Diagnostics-Provider > Autopilot

Use it to line up the pre-provisioning timeline and confirm whether the failure occurred before the expected enrollment sequence completed.

Intune and Autopilot portals

Check all three locations, not just one:

Location	What to verify
Intune admin center > Devices > Windows > Windows devices	Whether an old managed device record still exists
Intune admin center > Devices > Enrollment > Windows > Windows Autopilot devices	Whether the hardware is still registered in Autopilot
Microsoft Entra admin center > Devices	Whether the expected cloud device object is missing

If the device still exists in Autopilot and Intune but not in Entra ID, that matches the failure pattern Microsoft documents.

PowerShell and command-line checks

Run these checks before deleting anything else.

Collect the relevant User Device Registration events

Get-WinEvent -LogName 'Microsoft-Windows-User Device Registration/Admin' -MaxEvents 50 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message |
  Format-List

Review recent Autopilot events

Get-WinEvent -LogName 'Microsoft-Windows-ModernDeployment-Diagnostics-Provider/Autopilot' -MaxEvents 50 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message |
  Format-List

Capture diagnostics before the next retry

Microsoft documents this command for troubleshooting logs:

Mdmdiagnosticstool.exe -area Autopilot;TPM -cab C:\Autopilot\autopilot-0x801C03F3.cab

Check current registration state on the device

dsregcmd /status

dsregcmd will not recreate the missing object, but it helps you confirm whether the device is in a half-registered or unexpected state before you start cleanup.

Repair workflow

Step 1: Stop retrying the same broken registration

If the first failed run already produced 0x801C03F3, do not keep resealing and retrying the same registration state. Microsoft already documented the root cause pattern. Repeating the flow without fixing the missing cloud object usually wastes bench time.

Step 2: Record the identifiers first

Before cleanup, capture:

serial number
Autopilot registration status
existing Intune managed device entry if present
device name shown in any remaining portal record
timestamp of the 0x801C03F3 event

That makes it easier to prove you are deleting the stale records tied to the failed run instead of touching the wrong production device.

Step 3: Remove stale records in the right order

Use Microsoft’s registration overview as the primary workflow.

Delete the stale managed device record from Intune if it still exists.
Delete the stale Windows Autopilot registration.
Confirm whether any old Microsoft Entra device record is still present and remove it only when this specific broken-object scenario requires it.
Wait for the portal-side deletion to settle.

The key mistake to avoid is partial cleanup. Deleting only one layer is what creates most reuse problems.

Step 4: Re-register the hardware

After cleanup, import or register the hardware again in Windows Autopilot. Microsoft’s registration overview says a Windows Autopilot device registration automatically creates a Microsoft Entra object. That is the dependency this failure is missing.

Do not send the device back into pre-provisioning until you can verify:

the Autopilot record is back
the intended deployment profile is assigned
the corresponding Entra device object exists again

Step 5: Retry pre-provisioning on one pilot device

Run the next test on one device first, then validate:

the green pre-provisioning flow advances past the previous failure point
the User Device Registration log no longer throws 0x801C03F3
the Autopilot diagnostics page or logs show normal progress

Only after that should you release the same cleanup method to your wider bench or vendor process.

Why this happens so often on reused devices

Bench teams often work fast: test, wipe, delete records, re-import, repeat. That workflow is where 0x801C03F3 shows up.

Microsoft’s troubleshooting FAQ already warns that self-deploying and pre-provisioning scenarios are sensitive to device reuse and stale records. The registration overview adds that skipping steps or removing records out of order can create orphaned or unrecoverable devices.

So if your team frequently repurposes the same pilot machines, make this the rule:

do not manually delete only the Entra object
do not assume a local reset equals a cloud reset
do not hand the laptop back to the bench until Intune, Autopilot, and Entra records all agree

That process change prevents the next wave of 0x801C03F3 tickets.

Prevention

Use this prevention pattern for future Autopilot reuse work:

Start with the documented Intune delete step.
Then remove the Windows Autopilot registration.
Avoid manual Entra object deletion unless the scenario specifically requires it.
Re-register the device only after old records are gone.
Keep a short internal runbook for bench techs so they do not improvise deletions during turnaround pressure.
Collect diagnostics from the first failed device before assuming the same root cause across the whole batch.

This is one of those issues where a better cleanup habit prevents more incidents than any single fix command.

Conclusion

0x801C03F3 during Windows Autopilot pre-provisioning is usually a service-side object problem, not a device-side mystery. Microsoft’s current guidance points to a missing Microsoft Entra device object, most often after manual deletion. The durable fix is to clean up the remaining Intune and Autopilot records, re-register the device so the Entra object is recreated, and stop using ad hoc deletion shortcuts during device reuse.