SCOM 2012 – Maintenance Mode by Powershell, Orchestrator & SCOJobRunner

If you browse the web and you search for a solution to start maintenance mode in SCOM you will find many solutions. There are different approaches which are based on Powershell or Orchestrator but my intention was to to combine all of those and also utilize SCOJobRunner, Just for fun …

The idea looks like this…

The basic concept is to offer the user a kind of GUI where he/she can enter or select the required information and then triggering a runbook without the need of any SCOM permission.

SCOJobRunner

First lets start with the easy part .  We need the SCOJobRunner tool. You can download it from CodePlex where you also get the syntax how to use it. This tool is just one SCOJobRunner.exe file which you can use to start runbook jobs using a script or some other tool.

Powershell GUI

Below is a screenshot of the GUI I designed in Powershell. I used the free “PrimalForms Community Edition” editor to create this interface.

This tool allows you to design easily a Powershell GUI by dropping some controls onto a form. After you finished designing the GUI export it into a Powershell file. Of course after that you need to add some logic behind each field and button. In my case I ended up with something that looks like this…

Behind each control I wrote the parameters in red color which we use later in the “Initialize Data” runbook activity.

You need to enter the following fields:

FQDN Server => Server which you want to put into MM
Duration => How long should the server be in MM
Reason => Reason for the MM
Comment => If you don’t add a comment the current user login name will be put into the comment field.

Now you can choose either only put the Windows or Linux server into MM or put the Windows server into MM and restart.

Remember, each of these parameters are submitted to the runbook and can be used as published data!

If you want to try out my example you need to adjust the variables in the script…

$Webserver => Server which hosts the Orchestrator web service.
$RunbookGUID => GUID of the “1.1.0 Main” Runbook in Orchestrator
$RunbookServer => Runbook server where the Runbook will run
$Path => Path to the SCOJobRunner executable

The most important line in the code is where Powershell calls the SCOJobRunner.exe and submits the parameters which we catch from the GUI to Orchestrator. You don’t need to change anything in this line. I just wanted to point out how it works. See the line here…

Invoke-Expression -command “&`”$Path\SCOJobRunner.exe`” -ID:$RunbookGUID -Webserver:$Webserver -RunbookServer:$RunbookServer ‘-Parameters:Object=$Object;Time=$Time;Reason=$Reason;
Comment=$Comment;User=$env:Username;OS=$OS'”

Download my example (Start-RemoteMaintenaceMode.ps1) here.

Now it is time to design the runbook…

Main Runbook

There are 4 runbooks, “1.1.0 Main”, “1.1.1 SubLinux”,“1.1.2 SubWindows” and “1.1.1 SubWindowsRestart”.

The “1.1.0 Main” runbook uses the “Invoke runbook” activities to call the corresponding child runbooks and depending on the result of the child runbook it generates a critical or information alert in SCOM.  Below I documented one of the three workflows. You can easily adapt the other two workflows.

Child “Sub” Runbooks

The  “1.1.1 SubLinux” is configured get the data from the “1.1.1 SubLinux Invoke Runbook” and submits the parameters to the maintenance mode activity.

The  “1.1.2 SubWindows” is configured get the data from the “1.1.2 SubWindows Invoke runbook” and submits the parameters to the maintenance mode activity. The difference to the “1.1.1 SubLinux” runbook is the class you need to configure on the maintenance mode activity. Instead of “Microsoft.Unix.Computer” you need to set the “Microsoft.Windows.Computer” class.

The last runbook “1.1.3 SubWindowsRestart” gets also the data from its parent runbook and it is set up the same way as “1.1.2 SubWindows” runbook the only difference is that I added the “Restart System” activity to restart the system.

Configuration

At this point you have to be aware of a few things.

1. Because the Orchestrator service account executes all the runbooks this accounts needs permission in SCOM to put servers into maintenance mode and also permission to restart all the systems. In my tests I added the service account to the domain administrators group.
2. If  you receive an error “The requested operations requires Publish permissions on the Runbook” read this here .
3. If you want to set minimal permission for a user on a runbook read this here.

If you configured everything right you should be able to run the Powershell GUI and start the runbooks.

My goal is not to provide a final solution which you just can download and install. My intension is to show a possible way/solution which you can easily adapt and extend. I think it is a cool solution/idea which helps you to overcome certain difficulties and get a kick-start .