Workflow Manager Disaster Recovery

Lately, few of our customers have faced issues in setting up Disaster Recovery for WorkFlow Manager. There’s a fairly comprehensive document on MSDN that outlines this process – https://msdn.microsoft.com/library/azure/jj730570(v=azure.10).aspx#DisasterRecovery

Steps in brief – (parameters for the cmdlets and cmdlet usage available in the link above)

1. Open an elevated PowerShell (RunAs Administrator) window on the new machine.
2. Run the Restore-SBFarm cmdlet. This cmdlet creates a new Service Bus Farm Management database.
3. Run the Restore-SBGateway cmdlet on one of the farm nodes.
4. Run the Update-SBHost cmdlet on all farm nodes.
5. For each container database, run the Restore-SBMessageContainer cmdlet. Run this cmdlet on one of the farm machines.
6. Run the Add-SBHost cmdlet.
7. Call the Restore-WFFarm cmdlet using the ResourceManagement and Instance Database connection strings.
8. Call the Add-WFHost cmdlet.

 However, there’s a pre-requisite before you start with the steps above (a step 0, if you will) - you need to export the Service Bus encryption certificate(s) from the old WFM/SB node and import them on each of the new WFM/SB servers. This would be located in the Local Computer\Personal store on the server.

There’s a second catch here – the import would only work if the old ServiceBus certificate on the old WFM/SB server(s) were either –

1) Auto-generated during the old farm configuration by the Configuration Tool.

2) OR,

In case you had used a custom certificate for ServiceBus in the old environment, it needs to be wildcard certificates for your domain, i.e., the “Subject Alternative Name” field in the certificate was created with a value like - *.mydomainname.com

If the old ServiceBus certificate import is not done, the Restore-WFFarm cmdlet would fail with a somewhat cryptic error –

Token provider returned message: '<Error><Code>400</Code><Detail>The namespace 'WorkflowDefaultNamespace' does not have a valid issuer that can be used to issue tokens. Add a valid issuer with a valid signature to the namespace.

After importing the old SB certificate(s), you need to run Restore-SBFarm (Step 2 above) with the FarmCertificateThumbprint and EncryptionCertificateThumbprint parameters specified explicitly (use the Thumbprint of the imported certificate) –

Restore-SBFarm -FarmCertificateThumbprint <String> -GatewayDBConnectionString <String> -SBFarmDBConnectionString <String> [-AdminApiCredentials <PSCredential> ] [-AdminGroup <String> ] [-AmqpPort <Int32> ] [-AmqpsPort <Int32> ] [-EncryptionCertificateThumbprint <String> ] [-FarmDns <String> ] [-Force] [-HttpsPort <Int32> ] [-InternalPortRangeStart <Int32> ] [-MessageBrokerPort <Int32> ] [-RPHttpsPort <Int32> ] [-RunAsAccount <String> ] [-TcpPort <Int32> ] [-TenantApiCredentials <PSCredential> ] [-Confirm] [-WhatIf] [ <CommonParameters>]

Note: If you had used custom wildcard certificates in the old ServiceBus configuration and had used two different certificates for FarmCertificate and EncryptionCertificate, you would have to import both of them on each new node and provide the FarmCertificateThumbprint and EncryptionCertificateThumbprint parameters in the above cmdlet accordingly.

Here are the new steps:

1. Export both the root certificate with private key and the server certificate with private key. Import both into the Personal folder of the new server. Also import the root certificate into the Trusted Root Authority folder of the new server.
2. Open an elevated PowerShell (RunAs Administrator) window on the new machine.
3. Run the Restore-SBFarm cmdlet. This cmdlet creates a new Service Bus Farm Management database. 

Restore-SBFarm -RunAsAccount 'farm\test' -FarmCertificateThumbprint 41FED42EC87EA556FB64A41572111B96D13FBFC2 -GatewayDBConnectionString 'Data Source=DBServer;Initial Catalog=SbGatewayDatabase;Integrated Security=True;Encrypt=False' -SBFarmDBConnectionString 'Data Source= DBServer;Initial Catalog=SbManagementDB;Integrated Security=True;Encrypt=False' -AdminGroup 'BUILTIN\Administrators' -EncryptionCertificateThumbprint41FED42EC87EA556FB64A41572111B96D13FBFC2

       4. Run the Restore-SBGateway cmdlet on one of the farm nodes.

 Restore-SBGateway -GatewayDBConnectionString 'Data Source= DBServer;Initial Catalog=SbGatewayDatabase;Integrated Security=True;Encrypt=False' -SBFarmDBConnectionString 'Data Source= DBServer;Initial Catalog=SbManagementDB;Integrated Security=True;Encrypt=False'          
        5. For each container database, run the Restore-SBMessageContainer cmdlet. Run this cmdlet on one of the farm machines. 

Restore-SBMessageContainer -ContainerDBConnectionString "Data Source= DBServer;Initial Catalog=SBMessageContainer01;Integrated Security=SSPI;Asynchronous Processing=True" -SBFarmDBConnectionString 'Data Source= DBServer;Initial Catalog=SbManagementDB;Integrated Security=True;Encrypt=False' –id 1

       6. Run the Add-SBHost cmdlet. 

$myPassword=convertto-securestring 'ereee' -asplaintext -force 

Add-SBHost -EnableFirewallRules $TRUE -RunAsPassword $myPassword -SBFarmDBConnectionString 'Data Source= DBServer;Initial Catalog=SbManagementDB;Integrated Security=True;Encrypt=False'

       7. Call the Restore-WFFarm cmdlet using the ResourceManagement and Instance Database connection strings. 

$mykey=convertto-securestring 'etwegff' -asplaintext -force

Restore-WFFarm -RunAsAccount 'farm\test' -InstanceDBConnectionString 'Data Source= DBServer;Initial Catalog=WFInstanceManagementDB;Integrated Security=True;Asynchronous Processing=True;Encrypt=False' -ResourceDBConnectionString 'Data Source= DBServer;Initial Catalog=WFResourceManagementDB;Integrated Security=True;Asynchronous Processing=True;Encrypt=False' -WFFarmDBConnectionString 'Data Source= DBServer;Initial Catalog=WFManagementDB;Integrated Security=True;Encrypt=False' -InstanceStateSyncTime 'Sunday, May 11, 2014 12:30:00 PM' -ConsistencyVerifierLogPath 'c:\log.txt' -CertificateAutoGenerationKey $myKey

       8. Call the Add-WFHost cmdlet.

Add-WFHost -WFFarmDBConnectionString 'Data Source= DBServer;Initial Catalog=WFManagementDB;Integrated Security=True;Asynchronous Processing=True;Encrypt=False' -RunAsPassword $myPassword -EnableFirewallRules $TRUE -CertificateAutoGenerationKey $myKey
 

 Written By
Arindam Paul Roy

Reviewed By
Xuehong Gan

Microsoft GTSC

• Anonymous
  September 30, 2014
  The comment has been removed
  • Anonymous
    October 20, 2016
    The comment has been removed
• Anonymous
  October 02, 2014
  The comment has been removed
• Anonymous
  October 28, 2014
  The comment has been removed
• Anonymous
  October 29, 2014
  Nevermind, run: Get-SBNamespace on the old server to retrieve the original key
• Anonymous
  November 30, 2014
  Restore-WFFarm  is giving me error : the remote server returned an error 401 unauthorized, manage Claim is required for this operation
• Anonymous
  May 26, 2015
  I get same error that "John Naguib". Any resolution for it. I´m not apple to resolve it yet :( "Restore-WFFarm  is giving me error : the remote server returned an error 401 unauthorized, manage Claim is required for this operation..."