It’s not a secret that I find SCOM’s PowerShell support WAY to complicated. For PowerShell scripts to work, you have to dive deep into the Authoring Console’s dark corners, whereas our vbscripting friends can pretty much just paste in their scripts and be done with. I’m hoping that’s something SCOM2012 will address, but as of now, I don’t have any details around this.

So, why use PowerShell instead of vbscript if it’s so darn difficult? Well, with PowerShell you can do pretty much anything. And it’s easy. I also find it way easier to determine the output if a certain part of the code since PowerShell supports what I call “copy/paste execution” (I guess this is really called “interactivity”). So, any file or function or whatever you can think of that you can access using PowerShell can be monitored. And whatever can be output in a numeric format can be “graphed” in SCOM as performance data.

Another powerful(!) aspect of this is that it’s possible to put advanced monitoring logic into PowerShell instead of trying to recreate it in SCOM, which often takes some time to get right. Workflows like “If file A exists but event B hasn’t been writing to the event log within the last 2 hours, report an error. But only if it’s a Wednesday” are fairly easy to create in PowerShell, whereas creating the same kinds of correlations in SCOM can prove difficult. This is why the Exchange team created the correlation engine – to perform correlation analysis outside of SCOM. Sure, you may possibly lose something by building the monitoring logic in PowerShell instead – chances are you won’t present a detailed Application roll-up to the SCOM operator, it will be more like “The application is green” or “The app has failed”. However, by using variables in the alerts and state changes, you will still be able to present some very detailed info to the SCOM operator about what part of the application failed.

A real-life scenario would probably do a bit of both – a simplified health overview in SCOM, where the important parts of the application or service are presented as unit monitors and rolled up, and then PowerShell scripts would make sure each application component is monitored properly. This would get you the best of both worlds – an informative health model for your operators to gain insight to the health of the application, and PowerShell-based scripts that correlate all the required bits and pieces into each Unit monitor.

As I said in the beginning: PowerShell is difficult in SCOM. Too difficult. Not because of PowerShell, but because of the modules and data sources you need to build around SCOM for everything to work. However, for a complex application I’m betting that it’s still quicker to do it this way than to try and recreate every little bit of the application in a SCOM health model.

Now, with that in mind I set out to find some info on how to use PowerShell in SCOM. As always, I try and create a “goal” for myself when learning new stuff. Otherwise I just end up drawing circles on a napkin. So, I decided that I want to use SCOM for weather forecasting. It might not be very IT-oriented, but that’s the point. As long as I can output data using PowerShell, it doesn’t matter. And as a Snowboarding/mountain addict, it may very well be a monitoring solution I can actually use, for instance by alerting on monster dumps of powder.

I’ll describe this solution over a few blog posts here, but I ‘d like to point out my general goals first:

-I’m using yr.no, the excellent forecasting service from the Norwegian Meteorological Institute. yr.no gives access to free, xml-based weather forecasting data for each geographic location in their database, covering Norway and the rest of planet earth.

-I wanted to make it easy to add and remove locations to report weather on, and discovery of these should be automatic

- I decided to try and measure the following types of weather data: Temperature, precipitation, windspeed and barometric pressure.

-As much as possible should be overrideable, so that I could use different alert levels for each location

-All logic should happen inside PowerShell

-I also wanted to gather performance data from the forecasting, so that I would be able to graph it and design SCOM reporting around the forecasts later on.

So, I’ll be publishing info on this series in the coming weeks, beginning with the very start of designing a class model and discoveries. I don’t consider myself an expert in MP Authoring, but I figured it would be a good exercise to write about the process here anyway. Stay tuned!