Virtually Jason

 I was helping a customer resolve an issue with their KMS server recently and we decided that we'd like to get a look at which systems were actually using it, instead of just looking at the total number of systems as displayed by slmgr /dlv.  I couldn't find any slmgr switches that looked like they'd generate a report with this data, but my customer pointed out that we could find it in the event logs (under the Key Management Service grouping), but that it'd be a pain to go through all of the events and pull out the client names.  Well, you can probably guess where this is going - I put together a quick script to do exactly that! This is a really quick and dirty script; I built it to run on the KMS server and generate a table with the client ID in one column and a list of client computer names in the other.  Why is it a list of client computer names?  Well, this particular customer is running a VDI environment and there can be a bit of a problem with KMS and Ins...

This is probably going to be a relatively short one.  Here we are, 4 years after the initial release of Server 2008.  4 years after the initial implementation of KMS licensing… and I’m still coming across all sorts of confusion about how it works and how to use it.  I’m tired of seeing unintentional rogue KMS servers pop up on client networks, and so I’m going to rehash what many other people have already covered: how KMS licensing differs from Volume License Keys.  They are not at all the same, and if you try to use a KMS license key the way you would have used a VLK, your environment is going to get messed up. First, here’s some supposition about why the change happened.  When someone’s VLK leaked into the wild, it was basically a gravy train for every pirate who knew how to use google.  Since, by its very nature, a VLK was designed to allow many systems to activate, it meant that many pirate systems would be activated.  At best, Microsoft could k...