Adding Office 2013 Rearm to LTISysprep.wsf in MDT

If you include Office as part of your deployment images and use KMS to activate Office, you need to rearm Office before running sysprep and capturing the image. If you skip this step, the systems you deploy will have the same Client Machine ID (CMID). When the CMID is not unique on a computer, you can experience problems activating Office (as I’ve experienced firsthand).

To rearm Office 2010 and 2013, run the ospprearm.exe command. You can find the executable at these locations, depending on which version of Office you are rearming:

Office 2010 – %Program Files%\Common Files\Microsoft Shared\OfficeSoftwareProtectionPlatform

Office 2013 – %Program Files%\Microsoft Office\Office15

Use %Program Files(x86)% if you have 32-bit Office installed on 64-bit Windows.

If you’re using MDT 2010 or later, LTISysprep.wsf will handle the rearm of Office 2010 for you automatically. If you’re including Office 2013 in your images, however, you will need to modify LTISysprep.wsf because it only checks for the 2010 version of ospprearm.exe.

Find the following section in LTISysprep.wsf:

		'//----------------------------------------------------------------------------
		'//  Rearm Office 2010 if it is present
		'//----------------------------------------------------------------------------

		If not UCase(oEnvironment.Item("SkipRearm")) = "YES" then
			For each sOSPPPath in Array(oEnvironment.Substitute("%ProgramFiles%\Common Files\microsoft shared\OfficeSoftwareProtectionPlatform\OSPPREARM.EXE"), oEnvironment.Substitute("%ProgramFiles(x86)%\Common Files\microsoft shared\OfficeSoftwareProtectionPlatform\OSPPREARM.EXE"))
				If oFSO.FileExists(sOSPPPath) then

					oLogging.CreateEntry "Re-arming Office 2010 activation", LogTypeInfo
					iRetVal = oUtility.RunWithConsoleLogging("""" & sOSPPPath & """")
					If iRetVal = 0 then
						oLogging.CreateEntry "Re-armed Office 2010 successfully.", LogTypeInfo
					Else
						oLogging.CreateEntry "Unexpected return code while re-arming Office 2010, RC = " & iRetVal, LogTypeWarning
					End if

				End if

			Next
		Else
			oLogging.CreateEntry "Re-arming skipped by user request.", LogTypeInfo
		End If

and after it, add the following:

		'//----------------------------------------------------------------------------
		'//  Rearm Office 2013 if it is present
		'//----------------------------------------------------------------------------

		If not UCase(oEnvironment.Item("SkipRearm")) = "YES" then
			For each sOSPPPath in Array(oEnvironment.Substitute("%ProgramFiles%\Microsoft Office\Office15\OSPPREARM.EXE"), oEnvironment.Substitute("%ProgramFiles(x86)%\Microsoft Office\Office15\OSPPREARM.EXE"))
				If oFSO.FileExists(sOSPPPath) then

					oLogging.CreateEntry "Re-arming Office 2013 activation", LogTypeInfo
					iRetVal = oUtility.RunWithConsoleLogging("""" & sOSPPPath & """")
					If iRetVal = 0 then
						oLogging.CreateEntry "Re-armed Office 2013 successfully.", LogTypeInfo
					Else
						oLogging.CreateEntry "Unexpected return code while re-arming Office 2013, RC = " & iRetVal, LogTypeWarning
					End If

				End If

			Next
		Else
			oLogging.CreateEntry "Re-arming skipped by user request.", LogTypeInfo
		End If

Now LTISysprep.wsf will rearm both versions of Office.

If you’re interested in how I discovered this change was necessary, keep reading.

Last summer as part of our fall semester prep, I updated our system images to include Office 2013. I had also upgraded Microsoft Deployment Toolkit (MDT) to 2012 Update 1 from 2010. As we started to deploy systems, it became obvious that there was a problem. Users were calling the Help Desk to report that Office wasn’t activated. Attempts to activate Office manually failed every time. I knew the problem wasn’t with the KMS servers because Office 2013 upgrades on existing systems activated normally.

After doing basic KMS troubleshooting, I realized that the Office CMID for the problem systems were all the same. It turned out that I neglected to rearm the Office installation on my master image before it was sysprepped and captured. Every system we deployed from that image was using the same CMID.

I assembled a script from others I found online to use WMI to query the Office Software Protection Service (for Windows 7) and the Software License Service (for Windows 8) and retrieve the CMID. I found 16 different CMIDs were in use, each one from a different master image that had been created and used. This problem wasn’t new with Office 2013; it had started with Office 2010 as well. I completely missed the memo on needing to rearm Office back when we moved to Office 2010 and was blissfully ignorant because we never ran into any issues until the move to Office 2013.

One side note: As mentioned on the Office Deployment Support Team blog, when you query a Windows 8 system, it returns the CMID for Windows and not for Office. I only have a few Windows 8 systems in production, so I didn’t try to get the CMID via other means. I discarded the info from the Windows 8 clients and made a note to check them manually later.

I used another script to rearm and activate Office on all the systems with duplicate CMIDs, and didn’t experience any further activation issues.