Deploying Volume Activation for Office 2010

In this post I will be showing you how to use ospprearm.exe as part of a MDT Task Sequence to rearm Office 2010

Volume Activation in Windows 7 and Office 2010 uses Key Management Service (KMS) or Multiple Activation Keys (MAK). In an enterprise environment, it is highly recommended to use the same KMS infrastructure for the activation of Windows Server 2008, Windows 7, Windows Server 2008 R2, and Office 2010. A KMS for Windows can be set up following the Volume Activation Deployment Guide, and the same KMS can be enabled for Office 2010 activation with the Microsoft Office 2010 KMS Host License Pack.

Normally, KMS activation of Office 2010 happens without issues. But if you installed Office 2010 as part of a master image, and deployed that image 25 days later, you could get notification dialog boxes immediately following the deployment of that image. As shown below, the text of the notification would be:

This copy of Microsoft Office is not activated

This copy of Microsoft Office is designed for corporate or institutional customers. Connect your computer to your corporate network to complete activation. Your system administrator can help.

clip_image002

As described in Deploy volume activation of Office 2010, the notification is caused by the expiration of the 25-day grace period, from the day when Office 2010 is installed in the master image (and then captured), to the day when the master image is deployed. If the difference between these two points in time is more than 25 days, notifications to activate are displayed to the user.

You might be wondering - you sysprepped the machine during the image capture, so why is this happening? The problem is that sysprep does not have the capability to automatically rearm Office 2010. The solution, therefore, is that all Office 2010 installations should be rearmed before capturing the master image. Details to automate this process, as part of the Task Sequence, are provided below.

By design, the 25-day grace period should give ample time for a KMS host to be found and activation to succeed. If activation is successful, users do not see notifications to activate. All Office 2010 volume products have the KMS client keys preinstalled, and using a KMS key vs. a MAK key can be selected using the Office Customization Tool.

Note: Besides the activation notification caused by not rearming Office 2010, there stands a chance that Office activation might never happen, due to the same Office 2010 CMID for all computers, as described for Windows 7 activation in KMS Host Client Count not Increasing Due to Duplicate CMID'S. While this article refers to activation not happening for Windows 7 because of duplicated CMIDs, as what can happen if VMs were cloned without using sysprep /generalize, what isn’t necessarily clear is that there is a separate CMID for Office 2010, independent of the Windows CMID. This means that if you don’t rearm Office 2010 (analogous to not running sysprep /generalize on Windows 7, thereby not “rearming” Windows 7), and capture that installation as a master image, all deployments of that image will have the same Office 2010 CMID. Then, Office 2010 will never activate beyond the first machine where that image is deployed.

Bad, huh? So, remember, rearm Office 2010, and system /generalize Windows 7 (the latter is automatically done with MDT or MDT-integrated ConfigMgr Task Sequences).

Rearming the Office 2010 Installation during the Build Task Sequence

Office 2010 can be rearmed with the following batch file as a task in the Build Task Sequence, executed immediately after the installation of Office 2010:

rearmOffice2010.cmd

@echo off

IF /i "%PROCESSOR_ARCHITECTURE%" == "AMD64" "%PROGRAMFILES(x86)%\Common Files\microsoft shared\OfficeSoftwareProtectionPlatform\OSPPREARM.EXE"

IF /i "%PROCESSOR_ARCHITECTURE%" == "X86" "%PROGRAMFILES%\Common Files\microsoft shared\OfficeSoftwareProtectionPlatform\OSPPREARM.EXE"

Alternatively, the commands above can also run as a VBScript:

runOffice2010rearm.vbs

'==========================================================================

' NAME: runOffice2010rearm.vbs

' AUTHOR: Charlie Chen (MCS), Microsoft Corp.

' DATE : 1/24/2011

' COMMENT: To be executed after the installation of Office 2010 install,

' but before capturing the master image.

' Rearming Office 2010 is important:

' https://technet.microsoft.com/en-us/library/ee624357.aspx\#section4

' As sysprep does not automatically rearm Office 2010:

' https://technet.microsoft.com/en-us/library/ff678211.aspx

'==========================================================================

strComputer = "."

Set objWMIService = GetObject("winmgmts:" _

& "{impersonationLevel=impersonate,authenticationLevel=Pkt}!\\" _

& strComputer & "\root\cimv2")

Set colSettings = objWMIService.ExecQuery ("SELECT Architecture FROM Win32_Processor")

Set oShell = WScript.CreateObject ("WScript.Shell")

CommonProgramFilesx86 = oShell.ExpandEnvironmentStrings("%CommonProgramFiles(x86)%")

CommonProgramFiles = oShell.ExpandEnvironmentStrings("%CommonProgramFiles%")

For Each objProcessor In colSettings

If objProcessor.Architecture = 9 Then

'64-bit OS

oShell.run Chr(34) & CommonProgramFilesx86 & "\microsoft shared\OfficeSoftwareProtectionPlatform\OSPPREARM.EXE" & Chr(34),1,True

ElseIf objProcessor.Architecture = 0 Then

'32-bit OS

oShell.run Chr(34) & CommonProgramFiles & "\microsoft shared\OfficeSoftwareProtectionPlatform\OSPPREARM.EXE" & Chr(34),1,True

End If

Next

Set colSettings = Nothing

Set oShell = Nothing

Rearming the Office 2010 Installation during the Deploy Task Sequence

If a master image contains Office 2010 and the rearm was not performed, the rearm can also be executed in the Deploy Task Sequence. This can be performed by using the script in the following blog:

https://blogs.technet.com/b/odsupport/archive/2010/06/14/troubleshooting.aspx

However, the preferred method is to rearm Office 2010 in the Build Task Sequence, so that the rearm gets captured as part of a master image.

This post was contributed by Charlie Chen, a Consultant with Microsoft Services US with contributions from Barry Hartmann a Senior Consultant with Microsoft Services US

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use