Patching our systems has become a reality for all of us, and the Software Update Services Feature Pack for Systems Management Server 2.0 and the integrated tools in SMS 2003 have been a substantial help in the never-ending battle to keep systems up to date.
Out of the box, the patching tools for SMS include two types of patches: Security and Office. With Security patches, the Distribute Software Updates Wizard (DSUW) really does a great job. You approve a patch and the wizard downloads it for you. All you need to do is configure a few installation switches and you're ready to go. Unfortunately, to deploy patches to Microsoft Office, the tools aren't as much help as we might like.
Specifically, to deploy a client-side patch to Microsoft Office, your clients must have access to their admin installation point. If you can't meet that prerequisite, you're already in trouble. For a tutorial on admin install points, and how to repair deployments without any, see
Next, you need to expand the downloaded hot fix file into its included files, edit the ohotfix.ini file to make it be a silent installation and then tell the DSUW it needs to use ohotfix.exe instead of the pre-configured command. This process is very cumbersome, and the command-line to extract the hot fix files is enough to choke an elephant when you put together the source directory, patch name, extraction switches and destination directory.
Fortunately, if your clients already have access to an admin installation point and if you're using the DSUW to deploy updates, I have a script that will help with the cumbersome part of extracting patch files and editing INI files to deploy an Office patch. Just compile the SMS Installer source for this program and drop a copy of OHotFixer.exe into the source directory for each of your Office patch packages created with the DSUW.
Here's how it works:
- Use the DSUW normally to create or update a patch package for Office updates.
- Approve the relevant updates for your environment.
- Allow the DSUW to download the approved hot fixes for you.
- Make sure you have a copy of OHotFixer.exe placed in the top-level directory of your patch package source (same place that PatchAuthorize.xml and patchinstall.exe live) before you configure the individual patches; you only have to do this the first time you set up a new patch package.
- Launch OHotFixer.exe in the source directory of your patch package.
- Wait a few moments for the work to be done (a success message similar to this will be displayed). Picture Url: http://myitforum.techtarget.com/img/arts/9208OHotfixer.jpg.
- Configure each newly approved patch in the DSUW as follows:
A: Get Properties on the newly approved patch.
B: Use the Import button to select ohotfix.exe in place of the name of the downloaded program.
C: Respond Yes to the warning that this is not the suggested executable.
D: Make sure there are no command line parameters configured since ohotfix.exe doesn't need any and then hit OK to complete the Properties configuration for the patch.
E: Respond OK to the warning about not having any command line parameters.
F: Remember, do this for each newly approved patch!
- Complete the DSUW normally.
OHotFixer.exe does the cumbersome work for you. The steps needed for each patch in step 7 are extremely fast and simple.
Want to know how OHotFixer works? The source is probably shorter than this description, but it basically lists .exe files below the current directory. For each one found, it checks to see if ohotfix.exe is in the same directory. If it has been expanded, nothing happens at this point and the script moves on. If it's a new patch, OHotFixer expands it for you.
After expanding all newly downloaded hot fixes, it then finds all the ohotfix.ini files in your package source and edits them so ohotfix.exe can run silently. Specifically, it sets ShowSuccessDialog=0, and OHotfixUILevel and MsiUILevel to "q."
Remember, client systems must have access to an admin installation point for Office patching to work because MSI patches need to refer to the installation source media (this could be a local admin installation point, a CD or a network location, as long as your client systems know the location of their source).
I have been using this approach for about a year with great success. No warranty is expressed or implied, but I'm optimistic that this script can help you, too!
ABOUT THE AUTHOR: Greg Smith works in the global business technology department at Pfizer Consumer Healthcare, based in Morris Plains, N.J. As a senior architect, Smith works extensively with SMS, Active Directory and Group Policy. He can be reached at mailto:email@example.com.
This article first appeared in myITforum, the premier online destination for IT professionals responsible for managing their corporations' Microsoft Windows systems. The centerpiece of myITforum.com is a collection of member forums where IT professionals actively exchange technical tips, share their expertise, and download utilities that help them better manage their Windows environments, specifically Microsoft Systems Management Server (SMS). It is part of the TechTarget network of Web sites. To register for the site and sign up for the myITforum daily newsletter, click here.
This was first published in November 2004