Orchestrator 2012 introduced the capability to define a global Variable as encrypted. This now allowed admins to use variables to store passwords instead of typing them into lots of different places in runbooks. But if the variable is encrypted, how does it then un-encrypt the value to be used within activities? And, does the un-encryption happen for all the places where I might use the variable?
The quick answer is that encrypted variables are usable (unencrypted) in property fields that are designed to store encrypted data like passwords. This goes for all properties in activities where the text doesn’t display (like password properties), and also one special field – the script body of a Run .NET Script activity! That’s right, whenever you use an encrypted variable value in the body of the script in a Run .NET Script Activity, it gets automatically decrypted by the system so that you can use it correctly in your script. This is also why we decided to stop putting the body of the script in the published data (to protect against displaying passwords).
So, the next time you need to use a password in an activity, remember encrypted variables and stop typing the passwords over and over into individual activities. Until next time!
I really miss the script body published data within Run .Net Script. Ideally this would have been kept and the encrypted format of the variable would have been used to protect the password rather than removing this functionality altogether. Having the script body published data is extremely valuable when trying to troubleshoot why a particular script did not work properly because all of the various published data and orchestrator variables are already resolved so it is a relatively quick process to reproduce and troubleshoot a script in a tool like PowerGUI. Without the script body published data these things must be manually recreated by pulled them from the various other activities and orchestrator variables which can be time consuming and tedious.
I think that functionality makes a lot of sense. I'm happy to hear about it because it will make life much easier.
I would echo Vaughn in that the script body published data for Run .Net Script is extremely useful as well. I've used it a number of times to troubleshoot. Hopefully this can be reenabled in a way to not compromise encrypted variables and their usefulness.
I discovered encrypted variables when I was writing a runbook to join remote systems to an AD domain and they made it possible to use powershell remoting to accomplish this without including plain text passwords in the script. The only potential issue is that anyone who has access to create a workflow and access the variable will have the ability to see the password. If they use the variable in a line of code that has an error, it will show them the decrypted variable, so make sure that anyone who can both create runbooks and access the variable is someone who you'd give that string to.