Considerations for multiple WSUS instances sharing a content database when using System Center Configuration Manager, but without Network Load Balancing (NLB)

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.

Comments (11)
  1. justin says:

    This is a very cool solution when it comes to responding to load requirements and gets me one step closer to being able to say “yes SCCM does HA”. Let’s get a solution for that sitevserver role so I can finally provide that (telling a client that has extensive SCO run books and SCSM workflow integration that there isn’t a built in way to achieve HA rarely sits well).

  2. Anonymous says:

    227 Microsoft Team blogs searched, 60 blogs have new articles. 150 new articles found searching from

  3. Anonymous says:

    Recent Releases :

    EF6.1.0 RTM Available – 17-Mar-2014

    OData 6.1 and OData Client 6.1 are now

  4. Anonymous says:

    Buenos días,

    En nuestra documentación en TechNet se recomienda el empleo de una base

  5. Ravi says:

    Please expand on this with detailed instructions

  6. Seve says:

    You make it sound like this is a load balancing method where some clients talk to one SUP and others talk to another SUP. It is my understanding that only one SUP can be used at one time in a Primary site and installing multiple SUP’s is strictly for failover
    not load balancing.

  7. John Andre says:

    A bit of more details would be nice.
    If you already utilze wsus and SUP for patching. Do you still follow these steps to add a new server?

    3.Install other WSUS servers creating database
    Or would this actually delete everything you have in the database from before?

  8. Eric says:

    More information with detailed deployement can be referenced here:

  9. Marcos says:

    How does one apply the WSUS patch KB2938066 in this case? Just follow the instructions for NLB but skip the NLB suspend/start steps?

Comments are closed.

Skip to main content