In this post we are going to look at all the crucial components of a KMS Server, whilst also fixing / troubleshooting activation errors.

The sub-sections in the post will include-

1. General Requirements
2. Software Protection Service
3. DNS Records
4. Product Keys
5. Key Management Host File
6. Firewall Rules
7. Client Thresholds
8. Windows DCOM Security Settings
9. WMI Problems.

Common errors addressed –

0xC004F074 – The Software Licensing Service reported that the computer could not be activated. No Key Management Service (KMS) could be contacted.

0xC004F065 – The Software Protection Service reported that the application is running within the valid non-genuine period.

0xC004F041 – The Software Licensing Service determined that the Key Management Service (KMS) is not activated. KMS needs to be activated.

0xC004F042 – The Software Licensing Service determined that the specified Key Management Service (KMS) cannot be used.

0xC004F038 – The Software Licensing Service reported that the computer could not be activated. The count reported by your Key Management Service (KMS) is insufficient.

0xC004F039 – KMS activation request not answered by the Office KMS host

General Requirements

One Office or Windows KMS activation key does not activate the previous versions of MS Office or Windows. To activate older and newer versions of products on your KMS server, you will have to have a dedicated volume key for each version.

Software Protection Service

The Software Protection Service needs to be running on the KMS Server.

By going to Service.msc you can see a full list of the Services available on the KMS Server. Make sure the service Software Protection Platform (name differs a little depending on OS) is set to Automatic (Delayed Start) and running.

Command-Line:

net start sppsvc

DNS Resource Records

Check whether your clients looking at the correct KMS Server. In DNS there should be a SRV Resource record classifying your KMS Server as the host offering the KMS Service.

A way to test whether the DNS record is working correctly, is to run the below command on either the client or the KMS host

nslookup -type=all  _vlmcs._tcp

If the results show inconsistencies – Using DNS Manager, in the appropriate forwarding lookup zone, create/amend the SRV RR using the appropriate information for the location. By default, KMS listens on TCP port 1688, and the service is _VLMCS.

Navigate Forward Lookupzone > Domain > _tcp

SRV Resource Record:

You can determine what server the client computer is looking at too-

On the computer, open the Application Event log in Event viewer. Find the latest KMS activation request event and look in the General tab.

Check Product Key is still valid

Using Microsoft Volume Licensing Portal online – login and check your current active keys. Make sure the keys under Products in VAMT match.

Key Management Service Host File

Make sure you have downloaded the Key Management Service Host for the specific Windows product. Once downloaded, run the executable and enter your KMS product key for the specific product when prompted.

If this part isn’t completed, the KMS product key you entered manually into VAMT won’t work.

Firewall Rules

Make sure KMS activation communication between the server and the client’s aren’t being blocked by third party network firewalls or Windows Firewall.

On the KMS Server:

Navigate to Windows Firewall with Advanced Security

Select Inbound Rules in the left panel.

In the list of Inbound Rules and Outbound rules, double-click Key Management Service (TCP-In) and (TCP-Out), set them to allow.

If you can’t find a predefined rules, feel free to create them yourself, making sure to allow port 1688(default) remotely.

On the client computer:

Do the same making sure Windows Firewall is set to also allow inbound and outbound KMS traffic on the same KMS port 1688.

Testing port communication with telnet client:

Install the Telnet Client on both the KMS server and one of the client workstations. Then run the specified commands below – if a blank command prompt opens the port is open. Otherwise you will get a Connection failed error.

telnet KMSServerHostname 1688

Telnet Client on KMS Windows Server-

telnet ClientWorkstationHostname 1688

Client threshold

You will need at least 25 clients to meet or exceed the activation threshold, or the minimum number of qualifying computers that KMS requires. The KMS server needs to receive a set amount of requests for a specific Product before it starts activating clients. Depending on the product it can be between 5-25.

KMS clients in the grace state that are not activated because the activation count is too low, will keep trying to connect to the KMS host every two hours to get the current activation count and will be activated when the threshold is met.

Check Number of requests received-

Running the command below will provide you with all the information regarding how many requests your KMS server has received for any specific product.

slmgr.vbs /dli all

When the window called Windows Script Host appears, click it and Control+C, then paste it Control+V into a notepad so you can view everything.

To resolve this issue, you may just have to wait for more Windows\Office client activation to occur.

If the problem product isn’t in the list – go back to the Key Management Service Host File section.

Windows 7 DCOM security settings

When you’re implementing a KMS infrastructure in your Windows 7 environment, it is possible you get an “Unable to connect to the WMI service on the remote machine” when you are using the Volume Activation Management Tool (VAMT) to update clients with the correct license keys.

The solution was to be found in the Windows DCOM security settings on the Windows 7 clients.

1. Start dcomcnfg.exe
2. Goto Component Services –> Computers.
3. Right click My Computer and select Properties.
4. Goto the tab COM Security.
5. Click Edit Limits under Launch and Activation Permissions.
6. Select Everyone.
7. Make sure that Allow is enabled for Local Launch, Remote Launch, Local Activation and Remote Activation.

WMI Errors in VAMT

WMI Error – Unable to connect to the WMI service on remote machine

This is most likely related to WMI not being configured correctly, check the service on both server and client, check firewall settings and WMI configuration settings.

Also if you are working with client workstations not in the domain, but in workgroups, check out my guide on how to activate workstations in workgroups . It covers how to get around WMI errors caused by the workstations not being known to your internal DNS.

Thats it! – I hope after checking everything mentioned here, you have now got yourself back on track to having a functioning KMS Server without the woes.

If you are still having problems – Microsoft has published an overwhelming troubleshooting page located here.

Thanks for reading – feel free to follow and stay updated 🙂  View sysadminguides’s profile on Facebook View GuidesSysadmin’s profile on Twitter View 115372466162675927272’s profile on Google+