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.
- Install SQL
- Install first WSUS server creating database
- Install other WSUS servers creating database
- Create share for content (computer accounts must have change permission)
- On first WSUS server Use WSUSutil movecontent to change location
- 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).
- Add SUP (Software Update Point) role to first server and synch.
- 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.