Why Windows Server Update Services?

Yep, it is free, too. This "Free" theme is a nice one.

As previously discussed, the need to perform patching is pretty obvious. With all of the new threats that come out practically every hour, the ability to apply security patches is very important. WSUS enables quick patching where security is vital, and it allows for automation of patching of all systems in the environment. Deploying patches, manually, just does not scale well without a tool like WSUS. Manual patching not only takes a great deal of time, it involves using IT staff at odd hours to reduce the impact on end users. Having IT staff performing patches during late-night hours is not cost effective at all, and it is also leads to serious performance issues with IT staff as they are tired from late-night work and they are not motivated by the low-end complexity of patching work. It is boring, and it is aggravating. Patching manually ultimately leads to administrators who make mistakes or who leave the organization for the want of a real life outside of their offices.

Improvements over Software Update Services

Windows Software Update Services (WSUS) replaces Software Update Services (SUS). WSUS is a downloadable option for Windows environments that can be used to manage updates for Windows servers and Windows clients on small to large corporate networks. While Software Update Services (SUS) provided this same capability, WSUS has improved on SUS by providing:

• A larger number of available updates

• A better organized list of update options

• The capability to provide updates sorted by product

• The capability to provide updates sorted by type and priority of update

• Support for multiple languages

• The ability to provide different levels of service to specific computers or computer groups

• Improved reporting

• Improved network performance using Background Intelligent Transfer Service (BITS) 2.0

• Increased coverage of applications by including Office, SQL, Exchange, MSDE, and critical hardware drivers

For organizations still using Software Update Services (SUS), there are some good reasons to upgrade. Of course, these are all of the improvements, but most important, SUS support is going away. According to http://www.support.microsoft.com/kb/905682, Microsoft will no longer support SUS after December 6, 2006 and SUS will stop synchronizing updates after December 6, 2006. SUS is no longer available from the Microsoft download site. Installing WSUS in an organization involves a few high-level steps such as:

1. Purchase the appropriate licensing. Windows client access licenses are required for each computer that uses WSUS.

2. Install WSUS on the server.

3. Configure WSUS to obtain updates over the Internet from Microsoft.

4. Configure the clients on the network to install updates from the WSUS server.

5. Test the environment.

6. Approve and distribute updates.

WSUS is well worth the cost of the time and equipment needed, plus the small investment in software costs, to get it up and running. Alleviating the pain of manual patching and allowing administrators to get some more sleep has to be good for every organization out there.

WSUS Support

While the support level hasn't really changed much between SUS and WSUS, it is clear that Microsoft intends to continue supporting WSUS as more operating systems are released in the future. For example, Windows Server 2003 R2, Vista (the new Longhorn client operating system), and the new Longhorn server (name to be announced) will almost certainly be supported by WSUS. For now, however, the following operating systems can use WSUS as clients:

• Windows 2000 Professional, Server, and Advanced Server running SP3 or later

• Windows XP Professional and Home Editions (while Home Edition is not meant for business use, support is meant for people coming from home with notebooks to corporate offices for meetings, and so on)

• Windows 2003 Server Family

Currently, WSUS is supported for installation on Windows 2000 Server and Advanced Server as well as Windows Server 2003 Standard Edition and Enterprise Edition. Because Windows 2000 is no longer fully supported by Microsoft as it is phased out, it is extremely important that any new WSUS installations be done using Windows Server 2003. There are some added benefits to using Windows Server 2003, such as its improved performance and security as well as the fact that WSUS, when installed on Windows Server 2003, can use Microsoft Windows SQL Server 2000 Desktop Engine (WMSDE), which provides an unlimited database size for support of WSUS database needs.

Design

As with all applications, it is important to take some time before deployment to properly design the installation of the individual components. This book is focused more on "how to" and design definitely takes a back seat. There are some basics, however, that just can't be overlooked. WSUS can be a simple single-server deployment, or it can involve multiple layers of servers.

In a basic WSUS environment, as in Figure 5-11, the WSUS server on the local area network connects through the Internet to the Microsoft Update server, and all WSUS clients then connect to the WSUS server to get their updates and treat the WSUS server as if it were an MU server.

Figure 5-11

The next step of complexity is to add computer groups. With computer groups, an administrator can configure each group for separate deployments. For example, a test group can be created with all test servers and some test desktops installed in it. Updates can be targeted to the test group and the computers can then be tested and evaluated to verify that the updates will not cause harm to computers in the production environment. Another good use of computer groups would be the segregation of desktop workstations and servers into separate groups. If a patch is found to cause harm to specific desktop applications, then that patch can be excluded from the desktop workstation computer group while it is fully deployed in the server computer group.

