Just a few years ago, all we had to help us with Windows update management was a list of available patches on Microsoft's Web site. Today, our patch-management options range from free Microsoft products such as Windows Server Update Services (WSUS) to full-blown patch management solutions. But even with all these options, many small and midsized businesses (SMBs) fail to implement an update management plan.
Back in 2000, just trying to determine which hotfixes you needed to install was difficult. You could search the list of security bulletins only by year and product, and even then it was easy to miss some fixes. Today, users don't have to put much thought into patch management if they don't want to--they can simply enable Automatic Updates, which does almost everything for them. But Automatic Updates gives little control to network administrators, wastes bandwidth, and can sometimes cause problems with critical servers for which uptime is vital.
A patch management plan helps you better utilize network resources and ensure a smooth, consistent update process for your organization. I've put together a one-size-fits-all patch management plan that you can easily implement by using Microsoft's free WSUS. All you need is a server and an administrator who can dedicate a few hours a week to patch management. Because Microsoft typically releases patches on the second Tuesday of each month, I've built the plan around that schedule.
Prepare the Server
To implement this plan, you need to install the WSUS server. Although you can run WSUS on servers of various configurations (for details, see Microsoft's recommendations at http://www.microsoft.com/windowsserversystem/updateservices/evaluation/
sysreqs.mspx), I prefer a dedicated, clean installation of Windows Server 2003 on a system that has at least 512MB of RAM and 10GB (or more, depending on which updates you deploy) of free disk space. Active Directory (AD) isn't necessary, but it eases system management and deployment.
Before you do anything else, install Microsoft IIS and the latest service packs and updates. If possible, obtain a Secure Sockets Layer (SSL) certificate for the server. Then, install WSUS as explained in the Windows IT Pro article "Let WSUS Ease your Patch-Deployment Hassles," June 2005, InstantDoc ID 46171.
Configure Deployment Groups
Planning your patch deployment strategy helps you minimize problems and put your resources to the best use. The testing and deployment schedule depends on how critical each patch is and how crucial uptime is for each system role in your organization. The problem is that these two priorities conflict; typically, the most valuable, highest-risk assets are also those for which uptime is most important. Usually, you'd want time to thoroughly test patches before deploying them to critical systems, but you also don't want to leave those systems vulnerable to attack any longer than absolutely necessary.
The solution is to test and deploy updates to critical systems before you deploy them to the rest of your network. To do this, you need to establish several deployment groups.
Testing--The Testing group consists of representative systems that will go through specific test procedures.
Critical--In the Critical group, put systems that need to be patched promptly but that also need to remain up.
Pilot--The Pilot group is a small group of representative systems that will receive updates before you roll them out company-wide.
General--The General group consists of all systems that aren't in another group.
Depending on your organization's size and change management policies, you might need to create more groups to reflect more-specific roles. To create each group, click Computers on the WSUS console toolbar, then click Tasks and select Create a computer group. Type the name in the Group name field and click OK.
After you establish the deployment groups, open Group Policy Editor (GPE) for your domain and browse to Computer Configuration\Administrative Templates\Windows Components\Windows Update. If you don't see the Windows Update section and all the settings shown in Figure 1, you need to install the administrative template for WSUS. To do so, copy the file C:\Windows\Inf\wuau.adm from the server on which you installed WSUS to the Windows\Inf directory on your local system. Import the file into Group Policy by right-clicking the Administrative Templates folder in GPE, selecting Add/Remove Templates, and double-clicking the wuau.adm template.
To configure domain members to get updates from WSUS, enable the Configure Automatic Updates policy and the Specify intranet Microsoft update service location policy. For the latter policy, in both the Set the intranet update service for detecting updates and the Set the intranet statistics server fields, type the URL of the server on which you installed WSUS (e.g., http://MSUpdates).
After you set these policies, it might take several hours before all client systems appear on the WSUS server's Computers page. One weakness with WSUS is that it's completely client-based--there's no way to make the server push an update to clients. However, you can make clients check for updates by running the following commands on each client system:
gpupdate /force
wuauclt /detectnow
If all client computers don't appear on the list within an hour of executing these commands, check the event logs for the missing systems. If a system doesn't appear to communicate with the WSUS server, you might have to manually install the client agent, which you can download at http://go.microsoft.com/fwlink/?LinkId=43264.