How do I determine what server is hosting KMS?

The KMS (Key Management Service) host server can be located using DNS querying if it has been properly configured to publish itself in DNS. If the query you've tried (nslookup -type=srv _vlmcs._tcp) is not working, it typically means that:
  1. The KMS server's SRV DNS entry is missing or misconfigured.
  2. There is a network or DNS issue preventing the query from succeeding.
  3. You're querying the wrong DNS server.
Here’s how to troubleshoot and locate your KMS host server:

Step 1: Verify the SRV Record Manually

The SRV record for the KMS host is typically _vlmcs._tcp.<yourdomain>. You can manually verify its presence in DNS using the following methods:
  1. Use PowerShell:
    Run the following command to query DNS for the KMS SRV record:
    Code:
    powershell
    Resolve-DnsName -Type SRV _vlmcs._tcp
    • This will query your default DNS server to find if the KMS server SRV entry is registered.
  2. Nslookup with Default DNS Server:
    If Resolve-DnsName doesn't work, double-check it with nslookup manually:
    Code:
    bash
    nslookup
    set type=srv
    _vlmcs._tcp
  3. Manually Check Your DNS Zone:
    • Open DNS Manager on your DNS server.
    • Navigate to your forward lookup zone (e.g., example.com).
    • Look for _vlmcs._tcp under _tcp in the zone.

Step 2: Manually Register the SRV Record (If Missing)

If the SRV record is missing, you may need to add it manually on your DNS server.
  1. Steps to Add SRV Record:
    • Open DNS Manager.
    • Locate your domain zone, then expand _tcp.
    • Right-click > Other New Records... > Select Service Location (SRV).
    • Fill in the details:
      • Service: _vlmcs
      • Protocol: _tcp
      • Port Number: 1688 (default for KMS)
      • Host Offering This Service: Your KMS server’s FQDN (e.g., kms.example.com).
  2. Refresh Your DNS Settings:
    After manual configuration, refresh DNS propagation:
    Code:
    bash
    ipconfig /flushdns
    • Test the query again to confirm the record is visible.

Step 3: Check KMS Server Settings

If the nslookup/Resolve-DnsName commands aren’t returning results and you don't see the SRV record in DNS, ensure that the KMS server is properly configured:
  1. Verify KMS Host Activation:
    Run this command on the suspected KMS server:
    Code:
    bash
    slmgr /dlv
    • This will display the KMS host machine details, including its DNS publishing status.
  2. Enable DNS Publishing:
    If it states that DNS publishing is disabled, enable it:
    Code:
    bash
    slmgr /cdns
    This re-enables DNS record publishing for the KMS server.
  3. Force Registration:
    You can also forcefully register the DNS SRV record:
    Code:
    bash
    net stop sppsvc
    net start sppsvc
  4. Client-Side Debugging:
    On a KMS client, test and view the current KMS configuration:
    Code:
    bash
    slmgr /skms <kms-server>
    slmgr /ato

Step 4: Manually Locate the Host

If no automatic discovery is possible, you may need to identify the KMS server manually by:
  1. Logging into potential KMS hosts and verifying their slmgr /dlv output.
  2. Check your organization’s documentation and AD records for KMS information.

Additional Notes​

  • Ensure that your network firewall allows traffic over port 1688, which is required for KMS functionality.
  • If the SRV query and KMS server DNS publishing still fail, consider manually configuring the KMS server hostname on the clients using:
    Code:
    bash
    slmgr /skms <kms-server-fqdn>:1688
Let me know if you need more help configuring this or interpreting the results of any of the steps!
 
To determine what server is hosting the Key Management Service (KMS) in your network, the nslookup -type=srv _vlmcs._tcp command should typically return the SRV record responsible for KMS. If this command isn't working, there are several possible explanations and alternative ways to troubleshoot and identify the KMS host.

