16 Mar 2011

Troubleshooting WMI probe and Script related problems (part 1)



In all SCOM implementations, even if you have installed all WMI&WSH fixes to managed systems there are always alerts like:

- Workflow Runtime: Failed to run a WMI query
Object enumeration failed
Query: 'SELECT xx FROM xx WHERE Name =xx
HRESULT: 0x800xxxxx






- Script or Executable Failed to run
- WMI Probe Module Failed Execution
- Failed to run a WMI query
- Failed to run a process or script
- Backward Compatibility Script Error

There're lots of possible causes of these alerts(see next parts).


Sometimes they create much noise in "Active Alerts" view, and there's always a chance to miss really important alert because of the mess.

As they do not have a direct impact to monitoring, firstly I suggest to create a special view in SCOM operational console for such alerts. You can set security settings to enable only administrators and authoring teams to view these alerts.

Possible solutions:

- change severity of all rules and monitors that generate these alerts to "0"(information) and set severity filter in "Active Alerts" view properties.
- create a notification command channel that runs when any alert appear and changes the resolution state of WMI&Scripts related alerts. Set resolution state filter in "Active Alerts" view properties.

I'm not interested in first solution, because some information alerts are important. We can create an own severity value, f.e. 4 for such alerts, but then we'll have a problem with severity filter, from gui there can be chosen only 3 type of severities.
And I think there's no any difficulties to implement it.

The second solution is much more interesting.
I will use the following powershell script for automatic resolution change:

$rootms="Server.local"

#Initializing the Ops Mgr 2007 Powershell provider
     add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client" -ErrorVariable errSnapin ;
     set-location "OperationsManagerMonitoring::" -ErrorVariable errSnapin ;
     new-managementGroupConnection -ConnectionString:$rootMS -ErrorVariable errSnapin ;
     set-location $rootMS -ErrorVariable errSnapin ;


$Alerts = get-alert -criteria 'Name = ''Script or Executable Failed to run'' OR Name = ''WMI Probe Module Failed Execution'' OR Name LIKE ''%Run As Account%'' OR Name LIKE ''%Failed to run a WMI query%'' OR Name LIKE ''%Failed to run a process or script%'' OR Name LIKE ''%Backward Compatibility Script Error%'' OR Name LIKE ''%The Operations Manager%''' | Where {$_.ResolutionState -eq 0}
foreach($Alert in $Alerts)
{$Alert.ResolutionState = 20
$Alert.Update("Resolution State Changed")}


Here's a step-step instruction:

- create a new resolution state for these alerts("20" in my example)
- create a new notification command channel:


















- create a subscriber for this channel
- create a subscription, don't forget to set the filter to New alerts only
- important this script will be run under action account of RMS server!(I don't know why SCOM is not using the notification account for command channel!)

Now you have a special alert view that's very useful for future investigation and these alerts won't annoy operators!

1 comment:

  1. i enjoy most of your articles,the articles are so nice for readers.

    cathy
    www.gofastek.com

    ReplyDelete