Windows 10 Feature Upgrades Full Control

Jan 2020 Update: There are still issues applying the CSP with a value of “20H2”. Microsoft still has not fixed this bug as of the January 2021 cumulative update. The good news is that there are other way to apply this that achieve the same result. See the “Apply 20H2” section at the end for some options.

Introduction

If you’ve been using Windows Update for Business for any period of time, you’ll probably think that it’s just a glorified way of auto patching. Agree or disagree with Microsoft’s approach, it does make things easier for the IT admin in that they don’t have to deploy and push out each update manually. This is even more impactful when you have lots of devices on the road or at home. However, the most control you got was “deferring” when the patch comes as opposed to “pushing” it out when ready. This made it especially hard for Feature upgrades as way more testing is required and up until the 2004 release, the max you could stay on a feature version was 365 days. Windows only allowed you to “defer” the feature upgrade up to 365 days. You could technically “pause” feature updates after that, but it was a fairly tedious way to go. 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 has addressed this issue and added another way to control the Feature upgrade.

Introducing “TargetReleaseVersion”

2004 launch in June of 2020 and alongside it Microsoft published a new node in the Windows Update for Business CSP called “TargetReleaseVersion”. This new node, when deployed, tells the device which feature upgrade to “stay” on or which feature upgrade 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:
  1. 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.

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 TargetVersion-1809.xml and then click the “raw” button which will take you here.
  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.
  1. Click Save and Publish
  2. Go to device details > Profile tab. Find the profile and install it on the device.
  3. 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.
  1. Change the value in between the “Data” nodes to be the version you want.
  1. 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.
  2. 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.

Applying 20H2

Using a value of “20H2” in the CSP fails because the CSP expects a numeric value (yes, even though the format is “chr” in the XML…). However, there are a few easy ways to work around this.

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 Profile

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 tip!

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="20H2" Type="String" />
		</parm>
	</characteristic>
</wap-provisioningdoc>

This Post Has 10 Comments

  1. Ken

    How do you account for the data value (in your case “1909”) being deleted the next time the Windows Update payload Profile is applied?

  2. Ken

    The CSP doesn’t seem to work with 20H2, regardless of entering in 2009 or 20H2 in the data field.

    1. Brooks Peppin

      This does not work for the 20H2 version (yet). This is the first version to be alphanumeric, but MDM is still looking for all numerical values. Microsoft is aware of this issue and will be fixing this in a cumulative update soon. I’d recommend just holding off on going to this version until they patch this CSP. If you need to get on it early for dev or test devices, then you’ll need to remove this CSP altogether and instead use deferrals and set them to zero. I’ve updated the blog accordingly as well.

      1. Brooks Peppin

        @ken – I’ve updated the blog with some ways to deploy 20H2 value until MS fixes the CSP.

  3. Hari

    @Brooks any solution for 20H2? as mentioned profile failed with “The parameter is incorrect” error.

    1. Brooks Peppin

      This does not work for the 20H2 version (yet). This is the first version to be alphanumeric, but MDM is still looking for all numerical values. Microsoft is aware of this issue and will be fixing this in a cumulative update soon. I’d recommend just holding off on going to this version until they patch this CSP. If you need to get on it early for dev or test devices, then you’ll need to remove this CSP altogether and instead use deferrals and set them to zero.

      1. Brooks Peppin

        @Hari – I’ve updated the blog with some ways to deploy 20H2 value until MS fixes the CSP.

  4. Hari

    Thanks Brooks, really appreciate your help!!

    1. Brooks Peppin

      Thank you! Glad it helped.

Leave a Reply