Windows Activation using KMS

In a recent project, I found myself challenged to manage the Windows Server License activation for all servers in the Remote Support Network (RSN). In this environment, all newly minted servers are deployed as virtual machines (VMs) using vSphere in a VMware environment. One thing to note is that the entire network is heavily firewalled. In fact it relies heavily on VLANs to further segment and isolate the applications. So one of the constraints is no access to the Microsoft Windows Activation service on the Internet, hence the need for in in-house solution: Key Management Service (KMS) activation.

KMS Overview

Beginning with Windows Server 2003 and Vista, Microsoft requires that the operating system undergoes an activation process as part of the License Agreement to guard against software piracy. An activated Windows operating system is referred to a “Genuine”. A non-genuine system will offer the activation option each time an individual logs in to the system. In some instances after a pre-demined period of time, the OS will no longer allow a logon.

Microsoft uses two methods: Multiple Activation Key (MAK) and Key Management Service (KMS). MAK is used for one-time activation using the Microsoft Activation Services through the Internet or through telephone. Since the RSN is a firewalled environment, phone activation is the only option with MAK. KMS allows an organization to complete product activation without the need for individual computers to contact the Microsoft activation services over the Internet.

The KMS functionality is deployed in the environment as a Windows service. The Windows KMS Activation service is called Software Protection and the executable is sppsvc.

How it works

The KMS activates a client server for a period of 180 days. Once a machine is activated, it will attempt to communicate with the same KMS every seven days to renew its activation and to reset its license activation counter back to 180 days.

If it is unsuccessful, it will try to connect to the KMS every two hours until it is successful. If the machine has not been able to reestablish communication with the KMS after 180 days, it will become unlicensed. It then starts on a 30 day grace period and notifies the logged on user of this. If the computer is not activated within the grace period, it will enter a period of reduced functionality until it is able to connect and activate. If this fails, you can change to a valid MAK key and activate through the Internet or the phone. The RSN Windows 2003 Enterprise servers are licensed through a MAK key. Windows 2008 Servers use KMS activation.

KMS_Installation_Roadmap

The KMS server uses the Volume Activation Management Tool (VMAT) to provide a GUI-based Administrative interface to manage KMS & MAK activated systems. VAMT collects data on licensed clients, including information about the product keys and current license states, then stores this information in a computer information list (CIL) file. The CIL is an Extensible Markup Language (XML) file and is readable by any text editor, such as Microsoft Notepad.

Process

All new Windows 2008 R2 servers are deployed using a VMware template based on the server’s role. The template is modified by a VMware Configuration Script. This is similar to the text file used in unattended installation. The Configuration file contains the publically available generic Windows 2008 Enterprise R2 KMS Client Activation Key.

The main characters in the KMS Activation process are: the KMS Host Server and the Windows client OS, with DNS playing a supporting role.

A KMS Host is a Windows Server running the KMS service that has been activated by a KMS Key using the SLMGR command. The Host is normally activated through the Microsoft Activation Service; however, in the RSN firewalled environment, activation was accomplished using the phone activation. A DNS SRV (_tcp_VMS) record containing the FQDN of the KMS Host and the listening port (1688) is created as part of the activation process.

To create the SRV record:

  1. Log into a Domain Controller.
  2. Open the DNS Console.
  3. Under the DNS Server, navigate Forward Lookup Zones -> domain FQDN folder -> _tcp.
  4. Right-click the _tcp folder and choose Other New Records…
  5. Scroll down the list, choose Service Location (SRV) and click Create Record.DNS_srv_Record

Complete the form as shown below.

Service_Location_Record

The Windows client will query AD to locate the _VLMCS record to identify the KMS Host to contact from the information contained in the record.

Next, the client will send an RPC request on TCP/1688 to the KMS Host, generate a Client Machine ID (CMID), encrypt the request and present it. If the process fails, it will try again every 2 hours for clients in a “grace” period, meaning first time activation attempt or every 7 days for clients that need re-activation.

The KMS Host adds the CMID to its VMAT Table and returns an activation count to the client.

The client activates itself, stores the KMS product ID information and will attempt re-activation every 7 days.

Note that the KMS Host will not automatically activate clients until 5 clients have been activated. Kind of like a “chicken-egg” paradigm. Just manually activate 5 clients and get the rest “for free.”

Firewall port rules

This is very important! Insure that any firewalls in the environment including the Windows Firewall allow bi-directional TCP/IP post 1688 and RCP traffic from the KMS Host server to all of your VLANs.

