locked
When to deploy WSUS Replica Server RRS feed

  • Question

  • Is the primary purpose of installing a replica server to reduce traffic over the WAN?  For example if you have two main offices, install a replica server at the second so that local clients at each site will get update policy from the local WSUS server?  Any other benefits to a WSUS replica server?
    Tuesday, August 19, 2014 9:49 PM

Answers

  • Is the primary purpose of installing a replica server to reduce traffic over the WAN?

    That can be one benefit of deploying a replica server.

    For example if you have two main offices, install a replica server at the second so that local clients at each site will get update policy from the local WSUS server?

    Maybe. :-)

    Any other benefits to a WSUS replica server?

    That's a significant part of it.

    As to the question of when to deploy a replica server, this has been my guidance for the past several years to those who ask this question:

    • If the site of interest already has an established server infrastructure (and by this I mean more than one machine functioning as DC/DNS/DHCP/F&P server), then consider deploying a replica server. If the server infrastructure does not exist, it's almost never worth the effort to create a server infrastructure just for WSUS.
    • If the site of interest has LESS than 5mb/sec of WAN bandwidth per WSUS client, then you'll want a replica server to keep from saturating the WAN link. If the site has more than 5mb/sec of WAN bandwidth, managing BITS to use only after-hours/weekend time and having those clients communicate directly with the primary server can significantly reduce the time-to-patch-availability and time-to-report-status.
    • If the site of interest has more than a hundred clients (in which case it should already have a server infrastructure), then it probably should have a replica server.

    Consider also whether the site connectivity to the central office is being routed across an Internet-based VPN connection (read: isEncrypted and possibly only a portion of the total available Internet bandwidth), or is based on a dedicated connection (e.g. MPLS, Frame Relay, Leased Line) which won't be impacted by encryption. This may impact the decision of where a replica server gets its files from (Upstream Server or Microsoft).

    Finally, for some sites, you may want the benefits of local file transfer (to save the WAN circuit), but prefer the lighter overhead of a centralized server. In these scenarios, you should also consider having the clients get approvals from a central server, but download files direct from Microsoft. This still requires a 2nd server, but it can be a single centralized server that services service multiple sites.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    • Marked as answer by Steven_Lee0510 Monday, September 1, 2014 2:54 AM
    Wednesday, August 20, 2014 12:49 AM
  • Simply deploy a downstream server in the same datacenter to enable this feature?

    Yep. That simple. :-) Configure it at installation to NOT maintain a local content store, and that will force any clients assigned to that server to download binaries direct from Microsoft.

    I haven't been able to locate a related GPO that says anything about downloading updates from Microsoft once the policies have been applied.

    Correct. It's not a client-side setting; it's a server-side configuration option.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    • Marked as answer by Steven_Lee0510 Monday, September 1, 2014 2:54 AM
    Thursday, August 21, 2014 3:08 PM
  • Server side configuration option which is invoked simply by not creating a local database on the downstream server, or is there actually a config panel to go to?

    If it's done by design-and-intent, then there's a CHECKBOX on an installation screen where you will choose to NOT have a content store created (if you don't turn that checkbox off, the next screen asks you WHERE to create the content store).

    However, you can also REMOVE the content store after creation if you have need to change that configuration. This is found on Options -> Update Files and Languages:

    I notice now that our primary WSUS server has downloaded over 70GB of updates

    **OUCH**

    Will the downstream server which forces clients to download updates from the internet remove this local cache of Windows update files on the primary WSUS server?

    No... it simply will not copy them to the downstream server.

    But you should know... -70GB- is about 4x-5x what a well-maintained WSUS server would have, which suggests that you've, perhaps, approved about 10x the number of updates you actually needed to approve.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    • Marked as answer by Steven_Lee0510 Monday, September 1, 2014 2:54 AM
    Friday, August 22, 2014 2:04 AM

All replies

  • Is the primary purpose of installing a replica server to reduce traffic over the WAN?

    That can be one benefit of deploying a replica server.

    For example if you have two main offices, install a replica server at the second so that local clients at each site will get update policy from the local WSUS server?

    Maybe. :-)

    Any other benefits to a WSUS replica server?

    That's a significant part of it.

    As to the question of when to deploy a replica server, this has been my guidance for the past several years to those who ask this question:

    • If the site of interest already has an established server infrastructure (and by this I mean more than one machine functioning as DC/DNS/DHCP/F&P server), then consider deploying a replica server. If the server infrastructure does not exist, it's almost never worth the effort to create a server infrastructure just for WSUS.
    • If the site of interest has LESS than 5mb/sec of WAN bandwidth per WSUS client, then you'll want a replica server to keep from saturating the WAN link. If the site has more than 5mb/sec of WAN bandwidth, managing BITS to use only after-hours/weekend time and having those clients communicate directly with the primary server can significantly reduce the time-to-patch-availability and time-to-report-status.
    • If the site of interest has more than a hundred clients (in which case it should already have a server infrastructure), then it probably should have a replica server.

    Consider also whether the site connectivity to the central office is being routed across an Internet-based VPN connection (read: isEncrypted and possibly only a portion of the total available Internet bandwidth), or is based on a dedicated connection (e.g. MPLS, Frame Relay, Leased Line) which won't be impacted by encryption. This may impact the decision of where a replica server gets its files from (Upstream Server or Microsoft).

    Finally, for some sites, you may want the benefits of local file transfer (to save the WAN circuit), but prefer the lighter overhead of a centralized server. In these scenarios, you should also consider having the clients get approvals from a central server, but download files direct from Microsoft. This still requires a 2nd server, but it can be a single centralized server that services service multiple sites.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    • Marked as answer by Steven_Lee0510 Monday, September 1, 2014 2:54 AM
    Wednesday, August 20, 2014 12:49 AM
  • Thanks for your reply Lawrence. You seem to be the WSUS authority here on the TechNet forum. If I could pick your brain a bit more regarding the details of deploying a 2nd server in the same site for the purpose of pushing policy, but having clients download the updates from Microsoft rather than from our internal servers? We have a datacenter type environment and many remote sites. I'd like to use Microsoft's bandwidth if I could.

    Simply deploy a downstream server in the same datacenter to enable this feature?  What are the other steps?  I haven't been able to locate a related GPO that says anything about downloading updates from Microsoft once the policies have been applied.

    Regards,

    Adam Tyler / adam@tylercrew.com

    Wednesday, August 20, 2014 3:25 PM
  • Simply deploy a downstream server in the same datacenter to enable this feature?

    Yep. That simple. :-) Configure it at installation to NOT maintain a local content store, and that will force any clients assigned to that server to download binaries direct from Microsoft.

    I haven't been able to locate a related GPO that says anything about downloading updates from Microsoft once the policies have been applied.

    Correct. It's not a client-side setting; it's a server-side configuration option.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    • Marked as answer by Steven_Lee0510 Monday, September 1, 2014 2:54 AM
    Thursday, August 21, 2014 3:08 PM
  • Server side configuration option which is invoked simply by not creating a local database on the downstream server, or is there actually a config panel to go to?

    Follow up question to this, I notice now that our primary WSUS server has downloaded over 70GB of updates to the E:\WSUS directory I created during install.  This is obviously caching the Windows 7 updates that I have approved for install..  Will the downstream server which forces clients to download updates from the internet remove this local cache of Windows update files on the primary WSUS server?

    Thursday, August 21, 2014 11:15 PM
  • Server side configuration option which is invoked simply by not creating a local database on the downstream server, or is there actually a config panel to go to?

    If it's done by design-and-intent, then there's a CHECKBOX on an installation screen where you will choose to NOT have a content store created (if you don't turn that checkbox off, the next screen asks you WHERE to create the content store).

    However, you can also REMOVE the content store after creation if you have need to change that configuration. This is found on Options -> Update Files and Languages:

    I notice now that our primary WSUS server has downloaded over 70GB of updates

    **OUCH**

    Will the downstream server which forces clients to download updates from the internet remove this local cache of Windows update files on the primary WSUS server?

    No... it simply will not copy them to the downstream server.

    But you should know... -70GB- is about 4x-5x what a well-maintained WSUS server would have, which suggests that you've, perhaps, approved about 10x the number of updates you actually needed to approve.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    • Marked as answer by Steven_Lee0510 Monday, September 1, 2014 2:54 AM
    Friday, August 22, 2014 2:04 AM
  • Thanks again Lawrence.  I think we've sufficiently navigated away from the topic of this particular thread "When to deploy WSUS Replica Server".  I think I am going to open a new one just to discuss how to properly approve updates and manage the delete process for old updates.  Thanks!

    Adam Tyler / adam@tylercrew.com

    Friday, August 22, 2014 4:51 PM
  • Lawrence, I notice the "Do not store update files locally; computers install from Microsoft Update" option is available on the original WSUS server..  To confirm, for this to work you HAVE to install a downstream server?  Or can you simply select this option for a stand alone WSUS server and get the desired result?
    Friday, October 24, 2014 6:22 PM
  • Lawrence, I notice the "Do not store update files locally; computers install from Microsoft Update" option is available on the original WSUS server..  To confirm, for this to work you HAVE to install a downstream server?  Or can you simply select this option for a stand alone WSUS server and get the desired result?

    The option is applicable to both upstream and downstream servers, but it's rarely a functional option on upstream servers. Why would you NOT download content to a single store on the LAN for the rest of the LAN-based computers to transfer files from. Why would you force every client to download from the Internet when a local resource could already be available?

    The only practical scenario would be when *ALL* of the WSUS clients are remote, and have more Internet bandwidth available than they do to the WSUS server. In that case, there may be no value in having a local content store on that WSUS server. But if it has even ONE local client (other than itself, of course itself should always be a client), then it's more economical to maintain a store on the WSUS server and have all clients get content from the WSUS content store.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Friday, October 24, 2014 11:10 PM
  • Sorry for the delay in getting back to you Lawrence.

    In fact my company infrastructure is in a situation where all of our client machines are remote and spread over several small office locations or simply traveling laptop users.  We have a single shared storage device backing our VMware cluster which is collocated and space is at a premium cost.

    Checking the "Do not store update files locally" box was the final piece of the config I needed.  I now have a single WSUS server sitting in our datacenter which is serving policy to only our Windows 7 clients for the moment.  Seems to be working well and I don't have any patches cached locally.

    I'll likely apply the update GPO to servers, but our internal policy and HA configurations don't allow for most of our servers to automatically patch and reboot.  They can at least download the updates and wait for an admin to apply them.  However I don't know that I can configure a single WSUS server to stage patches locally for Servers and not for Windows 7 clients.  Would probably need to deploy an entirely different WSUS server and let it cache.  In which case a server count of our size I'll probably just leave each server to download directly from Microsoft Update.

    I appreciate your help with this. First WSUS deployment I have been through.

    Friday, November 7, 2014 7:29 PM
  • However I don't know that I can configure a single WSUS server to stage patches locally for Servers and not for Windows 7 clients.

    There are several ways in which this can be implemented, since the configuration option to install automatically or not, is a GPO setting, which makes it client-side, not server-side. The two most typical are:

    • If your Organizational Unit structure separates servers from workstations (it should!), then it's as simple as creating a different GPO for the servers.
    • If your OU structure does not separate servers vs workstations, you can implement this using WMI Filtering, and apply the policy only to systems running a Server OS. (And if the server list were short enough, which does not seem to be the case here, you could also implement the policy using Security Group Filtering by defining an AD Security Group containing only Server accounts.)


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Saturday, November 8, 2014 4:36 AM
  • Lawrence,

    I am familiar with how to filter GPO's with OU's and WMI filtering.  I am also aware that the update behavior per endpoint is a GPO setting and not enforced by the WSUS server.  I was referring to the WSUS server actually downloading and caching the update content.  Once you configure it to no longer cache those updates locally, I haven't been able to find a preference to then cache them locally for certain clients vs others.  With one WSUS server it appears to be off or on without downstream WSUS servers.  Thanks again for your help.

    Saturday, November 8, 2014 6:30 PM
  • I was referring to the WSUS server actually downloading and caching the update content.

    Ahh, my misunderstanding. It is a server setting and there is no way to split the behavior.

    In this scenario you would need to deploy two WSUS servers, an upstream and a replica. The upstream would maintain a content store for the servers; the downstream would be content-less, allowing the desktop clients to download direct from Microsoft. Both servers can exist in the same datacenter, simply servicing different sets of clients.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Sunday, November 9, 2014 7:41 PM