You are on page 1of 145

Deploying Microsoft Windows Server

Update Services
Microsoft Corporation

Published: June 3, 2005

Author: Tim Elhajj

Editor: Sean Bentley

Abstract
This paper describes how to deploy Microsoft® Windows Server™ Update Services
(WSUS). You will find a comprehensive description of how WSUS functions, as well as
descriptions of WSUS scalability and bandwidth management features. This paper also
offers step-by-step procedures for installation and configuration of the WSUS server. You
will read how to update and configure Automatic Updates on client workstations and
servers that will be updated by WSUS. Also included are steps for migrating from
Microsoft Software Update Services (SUS) to WSUS, as well as steps for setting up a
WSUS server on an isolated segment of your network and manually importing updates.
The information contained in this document represents the current view of Microsoft
Corporation on the issues discussed as of the date of publication. Because Microsoft
must respond to changing market conditions, it should not be interpreted to be a
commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any
information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO


WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN
THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without
limiting the rights under copyright, no part of this document may be reproduced, stored in
or introduced into a retrieval system, or transmitted in any form or by any means
(electronic, mechanical, photocopying, recording, or otherwise), or for any purpose,
without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other


intellectual property rights covering subject matter in this document. Except as expressly
provided in any written license agreement from Microsoft, the furnishing of this document
does not give you any license to these patents, trademarks, copyrights, or other
intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain


names, e-mail addresses, logos, people, places, and events depicted herein are
fictitious, and no association with any real company, organization, product, domain name,
e-mail address, logo, person, place, or event is intended or should be inferred.

© 2005 Microsoft Corporation. All rights reserved.

Microsoft, SQL Server, Windows, and Windows Server are either registered trademarks
or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks
of their respective owners.
Contents
Deploying Microsoft Windows Server Update Services.....................................................1
Abstract.......................................................................................................................1

Contents.............................................................................................................................5

Deploying Microsoft Windows Server Update Services .........................................8

Introduction to Deploying Windows Server Update Services ................................8

Design the WSUS Deployment .............................................................................9


Choose a Type of Deployment ...........................................................................9
Simple WSUS Deployment........................................................................................10
Chain of WSUS Servers............................................................................................12
Networks Disconnected from the Internet..................................................................13
Choose a Management Style ...........................................................................14
Centralized Management..........................................................................................14
Distributed Management...........................................................................................16
Choose the Database Used for WSUS ............................................................16
Selecting a Database................................................................................................17
Database Authentication, Instance, and Database Name.........................................18
Determine Where to Store Updates .................................................................18
Local Storage............................................................................................................19
Remote Storage........................................................................................................19
Determine Bandwidth Options to Use for Your Deployment .............................21
Deferring the Download of Updates...........................................................................21
Filtering Updates.......................................................................................................22
Using Express Installation Files.................................................................................23
Background Intelligent Transfer Service....................................................................24
Determine Capacity Requirements ..................................................................25

Install the WSUS Server ......................................................................................25


Configure the Firewall Between the WSUS Server and the Internet ................26
Prepare Disks and Partitions ............................................................................27
Install Required Software .................................................................................28
Windows Server 2003...............................................................................................28
Windows 2000 Server...............................................................................................28
Install and Configure IIS ...................................................................................29
IIS Lockdown Tool.....................................................................................................29
Client Self-Update.....................................................................................................31
Using the WSUS Custom Web Site...........................................................................31
Run WSUS Server Setup .................................................................................32

Configure the WSUS Server ...............................................................................37


Access the WSUS Administration Console ......................................................38
Configure WSUS to Use a Proxy Server ..........................................................38
Select Products and Classifications .................................................................39
Synchronize the WSUS Server ........................................................................40
Configure Advanced Synchronization Options .................................................40
Update Storage Options............................................................................................40
Deferred Downloads Options....................................................................................41
Express Installation Files Options..............................................................................41
Filtering Updates Options..........................................................................................42
Chain WSUS Servers Together ........................................................................43
Create a Replica Group ...................................................................................43
Create Computer Groups for Computers .........................................................44
Setting up Computer Groups.....................................................................................44
Approve Updates .............................................................................................46
Verify Update Deployment ...............................................................................47
Secure Your WSUS Deployment ......................................................................47
Hardening your Windows Server 2003 running WSUS.............................................47
Adding Authentication Between Chained WSUS Servers in an Active Directory
Environment...........................................................................................................48
Securing WSUS with Secure Sockets Layer.............................................................49

Update and Configure the Automatic Updates Client Component .......................54


Client Component Requirements .....................................................................54
Update Automatic Updates ..............................................................................55
Automatic Updates Client Self-Update Feature.........................................................55
Determine a Method to Configure Automatic Updates Clients .........................56
Configure Automatic Updates by Using Group Policy ...................................58
Configure Automatic Updates in a Non–Active Directory Environment .........65
Manipulate Automatic Updates Behavior Using Command-line Options ..........71
Detectnow Option......................................................................................................71
Resetauthorization Option.........................................................................................71

Set Up a Disconnected Network (Import and Export Updates) ...........................71


Step 2 Import and Export: Copying Updates from File System ........................73
Step 1 Import and Export: Matching Advanced Options ...................................74
Step 3 Import and Export: Copying Metadata from Database ..........................75
Migrate from a SUS Server to a WSUS Server ...................................................76
Migration Command-line Tool ..........................................................................77
Two Migration Scenarios ..................................................................................78
Same-server Migration .................................................................................79
Remote Server Migration ..............................................................................83

Appendix A: Unattended Installation ....................................................................87

Appendix B: Install MSDE on Windows 2000 ......................................................91


Step 1: Download and Expand the MSDE Archive.......................................................92
Step 2: Install MSDE.....................................................................................................93
Step 3: Update MSDE...................................................................................................94

Appendix C: Remote SQL ...................................................................................96


Remote SQL Limitations...............................................................................................96
Database Requirements...............................................................................................96
Step 1: Install WSUS on the Front-end Computer........................................................97
Step 2: Install WSUS on the Back-end Computer.......................................................100
Set Permissions on Windows Server 2003..............................................................105
Set Permissions on Windows 2000 Server..............................................................108
Step 3: Configure the Front-end Computer to Use the Back-end Computer...............110

Appendix D: Security Settings ...........................................................................111


Windows Server 2003.................................................................................................111
Audit Policy..............................................................................................................111
Security Options......................................................................................................113
Event Log Settings..................................................................................................125
System Services......................................................................................................126
TCP/IP Hardening...................................................................................................133
IIS 6.0 Security Settings..............................................................................................134
URLScan.................................................................................................................134
IIS Security Configuration........................................................................................136
SQL Server 2000........................................................................................................137
SQL Registry Permissions.......................................................................................137
Stored Procedures...................................................................................................138
Urlscan.ini file.............................................................................................................140
Deploying Microsoft Windows Server Update Services 8

Deploying Microsoft Windows Server


Update Services
This guide describes how to deploy Microsoft® Windows Server™ Update Services
(WSUS). You will find a comprehensive description of how WSUS functions, as well as
descriptions of WSUS scalability and bandwidth management features. This guide also
offers step-by-step procedures for installation and configuration of the WSUS server. You
will read how to update and configure Automatic Updates on client workstations and
servers that will be updated by WSUS. Also included are steps for migrating from
Microsoft Software Update Services (SUS) to WSUS, as well as steps for setting up a
WSUS server on an isolated segment of your network and manually importing updates.

In this guide

• Introduction to Deploying Windows Server Update Services

• Design the WSUS Deployment

• Install the WSUS Server

• Configure the WSUS Server

• Update and Configure the Automatic Updates Client Component

• Set Up a Disconnected Network (Import and Export Updates)

• Migrate from a SUS Server to a WSUS Server

• Appendix A: Unattended Installation

• Appendix B: Install MSDE on Windows 2000

• Appendix C: Remote SQL

• Appendix D: Security Settings

Introduction to Deploying Windows


Server Update Services
This guide describes how to deploy Microsoft Windows Server Update Services (WSUS).
Begin your WSUS deployment by reading about how WSUS functions, its general
requirements, and its features for scalability and bandwidth management. First, read
Deploying Microsoft Windows Server Update Services 9

Design the WSUS Deployment. Next, read how to install and configure the WSUS server
in the section, Install the WSUS Server.Then read how to configure Automatic Updates
on client workstations and servers that will be updated by WSUS in Update and
Configure the Automatic Updates Client Component.

There are companion papers to this guide that offer other types of information about
WSUS. For an overview of WSUS features, read "Microsoft Windows Server Update
Services Overview." For information about administering WSUS or troubleshooting
problems with WSUS, read "Windows Server Update Services Operations Guide." The
latest versions of these documents are available on the Microsoft Web site for Windows
Server Update Services at http://go.microsoft.com/fwlink/?LinkId=47374.

Design the WSUS Deployment


The first step in deploying WSUS is to design the server deployment. The following
sections describe various aspects of the WSUS server deployments—from a simple
single-server deployment to multiple WSUS server deployments. Considerations for
bandwidth management are discussed, along with guidance for capacity planning.

In this guide

• Choose a Type of Deployment

• Choose a Management Style

• Choose the Database Used for WSUS

• Determine Where to Store Updates

• Determine Bandwidth Options to Use for Your Deployment

• Determine Capacity Requirements

Choose a Type of Deployment


This section describes basic building blocks for all WSUS deployments. Use this section
to familiarize yourself with simple deployments, which involve deployments with a single
WSUS server. This section also describes the function of computer groups, which
involves targeting updates to different groups of computers you create, and also
describes more complex scenarios, such as "chaining" multiple WSUS servers together
or setting up a WSUS server on an isolated network segment.
Deploying Microsoft Windows Server Update Services 10

Simple WSUS Deployment


The most basic deployment of WSUS involves setting up a server inside the corporate
firewall to serve client computers on a private intranet, as shown in the "Simple WSUS
Deployment" illustration below. The WSUS server connects to Microsoft Update to
download updates. This is known as synchronization. During synchronization, WSUS
determines if any new updates have been made available since the last time you
synchronized. If it is your first time synchronizing WSUS, all updates are made available
for approval.

The WSUS server uses port 80 and port 443 to obtain updates from Microsoft. This is not
configurable. If there is a corporate firewall between your network and the Internet,
remember you might have to open port 80 for HTTP protocol and port 443 for HTTPS
protocol.

Although the connection between Microsoft Update and WSUS requires port 80 and
port 443 to be open, you can configure multiple WSUS servers to synchronize with a
parent WSUS server by using a custom port. Chaining WSUS servers together and
configuring a custom port for WSUS are both discussed later in this guide.

Simple WSUS Deployment

Automatic Updates is the client component of WSUS. Automatic Updates must use the
port assigned to the WSUS Web site in Microsoft Internet Information Services (IIS). If
there are no Web sites running on the server where you install WSUS, you have an
option to use the default Web site or a custom Web site. If you set up WSUS on the
default Web site, WSUS listens for Automatic Updates on port 80. If you use a custom
Web site, WSUS listens on port 8530.

If you use the custom Web site, you must also have a Web site set up and running on
port 80 to accommodate updating legacy Automatic Updates client software. If you use
the custom Web site, also remember to include the port number in the URL when you
configure Automatic Updates to point to the WSUS server. Other issues to consider when
using a custom port for the WSUS Web site are discussed in "Using the WSUS custom
Web site," in Install and Configure IIS later in this guide.
Deploying Microsoft Windows Server Update Services 11

Using Computer Groups


Computer groups are an important part of WSUS deployments, even a basic deployment.
Computer groups enable you to target updates to specific computers. There are two
default computer groups: All Computers and Unassigned Computers. By default, when
each client computer initially contacts the WSUS server, the server adds it to both these
groups.

Simple WSUS Deployment with Computer Groups

You can move computers from the Unassigned Computers group to a group you create.
You cannot remove computers from the All Computers group. The All Computers group
enables you to quickly target updates to every computer on your network, regardless of
group membership. The Unassigned Computers group permits you to target only
computers that have not yet been assigned group membership.

One benefit of creating computer groups is that it enables you to test updates. The
Simple WSUS Deployment with Computer Groups illustration depicts two custom groups
named Test group and Accounting group, as well as the All Computers group. The Test
group contains a small number of computers representative of all the computers
contained in the Accounting group. Updates are approved first for the Test group. If the
testing goes well, you can roll out the updates to the Accounting group. There is no limit
to the number of custom groups you can create. There are instructions for creating
custom computer groups in Create Computer Groups for Computers later in this guide.
Deploying Microsoft Windows Server Update Services 12

Note:
Do not use WSUS to distribute updates to client computers that are not licensed
for your organization. The WSUS license agreement specifically disallows this.

Chain of WSUS Servers


In contrast to simple WSUS deployments, you can also create more complicated
multiple-server WSUS deployments. The basic building block for this type of deployment
is the ability to synchronize one WSUS server with another WSUS server, instead of with
Microsoft Update. When you chain WSUS servers together, there is an upstream WSUS
server and a downstream WSUS server, as shown in the "WSUS Servers Chained
Together" illustration below. When configured this way, WSUS shares only updates and
metadata with its downstream servers during synchronization—not computer group
information or information about which updates are approved. If you want to set up
WSUS to distribute information about which updates are approved, look into using replica
mode, described in Choose a Management Style.

WSUS Servers Chained Together

This type of configuration is useful for many types of deployments. You might use it to
download updates once from the Internet and then distribute those updates to branch
offices having downstream servers, saving bandwidth on your Internet connection. You
might use it to scale WSUS in a large organization with more client computers than one
WSUS server can service. You might also use it to move updates closer to the edge of
your network, where they will be deployed.

When deploying WSUS servers in such a hierarchical architecture, three levels is the
recommended limit. This is because each level adds additional lag time to propagate
updates throughout the chain. Theoretically there is no limit to how deep you can go, but
only deployments with a hierarchy five levels deep have been tested.

The downstream server must always synchronize to an upstream server. For example, in
the "WSUS Servers Chained Together" illustration above, Server B synchronizes from
Server A. This keeps synchronizations traveling downstream. If you attempt to
synchronize an upstream server to a downstream server, you effectively create a closed
loop, which is not supported. You can find step-by-step instructions for synchronizing
WSUS servers in Chain WSUS Servers Together later in this guide.
Deploying Microsoft Windows Server Update Services 13

If you do use multiple WSUS servers chained together, we recommend the following
technique to prevent propagating updates with changes that break the protocol for
server-to-server communication.

WSUS administrators should point Automatic Updates on all WSUS servers to the
deepest downstream WSUS server in the hierarchy. This shields the entire chain from
server-to-server protocol-breaking changes, because the downstream WSUS server can
be used to update the broken upstream WSUS servers via Automatic Updates.

Networks Disconnected from the Internet


It is unnecessary for your entire network to be connected to the Internet in order for you
to deploy WSUS. If you have a network segment that is not connected to the Internet,
consider deploying WSUS as shown in the "Distributing Updates on an Isolated
Segment" illustration below. In this example, you create a WSUS server that is connected
to the Internet but isolated from the intranet. After you download updates to this server,
you can hand-carry media to disconnected servers running WSUS, by exporting and
importing updates.

Distributing Updates on an Isolated Segment

Exporting and importing is also appropriate for organizations that have high-cost or low-
bandwidth links to the Internet. Even with all the bandwidth-saving options described later
in this guide downloading enough updates for all Microsoft products throughout an
organization can be bandwidth-intensive. Importing and exporting updates enables
organizations to download updates once and distribute by using inexpensive media. See
Set Up a Disconnected Network (Import and Export Updates) for more information about
how to export and import updates.
Deploying Microsoft Windows Server Update Services 14

Choose a Management Style


WSUS supports deployments in both central and distributed management models. These
management models enable you to manage your update distribution solution in whatever
way makes the most sense for your organization. The following sections feature the same
organization, using both management models to stress the differences between the two.
You do not have to use a single management model throughout your organization. It is
perfectly acceptable for a single organization to have a centrally managed WSUS
deployment serving some computers, and one or more independently managed WSUS
deployments serving other computers.

Note:
You cannot import updates to a server that is being centrally managed. WSUS
servers on disconnected networks are always autonomously managed.

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, as depicted
in the "WSUS Centralized Management (Replica Role)" illustration below. The approvals
and targeting groups you create on the master server are replicated throughout the entire
organization. Remember that computer group membership is not distributed throughout
the replica group, only the computer groups themselves. In other words, you always have
to load client computers into computer groups.
Deploying Microsoft Windows Server Update Services 15

WSUS Centralized Management (Replica Role)

It is possible that not all the sites in your organization require the same computer groups.
The important thing is to create enough computer groups on the administered server to
satisfy the needs of the rest of the organization. Computers at different sites can be
moved into a group appropriate for the site. Meanwhile, computer groups inappropriate
for a particular site simply remain empty. All update approvals, like computer groups,
must be created on the master server. You can only add WSUS servers to replica groups
during setup. For step-by-step instructions, see Create a Replica Group later in this
guide.

Note:
If you change language options, Microsoft recommends that you manually
synchronize them between the centrally managed WSUS server and its replica
servers. This avoids a situation where changing language options on the centrally
managed server alone might result in the number of updates that are approved
on it not matching the number approved on the replica servers.
Deploying Microsoft Windows Server Update Services 16

Distributed Management
Distributed management offers you full control over approvals and computer groups for
the WSUS server, as shown in the "WSUS Distributed Management" illustration below.
With the distributed management model, you typically have an administrator at each site.
Distributed management is the default installation option for all WSUS installations. You
do not have to do anything to enable this mode.

WSUS Distributed Management

Choose the Database Used for WSUS


You do not need to be a database administrator or purchase database software to use
WSUS. No matter which version of Windows you install WSUS on, there is a free version
of Microsoft® SQL Server™ available. These free versions of SQL Server were designed
to require very little management by the WSUS administrator. Of course, if you want
more control over the database, you can also use the full version of SQL Server with
WSUS.

The WSUS database stores the following types of information:


Deploying Microsoft Windows Server Update Services 17

• WSUS server configuration information

• Metadata that describes what each update is useful for

• Information about client computers, updates, and client interaction with updates

Managing WSUS by accessing data directly in the database is not supported. You should
not attempt to manage WSUS in this way. Manage WSUS manually, by using the WSUS
console, or programmatically by calling WSUS APIs.

Each WSUS server requires its own database. If there are multiple WSUS servers in your
environment, you must have multiple WSUS databases. WSUS does not support multiple
WSUS databases on a single computer running SQL Server.

Selecting a Database
Use the following information to determine what database software is right for your
organization. Once you have made a selection, see if there are any additional tasks you
need to complete to set up the database software to work with WSUS. You can use
database software that is 100-percent compatible with Microsoft SQL. There are three
options that have been tested extensively for use with WSUS:

• Microsoft Windows SQL Server 2000 Desktop Engine (WMSDE) ships with
WSUS. It is available only if you install WSUS on a computer running
Windows Server 2003. It is similar to the next option, SQL Server 2000 Desktop
Engine (MSDE), but without limitations for database size or connections. Neither
WMSDE nor MSDE have a user interface or tools. Administrators are meant to
interact with these products through WSUS.

• Microsoft SQL Server 2000 Desktop Engine (MSDE) is available from


Microsoft as a free download. It is based on SQL Server 2000, but has some built-in
limitations that restrict performance and database size to 2 GB. Use MSDE if you are
installing WSUS on a computer running Windows 2000. See Appendix B: Install
MSDE on Windows 2000 for step-by-step instructions on installing MSDE.

• Microsoft SQL Server 2000 is the full-featured database software from


Microsoft. WSUS requires SQL Server 2000 with Service Pack 3a. If you use the full
version of SQL Server, the SQL Server administrator should enable the nested
triggers option in SQL Server. Do this before the WSUS administrator installs WSUS
and specifies the database during the setup process. WSUS Setup enables the
recursive triggers option, which is a database-specific option; however, it does not
enable the nested triggers option, which is a server global option.

WSUS does support running database software on a computer separate from WSUS, but
there are some restrictions. See Appendix C: Remote SQL for more information.
Deploying Microsoft Windows Server Update Services 18

Database Software Recommendations by Operating System

Operating System Recommendation

Windows Server 2003 If you are installing WSUS on


Windows Server 2003 and do not want to
use SQL Server 2000, WMSDE is the
recommended database software option.

Windows 2000 Server If you are installing WSUS on


Windows 2000 and do not want to use SQL
Server 2000, MSDE is the recommended
database software option.

Database Authentication, Instance, and Database Name


Regardless of which database software you use, you cannot use SQL authentication.
WSUS only supports Windows authentication. If you choose WMSDE for the WSUS
database, WSUS Setup creates an instance of SQL Server named server\WSUS, where
server is the actual name of the computer. With either database option, WSUS Setup
creates a database named SUSDB.

Determine Where to Store Updates


