Once upon a time, you could use do-it-yourself, spit-and-glue solutions to keep your systems patched. But malware now spreads so quickly that you can't rely on your users visiting Microsoft's Windows Update Web site to maintain an adequate level of security in your enterprise. On June 14, 2005, Microsoft released 10 security bulletins as part of its monthly patch update. Three of the vulnerabilities were rated critical, and analysts predicted that malware exploiting those weaknesses would appear within a week. Fortunately, just a few days earlier Microsoft had rolled out the first components of its new update infrastructure, including its robust, reliable patch management solution, Windows Server Update Services (WSUS).
In addition to Windows updates and security patches, WSUS lets you deploy drivers, tools, service packs, feature packs, Microsoft Office 2003, Windows XP, Microsoft SQL Server, and Microsoft Exchange Server. But before deploying WSUS in an enterprise, you need to plan for it by making decisions on key deployment considerations and choosing an appropriate topology. I explain the steps in designing an enterprise WSUS deployment, but I don't go into the details of installing WSUS; Douglas Toombs covers that topic thoroughly in "Let WSUS Ease Your Patch-Deployment Hassles," June 2005, InstantDoc ID 46171.
The Microsoft document Deploying Microsoft Windows Server Update Services, which you can download from Microsoft's WSUS Web site (http://www.microsoft.com/windowsserversystem/updateservices), offers key design considerations. First, you need to formulate your update plan, including strategy, objectives, resources, and procedures. Then, you need to select a database engine for WSUS, determine the best locations for your WSUS servers, decide which update files to obtain and where to store them, and develop a client-group targeting strategy. After you complete these tasks, you can design a WSUS topology.
STEP 1: Formulate Your Update Plan
Before doing anything else, you need to ensure that your team and organization agree about the need for update management, the objectives you want to achieve, and how WSUS meets those goals. WSUS supports a range of updates for key Microsoft platforms and applications and can manage patching on Windows 2000 and later clients. Although WSUS supports updates for third-party products, currently no third-party vendors are taking advantage of its capabilities, so you need to decide what tools to use to update technologies and products that WSUS can't yet handle.
You also need to determine the kinds of updates you want WSUS to deploy (e.g., security updates, feature packs, drivers, rollups, service packs) and the process you'll use to identify, evaluate, test, deploy, and troubleshoot or uninstall updates if necessary. Consider your requirements for compliance reports and determine whether WSUS's reporting capabilities meet your needs. Finally, identify who will perform the procedures necessary to support update services.
STEP 2: Select a Database Engine
WSUS downloads updates from Microsoft Update. Updates consist of the update file, which is distributed to clients for installation, and metadata, which includes the update's name, release date, revision number, affected products, and reboot requirements. The metadata downloads to a database that's dedicated to the WSUS server and also stores WSUS configuration settings. As clients poll WSUS, the server adds basic inventory information to the database. Update status is also stored in the database.
Each WSUS server requires a unique database instance. The database can be one of the following:
- Microsoft SQL Server 2000 Desktop Engine (MSDE) with Service Pack 4 (SP4) on a WSUS server running Windows Server 2003 or Win2K SP4.
- Windows MSDE (WMSDE) on a WSUS server running Windows 2003. WMSDE, which comes with WSUS, is a special, improved version of MSDE and an effective solution for many WSUS implementations.
- SQL Server 2005 or SQL Server 2000 SP4 on a WSUS server or back-end server. SQL Server's nested triggers option must be enabled, and the SQL Server instance must use Windows Authentication. WSUS can store its data in a SQL Server instance on another system; see the WSUS documentation for details.
The best database for your update server depends on your hardware platform, the number of clients the server supports, and your tolerance for license fees. Each WSUS server requires a unique instance of SQL Server, MSDE, or WMSDE; a remote centralized SQL Server system can't support multiple WSUS servers. I suggest you start with WMSDE on Windows 2003 and monitor performance.
STEP 3: Determine Locations for WSUS Servers
WSUS can run on Windows 2003 or Win2K Server SP4, including Small Business Server (SBS) 2003. WSUS can't run on 64-bit Windows 2003 platforms. Such systems can receive updates from WSUS but can't provide update services to other clients. Microsoft recommends Windows 2003 over Win2K Server SP4 because Windows 2003 has a more secure code base and WMSDE availability.
WSUS also requires Windows .NET Framework 1.1 with SP1, Background Intelligent Transfer Service (BITS) 2.0, Windows HTTP Services (Win-HTTP) 5.1, Microsoft Internet Information Services (IIS) 6.0 (for Windows 2003) or IIS 5.0 with IIS Lockdown (for Win2K Server), Microsoft Internet Explorer (IE) 6.0 with SP1, and a local database engine (unless you're running a remote SQL Server configuration). These software requirements might determine your choice of server, because they might affect previously installed services or applications on an existing server.
You need to install WSUS on a member server rather than a domain controller (DC). Running WSUS on a DC might be adequate for a small company or branch office, but doing so has performance and security implications for all enterprises. If you choose to install WSUS on a Win2K DC, read the documentation for specific Win2K DC problems. You can also install WSUS on SBS, but you need to read the documentation to prevent conflicts between WSUS, Companyweb, and Windows SharePoint Services. Installing WSUS on a member server is the best option.
To administer WSUS and manage updates, your security token must include the local Administrators group. Because you can't delegate WSUS or update administration without delegating administration on the entire server, you need to install WSUS on a dedicated server.
For optimal performance, place WSUS servers where they can best use the company's bandwidth. A WSUS server must download update metadata and, usually, the update files from Microsoft Update or an upstream WSUS server (as I discuss later). Because every client that's directed to a WSUS server polls and, typically, downloads update files from the server, a common configuration is to place WSUS servers in locations that are separated by slow links. You also need to consider the number of users to direct to each WSUS server and monitor the server for performance bottlenecks.