As we've seen, collections that are based on direct-membership rules need to be maintained by the SMS administrator since they are manually created and defined. Collections that are based on queries, however, can be updated automatically based on the schedule that you define. The SMS component responsible for carrying out this updating task is Collection Evaluator.
Collection Evaluator will execute the query and update the collection whenever the scheduled interval occurs, or when the SMS administrator forces an update through the SMS Administrator Console. When the SMS administrator forces an update or modifies a collection, creates a new collection, or deletes an existing collection, Collection Evaluator is notified of the event by SQL Monitor.
Collection Evaluator will execute a collection's query and update the collection membership according to whatever schedule you define. However, sometimes you need or want to update the collection membership outside of that schedule. The SMS administrator can force Collection Evaluator to update all the collections or any individual collection at any point in time.
To update all the collections at once, follow these steps:
Figure 11-17. The SMS Administrator Console with updated collections before being refreshed.
To update an individual collection, follow these steps:
Figure 11-18. Message box confirming the collection update.
That which the SMS administrator gives, the SMS administrator can take away. This of course is true of collections. While you maintain collections, you might need to reorganize your collection structure by creating new collections and deleting existing ones. Deleting a collection can have consequences other than just removing that collection. When you delete a collection, you will also effect the following events:
Fortunately, when you delete a collection, the Delete Collection Wizard warns you of these effects and shows you what properties of the collection might be affected.
Follow these steps to delete a collection:
Figure 11-19. The Effects Of Deleting This Collection screen.
If you selected the No option, you would proceed to step 11, where you would simply delete the collection. For this example, select the Yes option.
Figure 11-20. The Subcollections screen.
Figure 11-21. The Advertisements screen.
Figure 11-22. The Queries screen.
Figure 11-23. The Collection Membership Rules screen.
Figure 11-24. The Administrators screen.
Figure 11-25. The Choose Whether To Delete This Collection screen.
Figure 11-26. The Completing The Delete Collection Wizard screen.
In this section, we have seen SMS administrators update and maintain collections and subcollections. Next, let's discuss how SMS itself can update your collections automatically.
Collection Evaluator assigns resources to collections according to the most recent data about the resources. Collection Evaluator waits for a file change notification from SQL Monitor before the update process starts. As shown in Figure 11-27, SQL Monitor writes a wake-up file to Collection Evaluator's inbox (SMS\Inboxes\Colleval.box). SQL Monitor writes an update collection (.UDC) file when the update is forced or a collection is modified, an add collection (.ADC) file when a new collection is created, and a delete collection (.DC) file when a collection is deleted. SQL Monitor, like so many other components in SMS 2.0, is driven by SQL trigger events that cause the component ultimately to wake up and perform its task. Collection Evaluator then executes the query and updates the membership results in the SMS database.
Figure 11-27. The Collection Evaluator update process flow.
If the SMS site has child sites, Collection Evaluator also creates a .PSD file that contains the collection definition and membership. It writes this file to Replication Manager's inbox (SMS\Inboxes\Replmgr.box) so that the file can be scheduled and copied to Collection Evaluator's inbox on the child site. If the child site is a secondary site, the file is rewritten to disk as a .CLF file and contains only the collection memberships. If the child site is a primary site, the collection will be processed in much the same fashion as described in the beginning of this section.
When a child site changes its parent site affiliation, Collection Evaluator is responsible for removing any collections that were created by the parent (and are therefore locked at the child site). When the child site joins the new parent site, the collections created at the parent site are passed down to the child site, and Collection Evaluator locks them and keeps them updated.
As with all SMS components, Collection Evaluator generates status messages as it processes collections and subcollections, as well as a log file if you have enabled logging for this component. The Status Message Viewer window shown in Figure 11-28 displays typical status messages generated by Collection Evaluator. Notice that this component's message IDs lie within the 25xx range. For example, message ID 2516 indicates that Collection Evaluator was notified that a new collection was added (by the SMS administrator, of course). The .ADC file is a wake-up file written by SQL Monitor.
Figure 11-28. Sample status messages generated by Collection Evaluator as it processes SMS collections.
Notice also the 2508 messages, in which Collection Evaluator is set to replicate the site's collections and subcollections to child sites. The pairing of messages 2539 and 2510 indicates when the membership rules for a collection were processed and when the collection was updated.
In addition to these status messages, Collection Evaluator writes its thread activity to a log file named Colleval.log, if you enabled logging for this component. Figure 11-29 displays log entries as viewed through the SMS Trace utility. As you can see, there's really nothing remarkable here, except that you can view on a per-thread basis when Collection Evaluator processes each collection, updates or deletes wake-up files, and so on.
Figure 11-29. Sample log entries generated by Collection Evaluator during normal processing.