Understanding Volume Activation Services – Part 2 (Active Directory-Based Activation)

In the previous part of the series, we talked about KMS, MAK, and how to choose between the two when looking for the right activation method in your environment.
Today, we are going to talk about Active Directory-based activation or ADBA in short.


What is exactly ADBA and why do you need it?

Like KMS, Active Directory-based activation (ADBA) is used to activate Windows and Office in your corporate network.
ADBA is a more reliable and redundant solution, and it has significant advantages compares to KMS which make it the best option for activating clients machines.
As you can guess by its name, ADBA relies on Active Directory Domain Services to store activation objects and transparently activate domain-joined computers.


There are few prerequisites for using Active Directory-based activation:

  • Schema version must be updated to at least Windows Server 2012.
    • There’s NO need for upgrading the forest or domain functional levels.
    • Older Domain Controllers (like DCs running Windows Server 2008R2) will be able to activate clients using ADBA as long as the schema is updated.
  • Computers who would like to activate against ADBA must be:
    • Domain-joined to one of the forest domains (ADBA is a forest-wide feature).
    • Running a Windows Server 2012/Windows 8.1 and above. Older operating systems (including Windows Server 2008R2, Windows 7) are NOT supported.


There are some major advantages for using ABDA over KMS:

  • No thresholds – Unlike KMS, ADBA does not require any minimum thresholds for start activating clients.
    Any clients request for activation is immediately activated by ADBA as long as there is a suitable activation object in the Active Directory.
  • Eliminate the need for SRV record and dedicated port – As we learned in the previous post, the KMS server is listening on port 1688 for client’s activation requests.
    Clients can find KMS server based on the _VLMCS SRV records located in the DNS.
    When using ADBA, clients are looking for activation objects in the Active Directory by using LDAP, and the communication is based on the default domain services ports. No dedicated ports, neither SRV records are needed.
  • High availability – Active Directory-based activation is, by design, a high availability activation method. Any Domain Controller which is part of the forest can be used to activate a client. You won’t need to create a dedicated server for KMS host anymore.

While ADBA has significant  advantages, it also has a few drawbacks:

  • No support for older Windows versions – ADBA can only activate Windows Server 2012/Windows 8.1 and above. Therefore, as long as your environment still includes older Windows versions like Windows Server 2008R2 and Windows 7, you’ll have to keep maintain other activation methods like KMS and MAK.
  • Domain-joined only – ADBA can activate domain-joined computers only. In other words, any workgroup machine or machine that belong to a different AD forest cannot be activated using the ADBA.

The good news is that ADBA and KMS can live together. You can use ADBA to activate new versions of Windows and Office and maintain a KMS host servers for activating old Windows and Office versions like Windows 2008R2, Windows 7 and Office 2010.

This might be a good opportunity to remind you that Windows Server 2008R2 and Windows 7 will become out of support on January 14, 2020.

Deploying Active Directory-based activation

In order to deploy Active Directory-based activation, we are going to use the same Volume Activation Tools feature we used to deploy the KMS host.
It is recommended to run the Volume Activation Tools from a management/administrative machine running Windows Server 2019. If you are running the Volume Activation Tools from a Windows Server 2016 or Windows Server 2012R2, please install the following KB’s before you continue (KBs are required for activating the newest Windows 10 Enterprise LTSC and Windows Server 2019):

For Windows Server 2016:

  1. KB4132216 – Servicing stack update, May 18 (Information, Download).
  2. KB4467684 – November Cumulative Update or above (Information, Download).

For Windows Server 2012R2:

  1. KB3173424 – Servicing stack update (Information, Download).
  2. KB4471320 – December 2018 Monthly Rollup (Information, Download).

ADBA uses the KMS host key for activating clients. Yes, it’s still called that name, as the KMS host key is used for both Active Directory-based activation and KMS activation method.
The KMS host key can be obtained from Microsoft VLSC.
Remember that you should only obtain and install the latest KMS host key for Windows Server available in VLSC. This is because:

  • A KMS host key of newer Windows version can be used to activate older Windows versions.
  • A Windows server KMS host key can be used to activate Windows clients.

When the Volume Activation Tools opens, skip the introduction phase and choose ‘Active Directory-Based Activation’ as your volume activation method.
Pay attention that you must be a member of the ‘Local Administrators’ group on the computer running the Volume Activation Tools. You also need to be a member of the ‘Enterprise Administrators’ group, because the activation objects are created in the ‘Configuration’ partition in the Active Directory.

