You can manage the list of approved updates independently on each WSUS server in a hierarchical topology. But keep in mind that the most upstream server approves updates from Microsoft Update and downstream servers download only updates that the upstream server has approved. Downstream servers don't know about updates that the upstream server doesn't approve. Upstream servers in effect provide a global approval list, and downstream servers maintain the same list of updates or a subset of the list.
Because each server in a hierarchical topology lets you approve and target updates independently, you can choose whether to use a centralized or decentralized management model. For a distributed, centrally managed hierarchical topology, configure downstream servers to automatically accept all updates that the upstream server approves. For a distributed, decentralized hierarchical topology, let downstream WSUS server administrators configure their own approvals or auto-acceptance rules. This practice is common in large enterprises with geographically distributed business units. A central WSUS server manages the global list of approved updates, and administrators for downstream servers manage approvals for clients that use those servers.
If you employ a hierarchical model, don't use the deferred download option (which I discuss in an upcoming article). This option can delay update distribution to downstream clients, particularly in a hierarchy more than one level deeper than the most upstream server.
Remember that WSUS servers are also clients and must also be updated. In a hierarchical model, you need to direct the WSUS servers to the most downstream WSUS server for updates, which seems counterintuitive. The reason for this requirement is to allow for future patches to WSUS files. If Microsoft releases a WSUS patch and an upstream server patches itself in such a way that it prevents downstream servers from communicating with it, the update will never travel downstream and all updating will stop. Thus, you need to allow updates to travel all the way downstream before WSUS servers update themselves. In addition, the most downstream server must update itself last. The recommended method to achieve this goal is to target the server separately (i.e., place the server in its own target computer group) and approve WSUS-related updates after they are applied to existing WSUS servers. Finally, to ensure that updates travel downstream before the WSUS servers update themselves, keep your model relatively shallow.
Replica servers. A replica server is a mirror of an upstream WSUS server. Figure 4 shows a replica WSUS topology. Unlike a downstream server in a hierarchical topology, a replica replicates its upstream partner's entire configuration, including updates, approvals, targeting, and groups. The only thing a replica manages uniquely is computer group membership. Because a client points to only one WSUS server, a computer belongs to a group on only one WSUS server. The replica contains the same group names as the upstream server, and approved updates are targeted identically, but group membership is unique to the replica.
For example, an enterprise might decide on a computer group targeting model that includes the computer groups Test, Critical, Important, Low Risk, and Do Not Update. In a replica topology, the updates that the administrator approves and targets to each group synchronize to each replica server. Each branch office or business unit might host a replica WSUS server. Replicas then manage the membership of their own groups.
This topology supports a centralized update approval strategy but distributes the updates themselves to multiple servers. You configure replica servers during WSUS installation. To configure an existing WSUS server as a replica, you must reinstall WSUS.
Disconnected servers. WSUS lets you use the Wsutil command-line tool to export updates from one update server and import them to another. This export/import feature is useful for updating clients that reside on a portion of the network that's disconnected from the Internet or the rest of the network. For example, an organization with black box or classified networks might use this approach. An administrator exports approved updates from a connected WSUS server, transports them on removable media to the disconnected network, and imports the updates to the disconnected WSUS server.
Multiple servers. A multiple-server topology is simply a replication of a single-server topology. Multiple WSUS servers obtain updates from Microsoft Update. Each server is managed separately and can have a unique configuration and unique settings and approval lists. This topology can be useful in a highly decentralized enterprise in which each business unit is responsible for managing its own updates.
A multiple-server topology is also necessary if you have users who dial in to your network or use a VPN connection. Suppose you have a corporate WSUS server that stores approvals and updates locally. Internal clients are directed to that server for approvals and updates. To minimize bandwidth usage, you want to direct remote users to the WSUS server for update approval and reporting but to Microsoft Update to download updates, as Figure 5 shows. A problem arises because the internal clients' WSUS server stores update files locally but the remote clients' WSUS server doesn't. Downstream hierarchical and replica topologies require all servers to use the same update file storage location. Thus, you need a standalone WSUS server for remote users. You must manually approve updates on this server separately from the internal WSUS server—you can't export and import update approvals only.
Microsoft needs to address this scenario in WSUS's next release. An alternative solution is to configure the internal server to download express installation files. The efficiency of delta updates and BITS 2.0 might eliminate the need for a separate WSUS server for remote-user update approvals.
Prev. page
1
2
[3]
4
next page 
