Autopilot Reset – What does it do? How is it different?
You may have noticed that there are a TON of reset options in the Intune portal when looking at a device. Even clicking Wipe now includes an additional checkbox, to retain enrollment state.
So what gives? What’s the difference between all these options, and why do we now have another one with Autopilot Reset?
Let’s start with clarifying the most common options. A Wipe restores a device back to its factory settings (back to OOBE). This is what you should use for a lost or stolen device, since data can’t be restored.
If you select Retain enrollment state and user account, for a Wipe, it removes the MDM settings (configuration profiles, apps, etc.) and resets the OS, but (as the name suggests) retains the MDM enrollment and user profile. This would be the same as selecting “keep my files” in the Settings app.
Retire, on the other hand, removes only managed data & apps. This will in effect remove Intune management from the device. This would be used for a scenario where users have BYOD devices that are enrolled in Intune. Wi-fi, VPN profile, certificates, e-mail accounts, the Azure AD join record, and apps will all be removed. This does exclude O365 and Win32 apps, unfortunately.
One interesting side-effect of Retire option is that for a device provisioned for corporate use (say, Autpiloted), retiring it would remove access to the device entirely. Since the Azure AD join is removed you won’t be able to log in using an Azure AD account – meaning you’ll be stuck on the login screen (there was no local administrator provisioned). Be sure to only use Retire for BYOD devices!
Delete is nearly identical to Retire (because Intune also issues a retire command when you use Delete). Both options will remove the same company data from a device. But while Retire will wait for a device to check-in before removing it from the portal, Delete immediately deletes the record in Intune. This comes down to preference – I use Retire for active devices, and Delete for stale ones.
Regarding stale records… if you’ve noticed the Device cleanup rules under the Devices pane, you’ll see the option to Delete devices based on last check-in date. This action does not issue a Delete command – it just removes the device record. If a removed device checks in before its device certificate expires, it will reappear in the console. Device certs last 1 year.
So we’ve covered most of the “traditional” or common options. Before we get to Autopilot Reset, what about Fresh Start?
Fresh Start is nearly identical to Wipe. Both options will restore a device back to its factory settings (back to OOBE). The one difference here is that Fresh Start will also remove OEM-preloaded applications. For example, most Dell laptops purchased for corporate use will come with Dell Command Update. If you Fresh Start a Dell machine, the only built in applications then will be the ones included with the default from Microsoft Windows 10 .iso.
I personally just really enjoy that this exists at all. It’s quite powerful to be able to reset devices to a clean slate without having to put in the work to remove apps via Intune or PowerShell.
Just like with the Wipe, Fresh Start includes the option to retain user data on the device. And just like before, it removes the MDM settings (configuration profiles, apps, etc.) and resets the OS, but retains the MDM enrollment and user profile.
Finally we get to Autopilot Reset. I wanted to lay the foundation for various resets before we covered it, because like with the other options there are crossover.
Autopilot Reset removes personal files, apps, and settings on a device but retains the connection to Azure AD and Intune (or 3rd party MDM). The key here is personal data; Autopilot Reset basically only removes the user profile instead of wiping the entire OS drive. This makes Autopilot Reset a sort of middle-ground option, where you’re wiping a device and maintaining the enrollment state but not maintaining the user data.
Autopilot Reset also maintains the region/language/keyboard, any provisioning packages applied, and Wi-Fi connections. Autopilot Reset is the best option for re-using a device within your organization. You’re basically removing the last user from a device and (depending on your Intune deployment configuration) handing it right over to the next person with no extra work needed.
You can kick off Autopilot Reset via the Intune portal like any of the other wipe methods. But you can also run it locally at login by disabling the DisableAutomaticReDeploymentCredentials CSP (either via Intune configuration policy or Windows Configuration Designer). When you kick if off locally there will be a prompt for an administrator to log in, as shown here:
When the reset is a complete, the user will be presented with the Windows 10 login screen. All they need to do is login – no OOBE! There is the added security benefit (and our recommendation) of enabling the Enrollment Status Page to restrict users from accessing the desktop until all their apps and settings are installed.
One note to clarify – even though it’s called Autopilot Reset, it doesn’t prepare the device for Autopilot. You’ll have at least noticed that it doesn’t send you back to OOBE, so the device can’t even be Autopiloted. But further it doesn’t sync the device’s hardware hash up to the Autopilot service. So, my hunch at least, is that they’re branding this with Autopilot because it follows the same methodology. Autopilot Reset allows IT admins to get devices ready for productive use without additional infrastructure to manage, with “a process that’s easy and simple.” And Autopilot Reset is certainly simple to use.
Does that clear up all the options? If not post a comment below, and I’m more than happy to explain further.
There’s been another new wipe option added – a Protected Wipe! Check out our latest article to learn more: https://deviceadvice.io/2019/12/27/another-new-intune-wipe-option-continue-even-if-the-device-losses-power/
Thanks for a great article. I noticed that the Autopilot Rest leaves the first user only as local administrator. So you have to manually set the new user as local admin. Is there a workaround for this?
One workaround would be providing users the “Additional local administrators on all Azure AD joined devices” permission in Azure AD (Azure AD > Devices > Device Settings). With some additional work, it seems like you could target specific devices, but the feature is still in preview: https://docs.microsoft.com/en-us/azure/active-directory/devices/assign-local-admin#manage-administrator-privileges-using-azure-ad-groups-preview
Ole Jacobsen, I guess the best way to keep (or add) the existing local admin users after AutoPilot reset is using the Intune Script or a Configuration Policy in MDM. With a script or local admin policy, the device will automatically get the local admin user accounts.
What’s the exact difference between an Autopilot and non autopilot device assuming both azure and mdm enrolled .
The main purpose of Autopilot is to simplify the out of box experience for end-users provisioning devices. Devices end up in the same state whether they’re doing an Azure AD Join + automatic MDM enrollment or Autopilot user-driven mode. That’s because after a device ingests the settings from the Autopilot profile, it goes on to do a AADJ+MDM enrollment.
But, Autopilot lights up a few additional scenarios that aren’t possible with just AADJ+MDM, such as hybrid AADJ, self-deploying provisioning, white-glove provisioning, setting a device name, or having standard user accounts. If you look at the settings of an Autopilot profile in the MEM console, you can think of those as extra “features” you get for using Autopilot, but they’re not required for getting a device in an AADJ+MDM state.
Great article. Thank you.
Hey,
Great article thank you.
You mention “ Autopilot Reset removes all of the files, apps, and settings on a device (including the user profile) ”
But i don’t see this behavior in my test environment.
If i create folders and files on disk drive it will not remove it after autopilot reset. Is that correct or i missup with tests?
So my strategy was like after user leave company i run autopilot reset and send device to next user. But if data still on laptop i have to do fresh start because there shouldnt be any data from previous user.
Correct me if i wrong.
Thanks
You’re right – Autopilot Reset only removes data in the user profile, not across the entire drive. So if your users are saving data outside their profile it’d be best to do a Fresh Start (or Wipe). I updated the post above to be more specific about that!
An Autopilot enabled and already in Azure AD enrolled device was factory reset offline! by reinstalling Windows from HDD recovery partition. Intune was and is not aware of this. The associated primary user has left the company. How do I reset the device in Intune the right way to hand it out to another employee as his new device?
Wipe (no options selected) and then Delete. That will effectively get rid of the old record for that device.
Thank you, Janusz, that’s really a great article to learn simply the differences between these Intune features.
1. I gave my work laptop to my friend. We use pilot reset. Now after all I am still the primary user of this device so he cannot do much on his account. How to totally assign this device to him?
2. After pilot reset the device need some time to spread all those policies, credentials etc. It takes a long time but what to do in emergency situation if example I need to switch device to new user very fast?
1. Autopilot reset should remove your account from ownership of the device and set him as the primary user (as long as he has an Intune license). If it doesn’t, you could manually change the primary user through the MEM console (Docs link)
2. It shouldn’t take TOO long to apply all those policies. If they’re assigned to the device itself that may help since the device record is staying the same in MEM. If they’re assigned to the user, try enabling the Enrollment Status Page and track how long it takes to apply all the settings.
Stright forward, much appreciated.
Thanks for an awesome article. I’m trying to learn everything I can about this because my organization is beginning to use this. One caveat however is that we are running a Hybrid Azure environment. In addition to this, a very large number of our devices are multi-user devices where several people may log into them on a given day. I work in a high school. Autopilot reset is not supported in a Hybrid Azure environment from what I understand. It also seems that Microsoft does not even support multi-user Azure AD logins. If I’ve misunderstood please point me in the right direction. Thanks again for a great article!
Yeah that’s correct – Autopilot Reset doesn’t support Hybrid AADJ. For multi-user AAD login, take a look at this Shared PC Microsoft Docs article: https://docs.microsoft.com/en-us/windows/configuration/set-up-shared-or-guest-pc. I think that’s the scenario you’re trying to configure, and there’s lots of good docs online around configuring Shared PCs in EDU.
Hi thanks for the info. We are currently testing devices for primary schools. We do have a problem. One account was added to a students group with a few desktops shortcuts (both scripts and win32 ones) and another test account to a teacher group. When loggin in with the student account there are only a few things installed like no Team no Teamviewer no shortcut like the teacher. When logging off and the teacher account logs in on the same device at lot more things get installed. Then log off and on with student and the student has all the apps the teacher has, all the desktop icons. The device is not yet set for a shared device to be clear. But isn’t this weird? Also when doing autopilot reset all the desktops apps with scripts and win32 are still there. So I assumed the device would still be in endpoint manager with the same name but with all the chosen apps and scripts gone. Can you please explain why this is happening or how to prevent this?
Some Windows apps install per user, others install for the computer (meaning, all users). Teams can be set to installed for either way, so my guess would be that you need to change your install commands. Same goes for the apps/scripts – autopilot reset only removes personal apps, so that may be why you’re seeing some apps persist after the reset.
Ok thank you. So I assume only apps installed by the user itself disappear after autopilot reset. But everything that was prepared in endpoint manager and assigned to groups just stays. And the only way to test this properly (we have failing scripts) is to reinstall the computer and add to intune again. Unfortunately that’s going to be more work as the same devices end up multiple times in endpoint manager after reinstalls. Also we will not be able to use shared devices for several groups with several apps and shortcuts or it will all be a mess. The thing is I’m working with a company to set things up for us and they were surprised this is happening. We made many groups for different teachers, students and placed them in groups. Then assigned certain things to every group. Only the apps installed with chocolatey disappeared after autopilot reset. Can you point us to a script for shortcuts on the desktop that wouldn’t give us this problem please? We are also looking for a solution to add a custom icon for a shortcut to a desktop as little kids can’t read yet and it’s easy to tell them to click a certain icon. I have found several things but not yet succeeded. Thank you for replying.
Let me start by saying that you have an Amazing article here, thank you. Doing User AAd Autopilot deployment with win32 apps assigned to Devices only and working perfectly, now here is the thing, after doing Autopilot Reset I’m seeing the ESP under the Device setup showing App installs showing 1 of 1 app instead of 7 of 7, this while having the ESP setting to block device access until the apps are installed, meaning the apps are being installed after the user signs into to the device when the app installation it should be happening in the device phase.
Do you have any apps targeted in the User ESP portion? One workaround here could be adding a Dependency to a User-targeted app, which would wait until the Device ESP apps are installed before installing.
We are experiencing the same issue as David. 4 Win32 apps need to be installed during the device phase and 1 during the user phase (company portal).
What we see is that the 4 device apps are not installed during the device phase, but afterwards after the user is logged in. This works well with a Fresh start, but not with an Autopilot reset.
The same thing happens during the OOBE, where a new device is delivered to the user and it is turned on by the user. We want to be able to install those 4 Win32 apps during the Autopilot fase befor the user logs on. I hope you can clarify this for us.
Hi
I retire a autopilot-manage device. As you advice, my goal was to delete it afterwards. But I can’t access it any more in Endpoint after it has been retired as there is no Intunes association any more; So I can’t Delete it. How do I remove it from the list of enrolled devices?
If the device is no longer available in the Devices pane, you don’t need to delete it. I’ll update my post – the delete is really just for removing the record right away, if you don’t want to see it anymore. For your Autopilot device, you can go to Devices > Enroll devices > Windows Autopilot devices and delete the record from there as well, if you don’t want to it to be used again.