Subscribe to Windows IT Pro
October 30, 2007 12:00 AM

Automating Office 2007 Deployment

Economical and practical methods for deploying the latest version of Office
Windows IT Pro
InstantDoc ID #97016
Rating: (23)
Downloads
97016.zip

 

Executive Summary:
Previous Microsoft Office versions could be deployed using Group Policy Software Installation (GPSI). However, it's not recommended that you deploy Microsoft Office 2007 using GPSI. Instead, you must use Systems Management Server (SMS) or System Center Configuration Manager to do so, or find an alternative, more cost-effective deployment method.

 

A few months ago, in “Customizing and Deploying Office 2007,” May 2007, InstantDoc 95433, I walked through how to deploy Microsoft Office 2007 by creating a network installation point with a series of customizations, including setup customization (.msp) files and configuration (config.xml) files, to drive the behavior of Office Setup. Now that you’ve had time to prepare an installation of Office 2007, you can turn to the task of deploying Office 2007 to your clients. Let’s take a quick look at some familiar deployment methods that, unfortunately, aren’t necessarily ideal for Office 2007, then explore workarounds for deploying Office 2007 that won’t stretch your budget. You can also use these workaround methods to deploy other software and configurations— sort of a do-it-yourself Systems Center Configuration Manager.

Preferred Deployment Methods and Dead Ends
For software deployment, several methods come to mind. The first method is to use Group Policy Software Installation (GPSI) to deploy Office .msi files. Three previous Office versions could be deployed using GPSI, however, deploying Office 2007 using GPSI isn’t really a feasible option. Nevertheless, Microsoft documents how to deploy Office 2007 using GPSI (see “Use Group Policy Software Installation to deploy the 2007 Office system” at technet2.microsoft.com/Office/en-us/library/efd0ee45-9605-42d3-9798-3b698fff3e081033.mspx), and Darren Mar-Elia discusses the Group Policy deployment of Office 2007 in “The Group Policy Route to Office Deployment and Management,” April 2007, InstantDoc ID 95210.

Despite what these information sources say, I can tell you from my experience doing lots of testing that deploying Office 2007 using GPSI isn’t practical, even if it’s technically doable. GPSI uses .msi files with transforms (.mst files), whereas Microsoft architected Office Setup to use the Setup command (setup.exe) with .msp files to drive installation, so you’ll find that GPSI doesn’t support the kind of functionality and customization that you need. With GPSI, you must perform all customizations in the config.xml file, and even then you can customize only a few settings, such as the product key, language, and applications to install. And trying to configure which applications to install by using the OptionState element of the config .xml file is painful to say the least. The aforementioned Microsoft article provides information about how to use OptionState if you’re so inclined to self-torture. You can try deploying Office 2007 by using GPSI, but I expect you’ll find, like most organizations, that it’s just not full-featured enough to be useful.

A second deployment option is to use GPSI to deploy Office 2007 by using a .zap file. A .zap file is a simple script that can call any command—in this case, it would call Office’s setup.exe command with all its switches. GPSI can deploy a software package with a .zap file; you just have to select the .zap file instead of an .msi file when creating the package. However, .zap files can only be published, not installed, so that Office can appear in the Add/Remove Programs list under Programs and Features in Windows Vista and can even be associated with document extensions for install on demand. However, publishing Office 2007 means that it isn’t deployed until a user needs or requests it, and the user must be an administrator to launch Office Setup, so .zap files also fall short of the deployment requirements for most organizations.

The third option, and the option that Microsoft prefers you use, is to purchase Microsoft Systems Management Server (SMS) or the new rebranded release, Microsoft System Center Configuration Manager 2007. Although SMS and System Center Configuration Manager 2007 provide full-featured support for the deployment and subsequent management of Office 2007 as well as other applications and configuration, they also aren’t cheap.

Office Deployment Challenges
As you know, Office 2007 is a large application, typically consuming more than 1GB of disk space, which includes the applications and the local installation source (MSOCache). Installing Office 2007 takes quite a while, so when you’re choosing your deployment method it’s important to keep in mind how it will impact end users. You don’t want your CEO to log on to his or her computer just prior to a presentation to the board of directors, only to find that’s the moment when Office 2007 is deployed to his or her system.

Another challenge is that Office Setup requires administrative credentials to execute, so we’ll have to develop alternative deployment methods that ensure setup.exe runs with the appropriate credentials. I find it to be rather obnoxious that, in this day of least privilege and non-administrative users, Microsoft didn’t provide an easy and full-featured way to deploy Office 2007 using GPSI or logon scripts. Make some noise to Microsoft about this topic by sending an email message to your Microsoft sales representative—the company is developing Office 14 right now.

