Anyone testing the waters with this yet.
I installed it today, no big surprises until I tried to activate it.
Have the KMS key but can’t get that key installed.
We use KMS, but store the keys in AD as is MS best practice. I think they call that VAMT.
My googling led me to this link that says I need a non existent KB5003478
That update doesn’t show up in our update history, wsus or the MS Update catalog.
Any ideas from the collective appreciated.
I’ve deployed it in the lab a couple of times, and just deployed it as a hyper-v host yesterday evening, but I haven’t worried about activation yet.
So, tl;dr: I’m interested in any responses you get too.
--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
ntsysadmin+...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ntsysadmin/612e6eea.1c69fb81.620d6.abef%40mx.google.com.
Haven’t tried this for WS2022 yet, but, the way I read that article 5003478, it’s an informational article and it doesn’t directly relate to any specific update KBnumber.
What I mean is “we’re saying that any/every update (because cumulative) released for WS2016/WS2019, after April 2021, will include the necessary code fixes”
If so, then these patches, released after that date, and every patch since then, include the code fix.
May 11, 2021—KB5003197 (OS Build 14393.4402) (microsoft.com)
May 11, 2021—KB5003171 (OS Build 17763.1935) (microsoft.com)
So if you’re updated as much as you can be, it should be ok/working?
What does “but can’t get that key installed.” look like?
Error message/code?
DonP
(stupid volume activation specialist for too many years 😉
From: Glen Johnson
Sent: Wednesday, 1 September 2021 4:03 AM
To: ntsys...@googlegroups.com
Subject: [ntsysadmin] Server 2022 Key management
Anyone testing the waters with this yet.
--
I’ll describe it as best as I can.
DCs are all 2016 fully patched up to and including August KB5005043
I open the VAMT console, check Active Directory based Activation.
Next, paste in the KMS key, check Enter as display name, enter Server2022andPrior
Next, Leave Activate online check, Commit, Pop up showing “This will add an Active Directory based activation object to the domain forest. Do you want to continue?
Click yes.
Then I get this error.

If I choose skip to configuration on the second screen, it shows the existing AD products.
Office 2016, Windows 10, Server 2019 and prior and Office 2019 Pro Plus.
I tried removing the Server 19 key just to see if that was causing the error, but no change, so I added it back.
Could it be the domain and/or forest functional level, both are 2012?
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/4ADADAF6-14BE-42AF-B267-EBA510C4FD1B%40hxcore.ol.
Are you using the key from Volume Licensing Center > Licenses > Relationship Summary > Product Keys tab?
It’s called “Windows Srv 2022 DataCtr/Std KMS”
I applied this successfully yesterday on a 2016 server with August patches.
Rob
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/6132101c.1c69fb81.79e86.8bdf%40mx.google.com.
Rob.
No, I used the key from the Downloads and Keys, located server 2022, expand keys, but I checked the path you suggest and the keys are the same in both places.
I was able to use the MAK key to successfully activate a 2022 server, but not the KMS key as shown below.
Thanks.
Glen.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/LO2P265MB5421BF86C5A97F39AD8ABA78F6CF9%40LO2P265MB5421.GBRP265.PROD.OUTLOOK.COM.
Okay, thanks, that error message clarifies nicely.
Nope it’s not the DFL or FFL nor Schemaversion or that stuff. (unless you’re stuck on WS2003 but I think that would block you from adding WS2016 as a DC?)
This sure looks to me that your server (where you’re trying to process the PKEY) is missing the needed SLC updated DLLs etc.
I used to see a lot of this back in the days when WS2012R2 was new, and it was always due to a missing windows update package (update the SLC DLLs and the xrms (PKEY recognition data).
If it was a lack of permissions in AD, you’d get a different error to this, and your test with removing/reading the older PKEY would have failed too.
You could try using the old-school slmgr.vbs method instead of the VAtools? (the VAtools are much easier to use though)
Check ADBA objects: cscript slmgr.vbs /ao-list
Check current server config: cscript slmgr.vbs /dlv
Install the new PKEY on this server: cscript slmgr.vbs /ipk <YOUR-HOST-PKEY-GOES-HERE>
Install the new PKEY as ADBA object: cscript slmgr.vbs /ad-activation-online <YOUR-HOST-PKEY-GOES-HERE> [name-of-the-AD-object-you-choose]
You might need to use VAMT (on a PC as a proxy) though, in case you have no access outbound from the DC to the cloud activation service..?
Review:
KMS Activation in Windows Server 2019 - Microsoft Tech Community
Activate using Active Directory-based activation (Windows 10) - Windows Deployment | Microsoft Docs
I recall an issue a long while back, that the VAtools used a different set of xrms and needed an update, but the script would succeed?
DonP
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/6132101c.1c69fb81.79e86.8bdf%40mx.google.com.
Don. Thanks for the hints.
The first two scrips come back as expected.
Tried the last one to add the key to AD, same error.
Tried running windows update against MS and it says the server is up-to-date.
I played a bit with the VAMT, but ran into a problem and haven’t had time to re-visit.
I installed SQL express 2019 and then the VAMT.
When I run VAMT, it wants to create a new database so I let it.
It says it created the database and SQL management tools confirms the database is there.
But when VAMT tries to use the DB, it errors out with this.
The specified database is not a valid VAMT database.
So just for fun, I tried the last script on a second domain controller and success.
So it does look that that first DC has some missing or outdated files.
But for now the problem is solved.
And I am planning to demote and reload the first DC sometime in the not to distant future as it is running on 4 spinning drives in raid-6 and I have 4 shiny new SSDs to replace them.
I know, not really needed for a DC, but I have them, so why not. 😉
Thanks again for sharing your knowledge.
Glen.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/A8ACB641-F2D2-4A94-A3F1-DD67D3936976%40hxcore.ol.
Ah. Sorry that didn’t help, but yes, looks like you found the culprit (and it wasn’t anything you were doing wrong, so, well done you! ;)
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/61377d21.1c69fb81.9b171.26a6%40mx.google.com.
Yes we are good, but one correction. The DC that wouldn’t take the 2022 key is 2016, the one that did is 2019, to I’m guessing that the source of my problem and the solution too. Use the newest DC.
Thanks to all that took time to reply.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/23985843-1876-4315-A321-B5FEF926E97F%40hxcore.ol.