If you never seem to have enough time for the critical task of keeping up with software alerts and patches, take heart: Ohotfix can help. This valuable little tool makes it easier to deploy updates to Microsoft Office 2000 and Office XP installations. It’s small and configurable, and it’s now available as a stand-alone utility.

Installation
You can obtain Ohotfix from the Office Resource Kit or download it here. It is a mere 130 KB in size and is self extracting, but to use it, clients must be running at least version 1.1 of the Windows Installer.

Ohotfix should be downloaded into a directory that will contain the three principal files within the self-extracting Ohotfix package itself, as well as all the Windows Installer update (MSP) files that will subsequently be applied to clients. If Ohotfix is to work properly, putting all the required files together in this way is a must. The three files that make up the Ohotfix package are:

  • Ohotfix.exe—This is the core application file containing the UI and the code used to detect and apply the updates to clients.
  • Ohotfixr.dll—This library file contains text strings (dialog messages, etc.) that the application may use to inform the user of progress and any issues. It is language specific and needs to be localized accordingly.
  • Ohotfix.ini—This is the core of the package, where the clients retrieve the update information. This file can be edited in Notepad if necessary. It contains these settings: Type Of Update, Detection Parameters, Reboot Options, User Settings, Logging Levels, and Windows Installer Version Level.

Working with update files
Once installed, you can run Ohotfix from a command line to get the client updated. You can get the latest update files from the Office Update Download Center, then extract them using this command (with filename modifications as appropriate to your situation):
C:\path to update file\YourUpdate.exe /c /t:C:/destination-folder

Make sure that you place the extracted update files in the same folder as the Ohotfix files. If you get a message regarding the overwriting of Ohotfix’s EXE, DLL, and INI files, don’t worry. The update files will simply supercede these with higher versions.

You can put as many MSP update files as needed into one directory, where they are run in alphabetical order. What’s more, when clients connect to the update fileshare, Ohotfix detects which updates have been applied previously. It won’t reapply updates the client already has. This obviously saves time and processing power.

Patch deployment
Deploying the update files can be done in various ways, such as running Ohotfix from the update fileshare (check share permissions), running a logon script, sending out a batch file (if done by e-mail, make sure that virus scanners don’t block the file), and using SMS or a third-party application. I favor the first or second method.

The file space used by Ohotfix and update files is negligible in today’s world of massive hard drives, so you can just leave all the updates in the distribution share. The added advantage of having a permanent update fileshare point is that if a user accidentally deletes any of the cached MSP files on the client, Ohotfix can be run seamlessly without user disruption. The client simply connects to the permanent Ohotfix fileshare and the required file(s) are re-cached. If you’re trying to maintain a standardized set of updated Office installations, this practice will definitely help you to do it.

Troubleshooting updates
As we all know, even the simplest application deployments can cause big headaches—and Ohotfix is no exception. One of the most effective ways to troubleshoot an Office update gone wrong is to use log files. Office XP in particular doesn’t always generate descriptive error messages, so delving into log files can help you figure out where and what the mishap was. The nature of applying Office updates calls for particular methods of log file analysis.

Locate the log files in \Temp\Ohotfix. Their format is Ohotfix####.log and Ohotfix####_MSI.log. The # refers to the update number, which is incremented by 1 for every update. These log files are generated in pairs.

Determine the correct update log file pair using their numbers. The highest refers to the most recent update. If you’ve applied more than one update, this can be tricky. To definitively identify which log file you need, open an Ohotfix log file and examine the ninth line, which may say something like this:
MessageTitle=”Excel 2002 Update: May 14 2002″

This MessageTitle parameter contains the product, version, and date for the update installation.

If you’ve used update files from Microsoft’s Office Update Download Center and you want to see setup switches used, you can look here for the most common ones.

If you run into other problems, most of the information you’re likely to need is within the log files. Verbose logging is enabled by default on Ohotfix####_MSI.log, so this will provide an added level of detail. If you’re unable to identify and fix what happened in the update process, you can check out the nitty-gritty on log files here.

The way you interpret the log files does depend on where the update files were sourced from because, as you read above, they could also come from an online Office Update Download Center.

Failing all else, if you have unfixable problems, you can try to repair the Office installation itself by initiating the Office setup routine and selecting Repair Office when given the choice. Thereafter, try running the update process again.

Summary
Ohotfix can simplify the deployment of Microsoft Office patches and can help you standardize Office installation—and the program is free. But you also must be ready to use the tool to troubleshoot patch problems when they arise.