OIS - Integration Pack for PowerShell Script Execution 1.00

Good Morning Readers/Viewers!

Today, I am happy to announce the next addition to my collection of OIS 6.3 QIK based IPs on CodePlex. As you can see from the blog title, this one is all about PowerShell. :)


ORCHESTRATOR RC UPDATE (11/01/2011)

CodePlex Links:

NOTE: The rest of this post is unchanged, and can be referenced for OIS 6.3 or Orchestrator.


BACKGROUND:
If you have worked with PowerShell in OIS, you have likely needed to reference blog posts which address workarounds for PS running from x64 machines:

My goal in building this IP was to eliminate the need for this workaround using the “Run .Net Script” object. In the workaround, not only do you have to increase the number of scripting lines, but you also have to include credential information (either as plain text in the script or stored as plain text in an OIS variable). I believe both of these limitations from the workaround have been addressed with this IP.

THE INTEGRATION PACK:
First, here is the link to the CodePlex Project: https://opalis.codeplex.com/releases/view/65652

The Integration Pack for PowerShell Script Execution provides extended PowerShell Scripting capability for OIS and PowerShell (executed from and against both x86 and x64 OSs).

This Integration Pack adds the following objects to Opalis Integration Server:

  • Execute PS Script
  • Execute PS Script – Global

image

NOTE: I have included a User Guide which takes you through the configuration and object specifications.

EXAMPLE CONFIGURATION AND EXECUTION:
As I do not have an “8-Minute-Video” for this yet, I will walk through an example configuration and execution for this Integration Pack:

Step 1: Create a Connection
image
NOTE: This step is only required if you plan on using the “Execute PS Script – Global” object. You also have the option to configure all settings at the object level using the “Execute PS Script” object (where you can take advantage of Published Data, Variables, etc. to make the connection/object more dynamic).

Step 2: Configure an Object
image
NOTE: You will see that there is no extraneous PSSession or ScriptBlock code required. There is also no need to string all the lines of script together separated by ";". Because this is just like a standard OIS object, you can use Published Data and Variables to make the script 100% dynamic (I have left the script static so you can see what I am executing in the example).

Step 3: Run the Object
image
NOTE: In this example, only one PS Script was executed, resulting in just one result (both count and result are highlighted in the above image). Each of these objects have the ability to execute up to five independent PS Scripts (as well as output Write-Host commands if desired). Each PS Script output can range from one single-line data output to multi-line correlated data output. Unfortunately, unlike the "Run .Net Script" object, you cannot create your own correlated Published Data items. Each of the individual PS Script executions is unique. This optional functionality should only be used if you can predict that the output from each script will be aligned.

EXAMPLE USAGE:
Now I will walk through some example usage for this Integration Pack:

Example Usage: Multiple PS Scripts and Multi-line Correlated Data Output

image
PS Script 01

image
PS Script 02

image
Output from PS Script 01 and PS Script 02 Execution

Example Usage: Single PS Script 01 Execution with Write-Host in Output Option Enabled and Filtering

image
PS Script 01 with Write-Host Command

image
Optional Filter on the PS Execution 01 Results (data output will be limited to values which contain "Opalis")

image
PS Execution 01 Filtered Results - NOTE: The output for each PS Script execution can be filtered independently. You can see that even though only three filtered results were returned for the PS Script 01, the "Write-Host" Results contained unfiltered data to include with "Write-Host" command output.

image
PS Execution 01 Results (with Write-Host) - NOTE: The "Write-Host" commands will be collected and displayed at the end of any other execution results. If you wanted to, you could filter these results on a specific key word that may be in all your "Write-Host" commands, so all you see is "Write-Host" output. This functionality is Optional and will likely only be used during testing.

Example Usage: Single PS Script 01 Execution with Error Output

image
PS Script 01 configured against a Local Server Connection without the VMM PowerShell Snap-ins Installed, Standard $error Variable included in Script

image
PS Execution 01 Results with Error Output (because the $error variable was used) - NOTE: Even though the object completed successfully, didn’t mean that the commands executed correctly. If you want to check for errors in your PS Script, simply enter the $error variable at the end of your script, if there are errors, they will be appended to the output. You can see that the commands were not successful because this Local Server does not have the VMM PowerShell Snap-ins as was expected by the PS Script.

ENDING COMMENTS:
I realize that this Integration Pack will not solve all problems with PowerShell execution from OIS. I also know that it will not address absolutely every need. I just wanted to get something out there to fill the gap between now (OIS 6.3) and the future release of System Center Orchestrator. If nothing else, you should be able to see that new and different (sometimes even better) solutions can be built with the tools you already have at your disposal. This Integration Pack was 100% developed with the current version of QIK against the available PowerShell SDK (System.Management.Automation).

enJOY!

Comments

  • Anonymous
    January 01, 2003
    @Armand Campo - Again, my apologies for the extremely late reply. For 64 bit Orchestration, be sure to check out the latest offering in SC2012 R2 (in preview) called Service Management Automation (SMA). technet.microsoft.com/.../dn205295.aspx

  • Anonymous
    January 01, 2003
    @Kevin Verhoeven - sorry about the delay, I haven't looked at this blog in a while. From what I can remember (it has been a while since I created this), the object itself will not fail unless an actual exception is thrown. Trapping or redirecting exceptions would eliminate object failures.

  • Anonymous
    January 01, 2003
    @Michael @Ibrahim - QIK/OIT does not have the ability to provide a "run as" account option. @Ahmed Adly - QIK/OIT does not have the ability to provide progress bars. My apologies folks, these are limitations within QIK/OIT.

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    All: Please direct all future questions here: http://aka.ms/buildingclouds

  • Anonymous
    July 11, 2011
    Thanks for a very convenient IP for PowerShell. Just 2 quick comments: a) Can I run a PS script instead of typing the code in the windows? I assume that the answer is Yes. b) I notice that when I added 2 PS scripts in the pipeline, the last one goes into an endess loop. The PS code in those activitites ( objects) are exaclty the same. If there is only one object, the workflow stops correctly. Any hint?

  • Anonymous
    May 15, 2012
    Nice job Charles, I love the IP! I have one question. If the PowerShell script fails, like in your VMM PowerShell Snap-in example above, why wouldn't the object fail? Thanks!

  • Anonymous
    May 17, 2012
    Hello Charles. Great stuff! I'm hopingassuming this IP helps get around the whole SCORCH=32bit Exchange etc 64bit Powershell comandlets issue etc correct? I'm speaking specfically to this issue: social.technet.microsoft.com/.../53d58dce-d4d4-41f1-bb88-37be4d424c7e I believe I've installed the IP sucessfully & have the config correct as I no longer receive any errors about connectivity when running in the tester but alas while the runbook completes with out error nothing is actually happening. Let me explain what I'm trying to do; very simple PS script to set FullAccess perms on an Exchange mailbox. the alias of the mailbox and the person needing access are inputs to the PS script via the published data in the bus. It runs fine, but nothing happens and I know the scipt is exactly perfect because it runs in PS fine. Is this still the 32bit vs. 64bit debacle above perhaps yet its somehow not producing an error? We were able to find a different workaround using the following in a PS script using the .Net object: $ErrorActionPreference = "Stop" C:WindowsSysnativeWindowsPowershellv1.0Powershell.exe ` -NonInteractive -Command {Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin Add-MailboxPermission -Identity User1 -AccessRights FullAccess -User User2} The above is from this article: www.purgar.net/using-exchange-2010-cmdlets-in-system-center-orchestrator Lastly...any idea when MS will simply make SCORCH 64bit? It seems ridiculous that it was recoded from Opalis 6.3 to 64 bit in the first place yet it's full power using the .Net object is really limited due to this architecture mismatch. Many thanks!!!

  • Anonymous
    June 06, 2012
    The comment has been removed

  • Anonymous
    January 28, 2013
    Is there a way to specify a ‘run as’ account?

  • Anonymous
    March 25, 2013
    Hello Charles, Thanks for the wonderful integration package Actually we are using v1.1, and we are implementing a solution in an enterprise enviroment that consists of thousands of subsites. I'm writing a script to iterate on all subsites to get some data, it takes pretty long time, is there any way to make some kind of progresss bar. This command as u know (Write-Progress -Activity) is responsible for this,but how can it be appeared while I'm running my Orchestrator Runbook. Regards