I was recently involved with assisting our IT team use Asset Core to automate upgrading to Microsoft Office 2013, and I wanted to share the challenges we encountered, and how we addressed them in our environment. I will be detailing our upgrade to the 32 bit edition of Office 2013, as we faced a few additional challenges in our environment with this version (the 64 bit version was simpler, as there was no need to account for 32 vs 64 bit editions of Windows)
We started by using the Office Configuration Tool to configure the installation to be automated; specifically, the installer was configured to upgrade existing applications, keep the existing Outlook profile, and include the license key. More information on using the Office Configuration Tool to automate and customize deployments of Microsoft Office can be found in this TechNet article. The resulting .MSP file was then placed into the Updates folder in the Office installation source files.
After creating the MSP file with the OCT, we built a package containing the Office installation files, and set the run command so that setup.exe would be executed to perform the installation, and we started deploying the package to test systems.
During testing, we found that installations of Office 2007 were upgraded without issue, however, we ran into an issue with upgrading Office 2010. Specifically, due to an issue with the installer for Office 2010 SP1 SharePoint Workspace was unexpectedly installed on systems with Office 2010 (see Microsoft KB 2612800 for more details). Because Office 2013 does not include a new version of SharePoint Workspace, the shortcuts for SharePoint Workspace 2010 remained on the test systems after the Office 2013 upgrade was completed. Since our organization does not use SharePoint Workspace, and additional updates are needed to use SharePoint Workspace 2010 with Office 2013 (see Microsoft KB 2687364 for more information on this update)
We addressed this by using a Config.xml file to remove the SharePoint Workspace component before proceeding with the upgrade to Office 2013 (details in the above linked Microsoft KB article), however this presented another challenge to our deployment. Because we have a mix of 32 bit and 64 bit editions of Windows, we needed a way to run the Office 2010 setup.exe from a different path depending on the underlying OS, and ideally do this without needing to create separate operational rules for 32 bit vs 64 bit editions of Windows. This required us to create a batch file, which would determine if a 32 bit or 64 bit edition of Windows is running, and run the Office 2010 setup.exe from the appropriate location: "C:\Program Files\Common Files\Microsoft Shared\OFFICE14\Office Setup Controller\setup.exe" for 32 bit editions of Windows, and "C:\Program Files (x86)\Common Files\Microsoft Shared\OFFICE14\Office Setup Controller\setup.exe" for 64 bit Windows editions. This applied only to the 32 bit Office upgrade; SharePoint Workspace for 64 bit editions of Office 2010 can be removed by running "C:\Program Files\Common Files\Microsoft Shared\OFFICE14\Office Setup Controller\setup.exe" using the Execute Program operational rule step.
We elected to modify our existing package to include the config.xml, and batch script, rather than create a separate package for the uninstallation of SharePoint Workspace. We simply added these 2 files to the package, and changed the run command in the package parameters to start the batch script, rather than setup.exe (the batch script called the Office 2013 setup.exe after completing the removal of SharePoint Workspace). The attached archive includes copies of the XML and batch script used in our environment.
Now that we have a package which will upgrade Office 2007 or 32 bit Office 2010 to 32 bit Office 2013, we have to build an operational rule which will prevent the upgrade from being attempted on systems where attempting the upgrade would cause issues. Specifically, systems which perform the upgrade must:
- Not already have office 2013
- Use a version of Windows supported by Office 2013 (i.e. only upgrade systems running Vista or newer)
- Have sufficient disk space to download the package file, and complete the upgrade (we used a minimum free space of 10 GB)
- Not be using a 64 bit edition of Office 2010 (applies to the 32 bit version of this operational rule only; the 64 bit version of the rule would have a similar check, but stop the installation when a 32 bit version of Office 2010 is detected). More information on
We also wanted to alert the user that the upgrade was occurring, ensure that no Office applications are running before the upgrade and reboot the system when the upgrade is complete. The 32 bit version of the operational rule used the following steps:
Check Installed Software
|Determine if Office 2013 is already installed, and if so, stop the operational rule.|
|Check Operating System||Ensure the rule will not run on editions of Windows which are not supported by Office 2013|
|Registry Key Verification||Check the HKEY_LOCAL_MACHINE\Software\Microsoft\Office\14.0\Outlook\Bitness registry value to determine if the 64 bit edition of Office 2010 is installed, and if so, stop the operational rule (upgrading 64 bit editions of Office will be handled in a separate operational rule)|
|Check Disk Space||Ensure that 10 GB of disk space is available, and stop the operational rule if there is not enough space|
|Advanced Message Box||Alert the user that Office is being upgraded, and that the system will reboot when complete.|
|End Process||Terminate any running Office applications|
|Install Package||Starts the upgrade to Office 2013. This step is added automatically when the package is added to the Packages tab of the rule|
|Advanced Reboot||Reboot the system when the upgrade is complete|