Orchestrator 2012

What is orchestrator and should I care?
Well first of, you should care
This product will be a life-saver for many, and it is a crucial part of Microsoft’s private cloud solution.

But what is Orchestrator anyway?
It is a part of the Microsoft System Center family and the latest release is Orchestrator 2012, for those that don’t know the history of Orchestrator.
It was previously known as Opalis, which was actually made by a company called Opalis Software which was acquired by Microsoft.
It is a Process automation tool, and lets face it.. There are many tasks out there that could be automated but you don’t have the time or the resources to create a script to do the job.  This is where Orchestrator comes it!

Microsoft describes Orchestrator as this:
Orchestrator provides a workflow management solution for the data center. Orchestrator lets you automate the creation, monitoring, and deployment of resources in your environment.

I’m going to give a short intro of how Orchestrator works, with the different roles, integration, creating “runbooks”

First of Orchestrator consists of the following roles:

Management Server:
The management server is the service that communicates between the runbook designer and the Orchestrator database.

(Basically just this service)

 

Runbook Server:
A runbook server is where an instance of a runbooks run. These servere communicate directly with the Orchestrator database.

If you open the Deployment Manager you can see the runbooks server on the left side.

 

Orchestrator database:
This database contains all the deployed runbooks, the status of these, log files and config data Orchestrator.

Runbooks:
A runbook contains a set of activities.

(A Runbook with 3 activities)

Runbook designer:
This tool is used to build, edit and manage Runbooks.

(The runbook designer)

Runbook tester:
This is a tool to test runbooks created in Runbook designer.

Orchestration Console:
This console allows you to start or stop runbooks, view real-time status via a web site. (Typically on http:\localhost:82) of the
orchestrator server.

Orchestration Web service:
This is used by the Orchestrator console to interact with Orchestrator, it is also used to integrate with SCSM
So you can for instance attach a runbook to a request offering. (More that in a later post)

Deployment manager:
Deployment Manager is a tool used to deploy integration packs, runbook servers, and Runbook Designers.

Now first of download Orchestrator and install it.
You can find Orchestrator here:
http://www.microsoft.com/en-us/server-cloud/system-center/default.aspx

Second: You should also download the integration packs for other products like OpsMgr, ConfigMgr, SCSM, VMM.
And AD. Third party vendors like VM and HP also have some integration packs available. These packs gives orchestrator extended functionality towards the product. For instance I have imported 3 Integration packs. One for AD, 1 for ConfigMgr and 1 for SCSM. When I restart  the runbook designer after I imported the packs I get extra sets of tasks available for AD, ConfigMgr and SCSM.

 
 
But of course you need to setup a connection to each individual system before you can use these tasks against the systems. So go into the options menu on Runbook Designer and you get a option pane for AD, ConfigMgr and SCSM. Go into each of these and setup a connection. 

Now lets take a quick walkthrough in Runbook creating.
We will create a pretty simple Runbook which does the following. Based on the input parameters it will create an “incident” in SCSM. Since we now have the integration with SCSM its easy-peasy. First of we need a task that takes input from a users. So go into the “Runbook Control” option on the right side and find the task “Initialize data” and drag it out to the designer.

This task allows for Orchestrator to get input from the user, first of right click on the “Initialize data” and press Properties.
On the General tab you can change the name of the activity and the description. So lets change this to “Input data” and go over to Details.
Here we add 2 parameters
1: Called Title and choose String
2: Called Input and choose String.
. .
Then click Finish
(You could also check under Run Behavior where you could add options for error reporting but
since this is a basic runbook I want to simplify it. )

Now it should look like this.

Next we add an activity from the SCSM tab, since now we have input data we have to create an incident.
Now select the CreateIncidentWithTemplate activity and drag it out to the “drawing board”

Now after that mark the “Input Data” activity then a mark will appear on the side then drag it over to the other activity. Then it should look like this

Now we have to change the other activity that it should get the input data from the first activity.
So right click on the CreateIncident activity and press properties.
(Now remember that you need to have an active connection to SCSM before you can finish this)

Go to the General tab first and alter the name of the activity to Create Incident.
Next go to the Details tab, alter the connection (click the … button and choose a scsm server)
Then on the Class choose; Incident and next choose standard template for incident.

And by default now you should get two fields down below.
Priority and Effect, but those two parameters we added in the previous activity is a string value which is intended for the title and the body of the Incident.
Therefore click, select optional fields and choose Title and Description, and click ok. Now back to the details menu right click on the white space next to the title and choose Published data.

Now you see you get the option to get the input from the previous activity. So choose Title from the input data paramter.
And do the same for Description.

Now it should look like this. (I have a norwegian setup so don’t mind the words there)
And click finish.

Now it should look like this.

So lets test it!
Click the runbook tester, and click RUN.
You will get a screen up where you need to enter the paramteres.
In my case I entered title Test1 and details Test1

Now we can see that the Incident is created in SCSM.

Well now you get the general idea of how Orchestrator works, this runbook was based on input data from the user, but we could also create a runbook that uses a monitor. For instance you can create File Monitor (That watches if a .log file is create/edited/access under the folder c:checkthis) Lets say if app1 crashes it automatically creates a log file in that folder. So you need to restart a service in order for it to work. So I created a monitor activity, and if the file is there, it first creates a entry in the event log, restarts the service and also creates the log file (So the monitor doesn’t trigger again)

This was part 1 of Orchestrator post, stay tuned for more.

Orchestrator documentation on Technet:
http://technet.microsoft.com/en-US/library/hh420344