Office 2010 & Volume Activation

Office 2010 recently hit the RTM milestone and is now available for download via a couple of different channels.  For admins looking at deploying it, one of the biggest changes they will see relates to license keys & activation.  For previous office deployments, enterprises would establish a volume license agreement with Microsoft and then they would receive a volume license key (VLK).  They would then download a volume license (VL) edition of office, create a custom answer file, using the custom installation wizard or the Office customization tool depending on the version, run the setup with the answer file and be done.

For Office 2010 the process changes a little. The good news is that if you have deployed Vista or Windows 7, your pretty much set as Office now uses Volume Activation 2.0.  For those who haven’t though, a little time will need to be spent preparing your environments for Volume Activation.

KMS & MAK

The first question that needs to be answered is whether you will be using KMS or a MAK key. First let’s translate the acronyms into real words. KMS stands for Key Management Service while MAK stands for Multiple Activation Key. Now what’s the difference? MAK is like the traditional VLK, the difference being that the MAK still requires an initial activation that can be done over the internet, over the phone, or by using the Volume Activation Management Tool. The alternative is to use a KMS key.  The KMS key can be thought of a little like DHCP.  Activation clients discover a KMS host and get a license that is good for 180 days.  After 7 days the client will check back in with server and get it’s lease renewed.  If the client can’t contact the KMS host after 180 days then it falls back into an unlicensed state and the user will be notified that they need to activate their copy of office.

The decision on KMS vs MAK is going to hinge on a couple of factors.

1. Network connectivity – KMS requires that a client is able to contact the KMS host once every 180 days over TCP port 1688 (the port can be changed).
2. Activation limits – KMS requires a minimum of 5 clients to contact the KMS host before activation is successful.

The rule of thumb is generally if you have less than 50 machines to activate, go for MAK, more than 50 then go for KMS.

KMS Setup

If you decide to go down the KMS path then you will need decide what sort of machine will act as your KMS host.  The recommendation is that if you already have a KMS host deployed, then you should deploy the office KMS onto the same machine. This however raises a new concern.  The supported platforms for the office KMS host are

• Windows Server 2003 or with any service packs
• Volume license editions of Windows 7
• Windows Server 2008 R2

You may notice that there are a couple of omissions from that list, primarily Windows Server 2008 or Windows Vista.  The deployment guide specifically states that neither of them are supported, irrespective of the service pack deployed.  So this may force some organisations to either transition their existing KMS to a new machine, or alternatively deploy a new KMS host.  The reality of this though is that it is a fairly minor process.

1. Download the Office 2010 KMS Host License Pack
2. Run the executable to install the KMS host server
3. Enter your KMS license key and activate over the internet
4. enable a firewall exception for TCP 1688

And your good to go.  Well you are provided that your machine has internet access and your DNS supports SRV records and dynamic updates.

If your machine doesn’t have internet access you will need to activate the key over the phone, so to do that

1. open a command prompt and run the following command to get your installation ID (the guid is the activation ID for Office 2010)

   cscript slmgr.vbs /dti bfe7a195-4f8f-4f0b-a622-cf13c7d16864 

2. Then run this command to get the phone number for your region
   

   slui.exe 4 

3. Choose the option to activate your KMS key and enter the installation ID you got in Step 1. You will now get your 48 digit activation code, so it’s probably a good idea to write it down.  Also don’t make the mistake of using the installation ID you see in step 2.  It’s the windows installation ID and won’t help.
4. To finish the process, return to the command prompt and enter the command below, replacing ############ with the activation code you got in step 3
   

   cscript slmgr.vbs /atp ############ bfe7a195-4f8f-4f0b-a622-cf13c7d16864

The other component I mentioned above was DNS. KMS clients can discover KMS hosts in one of two ways.

1. Check for registry keys (here is the source)

   • SKU-specific value in the HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionSoftwareProtectionPlatformAppIDSKUIDKeyManagementServiceName REG_SZ registry value

   • AppID-specific value in the HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionSoftwareProtectionPlatformAppIDKeyManagementServiceName REG_SZ registry value

   • Global value in the HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionSoftwareProtectionPlatformKeyManagementServiceName REG_SZ registry value

   • SKU-specific cached KMS host (This is the cached identity of the host used in the last successful KMS activation.)

2. DNS SRV records and specifically an SRV record in the format of _VLMCS._TCP.contoso.com where contoso.com is the domain to which the client belongs.

If you only have a single KMS host in your environment and DNS that supports dynamic updates, then you are done.  If you have multiple DNS domains or multiple KMS hosts then there are a couple of extra steps you need to be aware of.

• Multiple KMS Hosts – Only the first KMS will successfully register as the SRV record will be owned by that server, so you need to create a new security group and add all the KMS hosts to that group, then change the permissions on the SRV record so that the group has permissions to modify the SRV record
• Multiple DNS domains – By default the KMS host will only register an SRV record in the domain to which it belongs, so you need to create a multi string registry value name DnsDomainPublishList under the HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionSoftwareProtectionPlatform key then restart the Software Licensing Service to get it to create the SRV records.  If you then look in the Application event log you should see an event ID 12294 indicating that the records have been successfully created. (for more details on this look here)

MAK Setup

MAK setup is really a bit of a misnomer as there is not much in the way of infrastructure required for MAK activation.

The simplest method of using MAK activation is to manually install office, enter the key then manually activate.

Obviously this won’t scale too well, so the next option is to create a custom install. To do this create a deployment share (i.e. copy the install CD to a network location) and then run the office customisation tool by running setup.exe /admin and then entering the MAK key on the licensing screen under the Enter another product key section (by default office 2010 is configured to look for a KMS server).

You would then install office and when it is opened for the first time, the timer for the activation grace period is started.  The user will then get 25 days before they are prompted to activate their copy of office.

This is a screenshot of what a user will see (have a look at this blog post by Ted Way from the office engineering team to get more on this process).

For MAK activation, there are three options, activate via the internet, over the phone, or through proxy activation. Unlike KMS which requires a one time activation per KMS host, MAK activation requires that each and every copy of office connect to the Microsoft activation servers.  Each MAK key has a specific number of activations associated with it.  If there is a significant change to the hardware on the machine, then Office will need to be reactivated. When the client reactivates, then this will also decrement the activations available for that key.

For the activation methods, internet & phone are both self explanatory, proxy is not quite.  Proxy activation refers to the use of the Volume Activation Management Tool or VAMT. The VAMT is used to query a machine, via WMI, for its unique ID (Client Machine ID or CMID) and the machine that is running the VAMT is then used to contact the Microsoft activation servers on behalf of the client.  This means that you can have machines that are located on an isolated subnet, but still activate them.  Using the VAMT you can also export the list of CMIDs to a file which can then be activated on another machine.

Volume activation tools

Office 2010 also includes a couple of new tools that can be used to manage activation on a client machine.

OSPPREARM.EXE

OSPREARM.EXE is used to rearm an office installation prior to imaging a machine for deployment.  Rearming is effectively the process of resetting the timer that office activation uses to work out when the grace period has expired and to notify the user.  If you don’t rearm your office installation prior to imaging, the first time a user opens office on an imaged machine, they will receive an activation notification.

OSPP.VBS

OSPP.VBS is the Office Software Protection Platform script and is the office equivalent of SLMGR.VBS of the Windows Software Licensing Management Tool.  Running this script from an elevated command prompt gives you the ability to do a whole bunch of things, the big ones being

• activate office
• show activation status & keys
• install or remove activation keys
• manage KMS host settings

So that’s the basics of Office 2010 volume activation. To get the full story check out these links

• Plan for volume activation of Office 2010
• Office Activation overview poster
• Deployment guide for Office 2010 download
• Volume Activation 2.0 for Windows Vista and Windows Server 2008  

Playing with some old school scripting techniques

This post may seem a little backward to some, given the newer alternatives such as Powershell or even vbscript, but the past couple of weeks have seen me playing a with script that has turned out to be pretty useful and I figured I would share.

The origins of this story then, I have a small customer who runs SBS 2003 premium in the office. Occasionally they would give me a call and complain that they couldn’t access the internet and that the server was offline.  They would then look at the console and it would be alive and they would be able to login without issue. I would get them to have a look at the services and they would report that the firewall service was not running.  They would then start it manually, then it would run like a champ and they would be happy.

The logs weren’t showing any major errors and the fact that once the service was started it all ran fine, we went with the easy option of creating a script that would check to see if the service was running, and if it wasn’t then to start it up.

Like any scripting solution, this could have been done a number of ways.  The simplest being to create a script that starts the service irrespective of its current state and then schedule to run at regular intervals.  To do this, you would open notepad, then type in the following

net start fwsrv

save that as a file named fw.cmd then schedule it using the AT.EXE command to run once at 11pm day by using this command

at 23:00 /every:M,T,W,Th,F "c:fw.cmd"

As a solution, this works, but it could be described as being a little base in its approach.  It works well for a single service, but if the service is already running, then there is not much point in trying to start it again.  So what if we could check the status of the service, and then if it is running, we’ll leave it be, but if its not, then we can start it? The first thing we need to do then is check the state of the current service, and as we’re trying to script this, opening the services console is not an option, we need something that will work from a command prompt and give us an output. This is where SC.EXE helps (that link is for the Windows Server 2008 version of the tool, so if you are using an earlier OS, be aware that the tool has evolved so check the help for the OS you are on).