Why might nslookup fail?​

  1. No SRV Record Exists: The _vlmcs._tcp SRV record might not be configured in DNS.
  2. Permission or Access Denied: The network or DNS server may restrict service record lookups.
  3. Incorrect Command: Syntax or spelling mistakes in the nslookup query.
  4. DNS Issues: Network or DNS server issues might prevent a proper response.

Alternatives to Find the KMS Host​

Here are some other methods to find the KMS server:

1. Use PowerShell to Query for KMS

You can use PowerShell to find the KMS server by querying DNS:
Code:
Resolve-DnsName -Type SRV _vlmcs._tcp
This provides detailed DNS information, similar to nslookup but often more reliable.

2. Check KMS Configuration on a Client

On a Windows client that's already activating against a KMS host, you can use the following commands to check its activation status and determine the KMS information:
Code:
slmgr /dlv
This will display details about the activation, including the KMS server name and the client machine's activation type.

3. Manually Search DNS Records

If you have access to your DNS server or a management console (like Windows DNS Manager), you can manually search for the _vlmcs._tcp SRV record there.

4. Check the KMS Server Directly

If you suspect a specific server is configured as the KMS host:
  • Run slmgr /dli or slmgr /dlv on the machine to confirm it's set up as the KMS server.
  • Look for the Software Licensing Service role in Server Manager, which supports KMS hosting.

5. Use Network Monitoring Tools

If you're unable to locate the KMS host via the above methods, you can use network monitoring tools to identify activation traffic from your devices. Tools like Wireshark can show the IP or hostname of the device handling KMS activation requests.

Troubleshooting DNS Issues​

If DNS misconfiguration is suspected, you may need to:
  • Verify the _vlmcs._tcp SRV record exists and is published correctly.
  • Confirm that DNS zones are propagating properly across your network.
  • Check network firewall and routing settings to ensure connectivity between your client and the DNS server.

Have More Details?​

If you're still experiencing issues, feel free to share additional details, such as:
  • Any error messages you're seeing.
  • The environment (e.g., domain-joined or standalone clients).
  • Steps you've already tried.
That way, I can provide more specific guidance! Let me know what you discover during your troubleshooting.
 
I see Volume Activation Services (Installed) on my domain controller roles. This should be the KMS Server correct?
 
Yes, if Volume Activation Services is installed on your domain controller, it is likely that this server is acting as the KMS host for your machines. However, we can confirm this to ensure it’s functioning as expected.
Here’s how to verify:

Step 1: Confirm KMS Host Role on the Domain Controller

  1. Run the Command to Check Activation Details:
    • On the domain controller, run the following:
      Code:
      bash
      slmgr /dlv
    • This will display detailed information about the KMS host, including:
      • Whether the KMS service is enabled.
      • The number of requests processed.
      • Whether it is actively publishing to DNS.
  2. Look for KMS Details:
    • If the server is the KMS host, you should see information like:
      • KMS Machine Name: The server’s name or FQDN.
      • License Status: KMS active.
      • Key Management Service is enabled on this machine.

Step 2: Verify the SRV Record in DNS

Even if KMS is enabled on this server, it needs to publish an SRV record to DNS for clients to discover it.
  1. Query the SRV Record:
    • Use PowerShell or nslookup to confirm the SRV record exists for _vlmcs._tcp:
      Code:
      powershell
      Resolve-DnsName -Type SRV _vlmcs._tcp
      Or:
      Code:
      bash
      nslookup -type=srv _vlmcs._tcp
  2. Check DNS Manager:
    • If Resolve-DnsName fails, open DNS Manager and look in your forward lookup zone under _tcp. for the _vlmcs._tcp SRV record. It should point to your domain controller.
  3. Fix if Missing:
    • If the record is missing, you can enable DNS publishing on the KMS server (your domain controller):
      Code:
      bash
      slmgr /cdns
  4. Restart the Service:
    • Restart the Software Protection Service to force DNS registration:
      Code:
      bash
      net stop sppsvc
      net start sppsvc
    • Wait a few minutes for DNS replication, and check again.

