Collections. They’re one of the base components of a Microsoft System Center Configuration Manager (ConfigMgr for short) environment and they can be the key to making or breaking^[1] [2] it. In my travels, I’ve seen collections for specific functions (e.g. power settings, deployments, client settings, etc.), collections for logical grouping (OS version, server vs. workstation, etc.), and sometimes even as simple as JBOC (just a bunch of collections). This post isn’t intended to tell you a right way or a wrong way to organize your collections – every organization’s needs can be different. I am going to walk you through a handful of gotchas I have encountered with various clients to help you better understand how your collections (especially incremental collections) refresh.

Whatever a company’s collection structure is, I frequently hear one goal: “We want our collections to update as fast as possible and have the newest devices and users in them instantly.” Unfortunately…

ConfigMgr Admin: “Hey… do something really quick for me, would ya?”
ConfigMgr: “Nope.”

As ConfigMgr administrators many of us know that things don’t necessarily happen quickly. I always teach clients “be patient” even though I am probably the most impatient person when it comes to Microsoft System Center Configuration Manager (do as I say and not as I do, right?). Things don’t always happen quickly for good reason though – the resources necessary to make everything instant, all the time, everywhere would be astronomical. (*Side note* – the ConfigMgr team is always working to make things faster and more instantaneous… CMPivot is one of those examples)

So how do we take our turtle from curmudgeon to charming?

Know That EVERY Collection Refreshes at 4am (almost) EVERY Day

This sounds like it should be wrong, but it’s a byproduct of the limiting collection requirement beginning in Microsoft System Center Configuration Manager 2012. Every collection needs to have a limiting collection (with the exception of the root/default collections) so everything will be directly or indirectly limited to the “All Systems” or “All Users and User Groups” default collections. If there is a change (addition/removal of a device/user) from these root collections then all your collections will run a full collection evaluation at 4AM. You can verify this for yourself by pulling up CEViewer from the ConfigMgr toolkit (if you’re in a big environment, maybe save this for a lab) and refresh either the “All Systems” or “All Users and User Groups” collections. You’ll see the entire chain of collections get scheduled for a full evaluation. If you really want to test it, you can wait until 4AM and check it with CEViewer then too – or you can just trust that I already did that for you:

Above you see the nearly all of the collections in my lab (one or two are hidden by the scrollbar). There are multiple tiers, of which only Tier 1 collections are limited to the root collection “All Systems” and some of them have no queries or even direct rules to evaluate.

Takeaway: If you’re only updating collections on their default schedule (which is every seven days), just skip it. The only exception to this is if the collection is not configured for incremental updates and you want the collection to evaluate at a specific time for new resources.

Incremental Updates Only Refresh Incremental Collections

“Umm… duh?” you say. While on the surface this caveat seems to be somewhat ridiculous it is necessary to understand. When a collection flagged for incremental updates detects changes, it causes collections using it as a limiting collection to be update ONLY WHEN THAT COLLECTION IS ALSO FLAGGED FOR INCREMENTAL UPDATES.

Above you can see only the incremental collections evaluating when their parent (limiting) collection is also set for incremental updates. There is a collection named “Tier 2 Collection 1 – Tier 1 Collection” missing from the list because it does not have incremental updates enabled.

It seems like a collection which receives an incremental update should force all collections in it’s chain to refresh as well. The reason it doesn’t is because the base/default collections are configured for incremental evaluation. So if everything was updated when a change was detected, EVERY collection in the environment would re-evaluate every time there was a change. Obviously, this causes significant overhead on the database.

Takeaway: If you have a collection marked for incremental updates and you want the child collections to run incremental evaluations, then the child collection needs to have incremental evaluations enabled. The reverse is also true – if you have a child collection with incremental evaluations enabled, you need to make sure the parent collection has it enabled; otherwise how will the parent collection have changes to pass to the child collection?

Use Incremental Updates Sparingly

This is a pretty well known “recommended practice” but it bears repeating. Since incremental collection evaluation happens every five minutes by default, every collection you have setup for incremental evaluation runs an evaluation if new resources are detected in the default collections. Microsoft says to keep it under 200 as a soft limit.

Just sprinkle incremental evaluations in ConfigMgr

Takeaway: If you have a chain of collections 10 layers deep (Col 1 -> Col 1.1 -> Col 1.1.1 -> etc…) and you need incremental updates enabled on the collection at the end of the chain – you’ll need to do incremental evaluation on all 10 collections expending 5% of the soft limit. Fun.

Included Collections Don’t Force Incremental Updates

Here’s the scenario. You have two collections (A and B) limited to All Systems. Collection A is set for incremental updates but Collection B is not. You have another collection (C) that is limited to Collection B, but it’s membership rules include Collection A.

When the incremental update takes place and a new resource is discovered – All Systems and Collection A will re-evaluate, however Collection B and Collection C will not.

Takeaway:

If you have collections that have include/exclude collection relationships different from its limiting collection and need it to update incrementally – you’ll need to make sure that ALL of them are setup for incremental updates.

Final Thoughts

If you take these caveats into consideration we can take your Curmudgeon Turtle and turn him into “Super Rocket Curmudgeon Turtle™”

Okay – maybe not that quick, but I hope that this information does help you make sense of some of the quirks of collection refresh and does allow you to make the best use of incremental refresh to ensure the collections you need to remain up-to-date do so as expected.

– Nate