Worklet: Enable Controlled Windows 10 Feature Updates through Automox Patching

The biggest problem that we are experiencing is after the reboot notification. The process kicks off fine notifying the user that an install is ready. The user clicks the Install Now button and it does take up to two hours until the user receives the Reboot Notification button. The upgrade from 1909 to 20H2 must be significant to take this much time and I am worried what would happen if they shut down the computer within that two hour upgrade period.

But, back to the Reboot notification. When the user finally receives this, and clicks on Reboot Now, it can take up to 45 minutes to actually reboot the PC. If they get bored waiting and perform a standard Windows reboot, that’s when it completely screws up the PC–the PC thinks it has two separate installs of Windows 10.

So, you can see why I am a bit nervous about rolling this out on a large scale. There are several points where users could do things I don’t want them to do.

…and another fail running the update policy, user received update notification ok, two hours later user received the reboot notification. User clicked on reboot and nothing happened for over three hours. I went into the Automox console and issued a console reboot and PC booted to the Windows Choose an Option screen. At this point, I have little confidence in this process. Has anyone gotten consistent results with this Worklet/Patching process?win10 fail0

I want to echo @djdink828 here. While I did not get the Choose an option screen, there are big reboot concerns. On a test laptop upgrading from 1909 > 20H2 the reboot prompt initiated the finalization commands that @d.mccleskey described. However, the Modern Setup Host task took so long Automox reported the following in the activity log: “Failed to apply patches (“Feature update to Windows 10, version 20H2”): COMMAND TIMED OUT” and never actually rebooted the machine. As we know by now, only an Automox reboot will cause the OS to upgrade itself. Since most of our workstations and laptops are remote, the best workaround I can think of waiting for another patch to initiate a reboot or create a worklet that prompts the user to reboot and issues the finalization commands.

The Finalization process triggered is running the windowsupdatebox.exe located in the downloaded patch source and using switches to finalize silently. I suggest reviewing the event logs and any security application logs running on the device to identify why it may time out. There is no content download for the finalization process to run. It is a direct handoff to the OS to run the finalization process… analyzing the processes running (and logging) at finalization will provide the best picture of what is happening.

I haven’t been able to reproduce the issue on any of my test systems but I have seen a handful of other COMMAND TIMED OUT errors on our remote workstations. The potentially problematic events I found on the one system that did time out in testing were Windows Error Reporting events related to MicrosoftEdgeUpdate.exe. Unfortunately I wasn’t logging anything at the time since it was the first time I had encountered the issue.

So far it hasn’t caused any issues beyond delaying the finalization process which is solved by an automox reboot triggered manually or by another patch.