To query the status of the firewall service, you run the command

sc query fwsrv

The problem with the output of this command is that the data we’re interested in, is on the 3rd line down, so we need a way to isolate that line so we can process it.  For this we can use the FINDSTR.EXE command.  In this instance, we need to find something unique on the line so we can query for it.  In this example I used STATE. So the next command we need is

findstr /i "state"

The /i switch is used to ignore the case of the word we are looking for.  I could have searched for “STATE” and not used the /i switch, it is just a habit that I have gotten into.

The next step then is to make a decision based on the state of the service. To do this, I use the FOR.EXE command.  If you have a look at the link, it can be a little daunting and it may not be immediately obvious as to how it is useful in this situation as the primary examples look at stepping through a file, so I’ll save time and show you the command and its output.

for /f "tokens=3" %i in ('sc query FWSRV ^|findstr "STATE"') do echo %i

The entry as displayed executes a command (‘sc query FWSRV ^|findstr "STATE"’) then looks for the third object in the output /f "tokens=3" and then assigns it as a variable named %i. In the example I have then used the ECHO command to see the value.

It is worth noting a couple of points regarding the format of the SC command within the brackets (‘sc query FWSRV ^|findstr "STATE"’).

1. The entire string needs to be placed within single quotes. If you don’t you’ll receive an error stating that “The system cannot find the file sc.”
2. The caret ^ is required before the pipe | or you will receive an error stating that “| was unexpected at this time.”

This now gives us a way of getting the numerical value of the current state of the service.  Having a value for the service means that we can then use an IF statement to make a decision on whether or not to start the service. From the output of the SC query above, we can see that a value of 4 means that the service is running (here is a link to a list of the seven possible values). What we need though is a way to pass the numerical value of the service state to the IF command, and for this, we can use an environment variable.  The command then now looks like this

for /f "tokens=3" %i in ('sc query FWSRV ^|findstr "STATE"') do set FW=%i

Putting all the pieces together then we end up with a script that looks like this.

:Query
for /f "tokens=3" %%i in ('sc query FWSRV ^|findstr "STATE"') do set FW=%%i
if (%FW%) EQU (4) goto :END else goto :start 

:start
net start fwsrv
goto :query 

:end 

 

As you can see, there are couple of formatting tweaks that are required to use the commands within a batch file. 

1. I added a couple of labels (:Query :start :end) to the script to support the use of the GOTO command.  The logic behind this is to provide a means to confirm that the service has started successfully and then to provide a means to jump out of the script.
2. The use of the double percantage (%%) is required when using a % within a script.

With the script complete, the next step then is set it up as a schedule task. I could use the AT command I showed you above, but in this instance I decided I would kick off the script once every two hours, so for this I used the scheduled tasks command line tool SCHTASKS.EXE.  The reason for using SCHTASKS.exe is that it offers more flexibility than AT.exe.

schtasks /create /SC HOURLY /MO 2 /TN CHECKFW /TR c:scriptsfwqry.cmd /ST 12:00

In this example, I saved the script as a file named c:scriptsfwqry.cmd and scheduled it to run once every 2 hours.

And that is it.  A script which will check once every two hours to see if a single service is running, and if its not, send a start command to the service.

But what if there is more than one service? This provides a great example of how you can take an existing script and with a little work, rework it for a new task.

For this scenario, I had a virtual machine setup that was running Office Communications Server 2007 R2 for a lab environment.  The vm in question was running as a standard edition server, and as such, had about 10 individual services that needed to be running in order for the server to operate correctly. In this instance, all the services have a prefix of RTC so this time the SC command is a little different

sc query state= inactive |findstr /i "RTC"

The command this time looks for all services that have a state of inactive (ie not running) and then we parse the output looking for the names of the services that start with RTC (e.g. RTCSRV).

When this is then rolled into the script, it looks like this

:Query
for /f "tokens=2" %%i in ('sc query state^= inactive ^|findstr /i "RTC"') do set SVC=%%i
Echo %FW%
if (%SVC%) == () goto :END else goto :start

:start
net start %FW%
SET FW=
goto query

:end

Like before, we need to modify the formatting to get it to work within a batch file

1. percent symbols (%%) need to be doubled
2. equal (=) and pipe (|) symbols need a caret (^) as a prefix so they are handled correctly.

The next step then is to check that a value has been set for the SVC environment variable.  If it is empty, then we know there are no stopped services with a prefix of RTC and we end the script, if it has a value we then send a start command to the service, reset the environment variable, and then re-run the query to look for stopped services with RTC as a prefix.

So there you have it, a couple of basic scripts that can be used to manage scripts within your environment.