Although metadata that describes what an update is useful for is stored in the WSUS
database, the updates themselves are not. Think of updates as being logically divided
into two parts: a metadata part that describes what the update is useful for, and the files
required to install the update on a computer. Metadata includes end-user license
agreements (EULAs) and is typically much smaller than the size of the actual update.
Update storage is described in this section.

You have two choices for where updates are stored. You can store updates on the local
WSUS server or you can store updates on Microsoft Update. The result for either option
is outlined in the following sections. If you have multiple WSUS servers chained together,
each WSUS server in the chain must use the same update storage option. These options
are selected during the setup process, but can also be changed after installing WSUS.
See Configure Advanced Synchronization Options for step-by-step procedures.
Deploying Microsoft Windows Server Update Services 19

Local Storage
You can store update files locally on the WSUS server. This saves bandwidth on your
Internet connection because client computers download updates directly from the WSUS
server. This option requires enough disk space to store the updates you intend to
download. There is a minimum requirement of 6 GB of hard disk space to store updates
locally, but 30 GB is recommended. Local storage is the default option.

Note:
The 30 GB recommendation is only an estimate based on a number of variables,
such as the number of updates released by Microsoft for any given product, and
how many products a WSUS administrator selects. Although 30 GB should work
for most customers, a worst-case scenario might require more than 30 GB of disk
space. If that should happen, "Windows Server Update Services Operations
Guide" offers guidance on how to recover. "Windows Server Update Services
Operations Guide" is available on the Microsoft Web site for Windows Server
Update Services at http://go.microsoft.com/fwlink/?LinkId=47374.

Remote Storage
If you want, you can store update files remotely on Microsoft servers. WSUS enables you
to take advantage of Microsoft Update for the distribution of approved updates throughout
your organization. This is particularly useful if most of the client computers connect to the
WSUS server over a slow WAN connection, but have high-bandwidth connections to the
Internet, or if you have only a small number of client computers, as shown in the following
illustration.
Deploying Microsoft Windows Server Update Services 20

Clients Downloading Approved Updates from Microsoft Update

In the scenario in the Clients Downloading Approved Updates from Microsoft Update
illustration, you configure WSUS so that client computers download updates from
Microsoft Update. When you synchronize the WSUS server with Microsoft Update, you
get only update metadata, which describes each of the available updates. In this
configuration, the files that install updates on client computers are never downloaded and
stored on WSUS.

You still approve updates to client computers on your network as usual, but when it
comes time for clients to obtain the actual update, each client connects to the Internet to
download it from Microsoft servers. These are the same servers Microsoft uses to
distribute updates to the public. Although your clients obtain updates from Microsoft over
the Internet, you still make the decisions about which updates are approved for
distribution. The benefit of this scenario is that the distributed clients do not have to use
the slow WAN connection to download updates, because WSUS only distributes
approvals over the WAN link.
Deploying Microsoft Windows Server Update Services 21

Determine Bandwidth Options to Use for Your


Deployment
No matter the amount of network bandwidth available, WSUS offers features that allow
you to shape the deployment to best fit your organization's needs. The decisions you
make about how to synchronize with Microsoft Update have a dramatic effect on the
efficient use of bandwidth. Use the following sections to understand WSUS features for
managing bandwidth.

Deferring the Download of Updates


WSUS offers you 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 you approve
for installation are downloaded in full to the WSUS server. You can test the files prior to
deploying them on your network, and your client computers download the updates from
the intranet. Microsoft recommends deferring the download of updates, since it makes
optimal use of network bandwidth.

Deferred Downloads of Updates

If you have a chain of WSUS servers, it is recommended that you do not chain them too
deeply, for the following reasons:

• In a chain of WSUS servers, WSUS automatically sets all downstream servers to


use the deferred download option that is selected on the server directly connected to
Microsoft Update. You cannot change this configuration. The entire chain of WSUS
servers must either defer the download of updates or download both metadata and
updates during synchronizations.

• If you have deferred downloads enabled and a downstream server requests an


update that has not been approved on the upstream server, the downstream server’s
request triggers a download on the upstream server. The downstream server then
downloads the content on a subsequent synchronization, as shown in the "Deferred
Downloads Using Multiple WSUS Servers" illustration. If you have a deep hierarchy
Deploying Microsoft Windows Server Update Services 22

of WSUS servers using deferred downloads, there is greater potential for delay as
content is requested, downloaded, and then passed down the chain.

Deferred Downloads Using Multiple WSUS Servers

For bandwidth savings, deferring downloads is particularly useful in conjunction with a


special approval setting that only detects whether client computers require an update.
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 you see
that your clients require updates that were approved for detection, you can then approve
them for installation.

This combination of deferring downloads and detection approvals allows an administrator


to download only the updates required by the client computers that are connected to the
WSUS server. WSUS allows you to automate this scenario by creating a rule on the
WSUS server that automatically approves all new updates for detection. For more
information about different types of approvals and creating automatic approval rules, see
“Windows Server Update Services Operations Guide” on the Microsoft Beta Web site for
Windows Server Update Services at http://go.microsoft.com/fwlink/?LinkId=3626.

If you chose to store updates locally during the WSUS setup process, deferred
downloads are enabled by default. You can change this option manually. See Configure
Advanced Synchronization Options for step-by-step procedures.

Filtering Updates
WSUS offers you the ability to choose only the updates your organization requires during
synchronizations. You can limit synchronizations 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. In other words, you can only set a filter for updates on the upstream server. You
Deploying Microsoft Windows Server Update Services 23

cannot change this configuration. The entire chain of WSUS servers must all use the
same update filters.

Although you cannot change the filters on downstream servers, you can defer the
download of updates to get a subset of language, product, or types of updates on a
downstream server. Deferring downloads is described in Deferring the Download of
Updates.

By default WSUS downloads Critical and Security Updates for all Windows products in
every language. Microsoft recommends that you limit languages to only those you need,
to conserve bandwidth and disk space. To change language options, see Configure
Advanced Synchronization Options. To change product and update classification options,
see Select Products and Classifications.

Using Express Installation Files


The express installation files feature is an update distribution mechanism. You can use
express installation files to limit the bandwidth consumed on your local network, but at the
cost of bandwidth consumption on your Internet connection. By default, WSUS does not
use express installation files. To better understand the tradeoff, you first have to
understand how WSUS updates client computers.

Updates typically consist of new versions of files that already exist on the computer being
updated. On a binary level these existing files might not differ very much from updated
versions. The express installation files feature is a way of identifying the exact bytes that
change between different versions of files, creating and distributing updates that include
just these differences, and then merging the original file with the update on the client
computer. Sometimes this is called delta delivery because it downloads only the
difference, or delta, between two versions of a file.

When you distribute updates by using this method, it requires an initial investment in
bandwidth. Express installation files are larger than the updates they are meant to
distribute. This is because the express installation file must contain all the possible
variations of each file it is meant to update.

The upper part of the "Express Installation Files Feature" illustration depicts an update
being distributed by using the express installation files feature; the lower part of the
illustration depicts the same update being distributed without using the express
installation files feature. Notice that with express installation files enabled, you incur an
initial download three times the size of the update. However, this cost is mitigated by the
reduced amount of bandwidth required to update client computers on the corporate
network. With express installation files disabled, your initial download of updates is
Deploying Microsoft Windows Server Update Services 24

smaller, but whatever you download must then be distributed to each of the clients on
your corporate network.

Express Installation Files Feature

The file sizes in the "Express Installation Files Feature" illustration are for illustrative
purposes only. Each update and express installation file varies in size, depending on
what files need to be updated. Further, the size of each file actually distributed to clients
by using express installation files varies depending upon the state of the computer being
updated.

Important:
Although there are some variables with express installation files, there are also
some things you can count on. For example, express installation files are always
bigger in size than the updates they are meant to distribute. As far as bandwidth
goes, it is always less expensive to distribute updates using express installation
files than to distribute updates without.

Not all updates are good candidates for distribution using express installation files. If you
select this option, you obtain express installation files for any updates being distributed
this way. If you are not storing updates locally, you cannot use the express installation
files feature. By default, WSUS does not use express installation files. To enable this
option, see Configure Advanced Synchronization Options.

Background Intelligent Transfer Service


WSUS uses Background Intelligent Transfer Service 2.0 (BITS) for all its file-transfer
tasks, including downloads to clients and server synchronizations. BITS is a Microsoft
technology that allows programs to download files by using spare bandwidth. BITS
Deploying Microsoft Windows Server Update Services 25

maintains file transfers through network disconnections and computer restarts. For more
information about BITS, see the BITS documentation on the MSDN site at
http://go.microsoft.com/fwlink/?LinkId=15106.

Determine Capacity Requirements


Hardware and database software requirements are driven by the number of client
computers being updated in your organization. The following tables offer guidelines for
server hardware and database software, based on the number of client computers being
serviced. A WSUS server using the recommended hardware can support a maximum
number of 15,000 clients.

Hardware Recommendations for 500 or Fewer Clients

Requirement Minimum Recommended

CPU 750 MHz 1 GHz or faster

RAM 512 MB 1 GB

Database WMSDE/MSDE WMSDE/MSDE

Hardware Recommendations for 500 to 15,000 Clients

Requirement Minimum Recommended

CPU 1 GHz or faster 3 GHz dual processor


computer or faster (use dual
processors for over 10,000
clients)

RAM 1 GB 1 GB

Database SQL Server 2000 with SQL Server 2000 with


SP3a Service Pack 3a

Install the WSUS Server


After designing the WSUS deployment, you are ready to install the WSUS server
component. Use the five topics listed below to prepare the computer and the network
environment for WSUS. Check hardware and software requirements, including database
Deploying Microsoft Windows Server Update Services 26

software. If you want to create a custom Web site or install WSUS to a computer that
already has a Web site, see the IIS section. If you have a firewall or proxy server, see the
firewall section to ensure that WSUS has access to updates on the Internet. After you
have done all that, then install and configure the WSUS server.

If you are doing a migration from Microsoft Software Update Services (SUS) or installing
WSUS on a computer with SUS, see Migrate from a SUS Server to a WSUS Server.

In this guide

• Configure the Firewall Between the WSUS Server and the Internet

• Prepare Disks and Partitions

• Install Required Software


• Install and Configure IIS

• Run WSUS Server Setup

Configure the Firewall Between the WSUS


Server and the Internet
If there is a corporate firewall between WSUS and the Internet, you might need to
configure the firewall to ensure that WSUS can obtain updates.

To configure your firewall


• If there is a corporate firewall between WSUS and the Internet, you might
need to configure that firewall to ensure that WSUS can obtain updates. To
obtain updates from Microsoft Update, the WSUS server uses port 80 for HTTP
protocol and port 443 for HTTPS protocol. This is not configurable.

• If your organization does not allow those ports and protocols open to all
addresses, you can restrict access to only the following domains so that WSUS
and Automatic Updates can communicate with Microsoft Update:

• http://windowsupdate.microsoft.com

• http://*.windowsupdate.microsoft.com

• https://*.windowsupdate.microsoft.com

• http://*.update.microsoft.com

• https://*.update.microsoft.com

• http://*.windowsupdate.com
Deploying Microsoft Windows Server Update Services 27

• http://download.windowsupdate.com

• http://download.microsoft.com

• http://*.download.windowsupdate.com

• http://wustat.windows.com

• http://ntservicepack.microsoft.com

Note:
The steps for configuring the firewall above are meant for a corporate firewall
positioned between WSUS and the Internet. Because WSUS initiates all its
network traffic, there is no need to configure Windows Firewall on the WSUS
server.

Although the connection between Microsoft Update and WSUS requires


ports 80 and 443 to be open, you can configure multiple WSUS servers to
synchronize with a custom port.

Prepare Disks and Partitions


Use the following guidelines to prepare the disks and partitions on the computer where
you will install WSUS:

• Both the system partition and the partition on which you install WSUS must be
formatted with the NTFS file system.

• A minimum of 1 GB of free space is required for the system partition.

• A minimum of 6 GB of free space is required for the volume where WSUS stores
content; 30 GB is recommended.

Note:
The 30 GB recommendation is only an estimate based on a number of variables,
such as the number of updates released by Microsoft for any given product, and
how many products a WSUS administrator selects. Although 30 GB should work
for most customers, a worst-case scenario might require more than 30 GB of disk
space. If that should happen, the "Microsoft Windows Server Update Services
Operations Guide" white paper offers guidance on how to recover. The latest
versions of these documents are available on the Microsoft Web site for Windows
Server Update Services at http://go.microsoft.com/fwlink/?LinkId=47374.
Deploying Microsoft Windows Server Update Services 28

• A minimum of 2 GB of free space is required on the volume where WSUS Setup


installs Windows SQL Server 2000 Desktop Engine (WMSDE).

Note that WMSDE is optional. For a complete list of database software options that have
been tested with WSUS, see "Selecting a Database," in Choose the Database Used for
WSUS earlier in this guide.

Install Required Software


The following is a list of required software for each operating system that supports
WSUS. Ensure that the WSUS server meets this list of requirements prior to your running
WSUS Setup. If any of these updates require restarting the computer when installation is
completed, you should restart your server prior to installing WSUS.

Windows Server 2003


The following software is required for running WSUS on Windows Server 2003:

• Microsoft Internet Information Services (IIS) 6.0. For instruction about how to
install IIS, see Install and Configure IIS.

• Background Intelligent Transfer Service (BITS) 2.0; go to the Download Center at


http://go.microsoft.com/fwlink/?LinkId=47251.

• Microsoft .NET Framework 1.1 Service Pack 1 for Windows Server 2003; go to
the Download Center at http://go.microsoft.com/fwlink/?LinkId=35326.

An alternative is to go to Windows Update at http://go.microsoft.com/fwlink/?


linkid=47370 and scan for Critical Updates and Service Packs. Install Microsoft .NET
Framework 1.1 Service Pack 1 for Windows Server 2003.

Windows 2000 Server


The following software is required for running WSUS on Windows 2000 Server:

• Microsoft Internet Information Services (IIS) 5.0. For instruction about how to
install IIS, see Install and Configure IIS.

• Background Intelligent Transfer Service (BITS) 2.0; go to the Download Center at


http://go.microsoft.com/fwlink/?LinkId=46794.

• Database software that is 100-percent compatible with Microsoft SQL. To obtain


Microsoft SQL Server 2000 Desktop Engine (MSDE 2000) Release A, go to the
Download Center at http://go.microsoft.com/fwlink/?LinkId=47366.
Deploying Microsoft Windows Server Update Services 29

• Microsoft Internet Explorer 6.0 Service Pack 1; go to the Download Center at


http://go.microsoft.com/fwlink/?LinkId=47359.

• Microsoft .NET Framework Version 1.1 Redistributable Package; go to the


Download Center at http://go.microsoft.com/fwlink/?LinkId=47369.

• Microsoft .NET Framework 1.1 Service Pack 1; go to the Download Center at


http://go.microsoft.com/fwlink/?LinkId=47368.

An alternative is to go to Windows Update at http://go.microsoft.com/fwlink/?


linkid=47370 and scan for Critical Updates and Service Packs. Install Microsoft .NET
Framework 1.1 Service Pack 1 for Windows Server 2000.

Install and Configure IIS


Before installing WSUS, make sure you have Internet Information Services (IIS) installed.
By default, WSUS uses the default Web site in IIS. WSUS Setup also gives you the
option of creating a Web site on a custom port.

If the IIS service (W3SVC) is stopped during WSUS installation, WSUS Setup starts the
service. Likewise, if you install WSUS to the default Web site and the site is stopped,
WSUS Setup starts it.

To install IIS on Windows Server 2003


1. Click Start, point to Control Panel, and then click Add or Remove
Programs.

2. Click Add/Remove Windows Components.

3. In the Components list, click Application Server.

4. Click OK, click Next, and then follow the instructions on the screen.

IIS Lockdown Tool


The information about IIS Lockdown Wizard can vary, depending on whether you are
using Windows Server 2003 or Windows 2000 Server. No matter which operating system
you use, if you decide to use IIS Lockdown Tool on a server running WSUS, and you
elect to use the URLScan tool, then you must edit the Urlscan.ini file to allow *.exe
requests.

After you edit this file, you must restart both IIS and the WSUS server. You can find the
Urlscan.ini file in the \WINNT\System32\Inetserv\Urlscan folder on the boot drive of your
computer.
Deploying Microsoft Windows Server Update Services 30

To edit the Urlscan.ini file


1. Open Urlscan.ini in a text editor.

2. Remove ".exe" from the [DenyExtensions] section.

3. Ensure that the following settings appear under the [AllowVerbs] section:

• GET

• HEAD

• POST

• OPTIONS

Windows Server 2003 and IIS Lockdown Tool


You do not need to run the IIS Lockdown Wizard on computers running
Windows Server 2003, because the functionality is built into that operating system.

Windows 2000 Server and IIS Lockdown Tool


If you are running IIS on a server running Windows 2000 Server, download and install the
latest version of IIS Lockdown Tool from Microsoft TechNet at
http://go.microsoft.com/fwlink/?LinkId=29896. WSUS Setup does not install this tool.

Microsoft strongly recommends that you run the IIS Lockdown Wizard to help keep your
servers running IIS secure. The IIS Lockdown Wizard turns off unnecessary features,
thereby reducing vulnerability to attackers. If you install the IIS Lockdown Tool and the
URLScan tool on a server running WSUS, you must also read and perform the steps in
the following sections.

IIS Lockdown Tool and WSUS on Windows 2000


When IIS Lockdown is installed on Windows 2000, it denies Execute permissions to
%windir% folder, which then causes an error in the WSUS administrative console. To
recover from this error, you must manually grant Read and Execute permissions to
%windir%\Microsoft.net\Framework\V1.1.4322\Csc.exe.

For more information, see this Knowledge Base article on the Microsoft Support site at
http://go.microsoft.com/fwlink/?LinkId=42681.
Deploying Microsoft Windows Server Update Services 31

Client Self-Update
WSUS uses IIS to automatically update most client computers to the WSUS-compatible
Automatic Updates software. To accomplish this, WSUS Setup creates a virtual directory
named Selfupdate, under the Web site running on port 80 of the computer where you
install WSUS. This virtual directory, called the self-update tree, contains the WSUS-
compatible Automatic Updates software. The earlier Automatic Updates software
included with SUS can only update itself if it finds the self-update tree on a Web server
running on port 80.

If you have Microsoft Windows XP without any service packs in your organization, you
can find more information about the limitations of the client self-update feature in the
"Updating Automatic Updates in Windows XP with no service packs" section in Update
Automatic Updates.

Using the WSUS Custom Web Site


If you put the WSUS Web site on a custom port, you must have a Web site running on
port 80. The Web site on port 80 does not have to be dedicated to WSUS. In fact, WSUS
only uses the site on port 80 to host the self-update tree.

Malicious programs can target the default port for HTTP traffic (port 80). If WSUS is using
a custom port, you can temporarily shut down port 80 throughout your network, but still
be able to distribute updates to combat malicious programs. For this reason, some
administrators find it helpful to have the WSUS Web site on a custom port.

If you already have a Web site on the computer where you intend to install WSUS, you
should use the setup option for creating a custom Web site. This option puts the WSUS
Web site on port 8530. This port is not configurable. If you are installing WSUS on a
computer with a SUS installation, WSUS Setup will only let you install WSUS using the
custom port. For more information about SUS to WSUS migration, see Migrate from a
SUS Server to a WSUS Server later in this guide.

Note:
If you change the port number after WSUS installation, in order to access the
WSUS administration console from a shortcut, you have to create a new shortcut
on your Start menu with the new URL. See Help and Support in Windows Server
2003 for instruction on creating shortcuts.

If you change the WSUS port number after WSUS installation, you must
manually restart the IIS service.
Deploying Microsoft Windows Server Update Services 32

Accessing WSUS on a Custom Port


Because the custom WSUS Web site is not on port 80, you must use a custom URL to
access the WSUS console and Web service. Use the following instructions to access the
WSUS Web site and to configure WSUS when it is running on port 8530.

• Include a custom port number in the URL directing the client computer to the
WSUS server—for example, http://WSUSServerName:portnumber.

• For more information about pointing client computers to the WSUS server, see
Determine a Method to Configure Automatic Updates Clients later in this guide.

• Include a custom port number in the URL for accessing the WSUS console—for
example, http://WSUSServerame:portnumber/WSUSAdmin/.
• If you set up any WSUS servers downstream of a server that uses a custom port
number, you must enter the custom port number on the WSUS console on the
downstream WSUS server. You do not form a URL to make this connection.

You can find instructions for connecting a downstream WSUS server to an upstream
WSUS server in Chain WSUS Servers Together.

Run WSUS Server Setup


After reviewing the previous topics, you are ready to install WSUS. You must log on with
an account that is a member of the local Administrators group. Only members of the local
Administrators group can install WSUS.

If you want to do an unattended installation, see Appendix A: Unattended Installation later


in this guide.

Important:
Be sure to read the WSUS Release Notes. Release notes often contain
important late-breaking information about the release. Look for the WSUS
Release Notes in the following location:

WSUSInstallationDrive:\Program Files\Microsoft Windows Server Update


Services\Documentation\En

To install WSUS on your server


1. Double-click the installer file (WSUSSetup.exe).

Note:
The latest version of WSUSSetup.exe is available on the Microsoft Web site for
Deploying Microsoft Windows Server Update Services 33

Windows Server Update Services at http://go.microsoft.com/fwlink/?


LinkId=47374.

1. On the Welcome page, click Next.

2. Read the terms of the license agreement carefully, click I accept the terms of
the License Agreement, and then click Next.

3. On the Select Update Source page, you can specify where client computers get
updates. If you select Store updates locally, updates are stored on WSUS and you
can select a location in the file system to store updates. If you do not store updates
locally, client computers connect to Microsoft Update to get approved updates.

Make your selection, and then click Next.


For more information, see Determine Where to Store Updates earlier in this guide.

Select Update Source Page

4. On the Database Options page, you select the software used to manage the
WSUS database. By default, WSUS offers to install WMSDE to computers running
Deploying Microsoft Windows Server Update Services 34

Windows Server 2003. You can specify where WSUS installs WMSDE. To accept the
default setting, click Install SQL Server desktop engine (Windows) on this
computer. If you cannot use WMSDE, click Use an existing database server on
this computer, and select the instance name from the drop-down list.

Make your selection, and then click Next.

For more information, see Choose the Database Used for WSUS earlier in this guide.

Database Options Page

5. On the Web Site Selection page, you specify the Web site that WSUS will use.
Note two important URLS: the URL to point client computers to WSUS and the URL
for the WSUS console where you configure WSUS.

Make your selection, and then click Next.

For more information, see Install and Configure IIS earlier in this guide.

Web Site Selection Page


Deploying Microsoft Windows Server Update Services 35

6. On the Mirror Update Settings page, you specify the management role for this
WSUS server. If you want a central management topology, enter the name of the
upstream WSUS server. If this is the first WSUS server on your network or you want
a distributed management topology, skip this screen.

Make your selection, and then click Next.

For more information about management roles, see Choose a Management Style
earlier in this guide.

Mirror Update Settings Page


Deploying Microsoft Windows Server Update Services 36

7. On the Ready to Install Windows Server Update Services page, click Next.

Ready to Install Windows Server Update Services Page


Deploying Microsoft Windows Server Update Services 37

8. If the final page of the wizard confirms that the WSUS installation was
successfully completed, click Finish.

Configure the WSUS Server


After installing WSUS, you are ready to configure the server. During installation, WSUS
Setup created a security group called WSUS Administrators for delegating privileges for
managing WSUS. Add WSUS administrators to this group so that WSUS administrators
do not have to be members of the local Administrators group to manage WSUS.

In this guide

• Access the WSUS Administration Console

• Configure WSUS to Use a Proxy Server

• Select Products and Classifications


Deploying Microsoft Windows Server Update Services 38

• Synchronize the WSUS Server

• Configure Advanced Synchronization Options

• Chain WSUS Servers Together

• Create a Replica Group

• Create Computer Groups for Computers

• Approve Updates

• Verify Update Deployment

• Secure Your WSUS Deployment

Access the WSUS Administration Console


Use the following procedure to access the WSUS administration console. You can also
open the administration console from Internet Explorer on any server or computer on
your network by going to http://WSUSServerName[:portnumber]/WSUSAdmin/.

You must be a member of the local Administrators group or the WSUS Administrators
group on the server on which WSUS is installed in order to use the WSUS console.

To open the WSUS console


• On your WSUS server, click Start, point to All Programs, point to
Administrative Tools, and then click Microsoft Windows Server Update
Services.

Note:
If you are running Windows Server 2003 and do not add
http://WSUSWebsiteName to the list of sites in the Local Intranet zone in Internet
Explorer, you might be prompted for credentials each time you open the WSUS
console.

If you change the port assignment in IIS after you install WSUS, you need to
create a new shortcut on the Start menu to access WSUS from the Start menu.

Configure WSUS to Use a Proxy Server


If you use a proxy server on your network, use the WSUS console to configure WSUS to
use the proxy server. This is necessary in order to synchronize the server with Microsoft
Update.
Deploying Microsoft Windows Server Update Services 39

To specify a proxy server for synchronization


1. On the WSUS console toolbar, click Options, and then click
Synchronization Options.

2. In the Proxy server box, click Use a proxy server when synchronizing,
and then enter the server name, and port number (port 80 is the default) of the
proxy server in the corresponding boxes.

3. If you want to connect to the proxy server under specific user credentials,
click Use user credentials to connect to the proxy server, and then enter the
user name, domain, and password of the user in the corresponding boxes. If you
want to enable basic authentication for the user connecting to the proxy server,
click Allow basic authentication (password in clear text).

4. Under Tasks, click Save settings, and then click OK when the confirmation
box appears.

Select Products and Classifications


After you specify the proxy server, you are ready to select the products you want to
update and the types of updates you want to download. There is a description of why you
might want to do this in "Filtering Updates," in Determine Bandwidth Options to Use for
Your Deployment earlier in this guide.

To specify update products and classifications for synchronization


1. On the WSUS console toolbar, click Options, and then click
Synchronization Options.

2. In the Products and Classifications box, under Products, click Change.

3. In the Add/Remove Products box, under Products, select the products or


product families for the updates you want your WSUS server to download, and
then click OK.

4. Under Update classifications, click Change.

5. In the Add/Remove Classifications box, under Classifications, select the


update classifications for the updates you want your WSUS server to download,
and then click OK.
Deploying Microsoft Windows Server Update Services 40

Note:
You may have to do an initial synchronization to get some products to appear in
the list of product classifications.

Synchronize the WSUS Server


After you select products and update classifications, you are ready to synchronize
WSUS. The synchronization process involves downloading updates from Microsoft
Update or another WSUS server. WSUS determines if any new updates have been made
available since the last time you synchronized. If this is the first time you are
synchronizing the WSUS server, all of the updates are made available for approval.

To synchronize the WSUS server


1. On the WSUS console toolbar, click Options, and then click
Synchronization Options.

2. Under Tasks, click Synchronize now.

After the synchronization finishes, you can click Updates on the WSUS console toolbar
to view the list of updates.

Configure Advanced Synchronization Options


Advanced synchronization features include various options to manage bandwidth and
store updates. There is a description of each of these features, including reasons why
these features are useful, and their limitations, in Determine Where to Store Updates and
Determine Bandwidth Options to Use for Your Deployment earlier in this guide.

Update Storage Options


Use the Update Files section to determine if updates will be stored on WSUS or if client
computers will connect to the Internet to get updates. There is a description of this feature
in Determine Where to Store Updates earlier in this guide.

To specify where updates are stored


1. On the WSUS console toolbar, click Options, and then click
Synchronization Options.

2. Under Update Files and Languages, click Advanced, then read the
warning and click OK.
Deploying Microsoft Windows Server Update Services 41

3. If you want to store updates in WSUS, in the Advanced Synchronization


Options dialog box, under Update Files, click Store update files locally on
this server. If you want clients to connect to the Internet to get updates, then
click Do not store updates locally; clients install updates from Microsoft
Update.

Deferred Downloads Options


Use the Update Files section to determine if updates should be downloaded during
synchronization or when the update is approved. Find a description of this feature in
"Deferring the Download of Updates," in Determine Bandwidth Options to Use for Your
Deployment earlier in this guide.

To specify whether updates are downloaded during synchronization or when


the update is approved
1. On the WSUS console toolbar, click Options, and then click
Synchronization Options.

2. Under Update Files and Languages, click Advanced, then read the
warning and click OK.

3. If you want to download only metadata about the updates during


synchronization, in the Advanced Synchronization Options dialog box, under
Update Files, select the Download updates to this server only when updates
are approved check box. If you want the update files and metadata during
synchronization, clear the check box.

Express Installation Files Options


Use the Update Files section to determine if express installation files should be
downloaded during synchronization. Find a description of this feature in “Using Express
installation files,” in Determine Bandwidth Options to Use for Your Deployment earlier in
this paper.

To specify whether express installation files are downloaded during


synchronization
1. On the WSUS console toolbar, click Options, and then click
Synchronization Options.

2. Under Update Files and Languages, click Advanced, then read the
warning and click OK.
Deploying Microsoft Windows Server Update Services 42

3. If you want to download express installation files, in the Advanced


Synchronization Options dialog box, under Update Files, select the Download
express installation files check box. If you do not want express installation files,
clear the check box.

Filtering Updates Options


Use the Languages section to select the language of the updates to synchronize. There
is a description of this feature in “Filtering updates,” in Determine Bandwidth Options to
Use for Your Deployment earlier in this guide.

To specify language options


1. On the WSUS console toolbar, click Options, and then click
Synchronization Options.

2. Under Update Files and Languages, click Advanced, then read the
warning and click OK.

3. In the Advanced Synchronization Options dialog box, under Languages,


select one of the following language options, and then click OK.

• Download only those updates that match the locale of this server
(Locale) where Locale is the name of the server locale. This means that only
updates targeted to the locale of the server will be downloaded during
synchronization.

• Download updates in all languages, including new languages This


means that all languages will be downloaded during synchronization. If a new
language is added, it will be automatically downloaded.

• Download updates only in the selected languages This means that


only updates targeted to the languages you select will be downloaded during
synchronization. If you choose this option, you must also choose each
language you want from the list of those available.

Note:
If you change language options, Microsoft recommends that you manually
synchronize them between the centrally managed WSUS server and its replica
servers. This avoids a situation where changing language options on the centrally
managed server alone might result in the number of updates that are approved
on it not matching the number approved on the replica servers.
Deploying Microsoft Windows Server Update Services 43

Chain WSUS Servers Together


There is a discussion of the benefits and limitations of this process in "Chain of WSUS
Servers," in Choose a Type of Deployment earlier in this guide.

To connect a downstream server to an upstream server


1. On the WSUS console toolbar, click Options, and then click
Synchronization Options.

2. In the Update Source box, click Synchronize from an upstream Windows


Server Update Services server, and then enter the server name and port
number in the corresponding boxes.

3. Under Tasks, click Save settings, and then click OK when the confirmation
box appears.

Create a Replica Group


A description of the benefits of creating a replica group is available in "Centralized
Management," in Choose a Management Style earlier in this guide.

To create a replica group for centralized management of multiple WSUS


servers
1. Install WSUS on a computer at a site where it can be managed by an
administrator. Follow the steps in Run WSUS Server Setup earlier in this guide.

2. Install WSUS on a computer at a remote site. Follow the steps in Run WSUS
Server Setup earlier in this guide. When you get to the Mirror Update Settings page
during WSUS setup, enter the name of the WSUS server from step 1.

Mirror Setting Updates Page


Deploying Microsoft Windows Server Update Services 44

3. Repeat step 2 as necessary to add additional WSUS servers to the replica group.

Create Computer Groups for Computers


There is a description of why you may want to use this feature, as well as a discussion of
limitations and default settings, in the "Using Computer Groups" section in Choose a
Type of Deployment earlier in this guide.

Setting up Computer Groups


Setting up computer groups is a three-step process. First, specify how you are going to
assign computers to the 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 group in WSUS. Third,
move the computers into groups by using whichever method you chose in the first step.
Deploying Microsoft Windows Server Update Services 45

Step 1: Specify How to Assign Computers to Computer Groups


Use the WSUS console to specify whether you are using client-side or server-side
targeting.

To specify the method for assigning computers to groups


1. In the WSUS console, click Options, and then click Computer Options.

2. In the Computer Options box, select one of the following options:

• Use the Move computers task in Windows Server Update Services if


you want to create groups and assign computers through the WSUS console.

• Use Group Policy or registry settings on client computers if you


want to create groups and assign computers using Group Policy or by editing
registry settings on the client computer.

3. Under Tasks, click Save settings, and click OK when the confirmation box
appears.

Step 2: Create Computer Groups


Create the computer groups in WSUS. Whether you use client-side or server-side
targeting, you must create the computer groups.

To create a computer group


1. In the WSUS console toolbar, click Computers.

2. Under Tasks, click Create a computer group.

3. In the Group name box, type a name for your new computer group, and then
click OK.

Step 3: Move the Computers


Use WSUS to move computers into groups or automate this task.

To move a computer to a different group by using server-side targeting


1. In the WSUS console, click Computers.

2. In the Groups box, click the computer group of the computer you want to
move.

3. In the list of computers, select the computer you want to move.


Deploying Microsoft Windows Server Update Services 46

4. Under Tasks, click Move the selected computer.

5. In the Computer group list, select the computer group you want to move the
computer to, and then click OK.

To move a computer to a different group by using client-side targeting


• Use Group Policy or registry to enable client-side targeting. For more
information about how to configure the client computer, see Determine a Method
to Configure Automatic Updates Clients. For more information about the client-
side targeting setting, see the "Enable client-side targeting" section in Configure
Automatic Updates by Using Group Policy, later in this guide.

Approve Updates
You should approve updates to test the functionality of your WSUS deployment. There
are many options for deploying updates; the procedure below only covers the basics. Use
WSUS Help or the "Microsoft Windows Update Services Operations Guide" to
understand all your approval options.

To approve multiple updates for installation


1. On the WSUS console toolbar, click Updates.

2. On the list of updates, select the multiple updates you want to approve for
installation.

3. Under Update Tasks, click Approve for installation. The Approve


Updates dialog box appears with the action for the Approve list set to Install for
the All Computers group.

4. If you want to specify a different default approval setting for one or more
groups, find the group for which you want to set the special approval setting in
the Group approval settings for the selected updates box, select an approval
setting from the Approval column, and then click OK. By default, all groups
found on the WSUS server are initially set to match the settings for the All
Computers group.
Deploying Microsoft Windows Server Update Services 47

Verify Update Deployment


When client computers check in with the WSUS server, you can use the WSUS reporting
feature to determine if updates have been deployed. By default, client computers check
in with WSUS every 22 hours, but this is configurable. For more information about
configuring the time when client computers check in with WSUS, see the "Automatic
Update detection frequency" section in Configure Automatic Updates by Using Group
Policy later in this guide.

To check the Status of Updates report


1. On the WSUS console toolbar, click Reports.

2. On the Reports page, click Status of Updates.

3. If you want to filter the list of displayed updates, under View, select the
criteria you want to use, and then click Apply.

4. If you want to see the status of an update by computer group and then by
computer, expand the view of the update as necessary.

5. If you want to print the Status of Updates report, under Tasks, click Print
report.

Secure Your WSUS Deployment


This guide includes three ways to further enhance the security of your WSUS server:

• Recommendations for hardening your Windows Server 2003 running WSUS.

• Recommendations for adding authentication between chained WSUS servers in


an Active Directory environment.

• Recommendations for implement Secure Sockets Layer protocol on WSUS.

Hardening your Windows Server 2003 running WSUS


You can find recommended settings for hardening your WSUS server in Appendix D:
Security Settings. These recommendations include hardening a number of Windows
Server components as well as IIS 6.0 and SQL Server 2000. If you are not running
Windows Server 2003 or if you are not using SQL Server 2000 as your database
software for WSUS, you may not be able to utilize all of these settings.
Deploying Microsoft Windows Server Update Services 48

Adding Authentication Between Chained WSUS Servers in


an Active Directory Environment
You can add authentication for server-to-server synchronization.

There are some limitations to enabling authentication. Any WSUS server you want to
authenticate must be in an Active Directory environment. Also, if the WSUS servers are in
different forests, there has to be trust between forests for this authentication method to
succeed.

Enabling authentication is a two-step process. First, you create a list of downstream


WSUS servers allowed to authenticate with this WSUS server; add this list to a text file
that was created when you originally installed WSUS. Second, in IIS, you disable
anonymous access to the WSUS server. With completion of these two steps, only the
downstream computers listed can synchronize with the WSUS server. Each of these
steps is detailed below.

Step 1: Create an authentication list


WSUS setup creates a configuration file that enables you to add an explicit list of
computers that have access to WSUS. You can find this file in the file system of the
WSUS server at:

%ProgramFiles%\Update Services\WebServices\Serversyncwebservice\Web.config

Use the <authorization> element to define an authentication list. You must add the
<authorization> element below the <configuration> and <system.web> elements.

Consider the example below:


<configuration>
<system.web>
<authorization>
<allow users="domain\computer_name,domain\computer_name" />
<deny users="*" />
</authorization>
</configuration>
</system.web>

Within opening and closing authorization tags, you specify a list of computers that are
allowed a connection to the Web service. You must enter these computers as
Domain\computer_name. If you want multiple computers, use a comma to separate the
names. You can also specify an explicit list of computers that are denied access. Order in
this list is important, as the evaluation stops with the first item that applies to the user.

The XML schema for this list can be found on an MSDN Web site at
http://go.microsoft.com/fwlink/?LinkId=47691.
Deploying Microsoft Windows Server Update Services 49

Step 2: Configure IIS


The next step is to configure IIS to disable anonymous access to the
ServerSyncWebService virtual directory and enable Integrated Windows authentication.

To configure IIS to disable anonymous access and enable Integrated Windows


authentication for the WSUS ServerSynchWebService
1. On the Start menu, point to Programs, point to Administrator Tools, and
then click Internet Information Services Manager.

2. Expand the local computer node.

3. Expand the WSUS Web site node.

4. Right-click SeverSyncWebService, and then click Properties.

5. On the Directory Security tab, under Authentication and access control,


click Edit.

6. In the Authentication Methods dialog box, clear the Enable anonymous


access check box and select the Integrated Windows authentication check
box.

7. Click OK twice.

Securing WSUS with Secure Sockets Layer


You can use Secure Sockets Layer (SSL) protocol to secure your WSUS deployment.
WSUS uses SSL to allow client computers and downstream WSUS servers to
authenticate the WSUS server. WSUS also uses SSL to encrypt metadata passed
between clients and downstream WSUS servers. Note that WSUS only uses SSL for
metadata. This is also the way Microsoft Update distributes updates.

As discussed earlier in this guide, updates consist of two parts: metadata that describes
what an update is useful for, and the files to install the update on a computer. Microsoft
mitigates the risk of sending update files over an unencrypted channel by signing each
update. In addition to signing each update, a hash is computed and sent with the
metadata for each update. When an update is downloaded, WSUS checks the digital
signature and hash. If the update has been tampered with, it is not installed.

Limitations of WSUS SSL Deployments


There are two limiting issues that administrators considering WSUS SSL deployments
need to know about.
Deploying Microsoft Windows Server Update Services 50

Securing your WSUS deployment with SSL increases the workload of the server. You
should plan for about a 10-percent loss of performance because of the additional cost of
encrypting all metadata sent over the wire.

If you are using remote SQL, the connection between the WSUS server and the server
running the database is not secured with SSL. If the database connection must be
secured, consider the following recommendations:

• Put the database on the WSUS server (the default WSUS configuration).

• Put the remote server running SQL and the WSUS server on a private network.

• Deploy Internet Protocol security (IPsec) on your network to secure network


traffic.
The Overview of IPsec Deployment page on the Microsoft Web site at
http://go.microsoft.com/fwlink/?LinkId=45154 offers guidance on how to deploy IPsec in
your environment.

Configuring SSL on the WSUS Server


The most important thing to remember when configuring the WSUS server to use SSL is
that WSUS requires two ports in this configuration: one for encrypting metadata with
HTTPS and one for clear HTTP. When you configure IIS to use the certificate, keep the
following points in mind:

• You cannot set up the entire WSUS Web site to require SSL. This would mean
that all traffic to the WSUS site would have to be encrypted, but WSUS only encrypts
metadata traffic. When a client computer or another WSUS server attempted to get
update files from WSUS, the transfer would fail because there is no way for WSUS to
distribute the file by using plain HTTP.

To keep WSUS Web site as secure as possible, only require SSL for the following
virtual roots:

• SimpleAuthWebService

• DSSAuthWebService

• ServerSyncWebService

• WSUSAdmin

• ClientWebService

To keep WSUS functioning, you should not require SSL for the following virtual roots:

• Content
Deploying Microsoft Windows Server Update Services 51

• ReportingWebService

• SelfUpdate

• The certificate on downstream WSUS servers has to be imported into either the
Local Computer's Trusted Root CA store or Windows Server Update Service's
Trusted Root CA store. If the certificate is only imported to the Local User's Trusted
Root CA store, the downstream WSUS server will fail server authentication on the
upstream server.

• You can use any port you like when you configure IIS to use SSL. However, the
port you set up for SSL determines the port that WSUS uses for clear HTTP.
Consider the following examples:
• If you use the industry standard port of 443 for HTTPS traffic, then WSUS
uses port 80 for clear HTTP traffic, which is the industry standard for HTTP.

