Distributing Office XP Client Updates to Users

If you are deploying Office XP for the first time or if you have never patched your administrative installation point, then distributing patches (including service packs) directly to users is usually the most efficient and reliable way to keep clients up-to-date.


 Note   The Office Resource Kit has published new and improved information for updating client installations. For more information about patching strategies, see Strategies for Updating Office XP Installations in the Office Admin Update Center.


Microsoft recommends this update strategy if you:

  • Have experienced synchronization problems between clients and the source in the past. Applying a client patch does not modify the locally cached Office MSI file. This behavior helps to prevent scenarios in which the client has one version of the MSI file and the source has another.
  • Distribute software updates gradually or selectively. It is not necessary to update all client computers that depend on the administrative image at once. Deployment can be targeted at one group or at individual users, as necessary.
  • Have network resource limitations. Distributing client patches requires considerably less bandwidth than does recaching and reinstalling Office.

 Note   Client patches stay applied to a client computer, even if you change files associated with the updated application. A client computer that loses a file and downloads the original one from the source will still have the patch applied to it, ensuring that the installation is always up-to-date.


This update strategy comes with the following requirements:

  • You must be running Windows Installer 2.0 or later to distribute client patches to users. Office 2000 shipped with Windows Installer 1.0. You can download the updated Windows Installer 2.0 for Windows 95, Windows 98, and Windows ME or Windows Installer 2.0 for Windows NT 4.0 (SP-6) and Windows 2000 at the Microsoft Download Center.
  • For new clients, you must chain any previously distributed patches to the core installation from the unpatched administrative image, as described later in this article.
  • To maintain control over the update level throughout your organization, Microsoft recommends that you block users' access to updates on Office Online and distribute all client patches yourself.

 Note    If you have already patched your administrative image, you must re-establish a new baseline and recache and reinstall Office with every service pack. Between service packs, however, you still have the option to distribute client updates.


Distributing binary client patches

You can distribute either type of a client patch to users, and users can apply binary and full-file client patches interchangeably. However, binary patches are usually smaller than their full-file counterparts. For that reason, they require less network bandwidth to apply and take up less hard disk space on the client computer.

If you choose to distribute binary patches, keep in mind the following requirements:

  • Users often need access to the source in order to apply a binary patch.
  • Binary updates require the most recent baseline version of the product.

For example, to apply a binary update released after Office XP SP3, the user must already have applied SP3 to the computer.

  • Users must have administrative rights to their computers.

If your users are not the administrators of their computers, you must be able to grant them elevated privileges while applying updates, or distribute the updates by using a deployment tool such as Microsoft Systems Management Server or Tivoli.

  • Organizations that run any Office applications from the source cannot use this patching strategy.

If a binary patch is applied to a client computer that is running an application from the source, the application is downloaded to the local computer and no longer runs from source.

Updating existing installations

Binary updates are run separately on each local computer. Binary patch files can be kept in a folder on the administrative server, or in any network share that is accessible to all clients on the network. There is no need to have a separate server to host the patches, although it can be set up that way.

Since the binary updates are released as EXE files, users can run them to install the updates on their computers. You can use a variety of methods to distribute the patches to your users:

  • Deploy the update by using a software deployment mechanism such as Systems Management Server or Tivoli.
  • Post the EXE on a network share and direct all users to run it.

Alternatively, you can extract the individual update files (MSP files) from the EXE package and use OHotFix, a supplied utility program, to apply the patch to the computers. By running OHotFix from a command line, you can then control such features as the display level and log file creation.

When OHotFix runs, it applies all the MSP files in its folder in case-sensitive (A-Z, then a-z) alphabetical order. You can place as many MSP files in the folder as you need. If you are updating computers that are at different states of currency, you can include all of the update files needed by the most out-of-date computer. OHotFix automatically detects whether an update file is applied to a computer and will not attempt to reapply the same patch.

Microsoft strongly recommends, however, that you keep only the latest updates for each application in the update folder, as the most recent update for an application contains all of the fixes in previously released updates. If updates are applied in the wrong order, it is possible that an older update may be applied over a newer one. For a list of latest updates for Office XP, see Office XP Resource Kit Downloads on the Office Admin Update Center.

By extracting the MSP files and storing them in a permanent folder on a server, you can create a resilient network source for the update. This practice is useful when the user of a client computer accidentally deletes the local MSP file and needs to recover the update. If the local MSP is deleted, Windows Installer looks for the MSP file at the path from which the patch was originally installed. If the network source is available, then Windows Installer recaches the MSP file without failing or prompting the user for the MSP file.

You extract the files from the update EXE file by using a command line similar to the following:

C:\[path to update file]\MyUpdate.exe /c /t:C:\[folder for extracted files]

For example, the client update file for the Office XP Activation Update is named Oxp1001.exe. When you extract the files from Oxp1001.exe, you see the following:

