SCCM 2012 - Updates - Multiple Automatic Deployment Rules, One Deployment Package

In SCCM 2012 R2 there are a number of possible ways to push out the monthly software updates. There are numerous excellent blogs on the web about the various ways to set up the monthly patching. The basic concept, if using an Automatic Deployment Rule, is as follows:

--> Create the ADR

--> ADR runs 

--> ADR locates the updates it needs by talking to Microsoft Update Site

--> Updates are downloaded into the Deployment Package 

--> Updates are either added to existing Software Update Group or a brand new one is created

--> Software Update Group is deployed to the target collection

             However, if you have multiple Collections set up for monthly patching, this will require the use of multiple ADRs. So does this mean that if each ADR has the same Products/Classificaitons you'll end up downloading the same updates multiple times? 

            Well, that depends on whether each ADR has it's own deployment package or not. If each ADR has its own Deployment Package then you will end up downloading the same updates repeatedly. However, if you create a single Deployment Package and simply point each ADR at it, then this problem will be avoided. 

In the below example, i have two ADRs set up - one for test servers and one for production servers. Both ADRs are set to download the same Products and Classificaitons. Although there are two ADRs, i have only create a single Deployment Package which both ADRs will use. The automatic monthly update process then proceeds in the following way: 

First Rule kicks off:

Config Manager finds two updates which need to be downloaded so it trundles off to the internet and pulls them down into the shared package:

Later that week, the second rule kicks off:

Config Manager again finds two updates which need to be downloaded. Before downloading the two updates it checks in the deployment package and discovers that both updates are already present. Config Manager moves on with the creation of the new SUG:

(the above snips are taken form RuleEngine.log which is the best log to consult when checking on ADRs)