Skip navigation
All Places > Support > Blog
1 2 3 Previous Next


43 posts

There is currently a .Net update that has caused disruption on SharePoint 2007,2010,2013 and 2016 platforms. 


After applying .NET Security Only patch to resolve CVE-2018-8421 (Remote Code Execution Vulnerability) , all SharePoint "out of the box" & Nintex Workflows fail to execute and the log will show an error like the below:


ULS Log: 

System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file


Publishing a Nintex workflow 




Microsoft link to issue & resolution.


Microsoft related update information:

Microsoft .Net 3.5 Information.

Microsoft .Net 4.X.X information.

This blog is dedicated to SharePoint on premise installations of the Hawkeye Data Collector in regards to Firewalls.


The Hawkeye SharePoint data collector communicates to the cloud in a couple of ways.

It talks to what we call the discovery API for commands, to register itself and request upstream endpoints to live events and workflow definitions. In production these urls are:


1. (port 443)
2. (port 443)
3. (port 443)


For upstream communication Nintex talks directly to azure storage and event hubs directly. Azure storage will again use port 443 on urls similar to this one https://<storage<https://%3cstorage> account name>


Event hubs can use a couple of different methods. The urls will look something like this sb://<event hub name> It will initially try to connect using AMQP over ports 5671 and 5672. If these are closed it will try TCP ports 9350 to 9354. If these are closed it will fall back to https over port 443 (this is slower).


You will notice that setting static IP addresses for the firewall are met a problem on the upstream communication connection. The address pool is large and dynamic for azure. 


Example IP Address from the Azure Communication



It is not possible for us to provide all IP ranges, as this service point can expand depending on usage for the Microsoft Azure platform. This is why it becomes important to have Application profile on a URL for a firewall rule rather then explicit IP address. This can be a problem for older firewall kit/software.


This blog gives a quick over view on Ports/Url's to consider when setting up Nintex Live in your corporate network. 


Reference Material:



The Urls/Ports






There is a chance you will run into an IP address change. So if you look them up please be aware as they are dynamic. 

Please be advised that Nintex intends to fully comply with the GDPR, to the extent it is applicable to Nintex, and to provide GDPR related assurances in our contractual commitments, once the GDPR becomes effective on May 25, 2018. Until then, our Privacy Policy,, and security disclosure,, remain in full force and effect. We have not yet published a GDPR Compliance Statement as the ICO has indicated there may be additional guidance on GDPR compliance issued prior to May 2018.


While we do not process or store any customer personal data, we acknowledge there may be situations in which we fall within the definition of a data processor.


Like most all companies, we are implementing processes and procedures to respond to subject access and portability requests under the GDPR.


Reference: Home Page of EU GDPR 

Meltdown and Spectre present 3 different ways of attacking data protection measures on CPU's enabling attackers to read data they shouldn't be able to.

