Best Practices with Windows Server Update Services 3.0

This section provides a list of best practices for managing updates with WSUS. There are four main sections: one on security practices, one on resource usage, one on setting up a WSUS network, and the last on miscellaneous best practices.

Use the Secure Sockets Layer (SSL) for WSUS connections (server to server, server to client) on all computers that download updates via the Internet. For information about configuring SSL, see the "Securing WSUS with the Secure Sockets Layer" section of the Windows Server Update Services Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=79983).

If you do not wish to use SSL, you can deploy Internet Protocol security (IPsec) on your network to secure network traffic. The Overview of IPsec Deployment page (http://go.microsoft.com/fwlink/?LinkId=45154) offers guidance about how to deploy IPsec in your environment.

Make sure that the WSUS server that downloads updates from Microsoft Update is secured behind a firewall, and allows access only to the domains needed by WSUS. For a description of these domains, see the "Configure the Firewall" section of the Windows Server Update Services Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=79983).

Make sure that WSUS servers have only the file and folder permissions that are needed by WSUS. For a description of the necessary file and folder permissions, see the "Before You Begin" section of the Windows Server Update Services Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=79983).

If a WSUS server is Internet-facing, its database should be located on a different computer that is not reachable from the Internet. For remote SQL Server installation, see "Appendix B: Configure Remote SQL" in the Windows Server Update Services Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=79983).

There are two security groups that are set up for WSUS: WSUS Administrators and WSUS Reporters. WSUS Administrators can perform any WSUS task, while WSUS Reporters have read-only access (view server settings, get reports, and so on). Make sure that the only people in the WSUS Administrators group are the ones who need to perform administrative tasks.

The following practices can help you conserve resources on your WSUS server.

Make sure that your WSUS server is configured to download only approved updates. When the server synchronizes updates, it downloads only the update metadata and will download the update files only after the update has been approved.

Use the Cleanup Wizard on a regular basis. This will keep the number of unneeded updates and revisions to a minimum.

If a WSUS server has a small number of clients, or if most of the clients are "roaming" clients with Internet access, you may wish to host update content on Microsoft Update rather than on the local WSUS server. Clients will get update approvals from the server, but can pull the upload files directly from the Internet.

If you are storing update content locally on your WSUS server, make sure you have enough disk space on the storage partition. Monitor disk usage on this partition carefully. One way to do this is to configure the WSUS health monitoring thread to warn you with an event if disk usage exceeds a specified percentage. For more information about configuring the health monitoring thread, see the explanation of the healthmonitoring parameter of the wsusutil utility in Managing WSUS 3.0 from the Command Line.

Approve only the updates that are really needed on your network. Limit the product updates to the products that are installed on the network. You can also set up separate WSUS servers for computers with different sets of Microsoft products.

Synchronize only the update languages needed on your network. If you need to synchronize more than one language and you are storing updates locally, you should estimate your needed disk space by multiplying the recommended space times the number of update languages. For more information about recommended disk space, see the "Determine WSUS Capacity Requirements" in the Windows Server Update Services Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=79983).

Make sure that your WSUS server is configured to synchronize all the needed languages, because you will not be notified of needed updates in the unsynchronized languages. These updates will appear as “Not Needed” on clients who require the language. To help avoid that problem, make sure to include all operating system languages in your WSUS server's synchronization options. You can see all the operating system languages by going to the Computers view of the WSUS administration console and sorting the computers by operating system language. However, you may need to include more languages if there are Microsoft applications in more than one language (for example, if Microsoft Word in French is installed on some computers with Windows XP in English).

You should allow WSUS to decline expired updates automatically (click Options, click Automatic Approvals, click the Advanced tab, and then click Automatically decline updates when a new revision causes them to expire). If you do not wish to decline expired updates automatically, you should decline them manually on a periodic basis.

You should not choose to synchronize express installation files unless you have a pressing need to minimize downloads between the WSUS server and its clients. Typically, using express installation files reduces downloads from WSUS servers to clients by a factor of two but increases downloads from Microsoft Update (or an upstream server) to the WSUS server by a factor of four. You should decide which criteria are more important to your network: local network bandwidth or server disk space and Internet bandwidth.

Use targeting to control the rollout. You can set up multiple computer groups, then approve large service pack downloads for a subset of these groups at one time.

Use peer caching (available only on Windows Vista and Windows Server 2008 operating systems) to minimize downloads from WSUS servers to clients and maximize the "sharing" of downloads among peer computers on a subnet of the network. This will reduce network load and in particular load on the WSUS server. For more information about peer caching, see Appendix E: Configuring BITS 2.0 and 3.0 for Download Performance.

Consider configuring WSUS clients to synchronize more frequently from the WSUS server and configuring downstream WSUS servers to synchronize more frequently from their upstream servers. This will allow updates to be deployed to clients faster, which could be important if you need to deploy an “emergency update” that must be installed as quickly as possible. This will result in smaller downloads from server to client, but will add additional load to the WSUS server. It will also add additional load to the network when updates are deployed, because clients start downloading updates as soon as they synchronize with the server.

If possible, set up WSUS networks with a hub-and-spoke topology rather than a hierarchical one. The greater the number of tiers in the network, the greater the latency in downloading updates.

Consider using DNS netmask ordering for roaming clients. For more information about setting up this configuration, see "Appendix D: Configure WSUS for Roaming Clients" in the Windows Server Update Services Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=79983).

Configure roaming clients, so they get their updates from the Internet-facing WSUS server, if they do not usually connect to your local intranet.

Client computers (and most servers) often need restarts after an update is installed. Deferring the restarts will put machines in an unsupported and unstable state, which may include mismatched client and server binaries. These computers should be set up to get automatic downloads and scheduled installs. You can pick a time for scheduled installations when there is little chance for lost productivity (for example, on Sunday at 3:00 A.M). For information about setting up client computers for a scheduled installation, see the "Configure Clients Using Group Policy" in the Windows Server Update Services Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=79983).

Critical servers cannot generally be restarted daily. If this is the case, you can either configure them for installations at longer intervals (weekly), or configure them to get automatic downloads but manual installations at a time when the servers can be restarted if necessary.

Configure e-mail notification to tell you when updates become available, so you can plan the deployment of these updates in advance.

If you need to deploy an “emergency update” and can’t wait for the next scheduled installation, approve the update with a deadline in the past. This will cause the update to be installed the next time the clients synchronize from the server. If you can’t wait for the next synchronization, create a script to automate installing the updates and then restarting your server. For more information about creating scripts to automate Automatic Updates tasks, see the Windows Update Agent Software Developer's Kit (http://go.microsoft.com/fwlink/?LinkID=43101).

Configure client computers or WSUS servers to immediately install updates that do not require a restart. For information about setting up client computers for a scheduled installation, see the "Configure Clients Using Group Policy" in the Windows Server Update Services Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=79983).

The following practices will help you ensure that WSUS servers are always available to their clients.

There are typically two different backup strategies. The first is a standard backup and restore strategy. For information about backing up and restoring WSUS, see Backing Up Windows Server Update Services 3.0. This strategy requires more work to maintain and requires extra storage for the backup files, but makes it possible to restore the system to a known state without needing to download the update files once more. The other strategy is to rebuild the server. This is a fairly fast operation and is preferred by many customers, because it requires less work and less disk space.

Consider using network load balancing if you have a requirement for high availability. Load balancing involves a more complex configuration and is not typically considered necessary, because new updates are not released very frequently. For more information about setting up network load balancing, see "Appendix C: Configure Network Load Balancing" in the Windows Server Update Services Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=79983).

You should thoroughly test large bundles of updates such as service packs to ensure that they do not break line-of-business applications. A typical test strategy is to set up test computer groups in which the test computers are configured with the same applications as the production groups, approve installation only to these groups, and then verify that the applications continue to function correctly.