Binary Differential Replication

Introduction

One of the concepts that I found extremely confusing in my early SCCM career was the concept of Binary Delta Replication. I still often see a lot of confusion and misinformation surrounding BDR. One of the most common misconceptions is that the BDR checkbox needs to be selected on packages for delta replication to occur…this couldn’t be further from the truth, in fact Delta Replication is by default a property of applications and package.

Delta Replication

Delta replication is always on. This form of replication occurs when the contents of a file or folder within a package change. Lets say that you have an Office2016 package that contains a number of update files within it. If you add a new update to the package and redistribute it only the file that was added will be sent to your distribution points as opposed to the entire package being sent again.

Binary Differential Replication

BDR functions much the same way as delta replication however there are some key differences. BDR must be explicitly enabled on the package properties.


When a package with BDR is distributed or redistributed only the bit changes on any files are distributed to the distribution point. Using the same example from above, consider the following:
You have a 10KB file contained within a .WIM file and you make a slight alteration to the file. The changes cause the file size to increase by 3KB for a total of 13KB. In this scenario SCCM will pull apart the ISO file and the 10KB file and only distribute the 3KB changes to the file. SCCM then recombines the file and it becomes 13KB.

Which one should you use?

This would be a matter of debate, BDR due to its nature can increase the amount of time it takes for SCCM to process and distribute package changes however it excels on packages that contain large single files. Operating system packages are a good example as the contain a large .WIM file where a bit level transfer would be much faster.

Drawback of BDR?

In my experience BDR does not provide a significant speed increase in file transfers to our distribution points. I have actually found that BDR enabled operating system files that are distributed often show a failure message on the package distribution status. This typically occurs within an hour of being distributed even though examination of logs on the pull distribution points show that the package is still transferring. Eventually the package status changes to reflect that it has finished distributing. However seeing a failure during the transfer of the package files can lead to troubleshooting an issue that isn’t actually a problem. This particular bug seems to occur regardless of the site server version. It also appears to occur only when using pull distribution points.

While we used to use BDR we do so no longer. We have not seen any negative effects as a result and our package distribution status messages are far more consistent.

If you do decide to implement BDR, ensure that you test it thoroughly to ensure that it has no ill effects on your environment.