This is attributed to OpsMgr SP1, and the converted SCCM management pack.  J

There were some updates to the consolidator module in R2 – which I believe addressed some of this.  In general – a lot of the consolidation rules in the SMS and SCCM conversion MP’s don’t always work as expected in SP1.  They are pretty good most of the time – but here is the general guidance I send out on these MP’s when you have a workflow acting up:

This is probably more than you want to know right now – in short…. Consider disabling any noisemakers – and replace them with a rule (with alert suppression enabled) or a repeated event detection monitor.

--------------------------------------------

There is an issue with the current SMS/SCCM MP’s with status messages.

This is due to them being conversion MP’s… and they had consolidation event rules in MOM 2005 that don’t work 100% correctly in SCOM.  The end result is – that we can continue to alert on a status message that is no longer re-occurring.

Here is a little tidbit on how they work – and what you can do to tune them:

We are not supposed to be re-alerting on old status messages.  We actually run a script and keep a record of the last status message ID – and won’t create new alerts on old status messages.  (provided this process is working)  In your C:\windows\temp\ you should see a SMS 2003 Monitor SMS Status Messages.VarSet which is the mechanism to keep track.  You should inspect this file and see if the counter is getting incremented every hour.

Essentially – we run a script every 30 minutes to check the database, and then there are consolidation rules that consolidate the events so we should only see alerts once per hour.

There is a workaround for these noisemakers….   essentially – first check to make sure the status messages really are not generating anymore for a given site database – then check the varset file in C:\windows\temp – examine its known last record ID….  (see below for that)

If these make sense, then simply disable the corresponding Consolidation rule for the given status message.

For instance –

In my test lab – I was having a problem writing to AD – and I was getting hammered with a status message about it – because I did not create the container for System Management and delegate permission to the site server to write SLP info there.

I fixed the problem on 7-20.  However, I continue to get an alert on this every 30 minutes (actually – not a new alert – but an incremented existing alert)  Since this is an incremented number – this would NOT create a new email or connector alert…. unless you closed the existing alert.  So the “noise” is limited to the console.  It is an issue nonetheless…. so moving forward… I check my varset file in \temp, and it shows the correct status message ID of the last status message that was generated that it created a real alert on.

First – go to authoring – and scope the rules view to “Microsoft SMS 2003 Site Database Servers”

Find the particular rule that generated the alert.  You should be able to search, and find an identical corresponding “consolidated status” rule.  Create an override for this – for all objects of type – and set the consolidation rule to be disabled.  This should stop the constant noise of incrementing existing alerts (or creating new alerts) for old status messages.

See below for my example:

There is an issue documented in the guide that you should take a look at:

Monitor SMS Status Messages Script in SMS 2003

When the SMS status message table exceeds 4,294,967,296 messages, the record ID restarts at zero. The Monitor SMS Status Messages script in SMS 2003 does not have a mechanism for detecting when the record ID has restarted at zero. The script currently looks forward only from the record ID of the last status message that it processed. If the record ID restarts, the Management Pack is not able to detect any new status messages.

On the site server, note the Next Status Message Record ID registry value in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\COMPONENTS\SMS_STATUS_MANAGER registry key. This is the next record ID placed in the SQL StatusMessages table. If this value is less than the LastRecordID value, the StatusMessages table has looped back around and restarted. The script does not process messages again until the Next Status Message Record ID registry value is greater than the LastRecordID value in the VarSet file.

You should periodically monitor the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\COMPONENTS\SMS_STATUS_MANAGER registry key on the site server for the record ID of the next status message. Small organizations or small sites that are low in the SMS hierarchy should check this registry key every two to three months. Large organizations or sites with several child sites should check this registry key every month. If the value approaches 4,294,967,296, monitor it more frequently. After the record ID has reset to zero, you must unblock status message monitoring on the computer running the SMS site database server for the site. You designate the SMS site database location when you install SMS.

One way to automate registry key monitoring is to create a computer attribute and computer group to monitor the computers that are nearing this threshold.

To locate all SMS site databases in your configuration group

1.   In the Operations Console, click the Authoring button.

2.   In the results pane, right-click Microsoft Systems Management Server (SMS) 2003, and then select View Group Members.

To unblock status message monitoring

1.   On the computer hosting the SMS site database role, in the Windows Temp folder, open the following text file: SMS 2003 Monitor SMS Status Messages.VarSet. The LastRecordID_[SMSDatabaseName] entry is a record ID value that indicates the last status message in the SQL StatusMessages table that the script processed.

2.   On the computer hosting the SMS site database role, change the LastRecordID_[SMSDatabaseName] value, for the appropriate site, in the file named SMS 2003 Monitor SMS Status Messages.VarSet to be equal to the Next Status Message record ID registry value minus one. If the result is 4,294,967,296, set the value to zero and save the file.

Hi,

Frequently I am getting this error from one particular server   “Consolidator Module Failed Initialization “.

Alert Description :

1) The Microsoft Operations Manager Condolidator Module processing thread failed with an internal error and must be unload. Error: 0x80070057 One or more workflows were affected by this. Workflow name: SMSv4_Consolidated_Status__Site_Component_Manager_started_to_install_site_system_component_1_Rule Instance name: Microsoft.SystemCenter.ConfigurationManager.2007.Microsoft_SMSv4_Site_Database_Servers_Installation Instance ID: {93BBF7D2-DAB9-8C94-8123-4C27FA219FC0} Management group: xxxxx

For This I have done some troubleshooting from client side like,  clearing the Cache and clearing the health store. But again it problem occurring..

We need to do anything from RMS/MS side or Agent server side.

Can any body faced this issue.   Please suggest me.

Many Thanks,

Narendra.

DISCLAIMER:
This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated.

==============
Missed an email? Check out the list archive:
http://myitforum.com/cs2/blogs/momlist/

==============
Missed an email? Check out the list archive:
http://myitforum.com/cs2/blogs/momlist/