Auditing Hotfixes
You can't instruct Hfnetchk 3.1 to audit only OS hotfixes or hotfixes specific to SQL Server or IIS. When you run the utility, it audits and reports on missing hotfixes for all products that Microsoft includes in the catalog. When I ran Hfnetchk on my combination firewall/ VPN server, for example, it reported on missing hotfixes for the current OS (i.e., Win2K SP2) and my version of IE.
Microsoft packages most security hotfixes with the hotfix.exe installer. When you install a security update, the installation procedure expands the download file into multiple files, one of which is the hotfix.exe installer. When hotfix.exe runs, it creates an uninstall directory in the system root and places the expanded hotfix files in that directory. The name of the directory is the same as the Q number of the Microsoft article that references the hotfix. You'll find hotfix.exe, along with one or more .exe, .sys, or .dll files, in most of the Qxxx directories in the system root. Hotfix.exe also creates a matching registry subkey with the same Q reference number. The installer creates this subkey in one of two places: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Current Version\Uninstall or below the appropriate product subkey in HKEY_LOCAL_MACHINE\SOFTWARE\Micro soft\Windows\Updates.
When you use Hfnetchk to audit security hotfixes, the utility reports that a hotfix is properly installed only when three conditions are met. First, the hotfix registry subkey must be present. Second, the version number of each file included in the hotfix must match the corresponding catalog entry. Third, the checksum of each file must match the checksum of the catalog file. If any of these conditions isn't met, the utility reports the hotfix as not installed.
Hfnetchk's False Alarms
In several situations, Hfnetchk can erroneously report a hotfix you installed correctly as not installed. These situations reflect inconsistencies in how Microsoft packages and installs security updates.
No registry subkey. Some hotfixes (specifically those packaged with Microsoft Data Access Internet Publishing Provider—MSDAIPP) don't create the expected registry subkey. To correctly interpret Hfnetchk's audit report, you need to know which security updates omit that step—but Microsoft doesn't document that information. To avoid receiving reports for hotfixes that don't create a registry subkey, you can use Hfnetchk's —z option to instruct the tool to skip the registry-subkey verification step for systems on which you've installed old or nonstandard updates. When you use this option, however, Hfnetchk skips the registry-subkey verification step for every hotfix.
MSDAIPP. Microsoft occasionally releases hotfixes that use a different installer: the MSDAIPP. This installer doesn't follow hotfix.exe's system-root and registry-subkey conventions and doesn't force a system restart. Thus, when you audit a system after you apply updates that use the MSDAIPP installer, Hfnetchk reports the patch as not installed. The WWW Distributed Authoring and Versioning (WebDAV) hotfix in Microsoft Security Bulletin MS01-022 is a good example of this problem. The first clue that the hotfix is a nonstandard update is that the name of the download file, rbupdate .exe, doesn't follow the Q-number naming convention. (Be aware, though, that even some download files that follow that convention—e.g., the IE post-SP2 update file q295106.exe—use MSDAIPP.)
You can identify a hotfix's installer by extracting the individual components in the download file. All updates that use hotfix.exe contain that file in the extract directory; updates that use MSDAIPP contain one or more files named msdaipp in the extract directory (e.g., after I expanded the WebDAV update, I found msdaipp.10 and msd aipp.15 in the extract directory). The fastest way, however, to determine which installer a security hotfix employs is to open a command prompt and type the name of the hotfix download file followed by a space, a backslash, and a question mark (e.g., rbupdate /?). When a security update is packaged with hotfix.exe, you'll see the output that Figure 2, page 3, shows. When an update is packaged with MSDAIPP, you'll see the output that Figure 3, page 3, shows.
To be absolutely certain you've installed MSDAIPP-based updates, you must manually verify that those files have the correct date, version, and checksum. (And no, you aren't the only one who thinks this is an unnecessary waste of valuable time.)
Auditing Remote Systems
Hfnetchk's strength lies in its ability to audit remote systems. To identify the systems you want to audit, you can provide the tool with an individual system's NetBIOS name or a list of names (to audit multiple systems), a list or range of TCP/IP addresses, or a domain name (to audit all systems in the domain). If you identify the systems by name or domain membership, Hfnetchk must be able to resolve the computer names with NetBIOS, even when you're running only Win2K systems. (In a mixed Win2K and NT 4.0 environment, you already use NetBIOS over TCP/IP—NetBT—to ensure that legacy systems can communicate.) You can use one of several options (i.e., –h, –i, –r, and –d) to instruct Hfnetchk to audit multiple systems.
For example, suppose you want to initiate an audit of three workstations and a server. You can use the –h option to tell Hfnetchk to locate and audit the systems with the specified NetBIOS computer names:
hfnetchk –x mssecure.xml –h \\<system1>,
\\<system2>, \\<system3>
Prev. page
1
[2]
3
next page 
