0

0

This is a step-by-step guide in multiple parts:

Part 1 will cover the Probe Actions Module Types: Part 1 is available on SCC or on code4ward 
Part 2 will be about creating a Data Source: Part 2 is available on SCC or on code4ward
Part 3 will cover creating a Monitor Type
Part 4 will cover the Unit Monitor itself

As always be careful with the samples provided here. Always use a test environment first to try those examples!

Will only work with OpsMgr 2007 R2 !

Part 3: Monitor Type

What’s a Monitor Type?

A monitor type actually defines the workflows for a monitor. So, before you can create a monitor you need to hook up different modules and specify how these play together and what the monitor should do. The first two parts showed how to create these modules and data sources and now all those modules are coming together…

Creating the Monitor Type

	Let’s navigate to the Monitor Types section in the Type Library space. Right-click on the Module Types panel and select New –> Composite Monitor Type. Type in an ID like: code4ward.Sample.PowerShellMonitor.MonitorType.CheckFileContent Also provide a Name like: Check File Content Monitor Type
	Click on the States tab and provide some meaningful IDs for the two states our monitor can have. In our case: ID of state 1 will be Healthy and ID of state 2 will be Unhealthy A three state monitor is not much different than a two state monitor. If you go through this guide you should also be able to create a three state monitor.
	The Member Modules tab is a bit different in this case. What here happens, is basically just the definition of modules and their configuration. There’s no order of execution of these modules. So here we define all our modules we need for our workflow and we start with our Data Source we created in Part 2. Click on the Add… button and look for the Data Source code4ward.Sample.PowerShellMonitor.DataSource.CheckFileContent As ID we specify DS (again, as mentioned in the previous parts, this ID must only be unique for the modules we need here, it doesn’t need to be unique through the whole MP!)
	After you hit OK, the configuration window of our module will show up. All the parameters for our data source will be set to $Config/…$ (see screenshot). You can use the fly-out button and select the Promote menu item to automatically fill in the $Config/…$ values. Just to repeat this one, here we define that our consumer (in this particular case the unit monitor) will provide these values. Every value you will set here “hardcoded” will not be configurable in the unit monitor. Also, remember, that if you have defined optional (non-required) parameters in the data source, you may need to add them manually by clicking on Edit… and use a XML editor (such as Notepad.exe or Visual Studio) to put in your parameter. A side note: when you use Visual Studio, an XML schema will be generated and used automatically which speeds up XML editing! In our case, no optional parameters are defined or needed, so nothing special to do here.
	Next we need two modules to evaluate our health state. Remember, our script returns a property bag, so we need to look for a value in our property bag (in our case “Status”) to determine if the health state is “Healthy” or “Unhealthy” (as we defined those IDs for our health states). So click on Add… again and look for the System.ExpressionFilter module and give that one the ID HealthyExpression. When the Configuration window appears, do not bother to insert data into the generic XML mask, click on Configure… to open up the expression builder UI.
	There we specify our expression for the Healthy state: Property[@Name=’Status’] Equals OK Click on OK and let’s do the same for the Unhealthy expression
	Same procedure as 2 steps above. We just specify another ID: UnhealthyExpression
	Type in the following in the expression builder: Property[@Name=’Status’] Equals ERROR
	At this point we would have already enough to create a two state monitor. Our data source which basically executes our script probe on a schedule and two expressions, one for each state. We will add two more modules. We need them to configure “On Demand” detection (= Recalculate Health button in Health Explorer).
	To enable on demand detection, we need our script probe we created in Part 1 of this guide and a PassThrough module (which is simple and doesn’t need any configuration). Click on Add… again and look for our Probe Action from Part 1 (NOT the one  we created for our Tasks!) The ID will be something like “Script”.
	In the Configuration window we will again Promote the parameters with the fly-out button, except the ExecutedAsTask parameter can be set to false, because the situation where we use this module will never see that parameter set to true. One question will arise here: We already configured the parameters $Config/File$, $Config/ErrorText$ and $Config/Debug$, what will happen now? The answer is fairly simple: In this case both modules will use the same parameter. When we configure the unit monitor we provide the parameter for $Config/File$ once and will be used in both modules. Our On-Demand detection will now execute our Probe Action module and use the same parameter as the Data Source we defined in this workflow. So when we set the Debug parameter to true on the monitor level, we will get debug information every time the monitor is executed and every time we do a Recalculate Health. Let’s say we always want to avoid debug information when we click on Recalculate Health, we just need to “hardwire” this parameter to false in this Configuration window and it will always be false in this workflow.
	The last module we need, is a PassThrough module. This module doesn’t need to be configured at all and is just needed to kick-off the workflow in the On Demand module. Do not ask me what it does exactly, I just know it is needed. Now let the fun part begin and change to the Regular tab to setup the workflow.
	In this tab we define for each health state (in our case two states) the workflow. So select the Healthy state in the list and check all modules we need in this workflow to evaluate a healthy state: We need our Data Source, we called it DS and our HealthyExpression. When those two modules are enabled, we need to define the execution order of these modules using the drop down lists in the Next Module column. The start of our workflow is the Data Source (DS), so here the Next Module must be set to HealthyExpression. The HealthyExpression is the last module in this workflow, so the Next Module must be set to Monitor State Output.
	Let’s move on to the Unhealthy state. Check all modules we need in this workflow to evaluate a unhealthy state: We need our Data Source again and this time the UnhealthyExpression Again, when those two modules are checked and enabled, setup the execution order: The start of our workflow is again the Data Source (DS). The Next Module must be set to UnhealthyExpression. The UnhealthyExpression is the last module in this workflow, so the Next Module must be set to Monitor State Output. That’s it for our two state monitor. Now we will setup the On Demand detection.
	First we need to check the Use On Demand Detection check box. On top of this dialog you have again both available health states. We need to setup a workflow for each health state. Select the first state (Healthy) in the list if not already selected and enable the modules needed for this workflow. In this case we need the PassThrough module, the Script (our Probe Action) and again the HealthyExpression. For the On Demand detection the first module is always the PassThrough module, so we select the Script module as Next Module for the PassThrough module. The Script module will return our property bag which needs to be passed on to the HealthyExpression module. The HealthyExpression module is our last in this workflow, so we set Monitor State Output as Next Module.
	Select the Unhealthy state in the list and let’s do the same workflow but in the end we will use the UnhealthyExpression module instead of the HealthyExpression. After that we finished all our workflows. Each workflow (healthy and unhealthy) will always be executed independently each time the monitor will run. So if you use other criteria in your expression (some performance value instead of a status text, or some and/or logic), be sure that each expression will uniquely identify each health state.
	As in our previous modules we need to be sure that the configuration schema is correct. The authoring console doesn’t always pre-set the right data type for each configuration value. So double check that Interval is an Integer and Debug is a Boolean.
	Now to the Overridable Parameters tab. Use the Add… button on the bottom to allow overrides on individual parameters. You may notice that I do not want to provide a way to override the File to monitor. This of course is up to you what you allow to be overridden and what not. I think it’s always a good idea to allow an override on Debug and Interval, this way you can look into issues on a specific server or change some configuration for a group of computers or so. As mentioned in the previous parts, you can mark this Monitor Type as Public, so that other MPs can reference your MP and use your Monitor Type (if sealed, of course). Click on OK and you are done!

That’s it for part 3. The next step will be creating the unit monitor and a task.

cheers,
Stefan Koell
http://www.code4ward.net