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:
- Part 1: Install SCCM agent
- Part 2: Generate Unique VM Name
- Part 3: Orchestrating Software Updates and Application Deployment
Another prerequisite for this runbook is having a VM template (with Windows 7 in my case) ready for deployment.
Scenario
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).
Image may be NSFW.
Clik here to view.
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.
Image may be NSFW.
Clik here to view.
Also enable “looping with”, and configure the exit conditions discussed here: Generate Unique VM Name (Part 2).
Image may be NSFW.
Clik here to view.
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.
Image may be NSFW.
Clik here to view.
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.
Image may be NSFW.
Clik here to view.
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.
Image may be NSFW.
Clik here to view.
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.
Image may be NSFW.
Clik here to view.
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.
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