• If you use any other port for HTTPS traffic, WSUS assumes the clear HTTP
traffic should be sent over the port that numerically precedes the port for HTTPS.
For example, if you use port 8531 for HTTPS, WSUS uses 8530 for HTTP.

Note:
If you change the port number or want to use HTTPS to access the WSUS
administration console, you have to create a new shortcut on your Start menu
with the new URL in order to access the WSUS administration console from the
Start menu. See Help and Support in Windows Server 2003 for information
about creating shortcuts.

Sample SSL URLs to Access WSUS Administrative Console


This section includes sample URLs to use for accessing the WSUS administrative
console when you have configured WSUS to use SSL.

Accessing WSUS Administrative Console by Using Industry Standard Port


Assignments for SSL

If you were to install WSUS to the default site, and then set up SSL to use industry
standard port assignments, you would use the following URL to access the WSUS
administrative console over a secure connection:

https://WSUSServerName/WSUSAdmin/

Note Remember that if you change WSUS port assignments after installation and you
are using SSL, WSUS uses the rules noted above to assign a port for the HTTP protocol.

Accessing WSUS Administrative Console by Using Custom Port Assignments for


SSL
Deploying Microsoft Windows Server Update Services 52

If you were to install WSUS to the custom site, and then set up SSL to use a custom port
assignment of 8531 for the SSL port, you would then use the following URL to access the
WSUS administrative console by using a secure connection:

https://WSUSServerName: 8531/WSUSAdmin/

Note You do not have to use 8531 for the SSL port. You can use any free port, but
WSUS requires two ports for SSL: the port that you assign and the port that numerically
precedes it. For example, if you pick 2424 for SSL port, WSUS would use 2424 for
HTTPS and 2423 for HTTP.

Configuring SSL on Client Computers


There are two important caveats when configuring client computers:

• You must include a URL for a secure port that the WSUS server is listening on.
Because you cannot require SSL on the server, the only way to ensure that client
computers use a secure channel is to make sure they use a URL that specifies
HTTPS. If you are using any port other than 443 for SSL, you must include that port
in the URL, too.

For example, you might use https://ssl-servername:3051 to point clients to a WSUS


server that is using a custom SSL port of 3051.

Likewise, you might use https://ssl-servername for a WSUS server that is using port
443 for HTTPS.

For more information about how to point client computers to the WSUS server, see
"Specify intranet Microsoft Update service location" in Configure Automatic Updates
by Using Group Policy later in this guide.

• The certificate on client computers has to be imported into either the Local
Computer's Trusted Root CA store or Automatic Update Service's Trusted Root CA
store. If the certificate is only imported to the Local User's Trusted Root CA store
Automatic Updates will fail server authentication.

• Your client computers must trust the certificate you bind to the WSUS server in
IIS. Depending upon the type of certificate you are using, you may have to set up a
service to enable the clients to trust the certificate bound to the WSUS server. For
more information, see "Further Reading" later in this section.

Sample SSL URLs to Point Automatic Updates to WSUS


This section includes sample URLs to use to point Automatic Updates to WSUS when
you have configured WSUS to use SSL.
Deploying Microsoft Windows Server Update Services 53

Point Automatic Updates to WSUS Using Industry Standard Port Assignments for
SSL

If you were to install WSUS to the default site, and then set up SSL to use industry
standard port assignments, you would use the following URL to point Automatic Updates
to WSUS server:

https://WSUSServerName

Point Automatic Updates to WSUS Using Custom Port Assignments for SSL

If you were to install WSUS to the custom site, and then set up SSL to use a custom port
assignment of 8531 for the SSL port, you would use the following URL to point Automatic
Updates to WSUS server:
https://WSUSServerName: 8531

Configuring SSL for Downstream WSUS Servers


The following instructions are for configuring a downstream server to synchronize to an
upstream server that is using SSL.

To connect a downstream server to an upstream server set up to use SSL


1. In the WSUS console toolbar, click Options, and then click Synchronization
Options.

2. In the Update Source box, click Synchronize from an upstream Windows


Server Update Services server, enter the name of the upstream server and the
port number it uses for SSL connections, and then select the Use SSL when
synchronizing update information check box.

3. Under Tasks, click Save settings, and then click OK when the confirmation
dialog box appears.

Further Reading on SSL


Setting up a Certification Authority (CA), binding a certificate to the WSUS Web site, and
then bootstrapping client computers to trust the certificate on the WSUS Web site are
complex administrative tasks. The step-by-step procedures for each task are beyond the
scope of this guide.

However, several articles on the subject are available. For more information and
instructions on how to install certificates and set up your environment, see the following
pages on the Microsoft Web site.
Deploying Microsoft Windows Server Update Services 54

• The Windows Server 2003 PKI Operations Guide page on TechNet at


http://go.microsoft.com/fwlink/?LinkId=47272 provides a guide for administrators on
how to configure and operate a Windows Certification Authority.

• The How To Set Up SSL on a Web Server page on MSDN at


http://go.microsoft.com/fwlink/?LinkId=41454 offers step-by-step instruction on setting
up SSL on a Web site.

• The Certificate Autoenrollment in Windows Server 2003 page on TechNet at


http://go.microsoft.com/fwlink/?LinkId=47373 offers instruction on how to
automatically enroll client computers running Windows XP in Windows Server 2003
Enterprise environments integrated with Active Directory.

• The Advanced Certificate Enrollment and Management page on TechNet at


http://go.microsoft.com/fwlink/?LinkId=47395 offers guidance on how to automatically
enroll client computers in other environments.

Update and Configure the Automatic


Updates Client Component
After planning the deployment, and installing and configuring the WSUS server, you are
ready to work with the client computers. You can use Group Policy or the registry to
configure Automatic Updates. Configuring Automatic Updates involves pointing the client
computers to the WSUS server, making sure that the Automatic Updates software is up-
to-date, and configuring any additional environment settings.

In this guide

• Client Component Requirements

• Update Automatic Updates

• Determine a Method to Configure Automatic Updates Clients

• Manipulate Automatic Updates Behavior Using Command-line Options

Client Component Requirements


Automatic Updates is the WSUS client software. Other than a network connection,
Automatic Updates requires no particular hardware configuration. It can be used with
WSUS on any computer that runs any of the following operating systems:
Deploying Microsoft Windows Server Update Services 55

• Microsoft Windows 2000 Professional with Service Pack 3 (SP3) or Service


Pack 4 (SP4), Windows 2000 Server with SP3 or SP4, or Windows 2000 Advanced
Server with SP3 or SP4

• Microsoft Windows XP Professional, with or without Service Pack 1 or Service


Pack 2

• Microsoft Windows Server 2003, Standard Edition; Windows Server 2003,


Enterprise Edition; Windows Server 2003, Datacenter Edition; Windows Server 2003,
Web Edition

Update Automatic Updates


WSUS requires the WSUS client, a version of Automatic Updates compatible with WSUS.
Computers running Windows XP with Service Pack 2 (SP2) already have the WSUS
client installed.

If you have been using Software Update Services (SUS) to distribute updates, you might
have the SUS client installed; however, you might also have the WSUS client in your
environment and not know it. This is because you can install the new WSUS client on the
same computer as the old SUS client and both clients will function; however, both cannot
function simultaneously.

If you point the WSUS client to a SUS server, the WSUS client hibernates and allows the
SUS client to function, complete with the old user interface. If you used SUS to deploy
Windows XP with SP2, you cannot see the new Automatic Updates user interface. This is
called side-by-side mode. None of the new WSUS client functionality is available in side-
by-side mode.

If you do not have Windows XP with SP2, you must update Automatic Updates by using
the client self-update feature.

Automatic Updates Client Self-Update Feature


With the advent of the original client software for SUS, each time Automatic Updates
checks the public Web site or internal server for updates, it also checks for updates to
itself. This means that most versions of Automatic Updates can be pointed to the public
Windows Update site and they will automatically self-update. You can also use the WSUS
server to self-update the client software. For specifics, see the "Client Self-Update"
section in Install and Configure IIS earlier in this guide.

The self-updating client software is available on the following operating systems:

• Windows 2000 with Service Pack 3 or Service Pack 4


Deploying Microsoft Windows Server Update Services 56

• Windows XP with Service Pack 1 or Service Pack 2

• Windows Server 2003

Updating Automatic Updates in Windows XP with No Service Packs


Windows XP with no service packs has Automatic Updates installed, but it will not
automatically update itself when pointed to the WSUS server. If you have Windows XP
without any service packs in your environment, and have never used SUS, you must
install the SUS client software to enable Automatic Updates to self-update. After you load
the SUS client, you can point these clients to the server running WSUS. If the client self-
update feature is configured on port 80 of the WSUS server, the SUS client will find the
WSUS client software and self-update. For more information about the client self-update
feature, see "Client Self-Update," in Install and Configure IIS earlier in this guide.

To obtain the SUS client installer, go to the Automatic Updates June 2002 page on the
Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=22338.

Determine a Method to Configure Automatic


Updates Clients
You can find the Automatic Updates user interface in Control Panel, but it appears in
different administrative tools in Control Panel depending upon the operating system. In
Windows XP and Windows Server 2003, it appears as a tab in the System administrative
tool. In Windows 2000, Automatic Updates has its own administrative tool in Control
Panel. Although Automatic Updates has its own user interface, you do not have to use
this interface to configure Automatic Updates for WSUS. In fact, you cannot use the
Automatic Updates user interface to point Automatic Updates to WSUS. This section
describes the options available to you for configuring Automatic Updates.

How best to configure Automatic Updates and WSUS environment options depends upon
your network environment. In an Active Directory environment, you would use Group
Policy. In a non-Active Directory environment, you might use the Local Group Policy
object or edit the registry directly.

Administrator-defined configuration options driven by Group Policy—whether set with


Group Policy in an Active Directory environment or via the registry or Local Group Policy
object—always take precedence over user-defined options. When you use administrative
policies to configure Automatic Updates, the Automatic Updates user interface is disabled
on the target computer.

If you configure Automatic Updates to notify the user of updates that are ready to be
downloaded, it sends the notification to the System log and to a logged-on administrator
Deploying Microsoft Windows Server Update Services 57

of the computer. You can use Group Policy to enable non-administrators to get this
message. If no user with administrator credentials is logged on and you have not enabled
non-administrators to get notifications, Automatic Updates waits for an administrator to
log on before offering the notification.

By default every 22 hours, minus a random offset, Automatic Updates polls the WSUS
server for approved updates; if any new updates need to be installed, they are
downloaded. The amount of time between each detection cycle can be manipulated from
1 to 22 hours by using Group Policy.

You can manipulate the notification options 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.

• 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. You can
manipulate computer restarts 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.

In this guide
Deploying Microsoft Windows Server Update Services 58

Configure Automatic Updates by Using Group Policy

Configure Automatic Updates in a Non–Active Directory Environment

Configure Automatic Updates by Using Group Policy


When you configure the Group Policy settings for WSUS, use a Group Policy object
(GPO) linked to an Active Directory container appropriate for your environment. Microsoft
does not recommend editing the Default Domain or Default Domain Controller GPOs to
add WSUS settings.

In a simple environment, link the GPO with the WSUS settings to the domain. In more
complex environment, you might have multiple GPOs linked to several organizational
units (OUs), which enables you to have different WSUS policy settings applied to different
types of computers.

After you set up a client computer, it will take a few minutes before it appears on the
Computers page in the WSUS console. For client computers configured with an Active
Directory-based GPO, it will take about 20 minutes after Group Policy refreshes (that is,
applies any new settings to the client computer). By default, Group Policy refreshes in the
background every 90 minutes, with a random offset of 0 to 30 minutes. If you want to
refresh Group Policy sooner, you can go to a command prompt on the client computer
and type: gpupdate /force.

Note:
On client computers running Windows 2000, you can type the following at a
command prompt: secedit /refreshpolicy machine_policy enforce.

The following is a list of the Group Policy options available for configuring WSUS-related
items in the environment.

Note:
In Windows 2000, Group Policy Object Editor is known as Group Policy Editor.
Although the name changed, it is the same tool for editing Group Policy objects.
It is also commonly referred to as gpedit.

Load the WSUS Administrative Template


Before you can set any Group Policy options for WSUS, you must ensure that the latest
administrative template has been loaded on the computer used to administer Group
Policy. The administrative template with WSUS settings is named Wuau.adm. Although
there are additional Group Policy settings related to the Windows Update Web site, all the
new Group Policy settings for WSUS are contained within the Wuau.adm file.
Deploying Microsoft Windows Server Update Services 59

If the computer you are using to configure Group Policy has the latest version of
Wuau.adm, you do not need to load the file to configure settings. The new version of
Wuau.adm is available on Windows XP with Service Pack 2. Administrative templates
files are stored by default in the %windir%\Inf directory.

Important:
You can find the correct version of Wuau.adm on any computer having the
WSUS-compatible Automatic Updates installed. You can use the old version of
Wuau.adm to initially point Automatic Updates to the WSUS server in order to
self-update. After the Automatic Updates self-updates, the new Wuau.adm file
appears in the %windir%\Inf folder.

If the computer you are using to configure Group Policy does not have the latest version
of Wuau.adm, you must first load it by using the following procedure.

To add the WSUS Administrative Template


1. In Group Policy Object Editor, click either of the Administrative Templates
nodes.

2. On the Action menu, click Add/Remove Templates.

3. Click Add.

4. In the Policy Templates dialog box, select Wuau.adm, and then click Open.

5. In the Add/Remove Templates dialog box, click Close.

Configure Automatic Updates


The settings for this policy enable you to configure how Automatic Updates works. You
must specify that Automatic Updates download updates from the WSUS server rather
than from Windows Update.

To configure the behavior of Automatic Updates


1. In Group Policy Object Editor, expand Computer Configuration, expand
Administrative Templates, expand Windows Components, and then click
Windows Update.

2. In the details pane, click Configure Automatic Updates.

3. Click Enabled and select one of the following options:

• Notify for download and notify for install. This option notifies a
logged-on administrative user prior to the download and prior to the
Deploying Microsoft Windows Server Update Services 60

installation of the updates.

• Auto download and notify for install. This option automatically begins
downloading updates and then notifies a logged-on administrative user prior
to installing the updates.

• Auto download and schedule the install. If Automatic Updates is


configured to perform a scheduled installation, you must also set the day and
time for the recurring scheduled installation.

• Allow local admin to choose setting. With this option, the local
administrators are allowed to use Automatic Updates in Control Panel to
select a configuration option of their choice. For example, they can choose
their own scheduled installation time. Local administrators are not allowed to
disable Automatic Updates.

4. Click OK.

Specify Intranet Microsoft Update Service Location


The settings for this policy enable you to configure a WSUS server that Automatic
Updates will contact for updates. You must enable this policy in order for Automatic
Updates to download updates from the WSUS server.

Enter the WSUS server HTTP(S) URL twice, so that the server specified for updates is
also used for reporting client events. For example, type http(s)://servername in both
boxes. Both URLs are required.

To redirect Automatic Updates to a WSUS server


1. In Group Policy Object Editor, expand Computer Configuration, expand
Administrative Templates, expand Windows Components, and then click
Windows Update.

2. In the details pane, click Specify Intranet Microsoft update service


location.

3. Click Enabled and type the HTTP(S) URL of the same WSUS server in the
Set the intranet update service for detecting updates box and in the Set the
intranet statistics server box. For example, type http(s)://servername in both
boxes.

4. Click OK.
Deploying Microsoft Windows Server Update Services 61

Enable Client-side Targeting


This policy enables client computers to self-populate computer groups that exist on the
WSUS server.

If the status is set to Enabled, the specified computer group information is sent to WSUS,
which uses it to determine which updates should be deployed to this computer. This
setting is only capable of indicating to the WSUS server which group the client computer
should use. You must actually create the group on the WSUS server.

If the status is set to Disabled or Not Configured, no computer group information will be
sent to WSUS.

To enable client-side targeting


1. In Group Policy Object Editor, expand Computer Configuration, expand
Administrative Templates, expand Windows Components, and then click
Windows Update.

2. In the details pane, click Enable client-side targeting.

3. Click Enabled and type the name of the computer group in the box.

4. Click OK.

Reschedule Automatic Update Scheduled Installations


This policy specifies the amount of time for Automatic Updates to wait, following system
startup, before proceeding with a scheduled installation that was missed previously.

If the status is set to Enabled, a scheduled installation that did not take place earlier will
occur the specified number of minutes after the computer is next started.

If the status is set to Disabled, a missed scheduled installation will occur with the next
scheduled installation.

If the status is set to Not Configured, a missed scheduled installation will occur one
minute after the computer is next started.

This policy applies only when Automatic Updates is configured to perform scheduled
installations of updates. If the Configure Automatic Updates policy is disabled, this policy
has no effect.

To reschedule Automatic Update scheduled installation


1. In Group Policy Object Editor, expand Computer Configuration, expand
Administrative Templates, expand Windows Components, and then click
Deploying Microsoft Windows Server Update Services 62

Windows Update.

2. In the details pane, click Reschedule Automatic Update scheduled


installations, click Enable, and type a value in minutes.

3. Click OK.

No Auto-restart for Scheduled Automatic Update Installation Options


This policy specifies that to complete a scheduled installation, Automatic Updates will
wait for the computer to be restarted by any user who is logged on, instead of causing the
computer to restart automatically.

If the status is set to Enabled, Automatic Updates will not restart a computer
automatically during a scheduled installation if a user is logged on to the computer.
Instead, Automatic Updates will notify the user to restart the computer in order to
complete the installation.

Be aware that Automatic Updates will not be able to detect future updates until the restart
occurs.

If the status is set to Disabled or Not Configured, Automatic Updates will notify the user
that the computer will automatically restart in 5 minutes to complete the installation.

This policy applies only when Automatic Updates is configured to perform scheduled
installations of updates. If the Configure Automatic Updates policy is disabled, this policy
has no effect.

To inhibit auto-restart for scheduled Automatic Update installation options


1. In Group Policy Object Editor, expand Computer Configuration, expand
Administrative Templates, expand Windows Components, and then click
Windows Update.

2. In the details pane, click No auto-restart for scheduled Automatic Update


installation options, and set the option.

3. Click OK.

Automatic Update Detection Frequency


This policy specifies the hours that Windows will use to determine how long to wait before
checking for available updates. The exact wait time is determined by using the hours
specified here, minus 0 to 20 percent of the hours specified. For example, if this policy is
used to specify a 20-hour detection frequency, then all WSUS clients to which this policy
is applied will check for updates anywhere between 16 and 20 hours.
Deploying Microsoft Windows Server Update Services 63

If the status is set to Enabled, Automatic Updates will check for available updates at the
specified interval.

If the status is set to Disabled or Not Configured, Automatic Updates will check for
available updates at the default interval of 22 hours.

To set Automatic Update detection frequency


1. In Group Policy Object Editor, expand Computer Configuration, expand
Administrative Templates, expand Windows Components, and then click
Windows Update.

2. In the details pane, click Automatic Update detection frequency, and set
the option.

3. Click OK.

Allow Automatic Update Immediate Installation


This policy specifies whether Automatic Updates should automatically install certain
updates that neither interrupt Windows services nor restart Windows.

If the status is set to Enabled, Automatic Updates will immediately install these updates
after they have been downloaded and are ready to install.

If the status is set to Disabled, such updates will not be installed immediately.

To allow Automatic Update immediate installation


1. In Group Policy Object Editor, expand Computer Configuration, expand
Administrative Templates, expand Windows Components, and then click
Windows Update.

2. In the details pane, click Allow Automatic Update immediate installation,


and set the option.

3. Click OK.

Delay Restart for Scheduled Installations


This policy specifies the amount of time for Automatic Updates to wait before proceeding
with a scheduled restart.

If the status is set to Enabled, a scheduled restart will occur the specified number of
minutes after the installation is finished.

If the status is set to Disabled or Not Configured, the default wait time is five minutes.
Deploying Microsoft Windows Server Update Services 64

To delay restart for scheduled installations


1. In Group Policy Object Editor, expand Computer Configuration, expand
Administrative Templates, expand Windows Components, and then click
Windows Update.

2. In the details pane, click Delay restart for scheduled installations, and set
the option.

3. Click OK.

Re-prompt for Restart with Scheduled Installations


This policy specifies the amount of time for Automatic Updates to wait before prompting
the user again for a scheduled restart.

If the status is set to Enabled, a scheduled restart will occur the specified number of
minutes after the previous prompt for restart was postponed.

If the status is set to Disabled or Not Configured, the default interval is 10 minutes.

To re-prompt for restart with scheduled installations


1. In Group Policy Object Editor, expand Computer Configuration, expand
Administrative Templates, expand Windows Components, and then click
Windows Update.

2. In the details pane, click Re-prompt for restart with scheduled


installations, and set the option.

3. Click OK.

Allow Non-administrators to Receive Update Notifications


This policy specifies whether logged-on non-administrative users will receive update
notifications based on the configuration settings for Automatic Updates. If Automatic
Updates is configured, by policy or locally, to notify the user either before downloading or
only before installation, these notifications will be offered to any non-administrator who
logs onto the computer.

