Collections that perform: query rules, incremental updates and collection evaluation

Almost everything in Configuration Manager targets a collection, so slow or stale collections show up everywhere: deployments that reach new devices hours late, maintenance windows that don't apply, a primary site busy evaluating rules nobody needs. In this deep dive I'll explain how collection evaluation really works, turn that into design rules for limiting collections, query rules and incremental updates, and show how to check the result.

How collection evaluation works#

Primary sites evaluate collections; a CAS only forwards update requests to each primary and receives the results. For every collection, the evaluator:

1. Runs the query rules, then adds direct members and members of included collections.
2. Keeps only resources that are also in the limiting collection.
3. Removes members of excluded collections — exclude always wins.
4. Writes the changes and triggers dependent collections: those limited to this one or referencing it in include or exclude rules.

Evaluation types#

• Scheduled (full) — runs on the collection's full update schedule (the Primary evaluator thread) and walks a graph of dependent collections.
• Manual — Update Membership in the console; highest priority, on the Single or Auxiliary thread.
• Incremental — when resource data changes, a SQL trigger adds a row to the CollectionNotifications table. Every five minutes by default, the Express thread checks just those resources against collections with Use incremental updates for this collection enabled.
• Daily — All Systems and All Users and User Groups run a full evaluation at 4:00 AM, and any change cascades to dependent collections.

Three behaviours that surprise people#

• A full evaluation stops where nothing changes. The graph only continues past collections whose membership changed. If an incremental cycle already added a device, the next full evaluation finds no change, and collections referencing it may not be evaluated in that cycle.
• Incremental graphs skip non-incremental collections. An incremental collection limited to a non-incremental one is evaluated against the limiting collection's current membership, so a new device must reach the parent on the parent's schedule first.
• Inventory-based queries change on the schedule. When a query depends on data that arrives later, such as hardware inventory, Microsoft notes the resource is only added or removed at the scheduled update. Incremental updates don't speed those collections up.

Step-by-step: design collections that scale#

1. Build a limiting tree#

Membership can never exceed the limiting collection, so use that to shrink what each query works on and to mirror your admin scopes:

All Systems
  All Workstations            (query: client installed, workstation OS)
    Workstations - Finance    (query: OU)
      Finance deployments     (include/exclude rules)
  All Servers
    Servers - Patch group A

Schedule less often as you go deeper. A collection with no schedule is still evaluated when its limiting collection updates, so frequent schedules low in the tree mostly repeat work.

2. Write cheap query rules#

Prefer discovery attributes on SMS_R_System (OU, AD group, OS, client status) over joins to inventory classes, use = rather than like when you know the value, and avoid leading wildcards. The workstation query above:

select SMS_R_System.ResourceId, SMS_R_System.ResourceType, SMS_R_System.Name,
  SMS_R_System.SMSUniqueIdentifier, SMS_R_System.ResourceDomainORWorkgroup, SMS_R_System.Client
from SMS_R_System
where SMS_R_System.Client = 1
  and SMS_R_System.OperatingSystemNameandVersion like "Microsoft Windows NT Workstation%"

Replace not in (select ...) subselects with rules. For "devices missing Contoso Agent", build Has Contoso Agent with a query on SMS_G_System_INSTALLED_SOFTWARE.ProductName = "Contoso Agent", then Needs Contoso Agent, which includes All Workstations and excludes Has Contoso Agent. Both depend on inventory, so give them a sensible full schedule rather than incremental updates.

3. Ration incremental updates#

• Microsoft recommends limiting incrementally updated collections to about 200; the right number depends on your total collections, how often resources change, client count and rule complexity.
• Reserve them for collections that change client behaviour or access — Microsoft's example policy names security scoping, client settings and maintenance windows — plus the few deployments where minutes matter.
• Collections without query rules gain little from them.
• If an incremental cycle takes longer than the interval, the site evaluates constantly. Reduce the incremental collections or lengthen the interval: select the site in Administration › Site Configuration › Sites, then Configure Site Components › Collection Membership Evaluation, or run:

Set-CMCollectionMembershipEvaluationComponent -SiteCode 'ABC' -EvaluationMins 10

4. Audit what you have#

# From the site drive, e.g. PS ABC:\>
$all = Get-CMCollection
# RefreshType: 1 manual, 2 scheduled, 4 incremental, 6 incremental + scheduled
($all | Where-Object { $_.RefreshType -in 4, 6 }).Count
# Limited directly to All Systems (SMS00001) or All Users and User Groups (SMS00004)
$all | Where-Object { $_.LimitToCollectionID -in 'SMS00001', 'SMS00004' } |
  Sort-Object MemberCount -Descending | Select-Object Name, CollectionID, MemberCount, RefreshType

Verify#

• colleval.log on the primary site server records the evaluator creating, changing and deleting collections, and its evaluation runs. Follow one collection:
  PowerShell

  Select-String -Path '<install dir>\Logs\colleval.log' -Pattern 'ABC00123' | Select-Object -Last 20

  Healthy looks like incremental cycles finishing well inside the interval and large full evaluations not piling up during working hours.
• Management Insights — in Administration › Management Insights › All Insights, the Collections group and the collection checks in the Configuration Manager Assessment group test your design against Microsoft's guidance. Work through them after a redesign.
• Evaluation status — from version 2010 you can view collection evaluation information in the console; older sites use the Collection Evaluation Viewer tool.
• A real test — a newly discovered device should appear in your incremental onboarding collections within a cycle or two.

Tips & gotchas#

• Don't run Update Membership on All Systems during working hours: any change cascades through its dependent collections.
• Avoid triggering large trees from the CAS. The request goes to every primary site.
• Direct rules follow the resource ID. A rebuild that creates a new record silently drops out; use a query or AD group for anything long-lived.
• Stagger full schedules instead of starting everything on the hour, and match inventory-based schedules to how often inventory arrives (weekly by default).
• Keep a full schedule on incremental collections so inventory-based changes are still picked up.
• Need a class your query can't see yet? See extending hardware inventory.

References#

• Collection evaluation in Configuration Manager
• Best practices for collections in Configuration Manager
• Set-CMCollectionMembershipEvaluationComponent