PowerShell Script Custom Workflow Action


Badge +7

Hi All,

I put together a custom Nintex Workflow action that executes PowerShell script based on Christian Glessners’ Execute PowerShell Script Action which is part of his Advanced Workflow Actions for SharePoint Designer 2010 which you can find on CodePlex.

The following variables are provided to your script:

  • $site = the current Microft.SharePoint.SPSite
  • $web = the current Microft.SharePoint.SPWeb
  • $list = the current Microft.SharePoint.SPList (null in site workflows)
  • $item= the current Microft.SharePoint.SPListItem (null in site
    workflows)
  • $ctx = the current workflow context
    Microsoft.SharePoint.WorkflowActions.WorkflowContext
  • $sharePointService = the current
    Microsoft.SharePoint.Workflow.ISharePointService service
  • $listItemService = the curent Microsoft.SharePoint.Workflow.IListItemService
    service

There are also 5 user variables that can be used as both input and output to your script.  One of the great things about this action is that you can require that all scripts have to be signed, thus preventing your workflow designers from writing any PowerShell they want. This is a farm level setting which means you can have it turned off in DEV but require it in TEST & PROD.

You can also pass in an encrypted string which will be decrypted at runtime which can be used for passwords.  Lastly, you can pass in a Secure Store AppId which will retrieve the credentials from the Secure Store Service at runtime and pass it in as the variable $credential as a
System.Net.NetworkCredentials object.


31 replies

Userlevel 5
Badge +9

That's really a great idea !

And security is included !

Userlevel 7
Badge +17

Great job, can't wait to try it out!

Badge +7

Just a quick word of advice regarding using this action.  Whenever possible use out of the box Nintex Workflow Actions instead of writing your own PowerShell scripts and running them using this component.  I'm confident the great engineers at Nintex work hard to optimize the code behind their components and side by side they'll probably perform better than custom PowerShell script that we write.  Just as an example of this, I ran a test where I used the Query List Nintex action and ran another test where I wrote PowerShell script using the SPQuery object and an optimized query.  You can see that the Nintex component executed in less than half the time, maybe on third the time, than my less than optimized PowerShell script ran in.  Below you will see the perfmon graph showing the execution of the PowerShell script (B) vs. the execution of the Query List Action (A).

1-8-2015 1-45-41 PM.png

I'm not trying to dissuade you from installing and using the component but just like most things in SharePoint, just because you can, doesn't mean you should happy.png.  With a little more optimization ViewFieldsOnly = $true and RowLimit=1, I was able to get my script to perform like the Nintex Query List Action. Below you can see they are closer now A=Nintex Query List & B=PowerShell Action

1-8-2015 2-53-39 PM.png

Userlevel 7
Badge +17

Well said. But just like a Web Service call can give you that extra extension to perform activities outside of the available actions, so will the possibility of a PowerShell script.

Userlevel 7
Badge +17

eric halsey‌, I didn't check, but does the feature activate automatically deploy the action to the available actions when the solution is deployed? I wanted to double check to help Andy Scott‌ with his question.

Badge +7

Hi Andy,

