Four factors can adversely affect a successful Windows 2000 Service Pack 3 (SP3) upgrade. To ensure success, you must identify potential post-SP3 hotfix conflicts, identify necessary security hotfixes, update Microsoft Internet Explorer (IE), and plan for Automatic Updates behavior.

Identify Post-SP3 Hotfix Conflicts
First, you need to inventory systems you plan to upgrade to determine whether you've installed any hotfixes that conflict with SP3. During the months before SP3's final release, Microsoft released 59 post-SP3 hotfixes to selected customers—then changed the final SP3 build. Therefore, the original post-SP3 patches contain file versions earlier than those in the final SP3 catalog. If you attempt to install the original version of the patches on a running SP3 system, file-version conflicts can cause the hotfix installation to fail or to function incorrectly. (According to Microsoft, these conflicts apply only to the privately distributed updates, not to security hotfixes or code fixes you might have downloaded from the Microsoft Download Center or the Microsoft Windows Update Web site.) To ensure a working OS, you must obtain the updated versions and install them after you finish upgrading to SP3. The following Microsoft articles (which you can read at http://support.microsoft.com) list the problematic hotfixes:

  • "Some Windows 2000 Active Directory Hotfixes May Cause a Conflict with SP3 for Windows 2000" (Q326797)
  • "Some Windows 2000 SMB Redirector Hotfixes May Cause a Conflict with SP3 for Windows 2000" (Q326798)
  • "Some Shell Hotfixes May Cause a Conflict with SP3 for Windows 2000" (Q326799)
  • "Some Windows 2000 Kernel Hotfixes May Cause a Conflict with SP3 for Windows 2000: 1 of 2" (Q326935)
  • "Some Windows 2000 Kernel Hotfixes May Cause a Conflict with SP3 for Windows 2000: 2 of 2" (Q326800)
  • "Some Windows 2000 Spooler Hotfixes May Cause a Conflict with SP3 for Windows 2000" (Q326801)
  • "Some Windows 2000 Network Shell Hotfixes May Cause a Conflict with SP3 for Windows 2000" (Q326802)
  • "Some Windows 2000 OLE Hotfixes May Cause a Conflict with SP3 for Windows 2000" (Q326803)
  • "Some Windows 2000 Internet Information Services Hotfixes May Cause a Conflict with SP3 for Windows 2000" (Q326804)

You can inventory installed hotfixes by using the SP3 version of update.exe, the hotfix.exe utility, Hfnetchk, or the Microsoft Baseline Security Analyzer (MBSA). However, these utilities only identify hotfixes that were installed through the hotfixe.exe installer, not code fixes that the Microsoft Internet Publishing Provider (MSDAIPP) installs. MSDAIPP doesn't record modification data in the registry location that hotfix.exe checks.

SP3's version of update.exe lists hotfixes that are installed on the local system. To display a pop-up window similar to the one that Figure A shows, expand SP3, open a command prompt, and type

i386\update\update -l

To use hotfix.exe to list hotfixes, expand any recent hotfix into its component files—for example, rename the long download hotfix filename to something short, such as Qnnnnnn, then open a command prompt and type

Qnnnnnn/ /x

Then, type

hotfix -l

Hfnetchk (http://www.microsoft.com/downloads/release.asp?releaseid=31154&area=featured&ordinal=2) and MBSA (http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/tools/mbsahome.asp) are the best tools for auditing installed hotfixes on remote systems. Hfnetchk has an extensive command-line interface that lets you select systems by domain, name, or TCP/IP address. Hfnetchk saves the audit report permanently in a text file. I like MBSA's friendly GUI and report-naming and report-archiving features. With its custom version of Hfnetchk, MBSA supports the same remote audit options and saves the results in an HTML file. With a permanent record, you can easily compare before and after snapshots of system status—important for tracking progress and validating the outcome of your configuration activity.

Identify Necessary Security Updates
SP3 contains 35 security hotfixes, some dating as far back as 2000. For a list of these hotfixes, go to http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/news/w2ksp3.asp. The embedded hotfixes represent only a subset of those that Microsoft published before releasing SP3. In particular, SP3 doesn't install 16 hotfixes published in 2002 or any security hotfixes published after MS02-029, which was released July 2, 2002. When you're preparing to upgrade, compare the security hotfixes in this list, plus all hotfixes published after July 2, 2002, with the hotfixes installed on the systems you plan to upgrade. You can then incorporate the missing patches into a combination-build directory or create a script to apply them after the SP3 upgrade finishes. The Microsoft Windows 2000 Hotfix Installation and Deployment Guide describes several techniques that you can use to install multiple hotfixes with only one reboot.

Update IE
Win2K SP3 lets you hide IE, Microsoft Outlook, and Outlook Express, but you need the most recent version of IE's mshtml.dll to do so without error. If you install SP3 on a system running IE 5.5 SP1 or earlier, IE generates an access violation in the mshtml.dll module when you hide these applications. To avoid this access violation, upgrade to IE 6.0 or IE 5.5 SP2 before you apply Win2K SP3. (See the Web-exclusive sidebar "Known Setup Problems," http://www.winnetmag.com, InstantDoc ID 27116, for discussion of a related problem.)

As a result of Microsoft's antitrust settlement with the US Department of Justice (DOJ), Microsoft no longer bundles IE updates with service pack releases. Win2K SP3 includes security updates from IE 5.01 SP2 but applies no security hotfixes for IE 6.0 or IE 5.5. However, you can find a list of current IE 6.0 updates at http://www.microsoft.com/technet/security/current.asp?productid=119&servicepackid=0 and a list of current IE 5.5 security updates at http://www.microsoft.com/technet/security/current.asp?productid=80&servicepackid=0.

Plan for Automatic Updates
Before you deploy Win2K SP3, you need a corporate policy for managing Automatic Updates. You need to decide whether to enable the feature, and if you enable it, you must select a preferred update mode for workstations, servers, and domain controllers (DCs). Otherwise, any user who can log on with an administrative account can configure Automatic Updates locally—and you might not want desktop systems and servers running to Windows Update daily. The Web-exclusive sidebar "Configuring Automatic Updates Through Group Policy" (http://www.winnetmag.com, InstantDoc ID 27114) describes how to use Group Policy to configure Automatic Updates.