If the status is set to Enabled, Automatic Updates will include non-administrators when
determining which logged-on user should receive notification.

If the status is set to Disabled or Not Configured, Automatic Updates will notify only
logged-on administrators.
Deploying Microsoft Windows Server Update Services 65

To allow non-administrators to receive update notifications


1. In Group Policy Object Editor, expand Computer Configuration, expand
Administrative Templates, expand Windows Components, and then click
Windows Update.

2. In the details pane, click Allow non-administrators to receive update


notifications, and set the option.

3. Click OK.

Note:
This policy setting does not allow non-administrative Terminal Services users to
restart the remote computer where they are logged in. This is because, by
default, non-administrative Terminal Services users do not have computer restart
privileges.

Remove Links and Access to Windows Update


If this setting is enabled, Automatic Updates receives updates from the WSUS server.
Users who have this policy set cannot get updates from a Windows Update Web site that
you have not approved. If this policy is not enabled, the Windows Update icon remains
on the Start menu for local administrators to visit the Windows Update Web site. Local
administrative users can use it to install unapproved software from the public Windows
Update Web site. This happens even if you have specified that Automatic Updates must
get approved updates from your WSUS server.

To remove links and access to Windows Update


1. In Group Policy Object Editor, expand User Configuration, expand
Administrative Templates, and then click Start Menu and Taskbar.

2. In the details pane, click Remove links and access to Windows Update,
and set the option.

3. Click OK.

Configure Automatic Updates in a Non–Active Directory


Environment
In a non-Active Directory environment, you can configure Automatic Updates by using
any of the following methods:
Deploying Microsoft Windows Server Update Services 66

• Using Group Policy Object Editor and editing the Local Group Policy object

• Editing the registry directly by using the registry editor (Regedit.exe)

• Centrally deploying these registry entries by using System Policy in


Windows NT 4.0 style

WSUS Environment Options


The registry entries for the WSUS environment options are located in the following
subkey:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate
The keys and their value ranges are listed in the following table.

Windows Update Agent Environment Options Registry Keys

Entry Name Values Data Type

ElevateNonAdmins Range = 1|0 Reg_DWORD

1 = Users in the Users


security group are allowed to
approve or disapprove
updates.

0 = Only users in the


Administrators user group can
approve or disapprove
updates.

TargetGroup Name of the computer group Reg_String


to which the computer
belongs, used to implement
client-side targeting—for
example, "TestServers." This
policy is paired with
TargetGroupEnabled.

TargetGroupEnabled Range = 1|0 Reg_DWORD

1 = Use client-side targeting.

0 = Do not use client-side


targeting. This policy is paired
with TargetGroup.
Deploying Microsoft Windows Server Update Services 67

Entry Name Values Data Type

WUServer HTTP(S) URL of the WSUS Reg_String


server used by Automatic
Updates and (by default) API
callers. This policy is paired
with WUStatusServer; both
must be set to the same value
in order for them to be valid.

WUStatusServer The HTTP(S) URL of the Reg_String


server to which reporting
information will be sent for
client computers that use the
WSUS server configured by
the WUServer key. This policy
is paired with WUServer; both
must be set to the same value
in order for them to be valid.

Automatic Update Configuration Options


The registry entries for the Automatic Update configuration options are located in the
following subkey:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate\A
U

The keys and their value ranges are listed in the following table.
Deploying Microsoft Windows Server Update Services 68

Automatic Updates Configuration Registry Keys

Entry Name Value Range and Meanings Data Type

AUOptions Range = 2|3|4|5 Reg_DWORD

2 = Notify before download.

3 = Automatically download
and notify of installation.

4 = Automatic download and


scheduled installation. (Only
valid if values exist for
ScheduledInstallDay and
ScheduledInstallTime.)

5 = Automatic Updates is
required, but end users can
configure it.

AutoInstallMinorUpdates Range = 0|1 Reg_DWORD

0 = Treat minor updates like


other updates.

1 = Silently install minor


updates.

DetectionFrequency Range=n; where n=time in Reg_DWORD


hours (1-22).

Time between detection cycles.

DetectionFrequencyEnabled Range = 0|1 Reg_DWORD

1 = Enable
DetectionFrequency.

0 = Disable custom
DetectionFrequency (use
default value of 22 hours).
Deploying Microsoft Windows Server Update Services 69

Entry Name Value Range and Meanings Data Type

NoAutoRebootWithLoggedOnUsers Range = 0|1; Reg_DWORD

1 = Logged-on user gets to


choose whether or not to
restart his or her computer.

0 = Automatic Updates notifies


user that the computer will
restart in 5 minutes.

NoAutoUpdate Range = 0|1 Reg_DWORD


0 = Enable Automatic Updates.

1 = Disable Automatic Updates.

RebootRelaunchTimeout Range=n; where n=time in Reg_DWORD


minutes (1-1440).

Time between prompting again


for a scheduled restart.

RebootRelaunchTimeoutEnabled Range = 0|1 Reg_DWORD

1 = Enable
RebootRelaunchTimeout.

0 = Disable custom
RebootRelaunchTimeout(use
default value of 10 minutes).

RebootWarningTimeout Range=n; where n=time in Reg_DWORD


minutes (1-30).

Length, in minutes, of the


restart warning countdown after
installing updates with a
deadline or scheduled updates.

RebootWarningTimeoutEnabled Range = 0|1 Reg_DWORD

1 = Enable
RebootWarningTimeout.

0 = Disable custom
RebootWarningTimeout (use
default value of 5 minutes).
Deploying Microsoft Windows Server Update Services 70

Entry Name Value Range and Meanings Data Type

RescheduleWaitTime Range=n; where n=time in Reg_DWORD


minutes (1-60).

Time, in minutes, that


Automatic Updates should wait
at startup before applying
updates from a missed
scheduled installation time.

Note that this policy applies


only to scheduled installations,
not deadlines. Updates whose
deadlines have expired should
always be installed as soon as
possible.

RescheduleWaitTimeEnabled Range = 0|1 Reg_DWORD

1 = Enable
RescheduleWaitTime

0 = Disable
RescheduleWaitTime(attempt
the missed installation during
the next scheduled installation
time).

ScheduledInstallDay Range = 0|1|2|3|4|5|6|7 Reg_DWORD

0 = Every day.

1 through 7 = The days of the


week from Sunday (1) to
Saturday (7).

(Only valid if AUOptions


equals 4.)

ScheduledInstallTime Range = n; where n = the time Reg_DWORD


of day in 24-hour format (0-23).

UseWUServer The WUServer value is not Reg_DWORD


respected unless this key is
set.
Deploying Microsoft Windows Server Update Services 71

Manipulate Automatic Updates Behavior


Using Command-line Options
There are two documented command-line options used for manipulating Automatic
Updates behavior. These options are meant to be run from a command prompt. They are
helpful for testing and troubleshooting client computers. For comprehensive
troubleshooting information for problems with both the WSUS server and client
computers, see "Microsoft Windows Server Update Services Operations Guide."

Detectnow Option
Because waiting for detection to start can be a time-consuming process, an option has
been added to allow you to initiate detection right away. On one of the computers with the
new Automatic Update client installed, run the following command at the command
prompt:

wuauclt.exe /detectnow

Resetauthorization Option
WSUS uses a cookie on client computers to store various types of information, including
computer group membership when client-side targeting is used. By default this cookie
expires an hour after WSUS creates it. If you are using client-side targeting and change
group membership, use this option in combination with detectnow to expire the cookie,
initiate detection, and have WSUS update computer group membership.

Note that when combining parameters, you can use them only in the order specified as
follows:

wuauclt.exe /resetauthorization /detectnow

Set Up a Disconnected Network (Import


and Export Updates)
Managing WSUS on a disconnected network involves exporting updates and metadata
from a WSUS server on a connected network and then importing all that information into
the WSUS server on the disconnected network. There is a conceptual discussion of why
this might be useful in the "Networks Disconnected from the Internet" section in Choose a
Type of Deployment earlier in this guide.
Deploying Microsoft Windows Server Update Services 72

Note:
You cannot import updates to a server that is being centrally managed. WSUS
servers on disconnected networks are always autonomously managed.

There are three steps to accomplishing an import and export. First, make sure advanced
synchronization options for the express installation files feature and languages on the
export server match the settings on the import server. This ensures that you collect the
type of updates you intend to distribute. For example, if you did not select the option for
express installation files on the export server, but did have the express installation file
option selected on the import server, you would not be able to distribute updates by using
express installation files, because none were initially collected on the export server. A
mismatch of language settings can have a similar effect. You do not have to concern
yourself with matching settings for schedule, products and classifications, source, or
proxy server, since the import operation itself overcomes the need for these settings. The
setting for deferred download of updates has no effect on the import server. If you are
using the option for deferred downloads on the export server, you must approve the
updates so they can be downloaded prior to taking the next step, which is migrating
updates to the import server.

Second, copy updates from the file system of the export server to the file system of the
import server. By default, updates are stored in the following folder:

WSUSInstallationDrive:\WSUS\WSUSContent\

You can use the Windows Backup Utility or whatever backup software your organization
is familiar with to copy the files. When you copy files to the import server, you must
maintain the folder structure for all folders under \WSUSContent. Make sure that the
updates appear in the folder on the import server that has been designated to store
updates; this designation is typically made during the setup process. You should also
consider using an incremental backup system to limit the amount of data you need to
move each time you refresh the server on the disconnected network.

Third, export update metadata from the database on the export server, and import it into
the database on the import server. You accomplish the metadata import and export by
using the command-line utility WSUSutil.exe mentioned in Migration Command-line Tool.
You can find WSUSutil.exe in the tools subfolder where you installed WSUS. You must be
a member of the local Administrators group on the WSUS server to export or import
metadata; both operations can only be run from the WSUS server itself. You can only run
WSUSutil.exe on a 32-bit platform.

You should copy updates to the file system of the import server before you import
metadata. If WSUS finds metadata for an update that is not in the file system, the WSUS
console shows that the update failed to be downloaded. This type of problem can be
Deploying Microsoft Windows Server Update Services 73

fixed by copying the update onto the file system of the import server and then again
attempting to deploy the update.

Although you can use incremental backups to move update files onto the import server,
you cannot move update metadata piecemeal. WSUSutil.exe exports all the metadata in
the WSUS database during the export operation.

In this guide

• Step 1 Import and Export: Matching Advanced Options

• Step 2 Import and Export: Copying Updates from File System

• Step 3 Import and Export: Copying Metadata from Database

Step 2 Import and Export: Copying Updates


from File System
Copy updates from the file system of the export server to the file system of the import
server. These procedures use the Windows Backup or Restore Wizard, but you can use
any utility you like. The object is to copy updates from the file system on the export server
to the files system of the import server.

Important:
The initial settings for access control lists differ between Windows 2000 Server
and Windows Server 2003. If you are copying content from Windows 2000
Server to Windows Server 2003, you have to manually add the Network Service
group to the access control list for the folder where updates are stored. Give the
Network Service group Full Control.

To back up updates from file system of export server to a file


1. On your export WSUS server, click Start, and then click Run.

2. In the Run dialog box, type ntbackup. The Backup or Restore Wizard starts
by default, unless it is disabled. You can use this wizard or click the link to work in
Advanced Mode and use the following steps.

3. Click the Backup tab, and then specify the folder where updates are stored
on the export server. By default, WSUS stores updates at
WSUSInstallationDrive:\WSUS\WSUSContent\.

4. In Backup media or file name, type a path and file name for the backup
(.bkf) file.
Deploying Microsoft Windows Server Update Services 74

5. Click Start Backup. The Backup Job Information dialog box appears.

6. Click Advanced. Under Backup Type, click Incremental.

7. From the Backup Job Information dialog box, click Start Backup to start
the backup operation.

8. Move the backup file you just created to the import server.

To restore updates from a file to the file system of the import server
1. On your import WSUS server, click Start, and then click Run.

2. In the Run dialog box, type ntbackup. The Backup or Restore Wizard starts
by default, unless it is disabled. You can use this wizard or click the link to work in
Advanced Mode and use the following steps.

3. Click the Restore and Manage Media tab, and select the backup file you
created on the export server. If the file does not appear, right-click File, and then
click Catalog File to add the location of the file.

4. In Restore files to, click Alternate location. This option preserves the folder
structure of the updates; all folders and subfolders will appear in the folder you
designate. You must maintain the directory structure for all folders under
\WSUSContent.

5. Under Alternate location, specify the folder where updates are stored on
the import server. By default, WSUS stores updates at
WSUSInstallationDrive:\WSUS\WSUSContent\. Updates must appear in the
folder on the import server designated to hold updates; this is typically done
during installation.

6. Click Start Restore. When the Confirm Restore dialog box appears, click
OK to start the restore operation.

Step 1 Import and Export: Matching Advanced


Options
Ensure that advanced synchronization options for express installation files and languages
on the export server match the settings on the import server.
Deploying Microsoft Windows Server Update Services 75

To ensure that advanced synchronization options on export server match


settings on import server
1. In the WSUS console of the export server, click the Options tab, and then
click Advanced in the Update Files and Languages section.

2. In the Advanced Synchronization Settings dialog box, check the status of


the settings for Download express installation files and Languages options.

3. In the WSUS console of the import server, click the Options tab, and then
click Advanced in the Update Files and Languages section.

4. In the Advanced Synchronization Settings dialog box, make sure the


settings for Download express installation files and Languages options match
the selections on the export server.

For more information about these advanced synchronization options, see the topics,
"Using Express Installation Files" and "Filtering Updates," in Determine Bandwidth
Options to Use for Your Deployment earlier in this guide.

Step 3 Import and Export: Copying Metadata


from Database
Export update metadata from the database on the export server, and import it into the
database on the import server. The WSUS Setup program copies WSUSutil.exe to the file
system of the WSUS server during installation. You must be a member of the local
Administrators group on the WSUS server to export or import metadata; both operations
can only be run from the WSUS server itself.

Important:
Never import exported data from a source that you do not trust. Importing content
from a source you do not trust might compromise the security of your WSUS
server.

Note:
During the import or export process, the Update Service, the Windows NT
service that underpins the WSUS application, is shut down.

To export metadata from the database of the export server


1. At the command prompt on the export server, navigate to the folder that
contains WSUSutil.exe.

2. Type the following:


Deploying Microsoft Windows Server Update Services 76

wsusutil.exe export packagename logfile

For example:

wsusutil.exe export export.cab export.log

That is, WSUSutil.exe followed by the export command, the name of an export
.cab file, a space, and the name of a log file.

The package (.cab file) and log file name must be unique. WSUSutil.exe creates
these two files as it exports metadata from the WSUS database.

3. Move the export package you just created to the import server.

To import metadata to the database of the import server


1. At the command prompt on the import server, navigate to the directory that
contains WSUSutil.exe.

2. Type the following:

wsusutil.exe import packagename logfile

For example:

wsusutil.exe import export.cab import.log

That is, WSUSutil.exe followed by the import command, the name of export .cab
file created during the export operation, a space, and the name of a log file.

WSUSutil.exe imports the metadata from the export server and creates a log file
of the operation.

Note:
It can take from 3 to 4 hours for the database to validate content that has just
been imported. Please be patient.

Migrate from a SUS Server to a WSUS


Server
This section discusses migrating from a Software Update Services (SUS) server to a
Windows Server Update Services (WSUS) server. The "Windows Server Update
Services Operations Guide" includes other types of migration documentation, such as
Deploying Microsoft Windows Server Update Services 77

migrating from MSDE or WMSDE to Microsoft SQL Server, or moving the WSUS
database from one SQL server to another SQL server.

WSUS is the next iteration of SUS. Although you cannot upgrade a SUS server to a
WSUS server, there is support for migrating your approvals and updates from SUS to the
new WSUS server. This ensures that you do not have to download the same updates
twice, nor spend time approving previously approved updates. If you are using multiple
SUS servers to target updates to computers fulfilling specific roles on the network, you
can map SUS approvals to WSUS computer groups as you migrate the approvals. This
allows you to consolidate multiple SUS servers on a single WSUS server.

It is simple to introduce WSUS into your production environment. You can install WSUS
and SUS on the same computer and both will function. You can also have SUS and
WSUS environments running simultaneously on your network. However, you can never
synchronize a SUS server with a WSUS server or vice versa. Beyond the migration, the
two update solutions are completely isolated from one another. This enables you to test
WSUS in your production environment while relying on SUS to update client computers.
When WSUS testing is complete and you are comfortable with the new solution, you can
decommission SUS.

There are some limitations to SUS-to-WSUS migration. Migration is only for approvals
and updates on the SUS server. You cannot migrate anything else, such as proxy-server
or IIS settings. These types of configuration tasks must be completed independently on
the WSUS server. Also, migration is a one-way process; you cannot migrate from WSUS
back to SUS.

Also note that if approvals are created on the WSUS server before approval migration is
performed, the explicitly created approvals are overwritten by the migration of approvals.

In this guide

• Migration Command-line Tool

• Two Migration Scenarios

• Same-server Migration

• Remote Server Migration

Migration Command-line Tool


WSUSutil.exe is a command-line tool that enables you to migrate from SUS to WSUS,
among other things. You can find WSUSutil.exe in the Tools subfolder where you installed
WSUS. By default, it appears in the following location:

WSUS install drive:\Program Files\Microsoft Windows Server Update Services\Tools


Deploying Microsoft Windows Server Update Services 78

You must be a member of the local Administrators group on the WSUS server to import
approvals or content from SUS. These operations can only be run from the WSUS server
itself. You can only run WSUSutil.exe on a 32-bit platform.

SUS does not have to be running to move updates or approvals. Although WSUSutil.exe
allows you to move both approvals and updates, you are not required to migrate one, the
other, or both. WSUSutil.exe uses HTTP to get approvals and SMB to copy updates from
a remote SUS installation. To copy updates from a remote computer, this tool requires
Read share permissions on the Content folder and all its subfolders.

Two Migration Scenarios


There are two basic SUS-to-WSUS migration scenarios:.

• Installing WSUS on the SUS computer and migrating content and approvals

• Installing WSUS on a different computer and migrating content and approvals

Depending on your current SUS infrastructure and goals for WSUS, you might need to
use both of these scenarios. For example, if you have two SUS servers and want to
install WSUS on one and then consolidate the other, you would have to use steps from
both migration procedures to achieve your goal. These processes are shown in the
"Comparison of SUS to WSUS Migration Scenarios" illustration.
Deploying Microsoft Windows Server Update Services 79

Comparison of SUS to WSUS Migration Scenarios

Same-server Migration
The same-server migration procedure is a four-step process, with an optional step for
testing. If you intend to utilize the SUS server to deploy WSUS, use this process. If you
have multiple SUS servers in your organization, you can use this process in combination
with remote server migration to consolidate multiple SUS servers on the server running
WSUS.
Deploying Microsoft Windows Server Update Services 80

Step 1 Same Server Migration: Install and Configure WSUS


When installing WSUS on a computer that has SUS installed, you must install WSUS by
using a custom port. You must synchronize the WSUS server prior to migrating. Consider
using the synchronization option for deferred downloads, which is enabled by default.
Also, configure WSUS to download updates for the same number of languages that SUS
was configured to download updates. By default, WSUS is configured to download all
languages. These configurations ensure that you do not unnecessarily download updates
already on your network or in languages that you do not require.

To install and configure WSUS on the SUS computer


• Install and configure WSUS on the SUS computer. See Run WSUS Server
Setup and Configure Advanced Synchronization Options earlier in this guide for
instruction.

Step 2 Same Server Migration: Migrate Content and Approvals


You do not have to migrate both content and approvals from the SUS server. You can opt
to initially migrate content and then migrate approvals at another time, or any number of
combinations that suit your purpose.

You do have to make sure that SUS is not synchronizing before you migrate content or
approvals. Use WSUSutil.exe to migrate content and approvals from SUS to WSUS. For
more information about WSUSutil.exe, see Migration Command-line Tool earlier in this
guide.

If you intend to map SUS approvals to a WSUS computer group, first create the group on
WSUS. For step-by-step instruction, see Create Computer Groups for Computers earlier
in this guide.

To migrate local content and approvals from SUS and map approvals to a
custom computer group on WSUS
1. At the command prompt, navigate to the directory that contains WSUSutil.exe.

2. Type the following:

wsusutil.exe migratesus
/content PathToLocalSUSContent /approvals SUSServerName "WSUSTargetGroupName"
/log filename

For example:

wsusutil.exe migratesus /content c:\sus\content\cabs /approvals sus1 "all desktops"


Deploying Microsoft Windows Server Update Services 81

/log local_migration.log

