Recent conversations have made me think that a blog on how Nomad works with RDC and Binary Differential Replication (BDR) in ConfigMgr would be a good thing. If you all don’t mind, I’ll take the next few minutes to explain how Nomad handles the retrieval of changed package content.
Let’s forget Nomad for a moment. In the native ConfigMgr environment you create a package. You deploy that package out your clients and in a (relatively) short time you have the content installed on your machines across your environment. Does anyone remember the days when the boss made you come in on Saturday and for a pizza and 64oz bottle of soda you’d earn the privilege of spending your day off installing software around the office? Software Distribution is great!
Next week you find that you need to update the package and the workstations. So you update the package source and the distribution points. When you go to deploy your software all your clients retrieve the entire package content…again…even though only a small bit of it changed.
Now, if your package is small, no harm, no foul. But if you have a large package (hundreds of MBs or even GBs) then this is a problem. Why would you clog up your WAN links to distribute a small change?
That is what Remote Differential Compression (RDC) and Binary Differential Replication (BDR) are about. Microsoft included BDR in ConfigMgr to allow for replication of only the changed bits in the content without having to transfer the whole package all over again. This is a good thing. But there are caveats.
In order to take advantage of BDR you need to have RDC installed on the site server and on any Branch Distribution Points (BDP). In addition you will need to select the Binary Differential Replication checkbox in the properties of any package for which you want to use BDR. This takes care of replication of only the changed bits during site-to-site and site-to-DP content transfers. Unfortunately, your clients will still retrieve the full content. We find ourselves asking about why we want to clog up WAN links again.
In the Nomad world RDC works in the following way.
You need to have RDC installed on the site server. The Nomad client doesn’t need RDC installed, which is one benefit of using Nomad over the DP/BDP. Another benefit is what Nomad can bring in the way of the reduction in resource usage and management of your ConfigMgr infrastructure. Furthermore, you do not need to remember to select the Binary Differential Replication checkbox for packages that you wish to use BDR on. Nomad reads your mind and knows what you are thinking 🙂
Seriously, Nomad will leverage RDC to perform BDR functionality without the checkbox being enabled. There are a couple of things to keep in mind about the way that Nomad works in this regard and we’ll take a shot at spelling them out here.
Keep in mind that Nomad will ensure that only one (master) system at a site will retrieve content from the DP, and the other systems at that site will retrieve the content from that master.
Nomad leverages RDC/BDR functionality when retrieving content from the Distribution Point. Nomad does not worry about BDR calculations (and the resultant processing overhead) to determine what is needed when getting content from a peer in the same site. It is a question of efficiency. When retrieving content over an expensive and lower bandwidth WAN link Nomad will take the time to minimize the amount of data transferred. When working peer-to-peer over fast LAN connections Nomad will not waste processing power and in order to get the file transfer done.
Also, Nomad only performs BDR for packages that are 1 version different (N-1) from the cached version. If the content is at version 3 and the client retrieving content has version 1 in cache then the client will retrieve the entire package. This sounds like a big caveat, but chances are that when Nomad goes to get the content there will be a peer in the local site that has it already, so the package won’t be transferred across the WAN link. Also, if the machine doesn’t have the N-1 version and another machine in the site does have the N-1 version, that content will be retrieved from the peer and only the delta content will be retrieved from the DP. In the event that it did have to traverse the WAN, Nomad (as we like to say) behaves like a gentleman on your network, and it will never step on your business traffic.
And one final note. Nomad automatically performs BDR functionality for packages over 125MB in size. Packages smaller than this do not benefit from BDR.
If a package containing multiple files is updated only the files that have changed are retrieved by Nomad, even if they are below 125MB. Nomad verifies that the other files are in cache and of the correct version so that the entire package is not retrieved. This is basic Nomad functionality and doesn’t leverage RDC/BDR functionality at all.
So, to summarize, the configuration to set up Nomad to use RDC to perform BDR functionality would be as follows:
- Site Servers must have RDC installed
- The DP and Clients have Nomad installed as usual (no special configuration for the BDR functionality)
- Your packages do not require any special configuration. Nomad will automatically invoke BDR for packages over 125MB in size
