ConfigMgr Collection Evaluation Analysis The Easy Way

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Community Hub.

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: https://aka.ms/JonasOhmsenBlogs

 

 

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:

Name in script output Name in CollEval.log Description
Schedule Primary

A scheduled refresh. Default refresh setting would be every 7 days.

ManualTree Auxiliary Evaluator

A manual refresh triggered from a ConfigMgr Account with collection refresh rights.

Triggered on a collection with sub-collections limited to the collection. Can also happen in case someone added a membership rule.

ManualSingle

Single Evaluator

A manual refresh triggered from a ConfigMgr Account with collection refresh rights.

Triggered on a collection with NO sub-collections limited to the collection. Can also happen in case someone created a new collection or added a membership rule.

Incremental Express

Incremental update for a single collection. Multiple collections can be added to the graph if multiple collections are activated for incremental updates. The default value is every 10 minutes.

 

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 parametersScreenshot: 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 collectionsScreenshot: 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:

Columnname Description

EvalType

Type of collection evaluation. See list above for more information in section: “Collection evaluation in a nutshell”

 

CollectionsInQueue

Total number of collections in queue based on evaluated collection graph.

 

CollectionsInQueueKnown

Total number of collections mentioned in CollEval.log

for the specific queue. The log entry might be truncated in case the queue contains more than ~700 collections.

 

CollectionsRefreshed

Total number of actually refreshed collections.

Keep in mind that sub-collections will only be refreshed in case the limiting collection has a member change.   

 

RunTimeInSeconds

How long the evaluation process took for all collections shown under “CollectionsRefreshed”

 

ChangeCount

Count of member changes for all collections in that queue

 

MemberCount

Number of collection members of the first collection in the collection evaluation graph

 

FirstCollectionID

CollectionID of the first Collection in the collection evaluation graph.

NOTE: This might be the first Collection of a chain of limiting collections, all collections set to incremental refresh or just a collection with the same schedule as the rest in the graph.

 

FirstCollectionName

Name of the first Collection in the collection evaluation graph.

NOTE: Not visible if the SMS Provider cannot be reached

 

StartTime

Start time of collection evaluation process

 

EndTime

End time of collection evaluation process for all collections in that queue. Not just one.

 

TimeZoneOffset

Time zone offset as shown in log entry

 

Thread

Thread ID of that process. Can be useful as a reference to the original entries in CollEval.log.

 

User

 

User who triggered a manual collection refresh.

Only visible if the ConfigMgr SQL server can be reached and if the script was able to match the SQL time with the log time entry.

NOTE: The script might not be able to match those entries because CollEval.log entries are not written the same time a manual user refresh is written to the database.

 

Component

 

Component a user used to refresh a collection. Typically, the ConfigMgr console or PowerShell.

 

Machine

 

Machine the user used to refresh a collection manually.

Notes

Can contain notes in case the script cannot find enough data in CollEval.log for example.

 

 

 

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: https://aka.ms/JonasOhmsenBlogs if you like. 

 

Best regards

Jonas Ohmsen

Microsoft Germany

 

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

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.