Watch the Installation Order
With Windows NT 4.0, installing hotfixes in the proper chronological order is crucial. To improve the hotfix installation process, Win2K and later OSs added more thorough version checking to improve the hotfix installation process. Microsoft has also released the Qchain tool (available at http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=a85c9cfa-e84c-4723-9c28-f66859060f5d), which lets you install multiple hotfixes without rebooting the system after each installation. However, situations still exist in which the hotfix installation order is important.
When a hotfix needs to install a file that's in use, the hotfix writes a registry entry that tells the OS to replace the file at the next reboot. When you install multiple hotfixes, the hotfixes might update the same file multiple times. In this situation, qchain.exe checks to make sure that only the most recent file version appears in the list of hotfixes to be installed. You should always run qchain.exe when you install multiple hotfixes.
But qchain.exe isn't perfect. You might still end up with an older file than expected. For example, some file types, such as .asp or .chm files, don't have version information built into the file. Also, qchain.exe works only with files that are in use that Windows can't replace until rebooting. Because a hotfix might replace some files immediately, qchain.exe will never see them.
To avoid these situations, you should install hotfixes in the proper chronological order whenever possible. However, the proper order isn't always clear. You can't just rely on the security bulletin number or the Knowledge Base article number. Although you can usually trust the hotfix release date, the only way to be absolutely sure of the proper installation order is to check the versions and dates of each file in the hotfix.
Don't Rely Exclusively on Automatic Updates
With Win2K Service Pack 3 (SP3), Microsoft introduced the Automatic Updates service, which automatically watches for, downloads, and optionally installs new Windows updates. This service is a huge step forward for Windows security, but solely relying on it does have some drawbacks.
To begin, not all security bulletins involve installing a patch. For example, Microsoft Security Bulletin MS02-064 (Windows 2000 Default Permissions Could Allow Trojan Horse Program) addresses a problem with the default NTFS permissions of the system root folder, but it doesn't provide a patch. Instead, you must manually fix these permissions on each server. The Automatic Updates service can't help you with this and other hotfixes that require manual intervention.
When you use the Automatic Updates service, neglecting to read Microsoft's security bulletins is an easy habit to get into. These bulletins contain valuable information, including best practices that can avoid or mitigate the problem, even without the patch. If you rely on automated systems to patch your servers, you need to watch the security bulletins for manual fixes.
Finally, the Automatic Updates service can't always handle the complexities of a hotfix. Some hotfixes have specific installation conditions that you must carefully review before installation. If you consider these drawbacks, you'll see that the Automatic Updates service is actually a distribution method and not a replacement for checking security bulletins.
Double-Check the Hotfix Checkers
Even when you use best practices to patch your systems, you might still need to reinstall a hotfix. For example, you might install all the Automatic Updates, then go to Windows Update only to find other fixes available. After installing all those other fixes, you might use the HFNetChk tool and discover even more fixes that you need to install. Taken a step further, you might run qfecheck.exe, which reports whether all hotfixes are installed properly, then run the Microsoft Baseline Security Analyzer (MBSA) and find that a hotfix isn't properly installed.
Why do these situations occur? Part of the problem is that Microsoft uses many different installers for hotfixes. You might notice, for example, that Microsoft Internet Explorer (IE) updates have different icons and file-naming conventions than Win2K hotfixes do. Some products use the Microsoft installer, Windows installer, or the Microsoft Systems Management Server (SMS) installer, whereas others, such as Microsoft Office, use yet another installer. With the release of SP3, even Win2K hotfixes switched from using the hotfix.exe installer to using the update.exe installer. Predicting how each of the many installers will behave in particular circumstances is difficult.
Installation order, file corruption, and even running the System File Checker can cause problems. (For details about System File Checkerrelated problems, see the Microsoft article "The SFC /SCANNOW Command May Overwrite Hotfix Files" at http://support.microsoft.com/?kbid=814510.) Other problems, such as service pack slipstreaming, human error, incorrect version detection, and limited product coverage, contribute to the inconsistent results.
Another part of the problem is that numerous tools exist for checking installed hotfixes, and each tool has its strengths and weaknesses. Each tool uses different combinations of methods to determine which hotfixes are installed and whether they're installed properly. To determine whether you've installed a hotfix, a tool can check the registry, the file versions, or the file signatures. But many complexities can complicate file and product versioning, so the process still isn't perfect. For example, slipstreaming a service pack to a server might not record a product version in the same way as if you'd installed it after the OS.
My solution is to check my hotfixes, then double-check them again with another tool. Table 1 provides a list of free products that you can use to verify your hotfixes.
Register
