SCCM 2012 Binary Replication - 4GB size limit on Applications?

Hi there,

We have been struggling with updating our Autodesk applications, all of which are 8-12 GB in size. Anytime we update the sources files, SCCM appears to do a FULL update of all source files across our WAN links, instead of a delta replication. I understand binary replication is enabled by default for Applications, but I was told by a 3rd party vendor that binary replication only works on Applications up to 4GB in size. Anything larger, and it is a full source file update everytime. I have not come across this in any documentation, and would like to know if this is indeed true.

Thanks for your feedback on this,

Rich

February 20th, 2015 7:38pm

I just started a thread with the product team and they are unaware of any such limitations or behaviors.

Perhaps the 3rd party vendor is referencing this: https://support.microsoft.com/kb/2927111/ ?

Free Windows Admin Tool Kit Click here and download it now
February 23rd, 2015 1:37pm

I *think* it is going to depend on the files with which you are dealing.  If there are large files in that 8-12GB that are new or changed, they will get replicated, thus consuming time/bandwidth even when binary differential replication is in effect.

Jeff

February 23rd, 2015 10:51pm

Thanks for the responses. The changes we make to our source files are minor at this point, typically 5-10MB in size. The following TechNet articles describes how every 6th update is a full update, and it creates a new version no matter what: https://technet.microsoft.com/en-us/library/gg712321.aspx#BKMK_PlanforBDR

I am going to test that this weekend, to see if maybe we are just hitting this cycle. If it continues, I will open a case with MS Premiere Support, because I tend to agree with Jason, and that there is no 4GB limit.

Rich

Free Windows Admin Tool Kit Click here and download it now
February 24th, 2015 6:24pm

I was able to add a hotfix to our Autodesk C3D 2015 package, and update content this weekend. Binary replication did work as we would expect it to. It created a content TAR file of ~100MB, located in SMSPKGSIG folder, as well as a Content folder in SCCMContentLib\DataLib of the same size, and only sent that amount of data out to all our sites. I verified it reviewing

It still took over 48 hours for all 60 sites in our environment, and would like to know if that is because the size of the Application is so big (11Gb with 25K files included), that it just takes a long time for SCCM to compare the changes made with the rest of the Application before updating itself properly? Does that make sense?

Thanks, Rich

March 9th, 2015 11:28am

I was able to add a hotfix to our Autodesk C3D 2015 package, and update content this weekend. Binary replication did work as we would expect it to. It created a content TAR file of ~100MB, located in SMSPKGSIG folder, as well as a Content folder in SCCMContentLib\DataLib of the same size, and only sent that amount of data out to all our sites. I verified it reviewing

It still took over 48 hours for all 60 sites in our environment, and would like to know if that is because the size of the Application is so big (11Gb with 25K files included), that it just takes a long time for SCCM to compare the changes made with the rest of the Application before updating itself properly? Does that make sense?

Thanks, Rich

  • Marked as answer by Rich Schafer Monday, March 09, 2015 3:26 PM
Free Windows Admin Tool Kit Click here and download it now
March 9th, 2015 3:26pm

For packages with large numbers of files -- thousands or even tens of thousands -- I typically suggest creating a single archive file that you distribute instead of all of the files separately. You then extract the archive file on the client and run your setup. Yes, this will take a lot more space on the client and some added time to run the extraction, but it eliminates all of the individual file checking. Of course, BDR differentials are unpredictable so the differential could be huge. There are variations of this approach but those may or may not be beneficial either like creating a new archive for only the changed files.
March 11th, 2015 10:43pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics