Windows Volume licensing upgrades

Great question! The short answer is no, your Volume License server (specifically the KMS Host) does not have to be running the latest version of Windows Server to activate newer versions of Windows Server. However, there are some conditions and requirements to be aware of.
Here’s how it works:

---

Key Points About Volume Licensing and Upgrades​

1. KMS Host and Product Support Compatibility:
   • A KMS Host running an older version of Windows Server (e.g., 2016 or 2019) can license newer versions of Windows Server (e.g., 2022), provided:
     • You install the appropriate KMS update for the version of Windows Server you wish to license.
     • A valid KMS Host key for the newest version has been installed on the KMS Host server.
   Example:
   • You want to activate Windows Server 2022:
     • Your KMS Host is running Windows Server 2019.
     • Install the KMS update for Windows Server 2022 support and provide a valid 2022 KMS Host key.
2. No Requirement for Upgrading the Host OS:
   • You are not required to upgrade your KMS Host’s operating system (e.g., to Windows Server 2022) unless there is an explicit business need. You can manage licensing for newer versions using updates and key management tools.
3. Client Activation Compatibility:
   • Once the KMS Host is appropriately updated and configured with the correct key:
     • It can activate older, same, or newer versions of Windows Server and Windows clients (e.g., Windows 10 or 11) depending on your setup.

---

Steps to Ensure Compatibility​

1. Install the Latest KMS Updates​

• Your KMS Host must be updated to recognize newer operating systems. Microsoft releases updates for older KMS Hosts that expand their licensing support.
• For example:
  • Add support for Windows Server 2022:
    • Install the October 2021 KMS update (KB5003478). This update includes support for Windows Server 2022 and Windows 11 activations.
  • Check for the latest KMS updates for your Windows Server version.

2. Add the Appropriate KMS Host Key​

• Log into your KMS Host and install the new KMS Host Key for the newer version:
  
  Code:

  bash
  slmgr /ipk <new_KMS_Host_Key>

  Replace <new_KMS_Host_Key> with your valid key from the Volume Licensing Service Center (VLSC) or Microsoft Partner Center.

3. Activate the New Key​

• After installing the key, activate it with Microsoft:
  
  Code:

  bash
  slmgr /ato

4. Verify KMS Hosts Licensing Ability​

• Run the following to confirm your KMS Host is active and supports the newer versions:
  
  Code:

  bash
  slmgr /dlv

• Review the KMS version number in the output to ensure it's configured appropriately for newer Windows versions.

5. Restart the Software Protection Service​

• After key updates and activation:
  
  Code:

  bash
  net stop sppsvc
  net start sppsvc

• This forces the KMS Host to re-register itself with DNS if needed.

---

Special Considerations for KMS Activation​

1. If You’re Using Active Directory-Based Activation (ADBA):
   • If your organization uses ADBA instead of KMS, the process is similar, but the activation is tied to your Active Directory rather than a specific KMS Host.
2. Older Hosts and Unsupported KMS Keys:
   • If your KMS Host is too old (e.g., Windows Server 2012 R2 or earlier), it may not support the necessary updates to activate newer servers like 2019 or 2022. In such cases, you may need to stand up a newer KMS Host or switch to ADBA.
3. Alternative Licensing Options:
   • Organizations moving toward Microsoft 365/Intune or Azure-based infrastructure may shift to MAK (Multiple Activation Keys) or subscription-based activation when managing a hybrid cloud and on-prem setup.

---

Summary​

• Your KMS host does not need to be running the latest Windows Server version, but it must be updated with the necessary KMS patches to recognize and activate newer versions.
• As long as the appropriate KMS Host key is installed and activated, the server can manage activations for newer Operating Systems.

---

Next Steps​

• Confirm your Volume License setup and whether your current KMS Host server has the appropriate updates and keys.
• Test the activation process on a new Windows Server to verify successful activation.

Let me know if you'd like detailed guidance on any of these steps!

I have installed the KMS 2025 license keys on my KMS server and then upgraded another server from 2022 to 2025 but is shows and not licensed after the upgrade.

Thank you for the clarity—if your KMS server is updated with the 2025 KMS Host keys, but the upgraded Windows Server 2025 is showing as not licensed, this could indicate either a configuration or communication issue between the KMS host and the client.
Here’s how to systematically resolve this issue:

---

Step 1: Verify the KMS Host Installation and Configuration​

1. Confirm the KMS Host Key:
   • On the KMS host, run:
     
     Code:

     bash
     slmgr /dlv

     • Look for the "KMS host enabled" line, ensuring the 2025 KMS Host Key was installed correctly.
     • Make sure the License Status for the KMS host itself is "Licensed".
2. Test KMS Functionality:
   • From the KMS host, confirm that it can handle requests. Run:
     
     Code:

     bash
     slmgr /dlv

     Look for:
     • The KMS Current Count: This should be at least 5 (minimum for activating Windows Server).
3. Restart the Software Protection Service on the KMS Host:
   • This will ensure that the KMS server processes are refreshed:
     
     Code:

     bash
     net stop sppsvc
     net start sppsvc

   • Following the restart, ensure that the KMS host updates its DNS SRV record if automated discovery is enabled (_vlmcs._tcp).

---

Step 2: Diagnose the KMS Client (Windows Server 2025)​

1. Verify the GVLK (Generic Volume License Key):
   • Upgraded machines may retain their old product keys, which are incompatible with the new KMS.
   • Set the appropriate Generic Volume License Key (GVLK) for Windows Server 2025. Run:
     
     Code:

     bash
     slmgr /ipk <GVLK_2025_key>

     You can find the correct GVLK keys from Microsoft’s GVLK list.
2. Test Connectivity to KMS Server:
   • Force the client to attempt activation with the KMS server:
     
     Code:

     bash
     slmgr /skms <KMS_Host_FQDN>:1688
     slmgr /ato

     • Replace <KMS_Host_FQDN> with the fully qualified domain name of your KMS server.
     • If successful, it will report back as "Licensed". If not, note any error codes returned.

---

Step 3: Common Troubleshooting Cases​

A. KMS Activation Threshold Not Met​

• If the KMS host current count (reported via slmgr /dlv) is 5 or lower, this means the KMS threshold for servers has not yet been met (minimum is 5 for Windows Server activations). Until this threshold is reached, the KMS host will not activate any clients.

Solution:

• Activate more Windows Server installations (e.g., at least 5 total) to meet the activation threshold.

---

B. DNS SRV Discovery Failing​

• If the upgraded server cannot locate the KMS host, forcing it to use the _vlmcs._tcp SRV record in DNS (or manually pointing the client to the KMS host) is critical.

Solution:

1. Verify the SRV Records in DNS:
   • Query the KMS SRV record from the client:
     
     Code:

     bash
     nslookup -type=srv _vlmcs._tcp

   • Ensure the KMS server FQDN is returned.
2. Manually Specify the KMS Host (if SRV lookup fails):
   • Tell the client exactly where the KMS server is:
     
     Code:

     bash
     slmgr /skms <KMS_Host_FQDN>:1688

   • Retry activation:
     
     Code:

     bash
     slmgr /ato

---

C. Firewall/Network Blocking Activation Requests​

Solution:

• Ensure port 1688 is open between the client and KMS host. You can test connectivity using:
  
  Code:

  bash
  telnet <KMS_Host> 1688

  • If blocked, adjust firewall rules to allow traffic over this port.

---

Step 4: Check Logs for Errors​

1. On the KMS Host:
   • Check Key Management Service Logs in Event Viewer:
     
     Code:

      Applications and Services Logs -> Key Management Service

   • Look for activation requests and confirm if the upgraded client is reaching the KMS host or if errors are logged.
2. On the Client:
   • Review the Software Protection logs in Event Viewer:
     
     Code:

      Applications and Services Logs -> Microsoft -> Windows -> Software Protection Platform

---

Step 5: Test with Other Clients​

Try activating another server or client machine to confirm whether licensing works. This helps isolate whether the issue is with the KMS host or the specific upgraded client machine.

---

Final Notes​

The most likely culprits here are:

1. KMS Threshold Not Met.
2. Client Not Pointing to the Correct KMS Host.
3. Old Key/Incorrect GVLK on the Upgraded Server.

