Windows 10 Feature Upgrades Full Control

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.

This Post Has 3 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.

Leave a Reply