Configuring WSUS 3.0 on Windows Server 2008

WSUS is a locally administered system that synchronizes the patches and hot-fixes from the official Microsoft Update website. These are downloaded and stored locally on a server. System administrators are able to manage the deployment of these patches throughout their network. This gives them much more control over the updates—from scheduling up to manual approval. It’s a comprehensive suite that is very configurable.

As you can imagine, implementing the WSUS solution (formerly known as SUS—Software Update Services) brings a lot of benefits in a corporate environment. First of all, aside from greater control, it also helps reduce workload, saving bandwidth, disk space, and ultimately also time. The network's computers will grab the updates via the local network from the central server.

WSUS makes it possible to remotely deploy not only Windows-related hot-fixes and patches, but also for any other Microsoft-made product, such as Office, Visual Studio, Exchange, and many other. Furthermore, administrators can configure WSUS to deploy device drivers and feature packs individually. The web interface of WSUS runs on a virtual IIS site, while the repository is based on an MSDE (SQL Server) platform.

In corporate environments, chances are that the infrastructure is based on Active Directory and certain policies are enforced via GPOs (Group Policy Objects). In this case, the administrators can set up and enforce specific policies regarding Automatic Updates on the client-side. This way they won’t be able to bypass and/or skip the deployment of the software patches supplied by WSUS. This turns it into a safer suite.

Now let’s see how to get started with this system. We are going to install and configure WSUS.

Installing WSUS

This article is a sequel to our Windows Server 2008 two-part series. This means that we are going to assume that your Windows Server 2008 is already alive and kicking. And if you are reading this article, chances are you are going to want to set up WSUS 3.0 on that new server of yours. As you have probably noticed, right now, the latest release of WSUS 3.0 already comes with SP1. It fixes most of its previous bugs.

Let’s discuss the pre-requisites in terms of WSUS. First of all, the central server ought to have the following services installed: IIS 7.0 (with ASP.NET, Windows Authentication, 6.0 Management Compatibility, IIS Metabase Compatibility), Microsoft Report Viewer Redistributable, and SQL Server™ 2005 SP1. The .NET Framework 2.0 and BITS 2.0 are included in the Windows Server 2008 installation already.

Before running the WSUS 3.0 SP1 installation, you should verify the existence of the components listed above. You can check for them either from Add/Remove Programs and Windows Components or from the Server Management Console. Furthermore, you should also make sure that you match the necessary disk space requirements. But let’s assume that everything is fine and download WSUS 3.0 from Microsoft.

Once you start the setup, the installation welcome screen pops up. Next, you are asked to select the installation mode. We’d advice picking “Full server installation including Administration Console” because it is the most comprehensive suite. Moving on, read and accept the license agreement, and then you will see the Select Update Source screen pop up. You should tick the box to store the updates locally and select the path.

The next screen concerns the Database Options. There are three options; use the first option if the server on which WSUS is installed doesn’t have any other database management service already running, and you don't want to use a remote database server. This option simply installs Windows Internal Database on the server and links WSUS through that.

