Speaker: Brian Wren, Principle Knowledge Engineer, Microsoft.
This is a packed room, and it’s one of the bigger rooms. Obviously a very popular topic. A quick poll by the speaker: Very few people in here with Opalis/Orchestrator knowledge. Most of the audience are OpsMgr experienced.
Quick run through of the two products (skipping OpsMgr in my notes)
Orchestrator has Orchestrator Database and Runbook Server. Runbook runs actions across applications. Workflows process on runbook server. Requires access to remote machines – very difficult for OpsMgr MP to do. Relatively few complex workflows. So OpsMgr monitors and Orchestrator does stuff.
We can integrate the two products.
Operations Manager Integration Pack
A runbook can use OpsMgr. Standard activities:
- Get Alert
- Get Monitor
- Create Alert
- Update Alert
- Monitor Alert
- Monitor State
- Start Maintenance Mode
- Stop Maintenance Mode
The monitor action in a runbook causes the executing runbook to sit there waiting for something to happen, e.g. if an alert of certain criteria appears, then continue execution of the runbook.
There is also a Start SCOM Task action. These are the actions you see in the Tasks pane in the OpsMgr console.
Orchestrator Management Pack
Allows OpsMgr to reach into Orchestrator.
Standard:
- General health monitoring
- Create Alert activity for runbook failures
Extend
- Start a runbook
- Get information about a runbook
This is made possible by a MP by Infront Consulting.
Extension and Automation Options
http://orchestrator.codeplex.com/releases/view/82959 has a library of cmdlets for Orchestrator because it doesn’t have any apparently.
Demo
Using his own MP instead of the Infront one. He shows two runbooks that are being monitored by OpsMgr. The Infront MP checks the last execution of a runbook for its health. You can launch a runbook via an OpsMgr task.
Scenarios
- Working with alerts
- Recoveries
- Tasks and Runbooks
Monitor Alert
A runbook monitors OpsMgr for an alert(s). When the alert comes in, Orchestrator does something. For example, a critical alert comes in and Runbook can do some complex notification tasks, e.g. if nobody responds in 20 minutes, then do something.
MSFT no longer investing in connectors for OpsMgr. Instead they are investing in Integration Packs for Orchestrator to implement this functionality instead – allows more complex tasks.
Monitor State
Expected you won’t use it much. Monitors the state of objects in OpsMgr. One scenario: an error occurs to a DB in a distributed application. With that rolled up state change, we can kick off a runbook in Orchestrator.
Demo
He forces an error to happen. Now we look at the runbook. We’re looking for new alerts that come from the MP that will soon detect the error and create an alert. Now he detects who owns the faulting app. This could be a query of the Service Manager CMDB. It’s a SQL query. He now automatically sets the owner of the alert in OpsMgr using that data and the ID of the alert. He now checks what time of day it is, and then sends out the appropriate notification. This is actually another runbook.
He pulls in data from the 1st runbook. It send an email. If that fails, it will create an alert in OpsMgr to say that there’s a problem with the notification system.
In theory, you could then track the alert to see if anyone does work on it in a predefined time. If not, you could escalate the alert.
Caution
Be careful of automated actions that do recoveries. You don’t want to blindly reboot some machine every time it does X, e.g. bouncing machine, someone disables an app without maintenance mode, etc. What if the thing autoresolves during the runbook execution? The runbook will continue to run.
Automated recovery option 1
Runbook monitors for alert in OpsMgr. Beware of having lots of concurrently running monitor runbooks because it won’t scale out that way.
Create the recovery in the OpsMgr MP to run the runbook in Orchestrator as required. It’ll use the Orchestrator web service to start the runbook over the network. It’s more difficult to set up than the monitor alert runbook.
Wow, this room is 95% full. Very popular topic.
Demo
There’s a distributed app. Any time there’s an error, he wants to send a notification to his helpdesk. He loses me here with XML MP authoring – a pity. Interesting, he appears to check the health of the object in OpsMgr from the runbook before bouncing the failed service. He then checks the state of the object after a 5 minute wait. If not healthy … there’s more.
Running Tasks From a Runbook
Runbooks run across the network. OpsMgr tasks run on the local agent. Runbook couldn’t do IPConfig but a task could. You can run an OpsMgr task from a runbook, wait for execution, and suck in the resulting data into the runbook.
Demo
Back to before. Now the runbook is going to reset a cache in the app to fix the issue. It’ll be done using an OpsMgr task. The task is actually a POSH script.