Share via


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

  1. Perform a full uninstall of Workflow Manager 1.0 from the farm server hosting it.

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

  3. Using the SharePoint Setup User Administrator account, login to the farm server that will be used to host Workflow Manager 1.0.

  4. Install Workflow Manager 1.0.

  5. Logout

  6. Using the SharePoint Setup User Administrator account, login to a farm WFE.

  7. Install Workflow Manager 1.0 Clients

  8. Repeat steps 5 and 6 for each farm WFE.

  9. Using the SharePoint Setup User Administrator account, login to the farm server on which you installed Workflow Manager 1.0.

  10. Configure Workflow Manager 1.0:

  11. Open an elevated SharePoint Management Shell.

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

  13. Logout.

  14. Using the SharePoint Setup User Administrator account, launch SharePoint Designer 2013.

  15. Open the site containing the 2013 workflows you want to restore.

  16. In the left Navigation panel, select Workflows.

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

  18. Up on the WORKFLOWS ribbon, in the Save group, click Publish.

  19. Repeat steps 15 - 18 for each 2013 workflow you want to restore.

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

  21. Log into the application server hosting Workflow Manager 1.0 using an administrator account (any will do).

  22. Perform an IIS Reset.

References

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.