Configuring and managing WSUS Downstream Replica Servers

Everything is great in your environment except the bandwidth between branch offices and the main office. After investigation you noticed that during client updates the bandwidth is full, so you decided to take action. Since you have a WSUS server in the main office you started deploying one in every company’s branch office. From now on the WSUS servers from the branch offices will download updates either from the main site WSUS server or from Microsoft, then clients will get their updates from their local WSUS server. This is great, but in those branch offices there is no administrator you can delegate to maintain the WSUS servers, approve updates, take care of the client errors that might pop-up or don’t update. If this is the case, the best option is deploy WSUS downstream replica servers because they inherit all the settings and approved updates from a main WSUS server; which can be the WSUS server from the main site. You will see what I’m talking about in just a moment.

For this lab I have three sites, one main site (the HQ) and two branch offices (Branch1 and Branch2) which are connected trough a site-to-site VPN. The main office WSUS server is running on Windows server 2012 and this is what I’m going to deploy on the branch offices to. Windows 7 and Windows 8 clients are running on these branch offices. I presume you already have your WSUS server up and running in the main site, if not follow this guide then come back here to continue.

If you want everything to work smoothly the OU’s and the GPO’s need to be put in place. In the bellow picture you can see the OU’s from my lab environment. Ignore the names. I named them that way so you can make a better image of what’s going on. As you can see I created OU’s for my branch offices and for the HQ and in every one of them there are computers belonging to that office.

   

As for GPO’s, I created one for every office. I don’t want computers to update at the same time on all offices. If you need more information on how to configure group policy for WSUS clients, read this guide.

On the branch offices you can start the installation of those WSUS servers. After the installation is done the WSUS Service Configuration Wizard should pop-up. When you get to the Choose Upstream Server page select the second option Synchronize from another Windows Server Updates Services server, then type the WSUS server name from the main site in the Server name box. Another important setting before we click Next, is to check the box This is a replica of the upstream server. Enabling the box is what makes this WSUS server act as a replica server for another one. In case you want to use SSL, first you need to configure the upstream WSUS server for SSL, than come back here and continue the wizard by checking the Use SSL while synchronizing update information box.

If you don’t want your downstream replica servers to download updates from an upstream WSUS server, and download them from Microsoft, leave the first option enabled and just check the box This is a replica of the upstream server. However for this lab I will choose to use and upstream WSUS server to download updates from.

To configure this WSUS server with the upstream server (WSUS from HQ) click the Start Connecting button.

At the end of the wizard you can opt to begin the initial synchronization. I recommend you do.

After the servers are synchronized, go to Options then click Computers. Make sure you use group policy to assign computers to WSUS groups; only if you don’t want to assign them manually. This is one of the few options that is still configurable on a WSUS replica server.

If you try to configure Products and Classifications, you can’t. Everything is grayed out, because the settings are inherited from an upstream WSUS server, the one from HQ.

   

The same is for the language files. You only get the languages that are set on the upstream WSUS server.

You might be tented to create a computer group, but if you right-click All Computers, the option is grayed out. This is also done from the upstream server, and after synchronization, the groups will appear on the replica servers. Well yeahh… those groups will be present on all the WSUS servers, but this is just the way it works.

Go ahead and create your computer groups, then let the synchronization do its magic. On the first image you can see the computer groups created on the main site (the upstream WSUS server), and on the second one those groups were synchronized on the replica servers.

You might need to refresh the console after synchronization in order for the groups to be displayed.

   

If you go to the main office WSUS, which is our upstream server, and click the Downstream Servers object, you can see all downstream WSUS servers and in which mode they are running. I forgot to tell at the beginning of the guide that there is another mode (beside replica mode) in which a WSUS server can run, Autonomous mode. Is similar to replica mode, but the WSUS servers can be configured individually. They are not inheriting settings and approved updates from an upstream server, they only download updates form it.

All you have to do now in order for the branch office clients to get updates, is to approve those updates. If you try to approve them from one of the replica servers, you are out of luck. You can’t. Not even from the Updates screen.

   

Again, this is controlled from the upstream server. On this one the option to approve updates for clients is working just fine.

   

Once you approve the required updates, they will be downloaded locally on the WSUS server (if set so). During synchronization between the upstream server and the downstream WSUS servers, updates will be then downloaded on the replica servers. After synchronization if you take a look at a computer report on one of the replica servers, you can see that updates got approved for installation.

All that is left now is for clients to get in touch with their local WSUS server and download available updates.

    

If updates were installed or failed can be seen on the computer report. You can open this report either from the client local WSUS server (replica server) or from the upstream server (WSUS from main site).

    

Using downstream replica servers can help you a lot to reduce WSUS administration on sites. Before use it, plan and test everything ahead so you don’t have surprises.

Want content like this delivered right to your

email inbox?


31 thoughts on “Configuring and managing WSUS Downstream Replica Servers

  • 07/06/2019 at 07:39
    Permalink

    Hi,

    Please help me on the GPO part. So for my site clients GPO i have to point it to downstream server right.
    So that the clients get update from downstream server. Is it correct.

    Thanks

    Reply
    • 12/06/2019 at 06:05
      Permalink

      Hi Sunil,
      Yes it is correct. You need to point your branch office clients to your downstream server. Just link the GPO to the OU where this clients (computers) are and you should fine.

      Reply
  • 13/02/2018 at 01:55
    Permalink

    I have upstream server manged by different team , I would like to setup a downstream server for the project servers we manage and patch the approved updates from the upstream servers. Is this possibl?

    Currently I have downstream server setup and fully synchronized with updates.But am unable to see any computers listing in my downstream server .

    Let me know if the whole scenario is feasible.

    Reply
    • 13/02/2018 at 14:57
      Permalink

      Hi,

      Yes, you can do this by synchronize your WSUS server from the “project servers” room with the main one. It won’t be a downstream server this way, it will be just another WSUS server that is taking his updates from another WSUS server instead of Microsoft.

      Reply
  • 30/08/2017 at 15:27
    Permalink

    Great post, followed it and everything appeared to be working fine…

    On the main server ie upstream, when I look at the downstream servers it shows the replica. Then I hop across to the replica and under downstream it has itself as the Upstream with the actual upstream as downstream to it!

    If I go to update source on the upstream and choose sync from MS, this becomes the new setting for the replica. If I set the replica to sync from the upstream, the upstream settings change to be a replica of itself and sync from itself.

    Any ideas?

    Reply
  • 23/08/2017 at 11:50
    Permalink

    If I have, for example, ten (10) branches, and one local server in each of them, do I need particular group policy for every office? Thanks,

    Reply
    • 31/08/2017 at 09:16
      Permalink

      Yes, if you want to the WSUS server in that office. It’s a little bit of work, but if you have low WAN bandwidth it worth the trouble.

      Reply
  • 01/03/2017 at 17:39
    Permalink

    Hello.

    As I said via email: FANTASTIC POST. CONGRATS .
    I completed my downstream as you told us an dnow I have a downstreams erver working. Issue now is that I have 16 servers and only 10 of them shows is WSUS (unnasigned comuters). Not appears all of them and also, I have created Group Computers and them are not going to the correct Group Computer.
    I ahve run all commands like wuaiclt /detectnow /resetauthorization and they´re good, GPO are good and everything is ok.
    Could someone where is the issue?.

    THANKS.

    Reply
    • 01/03/2017 at 19:11
      Permalink

      Is the policy applying to those computers? Do a gpresult /r on one of those “not assigned” computers and see if the policy is applied.

      Reply

Leave a Reply to Adrian Costea Cancel reply

Your email address will not be published. Required fields are marked *

*

css.php