The next dialog box asks you to pick the website for WSUS. You can either make the recommended choice, that is, using the existing IIS Default Web Site (http://server) or set up a different web site dedicated just to WSUS (http://server/site_goes_here). The first option uses the default HTTP port (namely 80) while the latter creates a site on the 8530 port. Both choices are fine as long as you keep in mind which one you're using. 

Finally, the installation begins, and you should see the progress bar increase. Once it is done, the WSUS Configuration Wizard pops up. You can always launch WSUS Configuration Management via the MMC Snap-in as well. This wizard leads you through the steps of configuring WSUS for the first time. Don’t worry if you make a mistake and do something wrong while using the wizard, since you can reconfigure everything later.

You should carefully configure the network connection for the WSUS server. If you have a proxy server through which the outbound connections travel, then do configure that in the Proxy Server window. The wizard will also ask whether you want to synchronize directly from Microsoft Updates Server or some other WSUS server. Chances are you don’t have another WSUS repository, so pick the first one—Microsoft.

Once these tasks are done, you should start synchronizing for the very first time. This does take a while. You can now take your lunch break—we’ll continue on the next page.

Configuring WSUS

After the synchronization process is done, the Choose Languages screen will pop up. Here you can select the languages of patches that are to be downloaded. On the next screen you can select the software products in which you are interested, in terms of patches, hot-fixes, and all kinds of other patch metadata. You should tick all of the software applications that are already being used or probably will be used in the future.

Then you are asked to specify the kinds of updates you want to synchronize. Here once again, it is advisable to think big and long-term. Generally the following three are the most often selected: Critical Updates, Definition Updates, and Security Updates. Automatic Updating is basically composed of these hot-fixes, so these are the heart of the entire system. But don’t limit yourself to only these; just see which ones look fine.

Moving on, you need to schedule when the synchronization happens. As a general rule, it is often recommended to pick a time when most of the bandwidth is free and there is little to no workload at all. In a corporate environment that’s probably around 02:00—03:00 AM. Be aware that a random offset will be added after the amount.

The configuration process is almost done. The initial synchronization will begin and the WSUS Administration MMC snap-in is brought up. The process of synchronization is quite slow, depending of course on your network bandwidth. But this doesn’t mean that you can sit back and relax. While it is downloading you should configure Automatic Updates via domain-based GPOs and enforce them on client PCs.

This is important, because you actually need to add client computers into WSUS. From now on, the Automatic Updates repository is the central server located on your local network. The entire schedule for when, how frequently, and via which repository to launch Automatic Updates must be configured now. This can be easily done if your domain is based on Active Directory Group Policies. If your network doesn’t implement a domain, then simply configure it via the Local Group Policies.

Create a new GPO or use an existing one in which you’re going to configure Automatic Updates. Add the WSUS Administrative Template (“wuau.adm”) into the specific GPO. Configure appropriately and pay close attention to the field where you need to point the client computers to the WSUS central server. This is the web site link of WSUS (the one we picked during installation) on your intranet.

Furthermore, once the GPO is configured, then you need to link it to the domain (if it isn’t already, as in the case of existing GPOs), enforce the policies, and manually force an update to the Group Policy. Just run the following command: “gpupdate /force.” This command immediately updates the policies instead of waiting about 90 minutes. You can also force Automatic Updates by running “wuauclt.exe /detectnow.”. By doing so, Automatic Updates will contact the WSUS central server right away!

If everything is configured right and the policies with the appropriate configurations are deployed, then as soon as the Automatic Updates contacts the WSUS Server located on your intranet, you should notice activity in the WSUS Administration MMC snap-in. Now you can create individual computer groups, because as you can clearly see, all of the client computers are going to be added under the “Unassigned Computers” group.

There are two possible ways to group the computers, either server-side targeting where the administrator manually categorizes the client computers into the correct group, or client-side targeting; that is, Group Policy and/or Registry-based. The latter is generally recommended, and you can individually add the name of the appropriate group as entries in the policies of the correct GPO. Creating groups is optional, though. They are useful in those situations where patches are deployed only on test groups.

And finally, from the WSUS Administration MMC snap-in, you need to set up the Approval Rules. As soon as the client computers begin synchronizing with the WSUS server, you can already see complex and thorough reports. You can set up automatic approval for various types of updates (such as always approve security patches) but also on specific groups and so forth. There’s a lot of flexibility. You can also specify deadlines for particular deployment jobs. Be sure to play around with reports as well!

As a final side note, don’t hesitate to look for help from the official TechNet site of Microsoft. WSUS is very thoroughly documented, and there are a lot of guides that lead you through specific scenarios. This guide covers client computer configuration based on GPOs. And there are many, many more. Configuring WSUS isn’t that tough.

Closing Thoughts

We have arrived at the end of this article, and hopefully by now you’ve successfully set up WSUS, configured the way you want it, and it is synchronizing and deploying appropriately without any issues. Throughout this article we presented the major steps for installing, setting up, and configuring WSUS.

WSUS comes with Windows Server 2008 already. This makes it easily affordable and a seamless solution to implement. According to some general statistics, it has been said that WSUS can satisfy the needs of most small-to-medium corporate and enterprise environments. It can also be used in advanced situations where thousands of computers need to be administered, but it may not be the ideal suite.

There are other aftermarket software update and patch management possibilities. Once again, it is up to the IT management to establish a thorough business analysis of requirements and decide whether implementing WSUS is a good decision for the business. Altiris Inc. (a subsidiary of Symantec) has a really high-end and complex patch management suite. It is a multi-purpose solution that integrates into others as well.

For most companies, implementing WSUS turns out to be a wise decision, because it requires no further acquisitions and licensing costs. It’s a solution that is developed and provided by Microsoft, and it integrates easily (since it comes with it) into the entire infrastructure if it’s based on Microsoft products. This article shown you how to implement WSUS and configure it appropriately to get the most out of its offerings.

We can’t really finish without inviting you to join our helpful forums at DevHardware Forums. We’ve a strong base of resident professionals, enthusiasts, and tech experts. If you want to hear opinions on some service or ask some clarifications regarding some details just shoot us your questions. We’ll do our best to help. And you should also want to pay a visit to the forums of our sister-site: DevShed Forums.