If your organization includes WSUS servers on disconnected networks, you can follow a two-step export and import process [see Figure 9.4] to update those replica servers.This process requires additional management overhead, but it does guarantee update consistency between all WSUS servers; however, there can be a high degree of lag time for this type of asynchronous synchronization. Good planning will optimize the process and minimize the time it takes to synchronize WSUS servers on disconnected networks.
Figure 9.4 Two-Step Export/Import Process for Disconnected Networks
Before attempting to export and import updates between the export server and the disconnected import server, you must first match the advanced synchronization options between the source and destination WSUS servers.This includes the express installation files feature and languages.This ensures that you collect the type of updates you intend to distribute.You do not have to worry about matching settings for schedule, products and classifications, source, or proxy server, because the import steps eliminate the need for these settings. If you are deferring downloads on the export server until updates have been approved, you must approve any pending updates so that they can be downloaded prior to migrating updates to the import server.
Shortcuts...
Detailed Steps for Updating WSUS Servers on Disconnected Servers
The following are suggested steps for managing the synchronization of updates between disconnected WSUS servers:
1. Copy updates from the export server to the import server. By default, updates are stored in the following folder:
Continued
C:\WSUS\WSUSContent. If you specified a different location during the setup process of the export server, use that path instead.
2. Export update metadata from the database on the export server, and import it into the database on the import server. You accomplish the metadata import and export by using the command-line utility WSUSutil.exe. You must be a member of the local Administrators group on both WSUS servers to export and import metadata. In addition, both operations can only be run from the WSUS servers. Be sure that you are logged on locally onto the export server before performing the export operation, and logged on locally to the import server before attempting to import the metadata.
You can use a file system backup utility to copy update files from the export server to the import server. You should capture and maintain the folder structure for the WSUSContent folder, and the update files should be copied to the local source repository on the import server [this may or may not be the same path as the export server]. You can limit how data is copied by making incremental backups rather than full backups of the WSUSContent folder.
Best Practices According to Microsoft_
Automatic Updates Configuration for WSUS Servers
If you chain multiple WSUS servers together, Microsoft recommends the following technique to prevent propagating updates with changes that break the protocol for server-to-server communication.
WSUS administrators should point Automatic Updates on all WSUS servers to the deepest downstream WSUS server in the hierarchy. This shields the entire chain from server-to-server protocol-breaking changes, because the downstream WSUS server can be used to update the broken upstream WSUS servers via Automatic Updates.
Export/Import for Disconnected WSUS Servers
Microsoft recommends that you copy updates to the file system of the import server before you import metadata. If WSUS finds metadata for an update that is not in the file system, the WSUS console shows that the update failed to be downloaded. This type of problem can be fixed by copying the update onto the file system of the import server and then again attempting to deploy the update.
Some Independent Advice_
One of the often overlooked benefits of WSUS versus other patch management products is that WSUS is based on standard Web technology. Updates are distributed via Hypertext Transfer Protocol [HTTP] and Hypertext Transfer Protocol Secure sockets [HTTPS] over ports 80 and 443, respectively. And with Microsoft's Background Intelligent Transfer Server [BITS] technology, WSUS is highly recoverable, allowing interrupted sessions to resume where they left off when connectivity is re-established with WSUS servers. Since BITS uses stateless session with the source Web server, it is possible to develop a highly scalable and highly available solution for WSUS using multiple WSUS servers.
Since Microsoft typically releases there patches on the third Tuesday of the month [commonly referred to as "Patch Tuesday"], a WSUS server managing hundreds or thousands of clients at a single site can become overloaded and perform poorly as clients retrieve their updates. Even worse, if you plan on using WSUS to distribute service packs for Windows or Office, you will quickly find out that just a few WSUS servers is not enough to handle that large of a load.
One solution is to selectively assign clients to specific computer groups managed by different WSUS servers. This type of solution, however, is not very flexible and requires lots of planning to distribute the load evenly between multiple WSUS servers.
Another solution would be to use a common Domain Name Service [DNS] alias with the Internet Protocol [IP] address for each WSUS server. Using round-robin DNS name resolution will balance connecting clients across WSUS servers fairly well; however, clients will be sent to WSUS servers that are offline or otherwise not responding, causing updates to fail.
A more elegant solution to this problem would be to use load-balancing technology. Microsoft's Network Load Balancing [NLB] service or, even better, a network load-balancing appliance or switch provides an effective solution with some intelligent rules to optimize the utilization of your WSUS servers while guaranteeing successful updates for client computers. Switch manufacturers such as Cisco and Nortel produce inexpensive load balancers. Even better, if your WSUS servers are running on blade servers you can provide load-balancing services inside the blade chassis. Both IBM and HP provide Layer 4-7 switches for their chassis, and Dell provides a software-based solution to load-balance functionality to their blades.