Summary: Learn about things to be aware of when working with a Windows PowerShell script in Orchestrator.
Hey, Scripting Guy!
I’m starting to use Orchestrator and Windows PowerShell, but before I get too involved, I’d like to know if there is anything I should look out for.
Honorary Scripting Guy, Sean Kearney, here. I’m continuing to fill in for Ed this week. With autumn around the corner, I’m going to “leaf” him alone right now.
So Windows PowerShell and Orchestrator do work well together but there are a few things to look out for. Here’s the biggest one I’m going to put on your plate now…before you trip over it and fall on your face.
Look at this Window from the Run .NET Script activity:
Now repeat after me, “This is not an editor! This is not an editor! This is not an editor!”
Are we clear on that information? Although you can go into this window and happily makes changes like the world was covered in pink bubble gum with twinkly green diamonds, do not trust this Window for making changes without doing two key things:
- Export your runbook before editing, attempting to edit, or even thinking about editing.
- Enter the window, press CTRL-A then CTRL-C, and paste your script into a backup Notepad.
Why am I so harsh on this window? For some reason, it’s missing the most critical feature needed for an editor: the undo option. There is no (just like life) CTRL-Z. Plan for this and be safe.
Now for the good news. Although your Windows PowerShell script might have some funky Orchestrator variables in there, when you use CTRL-C and paste it into Notepad, your Orchestrator data may look something like this.
But that’s OK! That numeric GUID is all Orchestrator is looking for, and it is expecting the information in ASCII form. If you paste it back into your Windows PowerShell script, it will magically translate back to whatever it was.
A big one to remember with the Variables and Published Data is that Orchestrator replaces the content before passing to the interpreter. So if you subscribe to data that might contain characters that are special to Windows Powershell (for example, the quote), and it does not contain proper escape characters, it can break your script. Even if it’s enclosed in quotation marks. This is something to plan for with your data and your script.
And of course, as you noticed, at this time, the Runbook Tester cannot see your Windows PowerShell objects. So if you need to debug, plan for it within your script.
Pop in tomorrow as we touch on how the community has aided and extended Orchestrator with its own cmdlets!
I invite you to follow the Scripting Guys on Twitter and Facebook. If you have any questions, send email to firstname.lastname@example.org, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Sean Kearney, Honorary Scripting Guy
Windows PowerShell MVP