Windows Servicing Upgrades from WSUS – Windows 10 & Windows 11

If you are going to handle Windows Servicing Upgrades, known as Windows as a Service (WaaS) with WSUS, there are some things you need to know. Windows Servicing (Windows 10 version upgrades: RTM>1507>1511>1609>1703>1709>1803>1809>1903>1909>2004>20H2>21H1>21H2>22H2 and Windows 11 version Upgrades (21H2>22H2) is only available with Server 2012 and higher. As of now, Server 2008 and Server 2008R2 are end of life, are not receiving any security patches, and cannot even synchronize with Microsoft’s systems as WSUS 3.0 has been deprecated due to the lack of support of TLS 1.2. While it is deprecated and on an unsupported operating system, it technically still can be used as a downstream system server to a Server 2012+ upstream system, although you should be upgrading your system to a server version that is in support – preferably the latest Server 2022.

Windows Server 2022/2019/2016

If you are using Server 2016 or higher, you only have 2 things to do to enable Windows Servicing:

1. In Products/Classifications, under the Classifications tab, make sure to check the Upgrades box or Windows Servicing Upgrades will not be available to approve. For Windows 10 upgrades, Under the Products tab, make sure you have “Windows 10, 1903 and later” checked as well or you will not receive upgrades past 1809. For Windows 11 upgrades, under the Products tab, make sure you have “Windows 11” checked. If you are synchronizing the Drivers classification, it is also recommended to check “Windows 10, 1903 and later, Servicing Drivers” and “Windows 10, 1903 and later, Upgrade & Servicing Drivers”
2. Server 2016+ already comes loaded with a MIME type for *.esd (application/vnd.ms-cab-compressed) and this will work for some installations, but we have found that for some this still will not work properly. Instead, we recommend that you change the MIME type to application/octet-stream at the top level in IIS.
   If you have WAM, Open the WAM Shell and type
   Add-ESDMimetype
   If you do not have WAM:
   To do this: Open IIS Manager > Select the server name > From the “IIS” section in the centre of IIS Manager, open “MIME Types” > Click “Add…” >
   File Name Extension: = .esd
   MIME type: application/octet-stream

Server 2012 & Server 2012R2 WSUS

If you are using Server 2012 or Server 2012R2, you have 3 things to do to enable Windows Servicing:

1. In Products/Classifications, under the Classifications tab, make sure to check the Upgrades box or Windows 10 Upgrades will not be available to approve. Under the Products tab, make sure you have “Windows 10, 1903 and later” checked as well or you will not receive upgrades past 1809. If you are synchronizing the Drivers classification, it is also recommended to check “Windows 10, 1903 and later, Servicing Drivers” and “Windows 10, 1903 and later, Upgrade & Servicing Drivers”
2. You also will need to add a MIME type for *.esd as application/octet-stream at the top level in IIS.
   If you have WAM, Open the WAM Shell and type
   Add-ESDMimetype
   If you do not have WAM:
   To do this: Open IIS Manager > Select the server name > From the “IIS” section in the centre of IIS Manager, open “MIME Types” > Click “Add…” >
   File Name Extension: = .esd
   MIME type: application/octet-stream
3. If you are using Server 2012 or Server 2012 R2, along your update path, you may or may not heard about the dreaded KB3159706 (https://support.microsoft.com/en-us/kb/3159706). While Microsoft has not officially superseded this update, from the feedback we have seen in the communities, the patches and fixes that this KB comes with have been included with the latest cumulative update for Server 2012 and Server 2012 R2. According to the KB Article, you now only need to run a single command ("C:\Program Files\Update Services\Tools\wsusutil.exe" postinstall /servicing). If KB3159706 still applies to you and is installed, perform ALL OF THE STEPS BELOW including the ones for SSL (which is Microsoft’s best practice anyways; more on that in Part 7).

Are You Still Upgrading from Windows 7 or Windows 8?

In addition to the steps above, if you are still upgrading from Windows 7 or Windows 8 systems to Windows 10, you will also need 3 registry keys on each of the machines you want to upgrade to Windows 10.

The easiest way to deploy these registry keys is by using a Group Policy Preferences (GPP) Registry Preference Policy with the Action set to Update and with Item-Level Targeting (ILT) to Operating System – Windows 7, Windows 8 or Windows 8.1 with the following keys:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\OSUpgrade]
"AllowOSUpgrade"=dword:00000001
"OSUpgradeInteractive"=dword:00000001
"OSUpgradeRunOnceCount"=dword:00000001

Apply this GPP to your clients that you wish to have updated to Windows 10. Once your systems have updated to Windows 10, be sure to remove these registry keys. The easiest way to remove them is to create a new GPP with the Action set to Delete with ILT to Operating System – Windows 10. You can now apply this and it will delete them from the updated systems.

Upgrading to Windows 11 from Windows 7 or Windows 8 would also need these keys, but likely your systems will not meet the new Windows 11 System Requirements (likely the Processor requirement) so this upgrade would likely be done through hardware attrition.

Windows 11 – Systems Not Meeting Hardware Requirements

If your systems are not meeting the new Windows 11 Hardware Requirements, Microsoft does NOT RECOMMEND you upgrade your system to Windows 11 as it will not be in a Supported state and Microsoft will not guarantee that it will receive new Cumulative Updates (Security Updates). Microsoft’s Documentation has indicated to create a new registry (REG_DWORD)  property called AllowUpgradesWithUnsupportedTPMOrCPU in the Key: HKLM:\SYSTEM\Setup\MoSetup with a value of 1.

Use an Elevated PowerShell (Run as Administrator) to add this on 1 system:

New-ItemProperty -Path "HKLM:\SYSTEM\Setup\MoSetup" -Name "AllowUpgradesWithUnsupportedTPMOrCPU" -Value 1 -PropertyType DWORD -Force

Apply this using GPP to your clients if you need to do this to multiple clients at one time.

[HKEY_LOCAL_MACHINE\SYSTEM\Setup\MoSetup]
"AllowUpgradesWithUnsupportedTPMOrCPU"=dword:00000001

After this registry entry is added, your system will now be able to upgrade to Windows 11 even though it doesn’t meet the system requirements. Your system still MUST have a TPM 1.2 chip though.

Addendum – KB3159706 – Manual Steps

In case you still need them.

1. Open PowerShell using ‘Run as administrator’
2. Run wsusutil’s post install with the /servicing switch
   "C:\Program Files\Update Services\Tools\wsusutil.exe" postinstall /servicing
3. Install the ‘HTTP Activation’ feature under .NET Framework 4.5 Features using an Administrative PowerShell prompt
   Get-WindowsFeature -Name NET-WCF-HTTP-Activation45 | Add-WindowsFeature -Restart:$False -Verbose -Source 'Windows Update'
4. Open the web.config file and modify it
   

   notepad ‘C:\Program Files\Update Services\WebServices\ClientWebService\Web.Config’
   Modify the config file to include the bolded lines
   <services>
   <service
   name=”Microsoft.UpdateServices.Internal.Client”
   behaviorConfiguration=”ClientWebServiceBehaviour”>
          <!–
          These 4 endpoint bindings are required for supporting both http and https
          –>
          <endpoint address=””
          binding=”basicHttpBinding”
          bindingConfiguration=”SSL”
          contract=”Microsoft.UpdateServices.Internal.IClientWebService” />
          <endpoint address=”secured”
          binding=”basicHttpBinding”
          bindingConfiguration=”SSL”
          contract=”Microsoft.UpdateServices.Internal.IClientWebService” />
   <endpoint address=””
   binding=”basicHttpBinding”
   bindingConfiguration=”ClientWebServiceBinding”
   contract=”Microsoft.UpdateServices.Internal.IClientWebService” />
   <endpoint address=”secured”
   binding=”basicHttpBinding”
   bindingConfiguration=”ClientWebServiceBinding”
   contract=”Microsoft.UpdateServices.Internal.IClientWebService” />
   </service>
   </services><serviceHostingEnvironment aspNetCompatibilityEnabled=”true” multipleSiteBindingsEnabled=”true” />

5. Restart WSUS Services
   Get-Service -Name WsusService | Restart-Service -Verbose
6. Run a checkhealth with wsusutil to make sure WSUS is healthy
   "C:\Program Files\Update Services\Tools\wsusutil.exe" checkhealth

Administrative Templates (.admx/.adml)

You will want to get the latest Administrative Templates (.admx/.adml) for Windows which are located at:

https://docs.microsoft.com/en-US/troubleshoot/windows-client/group-policy/create-and-manage-central-store

Get the latest one, even if it’s not for the OS you are installing. These are backwards compatible and cumulative meaning that the latest one will have all the updates from each of the preceding admx files. Install these Administrative Templates in your Central PolicyDefinitions folder on your Domain Controller.

1. When you download the Administrative Templates installer, install the definition files locally on your workstation. It will install the files to a folder in C:\Program Files (x86)\Microsoft Group Policy\[Downlaoded Version]\PolicyDefinitions\. Open this folder and copy all admx files (in the root folder) and the appropriate language folder (eg. en-US) and copy these to your Domain Controller into a temporary folder like C:\Temp\NewPolicyDefinitions).
2. Take a backup of your existing policies in case you need to revert them later for whatever reason. Copy the entire PolicyDefinition folder from your domain controller’s C:\Windows\SYSVOL_DFSR\domain\Policies\PolicyDefinitions (\\domain.com\SYSVOL\domain.com\policies\PolicyDefinitions) to another folder like C:\Temp and rename the folder to the current date.
3. Take the admx files and the language folder you copied to C:\Temp\NewPolicyDefinitions and COPY (not move) them, and paste them into C:\Windows\SYSVOL_DFSR\domain\Policies\PolicyDefinitions, overwriting files as required. Do not worry, these Administrative Templates are inclusive of all the prior versions of Windows but now with updated descriptions and applies to fields that are actually very good and very accurate. Delete the files and folders in C:\Temp\NewPolicyDefinitions to finish the cleanup.
4. Uninstall the Administrative Templates from your local workstation as you no longer require this to be installed.