You can get the solution file (.wsp) in the downloads section on CodePlex.  You can run the following PowerShell script assuming you change the path to where you saved the wsp (L: emp) and your web application url (http://intranet).  Also, wait a couple of minutes after you execute the install-solution command and before you run the enable-spfeature command.

if ((Get-PSSnapin "Microsoft.SharePoint.PowerShell" -ErrorAction SilentlyContinue) -eq $null) {

    Add-PSSnapin "Microsoft.SharePoint.PowerShell"

}

add-spsolution L: empNintexCustomWFActions.wsp

install-spsolution NintexCustomWFActions.wsp -GACDeployment

enable-spfeature NintexCustomWFActions_NintexCustomWFActions -Url http://intranet

Go to Central Administration -> Nintex Workflow Management -> Managed Allowed Actions and make sure the NintexCustomWFActionsExecutePowerShell item is checked.  You should now be able use the custom action.  Please see the CodePlex page for instructions on how to use it as it does require either signing every script or disabling script signing.

If you need help on adding and installing SharePoint solutions you can read the following Deploy solution packages (SharePoint Server 2010).

If you need additional help on activating web application features you can go to Enable-SPFeature (for 2013 but is basically the same as 2010).

Let us know how it goes.

Badge +7

Hi Andrew,

I thought so.  However, when I uninstalled it and tested the deployment commands I put together for Andy, it wasn't enabled so I'm not 100% sure.  I put in the steps to check it just in case.

Badge +7

Great!  Let me know how it goes and what kind of things you end up using it for.

Usually you get that error if you do not wait for the solution to get installed (install-spsolution) before enabling the feature (enable-spfeature).

Badge +2

As already mentioned in another thread there is a similar custom action available (commercially licensed) to execute PowerShell scripts from Nintex Workflows from the Nintex partner company Data One.

More Information about the Data One PowerActivity

Disclosure: I am working for Data One.

Badge +7

Thanks for sharing.  Is there an enhancement roadmap for your activity that you can
share with the community?

Badge +2

Sorry, there is no committed roadmap (features, release timelines) at this point in time.

Badge +5

Eric and others,

I've purchased the DataOne Power Activity but have not been able to get it to function properly. Initially they were responsive to my requests, but subsequent issues that I've submitted have received no response. I'm left to ditch this product and go with the solution provided here. Thanks for posting.

Badge +7

Hi Gerard,

Let me know if you have any issues and I'll do my best to help.

Regards,

Eric

Badge +2

Gerard,

I am sorry to hear that you are not satisfied with your support experience. I will have one of our support engineers reach out to you asap.

Regards,

Matthias

Badge

Hello Gerard,

I already talked with a developer and we will contact you through the e-mail address provided within your support ticket to solve this problem.

Kind Regards,

Frank

Userlevel 7
Badge +17

Nintex 2013 SDK was recently released The Nintex Workflow 2013 SDK is (initially) released!

Is it necessary to create the same solution using the 2013 SDK?

Badge +7

Hi Andrew,

I would hope not. Did you give it a try on 2013?

Regards,

Eric

Badge +5

Matthias, Frank,

I wanted to update my notes about DataOne's PowerShell tool for Nintex Workflow. Once we reconnected they have gone to great lengths to ensure we got the product up and working. There were numerous issues and discoveries on both sides. The net result is that we are now going into production using their tool and are very grateful for their diligence in getting this working in our environment.

I tend to challenge the software limits of products that I use so technical support becomes vital to a company's efforts to win my loyalty. Both Nintex and DataOne have done that for me.

Thought I should pass that on.

Badge +2

Gerard,

I am very happy to hear that finally you are satisfied with your Data One support experience and that you are about to go into production. Thanks for sharing that information.

Regards,

Matthias

Badge +1

I've the same issue as rene. Any update or fix?

Badge +2

I am sorry I cannot help you with your specific problem. But I invite you to use the free trial of our (commercially licensed) PowerShell activity to check out if it works for you.

Badge +7

Hi,

By default each script must be signed.  This allows admins to control what PowerShell script can be executed.  You can turn this off by running the Set-PowerActivityScriptSigning.ps1 script with $false as the parameter.  Please let me know if you have any other questions.

** Full Signing Instructions **

Signature

By default every script that you want to execute must be digitally signed. However, you can change the setting to not require a digital signature (dev system). The corresponding PowerShell script is included in package.

Disable Script Signing

The script must run on a SharePoint machine

PS> & .Set-PowerActivityScriptSigning.ps1 $false

Sign Scripts

In order to sign scripts you need the private key that has been generated during the installation of solution.

1. Export Private Key

The script must run on a SharePoint machine. Keep the private key secure.

PS> & .Export-Key.ps1 –path “C:private.key” –includePrivateKey $true

2. Sign the Script

After you have exported the private key you can sign the script. The signing must not be done on a SharePoint machine, you only need the private key and the script. To sign the script you have to save it temporarily to a file.

PS> & .Sign-PowerActivityScript.ps1 –keyPath “C:private.key” –scriptPath “C:script.ps1”

The signature will look like this:

YoVKP2lCKF1B8Q9ZIBvy98+T2haNayr81aGTfXEPyRmFxLNII3R6pagaHVZfZ7j5L2zTga53SqetVRLgTUebiOan2WUnCR2HualqvvdXYX1LhwAZ/KdaOibqpE5aGgZTesJJln8+81Qwy4wOqSxCv3iQjIgVbJz7+D3kIm9dP7Q=

Simply copy & paste the script and the signature to the script and signature field of the “Execute PowerShell Script” action.

White spaces in the script will be ignored in the signing process.

Badge +1

Hi Rene,

in my case the following powershell installation line do the trick.

"

install-spsolution NintexCustomWFActions.wsp -GACDeployment -CompatibilityLevel All

"

Badge +7

Hi Rene,

Did Hannes instructions help you?  I'm sorry but I haven't had the opportunity to test the activity on SP2013 so I'm not sure what may be the issue if it still doesn't work.

Badge +7

Hi Rene,

Not sure if this is it or not but you'll still need to add the SharePoint add-in if you use commands like Get-SPWeb.  That being said, if the $web you are creating is the same as where you are running the workflow (which it appears it is because you are using ItemProperty:URL) then you already have a $web variable that is automatically created that you can use in your PowerShell.  There are a number of other variables that are created for you as well.  The very first post in this thread has the list of variables you can use in your script without having to create them.  If you do need to use commands like Get-SPWeb make sure you add the add-in at the beginning of your script.

Add-PsSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue

Hope this helps,

Eric

Reply