none
Migrate Biztalk server to another domain RRS feed

  • Question

  • Hi,

    We are using Biztalk in our company. It is hosted in a virtual machine. Right now, we're planing to move all our server to a new data center, new domain. Can anyone advise whether is this possible to just clone the VM to new data center, change the domain, create corresponding service accounts and just reconfigure it? Or do we need to re-install Biztalk from scratch?

    Tuesday, November 24, 2015 2:27 AM

Answers

  • Your best course of action, and the one which will give you the fewest if any problems is to stage a new BizTalk Server VM in your new domain and migrate the apps.

    If the BizTalk installation uses all local accounts, meaning local to the VM and SQL Server is also installed locally, then you might be able to change the domain membership without problems.  If you are using any domain resources, accounts, groups, etc, then no, you cannot change the domain of the computer.

    Also, you cannot clone a configured BizTalk computer.  It is not a supported operation and it will not work.  There is no way around this other than un-configuring and re-configuring, which is essentially the same as staging a new VM.
    • Edited by Johns-305MVP, Moderator Tuesday, November 24, 2015 1:48 PM
    • Proposed as answer by Angie Xu Thursday, December 3, 2015 2:42 AM
    • Marked as answer by Angie Xu Thursday, December 3, 2015 2:43 AM
    Tuesday, November 24, 2015 2:52 AM
    Moderator
  • I concur with John, the easiest, quickest course of action would be to setup a fresh BizTalk environment in the new domain and migrate the applications. If you're using certificates you would need to procure a fresh set for the new FQDN, etc.

    However, if you're still forced to migrate then here are a few steps/thoughts on how.

    1. Get certificates for the new domain.
    2. Establish a TWO-WAY trust between the TWO domains.
    3. Move the servers into the new domain - after move remember to setup the computer accounts/trusts. Run the server change script (part of the DR strategy when pointing to new servers).
    4. You would need to deploy the new domain level certificates at this stage.
    5. Now create the BizTalk Accounts in the new domain.
    6. Give them membership to the domain groups in the old domain (this is what the TWO-WAY trust would enable you to do).
    7. Change the service accounts for all the BizTalk Services [Host Instances, Rules, IIS App Pools, SSO] to the new domain account - refer https://msdn.microsoft.com/en-us/library/aa561505.aspx
    8. Do the same for SQL and Analysis Service accounts.
    9. Now create the groups in the new AD Domain and add the accounts. Replicate these group and db level permissions in SQL and in BizTalk Host Configuration.

    Step 9 is something that has the highest chance of breaking something within BizTalk and making you regret not having setup a fresh environment. Needless to say, it would best be simulated on a Test/Pilot environment before even touching the production setup.

    If there are compulsions that require you to migrate across domains (as opposed to fresh setup in the new domain) then I'd strongly urge you open a case with Microsoft PSS and take their help for the activity.

    Regards.



    • Edited by Shankycheil Tuesday, November 24, 2015 5:24 AM edit
    • Marked as answer by Angie Xu Thursday, December 3, 2015 2:43 AM
    Tuesday, November 24, 2015 4:54 AM

All replies

  • Your best course of action, and the one which will give you the fewest if any problems is to stage a new BizTalk Server VM in your new domain and migrate the apps.

    If the BizTalk installation uses all local accounts, meaning local to the VM and SQL Server is also installed locally, then you might be able to change the domain membership without problems.  If you are using any domain resources, accounts, groups, etc, then no, you cannot change the domain of the computer.

    Also, you cannot clone a configured BizTalk computer.  It is not a supported operation and it will not work.  There is no way around this other than un-configuring and re-configuring, which is essentially the same as staging a new VM.
    • Edited by Johns-305MVP, Moderator Tuesday, November 24, 2015 1:48 PM
    • Proposed as answer by Angie Xu Thursday, December 3, 2015 2:42 AM
    • Marked as answer by Angie Xu Thursday, December 3, 2015 2:43 AM
    Tuesday, November 24, 2015 2:52 AM
    Moderator
  • I concur with John, the easiest, quickest course of action would be to setup a fresh BizTalk environment in the new domain and migrate the applications. If you're using certificates you would need to procure a fresh set for the new FQDN, etc.

    However, if you're still forced to migrate then here are a few steps/thoughts on how.

    1. Get certificates for the new domain.
    2. Establish a TWO-WAY trust between the TWO domains.
    3. Move the servers into the new domain - after move remember to setup the computer accounts/trusts. Run the server change script (part of the DR strategy when pointing to new servers).
    4. You would need to deploy the new domain level certificates at this stage.
    5. Now create the BizTalk Accounts in the new domain.
    6. Give them membership to the domain groups in the old domain (this is what the TWO-WAY trust would enable you to do).
    7. Change the service accounts for all the BizTalk Services [Host Instances, Rules, IIS App Pools, SSO] to the new domain account - refer https://msdn.microsoft.com/en-us/library/aa561505.aspx
    8. Do the same for SQL and Analysis Service accounts.
    9. Now create the groups in the new AD Domain and add the accounts. Replicate these group and db level permissions in SQL and in BizTalk Host Configuration.

    Step 9 is something that has the highest chance of breaking something within BizTalk and making you regret not having setup a fresh environment. Needless to say, it would best be simulated on a Test/Pilot environment before even touching the production setup.

    If there are compulsions that require you to migrate across domains (as opposed to fresh setup in the new domain) then I'd strongly urge you open a case with Microsoft PSS and take their help for the activity.

    Regards.



    • Edited by Shankycheil Tuesday, November 24, 2015 5:24 AM edit
    • Marked as answer by Angie Xu Thursday, December 3, 2015 2:43 AM
    Tuesday, November 24, 2015 4:54 AM
  • Hi ,

    If this is your Production or Pre Production Farm then there are lot of consideration which need to be taken care of which include data Consistency ,connectivity ,state of the long running transaction etc etc .

    This is not as simple to have a VM snap in working if you have multi server configuration having tons of transaction in processing stage .

    You can think of re storing your BizTalk DB'S full backup  for which you need to have a downtime , Its require bunch of task including changing windows group restoring SSO secret ,checking DTC transaction across server any many more .

    If its a production Environment ,then I would suggest to log a call with MS support to have a detailed plan for this .

    Note : If you are working on single server installation then your task become easy by having a fresh installation .

    Thanks

    Abhishek 


    If this answers your question please mark it accordingly. If this post is helpful, please vote as helpful by clicking the upward arrow mark next to my reply

    Tuesday, November 24, 2015 7:10 AM
  • There are some known issues with cloning the BizTalk server. There are many registry values starting from MSDTC and BizTalk related which screw the environment. therefore it's always recommended to perform a fresh installation of BizTalk Server.

    Thanks,
    Prashant

    My BizTalk Blog
    -------------------------------------------------------------------------
    Please mark this post accordingly if it answers your query or is helpful.

    Tuesday, November 24, 2015 9:50 AM