At a client recently installing Virtual Machine Manager (VMM) we ran into a small annoyance. Because of the many Hyper-V patches available, not all of the Hyper-V systems that we wanted to manage with VMM matched in patch level and thus version level; the complete list of patches is available at: http://technet.microsoft.com/en-us/library/dd430893.aspx. The real annoyance wasn’t the patches themselves, it was figuring out the version each Hyper-V instance was at. I couldn’t find a good place in the Hyper-V GUI to tell me so it was off to my favorite search engine. From there I determined that the authoritative version number for Hyper-V is the file version of vmms.exe located in %systemroot%\system32. With that and a little WMI “magic”, I came up with thissinle command to run from the command-line:
wmic /node:"vmh-c01", "vmh-c02", "vmh-c03", "vmh-c04" datafile where name="c:\\windows\\system32\\vmms.exe" get CSName, version
This single line queried the file version of the vmms.exe executable on all four Hyper-V nodes using WMI and quickly returned the result. One gotcha was the syntax of the /node option for WMIC; it took me several minutes to get that perfect because initially, without each system name individually quoted, WMIC saw the dashes in the system names as additional, non-valid parameters resulting in an “Invalid Global Switch” error. Lumping them all together in a single set of quotes resulted in the same error.
After many hours, the completely rewritten OSDAppChooser is ready for beta release. There have been a lot of changes but the purpose remains the same: to provide an interactive way to choose applications for installation during an OSD task sequence. Everything is posted on CodePlex: http://osdappchooser.codeplex.com. Please post any comments, requests, feedback, etc. on the discussion page there. Also, make sure you read through the documentation: there are quite a few new things to be aware of.
As I've described in the previous two installments, the KMS is a pretty simple and straight-forward service. When you think about, this makes sense because the only thing that it does is activate clients.
So how do you track what the KMS is doing and identify any issues? The first way is a vbscript located in %systemroot%\system32 named slmgr.vbs. This little script is the main way to interact with the KMS and the activation client. Running this script with –dli as an option will list the activation information for the local system; if the local system is a KMS, then will also list KMS related data including the number of clients that it has activated in total. Remember that this number is important because Vista clients won’t activate unless the KMS has already activated at least 25 clients and Server 2008 clients won’t activate unless 5 other systems have already been activated. The following screenshot shows the output of slmgr –dli on a KMS:
Of note are the following:
VOLUME_KMS_C_channel – The type of license key that was used to activate the system. For a KMS, this also indicates what type of clients it can activate, see Windows Activation – The KMS for details.
License Status – Indicates whether the local system has been activate or not.
Current Count – The number of client systems already activated.
DNS publishing enabled – Indicates whether this KMS system is publishing its SRV record in DNS.
slmgr –dlv displays the same basic information with some extra thrown in. This in shown in the next screenshot:
The two above commands also work on clients and show the same information minus the KMS specific items.
Both the KMS server and client add event log entries to track activations and activation requests. For the KMS server, there is a dedicated log view called Key Management Service located under Application and Services LOGs in the Event Viewer:
The KMS will add an entry to this log every time it receives a request for activation. They will look like the following:
The first field in the info section (marked by the red arrow), is the success/failure code; 0x0 is success.
For clients, two events will be placed into the standard Application Event Log with EventIDs of 12288 and 12289 and provider name of Microsoft-Windows-Security-Licensing-SLC. 12288 indicates a client request and which KMS server the request is being sent to (blacked out):
12289 indicates a reply from the KMS, the success/failure code (marked by the red arrow below) is the first field in the info section and is the same code listed by the event entry on the server side:
There are a handful of common error codes, the full list is available in the Volume Activation 2.0 Operations Guide in Appendix 2.
That’s the bulk of it. Like I said at the start, its a simple service that does only one thing: activate clients.