Calling PowerShell V3 from Orchestrator 2012

April 16th, 2012 by Karl

The problem with calling PSV3 from Orchestrator 2012 is that PSV3 runs on the CLR V4, while Orchestrator runbooks and the Invoke.Net Activity run in a CLR V2 Process, so it automatically Binds PowerShell Version 2. So even if you have installed PowerShell Version 3 (currently in Beta) on your runbook server if you run a dotnetscript like below


When you run it, even though you are in PSV3 its running on the V2 engine so you see this result


So how can we call V3 easily? Well there are hard ways, with using some loopback remoting to V3, or building your own integration pack that does some interprocess communication to a special PowerShell host sending data back and forth, maybe via a COM server, but there is an easier way

In PowerShell you can call PowerShell from powershell you can do something like

$a = powershell { 1..10 }

powershell then loads a child process, runs the scriptblock (the 1 to 10) it then gets serialized , returned to the host Process and deserialized.

The good thing here is when V3 is installed the Child Process will be PowerShell V3. So lets put this to the test.


and sure enough.


So now you can from your V2, call V3 and get results, How can you actually pass info from Orchestrator to V3. Well its actually easier than in plain PowerShell since orchestrator 2012 simply just edits the text of your script before you run it.


However maybe you want to actually pass it in, and pass in a variety of info and do it a more “PowerShelly” way. in that case you can Pipe in an object (or a collection of objects) to your call to PowerShell, and it will be available in that child PowerShell process as the variable $input

So in the next example. I create a PowerShell custom object containing more than one piece of info. a string and something from the databus. I pipe it into the PowerShell { } and then do some processing , returning a customobject with 3 properties.. one the powershell version, and the other just modified versions of the input (i.e uppercase). Then I bring that object back and break it out into individual variables for the “invoke dotnet script” to publish on the databus.


Below is my published data.


and here is the code.


#prepare data to pass
$databusvar = "\`d.T.~Ed/{2B4BE08D-BD2D-4ACD-856C-83764177F88B}.databusvar\`d.T.~Ed/"
$someotherthing = "someother"
$inobj = new-object pscustomobject -property @{
    databusvar = $databusvar
#call powershell V3
$theresults = $inobj | PowerShell {
    #use the special $input variable, just get the first item in case multiple
    #objects were piped in. (which weren't in this case)
    $inobject = $input | select -first 1
    #return results 
    new-object pscustomobject -property @{        
        version = " from Version $($PSVersionTable.psversion.tostring())"
        databusuppercase = $inobject.databusvar.toupper()
        hellorunbook = "hello $($inobject.other)"
#take the results from property and put them in variables for
#the script activity to pick up and publish on the databus
$theversion = $theresults.version
$other = $theresults.hellorunbook
$databusvar = $theresults.databusuppercase


and now the proof of the pudding.


and there you have it full round trip, multiple items of data in (including from the databus), calling PowerShell Version 3, and returning multiple items and publishing them to the databus.

Posted in Orchestrator 2012, Powershell | 5 Comments »

5 Responses

  1. Running 2012 Configuration Manager SP1 PowerShell cmdlets from an Orchestrator Run .NET Script activity. « LabRatCentral Says:

    [...] Explanation of the PowerShell V2 / V3 issue – Live PowerShell with Karl Prosser [...]

  2. Configuration Manager SP1 PowerShell in Orchestrator Part 2: The Rest of the Story « LabRatCentral Says:

    [...] Karl Prosser post - Live PowerShell with Karl Prosser [...]

  3. Orchestrator 2012 SP1 – PowerShell 3.0, Run .Net Activity and Get-SCXAgent | Says:

    [...] the command in a regular shell (PowerShell 3.0) everything worked fine. I came across a post from Karl Prosser where he describes the [...]

  4. Will Says:

    Fantastic post. I was struggling with an integration into IBM’s Maximo with a PowerShell script in Orchestrator. I didn’t even realize I was running into the issue until I found your post and tried.

    Worked like a charm!

  5. System Center Orchestrator and Azure PowerShell | Windows PowerShell Says:

    […] ran into the following article by Karl Prosser when I began investigating why I was unable to import the Azure module and simply list some […]

Leave a Comment

Please note: Comment moderation is enabled and may delay your comment. There is no need to resubmit your comment.