Content Distribution: The Myth

A quick post to dispel a common ConfigMgr myth about content distribution. The functionality in question is what happens when you change the source location of a package (or any content since they’re all technically packages on the back-end)? I’ve seen it stated multiple times by multiple folks that ConfigMgr will re-copy all of the files within that source location to your DP(s). This simply isn’t so (and never was even in ConfigMgr 2007). When you change the source location, ConfigMgr does indeed kick-off a DP update for that package incrementing its version in the process. But just like all package updates, it will perform a file-level differential replication.  This only copies the files that have changed which for a simple source location change means nothing will be copied (assuming the new source directory’s contents are identical to that of the original location). It does generate some network traffic and activity though because each and every file must be compared and the metadata about the package must also be transferred.((The process of determining which files have changed during content distribution was greatly improved in 2012 R2. Previously each and every file was compared; as of R2, this is done in batches of 50 greatly reducing the time resources required.))

The First Content Distribution Test

To prove this out, I created a single Test package containing 10 unique files and distributed it to my remote DP.

From there, I manually copied the content to another server and then updated the source location for the package.

Notice that the version is updated. This doesn’t happen instantly though so don’t expect to be able to reopen the properties dialog right away and see the updated version number. You can clearly see the new version in the distmgr.log on the site server though once the distribution manager starts processing the change.

After the distribution manager initiates the process, package transfer manager picks up the changes and replicates the necessary files. In this case though, as clearly shown in pkgxfermgr.log((I set the logging level for the package transfer agent to 0 to show this detail; without this set, the log does not show any information about the files considered.)), none of the files within the package were copied. This is because none were changed of course. This is identical to happens when you manually initiate a normal distribution point update when no files were changed. The only difference is that it is automatically initiated in response to the package source location being changed. Notice the metadata.ini ((Metadata files contain information about each package. These metadata files are small but proportional in size to the number of files within the source directory.)) file being transferred though.

As mentioned above, this package was distributed to a remote DP. For a DP on the actual site server, no replication ever takes place. This is because the DP uses the same location to store files as the site server does, specifically the content library (aka sccmcontentlib). The same principle applies though because the content library is a file-based, single instance storage mechanism.

The Second Content Distribution Test

Another notable capability to point out for content distribution is that the replication process also detects duplicate files between different packages. When it does detect duplicate files, it won’t re-send these duplicate files to the remote DP. To show this, I created another package that contained five of the same files from the Test package used above and added two new ones.

And, as clearly shown in the pkgxfermgr.log, only the two new files are actually copied to the remote DP. This is because the content library on that remote DP already contained the first five files even though they are part of a different package.

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.