Back Up and Restore List with Retention of Workflow Status on SharePoint 2010 Site

Question

I have a list in SharePoint 2010 web site with a simple workflow to test the possibility of back-up and restore of the list while retaining the status of work flow.

The list currently has only ID and Title to be kept as simple as possible and the workflow also has only one task in it which sends an email and waits indefinitely after the email. The workflow was written by Visual Studio 2010 based on the State Machine Workflow template.

I used following commands to perform back-up and restoration.

1. Export-SPWeb -identity http://testserver/sites/AnhamDev -itemurl Lists/Test%20List -path "C:\spbackup\TestList.cmp" -force
2. Import-SPWeb -identity http://testserver/sites/AnhamDev -path "C:\spbackup\TestList.cmp"

I deleted all rows from the list before starting the restoration step. There is no error while running the back-up and restoration and all data were restored successfully.

The problem is that the workflow is always restored as "Completed" after the restoration is finished. Since I designed the workflow waits indefinitely, the workflow status is supposed to be "In Progress" at all times. During the restoration, there are no emails sent out, either and that sort of gives me an impression that the workflow was never run but somehow reached its "Completed" status.

I created the same workflow by Visual Studio 2010 using Sequential Workflow template but the result was the same.

However, when I designed the same workflow using SharePoint Designer 2010, the Workflow was run during the restoration and was restored back to where it was which was "In Progress."

Could anybody tell me why my list can't be properly restored with a workflow designed by Visual Studio 2010?

Answer 1

Export-SPWeb doesn't export workflows. I'm surprised you get back those created with SharePoint Designer. Probably Mike's reference explains that.

I've tested site backup/restore and web export/import with focus on running workflows (created with Visual Studio), version history and auditing. You can find my test results here

Here are some results from Import-SPWeb test, shortly:

1)Importing in the same location

• Import operation does not import the workflows (as expected, because they don’t get exported with Export-SPWeb).
• Import does not affect the currently running workflows but import of the document versions fails for those documents with running workflow.
• Versions are correctly imported only for document with no workflows in running state when importing.
• Audit events are not affected by the import, so all events are retained including those registered between export and import

2)Import in another sub site

• All running workflows are lost
• All custom site properties and custom item properties are lost (properties in SPWeb.Properties and SPItem.Properties hashtables)
• All workflow associations are lost
• Document versions are imported successfully
• Audit events are lost
• Workflow tasks are lost

Answer 2

My guess is the three locations where custom VS workflows stores files were not backed up, and when you deleted the rows, it modified/deleted the files in these folders.

Backing up workflows in SharePoint

Workflows are a special case of customizations that you can back up. Make sure that your backup and recovery plan addresses any of the following scenarios that apply to your environment: • Declarative workflows, such as those created in Microsoft SharePoint Designer 2010, are stored in the content database for the site collection to which they are deployed. Backing up the content database protects these workflows.

• Custom declarative workflow actions have components in the following three locations:

1. The Visual Studio 2010 assemblies for the actions are stored in the global assembly cache (GAC).

2. The XML definition files (.ACTIONS files) are stored in the 14\TEMPLATE\\Workflow directory.

3. An XML entry to mark the action as an authorized type is stored in the Web.config file for the Web applications in which it is used.

If the farm workflows use custom actions, you should use a file backup system to protect these files and XML entries. Similar to SharePoint Server features such as Web Parts and event receivers, these files should be reapplied to the farm as needed after recovery.

• Workflows that depend on custom code, such as those that are created by using Visual Studio 2010, are stored in two locations. The Visual Studio 2010 assemblies for the workflow are stored in the GAC, and the XML definition files are stored in the Features directory. This is the same as other types of SharePoint Server features such as Web Parts and event receivers. If the workflow was installed as part of a solution package, backing up the farm, Web application, content database, or site collection protects these workflows.

• If you create a custom workflow that interacts with a site collection other than the one where the workflow is deployed, you must back up both site collections to protect the workflow. This includes workflows that write to a history list or other custom list in another site collection. Performing a farm backup is sufficient to back up all site collections in the farm and all workflows that are associated with them.

• Workflows that are not yet deployed must be backed up and restored separately. When you are developing a new workflow but have not yet deployed it to the SharePoint Server farm, make sure that you back up the folder where you store the workflow project files by a file system backup application.

Source: http://technet.microsoft.com/en-us/library/ee748642(v=office.14).aspx#Workflows