I’ve seen my fair share of organizaitonal structures when it comes to collections. Some involve creating collections for specific functions (e.g. Power Settings, Deployments, Client Settings) and all split by some sort of logical grouping (OS, Server vs. Workstation, etc) - others have been pretty basic (just OS and groups). Whatever your structure involves, there is nearly always one goal that everyone has with their collections: getting the correct devices or users into the collection as fast as humanly computerly(?) possible.

Here’s the deal though. As ConfigMgr admins, we all know the first rule of working with ConfigMgr: You must have patience. Things don’t typically happen instantaneously in ConfigMgr - nor would I want to convince the client of the expense of building an architecture which would support it being instantaneous. So here are four rules (or rather, things to know) when it comes to collection refresh management:

Know that EVERY collection refreshes at 4AM EVERY day

This sounds like it should be wrong. Why would we have the option then to create refresh schedules for any longer than one day? You can however, review this yourself by pulling up CEViewer from the SCCM toolkit and refreshing one of the two base collections (“All Systems” or “All Users and User Groups”). You’ll see that the entire chain of collections is scheduled for 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 sum of the collections in my lab. 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.

So why does this matter?

If you’re only updating collections on their default schedule (which is every seven days) just to say that they’re updating on a scheudle, feel free to just skip it. The only exception to this rule is if the collection is not configured for incremental updates and you want the collection to evaluate in the middle of the day just in case there are new resources. Incremental updates just so happen to be the next rule.

Incremental updates only refresh incremental collections

“Uhh… Duh.” you say. While on the surface this rule seems to be somewhat ridiculous it is necessary to understand. When changes are detected to a collection flagged for incremental updates, it causes collections using it as a limiting collection to be updated ONLY WHEN THAT COLLECTION IS ALSO FLAGGED FOR INCREMENTAL UPDATES.

Above you can see only the incremental collections being evaluated when their parent collection is also set for incremental updates.

It seems like a collection that receives an incremental update should force all updates in it’s chain to refresh as well - but the reason it doesn’t is because the base collections are by default 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 causing potentially significant overhead on the database.

So why does this matter?

If you have a collection that is marked for incremental updates, and you expect the child collection to re-evaluate it’s rules, you’re in for a bad time. The reverse is also true - if you have a collection that is marked for incremental updates but it’s limiting collection is not marked for incremental updates the child collection will never update on the incremental timer. This is where a large chain of collections could pose to be a problem. If you need incremental updates on a collection far down the chain - you need to make sure that everything further up the chain is also enabled for incremental updates, otherwise the evaluation is for naught. This brings me to my next rule.

Incremental updates should be used sparingly.

This isn’t really my rule - it’s just best practice. 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 root collections. Microsoft says to keep it under 200, as a soft limit.

So why does this matter?

Simply put - if you have a chain of incremental updates that is 10 collections deep, and you need incremental updates enabled… you’ve now expended 10 collections of your 200. Remember that evaluation of incremental collections only happens if all the collections in the chain are set to evaluate incrementally. Now remember that all your collections set for incremental evaluation by default evaulate every 5 minutes for new items. That’s a lot of updating if you have lots of collections - especially if they have poorly written queries!

Include 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.

So why does this matter?

If you have collections that have include/exclude collections which differ from your limiting collection - you’ll need to make sure that all of them are setup for incremental updates IF you need them to update incrementally. This again continues to add to the count of incremental collections which should remain below 200.

Final Thoughts

I would like to write another post detailing more about collections, but in the interest of keeping this post from getting too long, we’ll leave it at these four rules for now. There is so much to know about collections and we’ve really only touched on the surface of them. In a future blog post we’ll talk about queries and making sure you’re making good decisions there too.

Until next time, happy admining!