Please let me know what results you get after running these tests, as well as any error messages or codes. I’m here to help fine-tune further if needed!

Looks like the 2025 did not take. How do I know I am using KMS or AD activation?

To determine whether you're using KMS (Key Management Service) or AD-based Activation (ADBA) for your Windows Server activations, you can check a few settings both from the client side and on your activation host.
Here’s how to check which method is being used:

---

Step 1: Check Activation Method on the Client​

1. Run slmgr /dlv Command:
   • On the server you upgraded to 2025, run:
     
     Code:

     bash
     slmgr /dlv

   • Review the output to find the activation type:
     • For KMS:
     • The output will mention VL (KMS) or Key Management Service—this means activation occurs through a KMS host.
     • For AD-based Activation:
     • The output will mention Active Directory Based Activation (ADBA) or AD Activation.
2. Check the Product Key Channel and Activation Status:
   • Look for:
     • Product Key Channel:
     • Volume:GVLK = Generic Volume License Key (used for both KMS and ADBA).
     • License Status:
     • If it’s not licensed, this may suggest it failed to contact KMS or the AD activation object.

---

Step 2: Check if KMS or ADBA is Configured​

To identify whether KMS or ADBA is providing activation, here’s how to confirm on the KMS/ADBA server:

Option A: Check KMS Configuration​

1. Run slmgr /dlv on the KMS Host:
   • Run this on your suspected KMS server (e.g., the server with the Volume Activation Tools role):
     
     Code:

     bash
     slmgr /dlv

   • Look for:
     • Description: Will mention KMS host key if this server is a KMS host.
     • KMS Current Count: The current count must be ≥ 5 for Windows Server activation.
2. Check the Key Management Service Log in Event Viewer:
   • Open Event Viewer on the host server and navigate to:
     
     Code:

      Applications and Services Logs -> Key Management Service

   • Look for activation requests to confirm the KMS is receiving them.

---

Option B: Check Active Directory-Based Activation (ADBA)​

If your organization uses ADBA instead of KMS, follow these steps:

1. Open Volume Activation Tools:
   • On the server with the Volume Activation Tools role, open it via Server Manager.
   • If using ADBA, you’ll see Active Directory-Based Activation listed as the activation method.
2. Verify Activation Objects in Active Directory:
   • Open Active Directory Users and Computers (ADUC).
   • Navigate to:
     
     Code:

      CN=ADApplications,CN=Microsoft,CN=Program Data,DC=<your domain>

   • Look for Volume Activation objects related to the product, such as:
     • Windows Activation Services
     • Windows Server 2025
3. Clients Automatically Query AD:
   • If ADBA is active, any client or server with a Volume:GVLK key will attempt to activate against AD without needing an SRV DNS _vlmcs._tcp record.

---

Step 3: Verify Activation Logs​

1. Check Activation Log on the Client:
   • On the server showing "not licensed," review:
     
     Code:

      Applications and Services Logs -> Microsoft -> Windows -> Software Protection Platform

     • Look for errors like:
     • Failure connecting to a KMS host.
     • Issues locating the AD object for activation.
2. Check the Volume Activation Log on the Host:
   • For KMS, examine Key Management Service logs to confirm whether requests are reaching the host.

---

Step 4: Force a Specific Activation Method​

If you're unsure which activation source is being used, you can force the client to use either KMS or ADBA for testing purposes.

1. Test KMS Activation:
   • Explicitly point the client to your KMS server:
     
     Code:

     bash
     slmgr /skms <KMS_Host_FQDN>:1688
     slmgr /ato

   • Replace <KMS_Host_FQDN> with your KMS server's name or IP.
2. Test ADBA Activation:
   • Revert the client to query AD for activation:
     
     Code:

     bash
     slmgr /ckms
     slmgr /ato

   • The /ckms command clears the KMS server from the client, and it defaults to AD-based activation.

---

Step 5: Additional Troubleshooting​

1. If It's KMS:
   • Ensure that the KMS host has the correct 2025 KMS Host key installed.
   • Check that the server count (KMS Current Count) is at least 5 for server activations.
