Collections are a critical part of SCCM 2012. They factor into almost everything from deployments to client settings, to… everything! It just so happens that collections are a unique breed of things that are easy to understand but difficult to master.

I’ve had (at least) my fair share of collection issues to troubleshoot in both simple and complex SCCM implementations, so I’ve decided to share with you some of the issues I’ve seen and what you can do about them.

Issue 1: Clients were added to a collection via direct membership, but won’t show up in the collection.

Cause: This is most likely a case where the limiting collection does not contain “the device” you added as a direct member.

Here is an example:

Fix: In this scenario, the issue is that “The Device” is not part of “Dallas Devices”. The fix is to make sure that “The Device” in all the collections in the Limiting train.

Issue 2: It is taking days for a “The New Client” to fall into “The Collection”.

Cause: Collection Update times are in a reverse time order in the Limiting train.

Here is an example:

In the scenario above, let’s say that a new SCCM client is added to SCCM at 6:00 pm on Monday. It will fall into the “All Systems” collection within 30 minutes, so about 6:30 pm. At 5:00 pm on Tuesday, the client moves into the “Dallas Devices” collection. At 4:00 pm on Wednesday, the client moves into the “IBM Laptop Devices” collection. Why? The update times are get earlier as we move closer to the “IBM Laptop Devices” collection.

Fix: All collections times in the limiting train need to be in Ascending order from All Systems to the “IBM Laptop Devices” Collection.

Here is one example of a simple fix:

In the scenario above, clients will now move from “All Systems” to “IBM Laptop Devices” somewhere in the range of 2 hours if added before 6:00 pm, and as many as 24 hours if added after 8:00 pm.

Issue 3: Collections are stuck in the process of updating for hours before finally resolving.

Cause: There are too many collections with incremental update cycles. Think of the SCCM collection update process as a line for a ride at Disneyland. When a collection needs an update it gets added to a line called the “Collection Evaluator” where in most cases, they are processed using the first in/first out method. Simple, right? As long as the number of collections added to the line in a period of time is the same or less than the number being processed all is good.

Now, let’s say that a sudden power failure causes most of the other rides in the park to close down. Suddenly, we have a flood of new people lining up to ride because they don’t have anything else to do. Chances are that we develop quite a backlog and the line grows longer and longer.

For Collections, this is usually due to a high number of scheduled updates taking place together. By default, the collection update time is the same as the time it was created. This means that if an administrator typically creates collections every afternoon and he accepts the default time, all the collections update times will be clustered into the afternoon. You will see this same scenario if someone manually requests an update on many collections at once.

The last group that could cause an issue is collections with an incremental evaluation time. These are like people with a Fast-Pass, letting them skip the line to ride. While they are getting to ride, the regular line waits.

In the Collection world, all collections with an Incremental evaluation schedule update every 15 minutes by default. So every 15 minutes, all the normal collection evaluations have to wait.   When there are a large number of Incremental collections, the evaluator is unable to complete the cycle within 15 minutes, so the normal collections just sit there waiting, and waiting.

Fix:  Reduce your number of Incremental collections to less than 200.  If you are still having issues after that, consider increasing the interval between evaluations.  In a large environment I was in with many, many collections (thousands) I’ve seen it set as high as 90 minutes.

That brings us to the end of Part 1.  If you are seeing issues with your collection updates, take a look at your environment and see if you have any of the issues I’ve listed. In part 2, Troubleshooting Slow Collection Evaluation in SCCM 2012 (AKA Rooting Out Issues With Collections), I go a little deeper, even giving some SQL queries that can be run against the SCCM database to identify these issues, along with a few new ones.

Need additional help? I’m happy to consult with you directly. Contact Model to set up some time to chat and don’t hesitate to check out our services for a better idea of how we can help you!