Choose a Type of Deployment

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server Update Services

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.

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.

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.

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.

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.

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.

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.

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.

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.