Automation–Orchestrator Integration Pack for PowerShell Script Execution

  • Article

Hello Readers/Viewers!

Wow! An entire week has passed since my last post… not to worry, I have plenty of content coming up in the next few weeks – to include another couple “refresh topics” to work through. This happens to be one of those refresher posts – So, here we go, the fourth “real” post after my introduction…and this post and its associated deliverable is dedicated to the:

Orchestrator Integration Pack for PowerShell Script Execution

NOTE: Updated version available - more information about the update can be found here: Automation–Orchestrator Integration Pack for PowerShell Script Execution–Version 1.2!

History

As with all of the rest of these Integration Packs, their creation came about from a very clear and specific need. In this case it was the very obvious need for enhanced PowerShell capabilities within Opalis Integration Server (and now Orchestrator).

Opalis Integration Server is 32-bit application. It wasn’t until after the acquisition that OIS was even able to install and run on a 64-bit server, so the thought of executing PowerShell in a non 32-bit context was (and still is to some extent) a ways off.

This Integration Pack was developed as a stop-gap measure to both prove it was possible to execute remote 64-bit PowerShell from OIS and Orchestrator as well as to ensure we had the capability as close to “in box” as possible. has been up on CodePlex and filling this gap since 2011.

Fun Fact: As of the publication of this post, the Orchestrator Integration Pack for PowerShell Script Execution 1.1 and its documentation have been downloaded 4418 times from its previous home on CodePlex.

Relevance Today

Much to the chagrin of many folks, Orchestrator has continued this 32-bit legacy into its current iteration. What does this mean? Well go ahead and try to execute 64-bit only PowerShell from the “Run .Net Script” activity in System Center 2012 SP1 Orchestrator. Likely you will receive an error stating that a portion of your known good script “…is not recognized as the name of a cmdlet, function, script file, or operable program”.

So, is it still relevant?

Sure. Especially if you do not want to create Encrypted Variables to store in the “Run .Net Script” activity while you execute “Invoke-Command -ComputerName $ServerName -credential $credential” type commands. I am not discouraging the “Invoke-Command” method – it is a fine method that I leverage on a regular basis – I am just saying this Integration Pack is yet another option to execute PowerShell from Orchestrator, the forever 32-bit (yet loveable) datacenter application. ;)

Let’s take a look at the available activities within this Integration Pack:

  • Execute PS Script
  • Execute PS Script – Global

The two activities are identical save the fact that the “Global” activity option allows for a global configuration to be set for use across multiple activities. The non-“Global” activity option requires connection information be entered for each activity.

Usage

Please refer to the available and included User Guide for configuration instructions, example usage and troubleshooting notes. This old blog post may also be useful for even more background and usage information (NOTE: Be sure to use the following TechNet Gallery download location, instead of any old download reference).

Download

Click here for the TechNet Gallery Contribution for this Integration Pack!

NOTE: This TechNet Gallery Contribution has been updated to reflect the latest version (1.2) of the Integration Pack. More information about the update can be found here: Automation–Orchestrator Integration Pack for PowerShell Script Execution–Version 1.2!

enJOY!