That is, WSUSutil.exe followed by the migratesus command, a space, the /content
command-line option, a space, the location of the SUS .cab files, a space, the /approvals
command-line option, a space, the NetBIOS or fully qualified domain name (FQDN) of the
SUS server, a space, a quotation mark, the name of the target group on WSUS, another
quotation mark, a space, the /log command-line option, a space, and the name of the log file.

To migrate local content and approvals from SUS and map approvals to the All
Computers target group on WSUS
1. At the command prompt, navigate to the directory that contains
WSUSutil.exe.

2. Type the following:

wsusutil.exe migratesus
/content PathToLocalSUSContent /approvals SUSServerName /log filename

For example:

wsusutil.exe migratesus /content c:\sus\content\cabs /approvals sus1 /log


local_migration.log

To migrate only local content


1. At the command prompt, navigate to the directory that contains
WSUSutil.exe.

2. Type the following:

wsusutil.exe migratesus /content PathToLocalSUSContent /log filename

For example:

wsusutil.exe migratesus /content c:\sus\content\cabs /log


local_migration.log

To migrate only local approvals


1. At the command prompt, navigate to the directory that contains
WSUSutil.exe.

2. Type the following:

wsusutil.exe migratesus /approvals SUSServerName /log filename

For example:
Deploying Microsoft Windows Server Update Services 82

wsusutil.exe migratesus /approvals sus1 /log local_migration.log

Note:
If there are additional SUS servers in your environment and you want to
consolidate them on this WSUS server, finish this procedure and testing, and
then see the "Step 2 Remote Server Migration: Migrate Content and Approvals"
section in Remote Server Migration for instruction on migrating approvals from a
remote computer.

Step 3 Same Server Migration: Test WSUS (Optional)


Any computer that is going to connect to WSUS must have the WSUS client installed.

To deploy the WSUS client for testing


• Deploy the WSUS clients in your environment to test WSUS (optional). See
Update Automatic Updates earlier in this guide for instruction.

Step 4 Same Server Migration: Move WSUS to Port 80


Decommission the SUS server, and change the WSUS Web site from the custom port to
port 80. As the SUS clients check in with the WSUS server, they will find the WSUS Web
site and self-update to the Automatic Updates client compatible with WSUS. Note that
you do not need to make any changes to Group Policy to get the SUS clients to self-
update.

If you prefer to leave your updating solution on a port other than port 80, you can leave
WSUS on the custom 8530 port and change the client policy to point to this port on your
WSUS server. You still need to leave the virtual selfupdate directory on port 80 to allow
client computers that are not WSUS-compatible to get updated to the WSUS-compatible
client.

To decommission SUS
1. Click Start, and then click Run.

2. In the Open box, type inetmgr, and then click OK.

3. In IIS, right-click the SUS Web site, and then click Stop.

To switch WSUS to port 80


1. Click Start, and then click Run.
Deploying Microsoft Windows Server Update Services 83

2. In the Open box, type inetmgr, and then click OK.

3. In IIS, right-click the WSUS Web site, and then click Properties.

4. In the WSUS Administration Properties dialog box, change the value in


TCP port from 8530 to 80.

Note:
If you change the port number after installing WSUS, you have to create a new
shortcut on your Start menu with the new URL to access the WSUS console
from the Start menu. See Help and Support for instruction on creating shortcuts.

Remote Server Migration


The remote server migration procedure is a four-step process, with an optional step for
testing. If you intend to utilize a computer without a SUS installation to deploy WSUS, use
this process.

Remote server migration is helpful if you were using multiple SUS servers to approve
content for different types of client computers. This scenario features the ability to map
migrated SUS approvals and updates to computer groups on the WSUS server, as
depicted in the following illustration.
Deploying Microsoft Windows Server Update Services 84

Consolidating Multiple SUS Servers and Mapping Approvals to Unique Computer


Groups

Step 1 Remote Server Migration: Install and Configure WSUS


Unlike same-server migration, you do not have to concern yourself with installing WSUS
in any special way. You must, however, synchronize the WSUS server prior to migrating.
Consider using the synchronization option for deferred downloads, which is enabled by
default. Also, configure WSUS to download updates for the same number of languages
SUS was configured to download updates. By default, WSUS is configured to download
all languages. These configurations ensure that you do not unnecessarily download
updates already on your network or in languages that you do not require.

Install and configure WSUS on a computer separate from SUS


• Install and configure WSUS on a computer that does not have SUS installed.
For more information, see Run WSUS Server Setup and Configure Advanced
Synchronization Options earlier in this guide.
Deploying Microsoft Windows Server Update Services 85

Step 2 Remote Server Migration: Migrate Content and Approvals


Remote server migration requires that you share the Content folder on each SUS server
you want to migrate to the WSUS server (or use the default share to access the content
folder).

You do have to make sure that SUS is not synchronizing before you migrate content or
approvals. You do not have to migrate both content and approvals from the remote SUS
server. You can opt to initially migrate content and then migrate approvals at another
time, or any number of combinations that suit your purpose.

Use WSUSutil.exe to migrate content and approvals from SUS to WSUS. For more
information about WSUSutil.exe, see Migration Command-line Tool earlier in this guide.
If you intend to map SUS approvals to a WSUS computer group, first create the group on
WSUS. For step-by-step instruction, see Create Computer Groups for Computers earlier
in this guide.

To share remote content on SUS for migration to WSUS


1. On the SUS computer, locate the SUS content store in the file system. By
default, SUS content is stored in C:\SUS\Content\.

2. Right-click the Content folder, and then click Sharing and Security (or
Sharing, on computers running Windows 2000).

3. In the Properties dialog box for the Content folder, click Share this folder.

4. Click the Security tab, and ensure that the Everyone group has Read NTFS
permissions for the Content folder.

5. Click OK.

6. Repeat this step on each SUS server you intend to migrate.

To migrate remote content and approvals from SUS and map approvals to a
custom computer group on WSUS
1. At the command prompt, navigate to the folder that contains WSUSutil.exe.

2. Type the following:

wsusutil.exe migratesus
/content LocationOfRemoteSUSContent /approvals SUSServerName "WSUSTargetGroupName" /logfile
ame

For example:

wsusutil.exe migratesus /content \\sus1\content\cabs /approvals sus1 "all desktops" /log


Deploying Microsoft Windows Server Update Services 86

remote_migration.log

To migrate local content and approvals from SUS and map approvals to the All
Computers target group in WSUS
1. At the command prompt, navigate to the folder that contains WSUSutil.exe.

2. Type the following:

wsusutil.exe migratesus
/content LocationOfRemoteSUSContent /approvals SUSServerName /logfilena
me

For example:

wsusutil.exe migratesus /content \\sus1\content\cabs \approvals sus1 \\log


remote_migration.log

To migrate only remote content


1. At the command prompt, navigate to the folder that contains WSUSutil.exe.

2. Type the following:

wsusutil.exe migratesus
/content LocationOfRemoteSUSContent /log filename

For example:

wsusutil.exe migratesus /content \\sus1\content\cabs /approvals sus1 /log


remote_migration.log

To migrate only remote approvals


1. At the command prompt, navigate to the folder that contains WSUSutil.exe

2. Type the following:

wsusutil.exe migratesus /approvals SUSServerName /log filename

For example:

wsusutil.exe migratesus /approvals sus1 /log remote_migration.log

Step 3 Remote Server Migration: Test WSUS (Optional)


Any computer that is going to connect to WSUS must have the WSUS client. When you
installed WSUS, the client self-update feature was set up automatically by the WSUS
installer.
Deploying Microsoft Windows Server Update Services 87

To deploy the WSUS client software for testing


• Deploy the WSUS client in your environment to test WSUS (optional). See
Update Automatic Updates earlier in this guide for instruction.

Step 4 Remote Server Migration: Point SUS Clients to WSUS


Point the SUS clients to WSUS. As the SUS clients check in with the WSUS server, they
will find the WSUS Web site and self-update to the WSUS client.

To point SUS clients to WSUS


• Use Group Policy or registry settings to point SUS clients to WSUS. See
Determine a Method to Configure Automatic Updates Clients earlier in this guide
for instruction.

Appendix A: Unattended Installation


You can use command-line parameters to run WSUS Setup in unattended mode. When
running this way, WSUS Setup does not display a user interface (UI). If you need to
troubleshoot the setup process, use the log files, which you can find at the following
location:

WSUSInstallationDrive:\Program Files\Microsoft Windows Server Update


Services\LogFiles\

Use command-line parameters from a command prompt.

Type the following command:

WSUSSetup.exe command-line parameter /v" property="value" "

where command-line parameter is a command-line parameter from the WSUS Setup


command-line parameters table, where property is a property from the WSUS Setup
properties table, and where value is the actual value of the property being passed to
WSUS. Both tables can be found below.

If you need to pass a value to WSUS Setup, use the command-line parameter /v along
with a property and its value. Properties are always paired with values. Microsoft
Windows Installer requires values passed using a leading and trailing space. For
example, if you wanted WSUS Setup to install the WSUS Content Directory to D:\WSUS
you would use the following syntax:
Deploying Microsoft Windows Server Update Services 88

WSUSSetup.exe /v" CONTENT_DIR= "D:\WSUS" "

If you need help with WSUSutil.exe, you can use the help command. For example, use
the following command to display the list of command-line parameters:

WSUSSetup.exe help

WSUS Setup accepts the following command-line parameters.

WSUS Setup Command-line Parameters

Option Description

/q Perform silent installation.

/u Uninstall the product. Also uninstalls the


WMSDE instance if it is installed.

/d Use the existing database server (the


SQL_INSTANCE property will define the
instance to use).

/o Overwrite the existing database.

/? Display command-line Help

/v Passes specified values to the Windows


Installer package (.msi file). The property
Name value pairs should conform to the
format specified by Windows Installer. The
properties should be enclosed in quotation
marks with a leading and trailing space.

/f Install WSUS in a special mode designed to


be used with remote SQL. This option is
used to set up the front-end of the WSUS
installation, which includes IIS and the
update storage location. For more
information about remote SQL, see
Appendix C: Remote SQL.

/b Install WSUS in a special mode designed to


be used with remote SQL. This option is
used to set up the database on the back-end
SQL server. For more information about
remote SQL, see Appendix C: Remote SQL.
Deploying Microsoft Windows Server Update Services 89

Option Description

/l This option used in combination with a


language variable allows you to force the
setup wizard to use a different language
than the one detected as the default. Use a
colon followed by a language variable from
the Language Variables table below to set
the language.

/g Use this option to perform an upgrade from


the RC1 version of WSUS.

Use the following properties to configure WSUS by using the command-line parameter /v.

WSUS Setup Properties

Windows Installer Property Description

CONTENT_DIR The directory where content will be stored. Must


be an NTFS drive and can be a non-local
mapped network drive.

Default is
WSUSInstallationDrive:\WSUS\WSUSContent,
where WSUSInstallationDrive is the local drive
with largest free space.

CONTENT_LOCAL If set to "1" the .cab files will be stored locally


(this is the default).

If set to "0" the client computers will be


redirected to the Microsoft Update server for
downloading the .cab files.

WEBSITE If set to "0" or not present, the default Web site


on the IIS sever will be used (default).

If set to "1" the "Windows Server Update


Services Administration" site will be created.

INSTANCE_NAME The name of the SQL Server instance to be


used. If an existing instance is not present, the
default is "WSUS."
Deploying Microsoft Windows Server Update Services 90

Windows Installer Property Description

WMSDE_DIR The directory where WMSDE database will be


stored. The directory must be on an NTFS
drive.

The default is drive:\WSUS, where drive is the


local drive with largest free space.

RETAIN_DATA This option is used during uninstallation to


define what data should be left.

RETAIN_DATA=0 - Delete everything.


RETAIN_DATA=1 – Leave the database.

RETAIN_DATA=2 – Leave logs.

RETAIN_DATA=3 - Leave the database and


logs.

RETAIN_DATA=4 – Leave content.

RETAIN_DATA=5 - Leave the database and


content.

RETAIN_DATA=6 – Leave logs and content.

RETAIN_DATA=7 - Leave everything (default).

Use the following properties in combination with the /l option.

Language Variables

Variable Language name

CHS Simplified Chinese

CHT Traditional Chinese

CSY Czech

DEU German

ENU English

ESN Spanish

FRA French

HUN Hungarian
Deploying Microsoft Windows Server Update Services 91

Variable Language name

ITA Italian

JPN Japanese

KOR Korean

NLD Dutch

PLK Polish

PTB Portuguese-Brazil

PTG Portuguese-Portugal

RUS Russian

SVE Swedish

TRK Turkish

Appendix B: Install MSDE on Windows


2000
If you are using Windows 2000 for WSUS and do not have access to Microsoft SQL
Server 2000, you should install Microsoft SQL Server 2000 Desktop Engine (MSDE) prior
to running WSUS Setup. This section gives step-by-step instructions for this task.

Installing MSDE on Windows 2000 Server is a four-step process. First, you must
download and expand the MSDE archive to a folder on your WSUS server. Next, use a
command prompt and command-line options to run MSDE Setup, set the sa password,
and assign WSUS as the instance name. Then, when the MSDE installation finishes, you
should verify that the WSUS instance is running as a Windows NT service. Finally, you
must add a security patch to MSDE to protect your WSUS server.
Deploying Microsoft Windows Server Update Services 92

Step 1: Download and Expand the MSDE


Archive
You must download and expand the MSDE archive to a folder on your WSUS server. To
obtain SQL Server 2000 Desktop Engine (MSDE 2000) Release A, go to the Download
Center at http://go.microsoft.com/fwlink/?LinkId=35713.

To expand the MSDE archive


1. Double-click the MSDE archive (MSDE2000a.exe).

2. Read the license agreement and click I Agree.


3. In the Installation Folder box, type a path, and then click Finish. For
example, type C:\MSDE2000. The MSDE archive copies MSDE installation files
to the installation folder you specify.

Installation Folder Page


Deploying Microsoft Windows Server Update Services 93

Step 2: Install MSDE


Use a command prompt and command-line options to run MSDE Setup, set the sa
password, and assign WSUS as the instance name. When the MSDE installation
finishes, you should verify the WSUS instance is running as an NT service.

To install MSDE, set the sa password, and assign an instance name


1. At the command prompt, navigate to the MSDE installation folder specified in
“Step 1: Download and expand the MSDE archive.”

2. Type the following:

setup sapwd="password" instancename="WSUS"

where password is a strong password for the sa account on this instance of


MSDE. This command launches the MSDE setup program, sets the sa
password, and names this instance of MSDE to WSUS.

To verify that the WSUS instance of MSDE installed


1. Click Start, and then click Run.

2. In the Open box, type services.msc, and then click OK.

3. Scroll down the list of services, and verify that a service named
MSSQL$WSUS exists.

MSSQL$WSUS
Deploying Microsoft Windows Server Update Services 94

Step 3: Update MSDE


You must download and install the security patch described in the bulletin "MS03-031:
Cumulative Security Patch for SQL Server." To obtain SQL Server 2000 (32-bit) Security
Patch MS03-031, go to the Download Center at http://go.microsoft.com/fwlink/?
LinkId=37271.

To read bulletin MS03-031, go to the Microsoft Help and Support Web site at
http://go.microsoft.com/fwlink/?LinkId=37270.

To install SQL Server 2000 (32-bit) Security Patch MS03-031


1. Double-click SQL Server 2000 (32-bit) Security Patch MS03-031 (SQL2000-
KB815495-8.00.0818-ENU.exe).

2. On the Welcome page, click Next.

3. Read the End User License Agreement, click I accept the license terms and
conditions, and then click Next.

4. On the Instance to Update page, use the Instance box to select the WSUS
instance, and then click Next.
Deploying Microsoft Windows Server Update Services 95

Instance to Update Page

5. On the Authentication Mode page, select Windows Authentication, and


then click Next.

Authentication Mode Page


Deploying Microsoft Windows Server Update Services 96

Appendix C: Remote SQL


WSUS offers limited support for running database software on a computer that is
separate from the computer where the rest of WSUS is installed. This section offers step-
by-step instructions for how to install WSUS in this configuration.

Setting up WSUS for remote SQL is a three-step process. First, run WSUS Setup on the
front-end computer, which for WSUS is always the server running IIS in the remote SQL
pair. Next, go to the back-end computer, which for WSUS is always the server running
the database in the remote SQL pair, and then set up the WSUS database and configure
permissions. Finally, configure the front-end computer to use the database on the back-
end computer, and then manually start the Update Service.

Remote SQL Limitations


• You cannot use Windows 2000 Server on the front-end computer in a remote
SQL pair.

• You cannot use a server configured as a domain controller for either the front end
or the back end of the remote SQL pair.

• You cannot use WMSDE or MSDE for database software on the back-end
computer.

• Both the front-end and the back-end computers must be joined to an Active
Directory domain.

Database Requirements
You can use database software that is 100-percent compatible with Microsoft SQL and
not listed in "Remote SQL limitations. " Microsoft SQL Server 2000 has been tested
exclusively for use with remote SQL.

WSUS requires SQL Server 2000 with Service Pack 3a. If you use the full version of SQL
Server, the SQL server administrator should first verify that the nested triggers option on
the SQL server is turned on. Do this before setting up the WSUS database.

You cannot use SQL authentication. WSUS only supports Windows authentication.
WSUS Setup creates a database named SUSDB. For more information about what is
Deploying Microsoft Windows Server Update Services 97

stored in the WSUS database or how it functions, see Choose the Database Used for
WSUS earlier in this guide.

Step 1: Install WSUS on the Front-end


Computer
Install WSUS on the front-end computer. This server will need access to the Internet or
another WSUS server to obtain updates. You need to prepare this computer with all the
prerequisites for a normal WSUS installation, except for database software.

You run WSUS Setup from a command line, using the /f command-line option. This
option installs WSUS as the front end of a remote SQL pair, skipping the database setup
portion of the WSUS setup process and not starting the Update Service after installation
is complete. Database setup is accomplished in Step 2: Install WSUS on the Back-end
Computer. Manually starting the Update Service is one of the tasks you accomplish in
Step 3: Configure the Front-end Computer to use the Back-end Computer.

During this installation, be sure to note where you intend to store updates. Where you
store updates dictates how you set up the back-end computer in Step 2: Install WSUS on
the Back-end Computer.

For more information about hardware, hard disk, and software requirements, see Install
the WSUS Server.

To install WSUS on the front-end computer


1. At the command prompt, navigate to the folder containing the WSUS Setup
program, and type:

WSUSSetup.exe /f

2. On the Welcome page of the wizard, click Next.

3. Read the terms of the license agreement carefully, click I accept the terms of
the License Agreement, and then click Next.

4. On the Select Update Source page, you can specify where client computers get
updates. If you click Store updates locally, updates are stored in WSUS and you
can select a location in the file system to store them. If you do not store updates
locally, client computers connect to Microsoft Update to get approved updates.

To read more about update storage options, see Determine Where to Store Updates
earlier in this guide. Make your selections, and click Next.

If you click Store updates locally, make a note of the string used to identify the
Deploying Microsoft Windows Server Update Services 98

location for local update storage. You must use the same string when setting up the
back-end computer.

Select Update Source Page

5. On the Web Site Selection page, you specify the Web site that WSUS uses. For
more information, see Install and Configure IIS earlier in this guide. Note two
important URLS: the URL to point client computers to WSUS and the URL for the
WSUS console where you configure WSUS.

Web Site Selection Page


Deploying Microsoft Windows Server Update Services 99

6. On the Ready to Install Windows Server Update Services page, click Next.

Ready to Install Windows Server Update Services Page


Deploying Microsoft Windows Server Update Services 100

7. If the final page confirms that WSUS installation was successfully completed,
click Finish.

Step 2: Install WSUS on the Back-end


Computer
Install WSUS on the back-end computer. This server will need database software
installed. You do not need to have IIS installed on the back-end computer. Except for IIS,
all other prerequisites for a normal WSUS installation are required.

The steps for configuring permissions on the back-end computer differ, depending upon
whether you are using Windows 2000 Server or Windows Server 2003. Both procedures
are listed here. Make sure you use the right steps for the operating system you are using.

You must run WSUS Setup from a command line so that you can use command-line
options. Use the /b command-line option. In addition to running Setup with a command-
line option, you must run a SQL script to identify how update storage is being managed
on the front-end computer.
Deploying Microsoft Windows Server Update Services 101
These options install WSUS as the back end of a remote SQL pair, skipping most of the
installation except for the database setup portion. After installation is complete, you must
configure permissions on the back-end computer.

For more information about hardware, hard disk, and software requirements, see Install
the WSUS Server.

Step 2 contains the following procedures:

• Install WSUS on the back-end computer

• Run a SQL script to identify how update storage is being managed on the front-
end computer

• Configure permissions on the back-end computer

To install WSUS on the back-end computer


1. At the command prompt, navigate to the folder containing the WSUS Setup
program, and type the following command:

WSUSSetup.exe /b

2. On the Welcome page of the wizard, click Next.

3. Read the terms of the license agreement carefully, click I accept the terms of
the License Agreement, and then click Next.

4. On the Database Options page, you select the software used to manage the
WSUS database. You must click Use an existing database server on this
computer. Select the instance name from SQL instance name box, and then click
Next.

Database Options Page


Deploying Microsoft Windows Server Update Services 102

5. On the Connecting to SQL Server Instance page, wait to be prompted with for
a successful connection to the SQL server, and then click Next.

Connecting to SQL Server Instance Page


Deploying Microsoft Windows Server Update Services 103

6. On the Mirror Update Settings page, you specify the management role for this
WSUS server. If you want a central management topology, or if this is not the first
WSUS server on your network, enter the name of the upstream WSUS server here. If
this is the first WSUS server on your network or you want a distributed management
topology, skip this screen.

Make your selection, and then click Next. For more information about management
roles, see Choose a Management Style.

Mirror Update Settings Page


Deploying Microsoft Windows Server Update Services 104

7. On the Ready to Install Windows Server Update Services page, click Next.

8. If the final screen confirms that WSUS installation was successfully completed,
click Finish.

Once you install WSUS on the back-end computer, you must run a SQL script to identify
how update storage is being managed on the front-end computer. The syntax of the SQL
script you run depends on whether client computers are getting updates locally from the
front-end computer or are downloading updates directly from Microsoft. You established
where clients obtain updates when you installed WSUS on the front-end computer.

If you cannot remember how you configured the front-end computer, you can find out by
reading the log file located on the front-end computer here:

%programfiles%\Update Services\Logfiles\WSUSSetup_InstallDate.log

where InstallDate is the date you installed WSUS.

From this file you need the value for two keys:

• HostOnMu

• LocalContentCacheLocation
Deploying Microsoft Windows Server Update Services 105

To identify on the back-end computer how update storage is being managed on


the front-end computer
• At the command prompt, type one of the following commands, depending on
how you set up the front-end computer:

• If you chose local storage on the front-end computer, type:

"%programfiles%\update services\tools\osql\osql.exe" -
S SQLServerName -E -b -n -Q "USE SUSDB UPDATE
dbo.tbConfigurationA SET HostOnMu = '0' UPDATE
dbo.tbConfigurationB SET LocalContentCacheLocation =
N'LocalContentCacheLocation Value'"

whereSQLServerName is the name of the SQL Server instance that holds


the SUSDB database; where %programfiles% is the location of the Program
Files folder on the front-end computer; and where
LocalContentCacheLocation Value is the actual string used to identify where
in the file system of the front-end computer to store content, with
\WSUSContent appended to the end. For example, if you used C:\WSUS on
the front-end computer, you would type C:\WSUS\WSUSContent. Do not
use a network location or a UNC path. Do not add a trailing backslash (\).

• If you chose remote storage on Microsoft Update, type the following:

"%programfiles%\update services\tools\osql\osql.exe" -
S SQLServerName -E -b -n -Q "USE SUSDB UPDATE
dbo.tbConfigurationA SET HostOnMu = '1' UPDATE
dbo.tbConfigurationB SET LocalContentCacheLocation =
N'%programfiles%\Update Services\WsusContent'"

where SQLServerName is the name of the SQL Server instance on the back-
end computer; and where %programfiles% is the location of the Program
Files folder on the front-end computer.

Set Permissions on Windows Server 2003


If your back-end computer is running Windows Server 2003, use the following procedure
to set up permissions, and then see Step 3: Configure the Front-end Computer to use the
Back-end Computer.

To set permissions on the Windows Server 2003 back-end computer


1. On the back-end computer, click Start, point to Administrative Tools, and then
click Computer Management.
Deploying Microsoft Windows Server Update Services 106

2. In the tree, expand Local Users and Groups, and then click Groups.

3. In the details pane, double-click WSUS Administrators.

WSUS Administrators Group

4. In the WSUS Administrators Properties dialog box, click Add.

5. In Select Users, Computers or Groups, click Object Types.

6. In Object Types, click Computers, and then click OK.

Object Types Dialog Box


Deploying Microsoft Windows Server Update Services 107

7. In Select Users, Computers, or Groups, enter the name of the front-end


computer, and then click OK.

Select Users, Computers, or Groups Dialog Box

8. In the WSUS Administrators Properties dialog box, click OK.


Deploying Microsoft Windows Server Update Services 108

Set Permissions on Windows 2000 Server


If your back-end computer is running Windows 2000 Server, use the following procedures
to set up permissions, and then see Step 3: Configure the Front-end Computer to use the
Back-end Computer.

To create a global security group and add the front-end computer as a member
1. On a computer with Active Directory Administrative Tools installed, click
Start, point to Administrative Tools, and then click Active Directory Users and
Computers.

2. In the tree, right-click the folder in which you want to create the new group.

3. Point to New, and then click Group.

4. Type the name of the new group.

5. In Group Scope, click Global.

Global Security Group Dialog Box

6. In Group Type, click Security, and then click OK. A global security group is
Deploying Microsoft Windows Server Update Services 109

created.

7. Double-click the global security group you just created.

8. In the group properties dialog box, click the Members tab.

9. Click Add.

10. In Select Users, Contacts, or Computers, click Object Types.

11. In Object Types, click Computers, and then click OK.

12. In Enter the Object names to select (examples), enter the name of the
front-end computer, and then click OK.

13. In the global security group properties dialog box, click OK.

To set permissions on the Windows 2000 Server back-end computer


1. On the back-end computer, click Start, point to Administrative Tools, and then
click Computer Management.

2. In the tree, expand Local Users and Groups, and then click Groups.

3. In the details pane, double-click WSUS Administrators.

4. In the WSUS Administrators Properties dialog box, click Add.

5. In Select Users or Groups, select your domain from the Look in drop-down list.

Select Users or Groups Dialog Box


Deploying Microsoft Windows Server Update Services 110

6. Double-click the global security group you created in the preceding procedure,
and then click OK.

7. In the WSUS Administrators Properties dialog box, click OK.

Step 3: Configure the Front-end Computer to


Use the Back-end Computer
You configure the front-end computer to use the database on the back-end computer by
editing the registry. With the registry changed, you manually start the Update Service.
You are then ready to configure WSUS using the WSUS console on the front end.

Step 3 contains the following procedures:

• Configure the front-end computer to use the database.

• Manually start the Update Service.


Deploying Microsoft Windows Server Update Services 111

To configure the front-end computer to use the database


1. On the front-end computer, click Start, and then click Run.

2. In the Open box, type regedit, and then click OK.

3. In Registry Editor, navigate to the following registry key:

HKLM\SOFTWARE\Microsoft\Update Services\Server\Setup\

4. In the details pane, double-click the SQLServerName key.

5. In Value data, type the name of the back-end computer, and then click OK.
When entering data, use the syntax servername\instance. If your server uses the
default instance, you can omit the instance name—for example, servername.

To manually start the Update Service


1. Click Start, and then click Run.

2. In the Open box, type services.msc, and then click OK.

3. In the details pane, double-click the Update Services service, and then click
Start.

Appendix D: Security Settings


This appendix lists the recommended security settings for WSUS. The recommendations
are categorized into settings for Windows Server 2003, IIS 6.0, and SQL Server 2000.

Windows Server 2003


The following are security recommendations for Windows Server 2003 with WSUS.

Audit Policy
Enable audit events to ensure that adequate logs are collected for system activities.

Audit Policy Settings


Deploying Microsoft Windows Server Update Services 112

Option Security Setting Setting Rationale

Audit account logon events Success, Failure Auditing for successful and
failed logon events provides
useful data regarding
password brute-forcing
attempts.

Audit account management Success, Failure Auditing for successful and


failed account management
events tracks management
activities.

Audit directory service No Auditing This is only important for


access domain controllers running the
Active Directory service.

Audit logon events Success, Failure Auditing for successful and


failed logon events provides
useful data regarding
password brute-forcing
attempts.

Audit object access No Auditing Auditing object access is


unnecessary and creates
many unnecessary logs for
WSUS activity.

Audit policy change Success, Failure Auditing for successful and


failed policy changes tracks
management activities.

Audit privilege use Success, Failure Auditing for successful and


failed privilege use tracks
administrator activities.

Audit process tracking No Auditing Process-tracking events are


unnecessary for WSUS
implementations.

Audit system events Success, Failure Auditing for successful and


failed system events tracks
system activities.
Deploying Microsoft Windows Server Update Services 113

Security Options
Configure Windows Server 2003 security settings to help ensure optional security and
functionality.

Security Options Settings

Option Security Setting Setting Rationale

Accounts: Administrator Enabled Because it is necessary to


account status have an administrator, the
administrator account should
be enabled for authorized
users.

Accounts: Guest account Disabled Because it is risky to have


Status guest accounts, the guest
account should be disabled
unless specifically required.

Accounts: Limit local Enabled Accounts with blank


account use of blank passwords significantly
passwords to console logon increase the likelihood of
only network-based attacks.

Accounts: Rename Not Defined Renaming the administrator


administrator account account forces a malicious
individual to guess both the
account name and
password. Note that even
though the account can be
renamed, it still uses the
same well known SID, and
there are tools available to
quickly identify this and
provide the name.
Deploying Microsoft Windows Server Update Services 114

Option Security Setting Setting Rationale

Accounts: Rename Guest Not Defined Because the guest account


account is disabled by default, and
should never be enabled,
renaming the account is not
important. However, if an
organization decides to
enable the Guest account
and use it, it should be
renamed beforehand.

Audit: Audit the access of Enabled This setting needs to be


global system objects enabled for auditing to take
place in the Event Viewer.
The auditing setting can be
set to Not Defined, Success
or Failure in the Event View.

Audit: audit the use of Enabled For security reasons, this


Backup and Restore option should be enabled so
privilege that auditors will be aware of
users creating backups of
potentially sensitive data.

Audit: Shut down system Disabled Enabling this option shuts


immediately if unable to log down the system if it is
security audits unable to log audits. This can
help prevent missed audit
events. Enabling very large
log files on a separate
partition helps mitigate this.

Devices: Allow undock Disabled Disabling this option ensures


without having to log on that only authenticated users
can dock and undock
computers.

Devices: Allowed to format Administrators This option is not typically


and eject removable media useful for desktop images.
Deploying Microsoft Windows Server Update Services 115

Option Security Setting Setting Rationale

Devices: Prevent users from Enabled Because the Windows GDI


installing printer drivers system runs in kernel space,
allowing a user to install a
printer driver could lead to
elevated privileges.

Devices: Restrict CD-ROM Enabled Enabling this option prevents


access to locally logged-on remote users from accessing
user only the local CD-ROM, which
may contain sensitive
information.

Devices: Restrict floppy Enabled In situations where the


access to locally logged-on server is physically secured
user only and password authentication
is required by the Recover
Console, this option can be
enabled to facilitate system
recovery.

Devices: Unsigned driver Warn but allow installation Most driver software is
installation behavior signed. Administrators
should not install unsigned
drivers unless the origin and
authenticity can be verified
and the software has been
thoroughly tested in a lab
environment first. Since only
senior administrators will be
working on these systems, it
is safe to leave this to their
discretion.

Domain controller: Allow Disabled The ability to schedule tasks


server operators to schedule should be limited to
tasks administrators only.

Domain controller: LDAP Not Defined This option applies only to


server signing requirements domain controllers.
Deploying Microsoft Windows Server Update Services 116

Option Security Setting Setting Rationale

Domain controller: Refuse Disabled Enabling this option allows


machine account password machine accounts to
changes automatically change their
passwords.

Domain member: Digitally Disabled If the domain controller is


encrypt or sign secure known to support encryption
channel data (always) of the secure channel, this
option can be enabled to
protect against local network
attacks.

Domain member: Digitally Enabled Enabling this option provides


encrypt secure channel data the most flexibility while
(when possible) enabling the highest security
when the server supports it.

Domain member: Digitally Enabled Enabling this option provides


sign secure channel data the most flexibility while
(when possible) enabling the highest security
when the server supports it.

Domain member: Disable Disabled Disabling this option allows


machine account password machine accounts to
changes automatically change their
passwords.

Domain member: Maximum 30 days Less-frequently changed


machine account password passwords are easier to
age break than passwords that
are changed more frequently.

Domain member: Require Enabled Enabling this option sets


strong (Windows 2000 or strong session keys for all
later) session key computers running Windows
2000 or later.
Deploying Microsoft Windows Server Update Services 117

Option Security Setting Setting Rationale

Interactive logon: Do not Enabled Hiding the last user name


display last user name should be enabled,
especially when the
administrator user account is
renamed. This helps prevent
a passerby from determining
account names.

Interactive logon: Do not Disabled The CTRL+ALT+DEL


require CTRL+ALT+DEL sequence is intercepted at a
level lower than user-mode
programs are allowed to
hook. Requiring this
sequence at logon is a
security feature designed to
prevent a Trojan Horse
program masquerading as
the Windows logon from
capturing users' passwords.

Interactive logon: Message [provide legal text] An appropriate legal and


text for users attempting to warning message should be
log on displayed according to the
Corporate Security Policy.

interactive logon: Message [provide legal title text] An appropriate legal and
title for users attempting to warning message should be
log on displayed according to the
Corporate Security Policy.
Deploying Microsoft Windows Server Update Services 118

Option Security Setting Setting Rationale

Interactive logon: Number of 10 logons This option is usually only


previous logons to cache (in appropriate for laptops that
case domain controller is not might be disconnected from
available) their domain. It also presents
a security risk for some types
of servers, such as
application servers. If a
server is compromised, and
domain logons are cached,
the attacker may be able to
use this locally stored
information to gain domain-
level credentials.

Interactive logon: Prompt 14 days Password prompts should be


user to change password aligned according to the
before expiration Corporate Security Policy.

Interactive logon: Require Enabled Enabling this option allows a


Domain Controller domain controller account to
authentication to unlock unlock any workstation. This
workstation should only be allowed for
the local Administrator
account on the computer.

Interactive logon: Require Not Defined If this system will not be


smart card using smart cards, this option
is not necessary.

Interactive logon: Smart card Not Defined If this system will not be
removal behavior using smart cards, this option
is not necessary.

Microsoft network client: Disabled For systems communicating


Digitally sign to servers that do not support
communications (always) SMB signing, this option
should be disabled.
However, if packet
authenticity is required, this
can be enabled.
Deploying Microsoft Windows Server Update Services 119

Option Security Setting Setting Rationale

Microsoft network client: Enabled For systems communicating


Digitally sign to servers that do support
communications (if server SMB signing, this option
agrees) should be enabled.

Microsoft network client: Disabled If this option is enabled, then


Send unencrypted password a third-party SMB server
to third-party SMB servers could negotiate a dialect that
does not support
cryptographic functions.
Authentication would be
performed using plain-text
passwords.

Microsoft network server: 15 minutes This should be set


Amount of idle time required appropriately for the end-
before suspending session user system such that idle
connections do not linger,
consuming resources.

Microsoft network server: Disabled For systems communicating


Digitally sign to servers that do not support
communications (always) SMB signing, this option
should be disabled.
However, if packet
authenticity is required, this
can be enabled.

Microsoft network server: Enabled For systems communicating


Digitally sign to servers that do not support
communications (if client SMB signing, this option
agrees) should be disabled.
However, if packet
authenticity is required, this
can be enabled.

Microsoft network server: Enabled Enabling this option prevents


Disconnect clients when users from logging on after
logon hours expire authorized hours.
Deploying Microsoft Windows Server Update Services 120

Option Security Setting Setting Rationale

Network access: Allow Disabled This option is highly


anonymous SID/Name important for securing
translation Windows networking.
Disabling it severely restricts
the abilities granted to a user
connecting with a Null
session.

Network access: Do not Enabled This option is highly


allow anonymous important for securing
enumeration of SAM Windows networking.
accounts Enabling it severely restricts
the abilities granted to a user
connecting with a Null
session. Because “Everyone”
is no longer in the
anonymous user’s token,
access to IPC$ is disallowed.
Pipes that are explicitly set to
allow anonymous are
inaccessible because the
SMB tree connection to this
share fails.

Network access: Do not Enabled This option is highly


allow anonymous important for securing
enumeration of SAM Windows networking.
accounts and shares Enabling it severely restricts
the abilities granted to a user
connecting with a Null
session. Because “Everyone”
is no longer in the
anonymous user’s token,
access to IPC$ is disallowed.
Pipes that are explicitly set to
allow anonymous are
inaccessible because the
SMB tree connection to this
share fails.
Deploying Microsoft Windows Server Update Services 121

Option Security Setting Setting Rationale

Network access: Do not Enabled Enabling this option prevents


allow storage of credentials the storage of sensitive
or .NET passports for passwords in the computers’
network authentication cache.

Network access: Let Disabled Anonymous users should


Everyone permissions apply have no access to
to anonymous users computers.

Network access: Named Not Defined Named pipes should be


Pipes that can be accessed restricted anonymously.
anonymously Restricting named pipes
breaks some inter-system
processes, such as network
printing.

Network access: Remotely Not Defined Registry paths should be


accessible registry paths restricted from remote
access unless for monitoring
circumstances.

Network access: Shares that None No shares should be


can be access anonymously accessed anonymously.

Network access: Sharing Guest only – local users Limit all local accounts to
and security model for local authenticate as Guest Guest privileges.
accounts

Network security: do not Enabled Enabling this feature deletes


store LAN Manager hash the weaker LAN Manager
value on next password hashes, reducing the
change likelihood of password
attacks from sniffing the
weak hash over the name or
from the local SAM database
file.

Network security: Force Enabled This option should be


logoff when logon hours enabled as part of the
expire acceptable policy.
Deploying Microsoft Windows Server Update Services 122

Option Security Setting Setting Rationale

Network security: LAN Send NTLMv2 response Sending LM is less secure


Manager authentication level only than NTLM, and should only
be enabled if the system will
communicate with computers
running Windows 95 or
Windows 98. Additionally,
use NTLMv2 only; however,
computers running
Windows 95, Windows 98, or
un-patched Windows NT4.0
will not be able to
communicate with servers
running NTLMv2.

Network security: LDAP Negotiate signing Require signing when


client signing requirements authenticating to third party
LDAP servers. This prevents
attacks against rogue LDAP
servers and clear-text
submission of passwords
over the network.

Network security: Minimum Require NTLMv2 session The NTLM hashes contain
session security for NTLM security weakness that attacks may
SSP based (including secure exploit. Enabled, these
RPC) clients requirements strengthen the
authentication algorithms for
Windows.

Network security: Minimum Require NTLMv2 session The NTLM hashes contain
session security for NTLM security weakness that attacks may
SSP based (including secure exploit. Enabled, these
RPC) servers requirements will strengthen
the authentication algorithms
for Windows.
Deploying Microsoft Windows Server Update Services 123

Option Security Setting Setting Rationale

Recovery console: Allow Disabled If automatic administrative


automatic administrative logon is enabled, then a
logon malicious user that has
console access could simply
restart the computer and
gain administrative
privileges. However, an
organization may enable this
feature if the computer is a
physically secure server,
allowing access to the
system if the administrator
password is forgotten.

Recovery console: Allow Disabled The recover console can be


floppy copy and access to all used as an attack method to
drives and all folders gain access to SAM
database files offline;
therefore, this option should
be enabled to prevent those
files from being copied to a
floppy disk.

Shutdown: Allow system to Disabled This option is used to


be shut down without having prevent users without valid
to log on accounts from shutting down
the system, and is a good
precautionary measure.
Deploying Microsoft Windows Server Update Services 124

Option Security Setting Setting Rationale

Shutdown: Clear virtual Disabled Clearing the memory


memory pagefile pagefile at shutdown can
help prevent offline analysis
of the file, which might
contain sensitive information
from system memory, such
as passwords. However, in
situations where the
computer is physically
secured, this can be enabled
to reduce time required for
system restarts.

System cryptography: Force User is prompted when the Protecting local


strong key protection for key is first used cryptographic secrets helps
user keys stored on the prevent privilege escalation
computer across the network, once
access to one system is
obtained.

System cryptography: Use Not Defined Require stronger, standard,


FIPS compliant algorithms and compliant algorithms for
for encryption, hashing, and encryption, hashing, and
signing signing.

System Objects: Default Administrators group Administrators should only


owner for objects created by have access to the created
members of the file.
Administrators group

System objects: Require Disabled Require case-sensitivity for


case insensitivity for non- non-Windows subsystems,
Windows subsystems such as UNIX passwords.
Deploying Microsoft Windows Server Update Services 125

Option Security Setting Setting Rationale

System settings: Optional Enter POSIX here only if The POSIX execution layer
subsystems expressly required has had multiple local
exploits in the past, and
should be disabled unless
required by third-party
software. It is extremely rare
for POSIX to be required by
commercial software
packages.

System settings: Use Not Defined When certificate rules are


Certificate Rules on created, enabling this option
Windows executables for enforces software restriction
Software Restriction policies policies that check a CRL to
make sure the software's
certificate and signature are
valid.

Event Log Settings


Configure Event Log settings to help ensure an adequate level of activity monitoring.

Event Log Settings

Option Security Setting Setting Rationale

Maximum application log 100489 kilobytes A large event log allows


Size administrators to store and
search for problematic and
suspicious events.

Maximum security log size 100489 kilobytes A large event log allows
administrators to store and
search for problematic and
suspicious events.

Maximum system log size 100489 kilobytes A large event log allows
administrators to store and
search for problematic and
suspicious events.
Deploying Microsoft Windows Server Update Services 126

Option Security Setting Setting Rationale

Prevent local guests group Enabled Guest accounts should not be


from accessing application able to access sensitive
log information in the event log.

Prevent local guests group Enabled Guest accounts should not be


from accessing security log able to access sensitive
information in the event log.

Prevent local guests group Enabled Guest accounts should not be


from accessing system log able to access sensitive
information in the event log.

Retain application log 7 Days After a week, logs should be


stored on a centralized log
server.

Retain security log 7 Days After a week, logs should be


stored on a centralized log
server.

Retain system log 7 Days After a week, logs should be


stored on a centralized log
server.

Retention method for As Needed Overwrite audit logs as


application log needed when log files have
filled up.

Retention method for As Needed Overwrite audit logs as


security log needed when log files have
filled up.

Retention method for As Needed Overwrite audit logs as


system log needed when log files have
filled up.

System Services
Enable only services that are required for WSUS.

Enabled Operating System Services


Deploying Microsoft Windows Server Update Services 127

Option Security Setting Setting Rationale

Alerter Disabled The alerter service is of most


use when an administrator is
logged into the network and
wants to be notified of events.
For computers running
WSUS, the service is not
necessary.

Application Management Manual This service is only necessary


when installing new
applications to the
environment with Active
Directory.

Automatic Updates Automatic This service is required in


order to support a fully
patched operating
environment.

Clipbook Disabled This service is unnecessary to


the WSUS environment.

COM+ Event System Manual The COM+ event system


might be used in the Web-
based application.

Computer Browser Automatic The computer browser


service is required on
interactive workstations.

DHCP Client Automatic DHCP is necessary to have


an IP address on the WSUS
server.

Distributed File System Disabled DFS is used for file sharing


across multiple servers, which
is not needed for WSUS.

Distributed Link Tracking Disabled This service is only


Client appropriate if a domain has
distributed link tracking
configured.
Deploying Microsoft Windows Server Update Services 128

Option Security Setting Setting Rationale

Distributed Link Tracking Disabled This service is only


Server appropriate if a domain has
distributed link tracking
configured.

Distributed Transaction Disabled This service is only


Coordinator appropriate if a domain has
distributed link tracking
configured.

DNS Client Automatic DNS is necessary for IP-


address-to-name resolution.

Event Log Automatic The Event Log service is


important for logging events
on the system and provides
critical auditing information.

File Replication Disabled This service is used for file


replication and
synchronization, which is not
necessary for WSUS.

IIS ADMIN service Automatic This service is required for


WSUS administration.

Indexing Service Manual This service is used by IIS.

Intersite Messaging Disabled This service only needs to be


enabled on domain
controllers.

Internet Connection Manual This service is required if the


Firewall / Internet local ICF firewall is being
Connection Sharing used.

IPSEC Services Automatic This service is required if


IPsec has been utilized.

Kerberos Key Distribution Disabled unless This service is enabled by


Center functioning as a domain default in order to join and
controller authenticate to Windows
Server 2003 domain
controllers.
Deploying Microsoft Windows Server Update Services 129

Option Security Setting Setting Rationale

License Logging Service Disabled This service is used on


systems where application
licensing must be tracked.

Logical Disk Manager Automatic This service is used in logical


disk management.

Logical Disk Manager Manual This service is used in logical


Administrative Service disk management.

Messenger Disabled This service is only necessary


if NetBIOS messaging is
being used.

Net Logon Automatic This service is necessary to


belong to a domain.

NetMeeting Remote Desktop Disabled NetMeeting is an application


Sharing that allows collaboration over
a network. It is used on
interactive workstations, and
should be disabled for servers
as it presents a security risk.

Network Connections Manual This service allows network


connections to be managed
centrally.

Network DDE Disabled Network DDE is a form of


interprocess communication
(IPC) across networks.
Because it opens network
shares and allows remote
access to local resources, it
should be disabled unless
explicitly needed.
Deploying Microsoft Windows Server Update Services 130

Option Security Setting Setting Rationale

Network DDE DSDM Disabled Network DDE is a form of


interprocess communication
(IPC) across networks.
Because it opens network
shares and allows remote
access to local resources, it
should be disabled unless
explicitly needed.

NTLM Security Support Manual The NTLM Security Support


Provider Provider is necessary to
authenticate users of remote
procedure call (RPC) services
that use transports such as
TCP and UDP.

Performance Logs and Alerts Manual This service is only necessary


when logs and alerts are
used.

Plug and Play Automatic Plug and Play is needed if the


system uses Plug-and-Play
hardware devices.

Print Spooler Disabled This service is necessary if


the system is used for
printing.

Protected Storage Automatic This service must be enabled


because the IIS Admin
service depends on it.

Remote Access Auto Disabled Enable this service only for


Connection Manager RAS servers.

Remote Access Connection Disabled Enable this service only for


Manager RAS servers.

Remote Procedure Call Automatic This service is required for


(RPC) RPC communications.

Remote Procedure Call Manual This service is required for


(RPC) Locator RPC communications.
Deploying Microsoft Windows Server Update Services 131

Option Security Setting Setting Rationale

Remote Registry Manual Remote Registry is a key


target for attackers, viruses,
and worms, and should be set
to manual unless otherwise
needed, where the server can
enable it.

Removable Storage Manual For a dynamic server, this


service is necessary.

Routing and Remote Access Disabled Enable this service only for
RAS servers.

Security Accounts Manager Automatic This service should be


enabled, as it manages local
accounts.

Server Automatic This service should be


enabled or disabled as
necessary. The service
supports file, print, and
named-pipe sharing over the
network for this computer.

Smart Card Manual Because users will not be


using smart cards for two-
factor logon authentication,
this service is unnecessary
and should be disabled or set
to manual.

System Event Notification Automatic This service is needed for


COM+ events.

Task Scheduler Manual This service should be


enabled/disabled as
necessary. The service
enables a user to configure
and schedule automated
tasks on this computer.
Deploying Microsoft Windows Server Update Services 132

Option Security Setting Setting Rationale

TCP/IP NetBIOS Helper Automatic This service is used in


Windows networking for
computers running an
operating system earlier than
Windows Server 2003.

Telephony Disabled This service is not necessary


in this environment because
telephony devices are not
used.

Telnet Disabled The telnet service should be


disabled and its use strongly
discouraged.

Terminal Services Manual Terminal services should be


enabled or disabled as
necessary.

Uninterruptible Power Manual This service is necessary if a


Supply UPS is used.

Windows Installer Manual Users may choose to use


Windows Installer to install
.msi packages on the system,
and therefore this service
should be set to manual.

Windows Management Manual WMI provides extended


Instrumentation management capabilities.

Windows Management Manual WMI Driver Extensions allow


Instrumentation Driver monitoring of NIC connection
Extensions state in the taskbar.

Windows Time Automatic External time synchronization


is required for Kerberos key
exchange in Active Directory
environments.

Workstation Automatic The workstation service is


necessary for Windows
networking.
Deploying Microsoft Windows Server Update Services 133

TCP/IP Hardening
Microsoft recommends that you harden the TCP/IP interface for WSUS servers.

HKLM\SYSTEM\CURRENTCONTROLSET\SERVICES\SynAttackProtect

Security Setting Setting Rationale

REG_DWORD = 2 Causes TCP to adjust retransmission of


SYN-ACKS.

HKLM\SYSTEM\CURRENTCONTROLSET\SERVICES\tcpmaxportsexhausted

Security Setting Setting Rationale

REG_DWORD = 1 Helps protect against SYN attacks.

HKLM\SYSTEM\CURRENTCONTROLSET\SERVICES\TCPMAxHALFOPEN

Security Setting Setting Rationale

REG_DWORD = 500 Helps protect against SYN attacks.

HKLM\SYSTEM\CURRENTCONTROLSET\SERVICES\TCPmaxhalfopenretired

Security Setting Setting Rationale

REG_DWORD = 400 Helps protect against SYN attacks.

HKLM\SYSTEM\CURRENTCONTROLSET\SERVICES\AFd\parameters\enabledICMPr
edirect

Security Setting Setting Rationale

REG_DWORD = 0 Prevents the creation of expensive host


routes when an ICMP redirect packet is
received.

HKLM\SYSTEM\CURRENTCONTROLSET\SERVICES\tcpip\parameters\enableddead
gwdetect
Deploying Microsoft Windows Server Update Services 134

Security Setting Setting Rationale

REG_DWORD = 0 Prevents the forcing of switching to a


secondary gateway.

HKLM\SYSTEM\CURRENTCONTROLSET\SERVICES\tcpip\parameters\disableipsou
rcerouting

Security Setting Setting Rationale

REG_DWORD = 1 Disables IP source routing.

HKLM\SYSTEM\CURRENTCONTROLSET\SERVICES\tcpip\parameters\ipenabledrou
ter

Security Setting Setting Rationale

REG_DWORD = 0 Disables forwarding of packets between


network interfaces.

IIS 6.0 Security Settings


The following are security recommendations for IIS 6.0 with WSUS.

URLScan
Use the following settings in URLScan to help protect the administrative Web page for
WSUS. The complete Urlscan.ini file is located at the end of this topic.

Option ISEC Setting Setting Rationale

UseAllowVerbs 1 Uses the [AllowVerbs] section


of Urlscan.ini, which only
allows GET, HEAD, and POST.
Deploying Microsoft Windows Server Update Services 135

Option ISEC Setting Setting Rationale

UseAllowExtensions 0 Uses the [DenyExtensions]


section of Urlscan.ini. Allow
the following:

ASP Request: .asp, .cer,


.cdx, .asa

Executables: .bat, .cmd, .com

- Note that .exe must be


enabled for WSUS.

Scripts: .htw, .ida, .idq, .htr,


.idc, .shtm, .shtml, .stm,
.printer

Static Files: .ini, .log, .pol, .dat

NormalizeUrlBeforeScan 1 Canonicalizes URL before


processing.

VerifyNormalization 1 Canonicalizes URL twice and


reject request if a change
occurs.

AllowHighBitCharacters 0 Does not allow high bit


characters.

Allow Dot in Paths 0 Does not allow any periods in


paths.

Remove Server Header 1 Removes server information


from header response.

Per Process Logging 1 Enables the PID in


Urlscan.log. This allows extra
logging information for
URLScan.

AllowLateScanning 0 Ensures that URLScan is a


high priority.

PerDayLogging 1 Specifies that URLScan


produces a new log each day
with activity in the form
'Urlscan.010101.log'.
Deploying Microsoft Windows Server Update Services 136

Option ISEC Setting Setting Rationale

UseFastPathReject 0 Specifies that URLScan uses


the RejectResponseUrl or
allows IIS to log the request.

LogLongUrls 0 Specifies that only 1K can be


logged per request.

IIS Security Configuration


Consider enabling the following three security settings 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. We recommend
enabling IIS general (less detailed) error messages. This prevents an unauthorized user
from probing the IIS environment with IIS error messages.

To enable general IIS error messages


1. On the Start menu, point to Programs, point to Administrator Tools, and
then click Internet Information Services Manager.

2. Expand the local computer node.

3. Right-click WebSites, and then click Properties.

4. On the Home Directory tab, clickConfiguration.

5. On the Debugging tab, click Send the following text error message to
client.

Enable additional logging options


By default, IIS enables logging for a number of options. However, we recommend logging
several additional key options.

To add key IIS logging parameters


1. On the Start menu, point to Programs, point to Administrator Tools, and
then click Internet Information Services Manager.
Deploying Microsoft Windows Server Update Services 137

2. Expand the local computer node.

3. Right-click WebSites, and then click Properties.

4. On the Web Site tab, click Properties.

5. On the Advanced tab, select the check boxes for the following logging
options:

• Server name

• Time taken

• Host

• Cookie
• Referer

Remove header extensions


By default, IIS enables header extensions for HTTP requests. We recommend removing
any header extensions for IIS.

To remover headers extensions for HTTP requests


1. On the Start menu, point to Programs, point to Administrator Tools, and
then click Internet Information Services Manager.

2. Expand the local computer node.

3. Right-click WebSites, and then click Properties.

4. On the HTTP Headers tab, select X-Powered-By: ASP.NET, and then click
Remove.

SQL Server 2000


The following are security recommendations for SQL Server 2000 with WSUS.

SQL Registry Permissions


Use access control permissions to secure the SQL Server 2000 registry keys.

HKLM\SOFTWARE\MICROSOFT\MSSQLSERVER
Deploying Microsoft Windows Server Update Services 138

ISEC Setting Rationale

Administrators: Full Control These settings help ensure limited access


to the application’s registry key to
SQL Service Account: Full Control
authorized administrators or system
System: Full Control accounts.

Stored Procedures
Remove all stored procedures that are unnecessary and that have the ability to control
the database server remotely.

Unnecessary SQL Server 2000 Stored Procedures


Deploying Microsoft Windows Server Update Services 139

Description Stored Procedures Rationale

Delete the following stored • Sp_OACreate Remove all stored


procedure by using the following procedures that are
• Sp_OADestroy
command: not necessary for
• Sp_OAGetErrorInfo WSUS and could
use master exec
• Sp_OAGetProperty possibly give
sp_dropextendedprocstored
unauthorized users
procedure • Sp_OAMethod the ability to
where stored procedure is the • Sp_OASetProperty perform command-
name of the stored procedure to line actions on the
be deleted. • SP_OAStop
database.
• Xp_regaddmultistring

• Xp_regdeletekey

• Xp_regdeletevalue

• Xp_regenumvalues

• Xp_regread

Xp_regremovemultistring

• Xp_regwrite

• sp_sdidebug

• xp_availablemedia

• xp_cmdshell

• xp_deletemail

• xp_dirtree

• xp_dropwebtask

• xp_dsninfo

• xp_enumdsn

• xp_enumerrorlogs

• xp_enumgroups

• xp_eventlog
Deploying Microsoft Windows Server Update Services 140

Description Stored Procedures Rationale

• xp_findnextmsg

• xp_fixeddrives

• xp_getfiledetails

• xp_getnetname

• xp_logevent

• xp_loginconfig

• xp_makewebtask
• xp_msver

• xp_readerrorlog

• xp_readmail

• xp_runwebtask

• xp_sendmail

• xp_sprintf

• xp_sscanf

• xp_startmail

• xp_stopmail

• xp_subdirs

• xp_unc_to_drive

Urlscan.ini file
The following is a facsimile of the complete Urlscan.ini file.
[options]

UseAllowVerbs=1 ; If 1, use [AllowVerbs] section, else use the


; [DenyVerbs] section.

UseAllowExtensions=0 ; If 1, use [AllowExtensions] section, else use


; the [DenyExtensions] section.
Deploying Microsoft Windows Server Update Services 141
NormalizeUrlBeforeScan=1 ; If 1, canonicalize URL before processing.

VerifyNormalization=1 ; If 1, canonicalize URL twice and reject request


; if a change occurs.

AllowHighBitCharacters=0 ; If 1, allow high bit (ie. UTF8 or MBCS)


; characters in URL.

AllowDotInPath=0 ; If 1, allow dots that are not file extensions.

RemoveServerHeader=1 ; If 1, remove the 'Server' header from response.

EnableLogging=1 ; If 1, log UrlScan activity.

PerProcessLogging=1 ; If 1, the UrlScan.log filename will contain a PID


; (ie. UrlScan.123.log).

AllowLateScanning=0 ; If 1, then UrlScan will load as a low priority


; filter.

PerDayLogging=1 ; If 1, UrlScan will produce a new log each day


with
; activity in the form 'UrlScan.010101.log'.

UseFastPathReject=0 ; If 1, then UrlScan will not use the


; RejectResponseUrl or allow IIS to log the
request.

LogLongUrls=0 ; If 1, then up to 128K per request can be logged.


; If 0, then only 1k is allowed.

;
; If UseFastPathReject is 0, then UrlScan will send
; rejected requests to the URL specified by RejectResponseUrl.
; If not specified, '/<Rejected-by-UrlScan>' will be used.
;

RejectResponseUrl=

;
; LoggingDirectory can be used to specify the directory where the
; log file will be created. This value should be the absolute path
; (ie. c:\some\path). If not specified, then UrlScan will create
; the log in the same directory where the UrlScan.dll file is located.
;

LoggingDirectory=C:\WINDOWS\system32\inetsrv\urlscan\logs

;
; If RemoveServerHeader is 0, then AlternateServerName can be
; used to specify a replacement for IIS's built in 'Server' header
;
Deploying Microsoft Windows Server Update Services 142

AlternateServerName=

[RequestLimits]

;
; The entries in this section impose limits on the length
; of allowed parts of requests reaching the server.
;
; It is possible to impose a limit on the length of the
; value of a specific request header by prepending "Max-" to the
; name of the header. For example, the following entry would
; impose a limit of 100 bytes to the value of the
; 'Content-Type' header:
;
; Max-Content-Type=100
;
; To list a header and not specify a maximum value, use 0
; (ie. 'Max-User-Agent=0'). Also, any headers not listed
; in this section will not be checked for length limits.
;
; There are 3 special case limits:
;
; - MaxAllowedContentLength specifies the maximum allowed
; numeric value of the Content-Length request header. For
; example, setting this to 1000 would cause any request
; with a content length that exceeds 1000 to be rejected.
; The default is 30000000.
;
; - MaxUrl specifies the maximum length of the request URL,
; not including the query string. The default is 260 (which
; is equivalent to MAX_PATH).
;
; - MaxQueryString specifies the maximum length of the query
; string. The default is 2048.
;

MaxAllowedContentLength=30000000
MaxUrl=260
MaxQueryString=2048

[AllowVerbs]

;
; The verbs (aka HTTP methods) listed here are those commonly
; processed by a typical IIS server.
;
; Note that these entries are effective if "UseAllowVerbs=1"
; is set in the [Options] section above.
;

GET
Deploying Microsoft Windows Server Update Services 143
HEAD
POST

[DenyVerbs]

;
; The verbs (aka HTTP methods) listed here are used for publishing
; content to an IIS server via WebDAV.
;
; Note that these entries are effective if "UseAllowVerbs=0"
; is set in the [Options] section above.
;

PROPFIND
PROPPATCH
MKCOL
DELETE
PUT
COPY
MOVE
LOCK
UNLOCK
OPTIONS
SEARCH

[DenyHeaders]

;
; The following request headers alter processing of a
; request by causing the server to process the request
; as if it were intended to be a WebDAV request, instead
; of a request to retrieve a resource.
;

Translate:
If:
Lock-Token:
Transfer-Encoding:

[AllowExtensions]

;
; Extensions listed here are commonly used on a typical IIS server.
;
; Note that these entries are effective if "UseAllowExtensions=1"
; is set in the [Options] section above.
;

.htm
.html
.txt
.jpg
Deploying Microsoft Windows Server Update Services 144
.jpeg
.gif

[DenyExtensions]

;
; Extensions listed here either run code directly on the server,
; are processed as scripts, or are static files that are
; generally not intended to be served out.
;
; Note that these entries are effective if "UseAllowExtensions=0"
; is set in the [Options] section above.
;
; Also note that ASP scripts are denied with the below
; settings. If you wish to enable ASP, remove the
; following extensions from this list:
; .asp
; .cer
; .cdx
; .asa
;

; Deny ASP requests


.asp
.cer
.cdx
.asa

; Deny executables that could run on the server


;.exe
.bat
.cmd
.com

; Deny infrequently used scripts


.htw ; Maps to webhits.dll, part of Index Server
.ida ; Maps to idq.dll, part of Index Server
.idq ; Maps to idq.dll, part of Index Server
.htr ; Maps to ism.dll, a legacy administrative tool
.idc ; Maps to httpodbc.dll, a legacy database access tool
.shtm ; Maps to ssinc.dll, for Server Side Includes
.shtml ; Maps to ssinc.dll, for Server Side Includes
.stm ; Maps to ssinc.dll, for Server Side Includes
.printer ; Maps to msw3prt.dll, for Internet Printing Services

; Deny various static files


.ini ; Configuration files
.log ; Log files
.pol ; Policy files
.dat ; Configuration files

[DenyUrlSequences]
Deploying Microsoft Windows Server Update Services 145
.. ; Don't allow directory traversals
./ ; Don't allow trailing dot on a directory name
\ ; Don't allow backslashes in URL
: ; Don't allow alternate stream access
% ; Don't allow escaping after normalization
& ; Don't allow multiple CGI processes to run on a single request