How to Deploy Windows 10 Feature Updates with Complete Control

Read the blog below or check out my YouTube video on this process!

Introduction

Update: The bug with deploying “20H2” suing the CSP has been fixed by MS and will work after applying the May 2021 cumulative update.

If you’ve been using Windows Update for Business for any period of time, upgrading Windows 10 with the semi annual feature updates was particularly challenging as the only way to control them was by deferral. And not only that, the max deferral was only 365 days. So if you weren’t on top of the game with testing and validation, the latest feature upgrade could start rolling out to your environment without you even realizing. Additionally, other cumulative updates would sometimes not appear since the device “saw” the feature upgrade in the background and would prioritize that over regular patches. With the launch of 2004 (in May of 2020), Microsoft thankfully has addressed this issue and give us another way to deploy feature upgrade — and this time with full control.

Introducing “TargetReleaseVersion”

Windows 10 2004 launched in June of 2020 and alongside it, Microsoft published a new node in the Windows Update for Business CSP called “TargetReleaseVersion”. This new setting, when deployed, tells the device which feature version to “stay” on or which feature version to “go to”. Wait you’re telling me I can control when devices get the next feature upgrade? Well…Yes!

This powerful little setting does several important things:

• It allows you, the admin, to upgrade to whichever feature upgrade version you want, even if it’s not the latest one. For example, you could choose to go from 1809 to 1909 even though 2004 is already out. Previously this wasn’t possible as the device would always want to take the “latest” available feature upgrade if it was past the 365 deferral.
• It also “locks” the device to a specific version for the ENTIRE life-cycle of that version. This gives you way more than 365 days to stay on each version. You can check out the end of service dates for each Windows 10 version here. Don’t forget that fall releases (1809, 1909, etc) have a longer service life than the spring ones (1803, 1903, 2004).

A few caveats

There are a few caveats though so let’s run through them:

1. This can’t be used to go backwards, i.e. from 1809 to 1803.
2. This was released with 2004 version and simultaneously back-ported to older versions (1803-1909). But, in order to get it, you will need to apply the June 2020 cumulative update to your device. For example, it does not work on the March 2019 release of 1809 (10.0.17763.379). If you try to deploy the CSP it will say “node not found” and/or if you look in GPO it’s not there either. Once you deploy the June update, the setting appears:

3. Additionally, per MS recommendation you should also change the “Deferral” of feature upgrades in your normal ring settings. You should set to value to “0”. This is because we aren’t deferring anything, we are instead specifically telling the client what version to be on or go to. I’ve personally tested this with setting deferral to 365 and 0 and it doesn’t seem to make a difference though. The deferral appears to be ignored, but I still wanted to highlight the official MS documentation.
4. If you set the Release version to version that is no longer supported by MS (i.e. setting it to 1809 or 1903), then the system will ignore this and upgrade to the latest. This is another reason you always want to stay current and don’t fall too far behind with feature versions.

Configure and Deploy Profile with UEM

I’ve gone ahead and created some samples for each version, available here. Let’s do the 1809 one as an example:

1. Click on the desired target version XML and then click the “raw” button.
2. Select all and copy the text to clipboard
3. At the top of UEM console, click Add > Profile. Select Windows > Windows Desktop > Device Profile.
4. Fill out the General tab as appropriate. I recommend setting the profile to “optional” while you test. Assign a Smart Group as well.
5. On the left side of the window at the bottom click on Custom Settings and then Configure.
6. Paste the copied data from the sample xml files into the “Install Settings” section. Optionally you can configure the “Remove Settings”. Some customers paste the same data into both sections so that on un-erollment or un-installation of the profile, the settings persist. Leave “Make Commands Atomic” unchecked.
   

8. Click Save and Publish
9. Go to device details > Profile tab. Find the profile and install it on the device.
10. It should show green as successfully installed. You can check on the device to see the values applied by going to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\Update

Expected Behavior

After this is deployed, the device will stay on this version until you change the setting or it reaches end of service. Once you are ready to upgrade the first wave of test devices, you’ll go through this flow:

1. In UEM under Profile list view, select the Profile and click Manage > Copy at the top.
   

2. Change the value in between the “Data” nodes to be the version you want.
   

3. Assign to your first wave of devices. Once they get the profile, the next time the device checks for Windows Update it will then move to that version.
4. Add more assignment groups over time until you get everyone upgraded. Easy! No need to “approve” or “assign” the specific Windows update feature version in the UEM console.

Other Ways to Deploy

May 2021 Update: There was a bug in the CSP that prevented you from setting it to any non-numerical value like 20H2. Microsoft has finally fixed this issue! All you have to do is deploy the May cumulative of 2021 update to systems 1809 and newer and the CSP will work fine with “20H2” as the value. With that said, here are a few other ways to deploy if you don’t or can’t use the CSP.

Deploy via GPO

If your machines are still domain joined, you can deploy this value with traditional group policy. The GPO will configure the registry keys under this node: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsUpdate

You’ll need to ensure you have the Windows 10 ADMX templates (preferably updated to the latest version) installed on your domain controllers. Create a new GPO and edit it.

Expand Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Update > Windows Update for Business.

Edit “Select the Target Feature Update Version”, Enable it, and type in “20H2”

Close GPO editor and then ensure it is linked properly and the device is in the correct OU.

Deploy via Sensor

Another way of doing it is by configuring that same registry key, but instead of using GPO we can use Workspace ONE sensors. This has the benefit of being able to deploy to any Windows 10 device regardless of domain join status and it doesn’t require connectivity to the domain controller.

Open up Workspace ONE console and browse to Sensors. Depending on your version of the console, Sensors may be located in different places.
Devices > Sensors
OR
Devices > Provisioning > Custom Attributes > Sensors

Add a new Sensor, and name it (lowercase)

Configure the following:
Language: Powershell
Execution Context: System
Execution Architecture: Auto
Response Data Type: String
Code:

$path = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"
If(!(test-path $path))
{
    New-Item $path -Force 
}
New-ItemProperty -Path $path -Name "TargetReleaseVersionInfo" -PropertyType String -Value "20H2" -Force

Save and Assign to your Smart Groups. Under Trigger Type, set it as desired but I normally set it to “Schedule”

Any devices that get this sensor will have this registry key applied. It will also re-apply every time the Hub sync (every 6 hours by default).

Deploy via Registry

You can deploy registry changes via a custom settings profile as well. If you’d like to do that here are the steps. The benefit of this is that it is a bit easier to assign to your devices and it can remove the setting easily as well. Thanks to Shuler MeHaffey for the tip! Note that this in fact sets the same registry setting as what GPO sets as well.

Create a Windows 10 device profile and click on custom settings. Ensure you select “Workspace ONE Intelligent Hub” from the dropdown.

Install settings:

<wap-provisioningdoc id="4ee19c79-6a7a-4727-91db-c1c55025deca" name="customprofile">
	<characteristic type="com.airwatch.winrt.registryoperation" uuid="cd83e639-24cd-4108-954e-f2ab3263fe5e">
		<parm RegistryPath="HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" Action="Replace">
			<Value Name="TargetReleaseVersionInfo" Data="20H2" Type="String" />
		</parm>
	</characteristic>
</wap-provisioningdoc>

Remove Settings:

<wap-provisioningdoc id="788ae22e-c563-4afe-8b80-2d0f4b9fb8a8" name="customprofile">
	<characteristic type="com.airwatch.winrt.registryoperation" uuid="9803d4fc-21d8-4e97-aca2-5c2d19e3b7e8">
		<parm RegistryPath="HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" Action="Remove">
			<Value Name="TargetReleaseVersionInfo" Data="" Type="String" />
		</parm>
	</characteristic>
</wap-provisioningdoc>

Conclusion

The TargetReleaseVersion setting in Windows Update for Business gives you full control over how and when to upgrade your clients. You can configure this setting via the MDM CSP, traditional GPO, or via a registry key,. You can use Workspace ONE to deploy this to your client or another management tool such as Microsoft Endpoint Manager.