Based on the previous post about dealing with Windows 10 updates our WSUS is already prepared to serve Feature Updates. To enable this you have to open your WSUS console, go to Options, Products & Classifications and enable the Upgrades category (not the Updates). This will automatically create the Upgrades view on the left in the Updates branch. Then you have to go to the home page and run the synchronization. After this the Upgrades view should be populated with all the possible upgrade options. Among them the Creators Update for Windows 10. You will also see upgrade options for Windows 7 and 8.1 (we will not cover them in this article). Be sure not to approve them, if you are not planning to upgrade your existing older installations to Windows 10. To be sure, you can even decline them, so your clients won’t be showing in the list as if they are missing some update. There is also a distinction by the language used to install Windows 10. We currently have only two laptops with Windows 10. They came with a retail UK version of Windows 10 on DVDs (laptops came with pre-installed Ubuntu on them, so no OEM Windows). I had to approve Feature Update to Windows 10 Pro, versijon 1703, en-gb, Retail update option for them. There is also Feature Update to Windows 10 Pro, versijon 1703, en-us, which should cover regular OEM US installations. Enabling this upgrade wasn’t enough though.
My test Windows 10 Pro 1607 (Anniversary Update) installation picked the update, but just sat at Downloading 0% and showed the 0x8024200D error in the Event log. For WSUS to be able to serve Windows 10 Feature Updates, it has to recognize the eds file extension. On the Windows Server with WSUS open the IIS management console. Click on the root of your IIS server. Open the MIME Types menu. Press Add on the right panel and add .eds extension (with a dot), specify its type as application/octet-stream. You don’t have to restart IIS server. This change is applied immediately. You can press Check on Windows 10 and it will start downloading the update.
I was testing with a few years old HP laptop with i3-4000M, 4 GB RAM and SSD disk. It took about 15 minutes to download and prepare the update in a 100 Mbit network (4.6 GB size). Then it presents the popup shown at the top of this article letting the user to snooze, pick a time (then it will also let user to snooze it for 1 hour) or restart right away. It took additional 20 minutes after restarting until the Login window was shown (and a few more minutes after the login to finish preparing everything).
After the update winver command showed 1703 version as it should. Doing an additional check for updates found recent May updates for 1703 (already approved in WSUS), downloaded and installed them without issues. I guess fresh 1703 installations should hook into WSUS without problems either. Though i plan to test this scenario later this week anyway.
UPDATE: recently i had a case at my work, when 1607 version was not seeing 1703 update on the WSUS (although WSUS was reporting this update as Needed for that machine). WindowsUpdateLog didn’t show any helpful information. I have found on the internet, that deleting C:\Windows\SoftwareDistribution folder might do the trick. And it did. Although, stopping Windows Update service wasn’t enough to release that folder for deleting. I had to disable the service and reboot, then delete the folder and enable the service again. It created quite a bit of load on the WSUS server when doing a first fresh check against WSUS, but it finally saw the 1703 update and downloaded it. I hope i won’t have to do this often when updating our machines from 1703 to the newer version though. One can surely setup a script to do this automatically, but it won’t go well for the WSUS server when a bunch of machines will start doing a fresh check in the morning.
One thought to “WSUS – updating Windows 10 to Creators Update [EN]”