One of the great many features of System Center Orchestrator 2012 R2 is the ability to create reusable “Variables”. Now I use the term Variable loosely given what I am about to talk about is really static values that you as an administrator define. The reality is they are more a constant in scripting terms than a variable, but I digress.

One great use of the Variables is setting Service Account Usernames and Passwords, which can be encrypted in the Orchestrator database to ward off any prying eyes. The values can then be used/re-used inside a Runbook when you need to set credentials, say for example in a PowerShell script (Run .NET Activity).

In the following example, we will create 2 variables for an AD service account. One for Username and one for Password.

First we create a new Folder under Variables called RunAs Accounts. This is optional of course, but I like to keep things organized to my liking. You certainly could keep all variables in the root if you so choose.

Next we will create a new Variable within that folder for the Username of our AD service account. Simply right-click the folder and select New>Variable.

We will give the variable a good friendly name that we can recognize within our runbooks, and then for the value we add the username in the following format: DOMAIN\Username. As stated above, you can encrypt the variable value however for this demonstration I will leave the username unencrypted. I would always recommend encrypting passwords, however what you choose to encrypt or not encrypt is a decision you will need to make internally.

Once Name and Value are populated correctly click Finish.

Now create a second variable where we will store the password. Give it a friendly name and type the password in the value box.

We will now click the Encrypted Variable check box then click Finish.

Repeat these steps for any and all service accounts you want to use in Orchestrator.

OK, so now we have our variables, how do we use them in a runbook?

Anywhere you can subscribe to data, you can pull values from defined Variables. For instance, in this Run .NET Script activity, we have some powershell code where I am going to execute a Remote Powershell session.

I simply right-click between the quotes of my $username variable and select Subscribe>Variable.

Navigate to the RunAs Accounts folder

Select the Account variable I need for the username and click OK.

The Orchestrator variable now shows as the value of my PowerShell script variable.

Repeat this process for the $password variable

Now my username and password needed for my remote session are defined!

A word of caution:.

Taking this approach for elevated accounts in your environment needs to go hand in hand with proper security of your Orchestrator Infrastructure. Given the account and password can simply be used inside a runbook without the person creating said runbook needing to actually know what the password is, I hope you draw the conclusion that in the wrong hands, this could be bad.

Additional security should be taken in the form of least rights for the service accounts in question. I would HIGHLY recommend AGAINST ever setting this up for a Domain Administrator account.

Instead, each account should only be granted the exact permissions required to perform a particular function. Don’t be afraid to create multiple service accounts for a particular technology if needed. For example, you might create an AD Service account that only has permissions to Server OU(s) and another that only has permissions to Desktop OU’s.. This limits the damage that could be done if the account is compromised or someone new to runbook authoring misconfigures something.

To end on a high note, I hope you can see how taking advantage of “Variables” within Orchestrator can help secure your accounts and make your runbook authoring a little easier. Think about if you need to change a service account password. With this method you need only change it in one place. You will need to restart any running runbooks that use the variables, but that is whole lot easier than modifying however many numbers of runbooks you may have using the account. 🙂

Until next time!