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.
After the Creators Update for Windows 10 has been published for a few days now, the first companies are starting to distribute this Creators Update via WSUS (Windows Server Update Services). Today we want to go into what needs to be considered and any problems that may arise.
First of all, it is mandatory that you use at least WSUS version 4.0 , which is available as standard on a Windows Server 2012 R2 or Windows Server 2016. In the WSUS itself you have to go to
Products and classifications
specify the products with which your WSUS server should synchronize. Below you can see which products you have to activate.
These are the following Creators products:
- Windows 10 Creators Update and Later Servicing Driver
- Windows 10 Creators Update and Later Upgrade & Servicing
After you have correctly set these options in the WSUS , you have to carry out a manual synchronization or wait for the next automatic synchronization so that the necessary updates are downloaded from your WSUS and are ready for installation on the clients.
Of course, after the synchronization you have to release the 1703 Creator Updates in the area ” Updates / Upgrades “.
Important: You should bear in mind when distributing function updates via WSUS that, for example, the Creators Update has a size of approx. 4 GB. On the one hand, this places extreme strain on any WAN routes , and on the other hand, depending on the working speed, the clients need between 60-120 minutes to install the Creator Update. During this time it is not possible to work with the PC’s, you must take this into account when distributing the feature updates for Windows 10.
You should also note that further changes must be made to your WSUS system so that it can distribute the feature updates for Windows 10 correctly. We went into this in more detail in a further article. All necessary information can be found under ” Distribute Windows 10 Feature Updates with WSUS (application / octet-stream) “.
We have published many more interesting articles on the topic of ” WSUS “. Here is a list of the most popular articles.
– Windows 10 WSUS update from version 1511 build 10586.494 to 1607 build 14393.10
– correctly distribute Windows 10 Anniversary Update 1607 via WSUS
– Windows 10 Anniversary Update 1607 available for WSUS
– WSUS connection error – no remote API connection to the WSUS server
– WSUS shows Windows 10 clients as “Vista”
– WSUS database error – Reset server node – Call
internal WSUS database with SQL Management Studio
As Windows is now delivered ‘as-a-service’ with major updates being released biannually, you may want to push out these major updates using WSUS. In previous posts I’ve covered deploying Windows 10 1703 (Creators Update) as a clean install with Microsoft Deployment Toolkit and also how to perform an upgrade to Windows 10 1703 using MDT. In this post, I’ll walk through the process of pushing out the upgrade to Windows 10 1703 using WSUS. I’m going to assume that you already have Windows Server Update Services set up. If you don’t, don’t worry here’s a walkthrough I made previously.
Prerequisites
I have created a Computer Group in WSUS called Upgrades and assigned computers to it using Group Policy. The Windows Updates settings in Group Policy are set to automatically install any updates I approve in WSUS at a specific time, everyday. For this walkthrough I’ll be upgrading two Windows versions: a Windows 7 install and a Windows 10 1511 install, just to show the differences. Both installs are Hyper-V VM’s and are fully patched. The upgrade to Windows 10 1703 will be deployed from the WSUS server running on a fully patched Windows Server 2016 Hyper-V VM. Both the Windows 7 and Windows 10 1511 VMs have a local profile for a domain user account, with lots of data stored locally on the PC and several pieces of software installed such as Flash, Google Chrome, Office 2016, Adobe Reader and VLC.
Upgrading Windows 7 to Windows 10 1703 with WSUS
Let’s upgrade the Windows 7 install first. This update requires user interaction on the Windows 7 install, so I wouldn’t personally recommend this method to upgrade all of your old Windows 7 devices to Windows 10, but for devices that need to have software and data persevered it may be preferable to a clean install.
Finding and Approving the Update for Windows 7
We need to find the relevant update in WSUS. For my Windows 7 VM, it is listed as Windows 7 and 8.1 upgrade to Windows 10 Enterprise, version 1703, en-us, your language and edition may vary though.
- Expand the server node in the WSUS console.
- Right-click on Updates, and select Search in the menu.
- In the Search box, under the Updates tab enter the name of the update that is appropriate for you. Please note the edition and language may be different from my example above.
- When the search completes, you should have a few results.
- Right-click on each of the updates and select Revision History.
- You’ll want the most recent Revision Number. For my example above, it’s 201.
- Right-click on the update you wish to approve, and select Approve.
- Choose the Computer Group you wish to Approve the update for and click OK. Please note: depending on your configuration this will download and push out the upgrade to Windows 10 on all devices in the group.
- Close the Search box, and WSUS should be downloading the update to Windows 10 1703. It is approximately 5GB in size.
Once the update has downloaded, it will be available to the devices it has been approved for.
Performing the Upgrade on Windows 7
On my Windows 7 VM, I logged in as my domain user and checked for updates. It moved to the Upgrades Computer Group I had created for it in WSUS, but the Windows 10 1703 update wasn’t downloading. In Windows Update it reported as failed with the error code: 0x80240020, and in WSUS the computer was reporting the update installation as failed with the same error code also. After waiting for 24 hours and trying a few tricks (like resetting Windows Update), I had to edit the registry to get the Update to work.
Go to the following registry key:
|
|
Create a new DWORD (32-bit) Value with Name: AllowOSUpgrade and set the Value: 0x00000001. After creating this registry key, I went to Windows Update and it reported that it was ready to install the upgrade to Windows 10. I selected to to perform the upgrade and after downloading I was presented with a few screens asking if I wanted to proceed with the upgrade. The familiar Windows Update install screen appeared on shutting down Windows 7 and upon reboot the now even more familiar Windows 10 update install screen was displayed.
After several reboots and a screen asking about Privacy Settings, I was presented with the Windows 10 1703 log in screen. I logged in as my domain user which had a local profile on the VM and all my data and programs were there. When I logged in I was greeted by the “first run” screens that all new users receive when they log in to Windows 10 for the first time. Some of the personal customisations where there, such as the taskbar icons, but they were merged with the default Windows 10 taskbar icons. Sometime later when the VM checked for Windows Updates again, the latest updates for Windows Defender and the most recent Cumulative Update was installed, bringing Windows 10 1703 right up to date.
Upgrading Windows 10 1511 to Windows 10 1703 with WSUS
The update for existing versions of Windows 10 doesn’t require user interaction, it installs like all other Windows 10 updates preserving user data, profile customisation and installed software.
Finding and Approving the Update for Windows 10 1511
In WSUS the update for my Windows 10 1511 VM is listed as Feature update to Windows 10 Pro, version 1703, en-gb your language and edition may vary though.
- Expand the server node in the WSUS console.
- Right-click on Updates, and select Search in the menu.
- In the Search box, under the Updates tab enter the name of the update that is appropriate for you. Please note the edition and language may be different from my example above.
- When the search completes, you should have a few results.
- Right-click on each of the updates and select Revision History.
- You’ll want to select the update with the most recent date under the Revised heading. For me it was 27/07/2017.
- Right-click on the update you wish to approve, and select Approve.
- Choose the Computer Group you wish to Approve the update for and click OK. Please note: depending on your configuration this will download and push out the upgrade to Windows 10 on all devices in the group.
- Close the Search box, and WSUS should be downloading the update to Windows 10 1703. It is approximately 5GB in size.
Once the update has downloaded, it will be available to the devices it has been approved for.
Performing the upgrade on Windows 10 1511
I booted up the Windows 10 1511 VM and left it on the log in screen. The VM contacted the WSUS server and moved it’s computer object to the Upgrades Computer Group. Sometime later the VM rebooted from the log in screen and began the upgrade process.
After several reboots during the upgrade, the VM booted to the Windows 10 log in screen. I logged in with my domain user which already had a local profile on the VM, and was greeted with the “first run” screens that new users receive when they log in to Windows 10 for the first time. Despite these screens appearing the data and software had been migrated and the customisation I had done as the user of the Start Menu and Taskbar had been preserved, with the exception of the Store and Edge icons had been re-pinned to the Taskbar. Sometime later when the VM checked for Windows Updates again, the latest updates for Windows Defender and the most recent Cumulative Update was installed, bringing Windows 10 1703 right up to date.
If you have any questions or comments, please leave them below.
-Mike
Имеем: корпоративную сеть с кучей виндовых машин и WSUS-сервер для обновления оных. На части рабочих станций установлена Windows 10 Ent. 1511 и 1607.
На WSUS пришли обновления для корпоративной Windows 10 до версии 1703 (Creators Update, RS-2), клиенты эти обновления видят, но не могут скачать с WSUS, отваливаясь с невнятным сообщением об ошибке.
Посмотрев отчёт для рабочих станций видим ошибку обновления. В лучших традициях Microsoft текст ошибки не понятен никому: «(Unable to Find Resource:) Reporting Event.Client.167;».
Путём непродолжительного гугления был на spiceworks было найдено решение:
— подключаемся IIS-менеджером к серверу WSUS
— в корне дерева WSUS идём в настройки MIME
— добавляем новое расширение: .esd типа application/octet-stream
— на всякий пожарный перезагружаем весь WSUS
Как всегда непонятно почему о сведения о таких моментах находятся где-нибудь на spiceworks, а не у меломягких.
Well, it’s October 18th 2017 and the Fall Creators update (Feature update to Windows 10, version 1709) is now available for download. In my particular environment, I use WSUS to deploy and manage updates.
Update: It’s now May 2018, and this article also applies to Windows 10 April 2018 update version 1803 as well!
Update: It’s now October 2018, and this article also applies to Windows 10 October 2018 update version 1809 as well!
Update: It’s now May 2019, and this article also applies to Windows 10 May 2019 update version 1903 as well!
I went ahead earlier today and approved the updates for deployment, however I noticed an issue on multiple Windows 10 machines, where the Windows Update client would get stuck on Downloading updates 0% status.
I checked a bunch of things, but noticed that it simply couldn’t download the updates from my WSUS server. Further investigation found that the feature updates are packaged in .esd files and IIS may not be able to serve these properly without a minor modification. I remember applying this fix in the past, however I’m assuming it was removed by a prior update on my Windows Server 2012 R2 server.
If you are experiencing this issue, here’s the fix:
- On your server running WSUS and IIS, open up the IIS manager.
- Expand Sites, and select “WSUS Administration”
- On the right side, under IIS, select “MIME Types”
- Make sure there is not a MIME type for .esd, if there is, you’re having a different issue, if not, continue with the instructions.
- Click on “Add” on the right Actions pane.
- File name extension will be “.esd” (without quotations), and MIME type will be “application/octet-stream” (without quotations).
- Reset IIS or restart WSUS/IIS server
You’ll notice the clients will now update without a problem! Happy Updating!