Share This Post

Increase SCCM performance with Status Filter Rules

Status messages are an integral and important piece of the ConfigMgr puzzle. They tell us everything from package distribution status to how successful our last advertisement was. But lets face it – ConfigMgr likes status messages a little too much. Every little action gets reported…from the simple client action to massive site settings changes. The simple act of a client running an advert from Run Advertised Programs can generate more than a half dozen alone! It’s easy to see how that admittedly useful information can quickly turn into a flood of backlogged inboxes.

First, lets get an idea of how many status messages your Central Site server has processed in the last 7 days or so. Run this SQL query against your ConfigMgr database:

select count(*) as ‘MessageCount’ from v_statusmessage where time > getdate()-7

Was the number higher than you expected?

Now, let’s see what components and what the message-ids are that have the highest counts:

select count(*)as ‘MessageCount’, messageID, component from v_statusmessage
where time > getdate()-7
group by messageid, component
order by ‘MessageCount’ desc

There isn’t much data here, so a little cross referencing is in order. I haven’t been able to find a comparable document for ConfigMgr, but here is a link to a SMS 2003 SP1 document that contains many of the same message IDs and their descriptions:

http://www.microsoft.com/downloads/details.aspx?FamilyID=9f009942-b4d8-4a70-8f74-e81ccc7b2309&DisplayLang=en

So what does this all mean and how can it help? Assume you have a multi-tier hierarchy with a top Central Site and child Primary Sites. Do you really need your central site to know every time a child primary updates a collection? Why not let the child primary process and record that status message, but stop there and not send it up to the Central. Do you really want to make your Central site process a status message every time a client evaluates an advertisement and determines it’s not a valid platform/OS? It’s up to you to decide what you can and cannot live without, but rest assured that adding even a few status filter rules can lead to a drastic reduction in status message processing overhead. Here are a couple of suggestions that could help with processing at a central site when placed on the child primaries:

Make sure you increment the priority on these rules above “Replicate” status filter rules – otherwise the central site will still get the status messages!

Collection Evaluation:

Source: ConfigMgr Server
Component: SMS_COLLECTION_EVALUATOR
Severity: Informational

Do not forward to status summarizers
Do not process lower-priority status filter rules

Client Platform Rejected (a client rejected an advertisement because the platform/OS doesn’t match):

Source: ConfigMgr Client
Message ID: 10018

Do not forward to status summarizers
Do not process lower-priority status filter rules

The important thing to remember is to run the above queries, then determine what you need to monitor and what you don’t. Place these status message filters on the child sites, and you are basically blocking that data from reaching the central site.

Status Filter Rules are a powerful way to control data flow in ConfigMgr. Using 3 rules similar to the ones listed above, our Central site was processing 30% less status messages.

Share This Post

2 Comments

  1. BTW, I’m Totally stealing this for my SCCM Guru Cast

Leave a Reply