Configuring WSUS 6.x for Network Load Balancing (NLB)

  • Article

Some content in this section was written by Marta Barillas, a SDET on the WSUS engineering team.

This blog post applies to Windows Server 2012 and Windows Server 2012 R2.

  • For instructions using WSUS 3.x with NLB, please see this TechNet article: https://technet.microsoft.com/library/dd939896(v=ws.10).aspx
  • 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)

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

Install-WindowsFeature updateservices-services,updateservices-db,updateservices-rsat

Note: updateservices-rsat is Optional; it will install the WSUS MMC console and cannot be installed when installing WSUS on a Server Core installation.

 

  1. Once you have installed WSUS from the command line you need to run postinstall from the command line.

& 'C:\Program Files\Update Services\Tools\WsusUtil.exe' postinstall SQL_INSTANCE_NAME=<Name> CONTENT_DIR=<Path>

Note:

  • 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 \\server1\share1\contentdir 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.

  1. Launch Server Manager
  2. Select “Add roles and features”
  3. Click Next until reaching “Server Selection” tab, and select the server name to perform installation.

Note: local server is selected by default.

  1. Click Next to “Server Roles” tab, and select “Windows Server Update Services”
  1. A dialog will be displayed asking to include Features required for WSUS installation.
  2. If WSUS Console should not be installed, uncheck “Include management tools” option on the dialog box.
  3. Click “Add Features” on the dialog box.
  • Click Next until reaching “ Role Services” tab, and:
  1. Unselect “WID Database” option
  2. Select “WSUS Services” & “Database” options
  • Click Next to “Content” tab, and type the shared ContentDir path. This should be a UNC path, as mapped network drives are NOT supported.
  • Click Next to “DB Instance” tab, and type the SQL Server machine name.
  1. Click the “Check connection” button.
  • Click Next to “Confirmation” tab
  • Click “Install” and wait for installation to complete.
  • Click on “Launch Post-Installation tasks” link displayed after installation is completed.

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

 

Step 2. Configure Content Sharing

WSUS Content Sharing is required when using a Shared Database. Documentation for creating a shared file location can be found at: https://technet.microsoft.com/library/dd939896(v=ws.10).aspx. Relevant portions of that article are included here:

Create a shared file location

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.

For Windows Server 2012 (WSUS 6.2), The Scripting Guy wrote about the command line and GUI steps to be used to install a Front-End WSUS Server: https://blogs.technet.com/b/heyscriptingguy/archive/2013/04/15/installing-wsus-on-windows-server-2012.aspx

 

Step 3. Install/Configure NLB

The actual configuration of NLB is detailed on TechNet here: https://technet.microsoft.com/en-us/library/cc754833(v=WS.10).aspx

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:

  1. Backup the database.
  2. Remove all WSUS machines from the NLB.
  3. Stop the IIS services in all machines: ‘Net stop w3svc’
  4. Stop the wsus services in all machines: ‘Net stop wsusservices’
  5. Perform patching on all WSUS
  6. From 1 of the WSUS machine, run postinstall. This will update the database, so it is not needed to be rerun from other servers.
  7. Start the wsus services in all machines (if needed): ‘Net start wsusservices’
  8. Start the IIS services in all machines (if needed): ‘Net start w3svc’
  9. Enable WSUS machines on NLB.