Understanding Windows Update Services product categories for Windows Server 2022 and Azure Stack HCI

Iron Contributor

The new Server 2022 LTSC has arrived. And it is a great release.
Some customers still struggle to find their SA benefits and ISOs / licenses and RDSH licenses in VLSC, but it is officially released. If you fail to find it contact VLSC support via phone.


The Microsoft Teams have written excellent and brief blogs about the news in Storage, SMB, Security and other topics you can find on

Unrelated to this topic, links to some key improvements of Windows Server 2022 LTSC:

Windows Server 2022 Security Baseline - Microsoft Tech Community
Enabling HTTP/3 support on Windows Server 2022 - Microsoft Tech Community
Storage Innovations in Windows Server 2022 - Microsoft Tech Community
SMB over QUIC is now in public preview! - Microsoft Tech Community
SMB Compression in Windows Server 2022 and Windows Insider - Microsoft Tech Community

OPS104 Securing SMB from within and without - Microsoft Tech Community


What's not yet published is changes to WSUS.


"Hey Karl, do you speak about this legacy stuff to deploy Updates for on-premises?"

Yes, it still exists and is still needed for SMB and SMC and bigger organizations, while latter might use ConfigMgr or MEMCM or ISV solutions, where WSUS is often a needed requirement.


Technically we cannot expect anything new in WSUS?


Why? The rule to not update any legacy MMCs is in place with Windows Server 2022 LTSC, so also there are no improvements or additions to any MMC consoles, Server Manager, or Active Directory Administrative Center (DSAC). An exception to this rule was an important bug in DSAC that got caught in Windows Server 2022.

- Ultimately the issues with detection of WU client OS strings - since Windows Server 2016 and Windows 10 is not fixed in the WU database either. While it possible, there is a paid solution doing this for you to make your reporting great again.
 - Windows Admin Center support for Windows Update Services is not on the horizon either. I hope for Ignite 2021.


So what has changed? Product Categories, naming, that one need to learn and understand.


But before we get into let us recap about the history and where we come from.

Over the past decades, naming of product categories was rather simple.

- Windows Client had its own category per major release
- Windows Server had its own category per major release
- SQL Server had its own category per major release 

With the era of Windows 10 OS, which applies to Server and Client OS alike, as these are very similar to the core, this has game changed a bit. 

At first all Windows 10 versions have been assigned to "Windows 10" category.
Later, thankfully, the team added new categories per release. I will explain why this was important.


What changed with Windows 10?


With Windows 10 1903 Microsoft introduced "1903 and later" category which I supposed and promoted the idea to have one category for 1903 and 1909 as these share the binary same updates. 

Well, that did not happen. 1903 and later now includes updates for the following:
1903, 1909, 2004, 20H2 and 21H2, where 1903 and 1909 aswell as 2004-21H2 share the same binary updates.

So how about Windows Server, Windows Server product like SQL Server etc?

Simple as that one category for each release:

Windows Server 2008, 2008 R2, 2012, 2012 R2, 2016, 2019 

SQL Server each release had an own category from 2000 through 2019. 
So far so good and simple.

Another OS emerged called Azure Stack HCI, got it's own product category. But only for the initial release.
Another OS emerged for those with Software Assurance rights, called Windows Server version xxxx

aka Windows Server SAC, while xxxx follow the Windows 10 OS naming of YYMM so 1903 for March 2019 release - or more precisely end of development cycle (branch), as release happened sometimes later. Windows Server version will no longer be available after version 2004.

Microsoft noticed hindsight putting Azure Stack HCI, which is a SaaS product - same to Windows Server version (SAC) and has a similar release schedule - in one product category was an unfortunate design decision.


Why is one product category for any SAC product an unfortunate decision?

It means that the limitation Windows 10 versions having all releases in one product category repeats with Windows 11 and you face the same problem.

If you place all SAC products into one category, it makes it ultimately harder for an IT Pro using WSUS to automatically approve specific version and decline SAC versions that are no longer in use across the organization.
This is because SAC products do have an intended and short support period and will be replaced in production and so will play no further role but bloat up your database and metadata and compliance lists (WSUS reports) with unneeded versions.

From this perspective, it would have been wise to not repeat the same mistake name it Azure Stack HCI from the start but Azure Stack HCI, version 20H2.
Same as Microsoft factually did separate for Windows Server version, xxx in WSUS product categories. Well that did not happen, did it?


To the core of this article. What's next?

Starting with Windows Server 2022 and all 21H2 releases this familiar game will change rules.

Windows Server 2022 will not see an own product category called "Windows Server 2022" as we would assume and how it is officially named.

Azure Stack HCI OS will not be included into Azure Stack HCI OS category, except the first release version 20H2.

Both updates will be included in a new category named "Microsoft Server operating system-21H2"
Does this break any naming convention and former logic? Does it bother? You decide. 


How about the driver and servicing drivers categories?

That's still complicated. see:

How about Windows Server 2022 Azure Edition and neat Hotpatch feature?

You would assume that due to the naming convention you might find it in the near of Microsoft Server 2022 Azure Edition as a seperate product category.
Be disappointed. The naming convention does not apply to any extend.
It is called Server 2022 Hotpatch category, yes the full name, not even Windows Server 2022 Hotpatch or sorts.
Pardon me but seems like someone hotpatched the category name itself. I do not believe they will change this as this would stress to change the whole servicing and metadata and break things.


Any other caveats?

There are Windows Server categories for 2019 and other in the developer tools section.
This happened due to a catalogue update error, which causes WSUS and ConfigMgr to sync any updates in 2021. These categories do contain any updates. So, make sure you do not check or bother with the Server Categories in the Developer Tools Products.





- do not use product categories for Windows Server in Developer tools. These are dead.

- you will find Azure Stack HCI OS in the Azure Stack HCI product category, but only the initial version 20H2. No future ones.

- you will find future Azure Stack HCI OS version 21H2 and Server 2022 LTSC in the category named Microsoft Server operating system-21H2.



Source and kudos:

Thank you Artem Pronichkin, for the excursion and your help on the topic.

01/13/2022 - added notes about Windows Server Azure Edition and Hotpatch, minor fixes, corrected name from ADAC to DSAC
09/24/2021 - typo / grammar corrections
09/10/2021 - more insight from Artem, see reply
09/10/2021 - formatting, typo / grammar corrections, added screenshot
09/09/2021 - formatting, corrections

18 Replies
best response confirmed by kwester-ebbinghaus-business (Iron Contributor)

After further discussion with Artem, it is more understandable why this category.
While we agree the name is not a nice one. There are some facts that make the decision more understandable.

Windows Server 2019 did not only include Windows Server 2019 but also Windows Hyper-V 2019, as well as Windows Server version 1809 (SAC). All shared the binary same patches.
So, the category name in the past was also misleading.

This is the best explanation why the new name and no single category for Windows Server 2022 and a separate category for Azure Stack HCI OS 21H2.

Thank you Artem for taking the time on this debate. 
p.s. if you want to learn more about Artem Pronichkin here is a nice interview and links.
I really like his blogpost on his webpage about the history and PowerShell transition of sconfig. Worth reading.

Added Screenshot from WSUS, as due to the sorting the category is hard to find, also the Upgrade and Servicing drivers have a different name :)
Sorry but it still looks like insane to me.
A sub-category "Windows Server 2022" within "Windows Server", for people using Windows Server but not Azure Stack HCI (so no need to download then bloat WSUS database with it).
A sub-category called "Azure Stack HCI 21H2" for people using Azure Stack 21H2 and not older versions or Windows Server 2022, same reasons.
I read Artem reasons twice, and they still make no sense to me. Maybe I'm an idiot.

It is not logic for a non developer in fact. You see in the screenshot that the analogy why they chose the new name does funnily not apply for drivers :)
However Windows Server 2022 and Azure Stack HCI 21H2 do share the same updates. So you do not bloat your WSUS at all, it is just an awkward name, as Artem confirmed.

I am not aware if it would have been possible to assign one update to two categories in update catalog, while having one file only binary stored.

Is this understandable?