2. If It's ADBA:
   • Ensure the correct volume activation object for Windows Server 2025 exists in Active Directory.
3. Confirm Client GVLK:
   • The client must be set up with the Generic Volume License Key for Windows Server 2025. Reapply it if uncertain:
     
     Code:

     bash
     slmgr /ipk <GVLK_2025_Key>
     slmgr /ato

---

Takeaways​

• If the server is relying on KMS, ensure the KMS host has the correct key and DNS SRV record.
• If it's ADBA, ensure the required AD activation object exists for Windows Server 2025.
• Use logs and the output of slmgr /dlv and slmgr /dli to confirm which service is being used and resolve potential issues.

Let me know what additional info or errors come up—we’ll get this straightened out!

I don't see anything in ADUC for licensing but when I use the VATool the default it comes up with is Active directory but I can also select KMS

The fact that the Volume Activation Tools (VATool) default to Active Directory-Based Activation (ADBA) suggests that ADBA is either configured or partially operational in your environment. This would explain why there’s no _vlmcs._tcp SRV record, as ADBA doesn’t rely on DNS SRV records like KMS does. However, this can coexist alongside KMS since you also see it as an option.
Here’s how to proceed to clarify and resolve your activation environment:

---

Step 1: Verify Active Directory-Based Activation (ADBA) Setup​

1. Reconfirm ADBA Status in VATool:
   • Open Volume Activation Tools again.
   • If Active Directory-Based Activation is enabled, the VATool will show an existing activation object for your domain.
2. Manually Check ADBA Objects in ADUC:
   • Open Active Directory Users and Computers (ADUC).
   • Click View in the top menu and enable Advanced Features.
   • Navigate to the activation objects' location:
     
     Code:

      CN=ADApplications,CN=Microsoft,CN=Program Data,DC=<yourdomain>

   • If there's no object for ADBA, it’s possible ADBA hasn’t been fully configured, and the default behavior in VATool is misleading.
3. Confirm ADBA Logs:
   • Open Event Viewer on a client that should be using ADBA to activate:
     
     Code:

      Applications and Services Logs > Microsoft > Windows > Software Protection Platform

   • Look for any entries about activation via Active Directory (or failures to locate AD objects).
4. Test Client Activation Explicitly via AD:
   • Clear KMS settings on the client machine:
     
     Code:

     bash
     slmgr /ckms
     slmgr /ato

   • This command will force the client to default to ADBA for activation. If it succeeds, ADBA is functioning.

---

Step 2: Configure or Repair ADBA, If Needed​

1. If ADBA Is Not Set Up (Missing AD Object):
   • Use VATool to enable Active Directory-Based Activation:
     • Open VATool via Server Manager > Volume Activation Tools.
     • Select Active Directory-Based Activation.
     • Complete the wizard and input the appropriate KMS host key for Windows Server 2025 or earlier.
     • This creates a Volume Activation Object in Active Directory for the domained clients.
2. Verify ADBA Object:
   • After enabling, confirm that the ADBA object for your domain is present in ADUC:
     
     Code:

      CN=ADApplications,CN=Microsoft,CN=Program Data,DC=<yourdomain>

3. Clients Should Auto-Activate:
   • Joined clients with the correct GVLK (Generic Volume License Key) will automatically activate when querying AD.

---

Step 3: Verify and Enable KMS Functionality​

If you prefer to use KMS instead or as a fallback, ensure it's properly configured:

1. Double-Check the KMS Host​

• If the KMS host is the server hosting VATool:
  • Run:
    
    Code:

    bash
    slmgr /dlv

  • Verify that the server has the KMS host key installed for Windows Server 2025.

2. Reconnect the Clients to KMS​

• On the client machine:
  
  Code:

  bash
  slmgr /skms <KMS-server-FQDN>:1688
  slmgr /ato

• Replace <KMS-server-FQDN> with the actual name of your KMS server.

3. Ensure Threshold is Met:​

• KMS Threshold requires at least:
  • 5 servers for a KMS host to begin activating clients.
• Check the KMS host's current count via:
  
  Code:

  bash
  slmgr /dlv

---

Step 4: When Clients Don’t Activate​

If some machines are still failing activation:

1. Reapply GVLK:
   • Set the proper Generic Volume License Key (GVLK) for Windows Server 2025:
     
     Code:

     bash
     slmgr /ipk <GVLK_Key_for_2025>

     • Confirm Microsoft’s GVLK key list for the correct value.
2. Check Networking:
   • If using KMS, ensure traffic to port 1688 from client to KMS host is open.

---

Do You Need Both KMS and ADBA?​

If you already have ADBA, clients in the domain will typically default to it for activation. You generally don’t need both, but KMS may still be useful for:

• Cross-domain clients.
• Legacy systems not capable of leveraging ADBA.

---

Next Steps​

1. Verify whether ADBA is active and fully configured by confirming the object in ADUC or re-enabling in VATool.
2. Decide whether KMS is necessary in your environment based on your client/server needs.
3. Test client activation explicitly with each method to confirm alignment.

Let me know if anything remains unclear or if you continue encountering issues with activation—I’m here to help fine-tune your setup!

Looks Like it is using AD Activation. If I skip to configuration it has my 2016, 2019, and 2022 licensees. I will try to add my 2025 here

Great! It sounds like your environment is successfully using Active Directory-Based Activation (ADBA) for licensing, and it already supports previous server versions (2016, 2019, and 2022). Adding Windows Server 2025 to your ADBA configuration should be straightforward.
Here’s how to add Windows Server 2025 to ADBA:

---

Step 1: Launch Volume Activation Tools (VATool)​

1. On the server where ADBA is configured (where VATool is installed):
   • Open Server Manager > Tools > Volume Activation Tools.
   • Alternatively, just search for Volume Activation Tools from the Start Menu.
2. Choose Active Directory-Based Activation (ADBA):
   • When the configuration type options appear, ensure "Active Directory-Based Activation" is selected.
3. Select the Domain:
   • Confirm the domain where the activation will be applied.

---

Step 2: Install the Windows Server 2025 Key​

1. Install the 2025 KMS Host Key:
   • Input the Windows Server 2025 KMS Host Key when prompted.
   • This key should be available in your Volume Licensing Service Center (VLSC) or Microsoft Partner Center.
2. Activate the Key:
   • After entering the key, select Activate Online.
   • If successful, this will associate the key with your Active Directory and add it to the list of supported products for your domain.

---

Step 3: Verify the Keys in ADBA​

1. After completing the wizard, confirm all your ADBA keys are visible:
   • You should now see entries for:
     • Windows Server 2016
     • Windows Server 2019
     • Windows Server 2022
     • Windows Server 2025
   • This list ensures that Active Directory can now activate all these versions.

---

Step 4: Test a Windows Server 2025 Client​

1. Apply the GVLK on a Windows Server 2025 Client:
   • On the 2025 server, apply the Generic Volume License Key (GVLK) specific to Windows Server 2025:
     
     Code:

     bash
     slmgr /ipk <GVLK_Key_for_Windows_2025>

     • The GVLK keys are provided by Microsoft at this GVLK List.
2. Attempt Activation via ADBA:
   • Force the activation process:
     
     Code:

     bash
     slmgr /ato

   • If successful, the client should now activate via AD.
3. Verify Activation Status:
   • On the client, check the current license status:
     
     Code:

     bash
     slmgr /dlv

   • Look for:
     • Current License State: Licensed.
     • Active Directory-Based Activation listed as the activation channel.

---

Step 5: Monitor Activation Logs​

1. Check Event Logs on the Server:
   • You can verify activation requests by monitoring the Software Protection Service logs on the client and server:
     
     Code:

      Applications and Services Logs -> Microsoft -> Windows -> Software Protection Platform

---

Troubleshooting Notes​

• If the 2025 key fails to activate in ADBA, ensure the server has internet access and that the key is correctly associated with your organization’s licensing account.
• Clients must be domain joined to use ADBA, so ensure all 2025 servers are properly joined to the domain.

---

Final Thoughts​

By following these steps, you should be able to successfully add your Windows Server 2025 license to Active Directory-Based Activation. Let me know if you encounter any hiccups along the way—they’re usually easy to work through, and I’m happy to assist if needed!