Understanding Volume Activation Services – Part 3 (Microsoft Office Activation and Troubleshooting)

Part 1 and 2 of the series were dealing with KMS, MAK, and ADBA.
In part 3 we will focus on how to activate Microsoft Office using each of the three activation methods, and explain the limitation and best practices regarding each of them. This post will also deal with activation diagnostics and troubleshooting.

Series:

Part 1 – KMS and MAK
Part 2 – Active Directory-Based Activation
Part 3 – Microsoft Office Activation and Troubleshooting

Microsoft Office Activation

General information regarding Office activation

For Microsoft Office activation, and unlike the activation for Windows where the newest KMS host key can activate older versions as well, you should configure and install a dedicated KMS host key for each Microsoft Office version you use.
If, for example, There is a combination of Microsoft Office 2016 and Microsoft Office 2013 in your organization, you have to make sure there are two KMS host keys installed and available: One for 2013 and another one for Office 2016.

Another thing you should know about is the Microsoft Office Volume License Pack.
Microsoft Office Volume License Pack is an executable file which extracts and installs KMS host license files required for the KMS host service to recognize KMS host keys for Microsoft Office, including Visio and Project.
You should install the relevant Microsoft Office Volume License Pack according to the Microsoft Office version you would like to activate. The installation is performed on the server where you are running the Volume Activation Tools.
Microsoft Office Volume License Pack is required for both KMS and ADBA activation.
In case of ADBA, there is no need to install this on your Domain Controllers.

You can download Microsoft Office Volume License Pack in the following links:

Microsoft Office 2013 Volume License Pack – https://www.microsoft.com/en-us/download/details.aspx?id=35584
Microsoft Office 2016 Volume License Pack – https://www.microsoft.com/en-us/download/details.aspx?id=49164
Microsoft Office 2019 Volume License Pack – https://www.microsoft.com/en-us/download/details.aspx?id=57342

Microsoft Office GVLKs (Generic Volume License Keys), which enables Office to automatically discover and activate against a KMS server or ADBA, can be found in the following link: https://docs.microsoft.com/en-us/deployoffice/vlactivation/gvlks.
Pay attention that volume licensed versions of Office 2019 and Office 2016 are preinstalled with a Generic Volume License Key (GVLK), so no further action is required in this situation.

Using ADBA for Office Activation

Like in Windows, Office can use MAK or KMS channels for activation.
While KMS supports any Office version, Active Directory-Based Activation supports only Office 2013 and above when running on supported Windows Operating System (which is, as you know at that point, Windows 8.1/Windows Server 2012 and above).

So if, for example, you are running Office 2016 on a Windows 10 machine – you are good to go and can use Active Directory-Based Activation to activate Office.
If you are running Office 2013 on a Windows 7 client – KMS and MAK are your only options. ADBA is NOT supported in this case.

This is the place to say that KMS, ADBA, and MAK have nothing to do with Office 365 activation. Office 365 is activated automatically by cloud-based services associated with Office 365.

Like with Windows, it is recommended to use Active Directory-Based Activation if possible. If you have older operating systems or Office products like Windows 7 and Office 2010 which don’t support ADBA, use KMS along Active Directory-Based Activation. If Active Directory can’t be contacted, Microsoft Office will try to activate by using a KMS, so you shouldn’t worry about this.
MAK should only be used as a last resort where the KMS is not reachable or when the KMS limitations do not meet.

Reviewing Microsoft Office activation settings and status

Within the Microsoft Office installation folder (e.g C:\Program Files\Microsoft Office\Office16) you will find the ospp.vbs, a utility that can help you configure and test your volume licensed versions of Office, including Project and Visio.
You can think about ospp.vbs as the slmgr.vbs for Office products.

Here are the most common commands you would like to know:

ospp.vbs /inpkey: XQNVK-8JYDB-WJ9W3-YJ8YR-WFG99
This command changes the product key being used by Office. If there is already a product key configured, the /inpkey command will replace it with the provided product key. This can be relevant for situations where you have to move from MAK to KMS channel and vice-versa.
ospp.vbs /act
This command activates your Office product using the current configuration setup. After moving from MAK to KMS or when changing your activation configuration, you can run ospp.vbs /act to immediately try and activate your Office products.
ospp.vbs /sethst:KMSServerName.contoso.com
This command is used to manually configure the KMS host name that Office will try to activate with. This might come in handy in a situation where there is no _VLMCS record for auto discover the KMS server, or where the DNS service/resolving is not available for some reason.
ospp.vbs /dstatus
This command displays the license information for installed product keys. You can use the /dstatus to understand if and how your Office products are activated.

Here is a short video describing the use of ospp.vbs for displaying activation status and activate Microsoft Office with ADBA:

Troubleshoot activation issues for Windows and Office

Volume-Activation troubleshooting is quite simple if you understand how activation works and what you are doing.

There are a few common issues I would like to talk about in this post:

The computer is not running a volume-licensed edition of Windows Server or Office, making it irrelevant for KMS/ADBA activation.
KMS or Active Directory-Based Activation is missing the required KMS key for the specific Windows or Office version.
There is an issue with your Active-Directory-Based Activation or KMS deployment (unavailable for certain reason or misconfigured).

In order to understand what is the issue, I suggest starting with the slmgr.vbs /dlv (for Windows) or with ospp.vbs /dstatus (for Microsoft Office). This will help you better understand which activation channel is configured on the client, and what is the current activation status. If your product is using MAK channel, it will look similar to screenshot below:

To resolve this, use “slmgr.vbs /ipk <Relevant Product Key Here>” for Windows or “ospp.vbs /inpkey <Relevant Product Key Here>” for Microsoft Office to change your product key and move from a MAK channel to a KMS channel.
Then, run “slmgr.vbs /ato” or “ospp.vbs /act” to try and activate your product against the KMS/Active Directory-Based Activation.

Remember that by default, volume licensed versions of both Windows and Office are installed with a Generic Volume License Key (GVLK), so if you are installing the right versions, you shouldn’t encounter this issue.

If things still don’t work at this point, check the above:

Make sure that the client understands who is the KMS server (usually done by the DNS using the _VLMCS SRV record). Use nslookup to perform the test. If DNS resolving is not available for the specific client for some reason, you can use “slmgr.vbs /skms <KMSHostIP>” or “ospp.vbs /sethst <KMSHostIP>” to manually set the KMS server IP that the client will use.
Use Telnet to check if the client can contact the KMS server using port 1688. It is quite common to see clients behind a firewall that block traffic on the KMS port.
If your client can’t access the KMS server and you’re sure that no firewall restrictions are set, check that your KMS server is available and running using “slmgr.vbs <KMSHostname> /dlv”. If your KMS server does not respond as expected, try to restart the Software Protection Service.
Remember that Active Directory-Based Activation uses basic LDAP and Domain Services ports for activation and does not require any dedicated port like the KMS.
When using Active Directory-Based Activation, validate that the client is a member of a domain within a forest where ADBA was configured.
Make sure that your KMS or ADBA contain a relevant KMS key for the client’s OS. If, for example, the client is running a Windows Server 2019 datacenter edition and your Active Directory-Based activation has a KMS key for Windows Server 2019 standard only, the activation process will fail.

Final Thoughts

Well, this is the last blog post in the “Understanding Volume Activation Services” series.
I hope that now, after reading these posts, you have a better understanding about how Volume Activation is working and how you should use ADBA, KMS, and MAK for activating Windows and Office in your organizations.

Omer Eldan