Another design scenario includes the use of upstream and downstream WSUS servers. In this type of scenario, as displayed in Figure 5-12, the upstream server retrieves all updates from Microsoft Update, and then the downstream WSUS servers get their updates from the upstream server. In this scenario, bandwidth can be better controlled as computers in the downstream network will not have to consume bandwidth to go to the upstream server. Also, administrators can manage the upstream server and approve updates and thus limit the downstream WSUS servers and all of the computers in the downstream WSUS environment to using only approved and properly tested updates.

Figure 5-12

Microsoft recommends a three-level limit when using upstream and downstream WSUS servers to limit latency as the updates are copied from one level to the next. Using an upstream and downstream WSUS environment, as shown in Figure 5-12, allows for greater centralization of WSUS management. It is possible, however, to have multiple WSUS servers in an environment where each one is managed locally.

Important 

In an upstream and downstream WSUS environment, the computer group membership information is not replicated to downstream WSUS servers.

Yet another design scenario calls for the use of WSUS replicas. For improved centralized administration, Microsoft included the ability to create a replica group for multiple WSUS servers. A replica is very similar to a downstream WSUS server. The main difference between a replica and a normal downstream server is that the replica actually replicates (thus the name) all of the configuration information from the source WSUS server to the target WSUS server with the exception of membership of computer groups. The replica will contain all of the computer group names, but the groups will not be populated with computer names. Replica computer groups can have different memberships than the source WSUS server. To configure a replica group, follow these steps:

1. Install WSUS for the main location.

2. Install WSUS on another server and during the setup select the check box for "this server should inherit the settings from the following server" and enter the information.

3. Repeat Step 2 as often as needed.

Remember that a replica is still, essentially, a downstream WSUS server, and having too many levels of replicas can result in updates taking excessive time to get to computers using downstream WSUS servers. It is also important to note that an existing WSUS server cannot be made into a replica. It must be configured as a replica during installation.

A fairly common distributed WSUS server scenario uses different WSUS servers with different rules for different computers based upon their location. A great example of when an administrator might want to do that is shown in Figure 5-13.

Figure 5-13

Internal computers can get all of their approvals for updates and the updates themselves from the WSUS server for internal computers. Another WSUS server can be used for VPN clients that connect to the network but also have their own Internet bandwidth. In such a situation, computers using the WSUS server for external computers can get their approvals from the WSUS server, but then use Microsoft Update to download the updates. This enables administrators to control the updates deployed by providing the approval mechanism but not taking the space or the bandwidth needed to deliver the actual content. This same scenario can be applied to a branch office that has its own Internet connection as well as a connection to the main office. A separate WSUS server in the main office can be used for all such branch offices while a WSUS server in the main office can handle all of the computers in the main office network. The separate WSUS server for the branch offices can be separately administered (well, it must be because replicas have the same rules) to approve updates for branch office computers and then all the branch office computers can use their own Internet connections to download the updates from Microsoft Update directly.

Data and the Database

WSUS contains two types of data, the data about the updates (also called the metadata) and the updates themselves. The metadata is stored in a database so that it can be used in reports and for management of WSUS, while the actual update and patch files themselves are stored in another location. In both cases, the WSUS administrator should plan on where this information will be stored. If WSUS is being deployed in a chained (upstream and downstream server) environment, all of the WSUS servers must use the same storage options. So, if the upstream server is going to use local disk storage for the updates, then all the downstream servers also have to use local storage for their updates.

WSUS requires the use or a database to properly track all updates downloaded and deployed in the environment and other information such as the end user license agreements associated with the updates. The choices for database installation include:

• Using an existing SQL 2000 implementation: If using SQL 2000 SP3A or greater, the nested triggers option in SQL should be enabled before installing WSUS.

  Important 

  WSUS will enable recursive triggers for the WSUS databases, but the WSUS install cannot enable nested triggers. Nested triggers must be enabled manually.

• Using MSDE 2000: MSDE should be used only when installing WSUS on a Windows 2000 server in an environment where SQL 2000 is not available.

• Using Microsoft Windows SQL Server 2000 Desktop Engine (WMSDE) as provided by the WSUS installation: WMSDE is available only when installing WSUS on a Windows Server 2003 server.

Important 

WMSDE is not subject to the 2GB limit of the standard version of MSDE.

MSDE 2000 is severely limited and not recommended for a full production environment. MSDE 2000 is limited to a total of 2GB and cannot grow beyond that size. When the limit is reached, WSUS will need to be moved to a SQL 2000 server in order to support growth.

Microsoft documentation stresses that administrators of the WSUS environment do not need to be SQL database administrators to do their jobs properly. With the ease of installation and management of the WSUS environment in mind, Microsoft decided to distribute a free version of SQL with WSUS. The version of SQL distributed with WSUS is designed to require little or no database management. However, because larger organizations have SQL administrative skills available to them, there is a tendency to use existing SQL infrastructures and administrative skill sets to properly control the database and to properly secure its contents. The SQL environment for WSUS stores:

• WSUS configuration information

