Breaking your collections down into smaller subsets

A common requirement, when deploying something to a larger group of computers is, that you don’t want to distribute it to all at once. It might be as simple as targeting a smaller subset of devices for testing purposes, or you want to spread the distribution incrementally over a series of weeks. ConfigMgr added the ability of “Phased Deployments” some time back. And while it takes care about properly initiating the next “Phase” of the deployment, it still relies on you to define the individual target collections for each “Phase”. This article will go through some simple ways on how to prepare some re-usable collections that you can use for such scenarios.

Break it down

First, we need to find an easy and ideally universal way on breaking down a group of devices. While having a purely random distribution would be ideal, some pseudo-random distribution is typically enough. There are two candidates on a ConfigMgr resource, that are almost ideal for this.

1. The ResourceID

The ResourceID is automatically created by ConfigMgr by incrementing it on every new resource. Over time you end up with roughly 10% of all resources ending in a specific digit from 0-9. The exact percentage will vary a bit and largely depends on the amount of devices. Generally speaking, as more devices you have, as more they will approximate the 10%. And while it might make for some nice optics or statistics, it’s rarely ever necessary to have an exact 10%, rather than e.g. 9% in one and 11% in the next.

2. The Configuration Manager Unique Identifier

If a separation into 10% isn’t granular enough, the Configuration Manager Unique Identifier can come to the rescue. It’s a random GUID created by ConfigMgr. And as a GUID consists of hexadecimal characters, you can use any individual character in there to create a group of roughly 6,25%. While you could technically use any character, the easiest would be again to use the last character. This way is also interesting, if you would like to target something like 25% as 4 groups of 6,25% would equal to 25%. Something a bit harder to achieve if using groups of 10%.

Create the collections

As we have now identified methods on how we can properly filter our devices to our needs, it’s time to create a couple collections, that we can use. To be as universal as possible, we use the built-in “All Systems” collection as limiting collection. And then create a query similar to

That will create a collection that contains roughly 10% of your devices. Call it e.g. “All Systems – 10% – 1/10”. Create another one where you change the filter to

call it e.g. “All Systems – 10% – 2/10”. Rinse and repeat for the remaining digits 2-9.

If you prefer smaller subsets, use the Unique Identifier as mentioned above. The query would look like:

And you could name it e.g. “All Systems – 6,25% – 1/16”. Or whatever makes most sense to you.

Apply the magic of include and exclude

As we have our base collections created, let’s start and make them useful. Let’s assume we have a deployment planned to all our workstations. We want to start slow and easy with a batch of 10% to catch possible problems, do another 3 batches of 20% and finish with the remaining 30%. This is just a sample, so divide it however you seem fit.

First, we need our final target collection. Meaning a collection containing the total amount of devices that need to have this particular deployment. As we are doing kind of a phased deployment, I wouldn’t recommend on using any existing collection. It’s better to have a collection dedicated for it, as we are going to tweak it’s members. If the phased deployment is over, you can still create another deployment to any of your “standard” collections to catch the stranglers and/or ensure re-deployment on removal. If you have already a collection defined exactly as you need, it’s fairly easy to just create a new one and use it as an “Include collection”. Let’s call this collection “Target A”, as I’m simply very bad if it comes to be creative with names.

I will now go through different ways, on how we can do this. First, by creating separate collections, that can be used for the “Phased Deployment”. And second achieving the same with a single collection and tweaking the memberships on each phase.

Phased Deployments – Multiple collections

To be able to use phased deployments for our sample, we need to have 5 collections, as we divided our deployment in 5 phases. We have already 1, the “Target A” collection, which is the final phase of our deployment.

For the 1st phase, we need 10% of our devices. So we create a new collection and name it “Target A – Phase 1”. We use “Target A” as Limiting collection and then use our initially created “All Systems – 10% – 1/10”, as an include collection. That might not be immediately intuitive, but look at it from theory of sets perspective. We have a set of 10% of all devices, we have another set of our target devices. And we just created a collection that represents that intersection of these sets.

The 2nd phase would then need 20% of our devices. Again we create a new collection and name it “Target A – Phase 2”. We use again “Target A” as limiting collection and then use “All Systems – 10% – 2/10” and “All Systems – 10% – 3/10” as include collections. I guess the concept should be clear by now. So rinse and repeat for the remaining 2 phases. That now leaves us with 5 collections, that we can use as target collections for our Phased Deployment. I’m purposely not going through the details of how to create a phased deployment to focus solely on the aspect of creative ways on creating collections.

If you don’t want to use the Phased Deployments feature, you can achieve a very similar result by using these different collections and manually create a deployment to each collection with different start dates.

Manual Deployment – Single collection

If you don’t want to use the Phased Deployment feature and also don’t want to deal with so many different collections, rather use a single collection and “kick off” the next phase whenever you seem it fit, you can do this the following way.

Take the “Target A” collection, which currently contains 100% of our target audience. And then use “All Systems – 10% – 1/10” – “All Systems – 10% – 10/10” as Exclude collections. As exclude overrides include, the “Target A” collection has now no actual members. Create the deployment. And whenever you are ready, remove the “All Systems – 10% – 1/10” exclude collection. As we are now only excluding 90% of all systems, 10% of the devices in “Target A” will now get the deployment.

When ready to proceed, continue removing additional exclude collections as required until no exclude collection is left.

These were just two samples, how the creative use of limiting, include and exclude collections can easily achieve results that would otherwise require complex or many repetitive queries. They can be powerful tools.

Reminder

I had 90% of this this post written a while back, as I use this concept since years and thought it might be very useful for others. But never really came to finish or publish it. I had some fancy Venn diagrams in my mind that I wanted to add to better visualize the concept. But as I’m obviously horribly incompetent in all things related to graphics, it basically stalled there, as the stuff drawn was nowhere near anything I had in my mind.

Today I stumbled upon a question on twitter that could make use of the above described concept. It reminded me, that the actual value comes from the information presented itself. And while I could definitely have done better with the visual part, not sharing this information at all is still worse.

So in this particular scenario, assuming that “real” random isn’t necessary, one could use a variant of the above described “solution”. Basically creating a new collection that is limited to e.g. the “All Systems – 10% – 1/10” and than include all 10 collections should give a roughly 10% random sample intersection through all members of these collections. Assuming they don’t have overlapping members. For sure there are several other variants that might make more sense depending on the exact requirements. But as just mentioned, leveraging a combination of limited, include and exclude can lead to results that are otherwise only very difficult to achieve.