With Windows Update available, you’d think that installing the latest Office XP patches and program features would be as simple as pointing to the Windows Update Web site, running the applet, and waiting for the installation to finish. But it’s not that easy. For one thing, you want to control which patches your clients incorporate. For another, you may be stuck with a hodgepodge of computers that were updated at different times and in different ways. In that case, figuring out the status of each client quickly causes an inventory migraine.

To help alleviate the inventory headache for shops with computers at different update levels, Microsoft released the Office Update Inventory Tool version 1.5. If applied correctly, the application will list all updates applied to all networked computers and will also list which updates are missing. The tool even tells you which patches can only be applied by an administrative image. But be warned—the tool is clunky. And it’s only an inventory-taker, not a system-updater. In the end, it will be up to you to somehow consistently patch all of that hardware.

The Office Update Inventory Tool runs on Windows 98 and later and requires Windows Installer version 2.0. It will identify patches on Office versions 2000 (SR1 and later) and XP. Earlier versions of Office need not apply.

The tool’s conversion utility, which transforms inventory logs into reports, doesn’t run on Windows 98. It requires Windows Me or above, as well as Microsoft Internet Explorer 5 or above. If, for some reason, your organization must stick to an earlier version of Explorer, you can get around this requirement by downloading a stand-alone version of Microsoft XML Parser (MSXML 3.0 SP2).

Download and installation
Download the Inventory Tool’s two self-extracting files, Invcm.exe (161 KB) and Invcif.exe (256 KB), to a directory on a server with access to all of the computers you need to inventory. Double-click each file to extract the program components (five files, totaling 691 KB, and about 1 MB worth of unpacked “cif” files, containing data describing 977 office components as of this writing). Accept the license agreement. Provide a location for the files, or accept the default location.

Keep the updater updated

Invcif.exe needs to be re-downloaded whenever new updates are released, or the inventory won’t catch the latest and greatest patches. Feel the return of that inventory headache? It’s another detail to keep track of in Outlook’s tasks. You can find an up-to-date catalog of all Office Updates at the Microsoft Office Web site.

Using the Office Update Inventory Tool
Running Inventory.exe
To create an inventory of Office updates, run Inventory.exe. To create a report from the inventory logs, run Convert.exe.

Inventory.exe probes the Windows Installer database on each computer. The hitch is that someone has to run the program on each computer. Microsoft recommends two ways to get this done: Use Microsoft Systems Management Server or another system manager to deploy the software, or place inventory.exe on a network share, and ask users to run the tool on their own. Naturally, the latter choice isn’t efficient, but short of you walking around to each workstation on your network to run the utility, it’s your only choice.

It would be nice if Microsoft could have made using the programs a little easier and quicker, especially for end-users. But, at the moment, it’s strictly a command line tool. Users probably won’t like that. They will need to understand paths and be able to add command line switches.

Convert.exe needs to be pointed to the .cif files directory and to a folder you create (i.e. d:\inventory\data) for storing the logs. Make sure both directories can be shared by all the clients.

Open a DOS or CMD window on the target computer and type Inventory /s path-to-cif /o path-to-log where path-to-cif is where you’re going to store the cif files and path-to-log is the location where you’re storing log files.

A real command will look like this:
\\admin\inventory /s \\admin\inventory\cif /o \\admin\inventory\data

If you get stuck, the command Inventory /? displays help information.

Each computer’s data is stored in a separate file with a .log extension. The file name is the same as the computer’s NetBIOS name. The data includes each update and its status: whether the update has been already applied and whether it can be applied to that hardware.

For example, after running Inventory.exe on a Windows XP workstation called Freelancer2 with Office XP installed unmodified from the program CD, the data directory will contain a file Freelancer2.log. The log file simply contains a long list of updates, each one referenced by a number, followed by a comma and a status flag, such as:

The reference number means nothing to you and to me but is turned into English during the next phase.

