Troubleshooting Service Pack Upgrades

Troubleshooting Service Pack Upgrades
I've used three techniques to successfully upgrade servers and workstations, although I've not yet tried to update a domain controller (DC). The three techniques I tested include a local update that I started from the command line (w2ksp3.exe) on Windows 2000 Advanced Server Service Pack 2 (SP2); a network update I started with update.exe (on Win2K AS SP2 with many hotfixes), and a Group Policy (GP)-packaged update using update.msi (on Win2K AS with no service packs or hotfixes). Many of you have written to me about problems upgrading or have asked me questions about the upgrade procedure, so here’s an overview of the main steps that occur during a service pack upgrade.

• When you start an upgrade by double-clicking or running w2ksp3.exe, the installer uncompresses the service pack files to a temporary folder and runs update.exe from the temporary folder.
• The installer inventories system files and identifies files that must be updated.
• During the inventory, the installer displays the End User License Agreement (EULA) and prompts you to create an uninstall directory. This is the last opportunity to safely cancel the upgrade.
• The installer creates the $NTServicePackUninstall$ folder and copies into it all files that are marked for update.
• The installer replaces system files with files from the service pack. If the files are locked (in use), the installer gives the replacement file a temporary name and adds it to the "file rename pending log". The system replaces these files during the reboot.
• The installer parses applicable .inf files to update registry hives.
• The installer executes several programs using Rundll32.exe. These programs register Java applets, apply the upgrade security template, remove performance monitor counters, and perform other cleanup tasks.
• The installer deletes all temporary upgrade files and initiates a system restart.
• The file rename process finishes after the computer reboots.

Win2K SP3 setup logs all of the above activities in the log file \%systemroot%\svcpack.log. When the upgrade is successful, the first portion of the log contains references to “old information in the registry,” and “new information in the registry.” Next, if you use the default option, the log file shows the installer creating the uninstall directory, followed by several lines that estimate the time it will take to create, download, and expand service pack files, and create the uninstall directory. Then the installer registers the uninstall program and copies files to various locations in the system root. During the last stages, setup renames .dll files to temporary file names and runs several housekeeping programs (lines that begin with “Starting Process:”). If setup fails for some reason, comparing the logfile contents of the successful upgrade with the contents of the log file on the system where the upgrade failed might help you identify the problem.

Readers Share SP3 Problems and Solutions
I’ve received a great deal of mail regarding unexpected behavior during or after an SP3 upgrade. Here are three users' experiences that might save you some time and trouble when you’re testing this mammoth code update.

DHCP Problem
Reader Brian Gilbert passed along his experience with SP3 and DHCP: “Service Pack 3 has a bug in the dhcpsnap.dll that breaks the Reservation portion of the DHCP. I have about 200 reservations on my DHCP server. After installing SP3, I could no longer see or modify the reservations. I could add new reservations. After leaving messages at Microsoft and getting no response, a colleague found this problem and a solution at the Microsoft.Public.WindowsUpdate newsgroup. To correct the problem, I replaced the problematic SP3 dll with dhcpsnap.dll from the service pack backup directory and everything worked just fine.”

Desktop Applicationss Don’t Stay Hidden
Reader Dan Weikert passed on this tip about a known problem when you hide desktop applications: “Win2K SP3 includes the option to hide various applications, Internet Explorer (IE) and Outlook Express, for example. We use Outlook primarily in house, so as a test of a recent installation of Win2K and SP3 I turned off the visibility of Outlook Express. It worked until I upgraded the machine to IE 6. Then that pesky Outlook Express icon reappeared in the quick launch bar. The setting was still set to hide and it wasn't on the desktop, but I had to manually delete it from the quick launch bar.”

Automatic Updates Uses Port 443
Anthony Miller encountered problems with Automatic Updates on a Win2K SP2 system. “When running Windows update from the Tools menu, and I click "Scan for Updates," I get back zero updates available. I know there are available updates. (SP3 for instance!) If I click Windows Update in the left pane under "See Als," I got a similar message as you did but with a different hexadecimal code. I get 0x800A138F. This problem occurs only on three servers that sit in the demilitarized zone (DMZ) behind a firewall. I have yet to update to SP3, so there might be a bug in the ActiveX control. Of course, I can manually download updates but that kind of defeats the purpose.” After testing, Anthony discovered that “the new ActiveX control collects patch information and sends/receives that information over port 443 instead of port 80 as in the past (Windows Update from an NT server seems to be still using port 80 for everything). Port 443 was blocked for those servers in our firewall. Once opened, Windows Update worked as expected.”