Worklet: Finalize Windows 10 Feature Update to 2004 or 20H2 Applied From a Patch Policy

As older versions of Windows 10 are retired, upgrades to newer versions of Windows 10 begin to become available through Windows Update, and you can deploy them through patch policies to your devices. Please review our best practice policy for a Feature Update Policy guide:
NOTE: This is one of the few places I suggest switching on the “Install Optional and Recommended Windows Updates” option.

Up through feature update 1909, Automox handled the finalization of feature updates with a following reboot. That reboot could either be triggered by the policy, or from the console… in either case it sent down a command to finalize the upgrade, and the device would reboot and complete the upgrade.
Microsoft updated the way this works starting with feature update 2004. When the full feature update package for 2004 or 20H2 applies, the device will not reboot when triggered from Automox. If you manually reboot, the upgrade does not apply automatically (it responds as a standard reboot).

This Worklet will handle that situation. The evaluation block detects when a feature update is staged and ready to apply. The remediation block runs the upgrade finalization command.
User experience will be a hidden upgrade process, and then the device will reboot to continue with the upgrade process.

If you are upgrading from 2004 to 20H2 with a Windows 10 Feature Update to 20H2 Enablement Package, you will not need this Worklet. A standard restart will apply the new version as a patch.

Only run this policy if upgrading to 2004 or 20H2 from a previous version.


if (Test-Path $($env:SystemDrive + '\$WINDOWS.~BT\Sources')) { 
    # $WINDOWS.~BT is only present when a OS Upgrade is staged. 
    exit 1
} else { 
    exit 0


Finalize Windows 10 Feature Update to version 2004 or 20H2

  Runs finalization command to complete Windows 10 feature upgrade after staged, and complete upgrade with a reboot.  

Author: Automox

  Upgrade to 2004 or 20H2 must be successfully staged and ready to be applied.

#Handle Exit Codes:
trap {  $host.ui.WriteErrorLine($_.Exception); exit 90 }

function reboot ($isUpgrade) {
    if ($isUpgrade) {
        Write-Host "Finalizing OS Upgrade" 
        $arguments = "/Update", "/Finalize" 
        $patchPath =  Get-ChildItem C:\WINDOWS\SoftwareDistribution -Filter WindowsUpdateBox.exe -Recurse | ForEach-Object { $_.FullName } 

        & "$patchPath" $arguments 
    else { 
        Write-Host "No Upgrade Staged"
         exit 0 
if (Test-Path $($env:SystemDrive + '\$WINDOWS.~BT\Sources')) {
# $WINDOWS.~BT is only present when a OS Upgrade is staged. In order for the upgrade to apply on reboot this command needs to # be executed which will finalize a bunch of settings then reboot the machine to apply the update. 
    reboot $true
else { 
    reboot $false

Thanks - I did wonder why I had to manually update devices to 20H2.

Is there a way to filter on devices that have staged updates pending?

At this time, there is not a filter specifically for identifying devices with staged upgrades.

The Evaluation code block above is a pretty good indicator that an upgrade is staged. If the $WINDOWS.~BT directory exists, an upgrade was attempted. It is either sitting and waiting for completion, or the upgrade attempt failed and the files there provide information on to what caused the error.

That’s interesting - I’m sure I recall (back in the old days) that Automox put up a banner at the top of the dashboard which allowed you to see all devices that had not yet been patched to remediate a particular zero day exploit.

When exactly is the upgrade staged? I haven’t had any luck getting this to work. It either shows an error message or it says there are no upgrades staged.

HI @JustinS, this is a worklet that you would run in addition to a Feature Update installed as a patch from Automox. By itself, it does not install or stage the upgrade. It is meant to complete a staged update to 2004 or 20H2 that installed and needs to complete the installation which normally would be handled with a reboot from Automox.