The first consideration is the placement of the package itself. You essentially have two choices for getting the package to the client: an administrative installation or a nonadministrative installation.

You can perform an administrative installation of Office to a network share by using the setup/a option. As mentioned earlier, you should use a DFS share to deploy any applications in policy because it is impossible to change the path to an application once it’s been deployed. The advantage of an administrative installation is that you can patch the installation directly and then perform a redeployment to force all clients to reinstall the application with the new, patched version.

You can perform a nonadministrative installation of Office to a network share. That is, you can simply copy the contents of the Office CD to the network share and reference the Windows Installer package in policy. The advantage of this approach is that if you are deploying Office 2003, you can use the Local Install Source feature to cache the Office setup files on the local workstation during installation. The downside of a non-administrative install is that when you do have to patch or update Office, you must distribute and run the patch on each computer where the application is installed.

Note

If you perform an administrative installation of Office 2003, you can use the new Local Install Source feature in Office. This feature allows you to cache all Office cabinet (.cab) files needed for repairs, updates, or patches on the local computer in a hidden folder called MSOCache. In this way, the user doesn’t have to have the CD available during an update. You can specify that you want to create an LIS cache on the workstation during the installation of Office 2003 by creating a transform on the package prior to deployment. Of course, caching all of these .cab files takes nearly 200 MB of disk space on the workstation, in addition to using network bandwidth to copy the files to the client.

These two network-based options are best for deploying Office to computers with high-speed, low-latency network links to the servers where the packages reside. In some cases, however, you might have clients that are connected across intermittent, slow, or even dial-up links. When Group Policy detects a slow link, Software Installation policy is not processed by default, even during foreground policy processing. Even if it were, an application setup the size of Office would likely never complete, given how long it would take to run the install over a slow network link.

Even on fast networks, having many computers downloading 600 MB of Office at nearly the same time would likely saturate the network, causing intermittent failures as computers attempted to retry their communications. Therefore, a third and better approach for deploying Office or any large application is to deploy the setup package locally to each computer before deploying the application through policy. This pre-staging of the Office setup package offers two advantages:

You can use to get the files to the client using different mechanisms. You can use everything from the low-tech approach—such as the CD approach we just mentioned or simply running a series of xcopy commands to copy the files to each client—to high-tech approaches such as creating a scheduled task or a startup script to have the computer copy the files on its own time from the server. You can even use a robust file copy utility such as Robocopy (from the Windows Server 2003 Resource Kit) to get the files out to your clients.

The challenge in getting the files to the client is that, for a large package such as Office, copying the entire setup to every client on a large network can be extremely bandwidth intensive. In these cases, you should consider networking technology such as IP Multicast because as it can significantly minimize the repetitive data that flows over your network to remote sites. Another solution for these remotes sites is to first stage the Office setup files on a server at the remote location and then create a startup script or other job to pull those files from the server. In this way, you distribute the load of deploying the package and ensure that the file copying occurs only on local area networks (LANs).

Once you’ve deployed the package to every computer that will install it, you can set up policy to point to the local path where you’ve copied the setup files on each machine. This is a case where you do not use a path to a UNC share, but rather an absolute path to a folder somewhere on the computer’s local hard drive (for example, c:packagesoffice2003pro11.msi).

Tip

Sometimes when you copy the setup files to clients to stage the package to remote clients connected over slow links still might not be able to install the software. This can occur because the slow-link detection process does not consider the location of the package—only the fact that the computer is connected over a slow link. To get around this issue and ensure that Software Installation policy is always processed, you can enable Allow Processing Across A Slow Network Connection under Computer ConfigurationAdministrative TemplatesSystemGroup PolicySoftware Installation Policy Processing on all of the computers to which you will be distributing applications. By enabling this policy, you ensure that computers where you’ve locally staged the setup package will always run the installation, even when the computer is connected over a slow link.

Using transforms is a common method of customizing deployments of Office. Transforms give you the ability to customize almost every aspect of a Windows Installer package for deployment. In the case of Office, you can use a transform to control, for example, which Office applications are installed, what the default document locations are for each application, and settings for the user’s default Outlook profile.

To create a transform for Office 2003, you must download the free Office 2003 Editions Resource Kit Tools from http://www.microsoft.com/downloads/details.aspx?FamilyID=4bb7cb10-a6e5-4334-8925-3bcf308cfbaf&DisplayLang=en.

After installing the tools on your administrative workstation, you can run the Custom Installation Wizard to create transform files. Figure 9-13 shows how you can specify that certain applications—in this case, Microsoft Access—won’t be installed, while others that are not installed by default, such as New And Open Office Document Shortcuts, are added back into the installation.

Figure 9-13. The Custom Installation Wizard

When you complete the wizard, you are asked where to save the .mst transform file. If you copied the Office installation files to a network share in preparation for deployment, place a copy of the transform file within that share location. If you plan to copy the installation files to each local computer, you should copy the transform file along with the installation files to ensure that it’s available during installation. You’ll also need to configure policy so the transforms are used. See the "Customizing the Installation Package with Transforms" section in this chapter for details.

Software Installation policy provides a number of ways to deploy applications—including user assignment and user publishing—but the preferred method for deploying a large application such as Office is through computer assignment. Computer assignment provides for an unattended installation, with no user interaction required. All user-based deployment mechanisms require that the user be unable to use her workstation until the application installation completes. For an application such as Office, this could mean tens of minutes if the network is busy—or, even in the best case, 5 to 10 minutes.

Because computer assignment runs at restart, it offers the added benefit that no users will be logged on to the computer during deployment. The only challenge with computer assignment is that you must trigger a restart of the computer to kick off the installation. You can do this using a variety of methods, such as by using remote WMI script or by using the Shutdown.exe utility in conjunction with a Task Scheduler job.

The key here is that if you use a network-based share for the Office installation files, you should stagger the restarts to ensure that your network is not saturated by many machines requesting files from the share at once.

When Microsoft issues new service packs or patches for Office, you should also use policy to deploy them. The deployment process is relatively straightforward if you use an administrative installation of Office to deploy the application via policy. The first thing to note is that if the update is a service pack, you should download the full file version rather than the client version. Then you should extract the service pack files to a working directory rather than run the installation as is. This last step also applies to patches. Always extract the files in the service pack or patch to a working directory first rather than run the service pack or patch directly from your administrative workstation. You can do this by using the /t and /c options on a service pack or patch as follows:

officexpSp3-kb832671-fullfile-enu.exe /t:C:downloadsofficexp-sp3 /c

You will notice that many of the downloaded files have an .msp extension; this extension indicates a Windows Installer patch file, which must be applied to your administrative installation. To apply the updates to your administrative installation, you use the built-in Msiexec.exe command-line utility to patch the main .msi file on your administrative installation share. The command for this patching is as follows:

msiexec /p PathToMSPFile /a PathToMSIFile SHORTFILENAMES=TRUE /qb /L* PathToLogFile

You provide the path to the .msp file, the path on your administrative share to the main Office .msi file (usually pro*.msi for Office Professional), and a path to a log file that logs the success or failure of the patching process.

Once you’ve patched all of your administrative installation points, you must redeploy Office through policy. During the next foreground processing cycle, these computers or users will perform a reinstallation of the updated version of Office.

If you have deployed the Office setup files to your computers directly, the process of applying a service pack or update is different:

Note

If you are using the Local Install Source feature with Office 2003, you don’t need to perform this manual msiexec operation. You simply execute the client version of the patch or service pack on the local computer and the Local Install Source cache is updated.