Automating Office 2007 Deployment

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:

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.”)

The Log

The script logs the success or failure of the setup.exe command after the command is executed on each system. You must create a log file. The script is coded to work with a Microsoft Excel worksheet (Excel 97–2003 .xls format) as the log file, although you can change the script to work with a log file in the form of a Microsoft Access database (.mdb), Microsoft SQL Server database, or Office 2007 format database (.xlsx or .accdb). If you create an Excel worksheet, you’ll want to create column labels in the first row that match the labels defined in the script (i.e., ComputerName, Action, Status, Date, Notes). If you rename the worksheet from the Excel default name, Sheet1, remember that you must change the sTable variable in the script. Save the script to a folder to which Authenticated Users have read, execute, and write permission, and configure the variable sFile to point to the database.

The Groups

You can use the log to audit the success and failure of setup.exe, but it’s also handy to be able to easily monitor the machines on which Office should be installed, those for which setup.exe succeeded, and those that encountered errors. To do so, leverage Active Directory (AD) as your database and create the following three global security groups in AD:

The benefit of using AD as a database is that doing so makes it easy to manage change using group memberships. Computers in the CCM_Office 2007 Deploy group (CCM for Change and Configuration Management) will run the script using the methods described below. When the script succeeds, it moves the computer into the APP_Office 2007 group. If the script fails, it moves the computer into the ALERT_Office 2007 Deploy group. With either success or failure, the computer is removed from the CCM group, so that the script doesn’t run repeatedly.

For the script to move the computer between groups, you must delegate these groups correctly. These groups require the Self Allow Write Members permission. With this permission, the special identity Self must be allowed to modify the Members property. A user (or computer) can add or remove itself from a group but can’t add or remove other members. You can configure this access control entry (ACE) in the Security Properties dialog box of each group or place these groups in an organizational unit (OU) delegated with the Allow Self Modify Members ACE.

This ACE can be delegated on the OU. To do so, open the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in and select Advanced Features from the View menu. Then, right-click the OU containing the three groups and select Properties. Now, click Advanced under the Security tab. Click Add and enter SELF for the User or Group. Then click OK. In the Permission Settings dialog box, click the Property tab and select Group Objects from the drop-down menu. Now select the Allow check box for the Members property.

Group Policy Startup Script

Although GPSI doesn’t support Office 2007’s setup.exe command, startup scripts can execute any command you want to run. Startup scripts run locally in the context of the System identity, which provides sufficient access to run setup .exe successfully.

The Microsoft article “Use Group Policy to assign computer startup scripts for 2007 Office deployment” (technet2.microsoft.com/Office/en-us/library/a57c8446-b959-4025-a866-b690ddcaa66d1033.mspx) describes how to use startup scripts for Office 2007 deployment. Although the article is strong on concepts and on step-by-step instructions for creating and assigning startup scripts, the actual script it proposes is weak. Our script is much more robust.

There are two things to keep in mind if you decide to use startup scripts to deploy software.The first is the length of time it takes to perform the installation. Startup-script processing times out after 10 minutes by default, so you’ll need to match the script timeout Group Policy Object (GPO) setting located under Computer Configuration Administrative TemplatesSystem ScriptsMaximum wait time for Group Policy scripts with the maximum time (in seconds) that’s required to install Office. Determine the time through testing, but 15 to 20 minutes (900 to 1200 seconds) should be enough. I recommend configuring the expanded script timeout in the same GPO that you use to deploy Office, so that when the GPO no longer applies to a computer, its script timeout will return to the default or to another setting configured by other custom GPOs.

The other thing you must keep in mind when using startup scripts is how it will impact your end users. Startup scripts will run at each system startup, so you don’t want to be running setup.exe every time a client computer is booted. Setup won’t reinstall Office—it will detect the existing installation successfully— but it will still take time to process. Therefore, you want to configure your startup script to verify whether Office 2007 already exists on the system prior to running setup.exe. If Office 2007 has already been installed, the script will exit without running setup.exe.

There are several ways to configure your startup script to verify whether Office is already on a system. One way is to read the registry key that displays Office 2007 in the Add/ Remove Programs list. If it’s there, Office 2007 is installed. Another method is to create your own registry entry to track the successful installation of Office 2007. I’m a big fan of tagging systems for CCM. You can also create a “flag file” on the hard disk. Many systems administrators use this approach to tag a system. An empty text file is created with a specific name such as C:OfficeDeployed.txt. A script looks for this file to determine whether the script should run. I prefer to use a registry change rather than the flag-file method, since disk reads are more “expensive” than registry reads from a processing perspective, and there’s a risk of the file being deleted from the disk.

Finally, you can use a security group to deploy Office 2007. To do so, create a GPO called Office 2007 Deploy. This GPO will configure the startup script, which will install Office 2007. Edit the GPO Startup Script policy settings to run your script: The Script Name should be cscript .exe, and the Script Parameters should be the full path to your script in the Office network installation point, as Figure 1 shows. Try to avoid using spaces in the pathname or filename.

After you’ve created the Office 2007 Deploy GPO with the startup script that installs Office 2007, filter the GPO so that it applies to only the CCM_Office 2007 Deploy group, as Figure 2 shows. Don’t forget to remove Authenticated Users from the filter.

Any computer that’s in the CCM_Office 2007 Deploy group will run the startup script and install Office 2007. Now here comes the creative part. Because the startup script includes code that removes the computer from the group, the startup script will run only one time on that computer. Also, if Office installs successfully, the computer will be moved to the APP_Office 2007 group. You can use that group to monitor and report which computers have Office 2007. If Office installation fails for some reason, the computer will be added to the ALERT_Office 2007 Deploy group, which acts as a “red flag” for computers that should be examined to determine why Office installation failed.

Wrapping Up

We’ve created a script that acts as a “build-ityourself” SMS or Systems Center Configuration Manager by executing an action, logging the results, and ensuring the action doesn’t happen again. We’ve also looked at how to deploy the script by using Group Policy startup scripts. For more information about other Office 2007 deployment methods, see the Web-exclusive sidebar “Alternative Office 2007 Deployment Methods,” InstantDoc ID 97263. The approach I’ve laid out can be used for several systems management tasks in addition to deployment of Office 2007.