STEP 4: Decide Which Update Files to Use
After clients connect to a WSUS server, they obtain a list of approved updates from it, report whether the updates are necessary, and inform the server of the updates' installation status. You can specify whether clients download updates from the WSUS server or from Microsoft Update.
The advantage of storing update files locally is that you minimize the use of external links: The WSUS server downloads update files to the network, then distributes them to clients. BITS 2.0, the technology that downloads updates from Microsoft Update to WSUS and then to clients, uses network bandwidth more efficiently than does Microsoft Software Update Services (SUS). If a client's network location makes downloading updates from the WSUS server inefficient, you can configure WSUS to let clients obtain the list of approved updates from the server but download the updates themselves from Microsoft Update.
A useful feature is express installation files, which lets WSUS distribute only changed bits of files rather than entire updates. Clients apply the revised bits to the existing files. An express installation update is sometimes referred to as delta delivery because clients download only the difference, or delta, between file versions.
A drawback of express installation files is that the WSUS server must download a different variation of the delta for each version of a file. Instead of downloading only one update file, the server downloads a file that contains all possible variations. However, express installation still saves network bandwidth because clients download only the bits necessary to patch their current file version. Figure 1 illustrates the difference between a full file update and an express installation file update.
STEP 5: Develop a Group-Targeting Strategy
WSUS lets you create target groups of clients and approve updates for particular groups. Design your groups to support your update strategy. Common strategies are grouping clients by type (e.g., server, desktop, laptop), role (e.g., executive, development), update rollout phase (e.g., test, pilot, deploy, do not patch), client configuration (e.g., simple/ managed, complex/unmanaged—computers with complex configurations and unmanaged computers are difficult to troubleshoot or roll back), and update priority (e.g., critical, normal, low).
After you decide on a computer grouping, you need to determine which computers belong in each group and decide which WSUS server each computer will download updates from. These considerations affect your topology, which I discuss next. Implementing computer groups on WSUS is complicated; I'll discuss the process in a future article.
STEP 6: Design a Topology
After you complete the planning phase, you can evaluate WSUS topologies and determine how to best design your environment. Server configuration options include single, hierarchical or chained, replica, disconnected, and multiple.
To implement a topology, go to the WSUS administration Web site, http://WSUSservername/WSUSAdmin (where WSUSservername is the name of your WSUS server), and click Options, Synchronization Options. In the Update Source section, you'll see the options for obtaining updates. The first option, which is the default, obtains updates from Microsoft Update. This configuration is the basis for a single-server topology. You can also have WSUS obtain updates from an upstream WSUS server.
Single server. Using one WSUS server is the most straightforward topology. If your organization's update infrastructure can function with only one server, select Microsoft Update as the update source. After your server downloads updates, you can approve them and target them to groups of computers, and clients will download the appropriate updates from the server. You can use target groups, which I discuss in more detail in an upcoming article, to distribute updates to specific computers. Figure 2 illustrates a single-server topology.
Hierarchical or chained servers. If your site has many clients, you might want to deploy multiple WSUS servers to improve performance. You can have multiple servers in one location to support a large user population or distribute updates to servers in different locations, as Figure 3 shows.
If you use a single-server topology, the WSUS server obtains updates from Microsoft Update. In a multiple-server configuration, however, servers often obtain updates from other WSUS servers. The server that provides the updates is the upstream server; servers that download updates from an upstream server are referred to as downstream servers. Although the hierarchical structure technically has no depth limit, Microsoft has tested a depth of only five WSUS servers. The acceptable lag time between an update's approval on the most upstream server and when the approval installs on downstream servers and clients determines a hierarchy's maximum depth; three levels deep is the recommended maximum.
To properly implement a hierarchical topology, you must understand how configuration and updates are handled. You need to maintain a consistent configuration throughout the hierarchy. For example, each server must use the same update file storage location—a server can't store update files on Microsoft Update if an upstream or downstream server stores the files locally, and vice versa. Content filters (i.e., subscriptions to product categories, update classifications, and languages) must also be uniform. And if you use express installation files, you must do so consistently.
Prev. page
1
[2]
3
4
next page 
