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

Finally, part 2. I’ll cover a PowerShell based alert rule 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 PowerShell 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 “FileLocation” and “bDebug”. FileLocation is the file that the script will look for to determine if their is an error condition or not. In this case if you skip ahead and look at the rule configuration you’ll see that by default its the fileC:\Leibundgutski\Andy.txt that its looking for 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.
  • $API = New-Object -comObject ‘MOM.ScriptAPI’ – This is calling the SCOM scripting API for use in the script.
  • $Bag = $api.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.
  • $API.logscriptevent(“PowerShellProbe.ps1”,100,0,“PowerShellProbe.ps1 Ran”)

    – Use the LogScriptEvent to log events to the Operations Manager event log

  • $bag.AddValue(‘Result’, “GOOD”) – 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.
  • $bag.AddValue(‘FileLocation’, $FileLocation) – Here I’m creating a property of “FileLocation” with the value of the file location that is being monitored for later use in the alert description.
  • $Bag – Finally when its all done we return the bag to the DataSource\Workflow.

PowerShell DataSource


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


  • ID – “ScriptedAlertRule.PowershellProbe.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=”FileLocation” type=”xsd:string” – The location of the file to monitor
  • name=”bDebug” 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)
  • name=”TimeoutSeconds” type=”xsd:integer” – How long ths script runs before it times out
  • name=”Interval” type=”xsd:integer” – Setting for how often the script will be ran (in minutes)

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 – The datasources we are combining in this MemberModule is marrying a scheduler to our PowerShell probe. Without a schedule the script will never run.

  • ID – “Scheduler” is the name used to reference this module within the scope of this datasource.
  • TypeID – “System!System.Scheduler” – The “System!” portion is a reference to the “System.Library” MP and “System.Scheduler” is the datasource within that MP that we are passing our configuration to which runs the schedule for the script.
  • <Interval> – This is where the configuration for how often the script is ran via the scheduler for the script (in minutes).


  • ID  – “PowerShellProbe” is the name used to reference this module within the scope of this datasource.
  • TypeID – “Windows!Microsoft.Windows.PowerShellPropertyBagProbe” – The “Windows!” portion is a reference to the “Microsoft.Windows.Library” MP and “Microsoft.Windows.PowerShellPropertyBagProbe” is the datasource within that MP that we are passing our configuration to for the script.
  • <ScriptName> – The name of the script.
  • <ScriptBody> – Rather than sticking the script here I separate out the script and reference it here to keep things clean
  • <Parameters> – This is where you configure parameters to pass to the script.
  • <TimeoutSeconds> – This is where the config item for how long the script runs before it times out goes.

Composition – “Scheduler” and “PowerShellProbe – This is where you reference the DataSources and what order you want them to run in.

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.

PowerShell Rule


Rule – This is where the rubber meets the road. The script, the schedule, the alert all come together here. Rule documentation:

  • ID – “ScriptedAlertRule.PowerShellProbe.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 condole)
  • 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. In this case its all the windows server computers.
  • 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… har har

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

  • ID – “PowerShellProbe” – This is the unique name for this datasource within the scope of the rule.
  • TypeID – “ScriptedAlertRule.PowershellProbe.DataSource” – This is the datasource we created above and are referencing to pass our variables Interval, TimeoutSeconds, FileLocation, and bDebug 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 stored 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.PowerShellProbe.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 FileLocation name which was referenced from the property bag created in the PowerShell Script.

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’s all there is to it, fun stuff. I think next time we’ll circle back and go over seed based discoveries.

Site Index –