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.

    Week 1: Identify and Assess
    The first week of the month, prepare for the upcoming updates. Early in the week, check WSUS for any new systems that aren't assigned to a group or that aren't up-to-date with patches. To do so, open WSUS, click Reports on the toolbar, and click Status of Computers on the Reports page. Click View; set Computer Group to Unassigned Computers; select the Needed, Unknown, and Failed check boxes; then click Apply to generate the report. Review the report and apply any updates or resolve any problems necessary to bring all systems to your current baseline.

    On the first Thursday of the month, Microsoft releases a summary of that month's bulletins at http://www.microsoft.com/technet/security/bulletin/summary.mspx. Take time to review the new patches. There won't be much detail yet, but you can get an idea of the number of bulletins, their severity, and which products might be affected. Occasionally, Microsoft will simply state that there are no bulletins, which gets you off the hook for a month unless Microsoft releases an off-schedule update, as it sometimes does for critical bulletins. While you're on the bulletin summary page, you can sign up for the monthly Security Bulletin Webcast, which is scheduled for the day after Update Tuesday.

    With the information from the bulletin summary, you can begin a change request to formally document the upcoming changes. Every organization's quality control needs are different--your organization might have a formal change request process, or it might use something as simple as the form shown in Figure 2, page 12. You might find it helpful to visit http://www.securityfocus.com/bid to review recent vulnerability announcements, which might indicate the nature of upcoming patches.

    With this information, you should have a general idea of how much time to schedule for updates the following week. Based on the affected products, you might also need to make minor adjustments to the members of your Testing group.

    Week 2: Plan and Deploy
    On Monday of the second week, try to clear up any loose ends so you're ready for Update Tuesday. By the end of the day Monday, send an email message to members of the Test group to prepare them for the next day's patch installation.

    At about 10:00 a.m. Pacific Time Tuesday, Microsoft will make the bulletins public. Don't wait for the security bulletin email announcement to hit your Inbox; visit the security bulletin page at http://www.microsoft .com/technet/security/current.aspx or click Get Security Bulletin Notifications in the page's right-hand pane to subscribe to the Really Simple Syndication (RSS) feed for updates.

    Take a few minutes to review each bulletin that applies to your organization and complete and get approval for any necessary change request forms. In particular, pay attention to the listed mitigating factors and workarounds, which will give you hints on things you can do to limit exposure until you deploy the patches. The mitigating factors and workarounds might also give you an idea of specific firewall or Intrusion Detection System (IDS) settings you need to configure. Many companies release their own detailed advisories at http://www.securityfocus.com/bid to correspond with Microsoft's bulletins, so a visit to that site might be helpful.

    Plan your initial deployment to the Test group, and set all other groups to Detect only. Set the deadline for the Test group to a date in the past, as Figure 3 shows, so that installation will be immediate.

    Microsoft has made much progress recently to ensure the quality of updates, but testing is still important, especially for updates you'll deploy to crucial servers. Some companies might require a formal written test procedure; others will be OK with a simple reboot. You should at least verify that the affected products and features still work. Most updates will have a minimal effect on your system and will need only minor testing. If an update affects a critical aspect of your IT infrastructure, you should take the time to carefully test the patch. I find that most SMBs can usually get away with just a day or two of testing.

    After a period of testing, set each patch to Install to the Critical group by the deadline you put on your change request. After you feel comfortable that all critical systems are still running (usually about a day later), set the patches to install to the Pilot group. The Pilot group is just a small representative installation that you'll use to catch any remaining problems before deploying the update globally. Testing for the Pilot group need not be as thorough as for other groups, but members of the Pilot group should know to contact you if the update causes problems.

    Spend the rest of Week 2 addressing problems that have come up. For example, you might find that some third-party applications stop functioning, or you might experience more serious difficulties, such as blue screens. At the end of the week, visit Microsoft's security-related discussion groups at http://www.microsoft.com/technet/community/newsgroups/security/default.mspx to see whether other IT pros have experienced problems that might also affect you.

    Week 3: Final Deployment
    By Week 3, you should have a good idea of whether you'll have problems with the updates. If you do, you can call Microsoft Product Support Services, which doesn't charge for support calls related to security updates. Another good resource is the WSUS mailing list at http://www.patchmanagement.org. After you've resolved all problems, you can deploy the patches to the General group. Throughout the week, check the WSUS status reports on the WSUS server's Reports page and deal with any new problems that have come up.

    By the end of the third week, most systems should be up-to-date. When you're comfortable with the level of deployment, use Microsoft Baseline Security Analyzer 2.0 (MBSA 2.0) to establish a new security baseline for your organization. MBSA 2.0 not only checks the status of updates, but also scans for specific vulnerabilities and misconfigurations, such as weak passwords, that might leave a system exposed to attack.

    New analyzer features integrate with your WSUS deployment. For example, MBSA 2.0 uses your WSUS server to download the latest update catalog and lowers the priority of updates that aren't yet approved. The analyzer uses the same Windows Update Agent and update catalog that WSUS uses. MBSA 2.0 also helps you identify systems that aren't yet assigned to a WSUS server and can scan by domain name or a range of IP addresses to ensure complete coverage of your network.

    MBSA 2.0 is a bit more flexible than WSUS and can be helpful if WSUS is unable to patch a system or properly identify needed updates. MBSA provides more detail on file versions and better explanation of why an update failed. It also includes a command-line version that you can automate through scripts. If you have a large network, you might want to scan different groups of systems each month, but you should run MBSA regularly to ensure a consistent security baseline for your organization.

    Week 4: Prepare for Next Month

    Although you have a week or two left in the month, your patch management duties aren't finished yet. At the beginning of Week 4, mark the first Thursday and second Tuesday of the next month on your calendar so you'll be ready for the next set of updates. Take time during the rest of the month to keep up-to-date with non-Microsoft OSs and software, virus and spyware updates, and IDS rules. And check your WSUS reports weekly to ensure that all systems conform to your baseline so you'll be ready when Week 1 rolls around again.