Windows Patch Management, Looking Beyond Windows Page 2

Shavlik’s distributed tools are, for the most part, downloadable from files on its Web site, while HFNetChk and MBSA use Microsoft Web servers as the source, which, unfortunately, sometimes leads to inconsistent scan results.

For these tools to operate properly, a user who initiates a scan must be member of the local Administrators group on the target computers. Remote systems should have enabled Server service, Remote Registry service, File and Print Sharing, and default administrative shares. MBSA also requires an XML parser, which is included with IE 5.0 or later and can be added to IE 4.0 by installing MSXML 4.0 SP1 downloadable from http://www.microsoft.com/xml. When scanning computers residing behind a firewall, TCP ports 139 and 445, and UDP ports 137 and 138 must be open.

When a scan is initiated, MBSA and HFNetChk compare their own version number against the version specified in the XML file (they must match), check the version and locale of the operating system, service pack level, components, and applications installed. Based on this information, applicable security patches are determined. The tools also examine the content of registry keys under HKEY_LOCAL_MACHINESOFTWAREMicrosoftUpdates (the remaining portion of the path depends on the operating system version on the target machine) to determine whether patches are already present on a target system. If the registry key cannot be located, the assumption is that the patch has not been installed, and it is reported missing. The registry check can be bypassed by running MBSACLI.EXE in the HFNetChk mode with /z switch — i.e., MBSACLI.EXE /hf /z). Skipping the registry check might be useful if you have reasons to believe a particular patch has been installed. This way, the tools ignore the lack of a registry key and progress to the next stage of the check. At that point, the target file version and checksum are compared against its information in the XML file.

As we already indicated, Microsoft Baseline Security Analyzer can be launched in three modes:

• graphical (MBSA.EXE) launches directly from the All Programs menu or from the installation folder (Program FilesMicrosoft Baseline Security Analyzer). In this mode, /baseline and /nosum switches are applied. The /baseline switch triggers check for Windows security updates rated as critical, and the /nosum switch skips checksum file checks (which speeds up scan and limits bandwidth use when running the tool against remote computers). The results of the security scans are stored as an XML-formatted file in the SecurityScans subfolder in the profile directory of the user who launched the scan. The /f switch, followed by the path and name of an output file, can change these defaults.
• command line (MBSACLI.EXE) offers flexibility and scriptability. Typing MBSACLI.EXE /? in the Command Prompt window generates a full list of command line options. Like the graphical version of MBSA, the results of the scan are stored as an XML-formatted file in the SecurityScans subfolder of the profile directory for the current user.
• HFNetChk (MBSACLI.EXE /hf) exposes HFNetChk functionality, with all of its command line switches. This is helpful when transitioning to MBSA from environments where HFNetChk was the primary patch scanning tool, potentially referenced across many custom administrative scripts. The results are displayed in the text format in the Command Prompt window from which the tool was launched. Results can also be redirected to a text file by applying /f switch and defining its format with the /o switch.

Important to note:

• By default, both tools will attempt to download the most up-to-date copy of mssecure.cab from the Internet servers; however, they will fall back to the locally cached copy (residing in the Microsoft Baseline Security Analyzer installation folder) if the download fails. Alternatively, you can point to the MSBACLI.EXE running in the HFNetChk mode to a specific location of mssecure.xml (or mssecure.cab) file by adding -x switch (i.e., by running MBSACLI.EXE /hf /x mssecure.xml or MBSACLI.EXE /hf /x http://myWebServer/mssecure.xml).
• Instead of scanning patch level against the list contained in mssecure.xml, you can point both tools to Software Update Services servers on the local network (a solution to be discussed in greater detail in future articles). This limits the scope of the scan to only those patches explicitly approved. This behavior is invoked by applying /sus switch, followed by either the name of a SUS server or the location of ApprovedItems.txt file (which contains the list of approved patches), for example, MBSACLI.EXE /sus http://MySUSServer or MBSACLI.EXE /sus http://MySUSServer/ApprovedItems.txt. If the server or file name is not specified, MBSACLI.EXE will attempt to extract the information from the registry on the scanned system (HKLMSoftwarePoliciesMicrosoftWindowsWindowsUpdateWUServer entry).
• When connecting to remote computers, you have an option of specifying alternative credentials (i.e., MBSACLI.EXE /hf /u domain/username /p password).
• You can scan individual hosts (i.e., /i when using IP address and /c when using NetBIOS computer name in the format domaincomputer), a range of computers (i.e., /r IPStart-IPEnd when scanning IP ranges), or an entire domain (i.e., /d domain name option). In the HFNetChk mode, you can also specify a list of computers to be scanned by naming them directly in comma-separated format (MBSACLI.EXE /hf /h computer1,computer2,computer3), or including them in a file, with one computer name per line (MBSACLI.EXE /hf /fh filename) or one IP address per line (MBSACLI /hf /fi filename).

Future articles in this series will discuss a number of Microsoft patch deployment products (such as Software Update Services and Systems Management Server) that use technology implemented in MBSA to evaluate patch level before sending updates. Unfortunately, this approach is not fully consistent. Most notably, the mechanism that Windows Update uses is different from the one implemented in MBSA, which occasionally results in patches not being properly installed.