Tag: licensing

I encountered a weird problem with our Key Management Server (KMS) and client licensing recently

. The client I’m working with has 3 domains whereas there is a full two way trust between two of them, and limited trust towards the third
.

For some reason our Vista client (yes, Vista) we’re trying to update the license towards a KMS service on a domain controller in the third domain with limited trust. It also seems KMS has been deactivated on this server, but that wasn’t the challenge.

To update the KMS server address you need to run the Visual Basic (VB) script c:windowssystem32slmgr.vbs
. You can add argument to view the current configuration (-dli), manually set the KMS server (-skms) or do an autodiscover of the KMS server address (-ato)

.

In this case I ran the following command to see the current config:

I saw that the KMS server was not the one I expected for clients in this domain, so I ran this command to do an auto discover:

This generated an error:
Error code and message: 0xC004F039 The computer could not be activated. The Key Management Service could not be reached.

The cause for this error in our case was that the Vista client tried to update the license towards the last server it updated against. There is no error handling routine in slmgr.vbs that tells the client to do an auto discover of possible KMS servers elsewhere if it fails towards the server it last updated against.

To resolve this I had to clear the name of the KMS server the client already knew in order to force it to discover the actual KMS server on the intranet. I ran the following command to clear the name and run the auto discover:

 

NB. If this had failed, there would have been one last solution. You can update the name of the KMS server manually, thus bypassing the entire auto discovery and eliminating that as an error source. This requires you to know the name and port (usually port 1688) of the KMS server, and is done with the “-skms” switch like this: