This blog will be about a lesser-known feature in Windows Autopilot: the Userless Enrollment Status. We’ll look at how devices can end up in a blocked state after a reset, why that prevents self-deploying or pre-provisioning from running again, and how the new Unblock action (backed by the allowNextEnrollment API) changes the way you recover those devices.
Autopilot Enrollment blocked: 80180014
Windows Autopilot’s self-deploying and pre-provisioning scenarios use what Microsoft calls userless enrollment. In these cases, the device configures itself without a user signing in, making it ideal for large-scale or hands-off deployments.
There is, however, a limitation. If you reset a device that has already been through one of these scenarios, the next attempt could be blocked depending on the vendor. In that situation, the device will not re-enroll, and the error 80180014 will be shown.
Microsoft once attempted to handle this automatically through a background service called Fix Pending, but that approach never worked reliably and has since been retired. The supported path today is through the Userless Enrollment Status property and the Unblock action in Intune.
Let’s zoom into this Unblock and Userless Enrollment State a bit more
Userless Enrollment Status
Each Autopilot device record has a property in the backend called Userless Enrollment Status. In Microsoft Graph, this is exposed as UserlessEnrollmentStatus, which can be set to:
- Allowed — the device can attempt another userless enrollment
- Blocked — the device cannot attempt another userless enrollment until reset by an administrator
- Unknown — the service cannot determine the state, typically for new records
When a device is reset after running self-deploying or pre-provisioning Autopilot, the status can change to Blocked. From that point, the device may fail with error 0x80180014 unless the OEM has implemented functionality to allow automatic re-enrollment.
The Unblock Action: Userless Enrollment Status
To address blocked re-enrollment scenarios, Microsoft added an Unblock button in the Autopilot device blade with Intune 2310. Choosing Unblock resets the Userless Enrollment Status from Blocked back to Allowed, letting the device go through Autopilot again without deleting the device record or re-importing its hardware hash.
In the past, the only way to allow another userless enrollment attempt was to delete the Autopilot device object from Intune.
Back in the day, when you needed to delete the device object, you would also need to delete the Autopilot object. By deleting the Autopilot device object, you were required to also re-import the hardware hash. Luckily, that part also changed with the 2307 Intune release, and we no longer needed to delete the Autopilot object beforehand.
But still, this removal process added overhead and created unnecessary friction during deployments. With the introduction of the Unblock action, the same result can now be achieved directly on the existing record.
How Unblock Works in the Backend
When you click Unblock, Intune calls the Microsoft Graph action allowNextEnrollment on the Autopilot device identity.
This clears the Blocked state in the service and sets the useless Enrollment Status back to Allowed. The device is then able to start a new userless enrollment on its next run.
This update only applies to devices from certain OEMs. It does not fix devices stuck in the older Fix Pending state, as that remediation service has been discontinued. Administrators should confirm with their OEM whether allowNextEnrollment is supported for their models.
OEM Dependency
As mentioned in the previous paragraph, this Unblock functionality depends on OEM implementation. Microsoft has documented that not all manufacturers support allowNextEnrollment. For supported OEMs, Unblock is enough to retry enrollment. For others, deletion and re-registration of the device may still be required.
Example in Practice
In one deployment, Intel NUC devices configured for pre-provisioning began failing after a reset. Their Autopilot records in Intune showed Userless Enrollment Status (userlessEnrollmentStatus) set to Blocked. Instead of deleting the devices or re-registering hardware hashes, the Unblock option was selected. This triggered the allowNextEnrollment action, which reset the status to Allowed.
On the very next attempt, the devices completed Autopilot successfully.
Allowing the Userless Enrollment Status with Microsoft Graph
The Unblock button is simply a front-end for the Graph action allowNextEnrollment. This means you can perform the same operation programmatically, which is helpful for bulk remediation.
Replace {autopilotDeviceId} with the Autopilot device identity ID. The request body is empty.
A device in the blocked state will show: “userlessEnrollmentStatus”: “blocked”
After calling allowNextEnrollment, the property updates to: “userlessEnrollmentStatus”: “allowed”
This is the same transition that happens when you click Unblock in the Intune portal.
Where Unblock Does Not Apply
Unblock only clears the blocked state created by repeated resets in userless enrollment scenarios. It does not apply when the device hardware has changed. If a motherboard is replaced or another component change alters the hardware hash, the device record is no longer valid. In that case, the supported procedure remains: deregister the device, capture a new hardware hash, and register it again.
Troubleshooting Confirmation
Microsoft’s troubleshooting documentation confirms that error 80180014 during self-deploying or pre-provisioning scenarios is fixed by unblocking the device in Intune. Normally, 80180014 indicates a device enrollment restriction.
In this case, the blocked Userless Enrollment Status mimics that restriction and prevents the device from enrolling. Using the Unblock action calls allowNextEnrollment and resets the status back to Allowed, clearing the block without changing enrollment restriction policies
Conclusion
Userless enrollment makes Autopilot deployment efficient, but resetting a device after it has already completed a userless run can leave it blocked. Depending on the vendor, the next attempt may fail with 80180014.
In the past, the only way to fix this was to delete the device object and re-import the hash. Today, the Unblock action calls the allowNextEnrollment API to clear the blocked state and set the device back to Allowed. For supported OEMs, this avoids unnecessary re-registration and provides a clean, supported way to recover. For hardware changes, deregistration and re-registration remain required, but for blocked userless scenarios, Unblock is the recommended solution.