Looking for Nintex for SharePoint 2016 guidance? See the following link.
If Nintex Workflow was installed using its default configuration of one all-inclusive database, this data can be divided and distributed to one or more new databases. If SharePoint content needs to be similarly subdivided, there is a SharePoint method to achieve this. This document describes a process using both methods in conjunction to achieve a 1-to-1 mapping of SharePoint and Nintex data.
NOTE: If you do not want a 1-to-1 mapping of SharePoint and Nintex content databases, the SharePoint Content can be left as is and only a dedicated Nintex database created and the Nintex data moved. With this mapping, whenever a backup and restore is done in the future, the entire SharePoint content database and all the Nintex Workflow content databases will need to be backed up at the same time and restored at the same time. For more information, see Nintex Workflow Backup and Restore.
For guidance on planning database mapping and maintenance, see Database Design Guide: Nintex Workflow.
Please read this entire article to familiarize yourself with the process and its requirements. As always, Nintex recommends testing this process on a non-Production environment first.
The PowerShell Move-SPSite command is used to move the content of a SharePoint Site Collection from one database to another on the same SQL Server. This process can be done independently of Nintex – if a SharePoint site collection is given its own SharePoint content database, it will use its
existing Nintex content database until directed otherwise.
The NWADMIN movedata command is used to move the Nintex workflow progress data of a Site Collection into its own Nintex content database. The new database can be created using the Central Administration interface, but the data itself must be remapped using NWADMIN.
To split a SharePoint Content database and a Nintex Content database to enable one to one content for each:
To split out site collections to maintain a 1-to-1 mapping between SharePoint Content Database and Nintex Workflow Content Databases, use the PowerShell Move-SPSite, providing the ability to move a site collection to an another Content Database whilst preserving all SharePoint GUIDs (naturally
except the Content Database ID).
For these procedures to work, the following conditions must be true:
The specific KB describing this command from Microsoft is available here:
Before performing the below steps, disable access to the farm using Microsoft’s standard methods
Please note: The information provided below only caters for the example described above. However, the “movedata” command is capable of catering for other scenarios, for information in this regard, please refer to NWAdmin Operations - Nintex Workflow 2013 or NWAdmin Operations - Nintex Workflow 2010.
This operation is used to move all workflow progress data for a site collection to a selected workflow content database. This command should be run as the Farm Account, as this identity will have access to each workflow database.
The utility will begin by warning the user to pause all services that can run or interact with workflow. You will need to stop the Web Application that is to be restored. This includes stopping the IIS site mapped to the web application and stopping the SharePoint Timer Service and all servers in the farm. This is important: if the workflow data changes during the migration process it may become corrupted. Once the migration is complete, the tool will attempt to detect any changes to the data and handle this by warning the user and moving the changed data, but it is recommended to avoid this situation.
In a command prompt, type:
nwadmin.exe -o moveData –Url http://YourFullyQualifiedDomanName/sites/sitename
The tool will list the workflow content databases that are configured with numeric identifiers and prompt the user to choose which of these databases the site collection workflow data should be moved in to.
The data for each workflow instance is moved one by one. If any fails to move, the tool will display error details and prompts the user either to retry moving the instance, skip the instance or abort the process, rolling back any changes.
Once the operation is complete, restart all services to continue workflow operation. From this point on, workflows in the site collection will use the new database. If any services were not stopped during the migration process, they will contain cached references to use the old database so it is
critical they are restarted at this point (which will cause them to clear the cached database pointer and use the new database).
NWAdmin.exe -o MoveData [-Url <siteCollectionUrl>] [-SourceDatabase <connection string>] [-TargetDatabase <connection string>] [-RetainSourceData]
|-Url||The url to the top level site of the site collection that data will be moved for.|
|-SourceDatabase||A database connection string to the Nintex Workflow database to extract data from. Use when retrieving data from an external database not connected to the target environment.|
|-TargetDatabase||A database connection string to the Nintex Workflow database to move data from. If a value is not provided the console UI will prompt for the target database.|
I have tried exact same steps mentioned above and run nwadmin.exe -o moveData command to new Nintex DB.
When I browse to Central Administration; via the Database Setup and then Manage database mappings page it still shows old database mapping against my site collection.
I am getting error while browsing pending tasks.
I can't change that mapping manually, do you have anyway to change mapping.
I had the same issue. I did the following steps
- Restarted the timer services on all the servers
- Restarted IIS web sites in web front ends
- Did IIS Reset on all the servers
After that I could see the existing workflow data moved to new Workflow DB and the mappings in the Central Administration are updated. Hope this helps.
Did anyone face the issue? i recently did the same steps in our PROD environment, but i got end up with the following issue.
"ExecuteReader requires an open and available Connection. The connection's current state is closed"
A support ticket is already opened for this. 00071882
Due to this we are unable to
- See the workflow history
- Start the new instances of the workflows
Any help is greatly appreciated.
Make sure that the 'App pool Account' has the role WSS_Content_Application_Pools assigned in the Database permissions for the newly created Nintex DB. Once that permission role is assigned, the workflow history started showing up and there are no more issues. Thanks to Chad, Austin from Nintex Support for noticing this issue.
Emily Billing, thanks for such great article!
But I wonder if we really need to do so much IIS restarts and stops of web apps?
Isn't it possible to prevent any changes to workflows and underlying data by stopping 'Workflows' timer job and switching source and target site collections to 'read-only' mode?
Egor Yudkin, I would answer yes and no. One thing to note is that even in Read-only mode, the timer jobs will still fire off and thus the Workflow timer service will continue to run. This means that paused workflows can be processed, or scheduled workflows could start. So for complete control of the migration, these are the optimal steps. Some steps can be different, but you will have to know the state of every workflow in the site.
Andrew Glasser, I've mentioned stopping (i.e. disabling) 'Workflow' timer job too in my previous comment. I thought it is the only way for workflow activities to start, please correct me if I wrong.
Nope you have it right, maybe I misread your response thinking you didn't want to stop the timer service.
The IIS restarts will help to remove any cache or instances of workflows in the app pools for the web applications.