SCOM Visual Studio Authoring – VBScript and PowerShell Based Alert Rules (Part 1)

In this series of posts I’ll be going over both VBScript and PowerShell based alert rules. The first one will be the VBScript based alert rule which looks for the existence of a folder c:\Leibundgutski and alerts if it is detected. Secondly I’ll cover a PowerShell based alert rule in part 2 which looks for the existence of a file c:\Leibundgutski\Andy.txt and alerts if it is detected.

First things first, the complete solution is available for download here:

For the VBScript alert rule I’ll start by explaining how the script works


  • Ok, the first thing worth noting is that this script will accept two parameters from the DataScource “sFolderLocation” and “bDebug”. sFolderLocation is the folder that the script will look for to determine if their is an error condition or not. In this case by default its the folder c:\Leibundgutski but it can be overridden to whatever you like in the console. The bDebug parameter (True/False) just tells the script if I want it to enter an event log entry each time it runs or discovers and error condition.
  • Set oAPI = CreateObject(“MOM.ScriptAPI”) – This is calling the SCOM scripting API for use in the script.
  • Set oBag = oAPI.CreatePropertyBag() – This is using the SCOM scripting API to create a property bag object. Think of it as a “bag” you can put things into and then return to the SCOM workflow.
  • Call oAPI.LogScriptEvent(“VBScriptProbe.vbs”,101,0,”VBScriptProbe.vbs executed”) – Use the LogScriptEvent to log events to the Operations Manager event log
  • oBag.AddValue “Result”, “BAD” – Here I’m creating a property of “Result” in the bag with a value of either GOOD or BAD that will be used to determine whether or not to alert.
  • oBag.AddValue “sFolderLocation”, sFolderLocation – Here I’m creating a property of “sFolderLocation” with the value of the folder that is being monitored for later use in the alert description.
  • oAPI.Return(oBag) – Finally when its all done we return the bag to the DataSource\Workflow.

VBScript DataSourceVBscriptAlertRuleDataSouce1The DataSouce is where you create a configuration for your VBScript. This particular DataSource includes the configuration for how often the script is ran. Here’s the DataSourceModuleType Documentation:


  • ID – “ScriptedAlertRule.VBScriptProbe.DataSource” – This is the unique name used to reference the DataSource within the management pack.
  • Accessibility – “Internal” – That indicates the DataSource can only be referenced within this management pack, other MPs cannot use it.

Configuration – These Items are used to initiate the variables that are passed to the MemberModules. These variables will all be set in the actual rule configuration.

  • name=”IntervalSeconds” type=”xsd:integer” – Setting for how often the script will be ran
  • name=”TimeoutSeconds” type=”xsd:integer” – How long ths script runs before it times out
  • name=”sFolderLocation” type=”xsd:string” – The location of the folder to monitor
  • name=”bDebugFlag” type=”xsd:boolean” – Whether or not the script will be ran in debug mode (if its true it will write an event log entry, check out the script for how that works)

OverridableParameters – Notice I’m setting all the configuration items as overridable. None of them have to be, it just allows the option for each variable to be overridden in the console.The IDs for the overridable parameters could be named anything you like, I make them the same for easy readability. The part that is actually referencing each configuration item is the $Config/VariableName$ portion.

MemberModules – This is where you pass the variables to the script, and set the configuration items for its DataSource.

DataSource – So the datasource we’re creating is actually just a configuration for another datasource that combines a VBScript probe with a scheduler.

  • ID – “DS” this is the name used to reference this module within the scope of the datasource
  • TypeID – “Windows!Microsoft.Windows.TimedScript.PropertyBagProvider” – The Windows! portion is a reference to the “Microsoft.Windows.Library” MP and Microsoft.Windows.TimedScript.PropertyBagProvider is the datasource within that MP that we are passing our configuration to which runs the VBScript and a scheduler.
  • <IntervalSeconds> – This is where the configuration for how often the script is ran via the scheduler for the script
  • <SyncTime /> – I’m opting not to use this here. This would Sync the script across all the systems its ran on. There are use cases for doing this but be careful. Say all these systems are on a virtual host and all running at the same time and your script is a bit resource intensive you’ll end up with an angry virtual host.
  • <ScriptName> – The name of the script.
  • <Arguments> – The arguments being passed to the script.
  • <ScriptBody> – Rather than sticking the script here I separate out the script and reference it here to keep things clean
  • <TimeoutSeconds> – This is where the config item for how long the script runs before it times out.