VMAT Activation

The process described above will work for all new machines deployed in the RSN and for activated machines requiring renewal. There are two alternative methods of activation available: activation using the Volume Activation Management Tool (VMAT) or the command line SLMGR.VBS tool. SLMGR will be described in the following section.

VMAT is a free download that runs as a Microsoft Management Console. It is installed on the NLM-CON-MS11 server in the DS domain. VMAT allows you to:

  • Discover computers,
  • Manage product keys,
  • Manage activations and
  • Maintain status.

VMAT Console

Login to the KMS Host and launch the console.

You can add computers manually using the computer name or IP address or you can use the drop down in the standard view and select “Search for computers in Active Directory. Using this option, you can specify the domain (use FQDN and in subsequent dialogs the appropriate credential) and filter by computer name. This action queries AD and populates the list.

Each of the columns listed in the standard view allows you to sort the list, type in a text for a partial search and use the funnel to filter by checking the box(s) for the appropriate groups. The last two options work in conjunction with each other to narrow down the items displayed.

You can select computers by highlighting them, right-click, chose Update Status -> Current Credential. Depending on the domain in which the computer is located, you may need to provide alternate domain-specific credentials.

 

So, in the event the product key from the VMware template fails to automatically activate, use the following procedure to manually activate using this tool.

Add the computers to the tool using the method described earlier if the computer is not already in the table.

Select the computer, right-click and choose ”Install Product key…” The next dialog allows you to enter a product key. The default, “Select a product key to install” allows you to select from the keys listed. Select “Install a KMS Key” and the Host will choose the appropriate key. The window greys out as shown below.

KMS_Key

Enter alternate credentials as appropriate. Click OK and the key will be pushed out to the client compute if successful. If not, the error will indicate an a problem communicating with the server. If so, you’ll have to engage the appropriate network team to troubleshoot possible fire wall issues.

KMS_Activate

Leave the default selection unless you need to enter alternate credentials. Click OK. Any issues will generally involve network connectivity between client and host. Engage the network team as appropriate.

SLMGR

This is the alternate method of product activation from the client computer using the SLMGR.VBS tool. This script is run from a command prompt as an administrator. Right-click the icon and choose Run as administrator. This window will provide access rights and mapping to the tool. Use “cscript slmgr.vbs <switch> to keep messages in the command window or just type slmgr.vbs to run in Windows Scripting Host (WSH) mode.

You can get help by “cscript slmgr.vbs /?”. The following switches may be used:

  • Check your activation status: /DLI use /DLV to get detailed information.
  • Install a product key: /IPK <product key>.
  • Activate Windows: /ATO.

Three other options are available though not frequently used:

  • Uninstall a product key: /UPK.
  • Clear the product key from the registry: /CPKY. Using the /IPK switch automatically removes the current key.
  • Rearm the activation period: /REARM. Note that this requires a system restart.

Conclusion

With the open firewall rules allowing full RPC communication between the KMS Host and all of the VLANs in your environment, you shouldn’t have any problems automatically activation your KMS client.

This entry was posted in General Information and tagged , , , , . Bookmark the permalink.

2 Responses to Windows Activation using KMS

  1. Chris says:

    Great article. Quick Question

    I understand that the default port that the KMS server listens on is 1688. The client will also use the source port of 1688 by default when it make a request to the the KMS server. We have a lot of firewalls across the domain, is it necessary to allow NEW inbound connections to clients from the KMS server? I would think that since the clients make all NEW requests (starts the three way handshake) to the Server that allowing inbound from the KMS server to all the thousands of hosts in the enterprise to client port 1688 would not be required. Does the client actually listen on 1688 also? Does the KMS server ever in initiate communication with the clients? Thanks for any help.

    • John says:

      Hi Chris,

      In a secured VLAn, client outbound connections using TCP 1688 from the client to the KMS server are not a problem; however, the KMS server has to be configured to allow inbound traffic on port 1688. Network firewalls should be configured to allow this particular connectivity. Also, the KMS VMAT tool can query DNS to add servers to the tool. It can also update connected client status by querrying the client. I honestly, don’t know which port it uses to accomplish this.
      Here’s a pretty good reference on how to “Troubleshoot the Key Management Service (KMS)” from Technet. http://technet.microsoft.com/en-us/library/ee939272.aspx.
      Hope this helps.

Leave a Reply to Chris Cancel reply

Your email address will not be published. Required fields are marked *