The power of Orchestrator 2012 to automate actions is getting bigger and bigger, as the community for it grows and by that the number of Integration Packs (IPs). Of course there are also IPs for ConfigMgr, from both Microsoft itself and the community (via CodePlex). Besides that there wasn’t a real integration between ConfigMgr and Orchestrator, yet, but with MDT 2012 Update 1 a really nice new cool feature was introduced. This feature is the Execute Runbook –step during a Task Sequence. It gives anyone, with or without real programming skills, more robust options during a Task Sequence, as long as an IP exist for the action anyone wants to perform. Just remember, lots of these IPs are created by the community. So deliver useful feedback on them, or even better add your own actions, or IPs.

Prerequisites

In this post I want to show this new feature by creating a runbook for, an often requested script, or step, to move a(n existing) computer to a different OU. For the rest of the post the following points are prerequisites:

• A Microsoft Deployment Toolkit 2012 Update 1 –package. This package contains the necessary scripts to execute a runbook during a task sequence.
• The Nework Access Account needs to be “Orchestrator User”. By default the Execute Runbook –step will use the credentials of the Network Access Account to connect with Orchestrator.
• Register, Deploy and Configure the Active Directory IP from Ryan Andorfer. I used this one, because it was easy to set up and, even more important, it works (even with Orchestrator 2012 SP1 BETA)!
• The account used in the Connection Credentials needs to be at least member of the Account Operators –group in the Active Directory (AD). Otherwise it can’t move an object in the AD.

Runbook

Let’s start with configuring this nice and basic runbook. This runbook will contain three steps with the following configuration:

• Add an Initialize Data –activity and double-click it. In the Details Information click Add and a new parameter named Parameter 1 will be added. Now click Parameter 1 and change the name to ComputerName click Ok and click Finish.
• Add a Get Object DistinguishedName –activity, link it with the previous activity and double-click it. In the Properties, fill in with DomainName <aDomainName> and fill in with Object Class computer. Then right-click the field next to Object Name select Subscribe > Published Data. In the Published Data –popup, select with Activity Initialize Data, select ComputerName, click Ok and then click Finish.
• Add a Move AD Object –activity, link it with the previous activity and double-click it. In the Properties right-click the field next to Source Object LDAP Path select Subscribe > Published Data. In the Published Data –popup, select with Activity Get Object DistinguishedName, select Object_LDAP_Path and click Ok Then fill in with Destination Container OU LDAP Path <aOULDAPPath> and click Finish.
  • Note: Of course the Destination Container OU LDAP Path can also be (partly) filled with a Published Data. This basic sample is just to show the possibilities.

Task Sequence

Now let’s start with the configuring the task sequence. To execute the runbook from the task sequence add the following steps and configuration:

• Add an Use Microsoft Deployment Toolkit Package –step and Browse to the Microsoft Deployment Toolkit 2012 Update 1 –package.
• Add and Execute Runbook –step, fill in with Orchestrator Server <aOrchestratorServer> and Browse with Runbook to the just created runbook. Then select Specify explicit runbook parameters, fill in with ComputerName %_SMSTSMachineName% and click Ok.
• Note: By doing this the ComputerName –parameter from the Initialize Data –activity will be set to the computer name of the system running the task sequence.

Result

The default ConfigMgr task sequences are not able to move a computer object to an OU when it already exist in the AD. Running this task sequence will now result in the computer object being moved to the OU specified in the Move AD Object –activity, even when the computer object already existed in the AD. There are multiple places to look for the results of this action. Think about the log files (smsts.log and ZTIExecuteRunbook.log), the AD and the Orchestration Console. Of this last option I’ll show the results here: