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.
Series:
- Part 1 - KMS and MAK
- Part 2 - Active Directory-Based Activation
- Part 3 - Office Considerations & License Activation Troubleshooting
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.
Prerequisites
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.
ADBA Vs. KMS
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 2016:
- KB4132216 - Servicing stack update, May 18 (Information, Download).
- KB4467684 - November Cumulative Update or above (Information, Download).
For Windows 2012R2:
- KB3173424 - Servicing stack update (Information, Download).
- 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 Services\Microsfot SPP\Activation 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.
Summary
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.