Several readers reported experiencing the same problem with Windows 2000 Service Pack 3 (SP3) Automatic Updates: the Automatic Updates client fails with the error message "Send error number to Microsoft (0x800A1391). Note this sends error information but does not create a support incident; you may or may not receive a response." Because of the lack of documentation about the problem, I spent many hours testing manual and automatic update processes. I have some insight into the problem, a couple of suggestions for avoiding update problems, and several unanswered questions.

The Update Class ActiveX Control
The first time you browse to Microsoft's Windows Update site, the site queries your system and prompts you to install and run Windows Update Control V4. Windows Update requires that you install this ActiveX control locally to successfully interoperate with the update scan and download procedures. If you respond no to both prompts, Windows Update assumes you're not logged on with administrative privileges and provides instructions about how to use the RunAs command to log on with an Administrator account. Without the ActiveX control, Windows Update and the Automatic Updates client will fail.

If you respond yes to the prompt, Windows Update downloads an ActiveX control called Update Class and places the file in the %systemroot%\Downloaded Program Files directory. Windows Update creates and populates the Program Files\WindowsUpdate directory structure. The \v4 subdirectory contains a history of update activity, including scan results and downloads, if any. If you read any of the download documentation before you download the files, you'll find a copy of each document in the \wuaudnld.tmp\rtf\ directory. Deleting the Program Files\WindowsUpdate directory does not appear to interfere with the manual update process.

When I selected the Windows Media Player (WMP) update, Windows Update created a temporary directory on the boot drive called WUTemp and placed the downloaded file in a subdirectory named for the update. If you want to keep a permanent copy of such updates, you need to move them to an alternate location, preferably on a shared network drive.

During testing, I deleted the ActiveX control from the Downloaded Program Files directory and deleted the Program Files\WindowsUpdate directory, then rebooted to flush all controls from memory. Much to my surprise, after I restarted Windows Update, the program didn't prompt me to install the missing control. Instead, the program successfully scanned the system and downloaded the updates I selected. I have yet to figure out where the hidden copy of the Update Class control is located. If you have any suggestions, I'd love to hear them!

The Automatic Updates client accesses several catalogs at Windows Update to identify and download needed hotfixes. Based on my testing, the update client is not smart enough to download the Windows Update Control V4. For successful updates, you need to download the control manually or copy it from another system before you enable automatic update activity. So, for example, if you install Win2K SP3 on a new system or on a system that hasn't downloaded the new V4 Update Class control (latest version is 5.4.3630.11), the Automatic Update client will fail.

Automatic Update Q&A

Does the client run automatically?

Microsoft's documentation states that an SP3 upgrade disables the client, but I didn't see this behavior. My testing produced consistent results on two systems: one system on which I had previously used Windows Update and a second on which I removed and reinstalled SP3. In both cases, the client was enabled and the second update mode, "Download the updates automatically and notify me when they are ready to be installed," was checked. However, the client didn't appear to run until I cleared and then checked the "Keep my computer up to date" twice. If you don't want this functionality, you can permanently disable the client by clearing the "Keep my computer up to date" option, but you can't physically remove the Automatic Update code from the OS.

Will the client update my system if I'm not logged on?

You configure Automatic Updates behavior by using Group or Local Policy. If you don't control this feature with Group Policy and you want the client to run, you must log on as an Administrator. Start Automatic Updates in Control Panel and enable the client by checking the "Update my computer" option. Next, check one of the three available update modes. When you check either of the first two modes (Client prompts before it downloads and prompts again before it installs, or Client silently downloads but prompts before it installs), the client runs daily at 3:00 A.M., even when you're not logged on. The client silently downloads the updates but doesn't prompt you to install them until you log on. Microsoft's documentation also states that you can only select the third option (where you specify the date and time when the client should check for updates) when you also point the client to an internal update server. However, I checked this option and later received a prompt to install updates the service had downloaded. I don't have an explanation for this behavior right now, but I'll keep working on it.

Can I refuse to install updates?

When the client is ready to install patches it has downloaded, it lists the updates that are ready to go and prompts you to continue. You can refuse any or all of the patches; the client keeps track of the declined updates, and you can install them at a later time by clicking the Declined Updates button in Control Panel’s Automatic Updates client. The client logs hotfix installation in the System event log.

What's the difference between Automatic Updates and Windows Update?

Automatic Updates scans for and downloads only critical updates. The client uses Windows Update, which performs only a subset of the analysis that happens when you manually visit the site. When you instruct Windows Update to scan your system, it recommends the same critical hotfixes, plus additional upgrades that are appropriate for your system (e.g., updated device drivers). Windows Update isn't aware of the interdependencies between downloads, so it might recommend SP3, plus earlier post-SP2 updates. To avoid potential disasters, I recommend that you carefully scan the list of recommendations before you download and install them.

Also, after I instructed Windows Update to install the pre-SP3 fix MS02-006: An Unchecked Buffer in the SNMP Service May Allow Code to Run (Q314147) and pre-SP4 fix MS02-042: Flaw in Network Connection Manager Can Cause Rights Elevation (Q326886) on my test SP2 system, I rebooted and opened the Add/Remove Programs list. When I clicked either hotfix, Add/Remove programs responded with a Doctor Watson error "mshta.exe has generated errors and will be closed by Windows. You will need to restart the program...." That was not exactly the expected, or desired, outcome. To be honest, all these discrepancies occurred on a system that boots multiple instances of Win2K Server, Win2K Advanced Server (Win2K AS), and Win2K Professional (Win2K Pro). A multiboot system is great for testing purposes, but the multiple roots might be the source of this access violation and other unexpected results.