The why & how of this posting
Even though SCCM 1511 has almost the same ‘look & feel’ compared to SCCM 2012x, there are quite some differences. One of those differences is the way Automatic Deployment Rules (ADR) are deployed. Where as ADRs in SCCM 2012x have a one on one relationship with a Deployment, in SCCM 1511 this is changed into a one to many (Deployments) relationship.
This makes sense, since many times one ADR can serve multiple Collections. So why create yet another ADR? And yes, in SCCM 2012x one could work around the one-to-one relationship, by deploying the Software Update Group (SUG), created by the ADR, to other Collections as well. But this approach was pushing the boundaries of the SCCM UI and resulting in a messy overview which made it hard to see to what Collections a particular ADR was targeted. Because of this one could by mistake create multiple ADRs with the same functionality, ‘hitting’ the same Collections multiple times…
So in SCCM 1511 (and it’s future successors) this has been changed. As a result, many of the screens related to the ADR in SCCM 1511 are different compared to SCCM 2012x. I’ve noticed that these changes do raise some questions by people used to the SCCM 2012x ADRs.
Hence this posting in order to show the differences between both versions and the explanation behind it. For this purpose I’ve made two ADRs. One in my SCCM 2012 R2 SP1 test lab, titled SCCM 2012R2 ADR. And another in my SCCM 1511 test lab, titled SCCM 1511 ADR.
But where are the tabs Deployment Schedule, User Experience & Download Settings? These are moved to a new ADR entity in the SCCM 1511 Console, titled Deployment Settings, more about that later in this posting.
When looking in the related SCCM Consoles (\Software Library\Overview\Software Updates\Automatic Deployment Rules), you’ll notice some differences.
SCCM 1511 only: Deployment Properties screen
When opening the Properties screen of the selected Deployment (in this example for the Collection ‘All Mobile Devices’), you’ll find the previous missing tabs in the Properties screen of the ADR:
So there are the tabs Deployment Schedule, User Experience & Download Settings.
This makes perfectly sense, because in SCCM 1511 the relationship between an ADR and a Deployment is one to many. So the properties related to the specifics of a Deployment are gone from the basic properties screen of the ADR itself and brought into the new ADR entity, Deployment Settings.
This enables you to deploy a single ADR to other Collections, each with it’s specific required settings, like (but not limited to), to automatically reboot or not the devices related to the specific Collection when the updates are installed, what to do when the installation deadline is reached and so on.
What happens when an existing SCCM 1511 ADR is deployed to another Collection?
Let’s target the already created ADR SCCM 1511 ADR to another Collection, Windows Server 2012 for example.
Behaviour of a SCCM 1511 ADR with added Deployments. Sometimes a bit erratic?
It’s important to know how a SCCM 1511 based ADR ‘responds’ when an additional Deployment is added, or better, how it show’s itself in the SCCM Console under Software Update Groups (\Software Library\Overview\Software Updates\Software Update Groups).
In the same example the ADR SCCM 1511 ADR is targeted against the Collection All Mobile Devices, and saved. Before it’s first run the same ADR is deployed to another Collection as well, Windows Server 2012:
All is set now. Let’s run the ADR and check out the Software Update Groups view in the SCCM 1511 Console:
TWO SUGs are created?! Let’s check the details of each SUG, since the ADR is set to Add to an existing Software Update Group…
As you can see, per Collection a new SUG is created. Let’s see what happens when the ADR has run for a second time.
And it can get even a bit more confusing when creating a ADR, deployed initially against ONE Collection only which has run at least one time. With the default setting of the ADR (Add to an existing Software Update Group), only ONE SUG will be created.
When the ADR is modified in order to be deployed against other Collections as well, the SUG (after the ADR has run) will only show the original Collection it was initially deployed to…
It’s a good thing that an ADR can be deployed against multiple Collections. In SCCM 2012x this could be done as well but it took much more interaction and was prone to errors because it wasn’t easy to be found back in the Console that a single ADR had multiple deployments.
So far the good news. However, when deploying a SCCM 1511 based ADR to multiple Collections the same SCCM 1511 Console might throw some strange results, so be careful and double check it. Not only on the SCCM Console side of it all, but also on the side of the members of the related Collections to which the ADR is deployed to.