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.
