What is Binary Differential Replication in SCCM?

Binary Differential Replication, sometimes known as "delta replication," is used by Configuration Manager 2007 to update package source files with a minimum of additional network traffic.

When Configuration Manager 2007 updates the source files for a package, and the source files have already been distributed, it sends the parts of the package that have changed since the last time the package was sent (originally, as an update, or as a refresh). This minimizes the network traffic between sites, especially when the package is large and the changes are relatively small. A file is considered to be changed if it has been renamed, moved, or its contents have changed.

The originating site keeps the differences between the current version of a package and the previous five versions. If a child site or distribution point has one of the previous five versions of the package, the originating site will send the appropriate changes to that site. If the child site has an older version of the package, the originating site will send the entire package.

If the originating site sends the changed files for a package but the receiving site no longer has the package, or the package has been altered at that site, the receiving site will send a status message to the originating site reporting the problem.

Note
In order for Configuration Manager 2007 to use binary differential replication, all receiving sites must first have received at least the initial version of the package. Until all receiving sites have the initial version, Configuration Manager 2007 will not use differential replication.


Care should be taken when distributing changes to a package's source files. If the path to a receiving site is closed, it is important that you not attempt to update the distribution point multiple times before the site address is again available. Each update will include the files from the previous update because the receiving sites will not yet have the previous update. As a result, the updates will include multiple redundant files, wasting network bandwidth.

Note
The processing time for large packages can take an extended period of time (20-30 minutes in some cases or even longer, depending on the size of the package). During this package compression/decompression and hashing/signature-creating process, distmgr.log might appear to be idle, even though the process is continuing.