Autopilot reset: what blocks it, and what it leaves behind

Autopilot reset returns a Windows device to its original provisioned state without breaking its enrolment, which makes it the fastest way to move a laptop from one person to the next. It also fails more often than it should, and the two most common causes are settled long before anyone clicks the button: the device is Microsoft Entra hybrid joined, or Windows Recovery Environment is switched off. Neither of those produces an error that says so in plain words.

Which provisioning path the device came through matters as well, so establish that first, because Autopilot device preparation and classic Autopilot rebuild a machine differently. Below is what the action keeps, what it clears, the four conditions that block it, what error 0x80070032 actually means, and the one place the documentation contradicts itself. Verified against Microsoft Learn on 27 August 2026.

What autopilot reset keeps and what it clears

The action is narrower than a wipe and wider than Fresh Start. Microsoft documents that it removes personal files, apps and settings, then reapplies the device’s original settings and returns region, language and keyboard to their original values. What it deliberately does not touch is the part that costs time to rebuild.

That retention list is the whole reason to choose it. The machine never leaves Entra ID and never leaves Intune, so there is no re-enrolment, no new hardware hash to collect, and no waiting for a device record to reappear. Compare that with the sequence in wipe and retire, where the order of the two actions decides whether data is left orphaned. Fresh Start sits somewhere between: it strips apps and settings, and with Retain user data selected it keeps the Entra join and the contents of the user’s home folder. That is a different intent. Fresh Start is for a machine buried in OEM software. Autopilot reset is for a machine changing hands.

The four conditions that block an autopilot reset

1. Microsoft Entra hybrid joined devices are not supported

This is the condition that ends most refresh plans, and it is not a bug to be worked around. Microsoft states that Windows Autopilot Reset supports Microsoft Entra joined devices only and does not support Microsoft Entra hybrid joined devices, which need a full device wipe instead. The documentation then adds the part people discover late: after that full wipe, a hybrid joined device might take up to 24 hours before it is ready to be deployed again, and re-registering the device is the way to expedite it.

So on a hybrid estate, autopilot reset is not a same-day option and no configuration profile will make it one. Surface Hub is excluded for the same reason, and takes the same route.

2. Windows Recovery Environment must be enabled

The reset runs out of WinRE. If WinRE has been disabled or its partition has been left in a broken state, the action cannot start, and the error it returns is unhelpfully generic.

1REM Confirm WinRE status before planning any reset campaign
2reagentc.exe /info
3
4REM Re-enable it if Windows Recovery Environment reports Disabled
5reagentc.exe /enable

Run the first command against a sample of the fleet before you promise anyone a reset workflow. WinRE being disabled is common on machines that have had recovery partitions resized, imaged from an old reference build, or serviced by an update that could not fit into the recovery partition.

3. Local reset is switched off until you switch it on

Local reset, the version an engineer triggers at the device, is disabled by default so that nobody wipes a laptop from the lock screen by accident. The control is the CredentialProviders/DisableAutomaticReDeploymentCredentials policy, and it has to be set to 0. In Intune that is Devices, then Configuration, then Create, platform Windows 10 and later, profile type Templates, template Device restrictions, and under General the setting named Autopilot Reset, set to Allow.

Once the profile has landed, the trigger is CTRL + WIN + R from the lock screen, and it asks for local administrator credentials. If the key combination does nothing, the profile has not applied yet rather than failed, which is worth checking before raising a ticket. The three problems that look exactly like a sync failure apply here in full.

4. The role you need is not the role the documentation agrees on

This one is worth stating carefully because two current Microsoft pages give different answers. The Autopilot documentation says remote reset requires the Intune Service Administrator role. The Intune device action reference for Autopilot Reset, which is the more recently revised of the two, lists Help Desk Operator, School Administrator, or a custom role carrying the Remote tasks/Wipe permission together with read access to managed devices.

Plan against the narrower page. Granting Intune Service Administrator to a service desk so they can reset laptops hands out tenant-wide configuration rights to fix a delegation problem, and the custom role with Remote tasks/Wipe does the same job with none of that reach. If a service desk operator reports the button missing while an administrator sees it, this is the first thing to check, not the device.

Local reset and remote reset do not leave the same device record

The two entry points look interchangeable and are not. Remote reset, launched from Devices, then All devices, then the device, then Autopilot reset, removes the primary user and the Microsoft Entra device owner, and whoever signs in next inherits both. Local reset updates neither, so the record still points at the person who handed the laptop back.

That difference is quiet and it accumulates. A fleet refreshed locally ends up with device records attributed to departed staff, which breaks self-service in Company Portal for the people actually holding the machines. What the primary user controls, and when to clear it covers the consequences; the point here is simply that local reset leaves you a manual step and remote reset does not.

The failure modes

Error 0x80070032 during autopilot reset. This is ERROR_NOT_SUPPORTED, and on this action it means WinRE is not correctly configured or not enabled. It reads like a licensing or platform refusal and it is neither. Run reagentc /info, enable WinRE, retry. Microsoft’s guidance if the reset still fails after WinRE is confirmed enabled is to raise a support case, which is an honest admission that there is no second self-service fix.

The reset stops at a BitLocker recovery key prompt. Reported often enough to plan for, and I have not reproduced it in my own lab, so treat this as a documented-adjacent pattern rather than something I have measured. The mechanism people describe is consistent with the WinRE dependency above: if the recovery environment cannot cleanly take ownership of the encrypted volume, the reset falls through to a manual unlock. Have the recovery key to hand before starting, not after.

The device comes back and sits at the enrolment status page. Expected behaviour, not a fault. The reset restores the provisioning state, so the device works through the enrollment status page again on the way back to a usable desktop, and it blocks the desktop until the restore and any provisioning packages have been reapplied. On an MDM enrolled machine it also blocks until the MDM sync completes. A reset that appears to hang is usually a device waiting on a required app that was slow the first time too.

Nothing happens when the key combination is pressed. Either the device restrictions profile has not applied, or the account being used is not a local administrator on that device. Both are silent.

What I would do differently

I would stop treating autopilot reset as a troubleshooting tool and treat it as a logistics tool. It is very good at one job, returning a working, enrolled, on-network machine to a known state for a new owner, and it is poor at almost everything else, because it deliberately preserves the identity and enrolment state that most broken devices need rebuilding.

The order I would put the checks in, before writing any of this into a process document: confirm the join type, because a hybrid estate rules the action out entirely and that decision belongs at the top; audit WinRE across the fleet, because it is the single most common blocker and the only one that can be fixed in advance at scale; then decide local against remote on the basis of the device record rather than convenience, which almost always means remote. Only then create the device restrictions profile.

And I would say plainly what the documentation does not: this feature assumes a healthy device. If the machine is broken enough that you are considering a reset to fix it, the reset is the wrong action, because everything you are trying to clear is on the keep list.

Last verified: 27 August 2026.