SCOM – Windows Service Monitor Management Pack

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

NOTE – If you already have a previous version of this MP imported into SCOM and are updating to a newer version, backup your existing MP and follow the instructions below to copy the service monitoring configurations to the updated PM.

The progression should go:

  • Export your current Windows Service Monitoring MP.
  • Download the updated version, copy it to another location
  • Open the MP you exported from SCOM and copy the old service configurations to the new MP
  • So from this (search for “Dim Arr” to find it):wsm_updatemp
  • To this:wsm_update1mp
  • Now import the new MP into SCOM and you’re good to go

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

** Changelog **

Updates 2/25/2016

  • Added console tasks for service starting/stopping/status
  • Added a recovery to the service monitor for automatic service restart (disabled by default). It uses the three strikes and you’re out rule. By that I mean by default it will try to start a service 3 times in a 24 hour period and then it will not try to start the service again. This is to prevent a constant start/stop loop and is able to be configure to your preference
  • Added a timer reset monitor for when the 3 strike limit is reached, this is enabled by default and will automatically close by default
  • Fixed a small bug in the “ServiceMPEditor.ps1” tool where it wouldn’t import if you had 0 entries

Blog post begins here (with edits to reflect current updates)

I dislike the default Windows Service Monitoring Template in SCOM. Here’s a few reasons why:

  • The templates create a lot of monitoring bloat. Each service template configuration comes with a lot of baggage:
    • Its own class
    • Its own discovery
    • 3 monitors
    • 8 overrides
  • It takes forever to add/edit/remove a large amount of services from the console
  • If you override “Alert only if service start type is automatic” and set it to “false” it will alert for all startup types. This is a bummer when you have some disabled ones out there or want to temporarily set one to disabled and not have SCOM alert.
  • No built in flexibility for days of the week or hours of the day filtering
  • This method will not scale very well

So how do we make things better, it appears there’s some room for improvement. I’ve been thinking about and working on solving this problem for years and in that time two approaches to solving the problem have always float to the top:

  1. A scripted monitoring solution
  2. An optimized version of the built in template method

There’s pros and cons to each of these approaches as well

A Scripted Monitoring Solution

Pros:

Cons:

  • Performing overrides and alerting at the individual service level is a bit cumbersome

An optimized version of the built in template method

Pros:

  • You get most of the features you get with the template monitoring and some added extra ones that aren’t in the default template monitoring.
  • Each service has its own alert/monitor.

Cons:

  • Although it will scale better than the built in solution, it won’t scale up as well as the scripted solution.

An early version of the optimized solution is what I have here for you today. I’ve been working the last couple weekends on getting this put together and here’s a high level overview of the features I have so far:

  • I used the same datasource for service monitoring that SCOM uses so whatever magic they have going on to optimize that process should be included
  • Date and time filtering so you can exclude certain days/times from monitoring on a per service or service object basis
  • Console tasks for service starting/stopping/status
  • Automatic service recovery (disabled by defuault). Works on a 3 strikes and you’re out format. After 3 failures in a 24 hour period it will stop trying to restart the service. This is overridable to your needs.
  • Timer reset monitor (closes itself after 24 hours) to watch for and alert on the 3 strike out situation. This is enabled by default
  • Monitor all service startup types with the exclusion of disabled services from alerting
  • Created a custom discovery which discovers and adds all the service objects to one class rather than scattering them about like the templates do
  • Created a Service MP Editor to allow you to add/remove or mass import services to be monitored

Getting started

  • First download the MP and Service MP Editor here: https://gallery.technet.microsoft.com/SCOM-Windows-Service-c9fc3f95
  • Second, this is still really early days for this MP. Don’t go throwing it in production right away without testing. I’m releasing the MP in its current state hoping to get feedback from other people who might be interested in testing it out at this point.
  • Third, the Service MP Editor is really rough and only sort of tested. You’ll want to double check your MP before you import it back into SCOM or just edit the MP directly to add service monitoring configurations (more on how to do those things later)
  • Ok, so now that we have these things out of the way lets get started, you’ll see that you have three files from the download. The Readme.txt directs  you to this blog, the ServiceMPEditor.ps1 is used to add/modify/remove services to the MP, and WindowsServiceMonitor.xml is the management pack.wsmfiles
  • You can go ahead and import the management pack into SCOM, there’s no services that are discovered by defaults so out of the box it doesn’t really do much until its configured
  • Once you have it imported go ahead and run the ServiceMPEditor.ps1 script, this will launch the service add/edit/remove powershell form

wsm_poshgui1

  • Basically, what this form does is export the management pack from SCOM and reads the service discovery vbscript contained within the MP. It then allows you to edit the xml utilizing the GUI, and then you can import it back in after saving the changes.
  • Again, remember to have the MP imported and then lets go through adding the first one together

wsm_poshgui2

  1. Management Server – Put in the server name of one of your SCOM management servers.
  2. Management Pack Location – This is where the MP will be exported to and updated. This is also where any service exports/imports will go to/from.
  3. Get MP Config – Select this button after steps 1 and 2 are completed, this will export the MP to the “Management Pack Location”.
  4. New Service – Select this button to start a new service configuration
  5. Service Name – Put the “Service name” in here. Do not put in the “Display Name”, that will not work (unless they are the same).
  6. Confirm Service Edit – Select this after choosing all your service monitoring options. Dates that are checked will be days that the service is monitored and the time between “Monitor Start Time” and “Monitor End Time” is when the service will be monitored.
  7. Save MP Config – Once you’ve added your service(s) to be monitored select this button to save the service monitoring configuration

Next you’ll probably want to take a look at the MP and verify the GUI added in the services properly. A little about what is going on behind the scenes

The discovery script in the MP’s xml has an array that will hold the configurations for each service that will be discovered:

wsm_vbs1

After you save select “Save MP Config” in the GUI anything that’s in the “Services” list will be placed in the discovery script:

wsm_vbs2

Add the numbers for each day you want monitored together

After you see a couple of them in there you’ll get the idea of how it works and maybe you’ll prefer editing it manually, its up to you, the key is you have choices =)

  • Ok, back to main bullet points. So next you’ll want to head over to the console and check to make sure your service(s) is discovered:

wsm_discoveredinv

  • Looks pretty good – Some words about that.
    • The discovery interval is 86400 seconds (once a day). If you don’t want to wait for the discovery interval just restart the monitoring agent and it will run the discovery right away. You can also override the discovery interval if you like (Go to SCOM Console – Choose “Authoring” – “Management Pack Objects” – “Object Discoveries” – Search for: Windows Service Monitor Discovery)
    • You can also enable debug if you like, this will write 101 events to the SCOM event log each time the discovery is ran. It will let you know that it ran and which services the script discovered.
  • Lastly, lets take a look at the monitor configuration:

wsm_monitor

  • The big thing to mention here are the overrides: You can override the start/end times and the days of the week mask for one or a group (if you create one) of service objects here. Or just stick with your discovery settings. The world is your oyster.

Additional Monitoring Features Explained

  • Console tasks to start/stop and get service status. Pretty self explanatory, they will show up on the alerts as well.

wsm_consoletasks

  • Next is the recovery task. This is disabled by default. When enabled it will try to start a service automatically 3 times in a 24  hour period by default. If you would like to use this feature or change the settings you can override these values in the “Windows Service Monitor (Custom MP)” monitor

wsm_monitorrecovery

  • Also, there is another monitor that watches for when the service is restarted 3 times in a 24 hour period. This is enabled to alert by default and is called “Excessive automated service restart monitor”. Its a reset timer based monitor meaning that when it alerts it will stay open and then close after a period of time (24  hours by default)

 

I think that’s the basics on how things work. Again this is really almost a POC version of this management pack. I would love it if you would try it out and let me know your feedback! You can reach me via the comments or LinkedIn: www.linkedin.com/pub/andy-leibundgut/ab/23/a72

