locked
Redundant WSUS Servers RRS feed

  • Question

  • We have two sites - a main and a secondary.  We have a WSUS 3.0 SP2 box in one site that services both sites, as well as CISCO NAC clients being remediated before coming in through our SSLVPN.  We would like to provide a second WSUS server in the other site to provide redundancy in case NAC clients are connecting while either site or WSUS server is down.  Can this be done?  The hurdles that we see are registrations showing up on both WSUS servers, as well as the fact that the  field in group policy where you configure the Automatic Updates server only accepts one value...

    Has anyone else looked at this and is there a way to provide redundancy for WSUS servers?
    Thursday, September 17, 2009 5:06 PM

Answers

  • We have two sites - a main and a secondary.  We have a WSUS 3.0 SP2 box in one site that services both sites, as well as CISCO NAC clients being remediated before coming in through our SSLVPN.  We would like to provide a second WSUS server in the other site to provide redundancy in case NAC clients are connecting while either site or WSUS server is down.  Can this be done? 

    Yes --- but it's a complicated setup. There are two ways you can approach this. The option presented as Option #1 is offered first because you have the servers split across sites.

    Option #1: Review the section Appendix D: Configure WSUS for Roaming Clients in the WSUS Deployment Guide. Then you'll want to do some additional research on DNS Round-Robin and Netmask Ordering, including all the ways it can cause problems, and the special considerations for properly configuring DNS so you don't have stale information retained in the client-side DNS cache. Then you'll want to brainstorm with some like minds about the specific ramifications of using this feature with WSUS -- including the fact that clients will be reporting to two independent servers based on conditions only partially within your control.

    This scenario will have clients using their *local* WSUS Server, and if they change locations, they'll continue to use the local server. In this scenario you probably also want to make the second server a replica of the first -- or perhaps, even, the two live servers a replica of a third "management" server, which does not service actual clients. With this scenario, there is no "automatic failover", but if one server is known to be down, you can remediate the situation by removing that server's record from the DNS service until it comes back online. This will functionaly cause all clients to begin using the remaining server.


    The hurdles that we see are registrations showing up on both WSUS servers, as well as the fact that the  field in group policy where you configure the Automatic Updates server only accepts one value...

    So, you're saying that you've already configured this second WSUS server, and it's not behaving as you would expect it to.

    Why not share exactly what you've done with this second server, and that might help give a better clue as to how to help you.

    As a hint, though:
    1. If registrations are showing up on both servers it's because you either have conflicting group policies causing your clients to bounce back and forth between the two servers, or you have already configured DNS Round Robin and this is an expected result if those are mobile clients, or if you've misconfigured Netmask Ordering.

    2. Configuring the Automatic Updates server policy setting does only have one value because a client can only be assigned to ONE server name. This is where DNS Round Robin and Netmask Ordering come into play in the "Roaming Client" scenario described in the documentation.


    Option #2:  To the specific point of providing redundancy for WSUS Servers -- that is normally handled by the use of Network Load Balancing, which is discussed in the section Appendix C: Configure WSUS for Network Load Balancing. Network Load Balancing can be configured to operate across physical site boundaries, and this works great for web servers or other services that have stateless connections. However, the primary disadvantage of this for a mulit-site scenario with WSUS is that the remote node will have to maintain a stateful database connection to the shared back-end SQL Server at the main site, not to mention that you'll not be able to use the free Windows Internal Database and will need to license a full copy of SQL Server to support the solution. In addition, in this scenario, if the WAN connection goes down, the remote WSUS Server will be effectively offline as well, given it will have no access to the database server. In this scenario, redundancy actually fails, because with the WAN connection down, none of the machines on the remote site can get updates because the WSUS Server is functionally offline. Ultimately, then, we could say, you might as well not even have the server on the second site - as it really is not providing any redundancy at all. You would get the same net effect by moving the second node back to the primary site, running the 2-node NLB cluster from the same physical site, and eliminate the risk of losing the WAN connection rending the server useless.
    Lawrence Garvin, M.S., MCITP:EA, MCDBA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2009)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    • Marked as answer by Eric Zhang CHN Friday, September 25, 2009 10:13 AM
    Thursday, September 17, 2009 6:26 PM

All replies

  • We have two sites - a main and a secondary.  We have a WSUS 3.0 SP2 box in one site that services both sites, as well as CISCO NAC clients being remediated before coming in through our SSLVPN.  We would like to provide a second WSUS server in the other site to provide redundancy in case NAC clients are connecting while either site or WSUS server is down.  Can this be done? 

    Yes --- but it's a complicated setup. There are two ways you can approach this. The option presented as Option #1 is offered first because you have the servers split across sites.

    Option #1: Review the section Appendix D: Configure WSUS for Roaming Clients in the WSUS Deployment Guide. Then you'll want to do some additional research on DNS Round-Robin and Netmask Ordering, including all the ways it can cause problems, and the special considerations for properly configuring DNS so you don't have stale information retained in the client-side DNS cache. Then you'll want to brainstorm with some like minds about the specific ramifications of using this feature with WSUS -- including the fact that clients will be reporting to two independent servers based on conditions only partially within your control.

    This scenario will have clients using their *local* WSUS Server, and if they change locations, they'll continue to use the local server. In this scenario you probably also want to make the second server a replica of the first -- or perhaps, even, the two live servers a replica of a third "management" server, which does not service actual clients. With this scenario, there is no "automatic failover", but if one server is known to be down, you can remediate the situation by removing that server's record from the DNS service until it comes back online. This will functionaly cause all clients to begin using the remaining server.


    The hurdles that we see are registrations showing up on both WSUS servers, as well as the fact that the  field in group policy where you configure the Automatic Updates server only accepts one value...

    So, you're saying that you've already configured this second WSUS server, and it's not behaving as you would expect it to.

    Why not share exactly what you've done with this second server, and that might help give a better clue as to how to help you.

    As a hint, though:
    1. If registrations are showing up on both servers it's because you either have conflicting group policies causing your clients to bounce back and forth between the two servers, or you have already configured DNS Round Robin and this is an expected result if those are mobile clients, or if you've misconfigured Netmask Ordering.

    2. Configuring the Automatic Updates server policy setting does only have one value because a client can only be assigned to ONE server name. This is where DNS Round Robin and Netmask Ordering come into play in the "Roaming Client" scenario described in the documentation.


    Option #2:  To the specific point of providing redundancy for WSUS Servers -- that is normally handled by the use of Network Load Balancing, which is discussed in the section Appendix C: Configure WSUS for Network Load Balancing. Network Load Balancing can be configured to operate across physical site boundaries, and this works great for web servers or other services that have stateless connections. However, the primary disadvantage of this for a mulit-site scenario with WSUS is that the remote node will have to maintain a stateful database connection to the shared back-end SQL Server at the main site, not to mention that you'll not be able to use the free Windows Internal Database and will need to license a full copy of SQL Server to support the solution. In addition, in this scenario, if the WAN connection goes down, the remote WSUS Server will be effectively offline as well, given it will have no access to the database server. In this scenario, redundancy actually fails, because with the WAN connection down, none of the machines on the remote site can get updates because the WSUS Server is functionally offline. Ultimately, then, we could say, you might as well not even have the server on the second site - as it really is not providing any redundancy at all. You would get the same net effect by moving the second node back to the primary site, running the 2-node NLB cluster from the same physical site, and eliminate the risk of losing the WAN connection rending the server useless.
    Lawrence Garvin, M.S., MCITP:EA, MCDBA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2009)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    • Marked as answer by Eric Zhang CHN Friday, September 25, 2009 10:13 AM
    Thursday, September 17, 2009 6:26 PM

  • Have you considered using the DNS Round Robin name only for the detecting updates portion?

    If you look in the Group Policy Setting to specify the intranet Microsoft Update Service Location, you could set the location for detecting updates to the DNS RR Name so that all clients detect and download locally.  Then set the Intranet Statistics location to be the name of your hub/primary WSUS server.  This will force all statistics to the central server regardless of what server they get from DNS for downloading updates.
    Thursday, November 5, 2009 9:54 PM
  • Have you considered using the DNS Round Robin name only for the detecting updates portion?
    Since the O.P. hasn't responded to this thread in the two months since originally posted (and replied to), I wouldn't expect an answer to this question either.

    If you look in the Group Policy Setting to specify the intranet Microsoft Update Service Location, you could set the location for detecting updates to the DNS RR Name so that all clients detect and download locally.  Then set the Intranet Statistics location to be the name of your hub/primary WSUS server.  This will force all statistics to the central server regardless of what server they get from DNS for downloading updates.
    You cannot do this, and the behavior you have described will not work.If you read the product documentation carefully, you'll find it's expressly stated that these values must be identical at all times. See Configure Clients Using Group Policy in the WSUS v3 SP2 Deployment Guide for confirmation.

    Futhermore, the correct use of DNS Round-Robin is documented in Appendix D: Configure WSUS for Roaming Clients, which was provided as the correct guidance for this issue in the post from September 17th (correctly) marked as the Answer to this thread.
    Lawrence Garvin, M.S., MCITP:EA, MCDBA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2009)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Saturday, November 7, 2009 7:11 AM


  • Yup I think we agree Appendix D spells out how to do DNS RR.
    I was just trying to address his other concern about the registrations showing up on both.

    But you know maybe I missed it in the Configure Clients Using Group Policy where it expressly said they must be identical at all times....  if that were true, you gotta wonder why Microsoft would expose them separately.... :)
    Actually I used this back in the earlier times around 1.0  and it was needed and it worked fine.

    Now doing a little more digging on our current WSUS setup reveals it's not even necessary for a single hierarchy setup with the Statistics Rollup feature.  I suppose it could still come in handy if a company wanted to allow a branch office to have completely independent WSUS for  approvals but still have their computers report in to the "Central" hierarchy. 

    Food for thought in case anyone is hungry.


    Saturday, November 7, 2009 6:54 PM
  • Yup I think we agree Appendix D spells out how to do DNS RR.
    I was just trying to address his other concern about the registrations showing up on both.
    The registrations show up on both because that's the natural effect of using DNS RR to manage computers in a mobile enviroment. Clients are designed to register with the closest replica server, and that will result in the computers appearing on multiple replica servers. If the server-to-server synchronizations are timed correctly, the upstream server will show the latest data for that client.

    you gotta wonder why Microsoft would expose them separately.... :)
    The WUAgent team has never really commented on this question. One can only speculate that at one time, perhaps the intent was to allow for splitting this functionality, and then a better solution was found. I just wish they'd deprecate the second value and simplify the process. It doesn't even require a change to the GP template, just program the WUAgent to get the URL from only *one* of those values and ignore the other.

    Perhaps the functionality did work with the v5.4 (or earlier WUAgents), but it's never been an option since WSUS v2 was released.
    I suppose it could still come in handy if a company wanted to allow a branch office to have completely independent WSUS for  approvals but still have their computers report in to the "Central" hierarchy.
    A completely independent WSUS (i.e. an autonomous downstream server) cannot participate in reporting rollup. Reporting rollup is only available in a replica environment, and among other reasons, this is because the group structures must be identical on both ends, or you risk losing computers in the display.

    Lawrence Garvin, M.S., MCITP:EA, MCDBA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2009)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Sunday, November 8, 2009 3:23 PM