SharePoint 2013: how to restore Workflow Manager 1.0 workflows in the event of a disaster
Introduction
This posting consolidates notes and experience in restoring Workflow Manager 1.0 workflows from content database backups. It does not engage recovering workflow transactional history, but focuses strictly on recovering the workflows created on this platform in the event of a complete failure of the server hosting Workflow Manager 1.0 or some other problem that results in the total loss of the Workflow Manager 1.0 system. This posting assumes a farm situated on the corporate intranet; and it assumes authentication over HTTP.
Procedure
Perform a full uninstall of Workflow Manager 1.0 from the farm server hosting it.
Verify that the SharePoint Setup User Administrator, SQL Server and Farm Service accounts have Active Directory Read permission to the service account that will be used to run Workflow.
Using the SharePoint Setup User Administrator account, login to the farm server that will be used to host Workflow Manager 1.0.
Install Workflow Manager 1.0.
Logout
Using the SharePoint Setup User Administrator account, login to a farm WFE.
Install Workflow Manager 1.0 Clients
Repeat steps 5 and 6 for each farm WFE.
Using the SharePoint Setup User Administrator account, login to the farm server on which you installed Workflow Manager 1.0.
Configure Workflow Manager 1.0:
- Using the Configuration Wizard: Configuring Workflow Manager 1.0 using Configuration Wizard.
- Using PowerShell: Configuring Workflow Manager 1.0 using PowerShell.
Open an elevated SharePoint Management Shell.
Execute the following command:
Register-SPWorkflowService -SPSite 'http://myfarm.domain.com/' -WorkflowHostUri 'http://workflowhost:12991' -AllowOAuthHttp -Force
where myfarm.domain.com is the fully qualified domain name of your web application and workflowhost is the name of the server hosting Workflow Manager 1.0. Note that in this case authentication is occurring over HTTP and not HTTPS.
Logout.
Using the SharePoint Setup User Administrator account, launch SharePoint Designer 2013.
Open the site containing the 2013 workflows you want to restore.
In the left Navigation panel, select Workflows.
In the right response panel, under List Workflow, click on the desired 2013 workflow.
Note: if you experience an error at this point, that indicates the workflow could not be opened and to close Designer and re-open Designer, do exactly what the prompt is directing you to do: close Designer, restart it, and again open the site.
Up on the WORKFLOWS ribbon, in the Save group, click Publish.
Repeat steps 15 - 18 for each 2013 workflow you want to restore.
Verify by opening a browser, navigating to the list or library the workflow is attached to, Selecting the LIST tab on the ribbon, and then clicking the Workflow Settings button in the Settings group on the ribbon: the 2013 workflows should be listed.
Log into the application server hosting Workflow Manager 1.0 using an administrator account (any will do).
Perform an IIS Reset.
References
- Installing and Configuring Workflow Manager 1.0
- Understanding SharePoint 2013 Workflow Backup
- Disaster Recovery and Scope Restore in Workflow Manager 1.0
- SharePoint 2013: How to Restore Content Databases
- Get-SBFarm
- Workflow Manager: This takes you to the top-level of MSDN's Workflow Manager library.
- Register-SPWorkflowService
- Error while publishing the workflow in Sharepoint designer 2013
- Workflow Manager Farms for SharePoint 2013 Part One: Core Concepts, High Availability, Certificate and SharePoint considerations
- SharePoint 2013 Workflow: Token contains invalid signature
Notes
- Versions: Workflow Manager 1.0 (no CU); Service Bus 1.0 (no CU).
- The actual 2013 workflows themselves are stored in the web application content databases. Therefore, to restore them after the loss of the Workflow Manager framework system, you first need to rebuild the Workflow Manager system, re-attached it to SharePoint, and then re-publish the workflows.
- If the 2013 workflows were written using the 32-bit version of SharePoint Designer 2013, then be sure to use the 32-bit version when attempting to re-publish them after a restore operation. This recommendation is contrary to the direction we have received from Microsoft Support with respect to Workflow recovery efforts. I have found from experience that using the 64-bit version to restore workflows developed using the 32-bit version resulted in errors.
- UPDATE 05/04/15: whilst performing the most recent content refresh for a development farm, and as part of this, restoring workflows, I experienced an error during the Publish step: IMAGE I could not resolve this issue. Interestingly enough, it resolved itself after about a week. A colleague believes it involves configuration caching and that another step to perform after restoring content from another farm is to perform an IIS reset. I will be implementing this step at the next refresh coming up after patch Tuesday.
- UPDATE 06/04/15: continuing the previous update: performing an IIS reset indeed resolved the problem.
- This procedure is also valid for SharePoint 2016.