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
AUBede: WSUS Design
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
AUBede: WSUS Design
Table of Contents
TABLE OF CONTENTS.............................................................................................................................................. 3
1.
INTRODUCTION ............................................................................................................................................ 5
2.
TYPE OF DEPLOYMENT.................................................................................................................................. 5
2.1.
2.2.
2.3.
2.4.
3.
SIMPLE WSUS DEPLOYMENT ............................................................................................................................5
CHAIN OF WSUS SERVERS ................................................................................................................................6
DESIGN DECISIONS...........................................................................................................................................6
WSUS SERVERS CHAINED TOGETHER ..................................................................................................................6
MANAGEMENT STYLE ................................................................................................................................... 6
3.1.
3.2.
3.3.
3.4.
4.
CENTRALIZED MANAGEMENT .............................................................................................................................6
DISTRIBUTED MANAGEMENT .............................................................................................................................7
DESIGN DECISIONS...........................................................................................................................................7
WSUS CENTRALIZED MANAGEMENT (REPLICA ROLE) ............................................................................................8
STORAGE LOCATION ..................................................................................................................................... 8
4.1.
4.2.
4.3.
5.
LOCAL STORAGE ..............................................................................................................................................8
REMOTE STORAGE ...........................................................................................................................................9
DESIGN DECISIONS...........................................................................................................................................9
BANDWIDTH USAGE ..................................................................................................................................... 9
5.1.
5.2.
5.3.
6.
DEFERRING THE DOWNLOAD OF UPDATES: ...........................................................................................................9
FILTERING UPDATES .......................................................................................................................................10
DESIGN DECISIONS.........................................................................................................................................10
INSTALLING WSUS ...................................................................................................................................... 10
6.1.
6.2.
6.3.
7.
SOFTWARE REQUIREMENTS .............................................................................................................................10
PORT REQUIREMENTS ....................................................................................................................................10
DESIGN DECISIONS.........................................................................................................................................11
COMPUTER GROUPS ................................................................................................................................... 12
7.1.
8.
DESIGN DECISIONS.........................................................................................................................................12
AUTOMATIC UPDATES CLIENT COMPONENT .............................................................................................. 13
8.1.
8.2.
8.3.
8.4.
9.
INSTALLING AUTOMATIC UPDATES CLIENT ..........................................................................................................13
DESIGN DECISIONS.........................................................................................................................................14
CONFIGURING AUTOMATIC UPDATES CLIENT ......................................................................................................14
DESIGN DECISIONS.........................................................................................................................................15
SECURING WSUS SERVERS .......................................................................................................................... 16
9.1.
9.2.
9.3.
9.4.
10.
SECURING IIS 6.0 ..........................................................................................................................................16
DESIGN DECISIONS.........................................................................................................................................16
ADDING AUTHENTICATION BETWEEN CHAINED WSUS SERVERS .............................................................................17
DESIGN DECISIONS.........................................................................................................................................17
CONCLUSION .............................................................................................................................................. 17
3
AUBede: WSUS Design
4
AUBede: WSUS Design
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
AUBede: WSUS Design
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
AUBede: WSUS Design
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
AUBede: WSUS Design
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
AUBede: WSUS Design
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
AUBede: WSUS Design
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
AUBede: WSUS Design

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
AUBede: WSUS Design
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
AUBede: WSUS Design

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
AUBede: WSUS Design

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 SelfUpdate 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
AUBede: WSUS Design

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
AUBede: WSUS Design

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
AUBede: WSUS Design

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
AUBede: WSUS Design