File name Description
Ohotfix.exe OHotFix patching program
Ohotfix.ini Lists the settings that can be modified to control the behavior of Ohotfix.exe and Windows Installer
Ohotfixr.dll Library file for the OHotFix program
Shared.msp Windows Installer update file for the Office XP Activation Update

The OHotFix program runs automatically when you double-click the binary patch package. It first checks the state of the client computer, and then if appropriate, passes a command line to Windows Installer to apply the update. You can modify the behavior of OHotFix by changing settings in the OHotFix.ini file. Complete information on the available settings is included within OHotFix.ini itself.

Creating new installations

When a new client computer installs Office from an administrative installation point, the administrative source must first install the core software at a baseline version, and then install any current patches after the Office installation is complete. With this approach, the new client computer is guaranteed to have the latest updates.

If you are running Office XP, you can install update files automatically after the core Office XP installation by extracting the MSP files and chaining OHotFix in the Office XP Setup.ini file. Chaining allows you to deploy Office and related applications in one seamless process. In this case, OHotFix runs immediately after the Office installation is complete and installs the patches. You customize the OHotFix program by modifying the OHotFix INI file. To install the patches quietly, set ShowSuccessDialog to 0 in the OHotFix INI file.

For example, you might include an update called SecurityPatch in your core Office XP installation by adding the following EXE file to Setup.ini:

[ChainedInstall_1]
TASKTYPE=exe
PATH=\\server\share\admin_install_point\1234\OHotFix.exe
IgnoreReturnValue=0
Reboot=0

For more information on chaining, see Including Additional Packages in the Office Installation in the Office XP Resource Kit.

Distributing full-file client patches

In an ideal environment, an administrator can maintain the administrative installation point at a baseline level (such as the original release version of Office XP), efficiently distribute binary patches to users, and chain patches to any new installations of Office. In the real world, however, administrators sometimes need an alternate strategy. Although both the installation procedures and the results are the same for binary and full-file patches, the full-file versions are a good option under the following circumstances:

  • You support users who do not have consistent or reliable access to the network.

Because full-file patches replace (rather than merely update) files, they do not require the source. Whether you distribute them by means of the network, e-mail message, or a CD, users can apply them even when they are offline, and they get all the benefits of an up-to-date Office configuration.


 Note   For a list of documented scenarios in which a full-file patch might prompt an Office XP user for the source, see Knowledge Base article Service packs, updates, and security patches may require the Office XP CD-ROM.


  • You do not have the network bandwidth required to recache and reinstall Office on all clients at once.

After the full-file patch is distributed, clients can apply them without taxing the network at all.

  • Your clients are at inconsistent or unknown update levels but you need to deploy a security update right away.

Out of sync clients can apply full-file patches. Although the patch does not correct the synchronization problems, it does allow users to take advantage of the latest software updates until their next opportunity to recache and reinstall.

If you choose to distribute full-file client patches, keep in mind the following requirements:

  • Full-file patches are larger than binary patches.

In order to use this strategy efficiently, you must have sufficient network bandwidth or some other means to distribute the patches.

  • If clients are already out-of-sync with a patched administrative image, full-file patches do not resolve the problem.

At some point, clients must recache and reinstall Office from the administrative image to reconcile the MSI file versions. After that, however, you can patch clients directly without causing any new synchronization problems.

  • Full-file patches support the two most recent baseline versions.

For example, the full-file version of a patch released after Office XP SP3 can be applied to a client updated to Office XP SP3 or SP2.


 Note   For Office XP, only full-file updates released after Office XP Service Pack 2 (including Office XP SP 2 itself) can be applied directly to client installations. Earlier updates were designed to update only administrative images and fail when applied directly to clients.


Beginning with Office XP SP3, the behavior of full-file updates has changed. Now all client updates — both binary (client) and full-file (administrative) patches — are available from the same page on the Microsoft Download Center. In addition, the procedures for extracting, distributing, and applying both types of updates are the same. For both the binary and full-file versions of a given patch, double-clicking the EXE file applies the patch to the local computer. Regardless of whether you are deploying the binary or full-file version, you use the same command line to extract the MSP file from the EXE file:

[path\name of EXE file] /c /t:[location for extracted MSP file]

Related links

In a managed environment, Microsoft recommends that you block users' access to Office updates on Office Online. By setting a single registry subkey or policy, you can prevent users from downloading client patches on their own and still allow them to take advantage of all the other resources on Office Online. For more information, see see Blocking Users' Access to Office Update.

The strategies for applying updates to Office XP and Office 2003 Multilingual User Interface Packs are identical to those for updating the core Office XP and Office 2003 installation. For more information, see Distributing Multilingual User Interface Pack Updates in the Microsoft Office 2003 Resource Kit.