NLB is not supported on WSUS 2.x or earlier versions. WSUS 2.x is out of support and if you are still using it, you should upgrade to WSUS 3.2 which is available free of charge from Microsoft.

Requirements for NLB in WSUS 6.x

The requirements to run WSUS in a NLB cluster include:

All nodes in the NLB cluster should be running the same version of WSUS and the same version of Windows, and should have the same Windows Updates installed. Prior to Windows Server 2012, the same WSUS-specific patches must also be installed across all servers in the cluster.

SQL DB should be shared across all WSUS from the same NLB (WID is not supported for NLB, and the SQL DB need not be clustered -- though it may be clustered) *

Content directory should be shared across all WSUS in that NLB cluster (see "Configuring Content Sharing") below*

* If you are not running WSUS in a NLB configuration, then the WSUS servers must not share a database or content directory.

Prior to Windows Server 2012, WSUS 3.2 requires a special set up command line as described in the Network Load Balancing topic in WSUS 3.x documentation. Please refer to that documentation (in the in-box HTML help/CHM file) if you are using WSUS 3.2.

Additionally, all requirements for NLB also apply above and beyond the requirements discussed above.

Sample test configuration

WSUS 6.3 --- Windows Server 2012 R2 (2 units)

SQL Server --- SQL Server 2012 SP1 (1 unit)

WSUS Client ---- Windows 7 SP1 (1 unit)

Step 1. Install WSUS

The steps to install WSUS are the same for NLB and non-NLB scenarios. You can install WSUS using PowerShell or Server Manager.

Note: When you use PowerShell to install WSUS 6.x, you must run post-installation tasks from the command line.

Option1: Install WSUS for NLB using PowerShell (recommended)

Run this PowerShell command to install WSUS and the RSAT management tools:

SQL_INSTANCE_NAME is the name of the SQL Server & CONTENT_DIR is the path to the directory where downloaded update files will be stored. CONTENT_DIR should be a UNC path, as mapped network drives are NOT supported. For example, for example \server1share1contentdir would be valid. Z:contentdir would NOT be valid.

For simplicity in testing, you can use an account that has administrator privileges on the SQL server, and you can also use the default instance. You don't need to specify a named instance.

This step should be run in serial (not in parallel) across all WSUSs in the NLB.

All WSUS servers in the NLB group must use the same content directory and the same SQL database.

Option 2: Install WSUS for NLB using Server Manager

Alternatively, you can install WSUS using the Server Manager GUI.

Launch Server Manager

Select “Add roles and features”

Click Next until reaching “Server Selection” tab, and select the server name to perform installation.

You should create a single shared file location that is available to all of the front-end WSUS servers. You can use a standard network file share and provide redundancy by storing updates on a RAID controller, or you can use a Distributed File System (DFS) share. The domain machine account of each front-end WSUS server must have Change permissions on the root folder of the file share. That is, if there is a WSUS server installed locally on the computer that has the DFS share, the Network Service account should have change permissions on the root folder. In addition, the user account of the administrator who will run WsusUtil.exe movecontent should have Change permissions.

After you install a WSUS update, check the NTFS file system permissions for the WSUSContent folder. The NTFS file system permissions for the WSUSContent folder may be reset to the default values by the installer.

It is not necessary to use a DFS share with an NLB cluster. You can use a standard network share, and you can ensure redundancy by storing updates on a RAID controller.

In our own NLB test environment, we have the following settings set to ON:

Single affinity

Unicast

“Enable spoofing MAC Address” ON (for the NIC in Hyper-V, if you are using a VM)

Step 4. Check that things are working

4.1. Test that the master server can switchover in the event of downtime

Run the following command to ensure that multiple servers are listed:

Wsusutil listfrontendservers

Shut down the master server. Then run the command again (on a different WSUS machine) and verify that the master server has been switched.

4.2. Test the WSUS client connection

On the WSUS server, assuming that you are using the default port (8530), run the following command

netstat -nao | find "8530"

Verify that clients are able to connect. On a client machine which is configured to use the WSUS NLB cluster, run the following command:

wuauclt /resetauthorization /detectnow

Upgrade/Patch Considerations

Because of sharing same DB, patching can be tricky because only WSUS machines with the same version must be sharing DBs, as the DB schema could be changing as part of the patching.

If you are running WSUS in a NLB configuration, then you must upgrade all WSUS servers together. To do this, disconnect each server from the database & upgrade, then once all servers are disconnected from the database & content directory, you can start re-connecting WS2012 servers to the database & content directory. For one NLB cluster sharing a single database, you could follow these steps:

Backup the database.

Remove all WSUS machines from the NLB.

Stop the IIS services in all machines: ‘Net stop w3svc’

Stop the wsus services in all machines: ‘Net stop wsusservices’

Perform patching on all WSUS

From 1 of the WSUS machine, run postinstall. This will update the database, so it is not needed to be rerun from other servers.