• Information about the individual updates, i.e., what operating system or application they are used for and what knowledge base article or security bulletin they reference

• Information about the client computers and the updates that have been deployed

What is really important to note here is that although SQL maintains the WSUS configuration and other metadata, the actual updates are not stored in SQL. Microsoft strongly recommends that administrators do not attempt to alter the data or manage the data in the SQL databases using SQL tools. All changes should be made through the WSUS console only.

Because the data maintained in the SQL database is specific to the individual WSUS server, each instance of WSUS requires its own database. Microsoft does not support maintenance of multiple WSUS databases on the same SQL instance. Because the data stored in SQL does not include the actual content of the updates, the size of the SQL database will not directly correlate to the size of the content.

There are some limitations to using a remote database for WSUS. For example, in order to use a remote database:

• The WSUS server must run Windows Server 2003. Windows 2000 is not an option.

• The remote database must be SQL 2000 and cannot be MSDE or WMSDE.

• The WSUS and the database server must both be members of the same Active Directory domain.

• Neither the WSUS nor the database server can be domain controllers.

• The SQL server must use Windows authentication.

In a split server implementation, a WSUS server is used to connect to Microsoft Update and download the update information. The WSUS server is also used to control and manage the storage of update files. In a split server environment, the database is referred to as a back-end server and it stores all the metadata for the updates. In order to build this environment, WSUS must be installed on the front-end server first and then the database environment is built after the front-end environment has been installed.

The front-end WSUS is installed by running wsussetup at the command prompt with the /f switch, and then the back-end WSUS (the SQL server) must be installed using the wsussetup from the command line with the /b switch.

The process of configuring the split between the WSUS front end and the WSUS back end is much more complicated than performing a WSUS installation on a single server with the included WMSDE. For more information about how to install WSUS using a remote SQL server, refer to Appendix C of the "Deploying Microsoft Windows Server Update Services" article on Microsoft Technet.

The data is another matter completely. The updates files can be stored in a couple of different ways for WSUS:

• Local Storage: This is the default option. Using local storage requires a minimum of 6GB of hard disk space to store all of the updates on one of the local hard drives. Microsoft recommends 30GB of free disk space to store updates; however, it is possible that future updates will require even more than 30GB.

• Remote Storage: This option allows administrators to keep all updates on Microsoft Update and then allow computers connecting to WSUS to get approvals from WSUS and then download and install updates from Microsoft as needed.

Of the two storage options, Local Storage is best for organizations that have limited bandwidth and would like to host the files locally for best update performance. Remote storage makes sense in organizations with few computers and enough available bandwidth to the Internet to download and install updates pretty much on demand.

Prerequisites

WSUS utilizes both server-side and client-side software components. On the server side, WSUS has both hardware and software prerequisites that must be met in order to properly install and run the WSUS service within the organization. On the client side, Automatic Updates is used by WSUS, and it takes almost no effort to install this piece because it is already installed by default.

The WSUS client component is the Automatic Updates client that is installed by default on newer operating systems. Automatic Updates runs on:

• Windows 2000 Professional, Server, and Advanced server with SP3 or higher installed

• Windows XP Professional

• Windows Server 2003 Family products

The server side of WSUS, as previously discussed, is basically the same thing as a private copy of the Microsoft Update server from the Internet copied and installed in the local area network and accessible over a much faster network. The server side, with remote storage, can also be viewed as an approval filter that allows administrators to decide which updates computers will be allowed to install instead of letting Microsoft decide for them, as a Microsoft Update client would do.

WSUS Hardware

Performance will always be affected by the hardware used at some capacity level. In the case of WSUS, Microsoft has provided some very broad and gray guidelines. Microsoft's prerequisites for WSUS for 500 or fewer computers are:

• Pentium III, 750 MHz CPU is the minimum with a Pentium 3, 1 GHz or faster CPU recommended.

• 512MB of RAM is the minimum with 1GB of RAM recommended.

• 1GB of free space on the system partition.

• 6GB of free space for the WSUS storage minimum and 30GB recommended.

For 500 to 15,000 (yep, pretty wide range) computers, the recommendations are:

• Pentium III, 1 GHz CPU is the minimum with a 3 GHz Pentium 4 recommended, and dual processors are recommended if there are over 10,000 computers.

• 1MB of RAM is recommended.

• 1GB of free space on the system partition.

• 6GB of free space for the WSUS storage minimum and 30GB recommended.

For large organizations, upstream and downstream servers along with replicas can greatly improve the performance, especially in environments where there are wide area network segments that have slow connections.

WSUS Software

Of course installing WSUS includes downloading the WSUS software itself, but before WSUS can be installed, there are several other software prerequisites.

• Windows Server 2003: Either Standard Edition or Enterprise Edition will work, but there is no reason to use Standard Edition as WSUS really will not benefit from more than dual processors and more than 1GB of RAM. WSUS cannot be clustered, either. While Windows 2000 Server and Advanced Server can be used and will meet the requirements of WSUS, it is not considered a best practice to use operating systems that do not have mainstream support from Microsoft.

