Worklet: Enable Controlled Windows 10 Feature Updates through Automox Patching

This Worklet will allow you to define a Windows 10 Feature version, and make it possible to install that Feature Update through Standard Automox Patching Policies.

Please see the following Community post for additional details:

Setting the Target Release Version enables the ability to manage your preferred Win 10 Feature version.


  • Your devices must be running 1803 or newer

  • Your OS must be a manageable SKU (Education, Enterprise, Professional, Business)

  • The version can be set to the current version, or newer feature update version than is currently installed. This will keep a device on that version and can help to avoid automatic upgrades before you are ready for them. Please note, Microsoft may still force upgrades when versions go out of support.

  • Setting it to a previous version will not cause issues (example, it will not roll the version back), but it doesn’t make much sense to do this.

  • Do not set these keys when using WSUS. You can already deploy feature updates by approving them in WSUS. Enabling these features when using WSUS can also enable DualScan, allowing your device to automatically update from Windows Update, and bypass your WSUS server approval controls.

Please review the following article for best practices for deploying Feature Updates: What Are the Recommended Best Practices for Patching in Automox?
Create a Patch Only Patch policy, and specify: Everything “Feature update to Windows 10”.
ENSURE THE POLICY HAS THE “AUTOMOMATIC REBOOT” OPTION SET, as this will handle the needed finalization commands to apply the final restart and complete the upgrade. Please see the Article linked at the top in the same topic for more information.


  • Upgrading between versions released in the same year starting with 1903 and 1909 will leverage enablement packages. Enablement packages turn on previously download and installed components and flip the version switch to the new version. This package is very small, and can be installed in less than 5 minutes.
  • Feature Updates spanning to another annual version set (ex 1809-1903) will still require a large update, and will take some time to install. These packages are generally smaller than an ISO, and are dynamically updated by Microsoft. This method may also apply additional updates (such as additional Cumulative Updates) along with the upgrade process.
  • If you utilize Delivery Optimization (DO), your local devices can share downloaded content to reduce bandwidth and download time.
  • No need to script a Worklet to upgrade to a newer version of Windows 10 (unless you need to customize the upgrade process).

Set the $rValue and $rInfoValue in both the evaluation and remediation code to enable the feature and set the preferred version. The values must match in both code blocks.


#Evalaution Script - Determine if Target Release Version Registry keys exist and are set 

# Define Values in this section and ensure they match the values set in the remediation script
$rValue = '1' #Enable Target Release Version 0 = Disabled, 1 = Enabled
$rInfoValue = '2004' #Specify Windows 10 Target Release Version.  Select the preferred version from 

#Predefined variables
$rPath = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate'
$rVersion = 'TargetReleaseVersion'
$rVersionInfo = 'TargetReleaseVersionInfo'

#Check if $rVersion registry value missing

    $cVersion = Get-ItemPropertyValue -Path $rPath -Name $rVersion -ErrorAction Stop
    $cVersionInfo = Get-ItemPropertyValue -Path $rPath -Name $rVersionInfo -ErrorAction Stop
    Write-Error "Unable to read registry values"
    Exit -1

#Check if registry value data matches defined values
if (($cVersion -eq $rValue) -and ($rInfoValue -eq $cVersionInfo)) {
   Exit 0
} else { Exit -1 }


Configure Windows 10 Target Release Version

  Uses group policy registry keys to Enable and configure Target Release Version for Windows 10.  
Target Release Version
Enable = 1 or Disable = 0

Target Releaese Version Info
Specify the preferred version of Windows 10.  Enter version from

Author: Automox
Please note, these settings remain in the registry, and would require modification or removal to change or revert back to default. 

  Windows 10 1803 or higher
  Managable SKU (Pro, Education, Enterprise, Business)

# Define Values in this section
$rValue = '1' #Enable Target Release Version 0 = Disabled, 1 = Enabled
$rInfoValue = '2004' #Specify Windows 10 Target Release Version.  Select the preferred version from 
$rPath = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate'
$rKeyPath = 'HKLM:\Software\Policies\Microsoft\Windows'
$rVersion = 'TargetReleaseVersion'
$rVersionInfo = 'TargetReleaseVersionInfo'