Well from what I understand Artem isn't a developer, which make things even more akward.
Windows Server 2022 doesn't have a SAC version - just like all previous Windows Server versions except 2019. Yet it won't use the same naming convention in WSUS, nor will it follow the naming convention of SQL Server which traditionnaly shared it (SQL Server vNext won't be called "Microsoft SQL Server - database software 21H2" as far as I know).
Azure Stack HCI 21H2 share updates with Windows Server 2022 sure - for now at least. Who knows what will happen in the next ten years ? Especially considering the SaaS nature of Azure Stack, unlike Windows Server LTSC.
Same update base sure. But different products. So why not different categories ? Why complicate things ?

Why "Microsoft Server" anyway ? Why not "Windows Server" ? "Why "operating system" ? We'll get something in the future called "Server" but not being an operating system ? Or a Unix/Linux operating system ? Both at the same time ?

Sorry for the rant. WSUS products and classifications have been handled very poorly over the last years and are a total mess now. This is frustrating for us IT pros.
@Alban1999, please check the twitter thread. I have brought same or similar points. They will not change it whatever it takes, this was a clear statement. It would be interesting what's happening in 3 years with the next Windows Server.
Thanks, I'll check this. And thanks for your efforts I really do appreciate, even if it failed in the end anyway.
I wish Microsoft would discuss this with MVP and other IT Pros first, then decide on it later for this kind of change. We got Tech community blogs, forums, UserVoice, those tools exist for a reason. This is too important to be decided through Twitter.

And I just realize WSUS are automatically ordered using alphabetical, which means this product will sit right next to Microsoft Edge, instead of Windows Server forever. Sigh.
I agree very much on your feedback. It was not decided on twitter, just published by Artem and I have picked up a discussion and thankfully he was also spending time to hear the feedback and to explain some internal point of views.

Yes the sorting does not make it easier I have added a screenshot to my original post, to make it clear, because our apprentices also failed to find it with the given new name, and also me took some time to find it.
I just have to say that feature-freezing the MMCs is a really bad idea. As can be seen in this post, but in many other areas. WAC is great *for some things* but it's also terribly slow and some operations that take seconds in the MMC take minutes in WAC. It's just not ready for primetime. It should not have been pushed as a final replacement product until it reach feature parity with the MMC consoles.
on the other hand, allowing MMC to develop (they are not error free and feature complete and do not support any new features of OSes) this said gap might even increase, what do you think about this @thx1200?

@kwester-ebbinghaus-business MS should not deploy a new management tool until its feature complete and a smooth experience.  Having no new features in MMC and then a terrible experience in WAC is terrible for users/admins because you split your time between two tools.


So they should co-develop them both until the new one is ready.

Beating a dead horse, but for the fun of it, new product categories within WSUS :
Server 2022 Hotpatch Category
Azure File Sync agent updates for Windows Server 2022

Guess some people at Microsoft are not aware that Microsoft Server Operating System 21H2 replaced Windows Server 2022 as a brand.


Hi Alban, I don't think this is the case, they replaced the brand.
Artem made it clear why
- Windows Server 2022
- Azure Stack HCI 21H2
had be included in the same product category.

As someone from outside the limitation seems to be that an update can only have one product category name, per update in the Update Catalog.

Means they would have had to add double the number of updates (with the same binaries) if they put it into Windows Server 2022 and Azure Stack HCI 21H2 into separate categories, what would have made sense for IT pros, as it would follow previous logic.

In the past the duplicate updates in the catalog were always the norm.
For example:

Windows 10 1809 SAC was placed in Windows 10 product category.
Windows Server 2019 LTSC was placed in the Windows Server 2019 product category.
same with downlevel OS like Windows Server 2012 and Windows 8 and so on. 

Except the metadata both updates were identical but needed to be maintained / uploaded both to the catalog. From what I see this worked fine. You could even install Windows Server 2012 updates to an "end of update" Windows 8.0, none of this would be supported, but just for the sake of demonstration purposes and to confirm the statement above.

I would not understand why this is a challenge though. Maybe they could use deduplication etc.
Personally believe saving bandwidth and improving the effectiveness of Delivery Optimization might have been reasons to merge the categories.

They also did and do this for Windows 10.
There is a Windows 10 product category for Updates from 1507-1809 releases
There is Windows 10 1903 and later product category for 1903 and later for 1903 through 21H2 releases. And all of this this repeats with Windows 11.

I have proposed once, that all updates that share the same binary and are as such are qualified for enablement packages, like 2004, 21H1, 21H2 should have their own update product category. This idea has not made it to production as Windows 11 shows. For some reasons, using WSUS, we will have the same limitations to only sync and automatically the OS that we really need for the customer enviroment.
This all led me to the point to use DO and do not download any updates to the WSUS server anymore, so it does not really matter if I auto-approve updates for products that are not needed. Secondly use AJtek WAM to keep WSUS database performant.

Why the hotpatch is not named "Windows Server 2022 Azure Edition" or "Windows Server Azure Edition hotpatch" or even "Windows Server 2022 Azure Edition hotpatch" is absolutely unclear and seems arbitrary. At least it ruins alphabetical sorting in the WSUS product list.

As you said beating a dead horse, if you / customers would not have to use WSUS or ConfigMgr on-premises, the product naming would be very irrelevant.

Changing it now seems to be a no-go, to avoid breaking the servicing - at least what I guess that is the reason.

The official name of the OS is still Windows Server 2022, Azure Stack HCI OS, Windows Server 2022 Azure Edition, even though these do not match in the naming scheme in the catalog, WSUS respectively.

@abbodi1406 @Aria Carley @Mary Hoffman @Cosmos Darwin 
please correct me if I am wrong with what I can only assume here from outside view.

previous post needed some edits on the same day to make points clearer why I am discussing this topic anyway and how it is important for WSUS users.

Hello, the "brand" thing was a joke :) Maybe not totally a joke, as we moved from "Windows Server" to "Microsoft Operating System" during setup.
That's OK, we are gonna live with it. I'm just curious about vNext however. Will it get a "Microsoft Server Operating System 25H2" category within WSUS ? Or "Windows Server 2025" ? Time will tell.

I found this article harder to comprehend than the changes to the window servers categories in WSUS. 

HI Karl,


Just having some fun, as explaining something to make it easer to understand from a decision by MS to make it more complicated is funny, and especially, since I can see your native tongue is not English, I should be congratulating you on such a good effort and not making fun.


I did find this statement hard to understand..  find it in the near?

"You would assume that due to the naming convention you might find it in the near of Microsoft Server 2022 Azure Edition as a seperate product category.