Search This Blog

Friday, August 14, 2015

Rearming Office

When we include Office 2013 in our Build & Capture Task Sequences and use KMS (Key Management Service) we must always remember to rearm Office.

If Office is not rearmed then 25 days after deployment your users will get a notification dialog right after deployment of their new Windows.

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.

image

When installing Office we get a 25-day grace period, This is calculated from the day when Office installed in the image and captured to the day we deploy the image. If the difference is more than 25 days, notification will be shown.

From Rearm the Office 2013 installation :

There is a 25-day grace period from the time of installation of Key Management Service (KMS) clients before notifications to activate are displayed to the user. If you want to deploy an image, you must rearm your Office 2013 installation before you capture the image. If you do not rearm, users see notification dialog boxes at the time that the image is deployed, instead of 25 days after deployment. The 25-day grace period gives ample time for a KMS host to be found and activation to succeed. If activation is successful, users do not see notifications to activate.

Rearming does the following important tasks:

  • Resets the grace timer to 30 days.
  • Freezes the grace timer until either an Office application is run, or the ospp.vbs script is run.
  • Resets the client computer ID (CMID). This is important because the KMS host uses the CMID to determine the number of unique clients.

On Windows 7 you can display the Office CMID with this command cscript.exe ospp.vbs /DCMID (path must be Office15 installation folder as shown here):

image

The Windows CMID can be displayed with the command wmic softwarelicensingservice get clientmachineid

image

After SysPrep and capture the very same Office CMID is returned, so SysPrep doesn't change the Office CMID:

image

The Windows CMID has changed as expected:

image

After running the ospprearm.exe, you will see that the OFFICE CMID has changed:

image

On Windows 8 ospp.vbs /dcmid will show the Windows CMID as explained here:

Windows CMID is returned by OSPP.VBS script when running Office 2013 on Windows 8

To find the Office CMID you will have to find eventID 12288 (application event log) and activating request ending with a “5” as shown:

image

OK - now we know why it its important to use ospprearm.exe, let see an example from a SCCM Task Sequence (you can also use a script but remember there are one version for Office x64 and another for Office x86):

image

image

You will notice that both versions are executed, but a condition will make sure that the command is only executed if the file is present on the system:

image

image

You should also note that this issue is the same on Office 2010, just another path to the files:

“%PROGRAMFILES%\Common Files\microsoft shared\OfficeSoftwareProtectionPlatform\OSPPREARM.EXE" and

“%PROGRAMFILES(x86)%\Common Files\microsoft shared\OfficeSoftwareProtectionPlatform\OSPPREARM.EXE"

No comments:

Post a Comment