Server 2022 KMS host key bug; Can't activate Win10 Enterprise LTSB/LTSC

[ajc196]

We recently dropped our new Server 2022 KMS host key onto our KMS server. After the necessary update to accept the 2022 key and activating the new 2022 host key, we were able to activate our most common OS types in a quick test afterward -- Win10 Education 21H1, Server 2022, Server 2019, etc.

In the next few days, and even more today, we've been getting reports that Win10 Enterprise LTSB/LTSC  across some signage devices and laboratory machines stopped activating. Sure enough, I could reproduce the issue from a known good network.

Just this morning I spun up entirely fresh VMs and verified all the above is still reproducible with the following results:

Windows Server 2022 = Successfully activated

Windows Server 2019 = Successfully activated

Windows Server 2016 = Successfully activated

Windows 10 Education 21H1 = Successfully activated

Windows 10 Enterprise LTSC 2021 = FAILED ACTIVATION (0xC004F074: License server reported that the computer could not be activated.)

Windows 10 Enterprise LTSC 2019 = FAILED ACTIVATION (0xC004F074: License server reported that the computer could not be activated.)

Windows 10 Enterprise 2016 LTSB = FAILED ACTIVATION (0xC004F074: License server reported that the computer could not be activated.)

Windows 10 Enterprise 2015 LTSB = Successfully activated (odd, after the previous two)

Windows 8.1 Enterprise = Successfully activated

Windows 7 Enterprise = Successfully activated

Anyone else seeing this or could possibly test and confirm? I feel like this **has** to be a bug with 2022 host keys, but it's so new that I can't find anyone else in the same boat. I have a Premier ticket open for this.

[#2]

Had a feeling it wasn't going to be fixed. Just the way MS is.

[#3]

Dear @Mary Hoffman may I ask you to check with the team, if the fix for the Windows Server 2022 is on the way? From what I read it is not fixed for Windows Server 2022 but only Windows Server 2019, where is was also a known issue. For Windows Server 2022 it does not seem to be a known issue.

• Addresses a known issue that affects versions of Windows Server that are in use as a Key Management Services (KMS) host. Client devices running Windows 10 Enterprise LTSC 2019 might not activate. This issue only occurs when using a new Customer Support Volume License Key (CSVLK) and after installing updates released April 22, 2021 or later.

source: January 25, 2022—KB5009616 (OS Build 17763.2510) Preview (microsoft.com)

compare with: January 25, 2022—KB5009608 (OS Build 20348.502) Preview (microsoft.com)

[#4]

@kwester-ebbinghaus-business 

A fully updated Windows Server 2022 does not recognize the KMS key. Knows it as Volume_KMS_WS19 and does not activate clients.

[#5]

I understand the issue and problems it brings. That's why I asked Mary from the Windows Server team if she has more insights for us, when this issue will be triage and fixed on Windows Server 2022. As said it's not on the known issues list. The only workaround is to use ADBA, which doesn't fit for all scenarios but is better than KMS for most.

[#6]

Just to clarify, is this issue fixed for ADBA for 2022 KMS key? Or running on server 2019 for 2022 KMS key?

[#7]

@Carlin Zotz both should work

- 2019 KMS Server with the 2022 CSVLK Key (with the patch).

- ADBA with the 2022 CSVLK Key (without any patch)

[#8]

KB5009616 did not fix the issue for us on sever 2019 :( Please keep us posted on updates. Thanks

[#9]

+1 more vote and confirmation. The Feb patches for Server 2019 KMS server do not fix the issue with activating 2016 LTSB and 2019 LTSC Windows 10 clients.

[#10]

I wonder if someone just jumped the gun for the changelog for the regular February updates. Since waaaay last year (this issue has been going on for months), Support had told me that the fix was coming in *late* February for Server 2019 hosts, which I interpreted to be the "C" release updates. i.e. not February's "B" releases on Patch Tuesday.

[#11]

The KMS down-level keys were serviced for Windows Server 2022 is 2022.01 C release, so this should be working once the 1C update (or 2B security update) is applied. If the issue still occurs after applying the update, please provide logs.

[#12]

What do you mean exactly? KB5010421 has to be applied?
Just tested, does not work.

[#13]

Did you try to reactivate the CSVLK after installing the updates?
because the KMS Host Server licenses are indeed updated with 2022.01 C release to support LTSB 2016 / LTSC 2019 clients

[#14]

Indeed.... WTF.
After Installing KB5010421, reboot and slmgr /ato Activation is working!

[#15]

I can confirm that after installing KB5010421, rebooting and slmgr /ato, LTSCB/LTSC Clients can now activate.

[#16]

If you have many devices to manage I would still plea to use VAMT for KMS or ADBA Compliance, Key Management and activation. Saves you lot of work with slmgr.

[#17]

Thank you for your useful and exact reply, It seems to be working in our environment.

[#18]

OK, So our KMS server is running Server 2019, so the equivalent update for that OS is KB5010427?

Has anyone tried that and got it working with the 2022KMS Host key?

[#19]

So do we put the fix on the kms server or client? And do we need to get a new KMS key or will the KMS key installed on the KMS server work? Kind of confused on the whole 2022.01.. Will the key be updated to 2022.01 or do we need to get a newer key. I have KMS working on a 2019 server. And every think but Win10 LSTC works ever Win11. Had to go with a 2019 server because when I installed the 2022 key on a 2022 kms server it only recognized it as 2019 and below. Not a 2022 key. But before I screw around with KB5010427 on the server and screw up campus I'd like a little clarification.

[#20]

Just installed KB5010427 on our KMS host (Server 2019) and re-inserted our 2022 host key. We are now back to normal. 2016 LTSB, LTSC 2019, and LTSC 2021 are all activating fine. The few Server 2022 clients I had to put on MAK keys, I put back on KMS and they activated fine as well.

On one hand I'm happy this is fixed; On the other hand, this has been an ongoing bug since August. Seems like it was not highly prioritized, and we never did get a pre-release workaround/fix last year as offered by Premier. :\

[#21]

Same here. Just applied B5010427 on our KMS host (Server 2019) and everything's working. Clearly they must have been off a month on their documentation, or forgot to commit that code. Either way, a surprising mess. Maybe they have too many OSs and code branches in flight to keep track of.