The Office 2010 Office Customization Tool (OCT) can add and remove files to/from a computer that is installing Office. These are the steps in the OCT where you can add and remove files:
Notice the text in the Add files step; Specify files to add to the user’s computer during installation. When you exit this tool, copies of the files are saved in the Setup customization file. Notice also the Location column; [AppDataFolder]Microsoft…
So in the example above the normal.dotm and Word.officeUI files will be added to the MSP (Windows Install Patch) file.
When you deploy Office to a computer the files are copied from the MSP file into the [INSTALLLOCATION]Microsoft OfficePatchFiles and renamed with GUIDs as their names:
Now, looking back at the Location column in the Add files step in the OCT we can see that the files in this example are to be copied into the [AppDataFolder]Microsoft… etc. A user’s AppData folder is stored in the %APPDATA% environment variable and it’s usually something like: c:Users%username%AppDataRoaming. But since all users who log on to the computer, not just the one installing Office, needs these files they are copied from the PatchFiles folder into the AppDataRoaming folder for each new user who starts one of the Office applications. This feature also works the same way when Office is installed by the SYSTEM account, and not a user; the files are copied from the MSP file into the PatchFiles folder and from there to the user’s AppData folder.
Office 2010 Professional Plus (32-bit) deployed to Windows XP Professional Service Pack 3 (32-bit) clients with System Center Configuration Manager (SCCM) 2007 R2 (64-bit). Office 2010 configured with Office Customization Tool (OCT) according to Microsoft guidelines.
Upon completion the installation would initiate a forced reboot without prompting the user or giving any warning. After the reboot the Office 2010 installation would continue, but since it already completed before the reboot, this would be interpreted as a modification, prompting the user to select Add/Remove components, change product key etc. This, however, was not visible to the user since the program was configured to run without user interaction in SCCM. The result was that the Configuration Client (CcmExec) would wait for setup.exe for the maximum allowed run time and then terminate setup.exe, logging the installation as a failure. The whole process looked like this in the SCCM Advertisement Status report:
||Message State Name
||Waiting for content
||Program failed (unexpected restart)
||Program failed (run time exceeded)
At 11.11.2011 08:29 Office 2010 restarts the installation after the reboot, even though it actually succeeded before the reboot, and the reboot is just to complete the installation. This is interpreted as a modification to the existing install and setup.exe prompts the user for what modifications to make. The user cannot see this, however, because he cannot interact with the program. CcmExec lets setup.exe run until the max run time is reached and then terminates setup.exe (11.11.2011 13:28) logging the install as a failure.
The Office 2010 setup log, located in %systemroot%System32Temp indicates that the install is successful, but that a restart is needed.
To work around this problem it is necessary to suppress the reboot. This is done by adding the following to the MSP file in OCT (or the equivalent to config.xml):
With this setting in the MSP file the installation of Office 2010 will not be “fooled” by its own restart and complete successfully. You will first receive a status of Program completed successfully (reboot pending), until you initiate a restart on your own. After this restart the status will change to Program completed with success. Office 2010 seems to be fully functional even without performing this restart immediately, but the advertisement status in SCCM will not change until you restart.
Reports from other who have experiences similar issues indicate that the forced restart only happens on Windows XP computers, not Windows 7. I have not tested this myself.
OK, so this post is more of a public note-to-self.
I wanted to reinstall a Lenovo X1 portable computer. While preparing to wipe the machine I used ProduKey from NirSoft to extract the product keys for the installed software. This particular machine was sold with an OEM license, for which the product key was affixed under the machine. I quickly noticed that the key printed on the label did not match the one extracted from the machine with ProduKey. That meant that the machine was BIOS or OEM activated.
I now had two choices; I could bring the OEM activation with me over to my new install or just use the key printed on the sticker. The last option would have been the easiest, but that’s not how I roll. So how to “extract” the OEM activation?
A friend of mine had previously gone through just this scenario with a bunch of HP machines so I knew that the activation was dependent on a digital certificate, distributed by Lenovo with the machine and signed by Microsoft. Unfortunately the certificate file had been deleted by Lenovo setup. But the Lenovo recovery partition (Q:) included a WIM file called cdrivebackup.wim. This WIM was used by the recovery system to reinstall the machine in the event a failure occurred. It probably included the needed certificate. But first I had to make the contents of the recovery partition visible so I could easily copy the files to another computer and mount the WIM. This was accomplished by these two commands:
- echo y | icacls “Q:*” /grant Administrators:F /T
- attrib -R -A -S -H “Q:” /S /D
I then copied the entire contents of the Q drive to a memory stick and mounted the WIM with DISM on another computer:
- dism.exe /Mount-Wim /WimFile:h:LenovoRecoveryFactoryRecverycdrivebackup.wim /index:1 /MountDir:D:wimmount /ReadOnly
Now it was time to try and find the certificate (software license certificate have an xrm-ms extension):
- dir d:wimmount*.xrm-ms /s
This command yielded many files but only the one called lenovo.xrm-ms in the d:wimmountswworkOEM was of interest. I copied the file to a memory stick and proceeded to wipe the machine and reinstall Windows 7. After Windows 7 was installed I created a new folder under %windir%system32oem and copied the certificate into it. Now I could install the certificate and product key;
- cscript %windir%system32slmgr.vbs -ilc %windir%system32oemlenovo.xrm-ms
- cscript %windir%system32slmgr.vbs -ipk 237XB-GDJ7B-MV8MH-98QJM-24367
Now, the product key is kind of interesting. This key will be accepted as a valid key by Windows, but will not be able to activate the machine without the certificate file. It’s kind of like a KMS client key, but instead of a KMS Host it needs a certificate. As far as I can tell this key is Lenovo specific so I hope I haven’t infringed on any copyrights etc. by posting it here.