...building hybrid clouds that can support any device from anywhere
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:
NOTE: Updated version available - more information about the update can be found here: Automation–Orchestrator Integration Pack for PowerShell Script Execution–Version 1.2!
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.
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:
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.
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).
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!
This is exactly what we were looking for, as it makes running Powershell scripts on remote hosts much easier. I really like the Global option for storing connection information, unfortunately we can't use it because we need the Host Name to be passed as a variable from the Initialize Data. What are the chances of getting a Global Execute PS action that can still take the Host Name as a parameter (maybe an optional parameter)?
I may try and dig through the source code to create one myself. Otherwise we'll just use the non-global version.
Thanks, and keep up the great work!
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.
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.
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.
@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_18.104.22.168" 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.
(2nd try, not sure if last comment posted)
That works perfect! I copied the file to "C:\Program Files (x86)\Common Files\Microsoft System Center 2012\Orchestrator\Extensions\Support\Integration Toolkit\658466ff-a236-4ea2-ac75-0c7ddafc87cb" and updated the global connection settings to enable "Get Host Name from Activity". Now we can store credentials in the global settings but execute the script against a user specified server like so: http://i.imgur.com/gRpgw5a.png
Now the only issue is that we have some scripts that require using CredSSP Authentication to allow access to network shares and Active directory. Sounds like this is a well known issue called "Kerberos 2nd hop problem", but in order to do something like list the contents of \\Fileserver\Share via WinRM we have to use the "-Authentication CredSSP" option. Example:
write-output "Start $env:computername"
gci \\Fileserver\Share 2>&1 | write-output
#start execution script
$username = 'domain\username'
$password = 'password'
$securepw = ConvertTo-SecureString -String $password -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential -ArgumentList @($username,$securepw)
Invoke-Command -ComputerName remotecomputer -FilePath "c:\localscript.ps1" -Authentication CredSSP -Credential $cred
If we don't use the -Authentication CredSSP option the script will return an Access Denied error, since the Kerberos tolken is not shared with other servers by default. Hopefully CredSSP can be added as an authentication option for "Execute PS Script" in a future release.
Thanks again and keep up the great work!
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!
@Greg - Here is a link to the ZIP file "ExecutePS_22.214.171.124" 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.
Works Great! This give runbooks direct access to all the common WinRM authentication methods. I was able save the connection settings in the global activity and then execute the script against a server specified the in the initialize data activity. CredSSP is working correctly so I can use the domain credentials to access file shares and query Active Directory.
Thanks for all your hard work!
@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!
Awesome. Thanks again for all your help.
Just as an FYI, we noticed that the activity does not fail if it gets disconnected due to an idle timeout. We noticed that some of our long running scripts seemed to stop working after a few minutes, even through the runbook was still active. Using a 10 second loop to execute "winrm enumerate shell" on the remote server we saw that the WSMan Instance state changed from Connected to Disconnected after ShellInactivity went above 3 minutes (180 seconds, the default idle timeout for remote shells as per http://goo.gl/WrHs8 ).
It then would keep the session around in a disconnected state for another 240 seconds, after which "winrm enumerate shell" would not return any results on the remote server. Meanwhile the Execute PS activity would remain in an active state indefinitely until we would manually stop the runbook instance.
You might want to try and monitor the WSMan Shell Instance State variable to make sure that the session is still active, as it appears there are cases where it can become disconnected and the activity will get stuck. Increasing the Script Timeout in the PS Activity settings appears to have prevented the session from timing out on our long running processes, so we can use that to prevent this issue from occuring.
Thanks again! We probably would have had to resort to using Puppet/Chef or some other automation tool if it wasn't for your work on this PS Activity!
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!
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!
@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_126.96.36.199".
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.