Professional MOM 2005, SMS 2003, and WSUS

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:

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:

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:

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:

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:

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:

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:

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:

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

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.

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:

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:

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:

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.

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.

Related

Категории