(Scott Manley does a great job of explaining this YouTube Link



So what is Software vendors doing about this? 

  • The easy point to control this kind of operation hack is at the operating system level. So the main place to block this hack is with a patch for the operation system (Microsoft has already release patches for this so if you are up-to-date as of Jan 2018 you are in a good spot. 
  • Microsoft and the other major operation system providers have already prepared patches which effectively changes this speculative computation mechanism to avoid exposing kernel memory data. 


What impact does it have on Nintex Products.    

  • It impacts all software respectively as it hits performance & throughput on servers Intel based CPU's. 


What you need to do?

  • Make sure you are up-to-date with your operating system patching!#



Nintex security patch notice: Security patching to address the "Meltdown" and "Spectre" - Nintex Knowledge Base 

The account being used for installation is important. During the installation, the process will deploy or updated dll's and binaries to the operating system at the permission level of that user. So checking these items on the checklist should help to prevent any issues while updating or installing Nintex products. 




1: Check that the UAC setting for the account used is temporarily turned down. (You will need to do this on each server that makes up the SharePoint deployment excluding Exchange and SQL.) (Microsoft Reference)


UAC Setting  


2: Check that on-access scanning is turned off temporarily for SharePoint servers. There are many flavors of anti-virus, some impact and some don't on the installation process. To rule it out, temporarily disable it. 


Disable on access scan 


3: Check that the account has Farm Administrator and Local Machine Admin rights. This account will need local admin rights for all the hosts 



4: The account will need SQL read/write access at the point you click update. In the background, it will be updating the Nintex databases under the context of this user, that you are logged in as. 


Nintex database update

UPDATE: We've completed this effort. Please see: We Got Your Feedback On Our Product Feedback Process 


Hi, Everyone! Just a short note to let you know that we are going to streamline the experience at our customer feedback site. If you've posted a suggestion, it might soon get moved or merged into a new forum, but should still be on the site. Apologies if the effort temporarily costs you a link. We think the end result will mean fewer forums to keep tabs on, and more interaction with the people who're building the Nintex Workflow platform.

I'll blog more about it in a few days, but the gist of the effort is to reduce the number of forum, make the categories and statuses more consistent, and to help make it more clear whether or not we're going to pursue the suggestions.

Stay tuned!

As we know you can not open Nintex Workflow Designer for an UDA at Farm level in all versions of the product. So that begs the question how do we update an UDA at Farm Level if we need to change it? This is a question a Partner had and they shared their workaround with us. So I am sharing it with the community as I see it as being very useful.


The official method is using two farms. Editing the UDA in Farm A at site level then publishing at Farm Level in Farm B. This is not particularly convenient for single farm deployments. The reason behind this is that for an UDA to exist in a farm it needs a unique ID. Creating UDA's at site level to import over the farm level ones does not work since they have different ID's. 


Details on how UDA's are identified.


The UDA has a unique ID and Static GUID 

     - These can be referenced in the Nintex Config DB under the UserDefinedActions table. 


The workaround 


In Nintex Workflow 2010, 2013 and 2016, you can circumvent this limitation by editing an UDA at site level and this is achieved via modifying the UDA ID in your browser (IE 9+) URL. The result will redirect the designer session to target the Farm/Server UDA. 



By changing those values you can modify the farm level UDA. 


Known issues


If the central administration web application is on a different authentication model than the location where you opened the UDA, then the designer will not load as expected. 


This method is not an offical method. Should issues come from using this method it will not be supported by Nintex Support Team

Help file 2010 / Help file 2013 / Help file 2016     Please note these references will be updated soon.

There are different reasons for different IT teams to keep a version of the product unchanged for a length of time. When that length of time expands years it is natural to be cautious when it finally comes down to upgrading the product in your environment.


Nintex designs are by their nature almost limitless, so how do we prepare for an update when we don't know what sort of impact it will or will not have on the production workflows. The simple answer is to test it. You will need to run your designs on the desired Nintex version to be confident that they function as intended. This blog goes over some of the important 2010 and 2013 products changes and considerations. 



1: General product enhancement.

2: Action/Control updates.

3: Upgrade Strategy

4: Rollback options.



1: General product enhancement.


Topology enhancements.

From Nintex Workflow 2010 version up and Nintex Workflow 2013 version up a new solution was added to the installer in the form of Nintexworkflow201Xcore.wsp


From Nintex Forms 2010 version up and Nintex Forms 2013 version up a new solution was added to the installer in the form of NintexForms201Xcore.wsp.

These are globally deployed solutions which will deploy dll's to all SharePoint farm members. So it has the potential that APP servers with UAC may block deployment. 


Nintex Forms becomes Enterprise

When Nintex Forms as a product was divided into Standard and Enterprise, where previously it was just defined as Nintex Forms. A new license class was created. 

If you have an old license issued prior to 22nd July 2015 it is recommend that you request a fresh one prior to upgrading your Nintex Forms product.  


The Workflow Inventory

This handy one-stop page for workflow inventory added a new table to the Nintex Content DB's called dbo.Workflows. There is a minor issue if you are planning to move data after an upgrade under certain circumstances it is possible to duplicate the entries.

This is specifically with the NWAdmin.exe -o MoveData -RetainSourceData switch. 


2: Actions/Control updates.

The actions in Workflow and the controls in Forms get updated and amend where they need to over time, the list is long and all amendments can be seen here in the release notes.


Nintex Workflow 2010 - Release Notes 

Nintex Workflow 2013 - Release Notes 

Nintex Forms 2010 - Release Notes 

Nintex Forms 2013 - Release Notes 



3: Upgrade strategy 

There is a lot of information on the actions and controls in the release notes. Most of it will not be relevant to your environment, so how do you narrow what to look at. You need to gather insight on what is used in your environment for workflow and luckily there is an easy way to view it. This is not the same case for Forms since it is processed on the web front ends there is no capture of its use unless you had some analytics in the environment monitoring users trends. 



Find the most used workflows and build a list. 

The Know Your Workflow Script 


Test them on the new version. You will need another environment to set this up. If you have a valid Software Assurance agreement you are entitled to a development license. With a UAT/Test environment, you can test the workflow hopefully with the assistance of the business owner of the process. Validate it and move onto the next on the list. 


If you have found a workflow that is affected. You need to evaluate if a restart of the workflow resumes normal running, or if the design needs to be tweaked to handle the new expected action behavior. Environmental factors can play a part I have provided an example below.  


Example: In the Nintex workflow update lookup controls stopped working properly for users with IE8  


If the outcome is not as expected. Then you may need to check if it is a known bug with the support team. (




Finding the most used forms can be hard when they are not attached in workflows. You are at a big advantage if you have a form of analytics incorporated into your web applications.


When there is a problem with a form it is most likely that a control has been updated and functions slightly differently or may have been completely re-written. A good example is the people picker control as outlined in this article was completely redone.People Picker Extensions - Nintex Forms  


Just like with workflow testing the new version with your forms is key to a successful and trouble-free upgrade. 


4: Rollback options

Nintex Support does not support any roll back of the product update. 

You can SnapShot/CheckPoint your SharePoint VM's and backup your SharePoint Config and all the Nintex DB's, I would only perform this kind of restore in my testing environment.





If you have read this far I want to thank you for taking the time to read this post. I hope it has been useful and I wish you a smooth upgrade.  

This blog goes over the connection account prerequisites and considerations when designing in NWC. All this information was generated and reference on 05/12/2016  and is subject to change without notice from the vendors that provide the end-point service. 




The prerequisite is to use a Business Plan account and it has an API call limit which should be taken into account

when designing workflows.  


API account limits: 


  • Box API Access: 25k actions per month


  • Box API Access: 50K actions per month


  • Box API Access: 100K actions per month


Pricing :Plans and Pricing | Box 

Referenced from: Box Developer Platform   (Error Code reference) 





This connector requires you to allow Nintex Workflow Cloud to access your ShareFile account, you will be prompted when setting up the connector.


API account limit: N/A




The prerequisite is to enable the account to Send on behalf of functionality. SOBO functionality is only available to accounts that use the DocuSign API to send envelopes. It can be enabled for an account member by a DocuSign Customer Administrator through the DocuSign Console or by contacting your DocuSign Account Manager.


*You may need to check if your DocuSign account package allows for API calls, if not you will need to upgrade it to an Advanced Solutions package. Pricing and Packages 


API account limits: 

DocuSign has an API call limit of 1000 API calls per hour / per account (This is for Demo and Production Accounts). If the API call rate limit is reached, you will receive an exception for each call until the start of the next hour (this can be up to 60 minutes). The exception message states: “The maximum number of hourly API invocations has been exceeded” (error number 207)


Referenced from: API Call Rate Limits ; API - Send on Behalf of Functionality | DocuSign




The prerequisite is to use a Business Plan account it has an API call limit which should be taken into account when designing workflows.  


API account limit: N/A



Google Drive

No prerequisite for account plan. The API limit may very on the account plan you have. 


API account limit : 1000 requests per user per 100secounds 


Note: Although per-user limits are specified in queries per second, we permit short-term usage spikes. Therefore, you should set your limits based on sustained average traffic levels. If anyone tries to use an API in excess of these settings, the requests will trigger a limit exceeded error.


Referenced from: Capping API usage - API Console Help 




You will need to you have an account set with the appropriate permissions. Please see the getting started section here (They have a special API permission set that can be assigned to the account. 

API account limit: API access per instance limited to 100 calls per 20 seconds.


Daily Quota: Most subscriptions are allocated 10,000 API calls per day (which resets daily at 12:00AM CST). You can increase your daily quota through your account manager.


Concurrency Limit: Maximum of 10 concurrent API calls.



Microsoft Dynamics CRM

This is currently to Microsoft Dynamics CRM tenants only. So it is the online version. A trust is created between the NWC Connection Hub and the Microsoft Dynamics CRM service when creating the connection. You will need an administrative account for CRM to setup the connection.


API account limit: N/A





Microsoft OneDrive for Business Beta

Requires a business account.


API account Limit: N/A 



Microsoft SQL Server 

This service will need to be setup by your Database / Network team to make the SQL instance publically accessible. 


Nintex Help: Linked here




This service will need to be setup by your Database / Network team to make the MySQL instance publically accessible. 


Nintex Help: Linked here




This service will need to be setup by your Database / Network team to make the PostgreSQL instance publically accessible.


Nintex Help: Linked here





User account will need to have API enabled option


Setup ->Manage Users -> Profiles -> Under the "Administrative Permissions" area there is the "API Enabled" check box.


API account limit: 

The following table lists the limits for various types of orgs for concurrent requests (calls) with a duration of 20 seconds or longer.

Org Type Concurrent Limit
Developer Edition5
Trial orgs5
Production orgs25

The following examples illustrate API usage metering calculations for several scenarios.
For an Enterprise Edition org with 15 Salesforce licenses, the request limit is 30,000 requests (15,000 + 15 licenses X 1,000 calls).
For an Enterprise Edition org with 60 Gold Partner licenses, the request limit is 27,000 (15,000 + 60 licenses X 200 calls).
For an Enterprise Edition org with 15,000 Salesforce licenses, the request limit is 1,000,000. The number of licenses X 1,000 calls is greater than the maximum value, so the lower limit of 1,000,000 is used.
For a Developer Edition org that made 14,500 calls at 5:00 AM Wednesday and 499 calls at 11:00 PM Wednesday, only one more call could successfully be made until 5:00 AM Thursday.


Referenced from: Salesforce Developers


If you get insufficient privileges error on some objects you will need to check individually the object permissions in Salesforce, you may need the assistance of the Salesforce Administrator





Accounts do not have prerequisites. 


API account limits: 


In general Slack allow applications that integrate with Slack to send no more than one message per second. Slack allow bursts over that limit for short periods. However, if your app continues to exceed the limit over a longer period of time it will be rate limited.


If you go over these limits when using our HTTP based APIs, including Incoming Webhooks, Slack will start returning a HTTP 429 Too Many Requests error, a JSON object containing the number of calls you have been making, and a Retry-After header containing the number of seconds until you can retry.

If you go over these limits when using our Real Time Messaging API you will receive an error message as a reply. If you continue to send messages your application will be disconnected.

Continuing to send messages after being rate limited runs the risk of having your application permanently disabled.


Referenced from: Rate Limits | Slack





API account limits: N/A 


Loop protection

To protect your account, messages cannot be sent more than 15 times in a 30 second window between your Twilio phone number and another number. Doing so may trigger a 14107 warning that your message rate has been exceeded.


Nintex Help: Linked here




API Account Limits: 

This API is rate limited. Zendesk only allow a certain number of requests per minute depending on your plan and the endpoint. Zendesk reserve the right to adjust the rate limit for given endpoints to provide a high quality of service for all clients. As an API consumer, you should expect to be able to make the following number of requests per minute:


PlanRequests per minute
Team 200
High Volume API Add-On (Professional or Enterprise)2500


Nintex Help:  Linked here

This script was originally designed for sales and marketing to better understand the use of Nintex in our client's on premise setup. The support team has adopted it to help better inform SharePoint Administrators on what the farm has running in regards to Nintex. Showing most used workflows and peak time of year for processing for example. 


What does it do?

It will pull 4 reports on each Nintex Content DB that you have attached. This will come in the form of xls/csv files.  

 1: ActionStatistics

      Indicates workflow actions used in the last 90 days

 2: Activities:  

      (Used for reference and is the same each time as it looks at actions registered in the Nintex Workflow configuration
      database )

 3: OverviewStatistics

     Quantifies sites, initiators, and other data for completed workflows.

 4: WorkflowStatistics 

      Quantifies actions, durations, and other data for recently started workflows


How to get it and use it ?

Please download the attachment linked to this blog read though the "Know Your Workflow User Guide.pdf" provided in the zip attachment for how to use it. 


How to read the reports and make use of the information.  

This information will show you how often workflows complete. How many actions it processed for an average running of a workflow. This is important for planning databases, as you can better decide with this information which SharePoint Content DB's should have a dedicated Nintex Content DB as an example. 


The Overview report: This will give you a 12 month view of how many workflows were processed in the passed 12 months. This will show you you busy periods for that particular Nintex Content DB.


The Workflow Statistics reports: This will easily let you identify the Most run Workflow, the longest running, the highest action count on average workflow. This information can be invaluable in targeting business process owners to manage their data growth and in the case of Migrations lets you identify the biggest users of the product. Again this will only show information for DB it was run against. So you may need to get creative in amalgamating the information.    


This applies to Nintex Workflow 2010 / 2013 / 2016


Warning running these scripts will increase SQL load and may cause performance issues, so we recommend running them out of business hours.


  • Nintex Workflow 2013 version or later
  • Nintex Workflow 2010 version or later



The following message appears when installation is complete for Nintex Workflow.


Found Server(s) with ‘Web Front End’ Server Role:
Manual deployment of [version-name] solution on each listed WFE server is required.



[server-name] is a server detected to have the Web Front End server role

[version-name] is the version-specific solution: either NintexWorkflow2013WfeCore.wsp or NintexWorkflow2010WfeCore.wsp


The installer could not deploy the solution to the indicated WFE servers.


Manually deploy the version-specific solution on each WFE server using the PowerShell script InstallWfeCoreLocal.ps1. Instructions follow.

    1. Record the names of the WFE servers indicated in the installer message.
      Note: You can rerun the installer to view the message again.
    2. Export the solutions from the installer by rerunning the installer and selecting the export option. 
      1. Double-click the installer file to display the installation dialog box.
      2. On the Welcome to the Installation Wizard page, click Next.
      3. On the License Agreement page, review the license, click I Agree, and then click Next.
      4. For Nintex Live, choose the desired option.
      5. On the page “Do you want to add the solution to SharePoint now?,” select No, I wish to export the solution and deploy it manually later.
        Example from Nintex Workflow 2010 installer:
      6. Save the exported files to a folder of your choice.
    3. In the folder containing the exported files, open the "Workflow" folder and copy the following files.
      • InstallWfeCoreLocal.ps1
      • NintexWorkflow2013WfeCore.wsp / NintexWorkflow2010WfeCore.wsp
        Example of indicated files in Workflow folder from the Nintex Workflow 2010 installer:
    4. On each WFE server indicated in the installer message, do the following.
      1. Paste the copied files.
      2. Using PowerShell with administrative privileges, run the following file.
        The script deploys the solution locally. You can confirm deployment using Central Administration.


Nintex Forms does not currently offer an out-of-the-box method to print a Nintex Form. By adding a custom JavaScript button, you will be able to print the form.



Note: As Nintex Forms does not have a supported printing method, the print output may render differently than the screen output.


Add a Nintex 'Button' control to the form and apply the following:

  • Button Action: JavaScript
  • Button Type: Button
  • Button label: Print
  • Client Click: window.print();



Products: Nintex Forms 2013, Nintex Forms 2010




The following error appears when loading up Nintex Forms Designer and is logged in ULS logs:


The Expression prefix 'NFResources' was not recognized. Please correct the prefix or register the prefix in the <expressionBuilders> section of configuration.




The following errors appear in the logs:






The issue occurs when the Web Application Feature for Nintex Forms needs to be activated.




Use the following procedure to resolve this issue.


1. On the Central Administration Home page, click Application Management.

2. In the Web Applications section, click Manage web applications.

3. In the Name column, select the web application on which you want to activate Nintex Forms. For example, select SharePoint -80.

4. In the Web Applications ribbon, click Manage Features. The Manage Web Application Features dialog box appears.

5. In the Nintex Forms section, click Activate. After a short delay, the dialog box refreshes and the status is "Active."

6. Click OK


Note: For more information please review page 22 of the Nintex Workflow & Nintex Forms installation guide: Installing Nintex Workflow 2010 and Nintex Forms 2010 Installing Nintex Workflow 2013 and Nintex Forms 2013

Products: Nintex Forms 2010, Nintex Forms 2013




The following error appears during Forms Installation:


An object of the type Microsoft.SharePoint.Administration.SPPersistedfile named “NintexForms2010Core.wsp” already exists under the parent Microsoft.SharePoint.Administration.SPSolutionLanguagePack named “0” Rename your object or delete the existing object.


An object of the type Microsoft.SharePoint.Administration.SPPersistedfile named “NintexForms2013Core.wsp” already exists under the parent Microsoft.SharePoint.Administration.SPSolutionLanguagePack named “0” Rename your object or delete the existing object.




An error is logged in the installer progress window:






The form solutions were only partially deployed to the farm in a previous installation attempt.



Use the following procedure to resolve this issue.


  1. Retract NintexForms.wsp and NintexForms2010Core.wsp (or NintexForms2013Core.wsp) from the farm.
  2. Remove NintexForms.wsp and NintexForms2010Core.wsp (or NintexForms2013Core.wsp) from the farm.
  3. Re-run the installer.