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

Alban1999 

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 AriaUpdated Mary Hoffman Cosmos_Darwin 
please correct me if I am wrong with what I can only assume here from outside view.