Tuning Automatic Updatesby Mitch Tulloch, author of Windows Server Hacks
Keeping all the systems on your network properly patched and protected can be time-consuming and difficult, but it's a vital job these days as the interval between the discovery of a vulnerability and an exploit of it appearing in the wild continues to shrink. A great way to keep all your systems properly patched is to use Automatic Updates (AU), which automatically keeps Windows up-to-date with security patches and other critical updates released by Microsoft.
AU first appeared in Windows Millennium Edition, where it replaced an older Windows 98 feature called Critical Updates. Since then AU has gone through several revisions, and the latest version AU 2.2 is built into Windows Server 2003, and included in Windows 2000 Service Pack 3 and Windows XP Service Pack 1. In this article, we'll look at how to use AU, and how to tune its operation.
Using Automatic Updates
AU can be used in two different ways. First, you can configure it directly so your machines will download and install patches straight from the Windows Update web site. You can do this by using a Control Panel applet (the Automatic Updates tab in the System applet in Windows XP/2003 or the Automatic Updates applet in Windows 2000); using Group Policy (Computer Configuration-->Administrative Templates-->Windows Components-->Windows Update); or by editing the Registry (HKLM\Software\Policies\Microsoft\Windows\AU). (For more details, see Microsoft Knowledge Base (KB) article 328010.)
The second approach is to use AU in conjunction with Microsoft Software Update Services (SUS), a free tool that lets you download critical updates, approve them, and deploy them to machines on your network. The advantage of using SUS is that you can test downloaded updates before installing them on critical servers, which can save your bacon since occasionally a patch will end up fixing one thing while breaking another. With SUS on the server-side and AU as the client, you have complete control over how and when critical updates are deployed on your machines. For an overview of how SUS works and to download the latest version of AU, see Software Update Services on Microsoft's web site.
Configuring Automatic Updates
You'll probably want to configure AU using Group Policy if you're in an enterprise environment where Active Directory is deployed. To do this you could either edit existing Group Policy Objects (GPOs) or create new ones and link them to various organizational units (OU) where computer accounts reside. Figure 1 shows the four policy settings used to configure AU. (If you see only two settings when you get here, you need to add the
wuau.adm template in the
%windir%\inf folder to Administrative Templates under Computer Configuration in your GPO.)
Figure 1. Group Policy settings for configuring Automatic Updates.
The first policy, Configure Automatic Updates, (Figure 2) contains the main configuration settings for AU and lets you enable the feature, choose whether to download or install updates automatically, and specify a schedule for installing downloaded updates. The remaining three policies let you specify a SUS server (if you're using SUS), determine how long to wait after rebooting before installing downloaded updates if the previous scheduled install was missed, and decide whether to prevent AU from automatically rebooting the machine to complete installation of updates.
Figure 2. Details of the Configure Automatic Updates policy setting.
Tuning Automatic Updates
How you tune AU depends to a degree on whether you are using SUS. If your machines are configured to download updates directly from Windows Update, consider configuring AU so that updates are automatically downloaded and installed without any intervention on your part, and set the schedule so that updates are installed only once a week instead of daily as the default settings specify. For example, configure AU to automatically install downloaded updates Saturday morning at 2 a.m. so that if something goes wrong you at least have the weekend to troubleshoot the problem and weekday users will be least affected.
If you're using SUS, then you have more flexibility for configuring AU since only those updates you approve on the SUS server will be installed. This gives you time to test updates before deploying them to business-critical servers and to avoid any problems that might arise from updates breaking applications. However, most administrators prefer to manage their lives proactively -- instead of reacting every time a new update becomes available from Microsoft -- so installing updates once a week usually gives you better control over your network security than doing it daily.
There are times, however, when an update has to be installed right now instead of waiting for the next scheduled install -- for example, when an exploit suddenly appears in the wild that threatens unpatched servers. In this case you may want to push updates immediately from your SUS server to your AU clients, and the problem here is that AU is hard-coded to check for updates every 22 hours (minus a random offset of up to 5 hours). To work around this, you'll have to force AU to perform a detection cycle and check for pending updates ready to be installed. Here's how you can do it:
gpedit.mscto edit your GPO and change the "Configure Automatic Updates" policy setting to "Not configured," while leaving the "Specify intranet Microsoft update service location" setting "Enabled."
Force a refresh of Group Policy using
secedit /refreshpolicy(on Windows 2000) or
gpupdate /force(on Windows Server 2003 and Windows XP) so you can configure AU automatically on the machines.
Open the System (on Windows XP/2003) or Automatic Updates (on Windows 2000) applet in Control Panel on each machine and clear the checkbox labeled "Enable Automatic Updates," click Apply, count to 10, reselect the checkbox, and click OK.
After about five minutes an AU detection cycle should occur and the approved updates will be downloaded and installed. Don't forget to reset the "Configure Automatic Updates" setting back to "Enabled" afterward. For instructions on how to verify this worked, see Microsoft Knowledge Base article 326693 .
Return to WindowsDevCenter.com.