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.
- 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”
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.
I did. Because I saw that MSFT pulled the original. And it sucked anyway. I didn’t fix the config churn but changed some of how it worked. Made the defaults better. Deleted all the dumb 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 stupid 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.
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…
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?)
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:
Check the registry and see if one of those exist.
ok, found the reg-keys unter the following path:
not quite sure, if this is a normal behaviour or not (we did some inplace-upgrades in the past with our KMS?)
ignore my last post, wrong reg-keys. but did not find them on our envirnoment 🙁
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.
Bummer! Ok, I will have to fix that. Let me look into it
Ok, fixed. Your KMS servers MUST have “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform\KeyManagementServiceListeningPort” registry value now.
Yes we have the registry value. Now it works perfect. Good work 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?
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.
Basic question how do I actually run this tool on a sever?
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?