List all containers in all storage accountsBy 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.
Does anyone know if there is a runbook created to change service account passwords?
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.
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.
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
Steve
[…] A runbook is executed with the Orchestrator Runbook Service service account. In most scenarios that are not an issue. But in some scenarios you need a runbook to run with a specific account, and all other runbooks run with the default service account. This can be done with an extra Runbook Server that uses another Runbook Service service account, or per activity or it can be solved at design level in the runbook by using the Invoke Runbook activity. To configure a runbook to run with a specific account, please see this post. […]
[…] Read the full post: Run a runbook with a specific account […]