DCM Script – Detect Office Activation Status and Activate if Unactivated

This one was a lot of fun and by “fun”, I mean a complete pain.

Recently, several of my helpdesk calls have been along the lines of “When I open Word, it says that it needs activating”. As I’d hope most people with more than 20 PCs to manage do, we use a Key Management Services (KMS) Server to activate all of our Windows and Office clients. Windows and Office are supposed to activate themselves either during the build process or very soon afterwards. However, the PCs need to phone back to the KMS server every 180 days to remain activated so either the PC hasn’t activated Office during the build process or its activation ticket has expired and it hasn’t managed to get a new one. Therefore, I needed a way to detect whether Office is activated on a computer and activate it if it wasn’t. Detect a state? Remediate it if it isn’t in a desired state? Hmm, this sounds like something thats perfect for DCM! So I went a-looking, seeing what I could see.

First of all, this post is written for 64 bit machines which are running 32 bit Office. However, if you’re running 64 bit Office or 32 bit Office on 32 bit Windows, it’s just a matter of adjusting the paths for the Office VBS script accordingly.

At first, I hoped that I could use pure PowerShell to fix this. There is a very handy CIM instance called SoftwareLicensingProduct which lists the activation status for the Microsoft products installed on your computer. I thought a simple Powershell command like:

would give me a nice base to work from. On my Windows 8.1 machine, it does; it lists all of the KMS products on your PC and their activation statuses. However, on Windows 7, that CIM instance only lists the operating system, not Office and unfortunately Windows 7 is what is installed on the vast majority of the computers in my workplace. So that meant going back to the drawing board.

I needed another way to get the activation status for Office. From Office 2010 onwards, there is a VBS script called ospp.vbs. It needs to be run with the cscript interpreter as it’s purely command line rather than GUI driven. There are several switches for it which perform operations like attempting an activation, clearing the activation status, setting the KMS server name and port and displaying the activation status of the various Office products. Running the following command:

returned the following output on my PC with Office 2013 Pro Plus, Project 2013 Standard and Visio 2013 Pro installed on it:

Apart from the KMS Server, that output is verbatim. There is some very useful information in there; the product license, the activation information, the KMS server it’s using to activate, how long the activation has left. It’s great! Unfortunately it’s also a big lump of text which isn’t especially useful by itself.

At this point, I could have just created a package which ran

That script runs the Office activation VBScript and saves the output to a text file in the user’s TEMP directory. It reads the created text file and dumps the entire lot into a variable called Things (I was experimenting, I couldn’t think of a better name once I had finished and hey, it worked! If it ain’t broke don’t fix it). It converts the text file into a series of PowerShell objects using the series of dashes to separate them, replaces any colons with equals signs and excludes the “Processing” and “Exiting” lines. It uses the ConvertFrom-StringData command to add and populate properties on the objects which is why the colons needed replacing. It then selects the particular properties that I’m interested in. The whole lot gets put into a array called ActivationStatus which I can now use to do what I need to do.

The script creates another object called Var and pre-populates it with a bit of random text. It runs through all but the last object in the ActivationStatus array (If you look at the text file output, you’ll see that the series of dashes appears twice at the end so my little routine creates a blank but not null object at the end of the array) and checks to see if the “LICENSE STATUS” property is equal to ‘— LICENSED —“. If so, it appends “OK ” onto the end of Var, if not it adds “Bad “. Finally, the script looks at Var and sees if the word “Bad” appears in it. If so, it echos back to ConfigMgr that Office is activated or not activated.

The remediation script looks like this:

Simple, no?

When you’ve created the Detection and Remediation scripts inside ConfigMgr, create a Compliance Rule which looks for a string called “Office Activated”. Then, as always, either create a new baseline and deploy it to a collection or add it to an existing one.