Event banner
Event details
We have a very high turnover of devices within the organisation (school with pupils age 11 - 18 where each pupil has a Microsoft Surface Pro) both with devices coming back in to be reused by other users and new devices coming in after existing stock is sent off for repair, and we are struggling with keeping the process fast and efficient both on a technician side to make sure that devices are ready for users but also from a user side so that they aren't waiting for too long on device set ups. All devices are purely Azure AD joined.
What is the recommended process/best practice for this scenario?
Currently, for devices that are coming back from users to stay in the organisation we make sure the device has all its updates and then do an autopilot reset. For new devices coming into the organisation, either as new or repair replacements, we go through the standard set up with a service account, run all the updates (often including the update from Windows 10 -> 11) and then do an autopilot reset so that all devices that are ready to go out to users are in the same state.
There are a few issues with this, one is a bug where the Microsoft documentation here: https://learn.microsoft.com/en-us/autopilot/windows-autopilot-reset says: "When Autopilot reset is used on a device, the device's primary user is removed. The next user who signs in after the reset will be set as the primary user.".
This is not the case, primary users are not removed on reset nor are primary users set on set up. This is true for both local autopilot resets and those triggered through Intune.
This was raised with support last year who confirmed they could replicate the behaviour and nothing else came of it. While not the end of the world, it does require technicians to always remember their manual intervention to make sure primary users are up to date to allow for elements such as self service app installations and configuration reporting.
Additionally, we run into numerous issues with the user set up section where the devices don't show their progress (only shows "Pending" for all stages until it is complete), where updates with pending reboots prevent the process from working but requires the ESP to time out before it shows the reboot required error or where apps that are marked as required in the ESP are not installed but the process completes "successfully". This section also takes between 3 and 30 minutes to complete when it does complete successfully with no obvious reason as to the variation in time.
Furthermore, app installation status, configuration profile status and other records tied to the intune record of the device persist through every autopilot reset. I appreciate that part of the point of an autopilot reset is to keep the intune record, but it gets ungainly relatively quickly.
Previously we have tried using pre provisioning set up however this ended up taking too long to process devices on the technician side to make sure that they are ready while also hitting multiple issues such as requiring that the intune record be deleted and time outs on provisioning.
Happy to work through any issues we have with our deployment, however would appreciate some advice as to what the "intended" or advised route would be for this situation.
Hey JoeWhite, pretty experienced M365 MSP here.
We ask customers/users to reset their own devices via Company Portal app, which works reliably and doesn't show any of the issues you describe. Given that many students probably forget to do this, have you considered doing a "device wipe" from within the Intune Portal's device page? You can do that as a "bulk action" on multiple devices or groups simultaneously. This also is extremely reliable in our experience, resulting in factory-fresh devices and no stale entries or associations in M365 (except for Entra, which inexplicably retains the old device records that need to be cleared separately. But as long as devices get new device names this has no impact). You would need to change your re-deployment process to accomodate, but it may be worth it.
If you're getting restarts during ESP, that is a known issue when you apply policies to devices. Windows (as we know) often needs to restart for the most trivial reasons, and many Intune policies can do that too. Try applying most policies to USERS instead of devices, and you'll find those annoying reboots go away. We know many policies are supposed to be "device" policies, but find that almost all of them work just fine when applied to users. The only ones we apply to devices are Endpoint Security policies - and they don't cause reboots. There are a few other device security settings we deploy by script as a registry change - such as hardening LSASS and enforcing HVCI. Those normally require a restart, but if you just change reg keys, Windows doesn't know that during deployment. 😉
Also, DON'T try to force updates during ESP - that's a sure way to timeout ESP and/or cause unwanted restarts in our experience. Windows will automatically download and install updates roughly one hour after the primary user first signs in - including all security patches and updates. This works really well and our customers like it better. Devices are subjectively ready to use quicker. Also, if students perform the enrollment/onboarding at home (do they?), you've offloaded a lot of network traffic as well. Once the updates have downloaded and installed (devices can already be used!), students receive a prompt to restart which also enables the registry changes we made earlier. Even if students don't restart, I'm sure your update policy will enforce a restart <48 hrs after the updates installed. Right? 😁
So instead of trying to get as much work done BEFORE handing the devices over to students, maybe consider allowing them to finish certain things AFTER students have enrolled? --> Sure works great for us!