Two-state script monitor not auto-resolving in SCOM

Question

This script runs, and if it returns 'erro' an alert is generated in SCOM. The alert is set to resolve when the monitor returns to healthy state. I have tested the script with cscript and it returns the correct values in each state. I'm baffled as to why it generates an alert on 'erro' but will not auto-resolve on 'ok':

Option Explicit

On Error Resume Next

Dim objFSO
Dim TargetFile
Dim objFile
Dim oAPI, oBag
Dim StateDataType
Dim FileSize

Set oAPI = CreateObject("MOM.ScriptAPI")
Set oBag = oAPI.CreatePropertyBag()

TargetFile = "\\server\share\file.zip"

Set objFSO = CreateObject("scripting.filesystemobject")
Set objFile = objFSO.GetFile(TargetFile)

FileSize = objFile.Size / 1024

If FileSize < 140000 Then
    Call oBag.AddValue("State", "erro")
Else
    Call oBag.AddValue("State", "ok")
End If

Call oAPI.AddItem(oBag)
Call oAPI.Return(oBag)

Unhealthy expression: Property[@Name='State'] Equals erro

Health expression: Property[@Name='State'] Equals ok

If anyone can shed some light onto what I might be missing, that would be great!

score 0 · Answer 1 · answered Sep 24 '11 at 02:24

Still trying to wrap our heads around SCOM and we've wrestled with this a bit, too.

The trigger to an 'unhealthy' status seems to happen pretty quickly, but the trigger back to 'healthy' seems to be on what we are referring to as SCOM time. It happens, but it certainly doesn't happen quickly. I've been chalking this up to the sizing of our development lab.

The script looks ok, but you can also verify in the operation manager event log that there aren't problems during the execution of the script. e.g. if you are accessing a file share, and don't have a Run As account setup, it could fail if that server machine account doesn't have rights to the file share.

This will error the script but the monitor will stay healthy.

It may be succeeding for you because when you run it its executing under your user account, which probably has access to the file share.

Monitors are set to poll on an interval (unless they're event monitors, but that's another question). This means that the healthy state will not be set until the next interval of the monitor. Also, there may be some delay in the re-calculation of the aggregate monitors above (for rolled up object health indication) — Kevin Colby, Nov 09 '11 at 22:46

score 0 · Answer 2 · answered Nov 09 '11 at 22:25

The answer depends on whether the monitor is working to begin with. Does the monitor change states as appropriate or is the monitor not changing back to a healthy state when the issue is resolved?

If the monitor is working but the alert isn't resolving: Check the XML for your Unit Monitor and make sure you see <AutoResolve>true</AutoResolve> in the monitor definition. In the Authoring console you can also set this Auto-Resolve property.

Two-state script monitor not auto-resolving in SCOM

2 Answers2