Edit

Share via

Replace a KMS host

This article outlines the steps and best practices for migrating the Key Management Services (KMS) host role to a new server. Migrating the KMS host is often necessary when the existing host's operating system (OS) is approaching its end-of-support. It might also be required due to operational or organizational changes that mandate moving the role to a different server. The instructions in this guide provide a seamless migration process while maintaining uninterrupted activation services for Microsoft Windows and Microsoft Office clients. No data migration is required during this process as the KMS Host doesn't rely on any database or backup.

Before proceeding with your installation and licensing tasks, review the following details regarding your new KMS host:

  • Ensure you have access to your new Customer Specific Volume License Key (CSVLK). Your CSVLK is also known as the KMS host key for the Microsoft Windows OS and Microsoft Office, which are obtained through the Microsoft 365 Admin Center. The CSVLK has a predefined activation limit. If you encounter an error stating that you exceeded the activation limit, you can reset the key per request. To learn more, see Find and use product keys for volume licensing.

  • If you're unable to find your CSVLK, contact support for licensing assistance.

Prerequisites

  • The Volume Activation Services role must be installed on the device that acts as the new KMS host. To learn more, see Install or Uninstall Roles, Role Services, or Features.

    Alternatively, you can run the following PowerShell command:

    Install-WindowsFeature -Name VolumeActivation -IncludeManagementTools

  • You must be a member of the following groups:

    • Administrators
    • Domain Admins
    • Enterprise Admins

  • The CSVLK must be valid and accessible from your organization's licensing portal or the Microsoft 365 Admin Center. Ensure you have the appropriate CSVLK for the products you're activating, such as:

    • Microsoft Windows OS CSVLK
    • Microsoft Office CSVLK

  • Your OS must have the latest Windows updates installed before configuring your device as a KMS host. To learn more, see KMS host required updates.

Verify existing KMS hosts

Before you migrate to a new KMS host, it's recommended to inventory your environment to identify all existing KMS hosts. This helps ensure there aren't unauthorized or unnecessary KMS hosts present. Unapproved KMS hosts might appear if a CSVLK was used to activate a device that shouldn't serve as a KMS host. Only authorized servers should be activated with a CSVLK and configured as KMS hosts. Performing these actions can be done in an elevated command prompt or PowerShell window.

Retrieve a KMS host

To retrieve KMS hosts by the Domain Name System (DNS), run the following command:

nslookup -type=srv _vlmcs._tcp

To retrieve KMS hosts by the Fully Qualified Domain Name (FQDN), run the following command:

nslookup -type=SRV _vlmcs._tcp.mydomain.com

To retrieve KMS hosts by a specific DNS server, such as 8.8.8.8, run the following command:

nslookup -type=SRV _vlmcs._tcp.mydomain.com 8.8.8.8

If you discover unauthorized KMS hosts, you can revert them to KMS clients by running the following command in an elevated window and then restart the device. Replace the Generic Volume License Key (GVLK) with your GVLK:

slmgr.vbs /ipk <GVLK>

Verify KMS host product activation

To verify which products the current KMS host is activating and ensure the new KMS host activates the same Windows OS and Microsoft Office clients, run the following command:

cscript %windir%\system32\slmgr.vbs /dlv All

cscript $env:windir\system32\slmgr.vbs /dlv All

Check the output to determine whether the KMS host is processing activation requests for the Windows OS, Microsoft Office, or both. The partial product keys displayed can help you match these KMS host keys (CSVLK) with your records. Additionally, review the KMS Host Event log to identify which clients are sending activation requests to this KMS host.

Prepare the KMS host

Before configuring your environment as a KMS host, start with a clean installation of the target OS on the new server. To learn how to install your Windows Server OS, see Install Windows Server from installation media. Ensure that all available OS updates and security patches are applied and reboot as necessary. There are two options available for setting up your KMS host.

After you prepare the host OS, the next step is to configure it to serve as a KMS host. See Create a Key Management Services (KMS) activation host.

Verify firewall settings

Before proceeding on how to manage a KMS host, ensure that the firewall exception is configured for port 1688 to accept activation requests from KMS clients. Additionally, port 135 (Anonymous RPC) also needs to be configured.

  1. Select Start, type wf.msc, then select it to open the Windows Defender Firewall with Advanced Security.
  2. In the left pane, select Inbound Rules.
  3. In the right pane, select New Rule to open the New Inbound Rule Wizard.
  4. Under Rule Type, select Port, then select Next.
  5. Under Protocol and Ports, select TCP, enter 1688 in the Specific local ports field, then select Next.
  6. Under Action, ensure Allow the connection is selected, then select Next.
  7. Under Profile, Domain, Private, and Public are selected by default. Select Next.
  8. Under Name, provide any name desired for your rule, such as "KMS Host", then select Finish.

Repeat these steps to configure port 135.

To verify that traffic is allowed through port 1688 or 135, run the following command where values for ComputerName are the device name or IP address:

Test-NetConnection -ComputerName "MyDevice" -Port 1688

When the connection succeeds, the entry TcpTestSucceeded equals True, while if the connection to port 1688 can’t be made (for instance, if no service is listening or because of a firewall or network issue) then TcpTestSucceeded equals False.

Register a KMS host

After you configure the KMS host for Windows OS and Microsoft Office, it might automatically register with DNS if your domain permissions allow. If manual registration is required, follow the steps in Manually create DNS records.

After registering the new KMS host in DNS, you can remove the old KMS host from DNS. Client devices begin sending activation requests to the new KMS host, though it might take some time for the activation count to reach the required minimum thresholds.

Note

  • KMS Count client activation threshold: KMS requires at least 25 unique activation requests from the client or server OS to begin activating the client OS.
  • KMS Count server activation threshold: KMS requires at least 5 unique activation requests from the server or client OS to begin activating the server OS.

To confirm successful migration, review the Event Log on the new KMS host (Event Viewer > Application and Services Log > Key Management Service). You can also run the following command and review the output:

slmgr.vbs /dlv

Once client devices are sending activation requests to the new host, you can safely remove the old KMS host from DNS.

Note

  • To remove the KMS host functionality from old KMS host, install your GVLK and restart your device.
  • Best practice is to completely shut down the old KMS host to ensure that client devices transition to the new KMS host.
  • If a device was configured for a specific KMS host using slmgr.vbs /skms, executing slmgr.vbs /ckms clears that configuration and allows the devices to automatically detect the new KMS host.

Troubleshoot KMS activation

Performing these actions must be done in an elevated command prompt or PowerShell window. To further troubleshoot other issues, see Guidelines for troubleshooting the Key Management Service (KMS).

See also

  • Last updated on