Honey do list:

  • See about adding performance gathering rules (disabled by default)
  • Add some views
  • Maybe some reporting?
  • Add an alert description that can be configured per service in the discovery (ServiceMPEditor.ps1) so each service can have its own unique “KB” in the alert description.
  • Make ServcieMPEditor.ps1 a little prettier.
    • Maybe add a folder picker.
    • Prefill Management Server/Folder with last location (config file or something)
  • What else? let me know your ideas!

Site Index

Advertisements

SCOM PowerShell – Get Empty Classes

This little gem is fabulous.

Here’s the use case: Your environment has about a million MPs that have been imported by a long storied line of SCOM professionals that came before you and have long since gone. You have no idea if all these MPs are even being used anymore. There could be a bunch that aren’t even monitoring anything because the servers they were originally targeted at have all moved on to the graveyard. The only thing you know is its definitely time to clean house!

This script along with MP Viewer (http://www.systemcentercentral.com/download/mp-viewer-for-operations-manager-2012-2/) is a good start and can help you with identifying MPs that aren’t doing anything. Just put in your management server name and filter your MPs by name or have it go through all of them by using a “*”. It will then export a list of classes for each MP and let you know if they are empty or not.

Download the script here: https://gallery.technet.microsoft.com/SCOM-PowerShell-Get-Empty-cd632e89

Site Index

SCOM PowerShell – Get Alerts by Management Pack

This PowerShell script will return SCOM alerts by management pack (or management packs). Add your SCOM management server name and filter by MP(s) and it will return a bunch of alert info and save it to a csv file. I whipped it up quick today and thought I’d share it in case someone might find it handy. Its not super fancy but will get you started.

Download here: https://gallery.technet.microsoft.com/SCOM-Powershell-Get-Alerts-c432a65e

Site Index

SCOM Visual Studio Authoring – Basic Seed Class Discovery

In this blog post I’ll go over a basic seed class discovery. Basically a seed class is a class that normally utilizes a low cost discovery method (in this case a registry discovery) across a large group of servers to narrow the scope of which higher cost discoveries (A script in this case) then target in order to populate more classes.

So to further illustrate, say you have 1000 servers and an application that has 2 server types. You would like to create a class for each server type and you have a few things that can be used to identify the 2 server types:

  • Both server types have a registry key “HKLM:SOFTWARE\Leibundgutski”
  • One server type can be uniquely identified by the existence of a folder”C:\Leibundgutski”
  • The other server type can be uniquely identified by the existence of a file “C:\Andy.tx”

OK, so assume you have 3 of each server type for a total of 6 servers that represent your application and you want one class for each server type (2 classes in total). You have some options to discover them:

  1. High Cost – You create 2 classes that utilize a scripted discovery that target something like Windows Server Computer. Scripts have a lot of overhead and are considered a high cost method of doing things so what would happen is you have 2 scripts running on each of the 1000 servers each time the discoveries are ran to populate the two classes. That’s a lot of scripts (2000 scripts ran)!
  2. Low Cost – You create 3 classes. One seed class that targets that same Windows Server Computer and then 2 more classes, one for each server type, that target the seed class. The seed class utilizes a registry discovery which is a very low cost method of discovery. The registry key only exists on the 6 (total) application servers so only those 6 servers are populated within the seed class. Then what you do is run the higher cost scripted discoveries against that seed class and now you’re only running 12 high cost scripted discoveries across your environment.

If you haven’t guessed number 2 is the way to go. What I’ll be going over today is how to author a basic seed class discovery with Visual Studio. The code can be found here: https://gallery.technet.microsoft.com/SCOM-Visual-Studio-394b6d37

Alright so we’ll start with the seed class

BasicSeedClass_SeedClass

This is the class that represent all 6 application servers that we will then use as a target for the other two classes

  • ID – This uniquely identifies the class within the management pack
  • Comment – Comments about the class, put whatever you want in there
  • Accessibility – Public, when set to true this class can be used by other management packs provided you seal this management pack
  • Abstract – false, abstract classes have no instances and exist only to act as a base class for other classes. Don’t worry about this for now, consult the documentation if you want to know more (links to class documentation are in my MP)
  • Base – This is the class you are basing your class off of
  • Hosted – False, this is not hosted by another class
  • Singleton – False, this class has unique instances that will be discovered (IE its not a group or anything like that. Each discovered server is separate)

Next, seed class discovery

BasicSeedClass_Discovery

This is a registry base discovery used to populate the seed class. It discovers a server instance when the registry key HKLM\Software\Leibundgutski is found.

Discovery

  • ID – BasicSeedDiscovery.LeibundgutskiRegKey.Discovery – This is the name used to uniquely identify this discovery in the management pack.
  • Target – Windows!Microsoft.Windows.Server.Computer” – This is the class the discovery targets. “Windows” is a reference to the
    Microsoft.Windows.Library management pack and “Microsoft.Windows.Server.Computer is a class within that mp.
  • Remotable – true – this workflow can run for agentless monitoring.
  • Enabled – true – this discovery is enabled. It will run by default once its imported.

DiscoveryClass – BasicSeedDiscovery.Seed.Class – This is the class the discovery will discover.

DataSource

  • ID – “DS” – This is the name that uniquely identifies this datasource within the scope of this discovery.
  • TypeID – “Windows!Microsoft.Windows.FilteredRegistryDiscoveryProvider” – “Windows” is a reference to the
    Microsoft.Windows.Library management pack and “Microsoft.Windows.FilteredRegistryDiscoveryProvider” is a registry discovery datasource within that management pack that I’m for this discovery.
  • ComputerName – “$Target/Property[Type=”Windows!Microsoft.Windows.Computer”]/PrincipalName$” – This works out to be the computer name that the discovery is being ran on. Its a property of a parent class of Microsoft.Windows.Server.Computer.
  • AttributeName – “LeibundgutskiKeyExists” – This uniquely identifies the value this registry attribute definition is pulling from the registry.
  • Path – “SOFWARE\Leibundgutski” – This is the location in the registry that the registry attribute definition is looking at.
  • PathType – “0” – zero specifies that we’re looking for  a registry key.
  • AttributeType – “0” – zero specifies that we are returning a true/false value (does it exist or not)
  • Frequency – “86400” how often does the discovery run in seconds (once a day)
  • ClassID – “$MPElement[Name=”BasicSeedDiscovery.Seed.Class”]$” – This reprisendts the class being discovered
  • InstanceSettings
    • Name – “$MPElement[Name=”Windows!Microsoft.Windows.Computer”]/PrincipalName$” – The parent of our seed class “Microsoft.Windows.Computer” has a primary key of PrincipalName which is required to be discovered. This is referencing which value to populate
    • Value – “$Target/Property[Type=”Windows!Microsoft.Windows.Computer”]/PrincipalName$” – It looks kind of weird but the class we are populating (the seed class) is based on the same class as the seed discovery targets. So we are referencing the PrincipalName of the discoveries target class to populate our seed class which in this case are the same.
  • XPathQuery
    • XPathQuery- “Values/LeibundgutskiKeyExists” – This represents the value we pulled in the RegistryAttributeDefinition.
    • operation – “Equal” – The conditional parameter that is used to compare the XPathQuery and Value.
    • Value – “true” – if the value held within the RegistryAttributeDefinition is true then discover the server.

Alright, that’s how you populate the seed class. Next we’ll go over the seedling classes and how they work.

BasicSeedClassSeedlings

So I’ll just go over major differences in these classes from the seed class. Each of these classes represent a particular type of server. One, a type of server that contains a folder c:\Leibundgutski, and the other which represents a type server that contains a file c:\Andy.txt. The other important difference is the base of these seedling classes is the seed class. Notice that instead of targeting all server computers like the seed class does I’m just targeting the seed class itself. In other words only the computers that contain the registry key HKLM\Software\Leibundgutski will have the logic that looks for the folder or file ran on it.

Now I’ll go over the seedling discovery script (LocationDiscovery.vbs)

BasicSeedClassVBS

This script is used by each of the seedling discoveries to populate their classes. It uses conditional if/then logic against the sLocation argument to determine whether to populate (see CreateClassInstance) either the folder or file class. Or both if they both happened to exist. Some of the SCOMey code and considerations to take note of in the script is that every 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” which the script uses 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 a 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. At the end is the oAPI.Return which returns the discovery data to the workflow so it can populate the class. One last thing to note is the LogScriptEvent which creates a logging entry (if bDebug is true) in the Operations Manager event log on the target computer.

Alright, lastly is the discovery configuration for the seedling classes

BasicSeedDiscoverySeedlingDiscovery

Each of the discoveries individually call the LocationDiscovery.vbs script to populate their seedling class.

Discovery

  • ID – This is used to uniquely identify the discoveries within the management pack
  • Target – This is the class the discovery targets (the seed discovery for both above)
  • Remotable – Whether the discovery can be used for agentless monitoring
  • Enabled – T/F is the discovery enabled by default

DataSource

  • ID – This is used to uniquely identify the datasource within the scope of the discovery
  • TypeID – This is referencing to a datasource configuration in the “Microsoft.Windows.Library” MP “Microsoft.Windows.TimedScript.DiscoveryProvider” which run a script on a schedule
  • IntervalSeconds – How often the script is ran in seconds
  • ScriptName – The name of the script
  • Arguments – These are the arguments passed to the script. See the description of how the script works above for information on the individual arguments
  • ScriptBody – Although you could just put the script in here I create a script item in visual studio and use an IncludeFileContent (see the Scripts\VBScript folder in the project) to reference it.
  • TimeoutSeconds – How many seconds before the script is set to time out.

That’s all for today, hope it was helpful. Next time I think I’ll skip around again and show you how to do a scripted monitor.

Site Index

 

 

 

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: https://gallery.technet.microsoft.com/SCOM-Visual-Studio-bfb42ec6

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

PowerShellAlertRule

  • 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

PowerShellAlertRuleDataSource

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: https://msdn.microsoft.com/en-us/library/Ee533617.aspx.

DataSourceModuleType

  • 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

PowerShellAlertRuleConfig

Rule – This is where the rubber meets the road. The script, the schedule, the alert all come together here. Rule documentation: https://msdn.microsoft.com/en-us/library/ee533583.aspx.

  • 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: https://msdn.microsoft.com/en-us/library/ee809352.aspx
  • 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: http://blogs.technet.com/b/kevinholman/archive/2007/12/12/adding-custom-information-to-alert-descriptions-and-notifications.aspx. 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).

PowerShellAlertRuleStringResource

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.

PowerShellAlertRuleLanguagePack

  • 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 – https://leibundgutski.wordpress.com/2015/09/23/scom-visual-studio-authoring-site-index/

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: https://gallery.technet.microsoft.com/SCOM-Visual-Studio-bfb42ec6

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

VBscriptAlertRuleScript

  • 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: https://msdn.microsoft.com/en-us/library/Ee533617.aspx.

DataSourceModuleType

  • 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

VBscriptAlertRule

Rule – The star of the show, this is where it all comes together; the script, the schedule, the alert. Rule documentation: https://msdn.microsoft.com/en-us/library/ee533583.aspx.

  • 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: https://msdn.microsoft.com/en-us/library/ee809352.aspx
  • 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: http://blogs.technet.com/b/kevinholman/archive/2007/12/12/adding-custom-information-to-alert-descriptions-and-notifications.aspx. 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).

VbscriptStringResource

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.

VbscriptLanguagePack

  • 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 – https://leibundgutski.wordpress.com/2015/09/23/scom-visual-studio-authoring-site-index/

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: https://gallery.technet.microsoft.com/SCOM-Visual-Studio-e4149214

Alert Rule XML:

BasicAlertRule

Rule

  • 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

DataSource

  • 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: https://msdn.microsoft.com/en-us/library/Ee809339.aspx. 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: https://msdn.microsoft.com/en-us/library/ee809352.aspx (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: http://blogs.technet.com/b/kevinholman/archive/2007/12/12/adding-custom-information-to-alert-descriptions-and-notifications.aspx. 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.

BasicAlertRuleStringResource

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.

BasicAlertRuleLanguagePack

  • 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: https://leibundgutski.wordpress.com/2015/09/23/scom-visual-studio-authoring-site-index/