Call4Cloud | MMP-C | Autopilot | Device Preparation

Content Distribution: The Myth

Patch My Pc | install & update thousands of apps

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.

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

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.

4 thoughts on “Content Distribution: The Myth

  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?

    1. Hi Eswar. That’s a great question and it’s lead to a follow-up post: http://blog.configmgrftw.com/content-distribution-magic/. Please let me know if this answers your questions.

  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?

Leave a Reply

Your email address will not be published. Required fields are marked *

54  −  50  =  

Proudly powered by WordPress | Theme: Wanderz Blog by Crimson Themes.