Compartir a través de

Automation–Orchestrator Integration Pack for PowerShell Script Execution

  • Artículo

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!

Comments

  • Anonymous
    January 01, 2003
    @Greg First of all, thank you for the kind words. Your improvement suggestion is an interesting one. Let me investigate what the best method would be to add this functionality and get an optional release out... Question - would it be acceptable if I updated the code, and simply released a newer version of the DLL (with this change added/tested)? That way, you have the option to leverage the available "Invoke .Net" activity that ships with OIT and/or update the DLL on your Runbook Designer/Servers. This would allow for a much faster and cleaner optional release. Let me know. -Charles

  • Anonymous
    January 01, 2003
    Greg, Yeah, I didn't publish the source at the time I originally published the Integration Pack... in fact, none of the IPs I have created have published source code - QIK/OIT was just not something people were getting into back then. I did take the time to investigate the work effort to update / test and release a DLL. It shouldn't take me too long, I just have to fit it in with other priorities. That said, I do not believe it will be compatible with the most recent version of the Run .NET activity (that ships in the Integration Pack with OIT). BUT, the DLL that I do create can replace the existing ExecutePS.dll that is already on your Runbook Designer / Runbook Server in the special folder it lives in currently. You can even keep the old one (renamed) and swap it back if you decide. Let me work on this a bit and get back to you. I will let you know when I have something I can deliver to you for testing.

  • Anonymous
    January 01, 2003
    Interesting info

  • Anonymous
    January 01, 2003
    @Greg - I have a DLL for you to test. I have done some initial testing and it looks good... it doesn't modify any existing functionality, but adds the ability (option) to leverage "Host Name" from the activity level... Here is a link to the ZIP file "ExecutePS_1.0.0.1" containing the DLL: http://sdrv.ms/15V5alO Please rename your existing ExecutePS.DLL (at the very least on the Runbook Designer and one of your Runbook Servers, if they are different machines) and replace it with this file. You will see the new options available in the Global Configurations.

  • Anonymous
    January 01, 2003
    @Barry - Thanks. I just confirmed that this link (http://sdrv.ms/10dEvfQ) is still active and should take you to the download location (skydrive) for the following ZIP file "ExecutePS_1.0.0.2". We are noticing that CREDSSP functionality has become increasingly important in more and more automation scenarios. It is still my intention to publish a new version of the Integration Pack (for those who have not already used this DLL to "upgrade" behind the scenes. Look for that coming in the next few weeks. -Charles

  • Anonymous
    January 01, 2003
    @Greg - This is FANTASTIC NEWS! Thank you so much for testing and verifying functionality... Actually, now you have me pumped up a bit. I think I am going to find some time to rev the Integration Pack (more for net new adopters than Pros like you) to 1.2 to include these great enhancements you requested. :) Officially on my list...Thanks again and happy automating!

  • Anonymous
    January 01, 2003
    That is great news Greg! As far as CredSSP - I believe I investigated this a couple years ago... I will see what I can do to get you another build with this for testing in the next couple days... Stay tuned! Thanks!

  • Anonymous
    January 01, 2003
    @Greg - Here is a link to the ZIP file "ExecutePS_1.0.0.2" containing the latest DLL with the option for CredSSP: http://sdrv.ms/10dEvfQ I was only able to test that it attempts a CredSSP connection, not that it actually worked. Please let me know what your testing reveals.

  • Anonymous
    January 01, 2003
    Greg, You are most certainly welcome! The timeout stuff was something on my list, but no one had yet given me any evidence to support it wasn't working as expected. I added it in there in the beginning because I saw it was an option. Obviously it was not implemented properly. When I get some time I will take a look at the code and see what I can do. Thanks again for all your assistance in testing and making this a better product for everyone! And again, thanks for the very kind words. I will do my best to continue to improve on this and other offerings! -Charles

  • Anonymous
    April 24, 2013
    The comment has been removed

  • Anonymous
    April 25, 2013
    I tried looking through the source on CodePlex, but it looks like the integration pack build process isn't there. I assume it is just the code for generating the DLL, which then gets wrapped with meta data into the oip package via wix. If you are able to create a new DLL that would be great! Just let me know where to put it on the server and I'd be happy to test it out. Thanks!

  • Anonymous
    May 01, 2013
    The comment has been removed

  • Anonymous
    May 14, 2013
    The comment has been removed

  • Anonymous
    May 20, 2013
    The comment has been removed

  • Anonymous
    July 03, 2013
     The CREDSSP download link isn't working anymore. I just downloaded it a couple days ago but can't seem to put my hands on it. I am curious if anyone else is having to use credssp in SharePoint environments because of the double hop issue? I have tried Kerberos but have yet to make this work. Sounds like the Active Directory snapin has the same problem and requires credssp. Thanks for your great work!