Thus far, our Windows Patch Management series has focused on a number of free solutions from Microsoft that offer patch deployment and inventory capabilities. This installment and the next will round out the picture with coverage of Software Update Services (SUS), another patch deployment mechanism from Microsoft.
SUS was first released in June 2002 and is currently at version 1.0, Service Pack 1. Unlike the tools in the same category that we previously described (such as Critical Update Notification and Windows Update), which are intended primarily for non-managed environments and are limited in their ability to be centrally managed, SUS was designed to enable a higher level of customization for deployment infrastructure and patch selectivity.
In traditional Windows Update scenarios, client computers running the Automatic Update service pull a list of applicable updates directly from Microsoft servers. SUS also relies on the Automatic Update service running on client computers (which limits its scope to Windows 2000 and later operating systems), but it adds a layer of processing. This layer consists of at least one computer internal to a company's network running Windows 2000 SP2, or later, or Windows 2003 Server on which SUS software has been installed.
Windows update files are first downloaded to one or more of these servers from Internet-based Microsoft servers. This layer can have sublayers of additional SUS servers that simplify the coordination of patch deployment in larger environments: SUS servers are configured to synchronize content with other SUS servers -- not Microsoft Update Internet servers -- residing higher in this hierarchy. Appropriately configured client computers obtain the updates (using Automatic Update mechanism). The system administrator designates which updates are approved for distribution throughout the enterprise.
This approach provides several benefits:
- Control over which updates will be applied to computers
- Lowered bandwidth for the Internet connection
- The ability to manage the flow of patch downloads (this might be important in a multi-site environment separated by slow WAN links)
- The ability to deploy patches to computers without direct Internet access
- A solution for environments where proxy servers require authentication for secure access to the Internet (this causes problems with Automatic Update clients)
Service Pack 1 extends the basic feature set found in SUS 1.0. From an SMB point of view, one of the most important changes is ability to install SUS software on domain controllers. The lack of this functionality in the previous edition prevented SUS from being implemented in environments using Windows 2000 and 2003 Small Business Server editions, as they operate as domain controllers. The current incarnation of SUS also supports the deployment of Windows service packs (starting with Windows 2000 SP4 and Windows XP SP1), in addition to security patches. However, it does not allow updates to any other Microsoft products, such as Office, Exchange 2000, or SQL 2000 Servers.
SUS clients can be set to send information about patch operation to an SUS statistics server. This must be a Windows server running Internet Information Server, and it can be the one running the SUS component. If a different server is to be used, copy WUtrack.bin file from the SUS Web site root folder to the statistic server Web site root folder. Patch download and installation statistics sent by clients are recorded in the IIS logs.
More information about log content analysis is found in Appendix C of the "SUS SP1 Deployment Guide," downloadable from http://www.microsoft.com/windowsserversystem/sus/susdeployment.mspx.
Alternatively, you can also employ Microsoft Baseline Security Analyzer (by launching it from the command line using the syntax MBSACLI /hf /sus "http://SUSServer") to execute a security scan against list of locally approved updates rather than against a full list of the updates contained in mssecure.xml file on the Microsoft Internet Update servers.
As mentioned before, SUS 1.0 SP1 (downloadable from http://www.microsoft.com/downloads/details.aspx?FamilyId=A7AA96E4-6E41-4F54-972C-AE66A4E4BF6C&displaylang=en must be installed on a system running Windows 2000 or 2003 Server with Internet Information Services (and Internet Explorer 5.5 or later). The setup program uses a Web site bound to Port 80 or, if none exists, creates one and binds it to Port 80. (Port 80 is required for the proper communication between the SUS server, its clients, and other servers, including Microsoft Windows Update servers.)
The setup program also creates a folder where Web site files and Windows update files downloaded from Microsoft (or another SUS server higher in hierarchy) are stored. In case of update files, you have the option to not download them and have clients install selectively approved updates directly from the Microsoft Update servers. This option might make sense for clients residing on the far side of a slow WAN link, with no local SUS server on their site, that have a fairly fast direct Internet connection.
Next, you are prompted to select language versions of patches you are interested in. Select only those relevant to your environment, as this choice affects the disk space SUS occupies. Finally, decide whether new patches are to be approved automatically or manually. The first option makes sense if the organization's only goal is to optimize bandwidth utilization of its Internet connection; the second one is preferable when the IS organization wants to control which updates should be deployed in an environment.
On completion, the wizard provides URL path of the SUS Web site for client computers to access when downloading patches (typically, this path is http://SUSServerName -- where SUSServerName is the resolvable name of the server hosting the Web site). When installing on a Windows 2000 Server platform, the setup program also installs IIS Lockdown 2.0 and URL Scanner 2.5 utilities (providing they are not already present on the target system). These utilities are then used to disable or remove a number of potentially vulnerable features, (e.g., anonymous access, WebDAV, and Sample Web site). Once the installation is complete, it automatically launches Internet Explorer and connects to the SUS Administration Web page located at http://SUSServerName/SUSAdmin.
Configuring and Administering SUS
From the SUS Administration Web page, the administrator can configure SUS components and perform two main administrative tasks -- synchronizing and approving content. Configuration involves setting the following parameters (some of which are set during installation):
- Settings available from "Set options" entry in the left pane of the SUS Administration Web page
- Proxy Server Settings for accessing Microsoft Internet Windows Update servers
- SUS Server Name is what client computers use to locate the server; it can be the NetBIOS name, the hostname, a fully qualified DNS name, or an IP address
- Synchronization Source is Microsoft Windows Update servers or another SUS server
- Approval Setting for Updates of Previously Approved Updates is set to automatic or manual
- Storage Information is saved as updates to a local folder or relies on info stored on Microsoft Windows Update servers
- Locale Selection of localized versions of patches depends on languages used within an organization
- Settings available from the "Synchronize server" entry in the left pane of the SUS Administration Web page
- Synchronization Mechanism is set to manual or scheduled
- Synchronization Schedule is enabled if the scheduled synchronization option is selected
From the administrative page, you can also synchronize the SUS server with its source (by clicking the Synchronize Now button displayed after the "Synchronize server" option is selected), approve updates (provided the manual approval method has been chosen) by selecting the "Approve updates" option and selecting a checkbox in the list of Available Updates listed in the right side of the Web page, view synchronization and approval logs, and monitor servers, which gives you information about the number of updates loaded in the server's memory cache. This also speeds up access to them.
The next article will continue our coverage of the SUS solution with a discussion of additional configuration options as well as Microsoft's short-term plans concerning this technology.