try {
  if(-not(Test-Path -path $rPath)){
    New-Item -Path $rPath -Force -ErrorAction Stop | Out-Null
    Write-Output "SUCCESS: Target Release Version keys set`t"
    New-ItemProperty -Path $rPath -Name $rVersion -PropertyType DWord -Value $rValue -Force -ErrorAction Stop | Out-Null
    Write-Output "$rpath exists`t"
    New-ItemProperty -Path $rPath -Name $rVersionInfo -PropertyType String -Value $rInfoValue -Force -ErrorAction Stop | Out-Null
    Write-Output "$rVersion = $rvalue and $rVersionInfo = $rInfoValue`t"    
    Exit 0
} catch { $Exception = $error[0].Exception.Message + "`nAt Line " + $error[0].InvocationInfo.ScriptLineNumber
    Write-Error $Exception
    Exit 90
1 Like

Hi @d.mccleskey
Just having an intermittent issue with this, and then corresponding “Feature update to Windows 10, version 20H2”.

I apply this registry change worklet and it updates on the PC’s end (can check manually) however even after a few days/scans/reboots, then “Feature update to Windows 10, version 20H2” does not become available to install.

This is only happening to about 5-10% of the devices I’ve trialled on so far, but just wondering if there are any other pre-requisites you know of that could be preventing the update from being applicable?

I am going from 1909 > 20H2, and the 1909 devices are all on the 01-2021 Cumulative update.

You have covered the most relevant requirements.

Here are the primary physical requirements:
Processor: 1 gigahertz (GHz) or faster processor.
RAM: 1 gigabyte (GB) for 32-bit or 2 GB for 64-bit.
Hard disk space: 32 GB for both 64-bit and 32-bit OS. Ensure you have enough free space ~20GB.

Here is the 20H2 rollout known issues and notifications list which will help identify drivers etc that may cause a blocker:

I have created and run this worklet to set Target version to 20H2. I verified the registry was set to 20H2.

I then created a Feature Updates Policy: Patch Only with a Filter for: Feature update to Windows 10.
The filter looks like this:

Tested on 1903 and 1909 devices, but the policy did not update the devices. There are no Feature updates listed in the device detail page.

What did I miss?


Hi Mark,

If you want to install any Windows 10 Feature update, you could simplify the list by selecting everything with the context of Feature Update to Windows 10. Using the text filter makes it easier so you wouldn’t have to update the package list in the future.
Screen Shot 2021-02-24 at 3.03.22 PM

I suggest including a Reboot in the policy as the Automox restart will finalize the upgrade at the time of reboot.

1 Like

hi @mscro

Here is what I use and it works fine.
Note, you dont need an advanced policy, I just prefer the flexibility of it.

Advanced Policy
Can see I use all updates that have a Display Name of Feature Update to Windows 10

Then for the group(s) that get assigned this policy, I ensure it is using Windows Update as the source. That way it is pulling from MS directly. You can use WSUS just make sure the server has approved the enablement packs/feature upgrades.

Group OS Patch Management

1 Like

I like it! Here is a way to manage the same policy logic that covers multiple languages as well.

Thanks for replies. I issue I’m seeing is that my 1903 & 1909 devices do not have the Feature updates downloaded and available to install when I run the Feature update policy. I have verified all the requirements. Shouldn’t they be there?

The process would look like this.

  1. Set Targeted Release Version via this worklet or GPO
  2. Ensure all prerequisites are in place (no blockers, and required SSU and CU patches are installed)
  3. Run a scan to detect the Feature Update (according to Microsoft this can take up to 24 hours to appear, so another scan may be needed to get the Feature Update to appear as an available patch). The availability of the patch is strictly tied to the requirement check defined by Microsoft. If the device does not pass the check, the update will not appear.
  4. Ensure your patch policy to install the Feature Update is non-compliant for your device (this is a quick check to see there is a Feature Update available)
  5. Run the Feature Update Policy either through pressing the “Run on this device” button in device details, or waiting for the schedule to run.
  6. An Automox reboot will finalize the upgrade and apply the offline portion of the patch process. If you do not use Automox reboots, the finalization worklet in the community can be used (just be aware the Worklet will trigger a silent reboot where a patch policy with reboot can notify your user and provide deferrals).

If I understand correctly, you are around step 3-4. I suggest running a scan to return the most current update set, and verify if there are any awaiting patches or reboots needed.
If it still doesn’t appear, you could run a test to see if there is another blocker that is unlisted by changing the registry key to look for 2004 and run another scan. If the feature update for 2004 appears, than there is most likely something else blocking the 20H2 upgrade based on the update requirement check.

Thanks for the steps. You are correct, I’m at steps 3-4. I will run a few scans and apply any outstanding CU’s that might show up (none currently). If still no Feature update is present, I will drop down to target 2004.


the 1903/1909 devices, what Automox ‘Group’ are they in?
Have you checked that the group they are in is using the correct update source? Windows update (for MS), or WSUS (for your own server approvals)?

The same thing is happening to me on a few systems. No idea why. Think I will just have to remote in and install 20h2 manually.


Yes my setting are:

I’m working with a Test group of 11 devices. The feature update shows up in roughly half of the devices. Research indicates that Microsoft may have built-in blockers as the reason feature updates won’t show on certain devices. Upgrade blocks, or Safeguard holds as Microsoft calls them, are designed to prevent devices from being upgraded to a new version of Windows 10 because of known compatibility issues in that new version. I haven’t found a way to determine what specific compatibility issues are present on the devices in question.



I was able to get this running with the help of RMullen (thank you), but I still have some questions about workflow and logistics. You obviously need to run the worklet first to expose the 20H2 Feature Update to Automox, then you run the patch policy to install the Feature Update. I am having difficult determining how to set up the group or groups to do this in an automated fashion. Are folks creating just one group and running both the Worklet and the Policy? If so, do you have the timing set so that the the Policy runs 30 minutes after the Worklet runs? How do you know the Worklet has made 20H2 available? I have seen some cases where the Feature Update isn’t available even after running the Worklet. From a user perspective, are you notifying the users that the update is being pushed? Are you doing a group of PCs at a time? What happens if they shut down the PC in the middle of the update?

The alternative is to just allow the Feature Update to run on its own in our normal workstation patch policy but there is little to know control over that process.

Our Win 10 1909 users are starting to see the little amber Windows 10 end of life notification in their systray so the clock is ticking for us.

I would suggest running the targeted version Worklet setting the registry key as a passive action well before your feature update policy is scheduled. It can run daily, weekly etc.
The Feature Update patch policy would be something you schedule potentially with communication to your users that you will be upgrading them a certain day, etc if their device is ready for it. You can also run the policy manually for users that are ready to run it before your scheduled deployment time.
30 minutes between adding the key and running the patch policy may not be long enough. The key is making sure a scan is run between when the key is applied and when your patch policy is scheduled. A wrinkle in timing is also based on a note from Microsoft that the Feature Update take up to a day to appear.

I would suggest running the reg key Worklet, and allow your devices to apply the key and scan to collect a list of devices applicable for the the targeted feature update. Then schedule the feature update on predetermined and communicated times a Week or so later.

Thanks David–I believe that we have spoken several times during our implementation. Your instructions concerning running the Worklet and letting things bake in, and then choosing workstations to patch makes sense.

However, I have been seeing some inconsistencies with the way the patch policy–specifically when it comes to the reboot is working, and it makes me a little nervous about rolling this our widely. As I mentioned, all of our PC’s are on 1909 and moving to 20H2. The several I tested so far worked fine but most take well over an hour to complete–again, not sure what would happen if some folks rebooted or powered off their PCs.

More seriously, I had one test PC prompt me for the reboot, I clicked on reboot and nothing happened…it was obviously doing something because I saw some PowerShell processes running in the task manager. After 40 minutes, and still no reboot, I checked task manager again and saw nothing that appeared related to Automox so I restarted the PC using the native Windows restart. It did not go into the updating processes I expected, it shut down quickly and restarted into the Choose and Option screen. When I click on Use Another Operating system, I see two versions of Windows 10. Only one of the two versions of Windows boots and it takes me back to 1909. I have attached some screenshots. I have had three PC’s do this already, one using the Controlled process and two using the ISO method.

I think the only option at this point is to reimage the PCs . I am worried this will sporadically happen to other PC’s if we start using this process and we aren’t staffed to handle this type of issue. I am not sure where we go from here.

Thanks for bringing up the additional detail here. I do have some information that may be at least helpful to understand where errors can occur.
The patch policy method silently automates the process that would run should you run the In-place upgrade manually through the device software updates UI with a little more control on the target version. If there were a problem with a manual IPU, the automated process would also run into the same problems.

A note on the restart failing to actually trigger a restart and upgrade (which could account for the scenario you mentioned). An Automox reboot (either from the console or triggered from the patch policy) will run a finalization command to complete the upgrade. A standard reboot would not finalize the upgrade, and it would return to the original OS version after a manual (from the OS) reboot.

One nice feature Microsoft added with version 2004 and newer IPU is an automatic run of SetupDiag when an IPU attempts to install if there is an error or hard block. If the IPU installation did not complete its staging process, the Automox triggered finalization process could detect the IPU staged, but it may not detect that it attempted to stage and cannot complete an upgrade.
If there were a problem, SetupDiag would create a registry key with troubleshooting information you can use to identify why the upgrade will not complete. Here is a link with more detail on how to use the SetupDiag results:

One quick identifier is that if this reg path exists, there was a problem with the IPU, and it will not upgrade. Installing the patch again can be attempted again after the blocker or issue is remediated. Here is the reg path created when there was a problem: HKEY_LOCAL_MACHINE\SYSTEM\Setup\SetupDiag\Results

I think my question would be why the Automox reboot doesn’t kick off a reboot. That means the PC will eventually be rebooted using the Windows standard reboot and will cause the issue I documented. To me, that’s my biggest fear. The inconsistency with some of the Automox behavior is kind of scary when it comes to these large upgrades. Notifications seem inconsistent --either not prompting users to install when it should, or not rebooting PC’s when it should. I’m almost at the point where I am ready to send out instructions to our users on how to manually run the update via Windows Update.

I would welcome other customer experiences with running Feature Updates using either the Controlled Worklet or the Worklet to Automox OS Upgrade to Latest Windows10 OS version. I am really trying to make this work for us but am getting a bit worried that it is not as reliable as I was hoping.

I believe it has to do with the logic it uses with the reboot command. If it has staged an upgrade, it will send the finalization script to complete the upgrade which includes a reboot as part of the process. If it does not have an upgrade staged it sends a standard reboot.
If it staged the upgrade, and then the upgrade failed to complete the online portion of the process, it will still send the finalization command which will not complete, so no reboot happens.

Not sure if this was ever dropped anywhere, so dropping the link here, but this is the link for the chart with the Windows 10 build codes listed:

1 Like