When was the last time you had to think about activating Windows? Yea, it’s been awhile for me to. Three years ago I helped write a server provisioning process to deploy a Windows server to any of our datacenter locations in a fully-automated way. User submits a form with a few basic inputs and 10 or so minutes later they have a server. As with nearly any modern process, it used the native KMS Client Key, activating Windows upon Domain Join. It just works. The problem is, when things get automated and “just work”, people forget how it all works under the hood.
So yesterday I get pinged from an engineer who says two servers in his cluster show as requiring activation. Definitely odd. I say if they’re brand new servers, nuke and redeploy. The phrase “cattle, not pets” certainly applies with Servers (or should, anyway). If it’s an existing server that’s been fine and is suddenly not activated, check a few things and reach out to the right folk. Well, some time passed and the engineer came back saying none of the teams I directed him to could help him. In addition, he’s trying to figure out how to open a ticket with Microsoft. Yikes. “Alright”, I say, “Give me a server name and I’ll poke.”
First thing I do in this situation is check the time – are we sync’d or not. Strange things happen when servers aren’t synchronized with domain controller time. The fact I could even log in (to a server I’ve not logged in before) should have told me the time was good, but this was #NightShift so….
I’ve at least validated that indeed, the server needs activating.
The next step in any troubleshooting process involving a Windows Server is to check the event logs. Which? Any. But I start with the Application Log. It’s unfortunate that many times people either don’t think to look in the Event Logs, or go there and don’t know what to do with the information. Some day I’ll write a better post about Event Logs….
First thing I like to do is filter the event logs. Give me just the bad stuff, like this:
Next I take a look at what’s there, and sure enough we get a few random errors relating to Windows Activation. In this particular case, they don’t really tell me anything useful that I don’t already know. This one was particularly useless, but it confirmed that there’s definitely a problem of some kind:
Always, always check the Event Log. You never know what you’ll find!
The final step I take is to dig up the command line utility for checking licensing status. I knew what the command was, but it’d been a very long time since I had to use it. Our good friend slmgr.vbs
Microsoft has a couple really good documents for licensing and the use of the utility. The first is Guidelines for Troubleshooting KMS, and the second is basically the command line syntax and usage for the slmgr.vbs utility. With a reminder of the syntax I was looking for, I ran a side-by-side comparison between the broken server (to the left of the image below) and a known-good server (to the right).
Yep, that’s broken alright.
So at this point, I provided the engineer with all of the above data including the links. I don’t know what happened to cause the license to be changed, but the fix should be easy enough. If it were my server, I’d locate the publicly available Windows Server KMS Client key appropriate with the version of Windows Server being used, install that key, and force an activation attempt. It’s all done via the slmgr.vbs utility.
Check your logs frequently, don’t ignore the basics!
Nice write up Olson. Last week I had a vendor ask why their Citrix provisioning at a site took a long time to RDP. We’re talking 2 seconds, which at first they thought was a VM performance issue. 4 core w/ 16GB, hardly software installed and only during login process through RDP. I checked event viewer and notice that a security tool was reinstalling twice. These events occur each time I log off and on. I told them that is probably the root cause on pre-logon with RDP.