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