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.
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):
The Windows CMID can be displayed with the command wmic softwarelicensingservice get clientmachineid
After SysPrep and capture the very same Office CMID is returned, so SysPrep doesn’t change the Office CMID:
The Windows CMID has changed as expected:
After running the ospprearm.exe, you will see that the OFFICE CMID has changed:
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:
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):
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:
You should also note that this issue is the same on Office 2010, just another path to the files:
“%PROGRAMFILES%Common Filesmicrosoft sharedOfficeSoftwareProtectionPlatformOSPPREARM.EXE” and
“%PROGRAMFILES(x86)%Common Filesmicrosoft sharedOfficeSoftwareProtectionPlatformOSPPREARM.EXE”
