Child runbooks in Orchestrator: Automating an uniquely named,fully patched VM with basic apps installed.

I always see people comparing PowerShell with Orchestrator, or thinking of Orchestrator as a GUI for PowerShell. From my point of view the real power of Orchestrator lies in its capabilities to integrate at different levels to multiple systems and bring them together in a simple “runbook”.

Finally in this post, we can bring together all the previous runbooks and get to experiment with child runbooks. For this all the previous runbooks have to be ready:

Another prerequisite for this runbook is having a VM template (with Windows 7 in my case) ready for deployment.


The main idea, when creating these little runbooks, was to have a VM that:

  • Was auto generated
  • Has an unique name that complies with a specific standard
  • Is fully patched
  • Has a minimum of applications installed

Following this scenario, we easily get to connect to Active Directory, Exchange, SCCM and SCVMM. And we could go even further, by integrating this runbook with SCSM, for change management (future post).

20131113 - 0 Big Picture

Get Unique VM Name

So let’s start by dragging the “Invoke Runbook” activity, found under the “Runbook Control”. Browse for the UniqueVMName runbook and check the “wait for completion” checkbox.

20131113 - 1 Get Unique VM Name

Also enable “looping with”, and configure  the exit conditions discussed here: Generate Unique VM Name (Part 2).

20131113 - 2 Get Unique VM Name - Loop

Create VM from Template

One of the two new elements in this runbook is the “Create VM from Template” activity, which can be found in the SCVMM Integration Pack.

20131113 - 3 Create VM

Full configuration:

Destination Type Host
Destination srv.lab.local
Path E:\VMFolder
VM Name {UniqueVMName from “Get Unique VM”}
Source Template Name Win7Template
Computer Name: {UniqueVMName from “Get Unique VM”}
Domain Name lab.local
Domain User Name Valentin
Domain Password **********
Product Key ******************************
Admin User Name admin
Admin Password ***********

* For testing purposes, I used the GVLK keys (KMS Client Setup Keys) that are publicly available on technet – since the runbook will fail if you do not provide a product key.

Install SCCM Agent

By using “invoke runbook” again, we connect to the Install SCCM agent runbook (Part 1). The ComputerName parameter gets the value from the “Create VM from Template” activity.

20131113 - 4 Install SCCM Agent

Install updates

The next runbook we will invoke is “Install Updates”. Again, we have the parameter ComputerName, which expects a value. This time, the value is taken from the “Install SCCM agent” runbook, which publishes this information through the “Return Data” activity.

20131113 - 5 Install Updates

Email VMM Admin

I added this last activity, just to make the point on how Orchestrator can easily operate with data from across multiple systems.

20131113 - 6 Email VMM Admin

There is still a lot to cover on child runbook. Mainly why use them? One example why you might actually need to use them is that you require a loop, like I did for the “Get Unique VM Name”.  Another reason might be that you require speed, and you want to execute part of your activities in parallel.

We still don’t have something that really triggers all this runbooks, I will come back to that in a future post after we dive a little in SCSM also.
> V.


One thought on “Child runbooks in Orchestrator: Automating an uniquely named,fully patched VM with basic apps installed.

  1. Pingback: Orchestrating Software Updates and Applications Deployment | System Center Automation Blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s