2020-01-04: Note that this post has some incorrect information. If you have come across this page you likely found it from a link. There will be an updated version of this post coming in the future. When this new post is released a link will be placed here in this comment.

This post will mainly cover Automatic Deployment Rules, but honestly this applies to any package that uses Binary Differential Replication. This includes Applications as by their nature they use BDR. I’m mostly covering Software Update ADRs because it seems to me that these types of packages have the chance to go sideways the fastest - especially when you’re deploying SCEP definition updates.

A little background is in order for SCEP. By default, SCEP definition updates (as well as software updates that are superseded by Service Packs) do not expire when they are superseded if you define supersedence behavior in the console.

So if you’re using a tool like Clean Software Update Groups console extension for ConfigMgr and only cleaning expired updates, you might be surprised to find out that your deployment package for SCEP definitions grows rather large. I ran into a package that was less than a year old and it had already ballooned to 62GB!!

Not only does this mean that when you bring a new distribution point online you’re transferring all this data - it also means that every five times you update the content on the package if you have BDR enabled you’re also redistributing the ENTIRE PACKAGE to your DPs again.

That’s right - and here’s where we get to the meat of this post. BDR is awesome when you want to make changes to packages. By definition it allows you to only transfer the bits which have changed since the last revision of the package saving you some serious bandwidth on larger packages.

HOWEVER

BDR has a somewhat lesser known caveat to it called out in Microsoft’s documentation [HERE](https://docs.microsoft.com/en-us/sccm/core/plan-design/ hierarchy/fundamental-concepts-for-content-management#binary-differential- replication). For sake of you clicking on the link I’ll just quote the applicable text:

Configuration Manager supports up to five incremental versions of a content set before it resends the entire content set. After the fifth update, the next change to the content set causes Configuration Manager to create a new version of the content set. Configuration Manager then distributes the new version of the content set to replace the previous set and any of its incremental versions. After the new content set is distributed, subsequent incremental changes to the source files are gain replicated by binary differential replication.

So here’s the deal. Every 5th time you update the content on the package (meaning you’re on the 5n+1 revision - i.e. 6th, 11th, 16th…) SCCM will automatically redistribute the entire package to your distribution points.

Typically this wouldn’t be a big deal for smaller applications and/or packages which are not frequently changed. However, this becomes a bigger issue when you are updating a package with BDR enabled or an application frequently enough to trigger this full redistribution. This is where SCEP definitions and ADRs can cause some serious problems (especially if you’re not managing the size of the deployment package).

SCEP updates happen frequently. So often in fact that if you’re using SCCM to deploy them via ADRs, there is a good possibility you have your SUP set to check for updates multiple times a day. So now maybe you’re running an ADR three times a day and getting three package revisions per day. Combine that with non-management of a single deployment package for SCEP updates, and you’ve got a package that is FULLY redistributing every couple of days.

Fortunately there are some ways that you can mitigate this:

1. Create new deployment packages frequently and change your ADR to download to that package after creation. This has the added benefit if you’re not managing your deployment packages for expired/superseded updates (because you don’t care about disk space usage) that your packages to DPs remain small and bringing up a new distribution point will have smaller files to process.
2. Manage your single deployment package to remove superseded definition updates so that the package size remains small. This is probably a good practice to be in because no one likes to have the conversation with the storage team about needing more and more and more space on the SAN.

Between those two options, you should be able to avoid the pain of updating a 62GB deployment package every other day.

Happy admining!