Windows Patch Management: Updating MS Office

The previous article in this series discussed HFNetChk and Microsoft Baseline Security Analyzer (MBSA)— two free solutions available from Microsoft that provide a comprehensive evaluation of security-related software patches and system configuration settings.

Although the most recent version of MBSA saw its management functionality extended and the inclusion of additional Microsoft products (such as Microsoft Content Management Server, Commerce Server, and Host Integration Server), the capability to scan remotely for updates to its flagship product — Office — is still missing. Detecting Office-related patches (covering versions 2000, XP, and 2003) is limited strictly to the computer from which the scan is launched.

To remedy this situation, Microsoft released Office Update Inventory Tool (currently in version 2.0) as a stand-alone, free download (in addition to including it with the Office 2003 Resource Kit).

Office Update Inventory Tool provides the same functionality as the local Office patch update scan included with MBSA 1.2 (in fact, MBSA comes bundled with the Office Update Inventory Tool files stored in the OfficeUpd subfolder of the main installation directory). The main difference is the range of supported operating systems (Office Update Inventory Tool is superior in this regard because it is not subject to the compatibility limitations of other subcomponents of MBSA) and the way each tool is designed to operate.

While MBSA is used primarily to scan large groups of computers remotely (for all updates, with the exception of Office-related ones), Office Update Inventory Tool produces only listings that summarize the status of Office patches on the local machine. This means, in a typical scenario multiple instances of the tool would be running individually on each Windows computer. The tools then dump the results of their scans into a common network share to be analyzed in a comprehensive fashion.

Office Update Inventory Tool consists of two separate executables (and four supporting files). The first one (appropriately named INVENTORY.EXE) inventories the local system and generates a log file containing the results, while the second one (CONVERT.EXE) converts the resulting log file into a desired format. In addition to an XML file, you can generate a file in CSV format (i.e., comma-separated value), which can then be displayed easily in Excel or MOF (i.e., Management Object Format) output and then used by Systems Management Server to update its inventory information. Both executables and accompanying files are available in two separate downloads (Invcm.exe and Invcif.exe), packaged in self-extracting format, and published on the Microsoft Office Online Web Site.

While Invcm.exe (containing INVENTORY.EXE; oudetect.dll, which contains supporting code libraries; and CONVERT.EXE) is fairly static, Invcif.exe (which contains three compressed files: patchdata.xml listing update files, cifsPuids.cif storing detection data, and inventorycatalog.html describing mapping between updates and detection data) changes with every new Office patch. It should therefore be downloaded on regular basis. Fortunately (like with MBSA), every time the Office Update Inventory Tool is launched, it checks for a newer version of its two executables, as well as update and detection data, and downloads them automatically.

Continued on Page 2: OSes Supported

Continued From Page 1.

INVENTORY.EXE can execute on any system running Windows 98 or later with Windows Installer version 1.0 or later. Since Microsoft Office patches are applied as Windows Installer Package patch files (i.e., files with extension .MSP), they are registered in the Windows Installer database. The utility checks the content of the database and determines a list of already applied updates. It detects a patch level for Office 2000 SR-1a or later, Office XP, and Office 2003 (newer versions require Windows Installer 2.0). Note: INVENTORY.EXE, outdetect.dll, patchdata.xml, and inventorycatalog.html must all reside in the same folder, whether local to the system being inventoried or stored on a remote server.

You must also have access to Puids.cif file, which is located by default in the cifs subfolder within the main installation directory. You can also use /s switch to specify a subfolder’s location or place it in the folder containing the other files. Assuming you want to launch the inventory using files on the local system (stored in the default C:inventory folder) and redirect the results to the same location (determined by the value following /o switch), you would execute the following command:

INVENTORY.EXE /s C:inventorycifs /o C:inventory

If the files are stored in the Inventory share on a remote server (for example purposes, we’ve named it REMOTE) and you wanted to redirect the results there, you would instead run:

