No KMS Key in the VLSC for Windows 10 for OPEN License

With the release of Windows 10, many IT workers are beginning to look into it and perhaps test it for use in their organizations.  When the time comes to set up KMS activation of the new OS however, those IT staff using Microsoft's OPEN Licensing may find that something is missing...

When I logged in to the Volume License Service Center recently to look up the KMS activation key for Windows 10 Enterprise, I was surprised to find that only Multiple Activation Keys (MAK) were listed.  Searching online, I came across this blog post from someone who ended up calling Volume Licensing support to get his KMS key, but with no explaination as to why.  After digging around a bit, I happened to come across an entry in the VLSC FAQ which explains the missing key.  

If you can't read that, it says:
I am an Open Customer and do not see my KMS (Key Management Service) key displayed on VLSC. How can I get it? 
KMS keys are no longer pre-assigned to Open agreements as use of MAK (Multiple Activation Key) keys is the preferred method for activation. 
If you are an Open Customer and need a KMS key, please request one by either calling the PA Call Center or emailing KMSADD with your business need.
For whatever reason, Microsoft is no longer generating KMS keys automatically for customers using Open licensing.  MAK keys are now considered "the preferred method for activation" and will be the only keys listed in VLSC for OPEN customers by default.  OPEN customers can still receive a KMS key, but must call or email the VL support center to have a key generated.

If you are an OPEN license customer in need of a KMS key, just send an email to kmsadd@microsoft.com to request the a key and they should be able to generate one and add it to your account.

Comments

Post a Comment

Popular posts from this blog

Windows 10 Credential Guard breaks WiFi

Recently, I ran into an issue with computers running windows 10 that would not connect to our WPA2-Enterprise encrypted wifi network.  When it failed to connect, there was no indication of why, only the message "Can't connect to this network."  The computers were able to connect to unencrypted networks and networks using a Pre-shared key for WPA encryption without issue. Checking the event logs on the RADIUS server to see why the comptuer failed to connect, there was no log entry for a connection attempt from the affected system.  The WLAN-Auto-Config log on the client listed a couple of errors, including Event ID 11006 and 12013, but other than showing that the failure reason was "Explicit EAP failure received", they didn't give much to go on: Log Name:      Microsoft-Windows-WLAN-AutoConfig/Operational Source:        Microsoft-Windows-WLAN-AutoConfig Date:          8/15/2016 1:11:20 PM Event ID:      11006 Task Category: MsmSecurity Level:         Err
Read more

Mystery Solved: Bitlocker is enabled, but Intune shows the computer as non-compliant for Require Bitlocker

For some time, I have struggled to understand why Intune reports some computers as non-compliant with the "Require Bitlocker" setting, even though Bitlocker is enabled and working on the computer.  In my searches for an explanation, I found the same question asked by many others, but never an answer.  Until today. I accidentally stumbled across this article from Microsoft's Rob Lane , which explains how the Require Bitlocker setting is evaluated and why it might seem to incorrectly report a non-compliant state.  I encourage you to check out that article for full details.  I'll just summarize here the part that suddenly made this bitlocker compliance issue make sense to me. The "Require Bitlocker" setting in Intune relies on the Device Health Attestation (DHA) service in Windows 10 to report the state of Bitlocker encryption on the computer.  If Bitlocker protection is disabled or suspended, DHA will report that the computer is non-compliant with this
Read more

Data Sharing Service crashes on Windows Server 2016 - Event ID 7023

Image
While troubleshooting an issue recently on a Windows Server 2016 system, I noticed errors on the System event log about the Data Sharing Service crashing. The Data Sharing Service service terminated with the following error: %%3239247874 Searching online for more information about this service and why it might be failing, I came across a lot of people describing similar problems, but the only explanation and solution I found came from this December  blog post by Microsoft Japan .    Google translate did a great job making the post understandable to me, but since the information doesn't seem to have been widely publicized I thought I'd share it here to help get the word out. The Data Sharing Service fails due to a resource conflict with another service included in Server 2016, the User Access Logging Service.  Either one of these services alone will run without issue, but if one is already running and you try to start the other, it will fail. According to an update
Read more