[ad_1]
Back in 2019, I did a blog post about installing Windows updates during an Autopilot deployment. That was with Windows 10. There was no reason to believe that the behavior would be any different with Windows 11, but I hadn’t actually tried it — until now. And it wasn’t pretty: Autopilot and ESP really don’t deal with reboots triggered by Win32 apps at all. It’s not obvious if that’s a problem with ESP or with the Intune Management Extension, but either way I wouldn’t suggest trying it. Here’s what it ends up looking like:
After the reboot, Windows can’t sign back as the defaultUser0 account, so you have to put in some other credentials — we are AAD-joined at this point, so those credentials work, but then the whole process starts over again, and it will fail later when it tries to redo the MDM enrollment — an error is returned saying the device is already enrolled. So that’s no good.
So how does it work if we don’t do a reboot? It seems like getting the updates installed and then prompting the user to tell them a reboot is required would be a reasonable experience, and it at least hurries along the updating process which otherwise might be delayed until hours after the Autopilot provisioning process completes. Well, I didn’t see any notification, but at least when I manually rebooted it finished installing the updates.
The odd part is that if you open Settings before rebooting and check for updates, it will re-detect the same updates that PSWindowsUpdate already installed and go through all the motions of installing them again. This seems a little weird, but at least that’s not something normal people typically will do.
But still, without a notification they won’t know that a reboot is needed. If we can’t force a reboot during ESP due to the flakiness described above, we can at least schedule a deferred reboot. I added a “RebootTimeout” setting to the UpdateOS.ps1 script and set it to default to 120 seconds, so as long as user ESP is disabled (something I typically recommend) the reboot should be initiated after the remaining Autopilot process is complete. (If you have user ESP enabled, you’ll want to increase that timeout.) That does assume that the UpdateOS app is the last one in the list, which requires using a dependency chain to force that (useful anyway to make sure Windows is updating any optional features that might have been added in previous apps/steps).
With that reboot inserted, here’s what you see:
At some point, Autopilot will add the ability to do Windows update installs as part of the built-in process. That was something that was stated as a roadmap item back in 2018. We’re still waiting, but maybe not much longer?
[ad_2]
Source link
