MoveData

Description

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. 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.

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).

Retaining the source content database

After the data is moved, the source content database must remain in place until the redirects added by the MoveData operation have been cleaned up. To clean up redirects, use the CleanTaskDirects operation. After redirects are cleaned up and you are certain that no site collection is using the source content database, you can remove the source content database.

Use in migration scenarios and external databases

In some scenarios, it will be useful to move data to a Nintex Workflow database not connected to the SharePoint farm. For example if a site collection backup and restore is performed to move an entire site collection to a different farm, it is useful to be able to push Nintex Workflow data directly into the target farm. Likewise, there will be scenarios where it is useful to pull Nintex Workflow data from another farm into the current farm.

In this scenario, the details of an external database can be provided via the command line options. The user running the command must be in the WSS_Content_Application_Pools group on the external database to have permissions to read or write the data.

A limitation with external databases is workflows in progress at the time of the MoveData command cannot accept a LazyApproval response. Workflow tasks can still be completed via the SharePoint UI. New task actions that assign their tasks after the move data command can still use LazyApproval.

Note: It is recommended the workflow job in Central Administration is stopped in the target environment when a site collection migration with workflow is performed. If a workflow wakes up from a delay before the data has been imported, that workflow will fail. Stopping the workflow timer job will prevent workflows from executing.

When an external database is used, the notes under “Retaining the source database” above do not apply as the source database is not connected to the target farm.

When data has been pushed to an external database, the ‘Storage’ table in the Nintex Workflow configuration database for the target farm will need to be manually updated to link the target site collection with the correct content database. The ‘Storage’ table lists site collection IDs and the Nintex Workflow database ID to determine the database that the site collection will use. The IDs for the databases connected to the environment can be retrieved from ‘Databases’ table in the Nintex Workflow configuration database.

Changing the Site Collection ID

In migration scenarios, the ID of the site collection can change. For example, if a site collection is backed up from one farm and restored to another, it will be assigned a new site collection ID. Nintex Workflow application pages and workflow instances use the site collection ID to find data in the Nintex Workflow content database. If the site collection ID changes, and the records in the database are using an out of date ID, the data for a workflow will not be found.

In this case, the MoveData command allows the new site collection ID to be provided as part of the command. When data is written into the target database, it can be written with a new site collection ID, allowing the product to find the data when accessed from the restored site collection.

Usage

NWAdmin.exe -o MoveData [-Url <siteCollectionUrl> | -SiteID <site collection GUID>] [-SourceDatabase <connection string>] [-TargetDatabase <connection string>] [-NewSiteID <target site collection GUID>] [-RetainSourceData]

Parameters