Countless Horizon View and VDI administrators probably woke up on Tuesday, January 8th, 2019 thinking “Hey it’s Taco Tuesday!”  What they didn’t know was Microsoft had other plans for them.  Reddit and a variety of tech forums have been full of posts from admins whose users are getting the Windows is not genuine dialog boxes on Windows 7 VDI desktops.  It appears Microsoft has changed the way their KMS servers respond to certain activation requests.  Thankfully there’s a reported fix and as my first post of 2019, I wanted to share it with the masses.  Lets’ take a look at what’s happening and then dive into how to fix the issue!

What’s happening and why?

The issue apparently started Tuesday January 8th, 2019 and is intermittently causing some Windows 7 desktops that are activated by KMS to display the Windows is not genuine dialog when users login. This appears to be mainly on VDI desktops but some have reported physical desktops are having the issue as well. According to reports, the logs show that previous activation requests were going to the local KMS server and to Microsoft’s Activation servers online. If you are familiar with KMS you’d know that the local KMS server is the only thing that should be talking to Microsoft to get Activation. The Windows 7 desktop should only be talking to your local KMS server to get its’ activation. 

The culprit appears to be an ancient Windows 7 update called the Update for Windows Activation Technologies KB971033. As I recall this update has caused issues pretty much ever since it was released and it’s decided to come back for one more round of fun.  The update is automatically installed on Windows 7 through WindowsUpdate. So you likely have it installed unless you’ve removed it or haven’t updated. The KB971033 article has a nice blurb towards the bottom that explains if you’re an Enterprise customer using KMS or MAK key volume activation that you should NOT have the update installed on your reference image.  One would think if Microsoft was recommending to not install the update in Enterprise environments that they wouldn’t force it to install through WindowsUpdate on Windows 7 Enterprise, but I digress.

The KB971033 update causes your Windows 7 desktop to have two activation mechanisms. The first one is the default baked into Windows that is activating properly through your local KMS server. The second is part of the Windows Activation Technologies update and it goes out to Microsoft’s Activation servers through a scheduled task. The Windows 7 desktop would activate against the local KMS server successfully and then Windows Activation Technologies would attempt to activate to Microsoft’s Activation servers and could potentially override the results of the local KMS server.

Until this week this wasn’t causing an issue because the response from Microsoft’s servers allowed the desktops to work using the local KMS activation. As of Tuesday some time Microsoft has changed the way their Activation servers respond to the request with an error stating that the key being used is blacklisted.  If I had to guess, Microsoft probably blacklisted the GVLK (Generic Volume License Keys) keys from their online activation servers, but who knows.

How do I fix this?

I can’t take credit for the fix at all. It’s been posted all over in various forms with a few posts giving Microsoft Premier Support credit for it. As I said above my goal here is to summarize the issue and get it out for consumption. It consists of removing the update, deleting components related to it and then reactivating your image. The following procedure should be done on your reference/base/gold/master image.

• Uninstall the KB971033 update
• Reboot the Windows 7 desktop
• Open a Command Prompt as Administrator and type the following:

net stop sppsvc
del %windir%\system32\7B296FB0-376B-497e-B012-9C450E1B7327-5P-0.C7483456-A289-439d-8115-601632D005A0 /ah
del %windir%\system32\7B296FB0-376B-497e-B012-9C450E1B7327-5P-1.C7483456-A289-439d-8115-601632D005A0 /ah
del %windir%\ServiceProfiles\NetworkService\AppData\Roaming\Microsoft\SoftwareProtectionPlatform\tokens.dat
del %windir%\ServiceProfiles\NetworkService\AppData\Roaming\Microsoft\SoftwareProtectionPlatform\cache\cache.dat
net start sppsvc
slmgr /ipk 33PXH-7Y6KF-2VJC9-XBBR8-HVTHH
slmgr /ato

Activation should be successful at this point and after a reboot the issue should be completely resolved.  Note: You might need to change the GVLK key that’s used in the second to last command if you’re not using Windows 7 Enterprise.

In Conclusion

I heard about this from several customers who did the procedure listed above upon my suggestion and it has resolved the issues entirely in multiple environments.  You’ll have to thank the internet and possibly Microsoft Premier Support for the resolution because as I said before, they came up with all this information about the problem, I just summarized it here.  Happy New Year and thanks for reading!