Skip navigation

Client Management

4 Posts authored by: Eric Hazeltine Employee
Share This:

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:

 

Step NamePurpose

Check Installed Software

Determine if Office 2013 is already installed, and if so, stop the operational rule.
Check Operating SystemEnsure the rule will not run on editions of Windows which are not supported by Office 2013
Registry Key VerificationCheck 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 SpaceEnsure that 10 GB of disk space is available, and stop the operational rule if there is not enough space
Advanced Message BoxAlert the user that Office is being upgraded, and that the system will reboot when complete.
End ProcessTerminate any running Office applications
Install PackageStarts the upgrade to Office 2013. This step is added automatically when the package is added to the Packages tab of the rule
Advanced RebootReboot the system when the upgrade is complete
Share This:

In Technical Support we often see customers with questions or difficulties installing Footprints Asset Core. In an effort to make this process more understandable and easier to follow we have decided to dedicate an article series dedicated to the installation of the Asset Core master and database in a variety of environments.

 

Over the next few weeks we will be posting new documents on configuring each type of database system, installing the master agent on Linux and Windows systems, and deploying client agents to your devices.

 

In order to make these new documents easier to find we will update this post each time a new segment is available, so make sure to check back often! Please feel free to comment and let us know what you think of the series and give us feedback.

 

Installation - Preparing a PostgreSQL database server for Asset Core

Installation - Preparing an Oracle database server for Asset Core

Installation - Preparing a Microsoft SQL database server for Asset Core

Installation - Master agent on Linux

Installation - Master agent on Windows

Installation - Console

Installation - Clients and:

Installation - Mac Clients with Apple Remote Desktop

Prepare your installation of a client on Mac OS X: enable ssh for root and manage services

Install Oracle JAVA on Linux to run a FPAC master and/or console or a FPSC server

Share This:

In Technical Support we often see customers with questions or difficulties setting up Operating System Deployment in Footprints Asset Core. In an effort to make this process more understandable and easier to follow we have decided to dedicate an article series dedicated to the setup and use of this powerful module.

 

Over the next few weeks we will be posting new documents on each step of the process from initial configuration of the OS Deployment Manager all the way through various types of captures and deployments.

 

In order to make these new documents easier to find we will update this post each time a new segment is available, so make sure to check back often! Please feel free to comment and let us know what you think of the series and give us feedback.

 

OS Deployment - Initial Configuration

OS Deployment - Capturing a standard image

OS Deployment - Deploying a standard image

OS Deployment - Capturing a sysprep image

OS Deployment - Deploying a sysprep image

OS Deployment - Example workflow

OS Deployment - Troubleshooting and additional information:

OS Deployment - Analyzing logs

OS Deployment - The image you have captured is only a couple of MBs

OS Deployment - Operation: Error mounting log share.

OS Deployment - There's no bootloader / It's not possible to access to the project's unattend.xml/txt

OS Deployment - A popup message saying that the project already exists every time you try to compile it

OS Deployment - Executing RunSysprep.bat doesn't restart the computer to boot PXE

OS Deployment - How to fix drivers that are not imported correctly

OS Deployment - PXE-E55: ProxyDHCP service did not reply to request on port 4011.

OS Deployment - How to clone, move and/or update your OSD managers

OS Deployment - How to build an OSD USB stick

OS Deployment - Prevent sysprep install to prompt for unsigned drivers

Share This:

We have just posted an update to FootPrtints Asset Core 11.6. To see a list of issues addressed in this update, please visit this knowledge base article. The article does include a download link, or you can click here to visit the updates page for FootPrints Asset Core to download this update.

Filter Blog

By date:
By tag: