Quick Download: https://github.com/thekevinholman/Microsoft.KMS
Many customers still use KMS activation for on-prem deployments. This management pack will discover and monitor your KMS servers.
This MP supports KMS on Windows Server 2012 and later
Discovers and Monitors:
- KMS Servers
Key Monitoring Scenarios:
- KMS Service
- Idle Minutes Count
- Low Activation Count
- Initialization Failures
- DNS Failures
Changes from the original Microsoft KMS MP:
- Added discovery support out of the box for KMS on WS2016 and 2019 servers
- Removed all manual reset monitors and switched to rules
- Changed class design so source and path on alerts will contain the FQDN of the computer.
- Renamed and reduced views to make it more useable
- Changed discoveries and monitoring to more reasonable frequencies
- Added number of samples (matchcount) to Service Monitor
- Renamed and simplified MP Element IDs
- Added basic logging to discovery scripts.
- Note: This MP will still create config churn as I did not change the design where the MP classes discover properties that will change often. That will take a deeper redesign.
Troubleshooting:
- The primary method of discovery is to search for a registry value “KeyManagementServiceListeningPort” in the following registry key: “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform” If your KMS is not getting discovered – you can add that registry value. The default is REG_SZ with “1688”
19 Comments
Blake Mengotto November 21, 2022 at 9:10 pm
Reply
Kevin, did you make this? What was the motivation? I have the old native MP running and it is one of the largest discovery pigs of all management packs, and that is with aggressive discovery tuning.
Kevin Holman Post author November 21, 2022 at 9:22 pm
Reply
I did. Because I saw that MSFT pulled the original. And it was really poorly written anyway. I didn’t fix the config churn but changed some of how it worked. Made the defaults better. Deleted all the really bad stuff. Made it discover properly on 2012 and later (I think). Made the service monitor better. Changed anything manual reset monitor to a rule and deleted those awful monitors that should have never been invented. Renamed stuff to make sense and got rid of stuff that didn’t. Once you peel back the onion, you realize there wasn’t much in there to begin with. I’d love feedback\recommendations.
Dwayne February 28, 2023 at 11:32 pm
Reply
I did something similar when I built our last KMS box, as the old MP… well your right wasn’t very good and the discovery failed on anything that actually could do the kms role these days
I do bet as always your solution is better than mine. So will have a looksee
i ‘reassembled’ the MP, so to speak, from what i could pull from the system center wiki…
- See AlsoHow to create a Key Management Services (KMS) activation host in Windows ServerUsing KMS Manually to Activate Software | IT@CornellTroubleshoot Windows activation error codes - Windows ServerFortiguard
Sandro November 24, 2022 at 1:04 am
Reply
this is great, many thanks kevin!
hmmm actually the discovery for our KMS (windows server 2019) does not work (over a day now since installed the MP -> discovery-workflow is running 1 time per day, right?)Kevin Holman Post author November 24, 2022 at 9:50 am
Reply
Yes once a day. Restart the Microsoft Monitoring service on the agent to make discovery run within 5 minutes. I tested on 2019 and it works here.
The discovery is based on the existence of ONE of these registry values present in this key:
SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform\
KeyManagementServiceVersion
KeyManagementServicePort
KeyManagementServiceListeningPortCheck the registry and see if one of those exist.
Sandro November 25, 2022 at 3:20 am
Reply
ok, found the reg-keys unter the following path:
Computer\HKEY_USERS\S-1-5-20\Software\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform\55c92734-d682-4d71-983e-d6ec3f16059f\de32eafd-aaee-4662-9444-c1befb41bde2
not quite sure, if this is a normal behaviour or not (we did some inplace-upgrades in the past with our KMS?)
Sandro November 25, 2022 at 3:22 am
Reply
ignore my last post, wrong reg-keys. but did not find them on our envirnoment 🙁
Martin November 29, 2022 at 1:59 am
Reply
Hi Kevin!
I have a question about discovery. We have workstation servers (outside the domain) that we monitor.
I noticed that they have the registry value: “KeyManagementServicePort”. Dont ask me why. I guess they have been configured to use KMS in a different way than we traditional do for the domain servers.My question is if it is possible to override KeyManagementServicePort in the discovery?
Right now the Workstations servers shows up as KeyManagement Servers under the KMS “Server Role State” and in the “KMS Version” column the portnumber shows up.
Kevin Holman Post author November 29, 2022 at 8:29 am
Reply
Bummer! Ok, I will have to fix that. Let me look into it
Kevin Holman Post author November 29, 2022 at 12:43 pm
Reply
Ok, fixed. Your KMS servers MUST have “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform\KeyManagementServiceListeningPort” registry value now.
Martin November 30, 2022 at 1:23 am
Yes we have the registry value. Now it works perfect. Good work Kevin!
Saiyad Rahim November 30, 2022 at 9:42 pm
Reply
Hi Kevin,
I haven’t seen (original) MP and wondered why there was no MP for KMS.
Does this have ability to Alert on Servers in the environment that are/have not Activated based on a time period?Dwayne February 28, 2023 at 11:37 pm
Reply
should just be an event log monitor on the target windows server(s) to check for the activation services use the ‘missing event detection’
just find a valid activation event in the event logs and set that up to alert if not seen in your desired timeframe.
alerting on fails could trigger if activation is attempted during patching of your KMS box.
Joe January 20, 2023 at 10:25 am
Reply
Hi Kevin
Basic question how do I actually run this tool on a sever?
thanks
Martin March 22, 2023 at 9:40 am
Reply
Hi Kevin!
We get the alert “KMS Idle Time Monitor Alert” when we think we should not.
We have overrided the Threshold (minutes) from 720 minutes to 1440, that is 24 hours.
When we checking the KMS server for the 12290 event we can see that it´s only being idle for 4 hours.So we think it is strange that we get thoose alerts.
Are we missing anything or do you have any thoughts about it?Manuel May 1, 2023 at 7:17 am
Reply
We’re experiencing exactly the same problem. Did the same overrides and the Alert keeps triggering even tough the KMS (Event 12290) was never idle for more than 6 hours.
Did you have any luck fixing it thus far, Martin?
Martin May 17, 2023 at 2:04 pm
Reply
Hi Manuel
No were unfortunately still stuck with that issue…
AndresP June 29, 2023 at 1:07 am
Reply
On little remark – discovered that removing Volume Activation Service role didnt remove regkey KeyManagementServiceListeningPort – so it was still discovered as KMS server. Not directly related to MP – but may be help people who discover KMS in unexpected servers.
Martin September 12, 2023 at 6:54 am
Reply
Now i think i´ve finally figured out why we get the alert “KMS Idle Time Monitor Alert”.
Under “Product State” i found that they have left “one old product” that is not actual anymore. So idle time for this product, causes the “KMS Idle Time Monitor Alert”.
