Windows Patch Management, Office Update Inventory Tool Page 2
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:
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:
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 \\REMOTE\Inventory 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 (\cifs\Puids.cif, patchdata.xml and inventorycatalog.html) by applying the following syntax (for local and remote servers, respectively):
INVENTORY.EXE /update C:\inventory INVENTORY.EXE /update \\REMOTE\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 \\REMOTE\Inventory share, the following command should be executed (with source files residing on the local and remote computer, respectively):
CONVERT.EXE /d C:\inventory /o \\REMOTE\Inventory\%computername%.xml /xml C:\Inventory\patchdata.xml CONVERT.EXE /d \\REMOTE\Inventory /o
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 \\REMOTE\Inventory\%computername%.mof /mof CONVERT.EXE /d \\REMOTE\Inventory /o \\REMOTE\Inventory\%computername%.mof /mof
Finally, the creation of CSV files requires the following syntax:
CONVERT.EXE /d C:\inventory /o \\REMOTE\Inventory\%computername%.csv /csv CONVERT.EXE /d \\REMOTE\Inventory /o \\REMOTE\Inventory\%computername%.csv /csv
Note that in this case, we created the XML, CSV, and MOF files in the \\REMOTE\Inventory 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 <INVENTORY> marks the beginning and end of inventory, <MACHINE NAME> clearly identifies the NetBIOS name of the computer, and <APPLICABLE> 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 <ADMINAPPLICABLE> 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.
In the next article in this series we will present more elaborate and efficient patch management methods from Microsoft.