Of all the bits of System Center to come out next year it is Orchestrator I am most interested in, as it is one of the enablers to create a private cloud. It’s a new bit of the System Center suite and is the glue that not only integrates the rest of System Center, but also most of the popular non-Microsoft tools in the systems management space e.g. HP, BMC, CA, Symantec and Vmware. It has been developed from the acquisition of Opalis, and if you were familiar with that, Orchestrator is very similar except it is now in .Net and has a much simpler installation process.
Very simply, if you have to do the same task more than ten times then it’s probably something that should be automated. For the low level techie this might mean scripting in PowerShell, and although this might work and you might be able to reach all of the moving parts you need to, it is difficult to change, maintain and debug. On the other hand, Orchestrator allows you to map and design the process visually with very little coding:
- Each step (object) of the process (a runbook in Orchestrator speak) might be working with a different part of your infrastructure, such as the file system, active directory, e-mail etc. This is where the rich integration in Orchestrator shows up as it understands what other tools can do and what data they can supply and respond to. This knowledge about what systems management tools can do is encapsulated into integration packs which are rather like management pack in System Center Operations Manager (SCOM).
- Each step can get, set and pass data to another step like a user name, a machine name or an error condition. This published data, as it is called, passes along a data bus and is eventually stored in a SQL Server database.
- You have flow control to wait for event, loop, and conditionally branch.
- You then build and deploy this task from your designer to the Orchestrator server.
- Monitors can be setup to initiate workflow by watching for events in your system. Note that in System Center Service Manager 2012 runbooks can be directly invoked as part of an incident.
Creating the right runbooks will transform your data centre into more of a private cloud, for example:
- A runbook can respond to a helpdesk incident to provision a new service.
- Doing that endlessly, however, will mean you will end up running out of physical servers so other runbooks can be created to end of life servers.
- Runbooks can respond to events, indicating services are idle or are under pressure and reallocate resources to better balance operational needs.
If all that sounds interesting then the beta of Orchestrator is now available to download. If you do plan to evaluate it, here are few things you need to know:
- Orchestrator has a server component and a web console to monitor it and then there is a designer to create your runbooks. The easiest way to deploy Orchestrator is put everything including the designer on the one server and remote desktop into it. The only exception might be to deploy its data store to an existing database server.
- The integration packs I mentioned for connecting to System Center and other systems management tools aren’t included in the beta download (they will be for release), so you can get them by downloading Opalis 6.3 180 day trial, as these are compatible with Orchestrator.
- If you have been using Opalis before you can export your policies and then import into Orchestrator as runbooks. There may be some legacy objects that won’t work or need to be adapted which will block a runbook being deployed, and you’ll have to fix that.
For further resources visit the System Center TechCentre on TechNet.