Out of Office Hours

Triggered by the publishing of documentation for Windows Server 2025 about features removed or no longer being developed, Microsoft published a separate post explicitly calling out one of those items: WSUS. While the Server post described it as “no longer being developed,” the separate post called that “deprecated.”

But what exactly does that mean? If you haven’t looked at the definition of “deprecate” in a while, here’s what Merriam-Webster says:

to withdraw official support for or discourage the use of (something, such as a software product) in favor of a newer or better alternative

Well, Microsoft explicitly stated that they weren’t removing support, so they’re just discouraging use because they want you to use something else. So practically, it doesn’t really mean anything; it’s just another example of Microsoft trying to push customers in another direction (i.e. “cloud native”).

WSUS was already “no longer being developed” as it hasn’t had any significant changes in years. But it still chugs along as a key part of Microsoft Configuration Manager’s Windows updating capabilities. So which will die first, WSUS or ConfigMgr? If at some point in the future we see Microsoft working to remove the ConfigMgr software update point (SUP), then we will know. Until then, we can assume that they will both ride off into oblivion together.

When might that oblivion happen? Well, certainly it will still be supported for the life cycle of Windows Server 2025, which should take us through 2035 (assuming Windows Server 2025 will still have a 5+5 support model). Interestingly, Microsoft didn’t say that it would be removed from a subsequent Windows Server release, so perhaps it will still be in Windows Server 2028 (or whenever the next one happens) and then supported through 2038 (again assuming 5+5). But even that is dependent on ongoing usage — if ConfigMgr still has hundreds of millions of managed devices, and WSUS standalone is still being used by thousands of customers, it would be rather chaotic to pull the plug.

For Windows client OSes, Microsoft would love it if you panicked and started moving to Windows AutoPatch (which has now subsumed Windows Update for Business) right away, but there’s really no need. AutoPatch is also not free — there are licensing requirements that must be met to use all the functionality. (Technically, WSUS isn’t free either, since it requires Windows Server and CALs or equivalent.)

Since AutoPatch doesn’t support servers, you would need something else there, and of course there is a paid solution for that too with Azure Update Manager. At $5 per server per month for any servers that aren’t Azure or HCI VMs, that’s a non-trivial expense too.

I suspect customers will also look at non-Microsoft patching solutions for Windows, which could certainly make sense. However, keep in mind that a lot of these are fed by (free) data from Microsoft:

• Windows Update Services client-server protocol. The same data that is downloaded by WSUS is available to anyone to query using documented APIs. Microsoft even publishes sample code that shows how to do it, although that was “archived” last year.
• WSUSSCN2.CAB. For “offline” clients, you can download a CAB file from Microsoft that can be used to detect what updates are needed. Separately you can then download and install those updates on the machines.

Will those data sources go away with WSUS? If they do, most third-party solutions could die at the same time. I suspect they would work around this with a simpler solution that doesn’t work as well (e.g. just checking to see if there is a record that the LCU was installed, without actually checking if any components are missing and need to be reinstalled).