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.
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 your first mistake by the author at Microsoft. It clearly states that if you run a 64 bit environment you should run the script using a 64 bit command prompt. That is just plain wrong! Here is why:
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 64-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.
So in order for the script to work you have to run it using a normal administrator command window (32-bit).
In order to make sure the UpdatedRegistry-script updated all the settings I put together this script. Download and change the extension to vbs. Run it and see that all the settings were updated correctly.
Go back to line 24. It says if (err = 0) which seems like a good way to handle errors. It the setting is not found, an error is handled. Wrong! A failed read does not set an error code. It simply returns an empty value. So instead you should handle it using this: if (bKey).
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']").
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 use a 64-bit 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:
The solution is clear. Run the UpdateRegistry.vbs under a 32-bit command prompt.
Now to make it easier for you, I have made a new version of the script available here (change the extension after download).
This contains very few strange things but once again run it under a 32-bit cmd as keys are read. I also commented out everything about Hws. If you use it (strange person) then leave it in.
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).
I would love feedback on this! Please use the contact form and send me an email.
Remember; This is not really all that hard and if you practice you can move an entire production environment in under an hour.