Looking for Nintex for SharePoint 2016 guidance? See the following link.
This article provides guidance on data management procedures for Nintex Workflow (2013 and 2010), specifically backup and restore functions that are compatible with SharePoint’s own framework and processes. The target audience are system administrators of SharePoint and Nintex Workflow. See also Database Design Guide: Nintex Workflow.
The following backup and restore methods are supported for Nintex Workflow 2013 and Nintex Workflow 2010.
Note: Promoting subsites to site collections is not supported as it can result in missing or corrupt content types or other issues.
Nintex Workflow provides the ability to design SharePoint declarative workflows via a browser-based design surface. Once a Nintex workflow is published, SharePoint treats the workflow no differently to workflows created by SharePoint designer, and as such, the SharePoint content database is responsible for storing and persisting data associated with a given workflow instance as it transitions through its lifecycle. Workflow data managed by SharePoint encompasses workflow history items, workflow tasks, workflow state management and, importantly, the workflow association and definition is also stored and managed by SharePoint. All of this aforementioned data is associated with a single SharePoint content database.
Ancillary to the data SharePoint maintains for a workflow, the Nintex Workflow content database stores additional workflow logging and tracking data to allow for more advanced workflow reporting. This database is also used to keep track of workflow action and task states in a way that can be reported on by Nintex Workflow. The Nintex Workflow configuration database stores settings such as which activities are allowed on which sites, workflow constants, workflow schedule definitions, message templates and the global settings found in Central Administration.
In a default installation, the Nintex Workflow configuration database also acts as the first content database, therefore the configuration database also contains the schema for a workflow content database.
Nintex databases are not directly linked to the SharePoint content databases; however, all of the workflow tracking data for a particular site collection can be found in a single Nintex Workflow content database. You can set up SharePoint content database to Nintex Workflow database mappings pro-actively via SharePoint Central Administration to enable informed backup and restore decisions. When backing up a SharePoint content database, the corresponding Nintex Workflow content should also be backed up at the same point in time. When restoring a SharePoint content database, the Nintex
Workflow content database backup from the same point in time should also be restored to ensure consistency between the workflow state (SharePoint database) and the logging/tracking data (Nintex Workflow database).
For guidance on planning database mapping and maintenance, see Database Design Guide: Nintex Workflow. In many cases we recommend mapping each Nintex Workflow content database to a SharePoint content database (1-to-1 mapping). For greater granularity, as with SharePoint, provision different site collections in different content databases (as required).
For instructions on how to implement a 1-to-1 mapping for an existing site collection already utilizing Nintex Workflow, see Splitting existing SharePoint and Nintex Content Databases.
The supported ‘full fidelity’ backup and restore method, of both SharePoint Workflow data and Nintex Workflow data, needs to be performed as SQL database backups using SQL server.
In an environment that has databases that are managed by DBAs, the strategy employed is based on the following:
Backup using a SQL maintenance plan. Ensure SharePoint content databases and Nintex Workflow databases are backed up together and that you have full transaction logs to enable restoration at any point in time.
Individual SharePoint Content Database & Nintex Workflow database restoration process
Full (catastrophic) DR high-level process
Restoring SharePoint site collections via the PowerShell backup/restore commands has several implications with respect to associated Nintex Workflow state and meta-data. Two scenarios are covered below, detailing an In-Place restore; a site collection is restored in the same location that it already exists in, and an Out-of-place restore; a site collection is restored to a different location within the same SharePoint Farm
An in-place restore is when the site collection orignally exported is restored over the original site, effectively restoring to a previous version.
An out-of-place restore is when the exported site collection is restored to a different location, thus making a copy of the site.
Restoring SharePoint sites (team sites, also called webs) via the Export-SPWeb/Import-SPWeb commands has several implications with respect to associated Nintex Workflow state and meta-data. Two scenarios are covered below, detailing an In-Place Import; a Site or group of Sites is restored in the same location that they already exist in, and an Out-of-place Import; a Site or Group of Sites is restored to a different location within the same SharePoint Farm.
1. Run the command NWAdmin.exe -o PrepareSiteForExport -siteUrl urlToSiteToPrepare, before executing Export-SPWeb on your Site(s).
2. Run the command NWAdmin.exe -o FixSiteAfterImport -siteUrl urlToSiteThatWasImported, after executing Import-SPWeb on your Site(s).
Performing the above steps will ensure referential integrity of the Workflow to all SharePoint objects within the workflow definition. Specifically, the Import-SPWeb process generates new GUIDs for all SharePoint objects: Sites, Webs, Lists, ListItems. In order to remap the imported workflows to the newly generated GUIDs, we provide the preparesiteforexport fixsiteafterimport to work around this issue.
When configuring the association of a SharePoint Content Database to a different Nintex Workflow Content Database, the effects in relation to site collections are:
Existing site collections continue to use the previously mapped NW Content Database by design, as any previous workflow data is not migrated across when re-configuring the database mapping.
Refer to Scenario 1 to move existing workflow data and set the existing site collection to use the new NW content database.
Refer to Scenario 2 if you don’t have any existing workflow data in the parent site collection that the (out-of-place) site is to be migrated into.
In the situation where you require existing site collection workflow data to be moved to the new NW Content Database, and any new instances of workflows within the site collection to also utilize the new NW Content Database, you will need to run the NWAdmin –o moveData command to both move the existing workflow data, and to reconfigure this specific site collection against the new NW Content Database.
Refer to NWAdmin Operations - Nintex Workflow 2013 for further details on what you must do when running the moveData command.
After which, perform an IISReset to refresh any mapping records that are cached. At this point, you can perform your import of the site.
If you are not concerned with the existing site collection workflow data, to associate an imported site with the new Nintex Workflow Content Database:
Solved! Go to Solution.
What is the difference between "In-Place Import" and "Out-of-Place Import"?
Is it not possible to restore (Import) a Backup to two different Site Collections and run the fixsiteafterimport command on both?
Scenario: Creating a Project Template Site Collection with Nintex Workflows.
Export with preparesiteforexport.
Create two or more project site collections.
Import the Site Backup to the project site collections.
Run fixsiteafterimport on the project sites.
Surely this scenario has come up before, what is the best way to solve this?
In the context of this article, in-place is when the site originally exported is restored over the original site, effectively restoring to a previous version. Out of place is when the export is restored to a different location effectively making a copy of the site
You can import to as many locations as you want, and run fixsiteafterimport for each one.
All fixsiteafterimport does is this: When the site is imported, all the List IDs change to new values. So, preparesiteforexport trawls the site, takes note of all the list names and their IDS. You do the export and import, and then fixsiteafterimport goes through the newly imported site, determines a mapping between old and new list IDs, and updates all the workflow definitions to use the new IDs. Result, workflows previously saved will open correctly.
Really informative article, thank you!
I have a few questions. We like the portability of site collections in SharePoint. We manage the database size easily by moving site collections from one content database to another. Also, we promote site collections from development to test or production using the SharePoint backup/restore process for site collections. A few powershell commands and the site collection is moved, very easily and gracefully.
Is there a way to move the Nintex data from the Nintex database for a single site collection? The information in this article talks about restoring the entire Nintex database, but we have multiple site collections in both the content database and the NIntex database. If we only want to restore one site collection, what is the recommended set up and procedure? It sounds like we have to have each site collection that uses Nintex in its own content database and its own nintex database. Please tell me I am wrong.
Search on community for NWAdmin guide, and read about the MoveData command. This allows you to move data for a site collection between databases. You could use this to set up having one content database per site collection.
This is the only way to allow restore of a single site collection.
Hope this helps
Please could someone let me know if we have a sharepoint list with Nintex workflow attached, when we do a granular SharePoint restore how do we restore the workflows back to that list?
The most granular you can get with a backup and restore is to the site-collection level. You can't target a specific list since we can't save to a database that contains less content than an entire site collection, associated to a SharePoint Content database.
What about export / import commands for moving between farms? Will this work?
Please note we don't want to restore the Nintex entire workflow db, just move sites which happen to have workflows.
Which migration process is supported between different environments/farms?
Can someone just use export/import with nwadmin?
We have tried nwadmin and we are experiencing strange behaviours in our target environment. Sometime nintex forms show up and sometimes an expected error like the following arises:
Application error when access /groups/nintex_test_18/Lists/Workflowaufgaben/EditForm.aspx, Error=Value cannot be null. Parameter name: s
Any help would be appreciated!