Content Distribution: The Myth

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.1The 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.

The test source files

The test source files

The data source tab for the test package

The data source tab for the test package

The test package

The test package

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

The updated source location for test package

The updated source location for the test 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.

The test package version number in distmgr.log

The test package version number in distmgr.log

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.log2I 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 3Metadata 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.

pkgxfermgr.log showing the files not being copied

pkgxfermgr.log showing the files not being copied

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.

The source files for the second test package

The source files for the second test package

The second test package

The second test package

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.

pkgxfermgr.log showing the files not being copied

pkgxfermgr.log showing the files not being copied

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

Footnotes

Footnotes
1 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.
2 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.
3 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.

4 Comments

Cancel

  1. … During the 2nd test, will it compare only the filenames or size also matters here? What if i have same file name but different size like 1kb and 100mb? How does it works?

  2. Great post, thank you. Question, why is your PkgXferMgr.log file so clean and easy to read and mine is full of “SQL>>>…” entries that barely look like any kind of language?