Query based collections in ConfigMgr 2007 may fail to refresh after being modified

Consider the following System Center Configuration Manager 2007 scenario:

1. You create a query based collection.
2. You update and refresh that collection and it works correctly.
3. You go to the properties of that collection and edit the query it uses so that it should display different machines.
4. You update and refresh the collection.

After doing this the machines in the collection may still reflect the original query and never be updated.

Cause

This is a known issue with the hotfix (KB982400) that can occur when CollEval is overly taxed and thus has no idle time.

The thread performing collection evaluation has a cache of collections that it has processed in the past. It turns out the cache was never used because the evaluator would build a list of collections to process at the beginning and never update the list until the entire list had been processed, at which point the cache was cleared. In the new version of the collection evaluator the list is constantly updated and sorted, meaning that if a collection is processed then put back into the list for evaluation we will now take advantage of the cache and will not read the collection details from SQL. Unfortunately this means that if the collection gets modified the new rules will not be read until the entire list gets emptied out.

Resolution

The issue will resolve itself under two scenarios:

- If the SmsExec service is restarted for any reason (service restart, reboot, etc) then we have to read in the new collection details once it starts back up and the new query will be used.

- The second scenario is that the cache will be cleared any time the collection evaluator becomes idle for any period of time. The CollEval logs the server shows that it is extremely busy, with some collections starting to evaluate 20+ minutes after they were scheduled. We hit this because there is no time between evaluations of the same collection where the service is idle and the cache is cleared.

Alternatively you can use the following method to increase the interval of the updates, giving the process more time to complete:

1. Run GetCollectionRefreshSchedules.vbs to dump the collection refresh schedule to a file.

Syntax:  Cscript  /nologo GetCollectionRefreshSchedules.vbs SERVER01 S01 > C:\CollSched.txt

Note: SERVER01 -< Name of the SCCM Site Server.  S01 -< Site Code of the Site experiencing the problem.

2. Rename CollSched.txt to CollSched.csv.

3. Open the CollSched.csv file with Excel.

4. Select all the column headers and filter.

An example CSV filtered on Update Schedule of Every 59 Minutes looks something like this:

5. Run UpdateHourlySch.vbs (see the attached ZIP file) to increase the schedule interval.

The case I was working on had the most collections updating every 59 minutes so we tweaked the script UpdateHourlySch.vbs to update the schedule from minutes to hours.  Once we decided on the most aggressive schedule we could live with we ran UpdateHourlySch.vbs using the syntax below:

Cscript  /nologo UpdateHourlySch.vbs <Site Code> <Current Schedule> <New Schedule>

In our example, we used the following:

Cscript  /nologo UpdateHourlySch (Mins to hrs version).vbs Site1 59 3

6. Restart the SmsExec service.

Note: This doesn't seem to affect machines added to the collection as a direct member, only query based collections.

As with all scripts we provide, these are samples given for demonstration purposes only and provided as-is with no guarantees, etc.  It is your responsibility to test and determine their suitability to your environment.

Hope this helps,

Anshul Srivastava | Support Engineer – System Center Support

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The OpsMgr Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis