Home
.. About WSUS Wiki

WSUS
.. WSUS FAQ
.. WSUS on SBS
.. WSUS Troubleshooting
.. WSUS News Groups
.. Known WSUS Issues
.. WSUS Links
.. WSUS Wish List

WSUS Documents
.. WSUS Deployment Guide
.. WSUS Installation Guide
.. WSUS Release Notes
.. WSUS Best Practice

SUS
.. SUS FAQ
.. What Is SUS
.. SUS Troubleshooting
.. SUS Links
.. SUS Known Issues
.. SUS FAQ
.. What Is SUS
.. SUS Troubleshooting
.. SUS Links
.. SUS Known Issues

by Alex Harden (aharden at tycoelectronics.com)

Abstract

Construct two parallel Windows Server Update Services (WSUS) instances on two separate servers and use a DNS alias to direct Automatic Updates (AU) clients to the primary server.  The secondary server is then available for immediate use in the event the primary server becomes unavailable.

Background

WSUS's replica server mode is an acceptable method of bringing up synchronized remote WSUS servers that share the configuration of a parent WSUS server.  However, a WSUS replica server's settings can't be changed (save for synchronization options) and it can't be converted to a fully-configurable WSUS server in-place.  This means that if one constructs a WSUS infrastructure with a single master server and one or more downstream replica servers and their master server fails, they will have to restore or construct a new master WSUS server to replace it.  This could be potentially time-consuming and would prevent their WSUS environment from deploying new updates or changing update approvals until the new WSUS master server became available. 

Using Group Policy to assign WSUS settings, including target computer group names, to AU client computers enables one to very quickly move clients from one WSUS server to another, since the AU client software is stateless.  Since no authentication or prior relationship has to exist between an AU client and a WSUS server, an AU client talking to a particular WSUS server for the first time should communicate all the information required to determine what updates approved for its assigned computer group are required to be installed.  This makes it possible to redirect AU clients to another properly-configured WSUS server with minimal downtime in the event of a disaster or a desired change to the WSUS infrastructure.

This recipe assumes that the reader knows how to install and configure WSUS and Active Directory (AD) Group Policy Objects (GPOs), is familiar with the WSUS related GPO settings, and is able to create and change a DNS alias in their environment.

Requirements

• Two separate servers capable of hosting WSUS (I recommend hosting the WSUS database on a separate back-end SQL server if available)
• A DNS alias that can be edited to point to either WSUS server (ex. wsus.mycompany.com); initially point it to the primary WSUS server
• WSUS servers are set to use Group Policy or registry settings to assign computers to groups (in Computer Options)
• WSUS GPOs that correspond to each defined WSUS computer group, pointing the client to the WSUS DNS alias name

Setup

1. Completely configure two WSUS instances as standalone servers, not replicas, with exactly the same settings.
   
• They should both be configured to download updates from Microsoft, or to redirect clients to download updates from Microsoft (if applicable to your environment).  Neither should be set to download updates from the opposite WSUS server. 
• The servers should have unique computer names that are something other than the WSUS DNS alias name.
• Prior to the first synchronization, go into the "Update Files and Languages" section of Synchronization Options in WSUS and make sure your supported languages are all selected.  I've found that changing this option after having approved and downloaded a lot of updates has the potential to put the server in an unstable state.
• After the initial synchronization, go into the "Products and Classifications" section of Synchronization Options in WSUS and select the products and classifications you want.
2. Create the same WSUS computer groups you plan to use on both servers.  These should be consistent with the target group names that are set in the WSUS-related GPOs.
3. Approve the same updates for the same computer groups on both servers.  As new updates come out or new approval decisions are made, these will need to be implemented on both servers at roughly the same time to keep the servers in synch.  Besides the extra resources required initially for the secondary WSUS server instance, the extra time required to maintain updates and approvals on the secondary server is the price paid for higher availability.
4. Once the update files are downloaded (if applicable), both servers are ready for use.  If things are properly configured, clients will check in and report to only the primary WSUS server.
5. The secondary WSUS server's functionality should be tested by pointing test servers directly to its computer name.

To Fail Over From Primary to Secondary WSUS Instance

1. Reassign the WSUS DNS alias name to the secondary WSUS server.
2. As the DNS change redirects AU clients to the secondary WSUS server, they will start to check in and show up in the secondary server's administrative interface.
3. If the primary WSUS server is still online:
• As AU clients stop checking into the primary WSUS server, they will not automatically be removed from the primary server.  However, their "Last Status Report" values in the administrative interface should get older after they start checking in to the secondary server.
• WSUS computer objects with "Last Status Report" times of a few days in the past can be safely removed from the primary WSUS server, if desired.
4. Once all AU clients are checking in to the secondary WSUS server, it can safely be designated the primary WSUS server.

Notes

• Repeat the "fail over" instructions to move clients back to a rebuilt/restored primary WSUS server.  Use the information from the production WSUS instance to ensure that a newly built recovery WSUS server is configured identically to the production instance.
• Downstream replica servers will fail over in a manner similar to the AU clients.  In my testing, replica servers did not re-download update data that they already possessed.  Failing over a master WSUS instance should not produce a large amount of network activity between the new master instance and a replica instance if the new master instance is configured identically to the old master instance.  However, the initial synchronization to the new master instance may take longer than usual.