Great tool. But for enterprise use it's better to break general purpose PoSh activities into reusable but laser focused activities that cannot harm by inadvertently overburdening the infrastructure or outright doing bad things.
Considering the way the action works, I feel like the threat of that happening is low (the target executing machine must have WinRM enabled and the user specified must also be a local admin or be configured with least permissions to execute PS via WinRM.)
The only current pitfall I see with this action and system load is that it is a blocking action and is subject to the same batch timeouts as other sequential workflow activities. I do have this on the road map to be addressed however.
The game plan is to have a service (Windows or SharePoint) that actually performs the work so that the action can fire it up asynchronously and check up on the status of the PS session via a token system.
I welcome your thoughts opinions on that approach as it is still in development! 
Additionally, the same thing could be said for a lot of the other fairly open ended actions in Nintex Workflow (Call Web Service, Web Request, etc).
And that seems the reason for "Allowed actions" to exist in Nintex Workflow Settings, right? ;-)
That was my thoughts on it! There are quite a few checks and balances in there.. I always like to empower when possible and ensure there are plenty of options to manage potential abuses.. 
THIS is the best thing since the "self toasting knife bread",
Nice work mate
Nice work, Aaron!
I can see this coming in very handy in a number of SP admin and overall infrastructure scenarios. Gosh how I hated doing all of that heavy lifting with AutoIT and other assorted scripts back in the day.
If you have any cool usage stories, please do share! I am working on a few ideas myself to share with the community..
Use {TextStart}function scriptblock() {}{TextEnd} to work around
That should do the trick!
Are you running Server 2008 or 2008R2? The authentication type currently used by the action is Basic which works pretty much out of the box with Server 2012. The issue you are seeing is indeed a double hop authentication issue. I am currently looking at adding an option to change the authentication type from basic to CredSSP or Kerberos.
I do have a separate build of the action that supports CredSSP exclusively that you could use. I will upload a build to Codeplex and mark it CredSSP.
That is very strange, all of the environments (Server 2012) I have tested this on worked out of the box with the basic authentication.
No worries! Thank you for bringing it to my attention, please let me know if you run into any further issues. I am aiming for bug free!
I'll have a look and compile the changes in. Thanks!
Unfortunately I cannot share the password for the key as it is there to uniquely identify myself as the developer/compiler. That said, it is just a self signed cert. Feel free to compile/sign with another certificate. If you wish to branch/fork the action feel free to do that as well.
You make a valid point. I did not think about the change in the strong name. Let me look up the key for the cert. I will update the documentation on CodePlex with the info.
Run as is not running with account mentioned instead i see its passing as anonymous any idea how to get this done?
I'm directly passing a PS file location in the PS Script, that will run the PS file, but in the ULS i see its accessing as anonymous.
Hi Indra,
You might try using the CredSSP version of the action. If you run a scrip that has 'whoami' in it, what returns?
This looks great. Thank you so much! I got it installed, the only issue I have is the "Result Output" field. I can't enter anything and the combo box is empty. Something I did wrong? Thanks.
Sorry to bother you with this, I figured it out.
No worries! For any future readers, you need to create a multi line variable and select it in this field.
This is probably ignorance on my part again, but my workflow does not execute the script. I shared out the folder containing the script, and I can execute it from a powershell window on another server. I have the UNC path in the PowerShell Script box, and I have the servername with domain in the Server Name field. (servername.subdomain.domain.ext) I don't see anything in the ULS logs with the script name referenced. The wf, which has only the single step of the PowerShell action, completes without error. Any help greatly appreciated.
No worries at all! Do you see anything in the ULS logs at all that reference the NTX action? The correlation should step through each step of the action. You may need to flip on verbose momentarily to catch some of the messages.
Additionally, do you see anything in the event logs of the server that is executing the action (it could be any server running the workflow infrastructure service).
Thanks. Searching on NTX, I found this:
Legacy Workflow Infrastructure 00000 Unexpected Error Data:
System.Management.Automation.Remoting.PSRemotingTransportException:
Connecting to remote server servername.subd.dom.ext failed with the following
error message : The client cannot connect to the destination specified in the
request. Verify that the service on the destination is running and is accepting
requests. Consult the logs and documentation for the WS-Management service
running on the destination, most commonly IIS or WinRM. If the destination is
the WinRM service, run the following command on the destination to analyze and
configure the WinRM service: "winrm quickconfig". For more
information, see the about_Remote_Troubleshooting Help topic. at
System.Management.Automation.Runspaces.Internal.RunspacePoolInternal.EndOpen(IAsyncResult
asyncResult) at System.Managemen... 5414bdb2-702c-48d1-bdc0-529f725cbc75
09/11/2015
15:16:13.04* w3wp.exe
(0x2810) 0x05A4 Unknown Legacy Workflow Infrastructure 00000 Unexpected ...t.Automation.RemoteRunspace.Open() at
PSActivity.PSHelper.CreatePowerShellRunspace(Boolean UseSSL, String
Computername, Int32 Port, String AppName, String ShellUri, String UserName,
String Password) at
PSActivity.Activity.Execute(ActivityExecutionContext executionContext) 5414bdb2-702c-48d1-bdc0-529f725cbc75
I will check the event logs to see if I can find anything related. Thanks.