Running Convert.exe
Convert.exe sorts all of the logs into one file, which can be in either of three formats:

  • An XML file that can be read in a compatible Web browser
  • A CSV (comma separated values) file that can be loaded into a spreadsheet such as Excel and manipulated
  • A managed object format (MOF) file that can be parsed by Systems Management Server. You, and not the users, will run Convert.exe after all the inventory logs are in.

As I suggested above, the XML file contains the most useful data. CSV output only reports updates that have already been added; it won’t differentiate between client and administrative updates, nor will it include a list of needed updates.

The syntax for using Convert.exe is:
Convert /d path-to-log-files /o path-and-file-name-of-report

The /d command line switch path is the same as the /o command line switch in Inventory.exe. I would have preferred that Microsoft’s programmers use the same switch letter for the sake of consistency, but they didn’t, so you need to remember the different switch.

Other command line switches include:

/xml path-to-Patchdata.xml (Patchdata.xml is a required file, extracted during installation, that translates update numbers into update names.)

/c path-to-csv-report

/mof path-to-mof-report

/? (Help)

If the paths in /c or /mof are omitted, the report file is created in the same folder as the log files.

For example, the command to run Convert.exe on the Freelancer2.log file (and any other log files in the data folder), to request a report file called inventory_rpt.xml, and to format the report in XML (the default output) may look like this (in this example, Convert.exe is being executed from the folder in which it is installed, C:\Inventory):
Convert /d data /o data\inventory_rpt.xml /xml c:\inventory\patchdata.xml

To format the report as a CSV file, run the same command, but use .csv for the report’s file extension and add the /c switch. To format the output file as MOF, change the file extension to .mof and add the /mof switch.

The contents of inventory_rpt.xml for the computer FREELANCE2 appear as follows:
<?xml version=”1.0″ ?>
  <PATCH NAME=”Office XP Service Pack 1 (English version)” />
  <PATCH NAME=”Office XP Service Pack 2″ />
  <PATCH NAME=”Outlook 2002 Update: October 4 2001 (English version)” />
  <PATCH NAME=”Outlook 2002 Update: August 16 2001″ />
  <PATCH NAME=”Outlook 2002 Update: June 21 2001″ />
  <PATCH NAME=”Word 2002 Update: June 21 2001″ />
  <PATCH NAME=”Excel 2002 Update: October 4 2001″ />
  <PATCH NAME=”PowerPoint 2002 Update: October 4 2001″ />
  <PATCH NAME=”Office XP Activation Update: October 4 2001″ />
  <PATCH NAME=”Office Web Components 2002 Update: August 9 2001″ />

The three tags, <INVENTORY>, <MACHINE NAME>, and <PATCH NAME> are self-explanatory. A few others need explaining.

When the opening and closing tags <APPLICABLE> and </APPLICABLE> frame the list of updates, it means they haven’t yet been installed on that machine.

Installed updates are framed between <INSTALLED> and </INSTALLED> tags.

<ADMINAPPLICABLE> and </ADMINAPPLICABLE> tags enclose program patches that can only be applied to clients installed through administrative images (applied directly to clients) or baseline images (an administrative installation point on a network share).

An <ERROR> tag signals that Convert.exe was unable to create an XML file for various reasons, such as network interruption, full disk, and so on. There is no further troubleshooting detail.

As I explained earlier, .csv files offer less detail. Since my virgin Office XP installation has no updates, its .csv file consists solely of the computer name, “FREELANCE2.” This lack of patch names does suggest, by their absence, that the computer needs a quick update. But it doesn’t tell you which ones to look for.

A help or a hindrance?
Did Microsoft’s Office Update Inventory Tool make the Office XP (and Office 2000) patch inventory problem more difficult to solve rather than easier? It may appear that way, seeming to you that visiting each client with a legal pad and a pencil would be quicker. But in the final analysis, I believe Inventory.exe and Convert.exe are useful. With these utilities and just a little luck, you’ll have a complete report of Office Patches on each client, and you’ll be one small step closer to patching all of those machines.