Move Workflow Manager to new farm in a new domain

Question

We currently have a SharePoint 2013 farm including Workflow Manager (SharePoint 2013 Workflow).

We are planning to move the users to a new domain which means we need to recreate the farm in the new domain.

My worries are Workflow Manager and related SharePoint 2013 workflows. How can we move Workflow Manager from one farm to another? Note that this is also cross domain.

Answer 1

The critical component when failing over a Workflow Farm to a New SharePoint Farm (In the same domain or otherwise) is that the new SharePoint Farm must have the same Realm as the original one. Realm is by default identical to the SharePoint Farm ID, but can be changed using Set-SPAuthenticationRealm -Realm FarmIDoftheOriginalFarm.

Few Caveats:

• You will need the Service Bus Primary Symmetric Key to be identical. http://www.wictorwilen.se/workflow-manager-disaster-recovery-%E2%80%93-preparations

• You will need to set the permissions manually on the service Bus Name Space: ManageUsers to the new accounts, including the new setup account, https://msdn.microsoft.com/en-us/library/jj248750%28v=azure.10%29.aspx

• You must re-run Register-SPWorkflowService again on the destination farm with the same scope name that you originally used, e.g. ScopeName. That will correct the "Client Permissions" on Security Settings for the ScopeName/Default child scope.

With this note, along with 4 Workflow & Service bus databases backup (excluded the Service Bus Management and Workflow Management databases) and the 2 certificates used for Service bus and the instructions at http://social.technet.microsoft.com/wiki/contents/articles/29158.workflow-manager-disaster-recovery.aspx (I have several Comments at the end of this article most of which are incorporated now in this response), you should have enough information to recover your farm.

You can recover the Workflow Farm with entire new set of credentials that are defined during Restore-SBFarm, Add-SBHost, Set-SBNameSpace -ManageUsers, Restore-WFFarm and ADD-WFFarm.

You should also backup and restore the App Management Service Application database in the new farm, grant it necessary SQL permissions and create the service in the destination in the new SharePoint Farm.

Here's why Workflow Manager and SharePoint will still work even in a different domain: App Management table dbo.AM_Principals column:CompositePartitionKey (decoded from Hex to String) has an entry created for Each SPweb that has at least 1 designer 2013 workflow. The entry is created in the form of ((get-spweb WebURL -Site SiteURL).id)@(Get-SPAuthenticationRealm). Web ID (Its Guid) is also used as the deepest child scope name in Workflow Manager. So, WebID and RealmID are the ones that needs to be identical for SharePoint to be able to relate to workflow information/history published in Workflow Manager. Obviously WebID will never change in your move to another domain and you can set RealmID.

Also if you dive on how the Child scopes to ScopeName/Default on Workflow manager is defined, it is always in the format of (Get-SpSite URL of site collection).id/(Get-SPweb -Site SiteURL -Web WebURL).id . This naming convention make scope names consistent even if you moved content databases around, moved a site collection to another web application or even to another farm.

So service account credentials do not play any role in the Security between Workflow and SharePoint. Your changed domain will obviously impact the users in SharePoint, but there is enough body of knowledge on this topic. Best of which is described by Todd Klindt blog.

Final Note: Workflow Manager implementation follows strictly High trust Apps Model and the security is granted to Workflow Manager by merit of an X509 Certificate. Its configuration is just being made easier via the Register-SPWorkflowService special Cmdlet.

Answer 2

Haven't come across such requirement but I would try the steps given @ http://blogs.technet.com/b/sushrao/archive/2011/12/02/sharepoint-migrating-sharepoint-server-from-one-domain-to-another.aspx

Note: the article is old and it tells you to use "stsadm -o migrateuser" for updating users, instead you should use move-SPUser cmdlet.

Update:

Summary of steps:

1. Note down all service accounts and app pool accounts, change them to "Network Service"
2. Change domain of all servers
3. Add service accounts from new domain to appropriate groups like Local Administrator, WSS_WPG, WSS_ADMIN etc
4. Give appropriate permissions on SQL DB for new service accounts
5. Change service accounts and app pool accounts to use new service accounts
6. Use Move-SPUser to update user profiles (after all user IDs are migrated to new domain)