Migrating BizTalk to a New Domain
There are two main points:
- It's not supported by the BizTalk product group as clearly documented in KB article 904356.
- It can be done.
To expand on item 1, migrating BizTalk to a new domain has never been tested by the BizTalk product group, which is why it's not supported and which is why there is A LOT of hesitation to support it. We have had a few cases open regarding this so here are the rules:
a) The BizTalk product group will consider "supporting" this with the appropriate business impact statement. For example, just because you want to probably won't work. Remember, this has never been tested by the BizTalk Product Group testers so there is a risk.
b) The BizTalk product group will review the business impact statement and make a decision accordingly. If "supported" is returned and if something breaks as a result of the domain migration, we will get the help of the BizTalk product group if needed. An Advisory Services case is the only way we will help because there isn't anything break/fix about a BizTalk domain migration. Seriously - no break/fix here!!
With item 2, I deployed the HelloWorld BizTalk SDK sample on BizTalk 2004 SP1 to see if BizTalk could be migrated. I did this on BizTalk 2004 SP1 because the customer who opened the Advisory/Hourly case was using BizTalk 2004 SP1 with SQL Server 2000 SP4. This was about 2 years ago.
The exact steps I followed are in the attached DomainMigrationSteps.txt file.
BIG DISCLAIMER: These steps were tested on the following environment:
- Windows 2003 Active Directory Domain
- Windows 2000 SP4 servers
- BizTalk 2004 SP1
- SQL Server 2000 SP4
Please note the BizTalk 2006, R2 and SQL Server 2005 are not listed and therefore have not been tested. Also, only core BizTalk was tested: no BAM, EDI, Rules or HWS.
Here is a high-level overview of the steps involved:
1. Confirmed core BizTalk was functioning by copying SamplePOInput.xml into C:\Program Files\Microsoft BizTalk Server 2004\SDK\Samples\Orchestrations\HelloWorld\In and displaying in C:\Program Files\Microsoft BizTalk Server 2004\SDK\Samples\Orchestrations\HelloWorld\Out.
2. Backed up the database and the SSO master secret using the online MSDN documentation. Stopped ALL BizTalk processing.
3. Migrated the Active Directory pieces like users and groups and used the Active Directory Migration Tool v3.0 (ADMT). I did all this with the guidance of Active Directory support. A BizTalk administrator should do the same if he/she does not know the ins and outs of Active Directory.
a) Confirmed old and new Primary DC's can ping.
b) Configured the old and new domain to trust. Confirmed the trust worked by opening a physical folder and selecting the old domain. Confirm you can see the users/groups.
c) Use ADMT to move users between the two domains.
4. Updated the SQL Server and BizTalk accounts in SQL Server because ADMT migrates the user but assigns a new SID. This causes a mismatch between the SID present in Active Directory and the SID present in SQL Server (SYSXlogins table).
a) Created sp_help_revlogin procedure by copying/pasting the SQL script in KB article 246133.
b) Created SQL Permission scripts for all BizTalk databases.
c) Back-up all databases except tempDb using SQL Server Backup.
d) Detached all BizTalk databases.
e) Dropped all the Windows logins by using revokelogin.
f) Recreated all the Windows logins and specified NewDomain.
g) Attached all the BizTalk databases
h) Mapped the SIDS using sp_sidmap stored procedure in KB article 240872.
i) Updated all BizTalk SQL Agent jobs in Enterprise Manager to the NewDomain\OriginalUser.
Again, this is a high-level overview.
5. Configured BizTalk for the new domain accounts and groups by doing the following:
a) Updating the service accounts in Services
b) Reviewed ALL BizTalk databases and created a list of the tables that have OldDomain\User or OldDomain\Group as field values.
c) Update these BizTalk database tables to reflect the NewDomain. The SSODB changes were very cumbersome and prone to mistakes. This is where mistakes will be made if users aren't 110% careful.
6. I re-configured the HelloWorld SDK Sample orchestration Binding and Host using BizTalk Explorer in Visual Studio. After enlisting and starting the orchestration, messages were successfully processed using the Receive Location, orchestration and Send Port.
So, the HelloWorld SDK application was working.
7. Removed the trust between both domain controllers.
8. Tested the HelloWorld SDK application again and it worked.
MORE INFORMATION
Since BizTalk 2006 and R2 have the awesome ability of exporting an application as an MSI, unconfiguring and reconfiguring is the best option until/if/when the BizTalk product group automates the process. It may even be faster.
Thanks!
Mandi
Comments
- Anonymous
November 10, 2010
Hi Mandi,we are in a similar position. We have moved to a new domain and still have the old domains groups. You can reconfigure but it creates new databases. Did you try this method on your live server? did you have any issues? Did you find another way of achieving this? Did anyone else get in touch with you?Thanks,Nick - Anonymous
January 13, 2011
Hi Mandi,I have a situation in the enterprise. We have 2 W2k3 Servers with Biztalk Server 2002, and we need to migrate these 2 Servers to another domain. I was searching information on google, but the only that I could read was that is not possible. Is that correct? A KB of Microsoft (support.microsoft.com/.../904356) and following this (msdn.microsoft.com/.../ee251629.aspx) says that if you use Biztalk 2004 you have to run the ConfigFramework.exe located into the Application install folder. So in my installation folder I don't have this, because it seems that the 2002 version doesn't have that function. What you recomend?