When you want to upgraded to BizTalk 2009 from BizTalk 2006 R2, it is a relatively easy process to do on Windows 2003.
MSMQT will no longer work, so if you implement message queuing then I advise to build another solution than use MSMQT.
Here is the upgrade warning:
Setup has detected that BizTalk Server 2006 R2 is installed on this computer. Setup will upgrade BizTalk Server 2006 R2 to BizTalk Server 2009.
Prior to the upgrade, you must stop all BizTalk Services in the BizTalk Group and backup the BizTalk databases.
Warning: The following features are no longer available in BizTalk Server 2009.
BizTalk Deployment Command Line Tool
Human Workflow Services Runtime Components
Human Workflow Services Base Assemblies
Human Workflow Service Administration Tools
BizTalk Message Queuing
If you proceed with the upgrade current applications may not function correctly. If you do not wish to proceed with the upgrade, press Cancel.
Setup will upgrade the following databases. Please backup these databases before you click upgrade on the final summary screen.
- -Database: BizTalkMgmtDb on SQL Server: PP\WorkRomiko.
- -Database: BizTalkMsgBoxDb on SQL Server: PP\EUWorkRomiko.
- -Database: BizTalkDTADb on SQL Server: PP\EUWorkRomiko.
- -Database: BizTalkRuleEngineDb on SQL Server: PP\EUWorkRomiko.
Also you will need to install the redistribution cab files:
BTSRedistW2K3EN32.cab (32 bit servers)
BTSRedistW2K3EN64.cab (64 bit servers)
The best is:
1. Run the setup for the first time and choose the option: Download the redistributable prerequisites CAB file.
2. Rerun setup and choose the last option. Automatically install the redistributable prerequisites from a CAB file.
Doing it this way, gives you the opportunity to have the file and then you can reuse it for development, preproduction and production installs.
Also stpo the rule engine and www services before the upgrade and any Biztalk host instances.
Once the upgrade is complete I do notice that the SQL BizTalk jobs owner is changed to the Windows Account that did the upgrade, so if you like them to run under SA or not use windows accounts, then you must go to the SQL jobs and change the owner of the jobs, else you might find your SQL jobs failing!
I was pretty happy with the upgrade and everything went smooth.
However I have one gripe, and I hate moaning, but this is really not cool. The BizTalk administrator console is also upgraded, however it can no longer administer BizTalk 2006 servers, and it can only administer 2009 servers. This can pose a problem on an administration machine when you in a upgrade project cycle, if you want to administer 2006 servers, then you need to logon locally or use another admin console.
I also notice that the BizTalk install folder in program files will still be BizTalk 2006, which is nice, if you use the BTSNTSvc.exe.config file, so those settings are still kept e.g. Enterprise Library profiles etc.
I heard of an issue in Visual Studio 2008 Maps and Schemas can cause a problem, I have yet to see this, so if I do, I will write something up about it! I am just happy to get ion Visual Studio 2008 and get rid of Visual Source Safe and work on Team Server!
I must say assemblies compiled on Visual Studio 2005 still work on 2009 🙂 However if you upgrade your development machine, the BizTalk projects of 2006 will not be recognised, you will need to upgrade to Visual Studio 2008 and upgrade the BizTalk 2006 solution files etc.
Another thing to note, is that when you upgrade a BizTalk project with an orchestration using a web reference, then in visual studio 2008, the upgraded web reference will be updated, however the orchestration odx.cs code behind is not updated. The solution is to DELETE the web references and recreate them from scratch and then reconfigure the web port types 🙂
Another issue is Visual Studio 2008 COPY LOCAL setting for reference dll’s is very buggy, since it is not actually boolean, so migrated settings will not work even if copy local is on, careful of this, else you will get manifest problems thinking it copied the recompiled referenced assemblies. So solution to fix this, is set COPY LOCAL to false in the interface and then set it back to true, thanks to this dudes blog:
Hope this helps for anyone considering an upgrade.