Sep 09 2021 01:49 AM - edited Feb 03 2022 10:36 AM
Sep 09 2021 01:49 AM - edited Feb 03 2022 10:36 AM
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 techcommunity.microsoft.com.
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
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
Sep 10 2021 02:51 AM - edited Sep 10 2021 03:00 AMSolution
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.
Oct 07 2021 06:09 AM
Oct 08 2021 03:13 AM
Oct 08 2021 03:19 AM - edited Oct 08 2021 03:30 AM
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?
Oct 08 2021 03:44 AM
Oct 08 2021 05:47 AM
Oct 08 2021 06:20 AM
Oct 08 2021 12:32 PM
Dec 01 2021 08:53 PM
Dec 02 2021 05:09 AM
Dec 02 2021 06:33 AM
@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.
Jan 27 2022 06:42 AM
Feb 03 2022 10:12 AM - edited Feb 03 2022 10:30 AM
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.
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.
Feb 03 2022 10:31 AM
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.
Feb 07 2022 02:04 AM
May 22 2022 07:27 PM
I found this article harder to comprehend than the changes to the window servers categories in WSUS.
May 22 2022 11:13 PM
May 22 2022 11:29 PM - edited May 22 2022 11:30 PM
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.