Warning for people who landed here: this post is VERY OLD. It was written in the early days of struggling with OpsMgr 2007, and when nobody really knew how to do things.
I found that this way was working – and it surely does – but what is described here is NOT the recommended way to do things nowadays. This post was only meant to fill in a gap I was feeling existed, back in 2007.
But as time passes, and documentation gets written, knowledge improves.
Therefore, I recommend you read the newly released Composition chapter of the MP Authoring Guide instead
http://technet.microsoft.com/en-us/library/ff381321.aspx – and start building your custom modules to embed scripts as Brian Wren describes in there, so that you can share them between multiple rules and monitors.
This said, below is the original post.
There is not a lot of documentation for System Center Operations Manager 2007 yet.
It is coming, but there’s a lot of things that changed since the previous release and I think some more would only help. Also, a lot of the content I am seeing is either too newbie-oriented or too developer-oriented, for some reason.
I have not yet seen a tutorial, webcast or anything that explains how to create a simple unit monitor that uses a VBS script using the GUI.
So this is how you do it:
Go to the “Authoring” space of OpsMgr 2007 Operations Console.
Select the “Management Pack objects”, then “Monitors” node. Right click and choose “Create a monitor” -> “Unit Monitor”.
You get the “Create a monitor” wizard open:
Choose to create a two-states unit monitor based on a script. Creating a three- state monitor would be pretty similar, but I’ll show you the most simple one.
Also, choose a Management pack that will contain your script and unit monitor, or create a new management pack.
Choose a “monitor target” (object classes or instances – see this webcast about targeting rules and monitors: www.microsoft.com/winme/0703/28666/Target_Monitoring_Edit… ) and the aggregate rollup monitor you want to roll the state up to.
Choose a schedule, that is: how often would you like your script to run. For demonstration purposes I usually choose a very short interval such a two or three minutes. For production environments, tough, choose a longer time range.
Choose a name for your script, complete with a .VBS extension, and write the code of the script in the rich text box:
As the sample code and comments suggest, you should use a script that checks for the stuff you want it to check, and returns a “Property Bag” that can be later interpreted by OpsMgr workflow to change the monitor’s state.
This is substantially different than scripting in MOM 2005, where you could only launch scripts as responses, loosing all control over their execution.
For demonstration purpose, use the following script code:
On Error Resume Next
Dim oAPI, oBag
Set oAPI = CreateObject(“MOM.ScriptAPI”)
Set oBag = oAPI.CreateTypedPropertyBag(StateDataType)
Const FOR_APPENDING = 8
strFileName = “c:\testfolder\testfile.txt”
strContent = “test ”
Set objFS = CreateObject(“Scripting.FileSystemObject”)
Set objTS = objFS.OpenTextFile(strFileName,FOR_APPENDING)
If Err.Number <> 0 Then
[edited on 29th of May as pointed out by Ian: if you cut and paste the example script you might need to change the apostrophes (“) as that causes the script to fail when run – it is an issue with the template of this blog.] [edited on 30th of May: I fixed the blog so that now post content shows just plain, normal double quotes instead than fancy ones. It seems like a useful thing when from time to time I post code…]
The script will try to write into the file c:\testfolder\testfile.txt.
If it finds the file and manages to write (append text) to it, it will return the property “State” with a value of “GOOD”.
If it fails (for example if the file does not exist), it will return the property “State” with a value of “BAD”.
In MOM 2005 you could only let script generate Events or Alerts directly as a mean to communicate their results back to the monitoring engine. In OpsMgr 2007 you can let your script spit out a property bag and then continue the monitoring workflow and decide what to do depending on the script’s result.
So the next step is to go and check for the value of the property we return in the property bag, to determine which status the monitor will have to assume.
We use the syntax Property[@Name=’State’] in the parameter field, and we search for a content that means an unhealthy condition:
Then we decide which status will the monitor have to assume in the healty and unhealty conditions (Green/Yellow or Green/Red usually)
Optionally, we can decide to raise an Alert when the status changes to unhealthy, and close it again when it goes back to healty.
Now our unit monitor is done.
All we have to do is waiting it gets pushed down to the agent(s) that should execute it, and wait for its status to change.
In fact it should go to the unhealthy state first.
To test that it works, just create the text file it will be searching for, and wait for it to run again, and the state should be reset to Healthy.
Have fun with more complex scripts!