ConfigMgr Collection Evaluation Analysis The Easy Way

Hi, Jonas here!

Or as we say in the north of Germany: "Moin Moin!"

I’m a Microsoft Senior Cloud Solution Architect – Engineering (or short Sr. CSA-E) and in this article I want to talk about ConfigMgr Collection Evaluation.

About a year ago multiple customers asked me to analyze their collection evaluation process. Mostly to see if there is anything we could optimize and to speed up the evaluation process overall.

In the past I used CEViewer, some SQL queries and the total evaluation time as my tools to analyze the process. But since CEViewer was and is no longer supported, I was looking for a different approach.

While the individual evaluation times and the evaluation-queue information in the ConfigMgr console are helpful, I was looking for a method to analyze the evaluation process over a longer period.

The best thing to see historical evaluation information is the data written to CollEval.log.

So, I sat down and wrote a slightly overengineered PowerShell script to make the information from CollEval.log more readable.

Even though the topic is not new anymore, I thought I would share the script and explain a bit what you can do and see with it.

IMPORTANT: The script is not looking at individual collection refresh times. Those are in the console already. Instead, it gives insights about how many and which collections are refreshed at the same time and when.

Table of contents

Collection evaluation in a nutshell

How to use the script

How to interpret the script output

Some tips

Conclusion

TL;DR

If you are just looking for the download link for the collection evaluation analysis script here you go:

Get-ConfigMgrCollectionEvalTimes.ps1

Feel free to check out my other articles at: Core Infrastructure and Security Blog

Collection evaluation in a nutshell

Revisit the official documentation if you’re not familiar with the process and the terminology at: Collection Evaluation

To better understand the output of the script, remember that for evaluating any collection a graph of collections is built to determine which collections might need to be refreshed as well. For example, if an admin chooses to update “All Systems” manually, ALL collections linked to “All Systems” are added to the graph and will be evaluated later in the process. Therefore the list of possible evaluations can get quite long and might take some time.

The script output will show the different types of collection evaluations. The following list should give you some context. It also helps to find the right names shown in CollEval.log and the official documentation.

The distinct types are:

NOTE: New collections with no rules will not be evaluated.

How to use the script

Download or copy the script from my GitHub repository: Get-ConfigMgrCollectionEvalTimes.ps1

If you run the script on a Primary Site with access to the ConfigMgr log files folder and with the SMS Provider on the same machine, you don’t need any extra parameters to start the script.

Simply run the script without parameters:

.\Get-ConfigMgrCollectionEvalTimes.ps1

NOTE: While you need to be an administrator to be able to read the ConfigMgr Primary Site log folder, you only need the “Read Only Analyst” role for the rest.

Screenshot: Script started without parameters

NOTE: If you select an entry from the list and click “OK” the actually refreshed collections, based on column "CollectionsRefreshed" will be shown.

Read more about the columns shown in section: “How to interpret the script output”.

Screenshot: Output of script with actually refreshed collections

Parameter: -ProviderMachineName

If the SMS Provider is running on a different machine, use parameter “ProviderMachineName” to specify the FQDN of the machine.

Parameter: -ForceDCOMConnection

By default the script will use PSRemoting to connect to the SMSProvider. You can force the script to use DCOM instead by using "ForceDCOMConnection".

Parameter: -IgnoreCollectionInfo

The script will use the SMS Provider to get a list of Collection names, since CollEval.log only contains CollectionIDs.

If the IDs are enough, you could use parameter “IgnoreCollectionInfo” to prevent the script from connecting to the SMS Provider.

Parameter: -AddUserData

It is sometimes helpful to know who triggered a manual collection refresh. Use the parameter “AddUserData” to let the script connect to the ConfigMgr database to retrieve user related data for the last 24h. As with the collection names, the usernames are not part of CollEval.log.

NOTE: Keep in mind that the script might not be able to correctly match a manual refresh with a corresponding username. That’s due to the fact that writing CollEval.log and audit messages are not happening at the same time. I tried my best in the script though ;)

Parameter: - SQLServerAndInstanceName and –ConfigMgrDBName

Both parameters can be used if the script is not able to determine the ConfigMgr SQL and ConfigMgr database name by itself.

Parameter: -CollEvalLogPath

You can copy CollEval.log multiple times to a different directory and specify that directory with “CollEvalLogPath”. That gives you the option to analyze the collection evaluation process over a longer period of time.

Parameter: -ForceUniqueEntries

If you copied multiple versions of CollEval.log and set the path via “CollEvalLogPath”, the output can contain empty lines. This can happen if the script reads the same lines twice or multiple times from multiple versions of CollEval.log.

Use “ForceUniqueEntries” in that case.

NOTE: Using ForceUniqueEntries can cause the script to run very long.

How to interpret the script output

The script will output the results in a GridView containing the following information:

Some tips

This is a list of tips on how to deal with the script output. It is certainly not exhaustive and is only meant to give you a starting point for your analysis.

• If you mark one line of the GridView and click “OK” you will get another output with the actually refreshed collections. You can go back and forth unless you click on “Cancel” in the first GridView.
  
• In the case of a slow refreshing collection, consult the official documentation and stick to WQL query best practices.
  
• Keep in mind that Collection Excludes and Includes will also update the referencing collections. More on that can be found in the documentation: Collection Evaluation Process
  
• If “RunTimeInSeconds” shows a slow refresh time, keep in mind that this refers to all refreshed collections shown under “CollectionsRefreshed” combined.
  
• If “RunTimeInSeconds” for “EvalType” Incremental exceeds the incremental refresh time, you should either limit the total number of incremental collections, improve query time for them or (only as a last step) increase the refresh time via the console. (The setting can be found via: Administration\Site Configuration\Sites -> Configure Site Components -> Collection Membership Evaluation)
  

Conclusion

Having something like a collection evaluation history helped me better understand when and what was triggered in customer environments. With that information I was able to find some misconfigurations or a script updating “All Systems” on a regular basis.

Keep in mind that the script is not looking at individual collection refresh times. Those are in the console already. Instead, it gives insights about how many and which collections are refreshed at the same time and when.

I hope the insights will help you too.

Feel free to contribute to the script directly on GitHub or read any of my other articles at: Core Infrastructure and Security Blog if you like.

Best regards

Jonas Ohmsen

Microsoft Germany

Disclaimer:

This posting is provided "AS IS" with no warranties, and confers no rights

Continue reading...