Deploying Microsoft Windows Server Update Services

What is WSUS?

Simply put, Microsoft Windows Server Update Services (WSUS) is the Microsoft provided solution for enterprise patch management. Using WSUS, network administrators can manage and deploy software updates for all of the Microsoft products in a network. This includes client operating systems such as Windows XP and Windows Vista, server operating systems such as Windows Server 2003 and Windows Server 2008, and other products including Microsoft Exchange, ISA Server, and Forefront Security.

Looking Under the Hood

There are three main components that come together to make a WSUS deployment work. The first of these is the Microsoft managed component, Microsoft Update, which manages and distributes updates to Microsoft clients upon request. Next, is the WSUS server itself, which allows administrators to specify which updates are downloaded from Microsoft Update and then deployed to network clients. The final component is Automatic Update, which is built in to Windows 2000 SP4, Windows XP, Windows Server 2003, and Windows Server 2008 and allows these operating systems to download updates from a specified source.

Whether deploying WSUS for a small LAN or a large geographically disperse WAN, all that is involved is leveraging these three components. Let’s take a look at some of the scenarios you may need to deploy WSUS in and how we can effectively do this. Afterwards, we will actually step through the installation process.

WSUS in a Small LAN

The majority of WSUS installations take place in a smaller environment consisting of a single location and less than a hundred computers. In this configuration, a network administrator will manage a single WSUS server which downloads updates directly from Microsoft Update. More often than not, budget reasons prohibit the purchase of a server exclusively for WSUS, so the service will share hardware with something such as a file or application server.

Once you have everything set up, the only burden on the network administrator is to ensure that synchronization between the server and Microsoft Update is occurring properly and to approve the downloaded updates occasionally. Clients will download and install updates automatically using the Automatic Update component.

Figure 1: A Simple WSUS Deployment

WSUS in a Large LAN

A larger network brings a few new concerns into the mix. These networks are still contained in a single location, but have a much greater number of computers, servers, and network segments.

The first thing to consider is that that not all computers should receive the same set of updates. For instance, the users in your accounting department may run an application that does not play friendly with .NET framework 3.0, whereas users in the engineering department require it. This is a pretty simple fix through the use of computer groups. Every computer that reports to the WSUS administration console can be placed in a computer group depending on its individual needs. By default, all computers are placed in the “Unassigned Computers” group when they first report to a WSUS server. Once they have reported however, you can create a custom group and place them in that group. Updates are approved on a per group basis which will allow you to customize the updates installed to a group of computers based upon the user’s needs.

Aside from this, the next consideration here is the management burden imposed by multiple WSUS servers. Monitoring synchronization, approving updates, and ensuring the successful installation of updates is typically a pretty simple task. However, if you have five separate WSUS servers then the management of these can get time consuming for a single person…not to mention mind numbing. Luckily, WSUS was designed with the use of multiple servers in mind and averts this issue through the use of WSUS Server Hierarchies. This hierarchy model allows a single WSUS server to act as an upstream server and impose its configuration on those servers configured as downstream servers below it.

A WSUS hierarchy supports two modes, autonomous mode (which we will discuss later) and replica mode. In replica mode, the upstream server is the only WSUS server that downloads its updates from Microsoft Update. It is also the only server that an administrator has to manually configure computer groups and update approvals on. All information downloaded and configured on to an upstream server is replicated directly to all of the devices configured as downstream servers. Using this method you will save a great deal of bandwidth as only one computer is constantly updating from the Internet. More importantly however, you will save a countless amount of time since you are only managing one server now from a software standpoint.

Figure 2: Deploying WSUS in a Large LAN

WSUS in a WAN

The final and most complex scenario in which WSUS can be installed is a large WAN. These WANs are characterized by a large number of devices spread amongst several geographic locations.

Unlike our other scenarios, networks such as this often have a distributed IT management model. Rather than a single administrator managing all WSUS activities, each particular location could have a separate administrator who will need to manage computer groups and update approvals separate from that of the main office. As you would expect, this is another scenario where we can make use of upstream and downstream severs, or more specifically, autonomous mode.

Using autonomous mode, the upstream server transmits update files to the downstream servers, but nothing else. This means that individual computer groups and update approvals must be configured for each particular downstream server. In this deployment type, you get the benefit of optimized bandwidth usage with the flexibility of allowing individual site administrators to manage computer groups and update approvals themselves.

Another typical WAN scenario is caused by bandwidth restriction. It is common that remote network locations will have a high speed connection to the internet but a rather low speed link back to the main office, such as through a VPN. In these cases, an upstream server can manage update approvals, but those remote downstream servers can be configured to download the approved updates directly from the Internet as opposed to the upstream server.

Figure 3: A WSUS Deployment Designed for a WAN

Installing WSUS

After you decide what deployment scenario is right for your network, you will want to get to installing it. We are going to step through the process of installing WSUS on to your server.

Before you get started you will need to download the latest release of WSUS directly from Microsoft. After you have downloaded WSUS 3.0 to the server, simply run the executable to get started. At this point you will be notified if you are missing any of the requirements for installing WSUS (check those out at WSUS Installation Requirements). If you are in the clear, then you will be asked what components of WSUS you want to install. You can install either the full package containing the WSUS program components and the management console, or just the management console itself. In this case we will be installing all of the components. Proceed by accepting the license agreement.

The next screen will prompt you to select the update source. This is where your client computers will download updates from. For our purposes here we will select Store Updates Locally and choose a location with at least 20 GB of free disk space (more if you have a highly diverse range of products you will be updating). If you do not choose this option, the client computers will only use WSUS to manage what updates are approved and will download these updates directly from Microsoft Update over the Internet.

Figure 4: Selecting an Update Source during WSUS Installation

The database options page is next. This is where you choose the database technology WSUS will use to maintain update information about clients. By default, setup will use the Windows Internal Database. This works just fine, but if SQL Server software happens to be installed on the machine then you can also use that as well by entering its information in on this page.

The following screen allows you to select how WSUS will use IIS. You can use the default web site on port 80 or have WSUS create its own site using port 8530. Using port 8530 is recommended as it allows you some flexibility if you end up adding other web based applications to the same physical server later on.

Figure 5: Selecting what IIS Website WSUS Will Use

This is all of the configuration that is required at this point. Click Next through the remaining screens and choose Finish to complete the installation.

Wrap Up

We have just gone through a lot of the possible deployment options for WSUS as well as how to install it. There is quite a bit more to know about WSUS but the information provided here should give you a good jump start in determining how you should deploy this Microsoft technology so that you increase update efficiency and decrease administrative overhead.