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
31 thoughts on “Configuring and managing WSUS Downstream Replica Servers”
I have the next issue:
I have cnfigured a DC-A and a DC-B. I have installed Wsus and a Downstrream.
Boht are sync and downloading oatches,. the issue is:
In WSUS of Downstreamd does not appears Computers. Some idea bout?. I have run detect now /resetauthorization and doesn´t appear in WSUS.
Some help please?
It is all about the GPOs you are applying to the computers. Make sure you configure the GPO in site B to point the computers to the replica server.
I am in the same side. I have changed the GPO from dc-a (wsus downstream) to DC-B (Upstream) and machiens are the same. Does not shows more machines.
I’ve got a multi data center setup here and I’ve just installed my first replica at our new secondary data center.
I’ve selected replica and its showing in the main wsus server console as precisely that. I kicked off the initial sync after changing the settings on the replica to download from windows update, but monitoring both adaptors, they are pretty much in sync as if the main WSUS server is sending over its repository bit by bit. Bit confused by this double handling?
You can’t have a replica downloading from other sources. The replica only downloads patches from the upstream server, that’s why you see the same traffic. I guess it ignores the change you’ve made on the replica. Try using a network traffic analyzer and you will see that all connections point to the upstream server.
Any issues with having W2K8-R2 as an upstream WSUS and W2K12-R2 as a downstream one?
Hmmm, never tried it, but I can’t think of a reason of not working. Try it, then post the results here, I will much appreciate it.
When i assign branch wsus server for branch ou in gpo i am unable to update the clients.i am facing some error.
Some error like ?
Make sure the GPO is linked to the proper OU, force one of the clients to get the new GPO policy (gpupdate /force), take a look at the client and see if the policy applies (gpresult /r)
just set first replica server.
A question about reporting…
1. On upstream: Options-Reporting Rollup- Rollup status from Replica Downstream is checked.
2. In GPO applied to machines connected to Replica server I entered:
a) set the intranet update service – Replica_Server_name
b) should I type the same Replica_Server_name in Set the Intranet statistics server box or it should be the name of Upstream server?
Sorry for the late response. Set the Intranet statistics on the replica server, not the upstream one. Clients might not appear in the WSUS console if set otherwise.
Currently I have 2 site and I setup in the past 2 separate WSUS servers, one per site, and every time I make a change, I have to make it on the other side too. Both have their own SQL server.
I am trying to merge them together, I don’t care where the DB is going to sit, but can the DB be central? and each server still have their own local updates repo? I’d like to be able to see all the servers into 1 single console.
My issue is that I have to keep the QA servers (in site 1) with the same policies/updates as PROD (on Site 2), keeping in mind that these are also different domains, every time I have to make the change on the PROD WSUS manually that was done few weeks in advanced in QA WSUS. Was it clear?
What do you suggest I do merge the WSUS together? I’d like to keep the files local to their own servers, but I’d like to have a single console where I approve updates for PROD thatwere approved in QA already, in the same DB.
In this article is explained how you can do this. Well…most of it. You can have central SQL server for both of them but in this scenario all SQL log traffic will go over the wire. No need to complicate things. Just install the WSUS servers with their SQL version they come.
To have them both in one console just right-click the root of the console and add your second server. WSUS doesn’t care if it’s in one forest or multiple ones as long as clients can connect it.
Hope I cleared things a little. Let me know how it goes.
HI Milton! If i put the name of the downstream server as the “intranet Microsoft update service location” for my branch clients; so does
the clients will disappeared from upstream server?
could you advice me how to apply GPO for branch client to get update from downstream server?
Hi, This is a very informative how-to, thanks for that. Quick question, when setting up the GPO for the downstream OU’s, do i need to put the name of the downstream server as the “intranet Microsoft update service location”? or do i put the main server name?
You need to put the name of the WSUS downstream server. This way your branch clients won’t update trough the WAN link, instead they will update from their local WSUS server.
Thanks for the quick response. Keep up the good work.
Hi, I am deploying a similar hierarchy with 10 downstream servers for 10 OUs.
I’d like to use the group policy to assign computers to group.
are the groups populated by the OU’s GPO and sync back to HQ WSUS?
You will not be able to create computer groups on the replica WSUS servers, you can create them only on the upstream server (HQ WSUS), let them synchronize, then use GPOs to put computers in those groups from your branch offices. Everything is managed by the upstream server, the downstream servers are just serving as a repository for updates.
Well illustrated and very clear with screen shots..
Thanks it helped a lot..
Doing my best… I’m glad it helped.