2004-02-11
|
Patch management could easily be called the bane of every administrator's existence, the pain in the rear of system management, or that never ceasing headache that pounds at CIOs everywhere.
And I use the term "management" loosely. As I write this there are more than 40 updates that need to be applied to a new Dell computer running Windows XP. There were over 20 updates for Windows 2000 Service Pack 3 to apply to new systems before Microsoft released the fourth service pack in the summer of 2003. With this ever-growing hairball of security fixes, bug fixes, critical updates, and patches, might it be easier to disconnect all machines from the Internet and work with stone tablets than deploy new systems? But that's not feasible, of course. As things stand now, there are a few ways to handle distributing and applying updates:
In this three-part feature article, I'll discuss Microsoft's Software Update Services (SUS) in depth, including installation, administration, and maintenance. I'll also look at freeware and commercial alternatives to patch management and why certain solutions might-or might not-be the best fit for your enterprise. About Software Update ServicesMicrosoft's Windows Update technology-the software that runs the universal update site for all but the oldest versions of Windows-drives SUS. The company limited SUS at this point to critical updates only, allowing administrators to somewhat easily deploy these patches to servers running Windows 2000 or Windows Server 2003, as well as desktop computers running Windows 2000 Professional or Windows XP Professional. It's designed to work especially well in networks with an Active Directory implementation, but it will function without one. As you'll see from this piece, overall Software Update Services is a tool that's not perfect, that has limited functionality, and isn't very flexible, but it has two great plusses: it's timely, and it works fairly well.Using SUS involves having at least one server connected to the Internet running the actual server component of the application. This machine acts as a local version of the public Windows Update site, containing critical updates and service packs for all supported operating systems. This server synchronizes with the public Windows Update site on a schedule which you, as the administrator, select, and you then approve or reject the availability of certain updates on the SUS server. The Automatic Updates feature-found on Windows 2000 Service Pack 3 and higher or Windows XP Professional at any revision level-is the client side portion of SUS. Directed by a registry change or by an applied group policy object, the client computers that are running this automatic updates feature are sent to the local network's SUS server on a set schedule to download updates appropriate to their machines. The SUS server will analyze the operating system, service pack level, and currently installed updates and only push those updates that are both needed AND approved by the administrator beforehand. There are a few phases to the SUS installation, covered well in a document Microsoft prepared entitled "Software Update Services Deployment White Paper," found at http://www.microsoft.com/windowsserversystem/sus/susdeployment.mspx. Since the installation and initial configuration is fairly straightforward, I'll step through the guide, simplifying its language in places, and point out some issues and problems I've encountered. Synchronizing and approving contentWhen you start the content synchronization process, the SUS server goes out to either the public Windows Update servers or another local SUS server (as configured in the Set Options section) and downloads the entire library of available critical updates and service packs for each language you have configured. This synchronization usually results in about 150 MB worth of data being transferred for just English updates, or close to 600 MB for updates in every localization.
To synchronize content, surf to the SUS administration web site, and then:
You can also opt to schedule your synchronizations automatically, so that you don't have to remember to re-synchronize every time a new update is released-which is all too often in most of our opinions. On the Synchronize server page, click Synchronization schedule, set your desired options for synchronization and then click OK. Be aware that if the SUS server can't connect to the appropriate upstream update source, it will repeat its attempts four times, spacing out each attempt by half an hour. Now that you have an actual library of updates on or near your SUS host machine, you can approve the updates individually for distribution to client machines within your network. To begin the update approval process, in the navigation pane, click Approve updates, and then in the right-hand pane, select the updates that you would like to approve, and click Approve when you've finished your selection. Pushing out the Automated Updates clientYou can install the updated Automatic Updates client on your clients by installing the Automatic Updates client using the MSI install package, self-updating from the old Critical Update Notification (CUN) tool, installing Windows 2000 Service Pack 3 or 4, installing Windows XP Service Pack 1, or installing Windows Server 2003.Since the client installation program is an MSI, you can easily push the client-side program to clients by using Group Policy. To create a new GPO, assign it to your computers, and then have it installed automatically. The application will be installed in the context of the local computer, so be sure that authenticated users have rights on the source folders. You can also deploy the client MSI through a logon script by calling MSIEXEC followed by the client software filename as an argument. The software will be installed as requescned. Using Group Policy, there are four options to configure:
You need to be aware of a potential problem with GPO assignment: if you assign the SUS instructions as a GPO at the domain level, the time that you specify hosts to get their updates is identical for all of them. So you'd have 5,000 computers contacting your SUS server for updates, which could possibly slow the server down to a death crawl. Instead, consider adding the GPO at the OU level, which would simplify things by alternating the time at which systems contact the SUS server for updates. To adjust some of these behavior settings through registry changes, use the following guide:
Consider using a Registry editor file such as the following to automate registry changes. Below is a sample file that you can modify according to the above guide:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate] "WUServer"="http://YOUR-SUS-SERVER" "WUStatusServer"="http://YOUR-SUS-SERVER" [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU] "RescheduleWaitTime"=dword:00000003 "NoAutoRebootWithLoggedOnUsers"=dword:00000000 "NoAutoUpdate"=dword:00000000 "AUOptions"=dword:00000004 "ScheduledInstallDay"=dword:00000000 "ScheduledInstallTime"=dword:00000006 "UseWUServer"=dword:00000001 You might even consider creating and using an MSI to distribute the SUS register settings to be very beneficial. You can deploy the changes via a .exe or .msi on a non-domain machine. Additionally, you can use the Add/Remove Applications applet in the Control Panel to remove settings. Finally, they're relatively easy to create, using the free copy of WinInstall LE that comes free on the Windows 2000 Server distribution CD. There are also third-party packaging tools available. Coming upAs I mentioned at the beginning of the article, SUS is good in part due to its price (free), but it lacks several features that other patch management products have, including:
There are ways around at least the first limitation, however, and in the upcoming second part of the article, I'll cover a couple of ways-and their associated tradeoffs-to use and glean information from log files. I'll also cover some common problems and their workarounds, and how to monitor the status of client downloads and installations.
|
About the author
Jonathan Hassell is an author and consultant specializing in Windows
administration and security. He is the author of Managing Windows
Server 2003 and RADIUS, both published by O'Reilly & Associates, and
Hardening Windows, published by Apress. He also has written for Windows
& .NET Magazine and WindowsITSecurity.COM and is a contributor to PC
Pro, a leading computer magazine in the United Kingdom.
|