SCOM Visual Studio Authoring – Basic Alert Rule

Welcome back, today will be a shorter one than last time. A basic alert rule. This rule looks for an application event log with an event ID of “1234” and an event source of “TestSource”. It will then alert when that condition is met. Included in the project is a script (Make-TestEventLog.ps1) that will create a test event log entry. That’s about all there is to it. Lets begin!

Download the MP here:

Alert Rule XML:



  • ID – “BasicAlertRule.TestSource1234.AlertRule” – This Uniquely Identifies the rule within the management pack
  • Enabled – “True” – This rule is enabled by default for all targeted objects
  • Target – “Windows!Microsoft.Windows.Server.Computer” – This is the class that the rule targets, in this case all Windows server computers.
  • Category – Alert – Its an Alert rule so that’s the category


  • ID – “DS” – This uniquely identifies the data source item within the scope of the rule, its not global to the MP
  • TypeID – “Windows!Microsoft.Windows.EventProvider” – Microsoft.Windows.EventProvidere Documentation: Basically the “Windows!” portion is an alias that references the Microsoft.Windows.Library MP and the “Microsoft.Windows.EventProvider” portion references that data source within that MP which we are creating a configuration for.
  • ComputerName – “$Target/Property[Type=”Windows!Microsoft.Windows.Computer”]/NetworkName$” – This is a reference to the “NetworkName” property of the parent class to the Windows.Server.Computer class we are using to target our rule against. It’s essentially just the name of the computer the rule will be running on.
  • Logname – Application – This is the event log that the rule is monitoring (application, security, etc).
  • Expression – This is the filter to find the events we’re looking for in the application log.

WriteActions – In this case it’s configuring the alert for the rule.

  • ID – Alert – Again, just an identifier scoped only to the rule, not the entire mp.
  • TypeID – “Health!System.Health.GenerateAlert”  System.Health.GenerateAlert Documentation: (the screenshot above has incorrect info cuz I don’t know how I’m too lazy to fix it in the screenshot). So like the other TypeID we’re targeting an outside MP and creating a configuration for a writeaction within it.
  • Priority and Severity are pretty straight forward and covered in the documentation linked in the TypeID above.
  • AlertmessageID – “$MPElement[Name=”BasicAlertRule.TestSource1234.AlertRule.AlertMessage”]$” – 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: Thanks Kevin (read his stuff its good).
  • All the other stuff, meh… Don’t really need it here for this example.

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). Nothing more to really say about that I suppose.


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? 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.

Alright, another exciting day in SCOM. Next time we’ll delve into scripted alert rules. Thanks for dropping by!

Site Index:


SCOM Visual Studio Authoring – Site Index

Site Index

SCOM Authoring:

  1. Creating a New Management Pack
  2. Basic Class Discovery
  3. Basic Seed Class Discovery
  4. VBScript and PowerShell Based Discoveries
  5. Basic Alert Rule
  6. VBScript Based Alert Rule
  7. PowerShell Based Alert Rule

SCOM Scripting

  1. Get Alerts by Management Pack
  2. Get Empty Classes


  1. Windows Service Monitor

SCOM Visual Studio Authoring – VBScript and PowerShell Based Discoveries

Greetings, today I’m going to go over both VBScript and PowerShell based discoveries.

The full project can be downloaded here, its probably a lot easier to follow along if you have it:

VBScript Based Discovery – This configuration will discover and populate a class based off the existence of a folder C:\SCOM on a server.

PowerShell Based Discovery – This configuration will discover and populate a class based off the existence of the file C:\SCOM\Test.txt on a server and populate a custom property with a value of true of false if the file contains the string

Exciting right? OK, lets get started

VBScript Based Discovery

We’ll start with the class configuration


  •  The “ID” of “ScriptedDiscovery.SCOMFolder_VBScript.Class” is used to uniquely identify the class we’ll be populating with the VBScript discovery.
  • “Accessibility” is set to public so the class is able to be referenced from other management packs.
  • This class is based of the “Base” class of “Windows!Microsoft.Windows.Server.Computer” from the Microsoft.Winodws.Library management pack because I want my class to target all windows servers.

More on classes here:

Next, we’ll work from the bottom up. The script does the heavy lifting and populates the class. The probe is the configuration for running the script. Then the datasource will add in the schedule for how often the script runs, and finally the discovery brings it all together.

