This is part 4 in my blog series about using PowerShell scripts in SCOM. The other parts can be found here:

• Part 1: Intro
• Part 2: Service Model Design
• Part 3: Discoveries with PowerShell

Please note: This is not meant to be a “I will teach you something” blog series, it’s more like “ramblings as I go along”. So, if you learn something from it, great. If not, please don’t shoot me.

Well, to business. In Part 3 I looked at how PowerShell could be used for discovering SCOM objects (I’m calling them that, although the proper term is “Class instances”), and found that it actually wasn’t hard at all. If there are lots and lots of properties to be discovered for a class, PowerShell is absolutely the way to go – especially in cases where the properties can’t simply be read from registry.

So, time has come to get some actual data from PowerShell, and display it as SCOM Performance data. I will not be getting into PowerShell-based monitors in this part, I’m only going to concentrate on getting Performance Data from my script into SCOM for now.

The first thing you need to do if you’re preparing to author your first PowerShell-based SCOM rule and/or monitor is to watch this video:

http://technet.microsoft.com/en-us/systemcenter/ff723797.aspx

http://technet.microsoft.com/en-us/systemcenter/Video/ff770155

It’s the best primer on the subject available, and it’s well worth the hour it takes. The rest of this blog entry is more or less a reiteration of the subject in the video, although the script in my example might be a bit more complex than the one used in the video.

What I needed to get my head around when creating my management pack, was how everything fit together – probe actions, Data sources and what not. It is actually quite simple:

Probe Actions: Contain the actual PowerShell script to be run, along with info about override-able parameters and so on.

Data Sources: The middle layer between rules and Probe actions. A data source might contain a probe action and a scheduler, which makes sure the probe action is executed at certain intervals, every hour for instance.

Rules: Rules call the Data Sources mentioned above. Rules also might contain a “mapper”, which translates the output from the data source to performance data that SCOM understands. Rules also have actions for storing data in the OpsMgr database as well as the Data Warehouse.

 

Because of the Authoring Console’s tight validation of each change done when developing a management pack, you have no choice but to start with the probe action, then do the data source and then finally the rule.

 

Before I go any further I’d like to explain quickly how the xml data from yr.no works. This is the service I’m pulling data from in my management pack, and its quite easy.

As I described earlier, every (Norwegian) location has a URL which returns a simple xml string with that location’s weather forecast. This xml includes some metadata, along with the normal weather-type data: wind forecast, precipitation, temperature and so on.

Getting this data into PowerShell is quite simple – create a new WebClient object, and use it to download the data into a xml variable:

$YrUrl = “http://www.yr.no/place/Norway/Oslo/Oslo/Oslo/forecast.xml”
$clnt = new-object System.Net.WebClient
$XmlWeatherData = $clnt.downloadString($YrUrl)
$XmlWeatherData

Getting to “know” an xml structure in PowerShell is quite easy. I just “browse around” using auto-complete in the console until I get what I need. After some digging, I found that:

$XmlWeatherData.weatherdata.forecast.tabular.time

will return an array of point-in-time forecasts, like this one:

(Bear in mind, I’m no xml expert, so there’s probably some XPath-ing or other black art that could have made what I’m doing easier)

So, I needed to take these array entries and extract the data I needed. Once I had the objects I wanted, I could query it like “I want the wind forecast for the next 48 hours from right now”. The script is included at the end of this post, I won’t bore you with every line of it right here.

As far as making the script “SCOM-friendly” there’s a few things to add:

First, the parameters. My script takes these parameters:

Param ($YrUrl,$NumberOfHours,$ForeCastType, $LocationName)

the URL and the LocationName both come from the SCOM object. NumberOfHours is how many hours into the future I’d like the script to look at forecasts. The Rules I’ve created right now look at average for the next 48 hours, mostly. ForeCastType is the type of forecast I want returned (wind, precipitation, temperature).

This is what makes the “probe action—>Data type—>Rule” architecture so great – the same script can be used for several rules, returning different aspects of the same data. I’ll show this in a minute.

Also, a PowerShell script in SCOM needs to reference the SCOM com-objects:

$api = new-Object -ComObject ‘Mom.ScriptAPI’
$bag = $api.CreatePropertyBag()

These are installed along with the SCOM agent. Along with passing data to SCOM, you can also use this object to do logging, which will eventually show up in the “Operations Manager” log on the server running the script. These are collected by the SCOM agent and sent to the RMS as well, if memory serves me right. The object is documented here:

http://msdn.microsoft.com/en-us/library/bb437523.aspx

To send data from the script to SCOM, use so-called propertybags:

$bag.Addvalue(‘LocationName’, $LocationName)
$bag.Addvalue(‘TemperatureAverage’, $TempAverage)

and then return the data to scom by simply issuing

$bag

at the end of your script.

My probe action looks like this in the Authoring console:

Again, watch the TechNet video I mentioned above for details. Simply put: Create a probe action. Add a Member Module with type “Microsoft.Windows.PowerShellPropertyBagTriggerOnlyProbe”, which is where your script will sit, along with the parameters you pass to the script. In the “Configuration Schema” tab, add the parameters along with type for each one:

The Data source comes next. It’s pretty much just a job definition saying how often the Script/probe action should run:

The “Configuration Schema” is also pretty much the same, since we’re passing parameters from the rule “through” the data source down to the probe action. There are two extra parameters that configure the “Scheduler”, Intervalseconds and synctime:

And then finally, the Rule or Rules you want to call the script with. I have 3 right now, each calling the same script but with a different “forecasttype” so that I get precipitation, wind and temperature forecasting from the same script:

I’ll look at one of them more closely:

The “Data Sources” is the exiting part, the rest is just data mapping and saving data to databases.If I click “Edit” next to my data source, I get this:

The parameters I specified in the Data Source are available here, and this is where we link the monitored object’s attributes to the parameters we send down to the script through the data source. You can probably see that I send the “XMLAddress” from the object as the URL where the script is to download its xml file, that I want forecasting for the next 48 hours, and that in this case I’m interested in the Temperature forecast.

Note also that the mapper (System.Performance.DataGenericMapper) is where the various instances and counters are named:

After some tweaking and head-scratching, this gave the following instances in the SCOM Performance View:

Temperatures are measured in Celcius, which don’t stop at zero. I have no idea what SCOM will do when it starts getting negative values from the script, but I’ll just have to wait and see.

The rules are configured to run every 60 minutes, but the actual forecast data isn’t updated that often, which is why you don’t see nice rolly graphs in the picture above.

Looking at last months data, I’s not hard to tell we are getting closer to winter up here:

 

So, that pretty much covers it for this time. Next on my list is taking this data and construct monitors from it, so that I can get alerted if the forecasts says it’s going to rain heavily or whatever. I’ll think of something.

Below is the management pack as it sits on my lab server right now, along with the PowerShell script that produces the data (which is of course also included inside the management pack).

Management pack:

 

PowerShell Script: