A better way to keep up with security fixes
Patch management is a headache for security administrators at most organizations. To handle patch- management tasks, smaller organizations tend to rely on automatic updates from vendors' Web sites, such as Windows Update. Midsize organizations typically use patch- management solutions such as Software Update Services (SUS), and enterprise-class organizations leverage sophisticated tools such as Microsoft Systems Management Server (SMS) 2003. Recognizing SUS's deficiencies, such as the limited range of products that it lets you update, Microsoft has developed an improved patch-management product, called Windows Server Updates Services. WSUS offers benefits for organizations of all sizes, thanks to its flexibility, advanced features, and ease of deployment. We'll walk through the process of installing and configuring WSUS for your organization, obtaining updates, and configuring clients to use WSUS to obtain updates.
By the time Microsoft releases the final version of WSUS, it might include enhancements or additional features not in the Release Candidate (RC) version, which is currently available at http://www.microsoft.com/wus. (In June or July, Microsoft will ship the final version of WSUS as well as Microsoft Update, the successor to Windows Update.) Although I've found the WSUS RC to be stable, I recommend you experiment with it in a test environment until it's released. You'll also need to download Background Intelligent Transfer Service (BITS) 2.0 beta software via the WSUS Web site. WSUS runs on Windows 2000 Server and later and requires Microsoft Internet Information Services (IIS) 5.0 or later, BITS 2.0, ASP.NET, Windows .NET Framework 1.1 Service Pack 1 (SP1), a Microsoft SQL Servercompatible database, and an NTFS volume that has enough free space for WSUS and any updates it downloads for distribution to clients. WSUS ships with Windows Microsoft SQL Server 2000 Desktop Engine (WMSDE) for Windows Server 2003. If you're installing WSUS on a Win2K Server system and don't have a SQL Server 2000 database server, you can download and install WMSDE instead. For a typical configuration that supports fewer than 500 client systems, Microsoft recommends a system that has a 1GHz or faster processor, 1GB of RAM, and 30GB of free disk space. For a system supporting more than 500 clients, Microsoft recommends a system with a 2GHz or faster processor and a full installation of SQL Server 2000. The actual minimum requirements for WSUS are much lower, but if possible, you should install WSUS on a system that meets or exceeds the recommended configuration.
Installing WSUS is a relatively simple, wizard-driven process. After you've started the wizard by running the WSUS installation executable and accepting the license agreement, you're prompted to select the location in which updates will be stored. The default location is C:\WSUS; the WSUS installation creates a subfolder called WSUSContent under the selected location. Make sure you select a location on an NTFS volume that has enough free space to store downloaded updates.
The next wizard screen prompts you to specify details about the database you'll use to store information about updates and clients. If you're installing WSUS on Windows 2003, you can choose either to have the wizard install WMSDE as your database (the default), or you can select another database instance on the server. The default location for WMSDE is C:\WSUS; the WSUS installation creates a subfolder called MSSQL$WSUS (which is also the name of the WMSDE instance). If you're installing WSUS on Win2K Server, you must select a WMSDE or SQL Server instance that's already running on the system, by selecting the Use an existing database server on this computer option and selecting a database instance. If you want, you can install WSUS in a front-end/back-end configuration where the SQL Servercompatible database is installed on another server. The WSUS deployment guide describes the process of installing a front-end/back-end configuration along with caveats about its use.
Next, the wizard asks you to select the Web site to use for the WSUS administrative tool and Web services. You can elect to either run WSUS on the default Web site or create a new WSUS Web site that listens on an alternate port. I recommend that you run WSUS on a dedicated server and use the default Web site because Automatic Updates on WSUS clients won't update itself if WSUS is listening on a port other than port 80/TCP (HTTP).
WSUS servers can be deployed in a centralized management topology. Replica WSUS servers inherit or mirror the configuration of a central WSUS server. You can create replica servers only during WSUS installation. The next step in the installation wizard lets you specify the central server to inherit settings from if you're creating a replica server.
After you've selected the installation options, WSUS displays a summary screen before it begins the installation and configuration process. When the installation is finished, you can launch the WSUS administration Web page, which Figure 1 shows, by selecting Start, All Programs, Administrative Programs, Microsoft Windows Server Update Services.
Now you're ready to configure the WSUS server to obtain software updates. Start by clicking the Options icon at the top-right corner of the administration Web page and selecting Synchronization Options. If you haven't configured WSUS yet, the first time you attempt to synchronize WSUS to obtain software updates (click the Get started by synchronizing your server link in the To Do List section), the Synchronization Options configuration page will be displayed. Before you click the Synchronize now icon in the Tasks section, you should ensure that your WSUS server is configured correctly. The first configuration option is the synchronization schedule. Select either to require WSUS to automatically obtain updates once a day or to require manual synchronization (i.e., the WSUS server must be synchronized by the administrator when required).
Next, choose the products for which you want to obtain updates and the update classifications. By default, the WSUS server will download critical updates and security updates for all Windows products. You can change the products and types of updates that WSUS will obtain by clicking the appropriate Change button. Clicking Change under Products displays a dialog box where you can select the products for which you want to download updates. Clicking Change under Update classifications displays a similar dialog box listing types of updates that can be downloaded. You can select as many types of updates as you want; WSUS will retrieve those types but won't necessarily automatically distribute them to clients. The list of products and update classifications that WSUS supports are downloaded from the Microsoft Update site at each synchronization.
Scroll down the Synchronization Options page, which Figure 2 shows, and enter details about your proxy server, if you use one. If you perform egress filtering on your proxy server or firewall, you'll need to configure it so that WSUS can connect to the Web sites listed in Web Table 1 (http://www.win dowsitpro.com/windowssecurity, InstantDoc ID 46195). Next, specify where WSUS will obtain its updates. The default is the Microsoft Update site. However, a powerful feature of WSUS lets you build a hierarchy of servers so that the downstream server obtains updates from upstream servers. You can use this type of configuration to minimize the load on your Internet connection and your dependency on it. Typically, you'll configure the root WSUS server to obtain all updates for all products in your organization, and you'll configure second-tier servers to fetch only the updates required for their clients or downstream servers. A hierarchy of WSUS servers is different from a centralized management topology in which you create replica servers because you can manage downstream WSUS servers independently from the upstream servers from which they get their updates.
Finally, on the Synchronization Options page, click Update Files and Languages Advanced to select which update files to fetch during synchronization and which languages to download updates for. Another powerful feature of WSUS is that you can configure it to download only information about updates and not the actual updates before you approve the updates' distribution to clients. This feature lets you review available updates and decide which are necessary for your clients. You can also choose to download express installation files for updates to speed installation on clients. After you've configured WSUS, you can start a manual synchronization by clicking the Synchronize now icon in the Tasks pane. When synchronization is finished, you can obtain detailed statistics, including which updates were downloaded during synchronization as Figure 3 shows, by clicking the Last synchronization result value on the administration home page.
Configuring WSUS Clients
After you've installed and configured WSUS and verified that you can obtain software updates, the next step is to configure client systems to connect to WSUS and organize those systems into groups. A WSUS client can be any client running a supported Microsoft product. You can find a list of supported OSs and servers by clicking the Options icon on the WSUS administration home page, selecting Synchronization Options, then clicking the Products Change button.
Like SMS 2003, WSUS requires an agent on each client. Unlike SMS 2003, WSUS can't be configured to push agents to clients automatically. The good news is that the agent is the familiar Automatic Updates agent that ships as part of Windows XP and is the same as the agent shipped for Win2K as part of SUS. With the exception of the agent that ships with XP, Automatic Updates can download and install an up-to-date version of itself via WSUS. If you're running a pre-SP1 version of XP or if you have Win2K clients that don't have the Automatic Updates agent installed, you can download the Automatic Updates client at http://www.microsoft .com/windows2000/downloads/ recommended/susclient/default.asp. This version is packaged for distribution in corporate environments. You can learn more about how to deploy Automatic Updates in the Software Update Services Deployment White Paper at http://www.microsoft.com/ windowsserversystem/sus/susdeploy ment.mspx. For individual clients, you can download the Automatic Updates agent via Windows Update.
You can configure an Automatic Updates client to connect to WSUS in one of two ways. If clients are members of an Active Directory (AD) forest, you can configure Automatic Updates to connect to WSUS by using Group Policy Objects (GPOs). If your clients aren't part of a forest, you can configure them individually by using the Microsoft Management Console (MMC) Local Security Policy snap-in. In Group Policy Editor (GPE) or the Local Security Policy editor, navigate to Computer Configuration, Administrative Templates, Windows Components, then click Windows Update. At a minimum, you need to set the Configure Automatic Updates and Specify intranet Microsoft update service location settings. The first setting tells Automatic Updates how to handle updates (the default is to automatically download updates and notify the administrator that they're ready for installation). The second setting contains the URL for the WSUS and statistics servers to which the Automatic Updates client reports (you should use the same URL for both).
After you've configured clients to use the WSUS server, you should organize them in groups on the server. Groups are used to approve updates for collections of clients. Two built-in groups are created during WSUS installation: All Computers and Unassigned Computers. If all WSUS clients are configured alike, you don't need to create additional groups; you can approve updates for one of these two groups. You create groups by clicking the Computers icon, then clicking the Create a computer group icon in the Tasks pane. You can manually move computers into groups on the server by selecting a computer from the Unassigned Computers list, clicking the Move the selected computer icon in the Tasks pane, and selecting the group you want to move the computer into from the drop-down list. Alternatively, you can set a client's group name by using a GPO or Local Security Policy; this is called client-side targeting. This method is especially useful if you organize your desktops and servers into organizational units (OUs) by function or configuration and you use GPOs to configure computers in the OUs. Simply set the GPO setting Enable client-side targeting to the name of the WSUS computer group in which you want computers affected by the GPO to be members. You enable client-side targeting on the WSUS server by clicking the Options icon on the administration Web page, clicking Client Computer Options, and selecting the Use Group Policy or registry settings on client computers option. You'll also need to create the groups the clients will be members of. You can configure additional settings on the client through GPOs or Local Security Policy, which give you more flexibility about how Automatic Updates runs.
You can examine information about which updates have and haven't been applied to clients and which aren't applicable as well as basic information about each client, such as its hardware configuration and when the Automatic Updates client last contacted the WSUS server. To do so, click the Computers icon on the Web administration page, then select the client whose information you want to display.
Approving Updates for Groups
Updates obtained from Windows Update or from an upstream WSUS server aren't automatically distributed to clients. Before an update can be distributed, the WSUS administrator must first approve it for detection and for distribution. By default, only critical updates and security updates are approved for detection on clients in the built-in All Computers group, and updates are automatically approved for distribution. You can change which updates are automatically detected, which updates are automatically approved, and which groups of clients are included in both automatic detection and approval by clicking the Options icon, then clicking Automatic Approval Options, which displays a page like the one that Figure 4 shows.
For updates that aren't automatically approved for detection or distribution, you'll need to configure each type of approval manually. To do so, click the Updates icon, which displays a page like the one that Figure 5 shows. Each update that's been downloaded to the WSUS server is listed along with comprehensive information about the update; whether or not it's automatically detected and approved; and if automatic detection or approval is enabled, the computers (organized by group) on which the update is needed or installed. You manually configure an update for detection or approve it by selecting the update from the list and clicking the Change approval icon in the Tasks list. Doing so displays a dialog box in which you can approve the update. Options include Detection, Install, and Not approved. If you choose to install an update, you can set a date and time deadline for its installation by clicking the hyperlink next to Deadline. By default, no deadline exists and users with administrative privileges on the clients can choose when to perform the installation. Occasionally, an update will supersede another. In this case, you can prevent previous updates from being applied if they haven't yet been by selecting the Decline all updates superseded by the selected updates check box.
If updates are approved for installation on clients, they'll be installed the next time a client's Automatic Updates connects to the WSUS server. If only information about the update has been downloaded to the WSUS server, the server will download the entire update from Microsoft Update or the upstream WSUS server in preparation for downloading to clients.
You can also use WSUS to remove installed updates, if the update supports removal. This feature lets you roll back updates that cause problems with installed applications or other updates. To remove an update, select it from the list of updates, click the Change approval icon in the Tasks list, and select Remove from the drop-down list in the update dialog box.
Generating Reports with WSUS
WSUS lets you generate three types of reports, which you do by clicking the Reports icon on the WSUS administration page. The first report is a Status of Updates report that lists the updates downloaded to the WSUS server, whether they've been detected as necessary for clients, and whether they've been installed. The second report, Synchronization Results, details the last synchronization that the WSUS server performed either via Windows Update or an upstream WSUS server. The third report is a Settings Summary, which lists the pertinent settings for the WSUS server.
WSUS Support for Remote and Mobile Clients
Ensuring that remote and mobile clients are properly patched is an additional challenge for organizations of all sizes. Typically such clients connect to the network via dial-up or VPN circuits for varying periods of time, often over slow network links and not long enough to contact WSUS and to download approved updates. WSUS supports the option of distributing information about approved updates to the clients, then directing them to contact Microsoft Update to download them. To configure this option on a client, click the Update Files and Languages Advanced button and select the Store update files on Microsoft Update option. Unfortunately, such a setting isn't Computer-group specific; it affects all groups on the WSUS server and all clients that connect to it. If you plan to take advantage of this feature, you should dedicate WSUS servers to serve your remote and mobile clients.
Before deploying WSUS in a production environment, you should carefully plan your WSUS installation. Your first step should be to identify the systems that will be WSUS clients and to group them into categories. At this point, you might want to organize AD and collect client systems into OUs in preparation for using GPO to set Automatic Updates settings. If you decide to create a hierarchy of WSUS servers, you'll need to determine which downstream servers will distribute which updates and to which groups of clients. Upstream servers will need to obtain the updates distributed by downstream servers, even if they don't distribute the updates to clients themselves. After you've built your WSUS infrastructure and created groups, you can begin to point Automatic Updates on clients to WSUS servers. If feasible, you should use client-side targeting; otherwise, you'll need to manually move computers into groups on the WSUS server. As a best practice, you should test all updates thoroughly before distributing them. You might want to consider creating test or pilot groups and have WSUS distribute updates to them automatically. If no problems are reported, you can then approve the update for wider distribution after a fixed period of time. After you start using WSUS, you'll probably find that your patch-deployment headaches have been eased considerably.