Using the power of Orchestrator to move a computer to a different OU via ConfigMgr 2012

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.


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.



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

TasSeqEdiMovComNow 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.


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:ActDetMovCom

12 thoughts on “Using the power of Orchestrator to move a computer to a different OU via ConfigMgr 2012”

  1. Thanks for your tutorials always very helpfull!! Unfortunetly, I’m stuck at a problem with executing a runbook from a task sequence. The ZtiExecuteRunbook.wsf doesn’t seem to get the Network Access Account for Login to Orchestrator. ZtiExecuteRunbook.log says

    401 – Unauthorized: Access denied due to invalid credentials

    In the event log of Orchestrator I just get an anymous logon. NAA is definetely a member of the scorch users group. I checked all the points severeal times. Do you have any suggestions?

    Thanks a lot

  2. Hi Peter, no i can’t find the account in the log files. the only account i see is nt authority\system in execmgr.log to call the task sequence.

  3. Hi,

    I am confused. We are getting the 401 Access Denied Http Status with Error 10801. We gave the Network Access Account permission to run Runbooks, but:

    I found documentation on MSDN which says that the Network Access Account is not used to execute Task Sequences. And we can confirm that the Execute Runbook Task Sequence is accessing the Orchestrator Web Service “Orchestrator.svc” with the local system account.

    This however leaves me stumped and do not know which user to give permissions to for running Runbooks in Orchestrator?

    The article on Technet:

    The Network Access Account is never used as the security context to run programs, install software updates, or run task sequences; only for accessing resources on the network.

    We are using ConfigMngr 2012 R2 SP1 with MDT 2012 SP1

    We are now going to try MDT 2013 to see if it works differently.

    Kind Regards


    • Hi Bastien,

      That article is about the default usage of those accounts by ConfigMgr, not by MDT. At least back in the days that I wrote the article, the Network Access Account would be used by that task sequence step. Haven’t tested it recently though, but I can’t imagine that it was changed.


  4. Hi
    I know this is an old post, however I am facing the same problem – I cannot get the Execute Runbook task step to run, despite poring through the guides and configuring SCORCH according to those guides.
    The NAA is a member of the Orchestrator User and System groups. I can see the NAA in the permissions for each runbook (Read only).
    But still I get the 401 error, Invalid Credentials.
    I posted a question on the TechNet forums, but never got a reply.
    If anyone reading this has an idea of where I am going wrong, please respond.

    • Hi John,
      You can verify the ZTIExecuteRunbook.log file to see which account is being used. I’ve read about different behavior depending on the version of MDT. System account versus network access account.


Leave a Reply to Peter van der Woude Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.