ConfigMgr Management Insights for Collections

It’s important to regularly check the health of your ConfigMgr site. You may remember that back in January, I published a blog post, Configuration Manager Maintenance Tasks, about a list of items to review starting from the top of the console and moving down node by node. I try to perform this health check on an annual basis, usually in late December or early January, when things are quiet. Today, it was another quiet time, so I took the chance to review a few of the ConfigMgr Management Insights for collections that mostly focus on cloud services. I have known about the Management Insights feature within ConfigMgr/SCCM for a while, but this was my first opportunity to really look at it. In this post, I am going to tell you how I fixed some of the collection issues in my test lab that were pointed out by this feature.

What is the Purpose of ConfigMgr’s Management Insights?

The Management Insights dashboard identifies important items in your environment that should be looked at and fixed. Management Insights gets updated each time ConfigMgr/SCCM is upgraded. In order to stay on top of the latest details, check out the Management Insights in Configuration Manager docs page.

In the above screenshot, you can see that the first two items listed under, “Top 10 Applicable Insight Rules,” are about my collections, so I thought that I would start there.

ConfigMgr Management Insights for Collections

Start by clicking on the All Insights node and then double-click on Collections within the center panel (not shown). This creates a Collections node and the center panel appears similar to what you see above. In my test lab, I can quickly see that there are five rules that need my attention.

I am going to review these rules by talking about each one in order of their importance.

Empty Collections

I find this insight interesting because empty collections COULD be considered bad, BUT having them is NOT necessarily a bad thing. In my case, I consider them GREAT to have! Why? The simple answer is: re-occurring deployments with collapsing query collections.

This type of collection enables deployments ONLY to computers/users that need it. For example, if I want to deploy the latest version of Enhansoft Reporting (ER) to all computers, including servers, I create a deployment to a collection of computers without the latest version of ER installed. At first, the collection is full of computers, but over the coming days the collection drops to zero. As new computers come online, they fall within the collection and ER is deployed to them. The next day, these computers fall out of the collection. This is a nice and neat method for deploying software. It is also a quick way to see what computers are having problems with deployments and then the service desk can be called in to review those troublesome computers.

What I want to see with the Empty Collections insight is a flag for deliberately set self-collapsing collections. Until that happens, I am going to completely ignore this particular insight, but see below for what you can do!

Fix

There are two fixes:

1. Deliberately create self-collapsing collections.
2. If you didn’t deliberately create self-collapsing collections, review and update your collection query.

Collections with no query rules and no direct members

At first glance, you might think this is very similar to Empty Collections, but it is not. Empty Collections have a query with no computers/users as a result. Whereas these collections do not have a query rule or direct membership. This generally happens for two reasons. You created a collection and didn’t add anything to it, OR there was a direct membership rule, but the computer was removed from ConfigMgr and, as a result, from the collection too.

Fix

1. Edit the membership or delete the collection.

Collections with no query rules and enabled for schedule

Collections with no query rules and incremental updates enabled

Collections with no query rules and schedule full evaluation selected

These three rules are basically the same, so I am grouping them together.

At this point, you might be wondering, “What’s the difference between these three rules and the two rules (Empty Collections and Collections with no query rules and no direct members) I just talked about?” The answer is, “Not much.” The important difference to keep in mind is that these rules have at least one of the check boxes with the purple arrows enabled. That, in itself, however, isn’t the problem.

The main problem with the three rules I just grouped together is that the collection has no query (red arrow). The collection evaluator needs to process the collection on a predetermined schedule (one time, daily, weekly, incremental, etc.) but without a query, ConfigMgr’s CPU, Disk IO, and SQL Server usage is increased needlessly.

Fix

1. Edit the membership by adding a query or direct membership, or delete the collection altogether. Although, I’m not sure why you would want a direct membership collection to update on a schedule, but that is a discussion for another time.

Summary

Ideally, if you are no longer using a collection then it is best to remove the collection from ConfigMgr/SCCM. This prevents SCCM from needlessly processing collections that it doesn’t need to and allows the collection evaluator to finish faster, which is a good thing. Most companies never notice a performance hit of these extra collection evaluations, but that doesn’t mean you shouldn’t clean-up unused collections. Doing this frees up resources and, ultimately, makes SCCM more responsive. Who doesn’t want a more responsive SCCM console? At least once a year, take the time to review your ConfigMgr Management Insights for collections.

As I have time, I am going to continue reviewing Management Insights, updating my test lab and documenting solutions to problems, so watch for my blog posts. At the end of the day, we all want to make ConfigMgr run better! If you have any questions, please feel free to touch base with me @GarthMJ.