• Internet Information Server (IIS) 6.0: If for some reason Windows 2000 is used, then IIS 5.0 is required.

• Microsoft .NET Framework 1.1 with Service Pack 1: This can be downloaded from http://www.microsoft.com/downloads.

• Background Intelligent Transfer Services (BITS) 2.0: This can also be downloaded from http://www.microsoft.com/downloads. It is important to pay attention when downloading BITS 2.0 as there are three different versions: one for Windows Server 2003, one for Windows 2000, and one for Windows XP Professional.

• Internet Explorer (IE) 6 with Service Pack 1: IE 6.1 or later versions with the latest service pack will meet the prerequisites as well.

• Database software: WSUS includes WMSDE as previously discussed. WMSDE is a free version of SQL that does not require database administrator skills and is not limited to 2GB as the standard version of MSDE is. It is possible to use SQL 2000 Server on another computer in conjunction with the WSUS server; however, it is probably better to use the WMSDE and keep the entire WSUS solution in a single server to reduce troubleshooting efforts and to minimize performance impact on other SQL-based applications as well as the costs associated with obtaining all of the proper client access licenses for SQL.

Installation

Finally, the most important part about installation — the steps needed to install WSUS and make it work. Microsoft provides several options for the installation of WSUS. The options have been discussed at a high level in the design section of this chapter. This section covers the most common WSUS configuration, and it will not cover all of the different options. There are lots of Microsoft whitepapers that cover other options.

Overview of Installation

The installation process follows these basic steps:

1. Purchase Windows Server 2003 and Windows Client Access Licenses for each WSUS client computer. Windows CALs are required, and it is important that all the proper software is purchased for the WSUS server.

2. Install Windows Server 2003 with IIS 6.0. Use Microsoft Update to install all available patches.

3. Install BITS 2.0 and .Net Framework 1.1 with SP1. BITS 2.0 and Net Framework 1.1 with SP1 do not need to be installed if Windows Server 2003 Service Pack 1 is already installed and Windows Server 2003 has been fully updated.

4. Install WSUS.

5. Configure WSUS to receive updates from Microsoft Update.

6. Configure Computer Groups in the WSUS console.

7. Configure WSUS client computers to receive updates from WSUS.

8. Approve updates.

Install WSUS

Installing WSUS on the WSUS server is a pretty simple process using the installation wizard. Microsoft allows flexibility during the installation, as discussed in the Design section.

Download WSUS from the Microsoft web site at http://www.microsoft.com/wsus.

1. Double-click wsussetup.exe. WSUS decompresses itself to a temporary location and starts the installation wizard.

2. Click Next on the Welcome to the Microsoft Windows Server Update Services Setup Wizard window.

3. Select the I accept the terms of the License agreement radio button and then click Next in the License agreement window.

4. In the Select Update Source window, enable the Store updates locally check box and select the location for the update files, as in Figure 5-14, and click Next. As covered in the "Data and the Database" section, storing the updates on a local drive will improve the performance when it comes to installing the updates; however, it will require a minimum of 6GB of hard drive space with a recommended 30GB of hard drive space and potentially even more as new updates are released. If the check box is disabled, all updates will be downloaded from Microsoft Update as needed.

   
   Figure 5-14

5. In the Database Options window, select the Install SQL Server desktop engine (Windows) on this computer radio button, enter the physical location where the database should be stored, and click Next. The Use an existing database server on this computer radio button and its associated drop-down box will be grayed out during a normal WSUS installation. In order to enable this radio button, the /f switch is required as part of the setup command for WSUS.

6. Select the Use the existing IIS Default Web site (recommended) radio button on the Web Site Selection window and click Next. Using the Default Web site is recommended because even if a special WSUS web site is created on port 8530, there still needs to be a web site running on port 80 to listen for legacy Automatic Updates client software. Legacy Automatic Updates software cannot be updated if the WSUS server is not listening for these older components on port 80. Automatic Updates clients will automatically update themselves using the WSUS IIS services on initial contact. For more information on using custom web sites for WSUS, read the Install and Configure IIS section in the Deploying Microsoft Windows Server Update Services whitepaper found on the Microsoft WSUS web site.

7. Click Next in the Mirror Update Settings window. Do not enable the This server should inherit the settings from the following server check box if this WSUS server is the first one in the environment. Enabling the check box is used to create Replica Groups where replica WSUS servers are created based on the settings and configuration of the WSUS server entered in the Server namespace.

8. Click Next in the Ready to Install Microsoft Windows Server Update Services window. The installation will start after clicking Next.

9. Clear the Launch the Web Administration Tool check box and click the Finish button once the installation is complete.

Once the installation is complete, there are a few additional steps to take before the WSUS environment is fully installed and functional.

Configure WSUS to Receive Updates from Microsoft Update

The next major step after installation of the WSUS server software is to synchronize the server. Using a web browser, connect to the WSUS administration console web site at http://www.servername/wsusadmin. If prompted for credentials, supply the logon credentials for an administrator that is a local administrator on the WSUS server or an account that is a member of the WSUS Administrators group. The administration console, as shown in Figure 5-15, displays a To Do List at the bottom of the screen. After the installation, the list will include synchronizing the server with Windows Update. In this case, it also includes a warning to use SSL. Using SSL for the administrative console is a best practice.

Figure 5-15

To synchronize the WSUS server with Windows Update, use the following steps:

1. Click the Synchronize now link on the WSUS console

2. In the Schedule section on the WSUS console, select the radio button to Synchronize manually or to Synchronize daily at a time specified in the drop-down box. The Synchronize daily option is the better choice in most cases because it is too easy to forget to run it manually on a regular basis. One of the goals of WSUS is to implement an update program to automate the process.

3. In the Products and Classifications section, use the Change button under Products to select all of the products that are used in the organization and will be updated by the WSUS environment, and click OK to close the Add/Remove Products window.

4. In the Products and Classifications section, use the Change button under Update classifications to select all of the different classifications that should be downloaded and managed by the WSUS environment, and click OK to close the Add/Remove Classifications window.

5. In the Proxy Server section, configure all of the appropriate settings for the organization if a proxy server is needed.

6. In the Update Source section select whether the WSUS server should update from Microsoft Update or from an upstream WSUS server.

7. Once all of the sections have been configured, click Save settings and then click Synchronize now.

The Synchronization Status section will provide information on when the last synchronization was run and the status of any current synchronization processes that are running.

The initial synchronization may take hours depending on the amount of data that needs to be downloaded.

Approve Updates

Once all of the updates have been synchronized, they need to be approved before they can be downloaded and installed by WSUS client computers. Before approving updates, they should be tested in a test environment that mirrors production. If a problem is found with any updates and the test environment, the updates should not be approved and should not be used until the conflict can be resolved with the patch and any applications that it causes to fail.

While the majority of updates released by Microsoft do not cause any problems, it is vital to change management processes that they all be tested before organizational assets are put at risk.

Once updates have been tested, they need to be approved in the WSUS console so they can be downloaded and installed by the client computers in the organization. To approve updates, use the following steps:

1. Open the WSUS console.

2. Click Updates.

3. Select the updates for approval.

4. Click Approve for installation under Update Tasks.

5. Select the computer group or multiple computer groups (the All Computers group is the default) for approval in the Group approval settings for the selected updates.

6. Select the setting from the Approval column.

7. Click OK.

After updates are approved, WSUS client computers download and install them according to the options selected in previous sections of this chapter.

Update Status

The WSUS management console provides access to the status of updates in a couple of locations. The status of an individual computer or the status of an entire computer group can be checked using the WSUS console. The console provides one of the following status conditions:

• Failed: The update failed to install properly or was not detected properly.

• Installed: This is pretty self-explanatory — the update was installed.

• Last Contacted: This is the last date the WSUS client contacted the WSUS server.

• Needed: The update has been approved but has not yet been downloaded and installed. This status normally appears when the computer is supposed to receive the update but one of the following conditions exists:

  1. The computer has not reported in since the update was approved.

  2. The update has been downloaded but not installed.

  3. The update has been downloaded and installed, but it will not be fully installed until the WSUS client computer is restarted.

  4. The update has already been downloaded and installed but the WSUS client computer has not contacted the WSUS server since the update was installed.

  Important 

  As previously discussed, by default, WSUS client computers contact the WSUS server every 22 hours (it is 22 hours minus a random offset of 0–20 percent of the time configured). The status of the update as shown is not really valid until a complete day has passed and every computer has had a chance to connect.

• Not Needed: The update is not required by the computer or does not match the operating system or applications on the computer.

• Unknown: This means that the update was recently downloaded and the computer has not checked in yet.

Configure WSUS Clients

Of course, doing all of the work to install the WSUS server adds up to wasted effort unless you also configure the WSUS client computers to use WSUS. Once the WSUS server is up and running, the next step is to configure the WSUS client computers. This step is pretty easy because administrators can leverage the power of Group Policy Objects. There are a couple of pieces to this configuration: First Automatic Updates needs to be configured so the WSUS client will download and install the updates from the WSUS server, and then the location of the WSUS server needs to be configured for the client.

Microsoft recommends that a new GPO be used. Many administrators are tempted to edit the existing Default Domain Policy, but, for troubleshooting and ease of removal at a later time, creating a separate policy just for the WSUS client computer configuration is a very good practice. This GPO can later be unlinked and deleted if WSUS is uninstalled from the network in favor of Systems Management Server (SMS) or some other application that can be used for update distribution.

Configure Automatic Updates

Open Active Directory Users and Computers and navigate to the location in Active Directory where the GPO should be linked. For example, it might be at the domain level or it might be at an OU. Then follow these steps to configure Automatic Updates:

1. Right-click the object in Active Directory Users and Computers, and then click Properties.

2. Select the Group Policy tab, click New, and provide a name, like WSUS for the GPO.

3. Make sure the new GPO is highlighted and click Edit.

4. Expand Computer Configuration, Administrative Templates, and Window Components, and select Windows Update, as in Figure 5-16.

   
   Figure 5-16

5. In the right-hand details pane, double-click Configure Automatic Updates.

6. Select the Enabled radio button and then select the Configure automatic updating option by using the drop-down box. The best solution in most organizations is to select the Auto download and schedule the installation option as it will result in more timely updates and will result in more secure computers. Administrators should make sure that the day and time selected do not interfere with other processes, such as backups or virus scans, that could be stopped by any updates that require restarting the computer.

   Four options are available:

   • Notify for download and notify for install: This option requires that the user of the computer receive and respond to notifications to download updates and notifications to also install updates. This goes back to the concern about letting users control the patching of the computers, which is not a good practice when it comes to ensuring update compliance. This option provides notifications only to administrative equivalent users.

   • Auto download and notify for install: This option is a bit better in that at least the updates get downloaded, but that does no good if they are not installed promptly. This option provides notifications only to administrative equivalent users.

   • Auto download and schedule the install: When you select this option, the installation is performed based on the scheduled day and time set in the properties, as shown in Figure 5-17.

     
     Figure 5-17

   • Allow local admin to choose setting: This option lets local administrators of the computer go into the Automatic Updates Control Panel applet and configure how they want to manage updates. This option also puts the responsibility of updates on the computer user.

7. Click OK.

Set WSUS Server Location for WSUS Client Computers

The previous section shows how to configure the Automatic Updates component on the WSUS client computers. It would really help those client computers, however, if they were told where to go to get updates. By default, they will all go Microsoft Update to download updates, so it is important that they be configured properly to point to the WSUS server. Again, GPOs are helpful. In each place in Active Directory where a WSUS GPO has been created, that same GPO can be used to also configure the WSUS location. The steps are very similar because the setting is in the same location as the Configure Automatic Updates setting used in the previous section. Follow these steps:

1. Right-click the object in Active Directory Users and Computers, and then click Properties.

2. Select the Group Policy tab and click New and provide a name, like WSUS for the GPO.

3. Make sure the new GPO is highlighted and click Edit.

4. Expand Computer Configuration, Administrative Templates, and Window Components, and select Windows Update

5. In the right-hand details pane, double-click Specify intranet Microsoft update service location.

6. Select the Enabled radio button and then enter the web address of the WSUS server in both text boxes so that the WSUS server is used for both detecting and downloading the updates as well as intranet statistics.

7. Click OK.

Create Computer Groups

Computer Groups allow WSUS to target updates to groups of WSUS client computers in the environment. Using Computer Groups, an administrator can make sure that computers get the right updates at the right times. As previously discussed, Computer Groups can be used to separate test computers from production computers and to separate servers and workstations. Computer Groups can also be used to separate computers by department. For example, accounting might be in a deadline mode trying to get all of the corporate tax statements out, or they might be working on the bonus checks (quick, go get them some coffee and donuts) and it is in the organization's best interests to leave them alone and put them in a freeze state where no changes should be made. If there is an Accounting Computer Group, administrators can make sure to not allow them to receive updates until their freeze period is over. Along the same lines, the test computers should always get everything so the testing process is able to take into account every possible interaction with updates before they are allowed to be deployed to production computers.

By default, all computers are added to the All Computers group and the Unassigned Computers group. Once a computer is assigned to a Computer Group, it is removed from the Unassigned Computers group, but it remains in the All Computers group no matter what. WSUS client computers can belong to only one Computer Group other than the All Computers group and WSUS client computers can never be removed from the All Computers group without removing them completely from the WSUS environment.

Important 

It is important to remember that replica WSUS servers will inherit their Computer Groups from the source WSUS server and the computer groups cannot be changed on the replicas.

Using Computer Groups requires three steps:

1. Select the method to be used, server-side targeting or client-side targeting.

2. Create the Computer Group in the WSUS console.

3. Move the computers using the method selected in Step 1.

Specify Targeting Method

The WSUS console is used to select the targeting method for the WSUS client computers. The steps are as follows:

1. Open the WSUS console.

2. Click Options.

3. Click Computer Options.

4. Select one of the following two options:

   • Use the Move computers task in Windows Server Update Services: This option is used if groups are to be assigned using the WSUS console.

   • Use Group Policy or registry settings on client computers: This option is used if groups are to be assigned from the WSUS client computer.

5. Click Save settings under Tasks and click OK.

Using Server-Side Computer Groups

In some organizations, it is easier to populate Computer Groups, especially in organizations with a limited number of computers.

To create Computer Groups, use the following steps:

1. Open the WSUS console.

2. Click Computers on the WSUS console toolbar.

3. Click Create a computer group under Tasks.

4. Enter the Computer Group name and click OK.

To manually add a computer to a Computer Group from the WSUS server, follow these steps:

1. Open the WSUS console.

2. Click Groups.

3. Select the All Computers group.

4. Select the computer to be moved.

5. Click Move the selected computer under Tasks.

6. Select the destination Computer Group.

7. Click OK.

Using Client-Side Targeting

The power of GPOs can also be leveraged for client-side targeting. With client-side targeting, a different WSUS GPO can be created for each OU that contains WSUS client computers, and the GPO can specify the Computer Group name to use for all WSUS client computers that use the GPO. For example, an accounting OU can have a GPO for WSUS that points the WSUS client computers to a separate WSUS server from the rest of the organization. If the GPO is properly configured, the WSUS client computer will automatically add itself to the proper Computer Group when it contacts the WSUS server.

The target Computer Group name for all WSUS client computers can be entered and deployed as part of the settings in the Windows Update section of the GPO. Enable client-side targeting can be selected in the settings pane, and then the Computer Group name can be entered. It needs to be entered exactly as it appears in the WSUS console.

Other Windows Update Group Policy Settings

There are several other settings in the Windows Update section for GPOs that should be evaluated as part of the WSUS client computer settings that can be deployed. Some of the more popular settings you should look at include:

• Allow Automatic Updates immediate installation: This setting allows WSUS clients to immediately install updates that do not require a restart and do not affect services (start and stop or pause) that are running on the computer as soon as they have been downloaded and are available to install.

• Allow Non-administrators to Receive Update Notifications: This setting provides notifications to users that are logged whether they are administrators or not. The notifications include download notifications as well as installation notifications.

• Automatic Updates detection frequency: This setting tells the WSUS client computer how often to check the WSUS server for updates.

  • Enabled: If selected, an administrator can specify the interval between updates. The default is 22 hours and the range is from 1 to 22 hours. Even though 22 hours is selected, it is possible to overwhelm the WSUS server, so the actual time is the number of hours minus a random interval of up to 20 percent of the length.

  • Disabled or Not Configured: If selected, the default of 22 hours is used.

• No auto-restart for scheduled Automatic Updates installations: This setting will wait for a computer to be restarted by the user to complete any updates that require a restart rather than force a restart. The options include:

  • Enabled: If selected, the computer does not restart automatically if a user is logged on. The user is notified to restart the computer.

  • Disabled or Not Configured: If selected, after the update is complete, any logged on users are notified that the computer will be restarted in five minutes. The computer will then restart in five minutes and will forcibly disconnect users.

• Remove Links and Access to Windows Update: This setting stops all users and administrators logged on to the computer from getting updates from Windows Update. This setting forces all updates to come from the WSUS server. With this setting enabled, the Windows Update and Microsoft Update shortcuts on the Start menu are removed and any attempts to manually connect to Microsoft Update are prevented.

• Reschedule Automatic Update scheduled installations: This setting specifies what actions should be taken after a computer comes back up if a previously scheduled update was missed. The options include:

  • Enabled: If selected, the value for the number of minutes must be entered. After the number of minutes specified pass, then the scheduled installation that was missed will begin.

  • Disabled: If selected, a missed scheduled install will not be made up. The missed schedule will be included in the next scheduled installation.

  • Not Configured: If this setting is not configured, the missed scheduled installation starts one minute after the computer comes back up.

When selecting the setting and choosing the options, it is important to weigh user productivity against security improvements (through having current updates in place).

Reports

With the WSUS server in place, updates downloaded and approved, and clients configured, the computers on the network are much more secure. It sure would be nice if there were a way to generate reports to verify that all of the computers are updated properly. Wait … yep, WSUS does include the capability to generate reports on the updates and the computers.

WSUS includes a nice reporting component that can provide administrators with a number of different views of the status of updates and computers in the WSUS environment. As previously discussed, WSUS client computers check in to the WSUS server only every 22 hours by default. Reports should not be run until a full day has passed to make sure all client computers have had a chance to report in. If an administrator needs to force the contact of a client computer, it can be done from the client computer by running wuauclt.exe /detectnow at a command prompt without the quotes.

Important 

The 22-hour default setting can be changed using a group policy setting. In the Group Policy Object editor, click on and expand Computer Configuration, Administrative Templates, and Windows Components, and then click Windows Updates. In the right-hand details pane, click Automatic Update detection frequency and then set the option to the length desired.

The reports page provides these main reports:

• Status of Updates: This report provides the status of all administrator-approved updates by computer and by computer group. The updates can be viewed by computer and computer group in this report as well as at a high level for the WSUS clients reporting to the server. By default, the report lists updates alphabetically. The report can be sorted by approval action and by computer groups by clicking View, selecting the proper options, and then clicking Apply.

• Status of Computers: This view provides the status of all WSUS client computers and the status of the updates for those computers.

• Synchronization Results: This view provides a list of all of the new updates available, update revisions, and any errors during the synchronization process.

• Settings Summary: This report provides a summary of the WSUS configuration settings that are configured on the options page.

Compliance Reports

A common item for IT audits is a request for compliance reports showing that updates have been installed. WSUS provides two different compliance reports: one for WSUS client computers, and one for specific updates.

To run a WSUS client computer compliance report, follow these steps:

1. Click Computers on the WSUS console toolbar.

2. Click on the individual computer.

3. Click Print status report.

4. Select File Print.

To run an Update compliance report, follow these steps:

1. Click Updates on the WSUS console toolbar.

2. Click on the individual update for the report.

3. Click Print status report.

4. Select File Print.

Reporting functionality is an extremely valuable feature in the WSUS server.

Using the Command Line

As with most products, Microsoft provides a command-line option for managing WSUS. In some cases, the command-line option is easier and provides more options. This section covers some of the more popular commands to complete specific tasks and does not attempt to cover all of the options available.

Open a command prompt and navigate to the Tools folder located in the Update Services folder in Program Files of the drive where you installed WSUS. At the command prompt you should see something like C:\program files\update services\tools>. This folder contains WSUSutil.exe, which can be used to manage the WSUS server. The following commands are available through WSUSutil.exe.

• import/export: One major task that is often run on a regular basis on networks where there is a WSUS server with limited or no Internet bandwidth is the export of the WSUS metadata from one WSUS server to another. The import/export process is used only for metadata and is not used to copy configuration settings, update files, or approvals from one WSUS server to another. The process requires two steps:

  • export: The export command is used to package up the metadata on a server with Internet access that is able to download all of the metadata from Microsoft Update. The result of this command is the creation of a .cab file. From the command line, run wsusutil export packagename.cab logfilename. The packagename and logfile parameters can include a path name along with the file name. The log file can be used to verify that the command ran properly without errors.

  • import: The import command is used on the target WSUS server to extract the metadata from the package created by the export command. From the command line, run wsusutil import packagename.cab logfilename. The packagename and logfile parameters can include a path name along with the file name. The log file can be used to verify that the command ran properly without errors.

• Movecontent: This command is used to change the location of the update files from one drive to another when the hard disk is almost full or when the hard disk has crashed and is no longer functional. Using the movecontent command copies all of the update files and changes the WSUS metadata in the database to point to a new location for the update files. The update files content location required NTFS during the install of WSUS, and this command also requires that the target location be formatted using NTFS as well. If the drive containing the update files has failed, and the content has already been restored to the new location using backup tools, this command still needs to be run to properly set the database metadata to point to the new location. If the update files were replaced using another method, the movecontent command will not re-copy the files. In the event that the update files have been lost and cannot be restored or copied from another location, the movecontent command will initiate another download from Microsoft Update for all missing files. From the command line, run wsusutil movecontent contentpath logfile-skipcopy without the quotes. The skipcopy switch is used if the update files have already been placed into the new location using some other tool or process so that the movecontent command will not attempt to copy the update files at all. The skipcopy switch is optional. The contentpath and logfile parameters can include a path name along with the file name. The log file can be used to verify that the command ran properly without errors.

• reset: The reset command is used in troubleshooting scenarios in most cases. The reset command ensures that metadata and the update content files all match up. If update files are missing, they are re-downloaded from Microsoft Update. From the command line, run wsusutil reset.

• Deleteunneededrevisions: This command cleans up the metadata and deletes information for unneeded revisions or versions from the database. This command is often used when the MSDE database is used on Windows 2000 WSUS installations to clear up space when it nears its 2GB capacity limit. Once the MSDE database fills up, administrators are not able to synchronize with Microsoft Update, approve updates, add new computers, move computers between computer groups, or import events from WSUS client computers. Unneeded revisions are those that have been revised by new releases and those that have not been deployed to WSUS client computers for at least one month. The one-month limit is changed by WSUS when running the deleteunneededrevisions command if the command reduces the database (if it is over 1GB in size) by less than 25 percent. If the command does not shrink the database by at least 25 percent, it will attempt to gain space by changing the time from one month to a lower number of days so it can free up enough space. Before running this command, stop the World Wide Web Publishing Service and then restart the World Wide Web Publishing Service after completion of the command. From the command line, run wsusutil deleteunneededrevisions.

  Many other commands can be run with the wsusutil command-line tool. To see the options and get more information, run wsusutil /? from the command line.

The command line does not provide all of the functionality of the WSUS console, but it does provide some support that just is not available via the console.