WSUS Design WSUS Release 2.0 Prepaired by: Samih Ajrouch Approved by: Rim Kadi Published by the American University of Beirut Computing and Networking Services Beirut, Lebanon 1
AUB. All rights reserved. No part of this document may be reproduced or copied in any form or by any means (graphic electronic or mechanical, including photocopying) recording taping or information retrieval systems without express written permission from the American University of Beirut. Furthermore, no part of this document may be distributed or shown to persons, or organizations other than those authorized by the American University of Beirut. The information in this document pertains to the Enabled Desktop Environment plans for the American University of Beirut and is to be treated as confidential except where officially issued by the American University of Beirut for distribution. Please direct questions or comments about this document to the assigned University representative. 2
Table of Contents TABLE OF CONTENTS... 3 1. INTRODUCTION... 5 2. TYPE OF DEPLOYMENT... 5 2.1. SIMPLE WSUS DEPLOYMENT... 5 2.2. CHAIN OF WSUS SERVERS... 6 2.3. DESIGN DECISIONS... 6 2.4. WSUS SERVERS CHAINED TOGETHER... 6 3. MANAGEMENT STYLE... 6 3.1. CENTRALIZED MANAGEMENT... 6 3.2. DISTRIBUTED MANAGEMENT... 7 3.3. DESIGN DECISIONS... 7 3.4. WSUS CENTRALIZED MANAGEMENT (REPLICA ROLE)... 8 4. STORAGE LOCATION... 8 4.1. LOCAL STORAGE... 8 4.2. REMOTE STORAGE... 9 4.3. DESIGN DECISIONS... 9 5. BANDWIDTH USAGE... 9 5.1. DEFERRING THE DOWNLOAD OF UPDATES:... 9 5.2. FILTERING UPDATES... 10 5.3. DESIGN DECISIONS... 10 6. INSTALLING WSUS... 10 6.1. SOFTWARE REQUIREMENTS... 10 6.2. PORT REQUIREMENTS... 10 6.3. DESIGN DECISIONS... 11 7. COMPUTER GROUPS... 12 7.1. DESIGN DECISIONS... 12 8. AUTOMATIC UPDATES CLIENT COMPONENT... 13 8.1. INSTALLING AUTOMATIC UPDATES CLIENT... 13 8.2. DESIGN DECISIONS... 14 8.3. CONFIGURING AUTOMATIC UPDATES CLIENT... 14 8.4. DESIGN DECISIONS... 15 9. SECURING WSUS SERVERS... 16 9.1. SECURING IIS 6.0... 16 9.2. DESIGN DECISIONS... 16 9.3. ADDING AUTHENTICATION BETWEEN CHAINED WSUS SERVERS... 17 9.4. DESIGN DECISIONS... 17 10. CONCLUSION... 17 3
4
1. Introduction Windows Server Update Services (WSUS) is the new name for the next version of Software Update Services (SUS). WSUS is a patch and update component of Windows Server and offers an effective and quick way to help systems get secure and stay secure. WSUS will support updating Windows operating systems and all Microsoft corporate software. When initially released, WSUS will support updating Windows XP Professional, Windows 2000, Windows Server 2003, Microsoft Office XP, Office 2003, Microsoft SQL Server 2000, Microsoft SQL Server 2000 Desktop Engine (MSDE) 2000, and Microsoft Exchange Server 2003. Support for additional Microsoft products will be added over time. This document is intended to describe the design decisions for deploying WSUS at AUB, the hardware and software requirements, and the phases of deployment with migration from the existing SUS solution. 2. Type of Deployment WSUS could be deployed in one of two scenarios: Simple WSUS deployment Chain of WSUS servers 2.1. Simple WSUS Deployment This type of deployment involves setting up one WSUS server inside the corporate network. This server will connect to Microsoft Update to download updates and then clients on the private network would connect to this server to download and install the list of missing updates. A new feature introduced with WSUS is the Computer Groups that enables administrators to target updates to a specific group of computers. In simple WSUS deployment, the WSUS administrator can create different computer groups, move computers to these groups and then approve updates for specific groups instead of deploying them to all the organization at once. 5
2.2. Chain of WSUS Servers The basic idea behind this type of deployment is the ability to synchronize one WSUS server with another WSUS server. This type of configuration is useful for scaling WSUS in a large organization. In such a scenario, a downstream server must always synchronize to an upstream server, where the latter synchronizes to Microsoft Update. 2.3. Design Decisions At AUB, the Chain of WSUS Servers is the chosen deployment type. This decision was taken based on the following criteria: Load distribution: Currently all computers at AUB get their updates from one SUS server. Distributing the load to other WSUS servers will decrease the load on this server. Network Traffic: One WSUS server will be located in each Active Directory Site. This way, the traffic initiated from client computers to their WSUS server will flow within the same site; thus decreasing network traffic among sites. Minimize Failure Impact: This type of deployment ensures that if one WSUS server fails, other computers in other sites can still get updated from their own WSUS server. 2.4. WSUS Servers Chained Together Figure1: Chain Together 3. Management Style WSUS supports deployments in both central and distributed management models. 3.1. Centralized Management Centrally managed WSUS servers utilize the replica server role. The replica server role features a single administered server and one or more subordinate replicas. The approvals and targeting groups created on the master server are replicated throughout the entire organization. Computer group membership is not distributed throughout the replica group, only the computer groups 6
themselves. In other words, client computers must always be loaded into the created computer groups. 3.2. Distributed Management Distributed Management offers full control over approvals and computer groups for each WSUS server. With the distributed management model, a WSUS administrator exists at each site. The administrator at each site creates his/her own computer groups and approves the list of updates required at his/her site. 3.3. Design Decisions The management style that will be followed at AUB is the Centralized Management for the following reasons: There is no site administrator: At AUB, administrators are distributed among departments rather than among sites. Thus a site could contain several system administrators. Same updates: Normally the same updates are installed on all computers at AUB. Thus there is no need that each site has its own list of approved updates. Computer Groups: There will definitely be different computer groups among different sites at AUB. However this is not a constraint in Centralized Management since computer groups required throughout the whole organization will be created on the master server. These computer groups will be replicated to all Downstream WSUS servers. For each WSUS server in a site, only the necessary computer groups will be loaded with the appropriate computer objects. Membership of computer groups is never replicated to WSUS servers, only the name of the group. 7
3.4. WSUS Centralized Management (Replica Role) Figure2: Centralized management 4. Storage Location Metadata that describes what an update is useful for is stored in the WSUS database, the updates themselves are not. There are two choices for where updates are stored: On the local WSUS server, or on Microsoft Update. 4.1. Local Storage Updates are stored locally on the WSUS server. This saves bandwidth on the internet connection because the clients download updates directly from the WSUS server. This option requires a 30GB of disk space on the WSUS server. 8
4.2. Remote Storage Updates are stored remotely on Microsoft servers. This scenario is useful if client computers have a slow WAN connection with the WSUS server and a high-bandwidth connection to the internet. 4.3. Design Decisions Local Storage will be used at AUB since: There is a large number of client computers, each one downloading updates from the internet by itself would be a burden. There is no constraint on the hard disk space that can be purchased for WSUS servers. There are no slow connection between the client computers and the WSUS server. Only one computer (the upstream master server) would require unlimited internet connection. 5. Bandwidth Usage The following features of WSUS will be used to efficiently use the bandwidth: 5.1. Deferring the Download of Updates: WSUS offers the ability to download update metadata at a different time from the update itself during synchronizations. In this configuration, approving an update triggers the download of all the files used to install that particular update on a computer. This saves bandwidth and WSUS server disk space, because only updates that are approved for installation are downloaded in full to the WSUS server. For bandwidth savings, deferring downloads is useful in conjunction with a special approval setting that only detects whether client computers require an update (approve for detection setting). With this kind of approval, the WSUS server does not download the update and clients do not install the update. Instead, clients just determine if they need the update. If they do, they send an event to the WSUS server, which is recorded in a server report. If the clients require updates that were approved for detection, the administrator can then approve them for installation. 9
5.2. Filtering Updates WSUS offers the ability to choose only the updates that the organization requires during synchronizations. Synchronizations can be limited by language, product, and type of update. In a chain of WSUS servers, WSUS automatically sets all downstream servers to use the update filtering options that are selected on the server directly connected to Microsoft Update. 5.3. Design Decisions Deferred downloads will be used at AUB to minimize internet bandwidth usage. This way only the updates approved by the administrator will be downloaded from the internet to the upstream server. However, the Approve for Detection setting will not be used because it introduces an overhead on the WSUS administrator and at AUB there is not internet bandwidth restriction. Moreover, the WSUS administrator will initially approve only the updates necessary for any computer at AUB. Updates will be filtered by language. Only English updates will be selected for download and approval. This will save internet bandwidth. 6. Installing WSUS 6.1. Software Requirements Following is a list of software that should be installed on the WSUS server prior to installing WSUS: Windows 2003 server IIS 6.0 BITS 2.0 Microsoft.NET framework Service Pack 1 for Windows 2003 Microsoft Windows SQL Server 2000 Desktop Engine (WMSDE) 6.2. Port Requirements The WSUS server uses port 80 and port 443 to obtain updates from Microsoft. This is not configurable. Thus these ports should be open between the upstream WSUS server and the internet. 10
If there are no Web sites running on the server where WSUS is installed, there is the option to use the default Web site or a custom Web site. If WSUS is setup on the default Web site, WSUS listens for Automatic Updates on port 80. If a custom Web site is used, WSUS listens on port 8530. Even if WSUS is configured on a custom website and listening to port 8530, a Web site must also be set up and running on port 80 to accommodate updating Legacy Automatic Updates client software. Downstream WSUS servers can use the custom port to synchronize with the upstream WSUS server. 6.3. Design Decisions At AUB, five WSUS servers will be installed (one in every AD site). Each server will belong to the backbone subnet dedicated to the corresponding site. Since these servers will have other roles than windows update, the hardware will be powerful and will satisfy WSUS requirements. The WSUS web site will be installed on port 8530, leaving port 80 free for probable web sites to be installed on the server. The IP address of the upstream WSUS server should be configured for unlimited internet download. All other downstream servers will be configured to retrieve updates from the upstream WSUS server on port 8530. The upstream server will be scheduled to retrieve updates from Microsoft Update at 11:00 pm. Downstream servers will synchronize to the upstream server at one hour interval from each other. In order not to download and approve again the list of updates existing on the SUS server, a migration procedure will take place to migrate the content and approvals from the existing SUS server at AUB to the new upstream WSUS server. For this process, the upstream WSUS software will be installed on the same server acting as SUS server, and then the WSUSutil.exe utility will be used to migrate the content of updates and the list of approvals. 11
Figure3: Servers distribution 7. Computer Groups Setting up computer groups is a three-step process. First, specify how the computers will be assigned to computer groups. There are two options: server-side targeting and client-side targeting. Server-side targeting involves manually adding each computer to its group. Client-side targeting involves automatically assigning the computers by using either Group Policy or registry keys. Second, create the computer groups in WSUS. Third, move the computers into groups by using the method chosen in the first step. 7.1. Design Decisions At AUB, we will configure 5 main policies linked as the follows 12
All Backbone servers group All Departmental Servers All Public Computers All Administration computers Test Group More groups will be created upon the request of the system administrators At AUB, client-side targeting will be used on all downstream servers for computers joined to AD domain. The computers will be assigned to the appropriate computer group through group policy. A WSUS computer group will be created for every high-level delegated OU, and through group policy computers in the OU will be placed in the appropriate computer group. As to computers that are not joined to win2k.aub.edu.lb domain, they will not be member of any special computer group, and thus updates could not be targeted for a special group of these computers. Moreover, testing groups will be created to allow system administrators to test updates on their machines before deploying the updates to the whole organization. Each system administrator will choose one or more computer representative of the computers in his/her department. These computers will be included in the testing computer group. Whenever new updates are downloaded, these updates will be approved only for the testing computer group. The system administrators will be given a three-day period to install and test the updates on the testing computers. If no problems were encountered by any department, the updates will then be approved to the whole organization; otherwise, special computer groups will be created for computers that encountered problems, and these computer groups will be excluded from the approved updates. WSUS computer groups for delegated OUs will follow Active Directory OUs naming convention. 8. Automatic Updates Client Component 8.1. Installing Automatic Updates Client Automatic Updates is the WSUS client software. It can be installed on any computer running: Windows 2000 (Professional and Server) with SP3 or SP4 13
Windows XP Professional with or without SP1 or SP2 Windows Server 2003 Computers running Windows XP with SP2 already have the WSUS client software installed and do not need additional installation. To minimize administrative effort, automatic updates can update itself to the WSUS compatible software. If a machine has the legacy SUS client, every time it checks for updates on the internal server, it also checks if there is an update for itself. This way the SUS client software will selfupdate to WSUS client software. The self-updating client software is available on the following operating systems (those compatible with SUS client): Windows 2000 with Service Pack 3 or Service Pack 4 Windows XP with Service Pack 1 or Service Pack 2 Windows Server 2003 8.2. Design Decisions At AUB, all clients are currently using the SUS client software and are thus eligible for selfupdate to WSUS client software (if needed). On each WSUS server to be installed, the Self- Update directory will be created under the web site running on port 80. SUS clients will look for this virtual directory at port 80 and update themselves to the new version of Automatic Updates compatible with WSUS server. 8.3. Configuring Automatic Updates Client Clients can be configured to retrieve updates from WSUS server through domain or local group policy (depending whether AD domain computers or workgroup computers) or through modifying registry keys. In addition to pointing to the WSUS server, there are automatic updates configuration settings that are manipulated using same methods. When administrative policies (whether through group policy or registry) are used to configure Automatic Updates, the Automatic Updates user interface in Control Panel is disabled on the target computer. Notifications options can be manipulated as follows: If Automatic Updates is configured to notify the user of updates that are ready to install, the notification is sent to the System log and to the notification area of the client computer. 14
When a user with appropriate credentials clicks the notification-area icon, Automatic Updates displays the available updates to install. In this case, a user with the appropriate credentials is either a logged-on administrator or a non-administrator granted appropriate credentials by means of Group Policy. The user must then click Install so the installation can proceed. A message appears if the update requires the computer to be restarted to complete the update. If a restart is requested, Automatic Updates cannot detect additional updates until the computer is restarted. If Automatic Updates is configured to install updates on a set schedule, applicable updates are downloaded and marked as ready to install. Automatic Updates notifies users having appropriate credentials via a notification-area icon, and an event is logged to the System log. This indicates that the user can install updates. At the scheduled day and time, Automatic Updates installs the update and restarts the computer (if necessary), even if there is no local administrator logged on. If a local administrator is logged on and the computer requires a restart, Automatic Updates displays a warning and a countdown for when the computer will restart. Otherwise, the installation occurs in the background. If it is required to restart the computer, and any user is logged on, a similar countdown dialog box is displayed, warning the logged-on user about the impending restart. Computer restarts can be manipulated with Group Policy. After the new updates are downloaded, Automatic Updates polls the WSUS server again for the list of approved packages to confirm that the packages it downloaded are still valid and approved. This means that if a WSUS administrator removes updates from the list of approved updates while Automatic Updates is downloading updates, only the updates that are still approved are actually installed. 8.4. Design Decisions Configuration settings of the Automatic Updates Client will be done through group policy for Active Directory Domain computers joined to win2k.aub.edu.lb and by modifying registry keys through the Provisioning Service for non Active-Directory computers. The following settings will be configured for Automatic Updates Client on client (non-server) computers (either by group policy or by modifying registry through provisioning service): Administration PCs Auto download updates and schedule install (schedule will be based on computer OU location) Specify Intranet Microsoft update service location: Http://WSUSSiteServerName:8350 15
Enable Client Side targeting: Specify the computer group that computers will belong to. Reschedule Automatic Update scheduled installations: 10 minutes No auto-restart for scheduled Automatic Update installation options: Enabled Automatic Update detection frequency: Not Configured Allow non-administrators to receive update notifications: Disabled Public Labs Auto download updates and schedule the installation (schedule will be based on computer OU location) Specify Intranet Microsoft update service location: Http://WSUSSiteServerName:8350 Enable Client Side targeting: Specify the computer group that computers will belong to. Reschedule Automatic Update scheduled installations: 10 minutes No auto-restart for scheduled Automatic Update installation options: Enabled Automatic Update detection frequency: Not Configured Allow non-administrators to receive update notifications: Disabled 9. Securing WSUS servers 9.1. Securing IIS 6.0 9.2. Design Decisions The following three security settings will be enabled on the IIS Web server to help ensure secure WSUS administration. Enable general error messages: By default, IIS gives detailed error messages to remote Web clients. Enabling IIS general (less detailed) error messages prevents an unauthorized user from probing the IIS environment with IIS error messages. Enable additional logging options: By default, IIS enables logging for a number of options. Logging will be added to the following keys: Server name Time taken Host 16
Cookie Referer Remove header extensions: By default, IIS enables header extensions for HTTP requests. It is more secure to remove any header extensions for IIS. 9.3. Adding Authentication between Chained WSUS Servers 9.4. Design Decisions Authentication will be added for server-to server synchronization. Enabling authentication is a two-step process. First, a list of downstream WSUS servers allowed to authenticate with the upstream WSUS server will be created; this list will then be added to a text file that was created when WSUS was installed. Second, in IIS, anonymous access to the WSUS server will be disabled. These two steps will enable only the downstream computers listed to synchronize with the upstream WSUS server. 10. Conclusion This document described the design of WSUS at AUB. In summary, a separate WSUS server will be installed in every Active Directory site serving clients in the subnets belonging to that site. Domain computers will be pointed to their appropriate WSUS server through group policy, while non-domain computers will point to the appropriate WSUS server through changing the registry keys from a script. System administrators in each department will be allowed a three days period to test approved updates on sample machines before deploying updates throughout the whole organization. To prevent configuration and updates loss in case of a failure, it is recommended that the WSUS database and configuration be backed up frequently. This should be included in the design of the backup and disaster recovery strategy being studied for AUB servers. 17