SCCM 2012 patching design - no subcollections

Question

I made extensive use of subcollections in SCCM 2007 and I'm in the process of prototyping our new SCCM 2012 environment which has eliminated subcollections. I was wondering how others have dealt with this issue.

My SCCM 2007 collection hierarchy is four collections deep. Nested at the bottom is a test collection of systems. Each collection has a maintenance window. The test collection and the collection above it, collection 1, have Thursday maintenance windows. Collection 2 has a Friday maintenance window and collection 3, one on Saturday. With this design, I was able to create a single package and advertisement each month, applying it to the test collection on the first week, and after a week's delay moving the same advertisement to the collection above it after a weeks delay. (The week's delay is a testing/proving period required by administration.) And then on successive days, I'd retarget the advertisement to the collection above it on successive days util reaching the top, collection 3. Using the option 'this collection and subcollections', I was able keep these updates available for successive maintenance windows after the advertisement reached the top.

This design seems pretty common, so I was wondering how others are dealing with the flat design of SCCM 2012 and the elimination of the subcollections.

Answer 1

Firstly, SCCM 2012 isn't actually flat, you can (and should) create folders to organize your different types of collections in the console.

Secondly, I realise that doesn't really answer your question because you're asking about how to deploy settings, applications, updates, etc to a group of collections at the same time, and folders don't help with this.

The way that we do this is by using "Include Collections" (and "Exclude Collections") membership rules. You create what would have been your parent collection, and then add "Include Collections" membership rules to that collection for what would have been your sub-collections. This ends up being much more flexible than the old system because you can easily Include different combinations of collections into your new "parent" collections.

For instance we have a number of collections for server patching based on the servers job, location, risk level and where it sits in our patch cycle, this will then be included in one collection to get its maintenance windows (usually based on something like its location/time zone or usage pattern) and included into a second collection to get its list of approved updates deployed (usually based on its job and risk level), eg: