Been using WSUS for so many years and never learned this. Partly because on my old job we always were using one version of Windows 10 (or Windows 7) and there was no need to know the exact versions or builds. Now when i have to manage 4-5 different versions of Windows 10, Version column in WSUS became essential. It shows full Windows version with build number and last CU update version, e.g. 10.0.18362.449 for 1903 version. You can see the same information on a local machine in systeminfo or using winver command. But there is a catch which i’ve only noticed after installing 1909 Enablement Package update on one test 1903 machine. It still shows 18362 build in WSUS console, although it should be 18363. And even CU number after the dot is not up to date. I’ve been told that WSUS is actually checking Windows Update agent’s version (wuaueng.dll) to determine Windows build. And in 1909, this agent hasn’t been updated and stayed the same as in 1903 version (because 1909 is just a CU update of 1903 disguised as a “feature update”). Moreover CU updates also not always change WU agent’s version, so version after the last dot might also be stale. It seems that ConfigMgr has another column for that – Operating System Build, which shows correct version of a system. This is probably a result of WSUS being a legacy tool, not originally designed to work with such dynamic changes to build versions and it never was updated properly to work better with Windows 10 (and never will). This also shows in “failed” status while a machine downloads a feature update and some other quirks requiring a mandatory wiping of SoftwareDistribution folder as PCs just stop reporting status to WSUS properly. With 1909 update Microsoft is trying to optimize their updates and new features delivery process going away from a huge feature update rewriting all system files, requiring huge installation package and multiple restarts. Now they release new features with regular CU updates, but features stay disabled until an Enablement Package is installed at some point. It seems that MS is delivering on a promise of a Windows as a Service and maybe in a few years we won’t have big versions like 1809, 1903 and such. There will be one version for good and new features will be released monthly with regular CU updates along with fixes and security patches. Well, some businesses still will require LTSC version, so it probably won’t go away.
Microsoft has posted on their Windows IT Pro blog about a new temporary requirement related to Windows 10 1903. This new Windows 10 version will have changes to UUP (Unified Update Platform), which require to introduce new product in the list of Windows – Windows 10, version 1903 and later. Administrators will have to enable that product along with regular Windows 10 product to be able to sync updates for 1903 version (once they have upgraded their machines). This is a temporary requirement and there will be no similar product for 1909 version and newer. Once you upgrade to 1909 you should be able to uncheck this product and leave only regular Windows 10 selected. This applies both to WSUS and Config Manager (SCCM). But ConfigMgr also has to be updated to at least 1902 version to support this new product. Even if your older ConfigMgr is showing 1903 upgrade as available. This requirement is about updates that will come out later for 1903 version and not related to upgrade itself.
NOTE: after a few comments on MS blog it seems that maybe this new category will be used not temporary, but for all next feature updates going forward. And then old “Windows 10” category won’t be needed. Still waiting on clarification from Microsoft.
After quitting my job i didn’t have a chance to manage WSUS again. But i was curious how Windows 10 updates were handled in the recent months. So, i have spun up a Windows Server 2019 VM and installed WSUS. In the image above you can see all 1809 versions (Fall 2018 Update) currently available. 1809 first was released in the beginning of October and i was annoyed by the fact that by the end of that month there were still no separate install packages for x86 and x64 (which were introduced for previous versions to cut the size of install). It shows that separate x64 packages were released on November 27th. So it took Microsoft almost 2 months to do this. By that time i would usually already have all my PCs updated to the latest version. Ideally i would like to have separate packages be available at the same release date. Or we don’t even need combined packages. Anyway, turned out 1809 was a mess, so nobody hurried to install it. You can see that there was another build release in 2019 March (2019-03B), which probably had fixes for all 1809 nasty issues included. Interestingly, this time they released just separate packages for x86 and x64 at the same time and no combined one. Maybe they will keep this procedure. Will keep this VM around to check later. Obviously, there is no 1903 packages yet in the general Windows 10 product category (it is still in testing and wide release is planned for a second half of May). Although i saw “Windows 10 1903 and later” category in the list, but haven’t tried to sync it. This can be handy though. If your network only has PCs with say 1809, you don’t have to sync older updates, if you are setting up new WSUS service. Just pick the 1809 and later category and get only relevant ones.
Microsoft is planning to stop using SHA-1 algorithm when signing their updates (to prove they were not tampered with). Based on support article though it seems it only affects older, stand alone version of WSUS (3.0 SP2). If you are using WSUS as a role on Windows Server 2012 or higher, it should be 4.0 version and probably already supporting SHA-2. Anyway, there is still time before the switch. Microsoft should release SHA-2 support for 3.0 version of WSUS and older operating systems (Windows 7, Windows Server 2008/R2) in March/April of 2019 as security updates and the switch to use only SHA-2 signing will be executed on June 18, 2019.
UPDATE: i saw someone coming to this article with a search query “how to test SHA-2 support”. Well, you can’t, i think. Because Microsoft should stop signing updates with SHA-1 after June 18. I’m not sure how you can get an update signed only with SHA-2 until that point. So, you should install all security and critical updates for affected OSes, install that WSUS update and hope that everything works past that date.
A while ago i have posted about how i plan to deal with big feature updates for Windows 10 via WSUS. Now the April 2018 Update (1803) is out. Nothing has changed about the issues with Cumulative Update after the upgrade. Windows 10 still can’t see the latest Cumulative Update on WSUS after the upgrade. I have searched on this topic and read at some site, that it was a known bug for 1607 version. I guess it will never be fixed..
Last time i have explained how i was going to work with feature updates for Windows 10 further, which would involve lots of manual checking and fixing. I was also hesitant to do scripting, as it was hard to make a good and error prone script. But i have finally decided to try it with scripting, because it would just be very time consuming to do the old way for hundreds of PCs twice a year. Read More
Short post this time. After all the mess that happened after the Spectre and Meltdown vulnerabilities disclosure and a frenzy of patching (i think Microsoft has released updates 5-6 times in January) a few machines in our network have stopped updating their status in WSUS. Although, they were still able to check for updates. It happened after a failed installation of KB4056892 update. Which then installed correctly, but since then no status updates were sent. The solution is as per usual: stop the Windows Update service, wipe C:\Windows\SoftwareDistribution folder, start the service and run the check for updates.
Based on a few last updates in this post i had to adjust my Windows 10 management via WSUS. It will involve manual checking and fixing, so if one has thousands of clients – tough luck. It is possible to make a script to do everything. A complex, error prone and hard to test. I don’t want to end up with some PCs running with WU service disabled for a prolonged period of time. If someone can come up with a sophisticated script for this (possible to do everything on a single run during a startup, with pauses, etc.) feel free to share, though sometimes it just doesn’t allow to delete SoftwareDistribution folder after stopping WU service and you must to reboot the system or even disable WU and then reboot. What other options there are? SCCM uses the same method and i think i’ve read comments about people having similar problems. Not to mention it costs a lot. Intune won’t let you manage updates the way WSUS does. It is just a set of policies you apply to your PCs. Just like Windows Update for Business. You set how and what updates should it get and hope it is working. There is no GUI or a list of PCs to see if they are updating or not. In the world of WannaCry outbreaks it is crucial to have a tool to make sure your network is updated. WSUS is outdated and has its own flaws, but it was working fine until Windows 10 came. Microsoft needs to do something about it. Read More
After posting about my experience updating Windows 10 to Creators Update via WSUS earlier this year i thought updating to Fall Creators Update should be a breeze. Well, not exactly. There are some issues and quirks i had to deal with.
First of all, our WSUS has successfully pulled Fall Creators Update (1709 version) from Microsoft servers sometime around October 17 and started reporting Needed status for Windows 10 PCs in our network. So i went and declined an upgrade for Windows 7 and 8.1 machines as we are not doing such upgrades. And then approved en_us and en_gb updates for a special group, which i will be putting PCs in to update. We have two versions as there are a few computers in the network using en_gb version (that was a mistake, but now we don’t really want to reinstall them; i wish there were only one EN version..). Then i have added a few testing PCs to that group. When doing Check for updates it pulled the update from WSUS and started preparing it for installation. While PC was showing “Preparing” status, WSUS was showing Failed status for this machine (quirk No.1, but very minor one). After the update installation it still shows Needed status for some time, until it gets new info from PCs. Once PC has prepared Fall Creators Update (FCU or 1709) it shows a popup as shown above. It is different from what was shown last time and this popup is the usual Action Center popup. Although i would like not to have human faces in there as i have to prepare instructions with screenshots and this looks weird. Quirks No.2 and 3 – pressing Restart Now in this popup did nothing on one of my testing machines. I have waited 5 minutes, tried pressing it again, restarting the machine and pressing again. Nothing. The second PC haven’t even showed it at all for some reason. One should hope MS will fix this for the next update (actually, it should be fixed in the FCU already for it to work for the next update). So, i had to use Start > Power button > Update and Restart. This worked fine and FCU install went smoothly on both machines. It took around 10-15 minutes until seeing your desktop (with multiple reboots and waiting for it to finish once you login). As MS is now doing updates with only differences, not overwriting the whole system, it takes almost 2 times less time. This is great.
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. Read More
At the end of 2016 i had a chance to update our WSUS system. We’ve been using WSUS 3 version for almost 6 years on a rather old Windows Server 2008 platform. WSUS was installed as a separate service back then. And now we have used a new Windows Server 2012 R2 as a basis for it (of course, after the release of 2016 it can be considered as outdated already). WSUS 4 is now being deployed as a standard role (Server Role). All other requirements and features are selected and installed automatically. Although WSUS 4 itself both visually and in its functions hasn’t changed much. WSUS 4 deployment and configuration was a breeze and haven’t caused any problems, especially as it is so standartized and simplified in this case. But at the same time we have decided to launch a Windows 10 pilot (2 new PCs). So Windows 10 category and its updates have been enabled in our new WSUS system. And then the hell broke loose..
First of all, if you want to manage and deploy Windows 10 updates via WSUS, you have to provide a lot more storage space. Because one Cumulative update can take 1-1.5 GB 😯 Yes, i can’t wait for a time when MS will introduce their improved Windows 10 updates with a new Windows Update system, which should take less space (it should probably be revealed with the Creators Update in the Spring of 2017). The other thing to keep in mind – Feature Updates or Upgrades (how they are called in WSUS). These are not security or critical updates, but the new builds (just like SR1 – 1511 or Anniversary Update – 1607). WSUS 4 can’t normally deal with them without a few special hotfixes. So enabling this category without them can break your WSUS 4 system. We haven’t even tried this yet, as we are installing the newest build to this day – 1607. I might post about nuances of updating to the newer build via WSUS after the Creators Update arrives next year. But if you are installing WSUS 4, you can prepare for it in advance by installing those hotfixes and doing other required changes (more on this later). Read More