Run a runbook with a specific account

By default all activities are executed with the account you have specified on the Orchestrator Runbook Service on your Runbook servers. In some scenario you need to configure a activity with a specific account, you can do that on the security tab on each activity.

But it is a lot of work to update each activity in the runbook with new security credentials information. What if you want to use the same runbook, but with different input parameters and different accounts? The solution to that could be to trigger the runbook with the Invoke Runbook activity and specify a account, instead of trigger the runbook direct. Then you can specify a account each time you trigger the runbook. In this example I have built two runbooks. Runbook A and runbook B.

Runbook A writes its credentials to a text file (command “whoamI” and writes pure output to C:\temp\Iam.txt) and triggers runbook B that does the same. The result will be a text file with two lines, both lines is SKYNET\svc-sco-sa. SKYNET\svc-sco-sa is my Orchestrator Runbook Server service account, and that is the account that executes runbooks by default in my sandbox.

If I now configure the Invoke Runbook activity, on the security credentials tab, to run with the SKYNET\andersbe account instead, we will see a difference in the result

As you can see the second runbook is now running with the SKYNET\andersbe account instead of the default account.





6 thoughts on “Run a runbook with a specific account

  1. Does anyone know if there is a runbook created to change service account passwords?

  2. If you pass in a encrypted variable, that should not visable. But when you use the password field the text is encrypted. Another solution is to encrypt it on the runbook server with powershell.

  3. Anyway to securely pass credentials to a runbook without hardcoding in the runbook or in a global variable? Unfortunately “Initialize Data” only supports string and integer types but no password.

  4. Thanks for this, very useful.
    One point worth mentioning is that the account you use must be a member of the OrchestratorSystemGroup.
    If it isn’t then one of two things happens: either the runbook doesn’t run at all (although invoke runbook still returns success), or it runs using the default service account.

    Best Regards


Leave a Reply

Your email address will not be published. Required fields are marked *

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