The Script


Each script that is used in SCOM will need to bring in the SourceId and ManagedEntityID. I believe these are used to keep track of the workflow within SCOM. You’ll also need to initiate the “MOM.ScriptAPI” that is used to interact with SCOM. Notice the oAPI.CreateDiscoveryData. That is creating the object used to surface the discovery data to the class using the “CreateClassInstance” and then on to the “AddProperty” which is used to populate the key of the parent class (Microsoft.Windows.Computer). Note, you’ll need to populate the key property of any classes in the class hierarchy that contains a key property. In this example there are many classes in the hierarchy and the only one that has a key property in this example is Microsoft.Windows.Computer which hosts Microsoft.Windows.Server.Computer that our class is based off of. Anyway, knowing exactly how it works isn’t super important for the less complex discoveries. While you’re figuring things out just know to follow this basic formula of populating a class and you should be able to accomplish most of what you need. Lastly the discovered instance is added to the oDiscocveryData object that is then returned to the workflow for class population.

Whew, that was a lot of words. Hopefully I didn’t loose you. Now, onto the Probe.


The probe in this example is used to run the script and pass the parameters it requires in order to run.


  • ID – used to uniquely identify the probe within the management pack
  • Comment – Nice, I put df. Real descriptive. I’m not changing the screenshot
  • Accessibility – Public, other management packs can use it.

Configuration – These are used for passing parameters to the probe and then to the script. We’ll define their defaults in the discovery later in this case

OverridableParameters – Of the Configuration parameters that are configurable for the probe within the management pack these are surfaced to the user as parameters that can be changed in the SCOM console.


  • TypeID – In this example its the reference to the configuration that allows you to run a VBScript.
  • ID – same old story, its used to uniquely identify the probe action in the scope of the current ProbeActionModuleType.
  • Comment – A better comment than my ProbeActionModuleType that’s for sure.
  • ScriptName – Name your script, the sky is the limit. Try and make some kind of sense when naming them though.
  • Arguments – These are the arguments you’re passing to the script They can be parameters described in the configuration and passed in elsewhere or references to existing variables or a string you define right there.
    • $MPElement$ – Required
    • $Target/Id$ – Required
    • $Target/Property[Type=”Windows!Microsoft.Windows.Computer”]/PrincipalName$ – This is the property for the name of the computer. I’m passing it in to re-populate the same property in the parent class of the class we’re discovering for. I could just surface it in the script itself rather than passing it in but this way I know I’m being consistent with the parent class for sure. If you go to the SCOM console and look up the windows computer class in the discovered inventory area you’ll see the source of the property.
    • $Config/FolderLocation$ – This is the folder location parameter I’ll be defining in the data source and passing down to this probe. Its going to be the c:\SCOM folder I talked about earlier by default. This is an overridable parameter because its been designated as such in the overridable parameter area.
    • $Config/bDebug$ – This is a variable for whether or not the script will be in debug mode or not. There’s an if/endif in the script that sets whether or not it logs an event in the SCOM event log when it runs. This is an overridable parameter because its been designated as such in the overridable parameter area.
  • ScriptBody – This is the reference to the script I’m using to perform the discovery. Rather than include the whole script directly in the probe configuration I think its cleaner to separate them.
  • TimeoutSeconds – This is how long the scripts gets before it is terminated. I have this as a configurable parameter that will be defined in the data source and is overridable by the user in the console.

Composition – This denotes what order things are ran in the probe. There’s only one thing to be ran here as I’m not combining the script discovery with anything else at this point so its just the “VBSScriptProbe” and yes I just noticed the spelling error. Not changing it here.

OutputType – The type of data being returned to the workflow. Discovery data in this circumstance

InputType – The type of data the probe accepts, base data here.

The DataSource is next

The DataSource in this case will be combining the scripted probe that does the discovering of the folder with a schedule configuration that will be used to determine how often to run the discovery.



  • ID – used to uniquely identify the datasource within the management pack
  • Accessibility – Public, other management packs can use it.


  • Notice “FolderLocation”, “bDebug”, and “TimeoutSeconds”, these configuration items are carried over from the probe and the values will be passed down from the Discovery.
  • Interval – We gain interval as a parameter and pass it to the scheduler defined in the data source section.

