It’s not uncommon to want a device to have the latest security updates installed before the device can be used. One of these days we’ll add that capability to the Windows Autopilot process, built in so you don’t need to do much, if anything, to enable that. But until then, it’s not too hard to do this using the Intune Management Extensions. Because the enrollment status page (ESP) doesn’t currently track PowerShell scripts, it’s better to use a Win32 app to do this.
I’ve published a ready-to-use sample on GitHub at https://github.com/mtniehaus/UpdateOS. Download at least the UpdateOS.intunewin file (grab the whole repository if you want to make any tweaks), then add it to Intune as a new Win32 app. First, select the intunewin package:
Then specify the app name, description, publisher, etc.
Specify the install and uninstall command lines (as indicated on the GitHub doc page):
Select the architectures that you want (optional) and the minimum OS version.
Finally, add a detection rule (again using the instructions on GitHub):
Save the app and assign it as a “required” app to one or more groups, and you’re ready to deploy.
So what exactly does the script do? It’s actually pretty simple: It uses the PSWindowsUpdate module to check for and install all the available updates. With that module, that logic can be simplified to one line of PowerShell:
Get-WindowsUpdate -Install -IgnoreUserInput –AcceptAll -IgnoreReboot
While it’s pretty simple, it isn’t necessary quick – the exact time depends on the current OS patch level, network performance, CPU availability, etc. On my test VM, it took about 20 minutes for the updates to install. Since this was done during device ESP, it held up the progression of the app installation process. And because the latest cumulative update needs a reboot after installation, it also caused that reboot, which requires that the user again type in their user ID and password to continue the process with the user ESP steps.
You can find the log for the process in C:\ProgramData\Microsoft\UpdateOS (the same location as the “tag” file used by the detection rule to prove the “app” installed successfully). It’s not a pretty log, and it will not add any useful data until closer to the end of the script execution, but after the fact it is at least useful to get an idea of how long this process took.
Note that feature updates won’t be installed – this is only for quality updates. (We do hope to integrate a feature update process in the future). The Windows Update for Business and Delivery Optimization policies configured in Intune should be delivered to the device before this app installs (since the Intune Management Extensions needs to install before any Win32 apps can be installed, causing enough of a delay to ensure the policies are applied).
Give it at try, see what you think.
Categories: Microsoft Intune, Windows Autopilot
Hi Michael. We are trying to deploy Windows update rings to devices for AutoPilot White Glove. However, whenever an update ring policy is applied to our autopilot group we find the white glove fails with a red screen after 25 minutes. We logged a support call and were told they should be applied at the user level as they dont work with White Glove. Is this correct? if we remove the update ring from the device group it deploys fine.
Is this Hybrid AADJ? We are investigating an issue where the update rings cause a reboot, which then results in Autopilot “forgetting” that it had already done the offline domain join.
The devices are Hybrid AAJ. with either a windows update ring or the Edition Upgrade profile attached to a device they do not complete. The devices do not reboot. They just sit at provisioning for 25/26 minutes then go red. If we do not attach them to devices then they complete ok. As soon as applied again it fails. For now we have applied to the users but it would be good to get clarification on this. I haven’t seen any official documentation to say these profiles are not supported for white glove at the device level. Thanks
LikeLiked by 1 person