Office 16, retail(grace) channel product has non-kms client channel. skipped
- #OFFICE 16, RETAIL(GRACE) CHANNEL PRODUCT HAS NON KMS CLIENT CHANNEL. SKIPPED SOFTWARE#
- #OFFICE 16, RETAIL(GRACE) CHANNEL PRODUCT HAS NON KMS CLIENT CHANNEL. SKIPPED LICENSE#
- #OFFICE 16, RETAIL(GRACE) CHANNEL PRODUCT HAS NON KMS CLIENT CHANNEL. SKIPPED WINDOWS#
Requests with License Status License expired or Hardware out of tolerance: 76 Requests with License Status Initial grace period: 140 Requests with License Status Licensed: 18065 Requests with License Status Unlicensed: 0
Key Management Service cumulative requests received from clients Key Management Service is enabled on this machine
#OFFICE 16, RETAIL(GRACE) CHANNEL PRODUCT HAS NON KMS CLIENT CHANNEL. SKIPPED WINDOWS#
Name: Windows Server(R), ServerDatacenter editionĭescription: Windows Operating System - Windows Server(R), VOLUME_KMS_2012-R2 channelĪctivation ID: abcd1234-b123-ffff-9944-aabbccddeeffĪpplication ID: 4321dcba-b123-ffff-9944-aabbccddeeff The reason I overlooked this problem in step 3 of my troubleshooting above was that the KMS server output for that channel looked valid, but had a few problem indicators that I missed. It turns out that the KMS server was in fact missing the proper key.
So I’ve got a KMS server that looks just fine that my new servers are complaining about. Which pops up a helpful “An error has occurred” window, with an optional details pane that indeed reports the exact text of the error message that we started with. You can actually see the text of the slui.exe errors with a command like this, run on a Windows machine with a GUI (i.e., not Core): slui.exe 0x2a 0xC004F074 License Activation (slui.exe) failed with the following error code: I found this error in the Windows Application log: Source: Microsoft-Windows-Security-SPP So then I refer back to the application event log, hoping against hope that the “additional information” wasn’t some weird circular reference.
#OFFICE 16, RETAIL(GRACE) CHANNEL PRODUCT HAS NON KMS CLIENT CHANNEL. SKIPPED SOFTWARE#
Ensure the Software Protection Service (sppsvc) is in fact running on the KMS server.Ensure the domain _VLMCS DNS records are correct.Then, I started to dive into the rabbit-hole that is KMS troubleshooting: The first thing I do, naturally, was just to make sure my KMS server was in fact reachable from this machine. Please see the Application Event Log for additional information. No Key Management Service (KMS) could be contacted. The Software Protection Service reported that the computer could not be activated. I logged into one of the machines that was reporting activation errors and ran the trusty activation command: slmgr /ato Their two most recently deployed servers were reporting activation errors. In December, he reported that his newest servers weren’t activating properly. Because no one complained in June, I had assumed that someone had activated the proper key on the KMS server to support the new version. The KMS server had previously been patched to support Server 20 R2 KMS clients. In June of last year, they started deploying Windows Server 2012 R2 servers. One of our clients has an environment running KMS on Windows Server 2008 R2. Given that we still manage some Windows 2003 servers (if we must), I think it’s fair to assume we’ll still be using KMS well into the next decade.
It is of course on the way out, to be replaced by Active Directory-based Activation in Server 2012, but KMS will stick around until all of our Server 2008 R2 machines are out of production.