WSUS Product Team Blog

WSUS Product Team thoughts, information, tips and tricks and beyond :-)

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

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

  • Comments 9
  • Likes

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.

  • 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).

  • thank you indeed

  • Please expand on this with detailed instructions

  • 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.

  • Thanks for sharing.

  • 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?

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment