Triggering a Runbook from a SCOM Alert/Recovery

In previous posts I talked about how you can get a list of Runbooks from your Orchestrator Server and how you can use PowerShell to trigger a Runbook by supplying only the name of a Runbook and not a GUID.

Today we’re going to see how we can get SCOM to trigger a Runbook as a recovery task to a Alert. For this example we’ll use the “Health Service HeartBeat Failure” monitor. The idea here is that when this alert is received, we’ll trigger our Runbook to try and fix this issue. There’s a fair bit involved, so let’s get started:

 

The first thing we need to understand is that we cannot do this from the SCOM Console. Let’s take a look at the monitor in question. In the SCOM Console I’ve located the monitor.

Health Service HeartBeat Failure

 

 

 

 

 

 

 

 

 

 

On the “Diagnostic and Recovery” tab if we click “Add –> Recovery for critical health state”

Diagnostic

 

 

 

 

This brings up the “Create Recovery Task Wizard”. The trouble is, we only have 2 options. Run a Command or Run a Script. We want neither of those.

Create Recovery Task Wizard

 

 

 

 

 

 

 

 

 

So to the XML we go.

Now for all of this to work, we’re going to need a couple of things here. In a previous blog post we created a script that would execute a runbook by name. We’re going to use that script inside a new Management Pack. This will become a template if you like that we can use to execute ANY runbook later on. All we’ll need to do is pass it the required parameters and it’ll go execute that Runbook.

We’re also going to need a Run As Profile that will be used to execute our script, so obviously the account referenced in this profile will need appropriate permissions within Orchestrator to be able to perform the required tasks our Runbook requires.

Finally we’ll need to create a Recovery and store it somewhere. I’ll put this in a separate management pack for the purposes of this exercise.

 

So the 2 files we’re going to use are as follows:

Runbook_Recovery_Tasks  and  HealthServiceWatcher_Management_Pack

Download them, open them up and I’ll explain as we go.

 

 

Runbook Recovery Tasks MP

The most important things to identify as you go through this management pack and possibly modify it for your own uses are the following snippets of XML.

 

Identity

You’ll want to change this to whatever name you’d like to call your MP.

XML 01 - Identity

 

 

 

 

Secure References

We need to associate this code with an account that has permissions to execute an Orchestrator Runbook. So we will need to link to the appropriate Run As Profile.

XML 02 - Secure References

 

 

 

Write Action & Overrideable Parameters (optional)

We’ll also want to associate our write action module type with the Run As Profile and optionally allow any overrideable parameters. If you want to allow these parameters to be overrideable it can help more inexperienced admins with being able to override to a different Orchestrator Server for example.

XML 03 - Write Action

 

 

Parameters

Finally at the bottom of the MP, we’ll define the input parameters that our script will be receiving (Hint: it’ll get these from the next MP).

XML 04 - Parameters

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

HealthServiceWatcher Management Pack

The most important things to identify as you go through this management pack and possibly modify it for your own uses are the following snippets of XML.

 

Identity

You’ll want to change this to whatever name you’d like to call your MP.

XML 05 - Identity

 

 

 

References

You’ll need to provide a reference to the Runbook Recovery Tasks MP which of course, will need to be sealed.

XML 06 - Reference to Runbook

 

 

 

 

Recoveries

In the recoveries section we’ll need to define a few things. The target, the monitor, the RunAs details and the input parameters to the script (the Runbook Name, WebServer and InParameter)

 

XML 07 - Recoveries

 

 

 

 

 

 

 

 

So first we’ll need to define the target for our recovery. In this case it will be the Health Service Watcher. When we look at the properties of the monitor itself in the console we’ll see the monitor target is the Health Service Watcher.

Monitor Heartbeat Failure

 

 

 

 

 

 

 

 

 

When you want to find out the internal name of a monitor, use PowerShell like this:

get-scommonitor | ? {$_.DisplayName -eq “Health Service Heartbeat Failure”}  | select Name

Name
—-
Microsoft.SystemCenter.HealthService.Heartbeat

 

We’ll need to point to the right MP where the monitor we’re targeting lives…locate the alias above!

XML 08 - Alias

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Finally we’ll need to associate this Recovery with a Run As Profile that has permissions on the Orchestrator Server and define our input parameters.

<WriteAction ID=”RecoveryAction” RunAs=”Runbook_Recovery_Tasks!Runbook_Executor_Profile” TypeID=”Runbook_Recovery_Tasks!Runbook_Recovery_Task_Module”>
<RunbookName>2.5.1.0.1 SCOM Agent Heartbeat Failure</RunbookName>
<WebServer>ORCHESTRATORSERVERNAME</WebServer>
<InParameter>Server Name = $Target/Property[Type=”SC!Microsoft.SystemCenter.HealthServiceWatcher”]/HealthServiceName$</InParameter>

 

Now once you’ve created your changes, simply import the MP’s as you would normally. Once the config has been loaded and you reopen your monitor and the “Diagnostic and Recovery” tab, you should see your recovery task listed.

Configure Recovery Tasks

 

 

 

 

 

 

The next time this monitor produces a critical alert, it’ll trigger the Runbook and pass over the 3 parameters.

So there you have it…executing a Runbook from a SCOM Alert…not entirely difficult, but now that we have our Runbook MP we can create as many other MP’s as we like that simply use it to execute the Runbook of your choice.

 

 

 
Comments

No comments yet.

Leave a Reply