Step 3: Test Activation Requests

  1. Test from a Client Machine:
    • On a client machine trying to activate with the KMS host, run:
      Code:
      bash
      slmgr /skms <FQDN>:1688
      slmgr /ato
    • Replace <FQDN> with the domain controller’s fully qualified name.
  2. Verify Activation:
    • success messages indicate that your client can communicate with the KMS host.
    • Run:
      Code:
      bash
      slmgr /dli
    • This shows details about activation and confirms it was using the domain controller as the source.

Step 4: Monitor Logs

  • On the KMS Server (DC):
    • Check the key management service logs in Event Viewer under:
      Code:
       Applications and Services Logs -> Key Management Service
    • Look for activation requests from clients to ensure everything is working.

Optional: Confirm Licensing Status​

If the domain controller is not set up to act as a KMS server, or you have doubts, confirm that the appropriate Volume License Key (GVLK) for KMS is installed on the domain controller:
Bash:
slmgr /ipk <KMSHostKey>
Replace <KMSHostKey> with the KMS host key provided by Microsoft.

Conclusion​

Your domain controller likely serves as your KMS host, and the slmgr /dlv command will confirm its status. Publishing the _vlmcs._tcp SRV record ensures clients discover it automatically. If anything doesn't align, let me know, and we’ll troubleshoot further!
 
Yes, if the _vlmcs._tcp SRV record is missing from DNS and you want to enable automatic discovery of your KMS (Key Management Service) host for client machines, then you should manually create the record. This will allow your clients to locate the KMS server without needing it to be explicitly set on each device.

Steps to Create the _vlmcs._tcp SRV Record in DNS

1. Open DNS Manager

  • On your DNS server, open the DNS Manager.
    • You can do this by running dnsmgmt.msc or accessing it through Server Manager > Tools > DNS.

2. Navigate to Your DNS Zone

  • Expand your Forward Lookup Zones.
  • Locate your domain name (e.g., example.com).

3. Add the SRV Record

  1. Right-Click on _tcp Folder:
    • If there is a _tcp folder under your zone, right-click on it. If _tcp doesn’t exist, create it:
      • Right-click your domain > New Domain > Enter _tcp.
  2. Create the New SRV Record:
    • Right-click _tcp > Other New Records > Select Service Location (SRV).
  3. Fill in the SRV Record Details:
    • Service: _vlmcs
    • Protocol: _tcp
    • Priority: 0 (default priority, adjust if needed for multiple KMS servers).
    • Weight: 0 (default weight, adjust for load balancing multiple hosts).
    • Port Number: 1688 (this is the KMS default port).
    • Host Offering This Service: <FQDN of your KMS host> (e.g., kms.example.com or yourdomaincontroller.example.com).
  4. Click OK to save the record.

4. Verify the Record

  • Use nslookup or PowerShell to query the SRV record and ensure it is discoverable:
    Code:
    bash
    nslookup -type=srv _vlmcs._tcp.<yourdomain>

5. Flush DNS Cache and Restart Services

  • On the KMS server, restart the Software Protection Service:
    Code:
    bash
    net stop sppsvc
    net start sppsvc
  • On a client machine, flush the DNS cache to ensure the new SRV record is queried:
    Code:
    bash
    ipconfig /flushdns

Test KMS Functionality

  1. Verify Client Activation:
    • From a client machine attempting activation:
      Code:
      bash
      slmgr /ato
    • This will attempt to activate the machine using the discovered KMS host.
  2. Force Client to Use the KMS Server:
    • If needed, specify the KMS host manually (to confirm its functionality):
      Code:
      bash
      slmgr /skms <kms-server>.example.com:1688
      slmgr /ato
  3. Check Activation Status:
    • Run:
      Code:
      bash
      slmgr /dli
    • This will provide details about the activation status and the connecting KMS server.

Additional Notes

  • The _vlmcs._tcp SRV record enables automatic discovery, but manual activation using the slmgr /skms command will also work without DNS if you configure clients directly with the KMS host.
  • If you actively use KMS in a larger setup or have clients across domains, ensure that the SRV record propagates properly and that there are no issues with DNS replication across your infrastructure.
Let me know if you encounter issues while creating the SRV record or testing the setup, and we’ll refine the approach!
 
slmgr /dlv does not show the information you state. It does show VOLUME_KMSCLIENT it also shows Product Key channel: Volume GVLK and License status Licensed
 
Ah, thanks for pointing that out! The slmgr /dlv output showing VOLUME_KMSCLIENT and Volume GVLK (Generic Volume License Key) indicates that this server is not currently configured as the KMS Host. Instead, this server appears to be functioning as a KMS client, which means it is activating against a different KMS server.
You’ll need to locate your actual KMS Host, and here's how:

Step 1: Verify if KMS is Installed and Configured on This Server

While this server isn’t currently acting as the KMS Host, you can configure it or confirm whether it ever was the KMS host:

Run the Following Commands:​

  1. Check if the KMS Host Key is Installed:
    Code:
    bash
    slmgr /dli
    • Look for a line indicating a "KMS host key". If you don’t see it, this server is not a KMS Host.
    • If the server says KMSCLIENT, it means the generic volume license key is being used, which means this server is a client and not currently set up as a KMS Host.
  2. Check if Volume Activation Services is Functional:
    • Open Server Manager > Check the Volume Activation Tools under Roles.
    • Attempt to run through the configuration wizard. If this server has no valid KMS Host Key, it cannot act as the host.

Option to Promote to KMS Host:​

If this server needs to become the KMS Host, you must:
  1. Install the KMS Host Key for your licensing scenario:
    Code:
    bash
    slmgr /ipk <Your_KMS_Host_Key>
    Replace <Your_KMS_Host_Key> with a valid key from Microsoft.
  2. Activate the KMS host:
    Code:
    bash
    slmgr /ato
  3. Publish the DNS SRV Record:
    Code:
    bash
    slmgr /cdns

Step 2: Locate the Active KMS Host

Since this server isn't the KMS Host, you’ll need to find the actual server acting as your Key Management Service host. Here's how:

Using DNS to Find the KMS SRV Record

The KMS Host automatically registers itself in DNS if configured properly.
  1. On a machine connected to the domain, run:
    Code:
    bash
    nslookup -type=srv _vlmcs._tcp
    • This will query the SRV record for the KMS Host.
    • If successful, the FQDN of the KMS Host server will be returned.

Check Other Domain Controllers or Infrastructure Servers

  1. If your DNS lacks a proper _vlmcs._tcp SRV record, manually investigate the other servers that might host KMS.
    • Look for Volume Activation Tools in the Server Manager Roles and Features pane.
    • Log into potential infrastructure servers and run:
      Code:
      bash
      slmgr /dlv
      This should return the necessary information for any machine configured as a KMS Host.
  2. Ask Your Licensing Administrator:
    If no records or information can be found, consult whoever handles licensing to determine if the KMS is hosted externally or if it may need to be newly configured.

Step 3: Temporarily Configure This Server as KMS Host

If you cannot locate the existing KMS Host and need immediate activation functionality:
  1. Install the KMS Host Key:
    Code:
    bash
    slmgr /ipk <Your_KMS_Host_Key>
  2. Activate the KMS Host:
    Code:
    bash
    slmgr /ato
  3. Verify via slmgr /dlv:
    • Ensure it now reports Key Management Service enabled.

Troubleshooting Summary​

Your current server is configured as a KMS client and not the active KMS Host. Locating the active KMS Host or configuring a new one (if required) involves checking DNS, running activation tools, or manually provisioning the service with a valid KMS Host key.
Let me know if you encounter further issues or questions—I’d be happy to assist further in identifying or configuring your KMS setup!
 
Fantastic! I’m glad everything is all set now! If you need help with any other Windows or server-related issues in the future, feel free to reach out here. Good luck with your KMS setup, and have a great day!