Summary: Sean Kearney explains how to use a Windows PowerShell script in System Center 2012 Orchestrator to access variables and published data.
Hey, Scripting Guy!
I’m using System Center 2012 Orchestrator at work, but I don’t know how to access the variables and published data in Windows PowerShell. Is it possible? Is it easy?
—SH
Hello SH,
Honorary Scripting Guy, Sean Kearney here. I’m filling in for our good friend, Ed Wilson. He’s busy this week enjoying the beautiful colors in the trees and the foliage.
SH, when you put the word “PowerShell” in your question, the immediate answer is, “Yes, of course! You can achieve almost anything with Windows PowerShell." Right now I’m working on a module to allow Windows PowerShell to tie my shoes! (Of course I’m kidding. I’m pretty certain Ed has already written that.)
So for those of you just stepping in, Microsoft has a tool called System Center 2012 Orchestrator. It’s a really cool piece of technology that allows for some very complex automation to happen—but in a task-based scenario.
The strength of Orchestrator is that it presents a very simple to understand visual automation system. It’s also a very extensible system like Windows PowerShell. In fact, you can have Orchestrator launch Windows PowerShell scripts, which allows you to leverage in-house solutions within an Orchestrator runbook.
Within Windows PowerShell, we have objects like these:
$DOG=”I caught the kitty cat”
$USER=GET-ADUSER –filter “*”
System Center 2012 Orchestrator also has a way to store and retrieve user and system-provided data. But in Orchestrator, we call these Variables and Published Data. For a really great breakdown about System Center 2012 Orchestrator, here is a video from TechEd 2013 to bring you up to speed: Microsoft System Center 2012 Orchestrator: Crash Course.
If you were looking at a Windows PowerShell script in Orchestrator, you would be viewing a window similar to this, which is the .NET task in a runbook:
So as we can see this is a very blank script. It doesn’t have to do much today, other than access data in Orchestrator. So first we do the hard part—create a Windows PowerShell object:
Now if you’ve used Orchestrator before, this is actually the easy part. Right-click the middle of the script, click Subscribe, and select either Published Data or Variable (depending on the particular data in Orchestrator you want to access):
Now you’ll see a representation for the data in Windows PowerShell:
But wait now—you’re not done. You see, this is not a pointer. What Orchestrator will do when you run the Windows PowerShell script within (before it passes to the Windows PowerShell engine), is replace {DomainDNSName} with whatever your value is.
So if the value we had was a string called CONTOSO.LOCAL, this is what would be passed down to our good friend, Windows PowerShell:
$SomeVariableinOrchestrator=CONTOSO.LOCAL
Notice something wrong with this statement? There are no quotation marks around this string. So this would pass down to Windows PowerShell and be run as code, which of course, unless you had an alias called CONTOSO.LOCAL, would simply cough up some nasty error.
So what you’ll need to do is enclose the data in a pair of quotation marks when you subscribe as shown in the following image:
This would now translate to this:
$SomeVariableinOrchestrator=”CONTOSO.LOCAL”
Of course, this will work fine in Windows Powershell.
If the data being published is Date/Time data, you need to precede the Windows PowerShell object with [datetime] to allow it to be properly converted. Otherwise, it will simply be a string. Here is an example of this in action:
There are some situations where you won’t do this. If the data being published or the variable is an integer, there is no need to enclose any of this within quotation marks or precede it with [datetime].
Easy as pie!
Interested? Stick around for this entire week as we discuss Orchestrator and Windows PowerShell, the coolest two-punch combo in the industry—and see how to make them work together!
And tomorrow (if you’re really good), I’ll show you how to publish data to the Orchestrator data bus from Windows PowerShell.
I invite you to follow the Scripting Guys on Twitter and Facebook. If you have any questions, send email to scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Sean Kearney (filling in for our good friend Ed Wilson),
Honorary Scripting Guy, Windows PowerShell MVP