In the next step, you’ll be asked to provide the KMS host key you obtained from the VLSC. Once again, this is the exact same key you used to activate the KMS host.
It is recommended to enter a display name for your new activation object. The display name should reflect the product and its version (e.g. ‘WindowsServer2019Std’).

Managing Active Directory-based activation

To be honest, there’s no much to administer and manage in ADBA.
From time to time, you’ll be required to install a new activation object for a new version of Windows or Office, but that’s all.
However, if you would like to view and delete currently installed activation objects, you can use either the Volume Activation Tools or the ADSI Edit (adsiedit.msc).

Using the Volume Activation Tools, select ‘Active Directory-Based Activation’, click ‘Next’ and choose ‘Skip to Configuration’.

In the next screen, you can see the installed activation objects, including their display name and partial product key.
If you would like to delete an activation object, just select the ‘Delete’ checkbox next to it and click ‘Commit’.

If you would like to see the activation objects in Active Directory, use adsiedit.msc to open the ‘Configuration’ partition, and navigate to ServicesMicrosfot SPPActivation Objects.
You can see that the object class is ‘msSPP-AcitivationObject’, and you can identify the object easily by using the displayName value in the ‘Attribute Editor’.

Reviewing ADBA client’s settings

After you enable ADBA and create the activation object in your Active Directory, supported client computers which configured to use ‘KMS Client Channel’ will be activated automatically against the ADBA.
The activation is given for a 180 days period, and clients machines will try to reactivate every 7 days (just like in KMS).
If for some reason, the ADBA activation failed (e.g activation object can’t be found/does not support the client OS), the client will try to use KMS activation as an alternative.

You can still use the slmgr.vbs script to manage and view activation settings.
Run ‘slmgr.vbs /dli’ to display the activation status. Pay attention to the “AD Activation client information”, which indicates that the client was activated using ADBA.

Other slmgr.vbs commands like ‘slmgr /ipk’ and ‘slmgr /ato’ can still be used to manipulate and configure the activation settings in the client machine.


Active Directory-based activation should be your top priority when considering volume activation models.
As it goes hand by hand with Active Directory, it provides you with high availability and eliminates the need for a dedicated server for activation.
ADBA is also great for small environments, where the number of computers does not meet the KMS activation threshold.
Remember that you can run ADBA next to KMS  if you still have earlier operating systems or workgroup computers in your network.

In the last post of the series, we’ll talk about Office activation and how to troubleshoot activation issues in your environment.


7 thoughts on “Understanding Volume Activation Services – Part 2 (Active Directory-Based Activation)

  1. Hi!
    If two departments share the same forest with two distinct domains, is it possible to ensure that one department is not consuming activations from the other department?

      1. Add Custom DACL (a new ad group) for ActivationObjects container to allow only specific department computers to read the container. Add all the specific computers in the new ad group.

        Once done, only the relevant department computers will be able to read MAK data and activate.

  2. I can’t seem to find the answer to this question definitively. It appears to me that this article answers it but I just want to confirm… If I am running all 2012 R2 AD DCs, at the 2012 R2 forest functional level, can I use a KMS host key for either Windows 2016 or 2019 to enter into the Volume Activation Tools wizard on the Manage Activation Objects page shown above? I know that when using a KMS host, I have to install a hotfix to get a 2012 R2 host to manage 2016 or 2010 clients. Is there something similar to do with ADBA, or does it just work automagically if you use the KMS Host key for the higher OS during initial configuration? I have tried using a 2012 R2 KMS host key for ADBA, but the problem is that 2016 servers do not activate because they can’t find it in AD.

    1. The KBs should be installed on the server that you are using to run the Volume Activation Tools (can be a different server, as a management server, or one of your Domain Controllers).
      After installing the KBs, the KMS host key will be recognized during the initial process in the Volume Activation Tools, and a new ‘Activation Object’ will be successfully created in AD.

      It doesn’t matter if your Domain Controllers are running Windows Server 2012 R2 or higher.
      This Activation Object will be used to activate any relevant products, no matter if the activated OS is newer than your Domain Controllers OS version.

      Hope it’s clear now.

      1. Thanks for the reply Omer. I wound up getting this working on Friday by installing the required hotfixes as you note above. I installed KBs 3173424 and 4471320 on the 2012 R2 server where I was running the VAT, and it then accepted the KMS host key for Windows Server 2019. However, it would not accept a 2016 KMS host key. I assume this is based on the KBs installed. Either way, I am able to get 2012 R2 servers to activate with GVLK license keys now.

        Thanks again.