OverridableParameters – of the configuration items these are the ones that can be overridden by the user in the SCOM console


  • ID –  “Scheduler” is the name that uniquely identifies this DataSource in within this DataSourceModuleType.
  • TypeID – “System!System.Scheduler” is the scheduler DataSource i’ll be using from the System.Library management pack. “System!” is the alias to that MP and “System.Scheduler” is the DataSource I’m referencing in that MP.
  • Interval – <interval> comes from the configuration of the referenced “System.Scheduler” datasource and $Config/Interval$ will be how often in minutes the discovery is ran and will be defined in the discovery.


  • ID – “VBSScriptProbe” is the name that uniquely identifies this Probe action within this DataSourceModuleType. I still haven’t learned to spell it seems.
  • TypeID – Notice i’m just referencing my probe that we just went over “ScriptedDiscovery.VBScrptFolderFinder.Probe”. No alias needed here because its within the scope of the current management pack.
  • <FolderLocation>, <bDebug>, and <TimeoutSeconds> come from our “ScriptedDiscovery.VBScrptFolderFinder.Probe” configuration and $Config/FolderLocation$, $Config/bDebug$, and $Config/TimeoutSeconds$ will be defined in the discovery.

Composition – This denotes what order things are ran in the DataSourceModuleType. It works inside out so the Scheduler runs first and then the VBSScriptProbe runs second.

OutputType – The type of data being returned to the workflow. Discovery data in this circumstance

And now the star of the show, the Discovery



  • ID – “ScriptedDiscovery.VBScrptFolderFinder.Discovery” This is used to reference the Discovery.
  • Target – “Windows!Microsoft.Windows.Server.Computer” This is what we are targeting this discovery against. In this case its all windows servers that the discovery will run against. “Windows!” is an alias for the “Microsoft.Windows.Library” where this target class lives.

Category – Its always going to be “Discovery” for a discovery

DiscoveryTypes – In this case its only going to be <DiscoveryClass TypeID=”ScriptedDiscovery.SCOMFolder_VBScript.Class”> which is the class we created in this management pack that we are populating with servers discovered by our discovery.

DataSource – Finally we’re defining those configuration items from the datasource and the probe!

And wallah that’s it, a VBScripted discovery. I’ll be more brief with the explanation of the PowerShell based discovery. I’ll go over the class, probe, and script and the rest (discovery and datasource) pretty much follows the same formula as the VBScripted discovery.

The PowerShell based discovery populates a class based of the existence of a file “C:\SCOM\test.txtand populates a property if the file contains “”. So now without further ado, the explanation of how to create the discovery.

Class Configuration


  •  The “ID” of “ScriptedDiscovery.SCOMFile_PowerShell.Class” is used to uniquely identify the class we’ll be populating with the PowerShell discovery.
  • “Accessibility” is set to public so the class is able to be referenced from other management packs.
  • This class is based of the “Base” class of “Windows!Microsoft.Windows.Server.Computer” from the Microsoft.Winodws.Library management pack because I want my class to target all windows servers.
  • Notice Property with ID of “bContainsContent” it denotes whether or not the file contains “” or now. Its not a key property and is of type bool so its a true or false value only.

The Script


As before with the VBScript, with the PowerShell script we need to bring in the SourceId and ManagedEntityID. The ComputerName, bDebugFlag and a FileLocation parameters are also brought into the script. Again we’ll initiate the “MOM.ScriptAPI” that is used to interact with SCOM just like in the VBScript. Next the DiscoveryData object is created for use in holding the discovery data. Its used to surface the discovery data to the class at the very end of the script. Moving along we create an instance object and set it to the class we want to populate our discovery data with and add some properties to it before adding it to the DiscoveryData object and returning it to the workflow. up next, probe time.

PowerShell Probe


Ok, so the big difference here from the VBScript probe configuration is that we are using a different ProbeAction TypeId of “Windows!Microsoft.Windows.PowerShellDiscoveryProbe” which allows for the use of PowerShell in the scripted discovery and instead of the parameters being passed in one big line like they were in the VBScripted discovery they are passed individually through their own separate xml configurations.

One other thing I’ll mention that helps me visualize how this process works is that Configuration data for the discovery flow down to the script from the discovery, to the datasource, the probe, and then the script and than the discovered dta goes back up in reverse ending at the class.

Hope this helps, thanks for reading. Next time we’ll do a rule configuration that alerts. See you then!

SCOM Visual Studio Authoring – Site Index