Workflow Manager Server is a technology that is used to host high-scale, high-density workflows. It allows you to develop workflows as declarative model. In other words, there is no code in the workflows to be developed, only their declarations. It is aimed to apply business logic to the flow by communicating with the background systems over the services. It is built on Microsoft .Net Framework 4.5 and Windows Workflow Foundation.
The general use of Workflow Manager is running SharePoint Workflows on Microsoft SharePoint Server. Although Workflow Manager is not a technology created for SharePoint, it is mainly used with SharePoint product.
It works in Farm topology. So, just like SharePoint or Exchange Server farms, you perform a farm configuration after the initial server setup. Then, you can add servers to this farm that you created by installing applications on new servers. If we talk about SharePoint specific, you can also install directly on servers that have SharePoint Server installed without a separate server. (Not recommended, however)
After a brief summary about Workflow Manager, I would like to come to the main issue I want to address in this article. As with all server applications, you may want to move Workflow Manager to a different environment over the server that it is currently configured. Your reasons may be one of the following;
After the difficulties experienced in the current environment, you could not be able to make in-place corrections and you want to re-install.
After an architectural decision, you may want to install Workflow Manager as a separate farm.
After a disaster scenario, you may only have up-to-date Workflow Manager databases and want to continue your work with a new configuration.
You may want to renew the configuration due to infrastructure operations such as Windows upgrade, domain upgrade / change etc. in the installed environment.
It is possible to increase these reasons. Basically, re-installing and configuring an application does not seem like a serious problem. However, when it comes to a structure like Workflow Manager, one of the important issue is business continuity. You can have dozens of workflows that have been deployed on their existing setup, and thousands of instances of these workflows associated with SharePoint lists and libraries. Of course, you will not want to re-deploy all of your workflows, nor to lose the ongoing instances and restart them. At this point, it is significant to configure a healthy environment and to ensure that the existing farm works with ongoing instances of this environment.
To perform this process, we first need to define our prerequisites.
You should make sure that the authentication mechanism of your new environment is the same with the environment integrated to SharePoint farm you will use.
You should get the primary symmetric key used in the existing Workflow Manager Farm and save it to use during the process. You can use the following command for this process.
Get-SBNamespace -Name WorkflowDefaultNamespace
You must have backed up the databases used in the Workflow Manager farm configuration. Normally there are management databases for Service Bus and Workflow Manager, but we do not need a backup of them, because we will make this configuration from scratch in the new farm. For this reason, it is sufficient to back up only the databases below.
1- Service Bus Gateway database
2- Service Bus Message Container database
3- Workflow Manager Instance database
4- Workflow Manager Resource Manager database
Of course, the information about the service account with which you have configured your current Workflow Manager farm.
After completing our prerequisites, let’s try to summarize the process steps and then end the process we will do through scripts. Our process steps;
Installing Workflow Manager on all servers that we will use in our new Workflow Manager farm. (Via Windows Platform Installer)
Restoring the Service Bus and Workflow Manager databases that I have referenced above, which we have previously backed up on the SQL Server you are using.
Ensuring that the new Workflow Manager farm works with existing data (workflows and ongoing instances) by running the following commands.
All the commands we will run will be via Microsoft PowerShell, and it is important that you did not do the farm configuration operations via the visual setup interface of the Workflow Manager before running these commands. You must open the PowerShell console in “Run as Administrator” mode.
Adding Workflow Manager module to PowerShell
First, we restore the Service Bus farm. While doing this operation, Service Bus Gateway database (SbGatewayDatabase) and Service Bus Message Container database (SBMessageContainer01) in the old environment that we previously backed up will be used. We will create the Service Bus management database (SbManagementDBNEW) via the command.
Service Bus is ready. Now we can proceed to restore Workflow Manager farm. During this process, the old environment Workflow Manager Instance database (WFInstanceManagementDB) and Workflow Manager Resource Manager database (WFResourceManagementDB) that we previously backed up will be used. We will also create the Workflow Manager Management database (WFManagementDBNEW) from the code.
After the restore process is completed, we also restore the “PrimarySymmetricKey” that we previously noted for WorkflowDefaultNamespace and set the SBClientConfiguration to use WorkflowDefaultNamespace. You can also set up authorized users for WorkflowDefaultNamespace here.
With the commands we have run so far, we have restored the Service Bus and Workflow Manager farms with their old configurations and contents. You can confirm that the farm is working properly by running the following commands. All our services should be in “Running” mode and we should see that the farm configuration is successful in the output we receive with * Status commands as in the examples below.
If everything is fine, we can now connect our existing SharePoint site collection and the new Workflow Manager farm with the Register-SPWorkflowService command.