Upgrades from WSUS

If you are going to handle upgrades from Windows 10 to Windows 10 latest streams in WSUS (eg, 1511 to 1607 or 1703 or 1709 or 1803) also known as Windows as a Service (WaaS), there are 3 things you need to do on Server 2012 or Server 2012 R2 (2016 has all of this taken care of already except some people have had to do #2). If you’ve followed my instructions from the start, you can skip number 3 as that’s already done.

1. In Products/Classifications, make sure to check the Upgrades box or Windows 10 Upgrades will not be available to approve.
2. You also will need to add a MIME type for *.esd as application/octet-stream at the top level in IIS.
   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 I’ve seen in the communities, the patches and fixes that this KB comes with has 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).

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.

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)

You will want to get the latest Administrative Templates (.admx) for Windows 10 which is located at:

https://support.microsoft.com/en-ca/help/3087759/

Install these Administrative Templates in your Central PolicyDefinitions folder on your Domain Controller. The best way to update them is to take a copy of the PolicyDefinitions folder as a backup and stick it in a backup folder for archiving in case you need them later. Then take the ADMX files and the language folder you’re using and copy/paste them into the PolicyDefinitions folder, overwriting files as required. Don’t 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.

Why Keep the ADMX files?

Microsoft occasionally removes some settings from ADMX templates leaving the GPO policy with ‘Extra Registry Settings’. Unfortunately, the only way to undo these extra registry settings is to either re-create the GPO policy, or put back the original ADMX templates that you set these policies on, and adjust the policy to Not Configured. 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. Other times, it may be easier to revert to a previous set of ADMX templates to edit those policies and set them as Not Configured, and then re-upgrade the ADMX templates. This is why 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 add custom ADMX files to the central store.

Wait… I don’t have a central PolicyDefinitions store

If for some reason you don’t have the Central Store, please set it up following the directions at the link above.