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.

NEED TO KNOW:

  • 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.

BEST PRACTICE
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.

BENEFITS

  • 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).

Actions:
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.

EVALUATION CODE

#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 https://docs.microsoft.com/en-us/windows/release-information/ 
#############################################

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

#Check if $rVersion registry value missing

try{
    $cVersion = Get-ItemPropertyValue -Path $rPath -Name $rVersion -ErrorAction Stop
    $cVersionInfo = Get-ItemPropertyValue -Path $rPath -Name $rVersionInfo -ErrorAction Stop
}
catch{
    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 }

REMEDIATION CODE

<#
.SYNOPSIS
Configure Windows 10 Target Release Version

.DESCRIPTION
  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 https://docs.microsoft.com/en-us/windows/release-information/

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

.PREREQUISITES
  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 https://docs.microsoft.com/en-us/windows/release-information/ 
#############################################
$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
}

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?

Thanks
Mark

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.

Thanks
Mark

@mscro
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.

@rmullen

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.

Thanks

Mark