2015-01-07: Edit. The part about 32 vs 64 bit was wrong on my part! I have rewritten the post.
Also, since this post was written Microsoft has updated the original article.
Skipping ahead a bit
After some feedback about the last article (thanks everyone) you all seem to know how to follow instructions from Microsoft. You all told me to skip to the part about the instructions being wrong. So I will.
Make sure to read the entire article.
32 vs 64 bit
Ever heard of that issue? Ever run into trouble because of that? Of course you have! Now you might be able to avoid it.
When you reach step 11 in the article “How to restore your databases” you run into the statement that you have to run the 64 bit cmd if you are running in a 64-bit environment (who does not?).
The thing is that the cmd-prompt you get when use Run+cmd is the 64 bit one! If you (like me) navigate to %windir%SysWow64 and run cmd, thinking you will get the 64 bit one that way, you will get the 32 bit one!!!
This is were I was wrong. It is a very confusing that the 64 bit version is located in the System32 folder and the 32 bit under SysWow64, but that is the way it is. In short: Simply use Run+Cmd and you will get the correct version.
So why is this a problem?
Reading registry settings the wrong way
If you open the file C:\Program Files (x86)\Microsoft BizTalk Server 2010\Bins32\Schema\Restore\UpdateRegistry.vbs and take a look at line 23. It reads: bKey = WshShell.RegRead("HKLM\SOFTWARE\Microsoft\BizTalk Server\3.0\Administration\MgmtDBServer").
If you run this script in a 32-bit command prompt the script will actually look for this key: HKLM\SOFTWARE\Wow6432Node\Microsoft\BizTalk Server\3.0\Administration\MgmtDBServer. Now in this row there is nothing wrong with that as it will find a key.
The trouble comes a couple of rows down: WshShell.RegWrite will only update the 64-bit registry settings(!) and all your 32-bit hosts will fail.
Not updating the SSO database!
Now this is scary, because it effects the SSO database. It does not update any registry setting about the SSO database, but it uses the program called Ssoconfig to change the database name. This is done by using the %path%-parameter called “CommonProgramFiles”, which is awesome. However, dead wrong as it points to the 32-bit common program files (if you the wrong cmd) and Ssoconfig is not installed there. The effect is that the SSO database is not moved and the script does not even throw an error.
This is very easy to test:
- Open a 32-bit command-prompt and type in the following: cd "%CommonProgramFiles%.
- This will change the directory to “c:\ProgramFiles\Common Files”, which is where Ssoconfig is located.
- Now try the same on a 64-bit command prompt (located at C:\Windows\SysWOW64\cmd.exe) and run the same command.
- Result C:\Program Files (x86)\Common Files. That is NOT the right path.
The solution is clear. Run the UpdateRegistry.vbs under a normal (64 bit) command prompt.
Minor mistake about EDI
Now go to line 131. It says to look for an attribute called EDI. If it finds this attribute, the EDI settings will be updated. However step 11 in the guide says you should update your SampleUpdateInfo.xml to include an attribute called MsEDIAS2. Update the line in the script to: set node = configObj.selectSingleNode("/UpdateConfiguration/OtherDatabases/Database[@Name='MsEDIAS2']").
This contains very few strange things but once again run it under a 64-bit cmd as keys are read. I also commented out everything about Hws. If you use it (strange person) then leave it in.
BAM databases and other BAM components
If you are using BAM in your environment, good for you. Be sure to follow this article to the letter after moving the databases and running the scripts. http://msdn.microsoft.com/en-us/library/aa561586.aspx It basically points everything (the BAM portal and BAM WS) to the new database.
Ok so there are a couple of more pointers. The jobs you scripted for BizTalk, some have to be updated by hand (no biggie).
- BizTalk Backup has a database server name in it.
- Operations_OperateOnInstances_OnMaster_BizTalkMsgBoxDb also has a server name in it.
- Rules_Database_Cleanup_BizTalkRuleEngineDb.sql run this when/if the Rule engine DB has been created on the new server.
- TrackedMessages_Copy_BizTalkMsgBoxDb.sql also has a server name in it.
The article used to contain links to my version of the update-scripts, but as the normal scripts work as long as you use the correct version of cmd, they only contain one error (the EDI one) as far I know.
Remember; This is not really all that hard and if you practice you can move an entire production environment in under an hour.