Working with runbooks in Orchestrator

Working with runbooks

With the new kind of science, which you get from Orchestrator, people are often amazed when they see this engine in action for the first time.

It’s a standard reply to all questions related to Orchestrator, and that is ‘yes’. Your imagination is the limit.

In this blog post, I will show to simple runbooks that does something you might find boring and repetitive if you are working as a sysadmin today.

The first runbook will create a new user in my Active Directory domain, and enable the account.

The second will create a new virtual machine in my cloud.

Yes, as I said. Two very simple runbooks. Although you can create workflows that integrates all from hardware, software – and even human resources, it’s often best to start with small chunks to remove the typical tasks that you’re not paid for anyhow. You should be focusing on much more important tasks than these two, but that would be the next phase.

Background:

System Center 2012 has a component called Orchestrator. This is the glue in the System Center stack, orchestrating the most simple – and also the most complex tasks in your environment. The workflows that you create could be a combination of activities and scripts, running on your terms.

Orchestrator has a bunch of existing activities when you’re opening the runbook designer for the first time.

If you take a closer look at the picture, you will also find well-known Microsoft products and components as well as third parties. System Center 2012 has activities to each and every component, so that you can create extended functionality in your infrastructure, as well as automated tasks initiated by your users and customers, in conjunction with Service Manager’s self-service portal.

If you look closely, you can also see that I have imported an Integration Pack that integrates with VMware. But that’s another blog posts, and most likely it’s written by someone else.

Creating runbooks

Create a new Active Directory user

There are several ways to create runbooks. Some runbooks could be solely dedicated to system tasks, that runs either on a schedule, or is initiated by some system events and so on.

But if you want to create a runbook that should be presented to their users through some self-service mechanism, you would normally follow these steps:

1.       Initialize data

This activity will let you define parameters/inputs with different data types. For example, a user can specify user name, display name and other related information for a user object in Active Directory that will flow over the data bus to the next activity, which actually creates a new user based on the input in initialize data.

2.       Leveraging the activities from Active Directory Integration pack, will let you mix and match the most common tasks you would normally do manually. In this example, we will use the activity called Create User. The activity is connected to a domain controller in your environment. This is something you configure in the runbook designer itself, and also on each activity. The activities have several options related to them, and you can also add extras if you’d like. So the questions is: How can we get the data from the first activity and map them into the correct options in the next one?

 

In each option, you have the possibility to ‘subscribe’ on published data. Right click and click subscribe. This will let you map and address the data.  

3.       Enable the user is the last activity in this runbook. So once the user is created based on the input in the first activity, the account will be enabled.

Now, if you look at this runbook, you might think it’s simple, easy and not much of a hazzle to get things up and running.

However, I would like to stress that you should design your runbooks properly with some logging, alternative routes in case if an activity is failing and so on.

So let’s take a look at my second runbook.

Create a new virtual machine

We will start with the same task, initialize data. We want to combine this with a Service Offering in Service Manager, so that the users should be able to access this by themselves, with no need to access the actual management tools to perform this. (This is the beuty of self-service).

1.       Initialize data

I want my users to be able to create and deploy their virtual machines by themselves, without having the IT organization to interact each time. In addition, this must be as simple as possible, where the users have no idea of the underlying resources, or where it’s actually placed.

The only thing they should determine, is the name of the virtual machine – so that they can recognize it afterwards. 

2.       Create a VM from Template is the activity I will use. I have already create the sysprep’d VM, stored it in my library, and associated some profiles to make this magic happen.

3.       Start the Virtual Machine is the last activity, so they will be able to connect and access their resources once it’s comlpeted.

Again, a very simple runbook. But if you take a look at the data buses in this workflow, you can see I have differentiated them by using different colors. The blue ones are representing the data buses that went ok, and the red ones are related to errors.

To summarize, in case of an error during the process, the runbook will head over to the activity called ‘Send e-mail’ to notify some admins about what happen.

Hopefully, you got some ideas on how to get started with Orchestrator by now.

Use your imagination and try to start with the most boring tasks first thing first.

Next time, we’ll see how we can take this a step further with Service Manager.