System Center Configuration Manager 2007 : Making the Status Message System Work for You

You can choose which messages to replicate and the data priority for each type of message sent between sites. Status messages sent up the hierarchy can account for much of the overall site-to-site traffic. This is particularly true when child sites have a large number of clients. To limit the impact of status message replication, it is important to tune the Status Message System.

The most important settings for status message replication are the status filter rules. All status messages received by a site pass through the site’s status filter, which evaluates the message to determine if it matches the criteria of each of its status filter rules. A match invokes the action you specify for the rule. One of the actions you can specify is to replicate the message to the parent site.

You can configure status filter rules in the ConfigMgr console, at System Center Configuration Manager -> Site Database -> Site Management -> <Site Code> <Site Name> -> Site Settings -> Status Filter Rules. As shown in Figure 1, two status filter rules for replication are already enabled, by default:

• Replicate all SMS Client messages at low priority

• Replicate all other messages at medium priority

Figure 1. The List of status filter rules enabled in the default configuration

The rule to replicate client settings is higher on the list in Figure 21.16—showing it has a higher priority and will be processed before the rule that replicates all other messages at medium priority. Messages received from clients match the first rule and replicate to the parent site at low priority. All other status messages are replicated at medium priority. You can modify these rules depending on your requirements. For example, if local administrators perform all client troubleshooting at a particular site, you might decide not to replicate status messages originating on client systems from that site to its parent site.

To stop replicating client messages, perform these steps:

By changing the action from the default of Replicate to Parent Site to Do not process lower-priority status filter rules (as shown in Figure 2), you can prevent these messages from being processed by the lower priority Replicate all other messages at medium priority rule. This action results in client messages being discarded. As that data is not forwarded, it eliminates data within some reports at higher-level sites and any centralized view of deployments.

Note that the modified rule is still named Replicate all SMS Client messages at low priority, although it no longer actually replicates the messages. To change the name of the rule, you need to delete or disable the existing rule and create a new rule with the appropriate name.

You can create new rules to control replication of specific types of messages. To create a new status filter rule, perform the following steps:

1.	Right-click the Status Filter Rules node in the console tree; then select New Status Filter Rule to initiate the New Status Filter Rule Wizard.
2.	Name the rule Replicate Milestones and Informational Messages at Low Priority and check the Message Type and Severity boxes. With the selections shown in Figure 3, the filter processes all messages of type Milestone or severity Informational. Figure 3. Specifying Criteria against which the Status Message will be evaluated to determine if the new status filter rule will be applied
3.	Next, choose the action Replicate to parent site / Replication priority and select Low from the drop-down list, as shown in Figure 4. Figure 4. Specifying the actions that occur when a Status Message matches the filter criteria
4.	The wizard displays a Summary page for the new rule and asks you to confirm your choice. This completes the New Status Filter Rule Wizard.

After completing the wizard, you need to change the priority of the rule so that it processes in the correct order. The rule should run after the rule that discards client messages, but before the catchall rule to replicate at medium priority.

Right-click the rule in the list and choose Increment priority. Figure 5 shows the sixteen rules. This discussion focuses on the last three rules, which configure how status messages replicate within ConfigMgr. As a summary, these are the actions now defined for ConfigMgr:

• All Client messages will be dropped because of the steps taken to stop replicating client messages.

• Informational and Milestone messages will be replicated only during times when the Sender Address setting allows sending low priority data.

• All other messages will be replicated during times when the Sender Address setting permits sending medium priority data.

In addition to individual status messages, each ConfigMgr site maintains status summary data by default. This status summary data displays the overall status of a system, component, or advertisement as OK, Warning, or Critical based on the number and type of messages received. Similar to individual status messages, you can decide whether to replicate status summary data to the parent site and the data priority to assign to the replication.

Perform the following steps to configure replication of status summarizer data:

Figure 6 shows the default settings for the Advertisement Status Summarizer.

Effectively configuring your status filtering rules can help to direct your ConfigMgr environment to show only the status information relevant to your particular ConfigMgr site.

Maintaining Status Data

ConfigMgr retains two different types of status data, which are set in the ConfigMgr console, at Site Database -> Site Management -> <Site Code> <Site Name> Site Settings -> Status Filter Rules:

• Audit messages—Audit messages retention is configured within the Write audit messages to the site database and specify the period after which the user can delete the messages rule. This status filter rule has a default setting of 180 days before the user can delete messages.
  
  
• All other messages—Other message data retention is configured within the Write all other messages to the site database and specify the period after which the user can delete the messages rule. This status filter rule has a default setting of 30 days before the user can delete messages.
  
  

These messages are removed from the ConfigMgr database through the Delete Aged Status Messages task (navigate in the ConfigMgr console to Site Database -> Site Management -> <Site Code> <Site Name> Site Settings -> Tasks). This task runs daily between midnight and 5:00 AM. The task deletes status messages older than seven days.

As an example, in a default configuration all audit messages are retained 180 days, and all other messages are retained 30 days. Even though the task deletes messages older than 7 days, the actual data is retained in the database for 30 (or 180) days. If you decrease the All other messages setting from 30 days down to 14 days and rerun this task, it does not have what might be the expected results, which is to delete messages older than 14 days (other than audit messages).

This is because when status messages are written to the database, the date they are scheduled to be deleted is written based on the setting on the status filter rule at that point in time. The date is calculated based upon the settings that existed for the appropriate message retention task. When the retention period is changed, the new messages remain for the time defined when they are written. Therefore, by following the example in the previous paragraph, the status messages written with the 14-day retention would be deleted and then the status messages written under the 30-day retention would be deleted.

It is recommended to retain the status messages as long as is required to diagnose the status of your ConfigMgr 2007 system. If you need to minimize the amount of space used by status messages, you can decrease the retention periods within the two rules listed in this section—although making this change is not suggested, unless it is necessary to decrease the amount of data retained.

Status Filter Rules

Status filter rules allow a ConfigMgr administrator to control which status messages are both forwarded to parent sites and which ones are written to the ConfigMgr database. These rules can be a critical method of tuning performance and eliminating unneeded information.

Rules are set in a top-down ranking, meaning that rules listed at the top of the list are processed first, followed by those listed next. This assumes that a higher-level listing does not stop processing of lower priority rules. Think of status filter rules as a series of gates that each status message must pass through. Each gate has a set of criteria against which each message is checked.

• If the message doesn’t match the criteria, it passes through the gate to the next rule.

• If it matches, a set of actions can be taken, including either allowing the message to continue on its path, or stopping all further activity for the message.

ConfigMgr 2007 comes with a number of status filter rules predefined and enabled by default. These status filter rules provide actions that occur when various conditions are met, as shown in Table 1.

Using the ConfigMgr console, you can create new status filter rules or update existing ones. Utilize these status filter rules to either change how these configurations function, or add matching and actions for additional configurations not predefined within ConfigMgr.