Composition – “DS” – There’s only one member in this module, DS. This is where you call out the order of which things are ran in a datasource.

OutputType – System!System.PropertyBagData – This is indicating that we’re expecting an object from the script to pass up through the workflow to the rule.

VBScript Rule


Rule – The star of the show, this is where it all comes together; the script, the schedule, the alert. Rule documentation:

  • ID – “ScriptedAlertRule.VBScriptProbe.AlertRule” – This is the unique name used for referencing the rule within the management pack.
  • Enabled – Is the rule enabled by default or not (overridable in the console)
  • Target – “Windows!Microsoft.Windows.Server.Computer” – Winodws! is a reference to the “Microsoft.Windows.Library” MP and “Microsoft.Windows.Server.Computer” is a target class within that MP that we are targeting the rule against.
  • ConfirmDelivery, Remotable, Priority, and DiscardLevel – you can look them up in the documentation above if you like, they are all optional parameters. Nothing super relevant to what we are doing here.

Category – Custom – You would think rule right, but no its not an option and it doesn’t make much sense but I don’t make the “rules”… lol

DataSource – Here’s where we set the default values that are passed down the various configurations of the workflow.

  • ID – “VBScriptProbe” – This is the unique name for this datasource within the scope of the rule.
  • TypeID – “ScriptedAlertRule.VBScriptProbe.DataSource” – This is the datasource we created above and are referencing to pass our variables IntervalSeconds, TimeoutSeconds, sFolderLocation, and bDebugFlag to.

ConditionDetection – The property bag that we created in the script, and passed up throught the datasource is surfaced here where we use the data in it to determine if there is an error condition for the property of “result” equaling “BAD”. If the condition detection is met the rule moves along to the write action. These can be made with multiple expressions for more advanced logic if necessary. We’ll go over that some other time.

WriteAction – This is the configuration for the alert.

  • ID – “GenerateAlert” – This is the unique name for this write action within the scope of the rule.
  • TypeID – “Health!System.Health.GenerateAlert” – Health! is a reference to the System.Health.Library MP and the System.Health.GenerateAlert is a write action within it. System.Health.GenerateAlert Documentation:
  • Priority – Alert Priority – 0-2 (low, medium, high)
  • Severity – Alert Severity – 0-2 (information, warning, error)
  • AlertmessageID – “$MPElement[Name=”ScriptedAlertRule.VBScriptProbe.AlertRule_AlertMessageResourceID”]$” – This is the unique name given to the alert and is used for providing “friendly” name within the console, more on this in a moment (see “string resource” below).
  • AlertParameters – These are used as variables that can be surfaced to the alert message within the console. Here’s a good resource for various options for parameters: The alert parameter for this rule is the folder name which was referenced from the property bag created in the VBScript.

String Resource – This one is kinda weird, but in essence it represents the alert message and is required if you’re going to create an alert. Notice its the same as the AlertMessageID (without all the MPElement drapery).


Language Packs – Not required but if you want your stuff to look pretty in the console you’ll want to take the time to configure these.


  • ID – ENU – English. you can do multiple languages for any given anything so keep that in mind if you want to do multilingual MPs.
  • Default – Default language I think? Also, If you split up your language pack definitions in visual studio like I do it will get angry if you put true on one and false on another. Or maybe its all of them…. I’m not sure, for my purposes false is grand and it will likely be the same for you.
  • DisplayString ElementID – This corresponds to those unique TypeID identifiers for rules and alerts and provides friendly display data for them in the console.
  • Remember that AlertParameter earlier in the Writeaction? This is where you can reference the variable in the KB for the console. Take notice that the AlertParameter1 begins at 1 and goes on to Alertparameter2, 3, 4 etc but the reference in the description begins at zero {0} and then {1}, {2}, etc. I’ve always thought it odd that one reference sequence begins at 1 and the other at 0. Just thought I’d point it out as something to keep in mind when trying to reference the correct variable.
  • KnowledgeArticle – This is the KB for the alert, pretty straight forward. check the documentation if you want more info.

That ends things for today. Stay tuned for part 2 where I will go over a Powershell based alert rule with the bonus of an example of alert suppression.

Part 2 – SCOM Visual Studio Authoring – VBScript and PwerShell Based Alert Rules Part 2

Site Index –