A Second Look at Automatic Updates

This discussion is a follow up to my article "SP3's Unexpected Automatic Updates Behavior,". Since I wrote that article, I've learned that Microsoft's Automatic Updates client has other unexpected and potentially undesirable aspects. Depending on your frame of reference (or your state of mind) your reaction might be "you get what you pay for," or "automatic updates are better than the manual method." Automatic Updates is the only truly new feature in Windows 2000 Service Pack 3 (SP3). After you upgrade a system to SP3, you can manage that system's update activity locally with the Control Panel Automatic Updates applet. You can also use the Windows Update Administrative template and Group Policy to control update activity on an enterprise basis.

When you log on to a Win2K SP3 system with user privileges and start the Automatic Updates applet, you can view, but not change, client settings. To disable updates or to change how the client operates, you must log on with an account that has local administrator rights. If the client settings are shaded out even when you log on as a local administrator, someone has configured the client with Group Policy. You can't manage the client locally until an administrator disables the Group Policy Object (GPO) update control.

Microsoft’s documentation incorrectly states that SP3 disables the Automatic Updates client. When you open Automatic Updates on a newly upgraded SP3 system, you see that the default configuration checks for and downloads updates from Windows Update every day at 3:00 A.M. On the Automatic Updates screen, you enable the client by selecting the "Keep my computer up to date" check box in the Automatic Updates screen. To disable the client, clear this check box. The Group Policy comments at the end of this column explain why you might want to disable the client locally.

Prompt Mode Operation
When you enable the Automatic Updates client, you can select from two prompt-based update modes and one automatic mode. The prompt-based modes are "Notify me before downloading and … before installing" and "Download updates automatically and notify me when they are ready to be installed." When you select the first mode, the client prompts you to confirm downloads and to confirm installations. When you select the second mode, the client automatically downloads updates and prompts you to approve the installation. The client checks for updates at 3:00 A.M. in both modes. You can change this schedule only by editing client parameters in the registry.

Naturally, you assume that once you configure the client, either locally or with a GPO, that the client will run every day. In the simplest scenario, you log on as a local administrator and configure the client to prompt you for downloads and installations. If you leave the Administrator account logged on for at least 22 hours before the default 3:00 A.M. schedule, the client will check Windows Update, identify critical updates, and place an icon in the lower right corner of your computer screen that prompts you to download or to install the updates (depending upon the option you select). This behavior is exactly what you’d expect.

If you log off as an administrator and log on with a regular user account, the Updates icon disappears, and nonadministrative users have no idea that updates are available or ready for installation. In either prompt-based mode, the client is visible only when a local administrator is logged on. If you don’t understand that nonadministrative users can't interact with the update client, you might mistakenly believe that the client is updating the system every day. This behavior is not what you’d expect.

Automatic Mode
If you want the client to automatically download and install updates, you must select the third option, "Automatically download the updates and install them on the schedule that I specify." In this mode, the client installs updates by using the schedule you select, without regard to the currently logged on user. (The documentation for this option is misleading—it implies that you can use a schedule only when you redirect the client to an internal update server, and such isn't the case.) In automatic mode, the client issues a logoff warning 5 minutes before a reboot when critical updates require a system restart. The warning interval isn't configurable and might be inconvenient for some sites. Many critical updates require a reboot, so you need to consider this factor when you define the schedule, especially at sites where systems are in use around the clock.

Refusing Critical Updates
When you're logged on as an administrator and you select one of the prompt modes, the client displays a pop-up window that provides a minimal description of the queued-up patches. Each patch has a check box with a check in it. You can refuse any update by clearing the check box. This method lets you avoid updates you don’t need or an update that was approved and subsequently recalled on an internal Microsoft Software Update Services (SUS) server. When you decline updates, you can accept them at a later time; however, the refused updates don’t reappear on the list until the next time the client accesses the update server.

Group Policy and Automatic Updates Interaction
If you control update activity with Group Policy’s Windows Update Administrative template, you can configure all clients to use the same mode, whether prompt-based or automatic. (The update template also lets you redirect clients to an internal SUS server.) If you later disable GPO-based update controls, the client isn't disabled—it reverts to the previous local configuration. If, for some reason, you disable GPO controls, SP3 clients revert to the default setting, which means they'll contact the Windows Update site at 3:00 A.M. If you don’t want network systems to use Windows Update, you need to disable Automatic Updates in your standard build images before you release SP3 systems to production.