locked
Problem about SCCM MP in SCOM 2007 RRS feed

  • Question

  • Hi All,

    We have SCOM 2007 R2 running on W2K3 R2 SP2 (single server).
    We have SCCM 2007 SP1 R2 running also on W2K3 R2 SP2 (single server).

    I've imported the SCCM 2007 MP into SCOM.

    I have a Critical alert in SCOM every few hours that says :
    ConfigMgr 2007 State Message Summary Tasks: Script error
    [SCCM Server Name]
               - ConfigMgr 2007 State Message Summary Tasks: Script error.


                The script 'ConfigMgr 2007 Monitor State Message Summary Tasks' running under processing rule '{AA35C504-5200-6A1F-BA54-82D56FD28DFB}' encountered a runtime error.
    Failed to calculate current runing time for SMS task 'Update NAP Restriction Error Summary'.

    We do not use NAP in SCCM.

    How can I prevent this alert ?
    How can I find the script being use with this rule ?

    Thank you all for the help,
    Dominic

    Wednesday, December 2, 2009 7:57 PM

Answers

  • So - I havent tested this thoroughly in the new MP - but it looks like no changes were made in this regard.  Here is a document I used to send out on the SMS and SCCM MP's for this issue - of constant re-alerting:



    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.

     

     

     I will do a blog post at some point in the near future with detailed examples for the SCCM MP.

    Thursday, December 3, 2009 5:19 AM

All replies

  • What version of the SCCM MP are you using?

    I remember that there were some bugs with the state message monitors that meant you got incorrect alerts.

    See this post from Kevin Holman:


    #################################################

    ...
    As to the noise - yes - this MP has some challenges - it utilizes consolidation modules for the status message events - and often times they dont work right - and it continues to flood repeat alerts for incidents that happened in the past.  I am waiting for the new one myself... which I am hoping will be out soon.  If these are still a problem - I will blog a workaround which will fix them

    Many of my customers just turned off the database status message script - which generates 95% of the noise.... since these status messages and state are already available in the SCCM console.  I am not saying that is a good path or workaround... but it does speak to how much noise this MP will generate as one of our last big "conversion" MP's.

    Make sure - if you use this script - that you are well versed in the localizedtext cleanup necessary... in both SP1 AND R2.... this MP is a top generator of localizedtext table growth:

    http://blogs.technet.com/kevinholman/archive/2008/10/13/does-your-opsdb-keep-growing-is-your-localizedtext-table-using-all-the-space.aspx

    http://blogs.msdn.com/steverac/archive/2009/06/09/localizedtext-issues-gone-in-r2.aspx

    Matt White
    ( http://systemcenterblog.hardac.co.uk/ )
    Wednesday, December 2, 2009 9:14 PM
  • So - I havent tested this thoroughly in the new MP - but it looks like no changes were made in this regard.  Here is a document I used to send out on the SMS and SCCM MP's for this issue - of constant re-alerting:



    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.

     

     

     I will do a blog post at some point in the near future with detailed examples for the SCCM MP.

    Thursday, December 3, 2009 5:19 AM
  • Hi Matt,

    Thank you for the answer !
    I'm using version 6.0.6000.2.

    I'm also thinking of disabling it, but I was searching for a better way of doing it.

    Thanks again for the help.
    Dominic
    Thursday, December 3, 2009 1:42 PM
  • Thanks Kevin / Mart.

    I will check on this and will let you know the update.


    Thanks & Regards Deepak Kumar
    Sunday, November 14, 2010 7:59 PM