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

Did you know that 80% of the content in Microsoft Update (MU) is drivers? Drivers represent a huge amount of content, so if your organization has standard devices, or you know what drivers are needed by your users, you can dramatically reduce the amount of metadata and content in your WSUS server by not syncing the "Drivers" category to WSUS.

Instead, you can selectively import drivers from the catalog by using a feature in the WSUS UI. Please note, this is only available through a WSUS Management Console of same version as the WSUS Service that is connected to in remote scenarios.

1. Launch WSUS console
2. Click on the “Updates” node (left panel)
3. Click on “Import Updates” (right panel)
4. Search and download the update from the opened IE page

Once you have downloaded the update using the Microsoft Update Catalog, the update will appear in "All updates." From there, you can approve the update, assign it to target groups, and set deadlines.

click the screenshot above to enlarge

When you use System Center Configuration Manager (SCCM) to manage updates, SCCM causes clients not to use WSUS servers directly for all operations (such as reporting). In this configuration, it is possible for multiple WSUS instances as part of SCCM to share the same database but not be configured as a NLB cluster. Technet states:

When you install more than one software update point at a primary site, use the same WSUS database for each software update point in the same Active Directory forest. If you share the same database, it significantly mitigates, but does not completely eliminate the client and the network performance impact that you might experience when clients switch to a new software update point. A delta scan still occurs when a client switches to a new software update point that shares a database with the old software update point, but the scan is much smaller than it would be if the WSUS server had its own database.

To set up such a configuration, you would install multiple SCCM SUPs with WSUS on shared database, configure WSUS/SUP to store content on a file share, but stopping short of enabling NLB.

1. Install SQL
2. Install first WSUS server creating database
3. Install other WSUS servers creating database
4. Create share for content (computer accounts must have change permission)
5. On first WSUS server Use WSUSutil movecontent to change location
6. On each WSUS server, in IIS ensure the “Content” virtual directory path is set to the share, and specify an account to use to connect to the path (to cater for anonymous access).
7. Add SUP (Software Update Point) role to first server and synch.
8. Add SUP role to other servers.

Rather than connecting to WSUS directly, clients are choosing a random SUP to connect to (which is their expected behavior, and why the NLB is not needed on the server side). This is a supported configuration of WSUS, but only when WSUS is being used in a SCCM deployment.

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: http://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: http://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: http://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: http://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.