Geek of All Trades: Automatically Deploying Microsoft Office 2010 with Free Tools

You can’t avoid Office 2010, but you can find other ways to automate installation with any of these free tools.

By Greg Shields

Love it or hate it—Microsoft Office has been the centerpiece of business application infrastructures for years. Contact databases connect with Outlook. Financial applications interact with Access and Excel. Database reports are output into nicely printable Word formats. Nearly every application relies on some piece of the Microsoft Office suite to perform at least a portion of its duties.

That being the case, to be a good applications administrator means you have to be a great Microsoft Office administrator. And being a great Microsoft Office administrator—even for the jack-of-all-trades IT professional—means knowing how to install and tailor it for your specific needs.

Unfortunately, automating Microsoft Office installations often involves shoe leather and a healthy dose of Next, Next, Finish. However, your next installation of Microsoft Office needn’t necessarily involve you ever leaving your desk. While you can automate installation with solutions like System Center Essentials and System Center Configuration Manager, there are alternatives that don’t cost you any additional cash.

Group Policy is one alternative. You may have read that installing Microsoft Office 2010 through Group Policy doesn’t work with Group Policy Software Installation. However, there’s another solution using startup scripts that will work for the small environment. If you build that solution correctly using the right Microsoft tools and scripts, you’ll even get a tiny bit of reporting that helps you know the status of every desktop’s upgrade.

It’s not the greatest or smoothest solution, but for the price it’s absolutely worth a look. If you’re considering an upgrade to Microsoft Office 2010 but just don’t have the time, consider this quick step-by-step process that could upgrade your entire office to Microsoft Office 2010 overnight.

Step 1: Customize Office Setup with the OCT

The Microsoft Office media comes in two slightly different flavors. The Volume Licensing version includes a helpful extra called the Microsoft Office Customization Tool (OCT). It’s a wizard-driven interface for tailoring your Microsoft Office installation at the point of installation.

This tool has come with the last few versions of Microsoft Office. You won’t find the OCT with the off-the-shelf version of Microsoft Office, but it can be downloaded from the Microsoft Office 2010 Administrative Template files (ADM, ADMX/ADML) and Office Customization Tool page.

You’ll know you’re using the Microsoft Office Volume Licensing version if a \Admin folder already exists in its media. If it isn’t there, unpack the media to a folder on your desktop, create a \Admin folder, and copy what you downloaded to that folder. Then run setup.exe /admin to launch the OCT.

Figure 1 The Microsoft Office Customization Tool

No matter how you get your hands on a copy of OCT, the product of this tool (see Figure 1) is an MSP file. That file instructs a Microsoft Office installation to make special changes during configuration. Figure 1 shows one of those changes, telling the installation to use a specific Multiple Activation Key (MAK). This also tells the installation to run silently by setting the Display level to None and checking the box marked Suppress modal. You’ll need these silent settings later to install Microsoft Office 2010 through Group Policy.

Figure 2 The Microsoft Office Customization Tool can modify user settings.

The OCT exposes an impressive number of ways in which you can tailor an installation. Figure 2 shows an exhaustive list of user-setting modifications you can lock down or otherwise configure at installation. There are other settings available for tuning highlighted in the Microsoft Office 2010 Resource Kit.

Of all these settings, the most important are ensuring that your license information and silent installation settings are configured. You’ll also want to identify which Microsoft Office applications should or should not be installed in the section marked Set feature installation states. You can consider all other settings optional, although you’ll want to review each one to validate whether it suits your needs. Then save the resulting MSP file, as you’ll need to use it later.

Step 2: Create a Distribution Folder

To install or upgrade Microsoft Office 2010 with a Group Policy startup script, you’ll obviously need a set of source files. Create a share somewhere within your network, and ensure that the “Everyone” group has Read rights to both the share and underlying NTFS permissions. Unpack and copy the Microsoft Office 2010 media to this location.

Step 3: Configure config.xml

While this step might seem redundant, it’s an essential part of the automated installation setup. Look inside your Microsoft Office distribution folder for a folder whose name resembles the Microsoft Office edition you intend to install. This folder will have a .WW extension. Inside this folder, there will be a file called config.xml. Open this file in Notepad and look for a line similar to the one here; change the values of that line to the following:

<!-- <Display Level="none" CompletionNotice="no" SuppressModal="yes" AcceptEula="yes" /> -->

These values further ensure silent installation. Because a Group Policy startup script is running the installation, you won’t want your users to see any installation screens or be prompted with questions. You can ignore the other lines in the file. Then save the file and remember its location.

Step 4: Download and Modify the Group Policy Startup Script

Microsoft provides a sample Group Policy startup script in the Microsoft Office 2010 Resource Kit. This startup script is important because it includes logic that prevents the installation from repeating at every desktop reboot. Copy and paste this script into Notepad.

This script checks for a certain registry key prior to starting installation. If that registry key is there, it assumes the installation is complete. Thus, it skips the installation. This tiny bit of logic lets you keep the startup script operational even as your users reboot their desktops over time.

The sample startup script requires that you customize four lines from the code block below:

set ProductName=Office14.PROPLUS
set DeployServer=\\FS\Office2010SourceFiles
set ConfigFile=\\FS\Office2010SourceFiles\ProPlus.WW\config.xml
set LogLocation=\\FS\Office2010LogFiles

Line one is the hardest of these to understand. Look back at the folder in Step 3 where you found the config.xml file. You found that file with a .WW extension, within the folder relating to the type of Microsoft Office edition you intend to install. For example, the folder name for the volume license flavor of the Microsoft Office Professional Plus 2010 Edition will be proplus.WW. Replace PROPLUS in line one with the name of that folder, minus its .WW extension. For most of us, it will remain PROPLUS.

Line two is the UNC path to the distribution folder you created in Step 2. Line three will be the UNC path to the config.xml file you modified in Step 3. Line four is where you configure that aforementioned tiny bit of reporting. You’ll notice in the previous example that line four points to a different share on the file server: \\FS. Create this folder and enable it for sharing. Its share and underlying NTFS permissions should be configured to grant Modify access to the “Everyone” group.

Assuming you’ll be installing x86 in nearly every instance (see “64-Bit or 32-Bit?”), your share will include a set of folders for each of the Office applications. One of those folders is titled \Updates. This is a special folder the Microsoft Office installer routine uses. Any MSP files that are copied to this folder will be automatically installed during the Office installation. This includes any updates or patches that you want automatically installed. It also includes the MSP file that you created in Step 1. Drop that file into this folder to instruct the installer to use your customizations.

Figure 3 A report from two installation attempts on the computer MYKA.

Every installation of Office 2010 will send information about the success or failure of the install process. Each computer will create a TXT file with its computer name as the filename (see Figure 3). For a successful installation, that TXT file’s contents should resemble:

Mon 07/19/2010 13:15:54.20 Setup ended with error code 0.

Any other error code means something went wrong with the installation, and you’ll have some troubleshooting to determine why. Be aware that in testing this approach, some of my clients actually needed to run installations more than once. While the first installation responded with a non-zero error code, a subsequent manual installation succeeded with error code 0. This tiny bit of reporting gives you the positive affirmation that your Microsoft Office 2010 installations or upgrades are completing successfully. Save the file once you’re complete, as you’ll be using it in the next step.

Step 5: Create the Group Policy Object

The final step in this process is to create the Group Policy Object (GPO) that will deploy the startup script. Do this within the Group Policy Management Console by creating a new GPO and linking it to an Organizational Unit that is full of Computers (not Users).

Figure 4 Properties of a startup script

Edit the policy and navigate to Computer Configuration | Policies | Windows Settings | Scripts (Startup/Shutdown). Double-click Startup in the right pane to see a Properties screen similar to Figure 4.

Click the Show Files button to open an Explorer window at the exact location where you’ll need to copy your startup script from Step 4. Copy that script into the resulting Explorer window and close the window.

Finally, back at the Properties screen, click the Add button and type in the name of the BAT file you just copied. In Figure 4, you can see the name of my BAT file is Office2010StartupScript.bat.

Configuring Group Policy like this will not begin the Microsoft Office installation until the next reboot of the computer. You want the installation to occur with the necessary elevated rights for installation. The installation can take a while, so initiating that first reboot of computers after hours might be a good idea.

Step 5: Create the Group Policy Object

Ain’t the Greatest, but It Sure Is the Cheapest

While this solution is admittedly not the best on the planet for completing your Microsoft Office 2010 installation or upgrade, it is the one that costs you the least. You don’t need an automated software deployment solution. You don’t need expensive packaging software. All you need are a few free tools, and a little testing. The Deploy Office 2010 by using Group Policycomputer startup scripts page provides even more detail about the process, but this handy step-by-step will get you started.

Greg Shields*, MVP, is a partner at Concentrated Technology. Get more of Shields’ Jack-of-all-Trades tips and tricks at ConcentratedTech.com.*

Sidebar: 64-Bit or 32-Bit?

At this point, you might be asking yourself a question: Today’s world is all about x64, but is x64 a good idea for Microsoft Office? Even Microsoft recommendations suggest “no” unless you have very specific requirements. Microsoft gives the following recommendations on when you might install the Office 2010 x64 version:

If users in your organization depend on existing extensions to Office, such as ActiveX controls, third-party add-ins, in-house solutions built on previous versions of Office, or 32-bit versions of programs that interface directly with Office, we recommend that you install 32-bit Office 2010 (the default installation) on computers that are running both 32-bit and 64-bit supported Windows operating systems.

If some users in your organization are Excel expert users who work with Excel spreadsheets that are larger than 2 gigabytes (GB), they can install the 64-bit edition of Office 2010. In addition, if you have in-house solution developers, we recommend that those developers have access to the 64-bit edition of Office 2010 so that they can test and update your in-house solutions on the 64-bit edition of Office 2010.

As you can see, the answer for nearly every user will be “no,” except when that user needs to run monster Excel spreadsheets or if you plan to deploy software that itself needs a x64 version of Office. Most other users will work fine within x86’s memory boundaries.

—G.S.

Related Content

• Plan an upgrade to Office 2010
• Utility Spotlight: The Compatibility Question
• Utility Spotlight: Configure Office 2010 with the Office Customization Tool