Most organizations deploy Office to computers, not users. You don’t need Microsoft Visio “following” users from computer to computer. It’s best to have Office applications installed per machine, available to any user who logs on to that machine. That approach also facilitates license management, since Office is licensed per machine.

With these challenges in mind, let’s explore our Office 2007 deployment options. The solutions below will work with both Vista and Windows XP clients in a Windows Server 2003 domain.

The Script
You can install Office 2007 by launching setup .exe. Setup.exe takes optional parameters, as discussed in “Customizing and Deploying Office 2007.” If you’re launching setup.exe on remote systems to deploy Office 2007, you’ll want to ensure that setup finished successfully. Therefore, we’ll build a script that not only deploys Office 2007 by running setup.exe but logs its success as well. This script will also ensure that each target system does, in fact, run setup .exe only once. Listing 1 shows a portion of the script, Office2007_Deploy.vbs. You can download the entire script at www.windowsitpro.com, InstantDoc ID 97016. (Click the Download the Code Here button near the top of the article.)

Here are the script’s core elements:

  • The Configuration Block: Office2007_ Deploy.vbs is written in VBScript, and you'll find it easy to configure, even if you’re not a scripting guru. All required parameters are in the Configuration Block, which is heavily commented to help you understand how to customize the script for your environment. I’ll discuss the purpose of each set of parameters a bit later.
  • Callout A: The script calls a subroutine, ExecuteCommand, which launches the Office Setup command as defined in the Configuration Block by the variable sCommand (e.g., "\\windomain.com\software\office\sdp\setup.exe"). The ExecuteCommand routine waits for the command to finish, then transfers the exit code and contents of the StdOut and StdErr streams to variables for logging. The code at callout A then interprets the exit code to determine whether the command was successful and calls Log_WriteCommandResults to write a new record to the log.
  • Callout B: The script adds the computer to one of two groups (i.e., APP_Office 2007 Deploy or ALERT_Office 2007 Deploy) indicating the success or failure of the command and removes the computer from the staging group (i.e., CMM_Office 2007 Deploy). I’ll explain these groups in more detail shortly.

To use the script, save it to your Office 2007 network installation point. I suggest creating a folder at the same level as setup.exe and the Updates folder called CompanyName_Setup. Put the script in that folder and secure the folder so that Authenticated Users have Read permission, and only administrators have Modify permission. Because the script will be run on systems using administrative credentials, you don’t want untrusted users to be able to modify the script.

Don’t forget to put your Office Setup customization file in the Updates folder and to use the /adminfile switch on setup.exe to point to the Setup customization file. Your Setup customization file should ensure a silent installation of Office 2007. (For more information about how to point to your Setup customization file, see “Customizing and Deploying Office 2007.”)

Related Content:

ARTICLE TOOLS

Comments
  • john suskey
    6 months ago
    Nov 10, 2011

    I've had some success with this. I think that given it's been almost 5 years, most "techs" would be looking for a 2010 office install. However we are still running both XP and Off 2003. I got this script to run as local admin. It did remove from the computer object from the security groups, and moved into the new group. It did the logging the data into the excel file also!!!
    I have yet to get this to run under the system and as a startup script, but it is progressing as I troubleshoot.

    THE AUTHOR of the solution deserves credit; albeit a little "late". THANK YOU.

  • 2Tall2
    2 years ago
    Nov 25, 2010

    I have the same issue, its a bit frustrating as the script would be great if it all worked. The script successfully removes computers from the staging group but doesn't add them to the success or error group. All three groups have "SELF" "Write" "Member" permission. There is nothing in the event logs. Any update on this?

  • jim
    4 years ago
    Aug 14, 2008

    all these readers complaining about the code quite some time ago... and its still not there... how do i get i?

  • Curt
    4 years ago
    Jun 30, 2008

    The script successfully removes computers from the staging group but doesn't add them to the success or error group. All three groups have the "Add/Remove Self as member" permission set for the Self account. There is nothing in the event logs.

  • Bill
    4 years ago
    Apr 24, 2008

    See if this helps everyone...
    http://www.windowsitpro.com/Files/97016/97016.zip

You must log on before posting a comment.

Are you a new visitor? Register Here

advertisement

advertisement

Windows is a trademark of the Microsoft group of companies. Windows IT Pro is used by Penton Media Inc. under license from owner.