REMOTEInventoryINVENTORY.EXE /s REMOTEInventorycifs /o REMOTEInventory

In both cases, the outcome would take the form of a log file named after the local computer’s NetBIOS name and will be stored in either C:inventory on the local system or REMOTEInventory on the remote server. The log will consist of line-based, individual encoded entries that specify the patch identifier and its status. In both cases, the command must be invoked from the local system (the one where the MS Office installation being scanned resides).

INVENTORY.EXE can also be used to force updates of the detection files (cifsPuids.cif, patchdata.xml and inventorycatalog.html) by applying the following syntax (for local and remote servers, respectively):

INVENTORY.EXE /update C:inventory

CONVERT.EXE requires Windows ME or later and MSXML parser 3.0 SP4 or later (which is included with Internet Explorer 5.0 or later and can be downloaded separately, should you have an older version of the browser). The utility uses a log file generated by the INVENTORY.EXE and, based on information from patchdata.xml, it converts the data to XML (or, alternatively, CSV or MOF) format. As in the previous example, you can store it on a local or remote system, assuming the server, folder, and share names are the same as in the previous examples. When creating the output XML file in the REMOTEInventory share, the following command should be executed (with source files residing on the local and remote computer, respectively):

CONVERT.EXE /d C:inventory /o REMOTEInventory%computername%.xml /xml C:Inventorypatchdata.xml
CONVERT.EXE /d REMOTEInventory /o 
REMOTEInventory%computername%.xml /xml REMOTEInventorypatchdata.xml

Similarly, to convert log files to MOF format and store them with the same name but extension *.mof, you would execute:

CONVERT.EXE /d C:inventory /o REMOTEInventory%computername%.mof /mof
CONVERT.EXE /d REMOTEInventory /o REMOTEInventory%computername%.mof /mof

Finally, the creation of CSV files requires the following syntax:

CONVERT.EXE /d C:inventory /o REMOTEInventory%computername%.csv /csv
CONVERT.EXE /d REMOTEInventory /o REMOTEInventory%computername%.csv /csv

Note that in this case, we created the XML, CSV, and MOF files in the REMOTEInventory share (which simplifies collecting inventory information from a number of computers). Each file would have a unique name, derived from the computer name where the scan was performed. The files include information about the date of the detection data on which scan results were based. XML files can be easily analyzed by opening them in Internet Explorer (which has a built-in XML parser). The XML tags, used to separate and describe file content, are fairly intuitive. The top-level tag &ltINVENTORY&gt marks the beginning and end of inventory, &ltMACHINE NAME&gt clearly identifies the NetBIOS name of the computer, and &ltAPPLICABLE&gt designates updates that are missing (each such entry would contain an URL from which the update can be downloaded).

Once in a while, you might run across the &ltADMINAPPLICABLE&gt tag, which indicates that the patch must be applied to a server-based image from which the application has been originally installed (using administrative the installation option). Alternatively, instead of opening the file in the Internet Explorer, you can copy it to the report directory MSBA uses (SecurityScans resides in the profile folder of the user account used to install the MBSA) and view it using its graphical interface (select the “Pick a security report to view” option). Although the scan will be listed as incomplete, results specific to the Office Security Updates item can be examined.

Microsoft’s recommendations for implementing the Office Update Inventory Tool involves using the SMS 2.0 Feature Pack (to be covered in a future article in this series) or having users launch the tool from their workstation (e.g., by clicking on a shortcut pointing to a batch file that invokes the inventory process). While the first option greatly streamlines the process of collecting inventory and applying missing updates based on its results, the second hardly qualifies as a sound solution in larger environments. For other ways to deploy Office Update Inventory Tool, refer to some of the solutions presented in the second article of this series. These solutions allow the remote execution of arbitrarily chosen programs.

Article courtesy of ServerWatch.

Latest Articles

Follow Us On Social Media

Explore More