Why Keep the Old ADMX files?

Occasionally you may need to revert a specific ADMX template if a setting is no longer available, especially in custom ADMX files or 3rd party ADMX files. Microsoft occasionally removes some settings from ADMX templates leaving the GPO policy with ‘Extra Registry Settings’. There are 3 ways to remove these.

1. Re-create the GPO policy from scratch. Sometimes the easiest way is to simply re-create the policy copying the settings from the old policy manually into the new one, applying it, and deleting the old policy.
2. Put back the original ADMX templates that you set these policies on and adjust the policy to Not Configured. Therefore, you should be keeping the ADMX file backups of your PolicyDefinitions folder because you may end up needing a working copy of what you had before, especially if you are adding custom ADMX files to the central store.
3. Use PowerShell from a workstation with GPMC to remove the values from the GPO making sure it is running as a user that has modify permissions on the GPO.

Using the GPMC settings report, you will see the registry key and value to remove under the “setting” column in the report.

If the setting is under the User Configuration portion of the GPO, it will relate to the hive HKEY_CURRENT_USER (HKCU).

If the setting is under the Computer Configuration portion of the GPO, it will relate to the hive HKEY_LOCAL_MACHINE (HKLM).

Import-Module -Name GroupPolicy
Remove-GPRegistryValue -Name "Office Deployment" -Key "HKCU\Software\Policies\Microsoft\Office\11.0\Word\DisabledCmdBarItemsCheckBoxes" -ValueName "FileOpenToolsFind"

Wait… I Do Not Have a Central PolicyDefinitions Store!

If for some reason you do not have the Central Store, please set it up following the directions at https://docs.microsoft.com/en-US/troubleshoot/windows-client/group-policy/create-and-manage-central-store#the-central-store

Essentially it is creating the appropriate folder on the domain controller, placing the admx/adml files into it, and that is it. GPMC.msc and Windows DFSR handles the rest (DFS replication of SYSVOL to other domain controllers). If you have not set up DFS Replication and are still on an older 2008R2 or lower FRS methodology, first migrate to DFSR for SYSVOL.