BizTalk 2009 RTM Upgrade Gotchas – Tracking Data

Originally posted by Nick Heppleston at: http://www.modhul.com/2009/04/11/biztalk-2009-rtm-upgrade-gotchas-tracking-data/

I’ve started to play around with my new BizTalk 2009 installation following my upgrade fromBizTalk 2006 R2 and I’ve noticed a few quirks that you may need to watch out for, following an upgrade.

Tracking Data

The new Admin Console comes with a bunch of new queries relating to your tracking data, including the ability to view Tracked Service Instances and Message Events:

bts-admin-console-tracked-message-counts

Drilling into the Tracked Message Events view presents the usual Query Results, displaying tracked message events from the BizTalkDTADb dta_MessageInOutEvents and dta_ServiceInstances tables among others:

bts-admin-console-tracked-message-events-results

However, drilling further into an individual message presents the following error dialog:

bts-admin-console-tracked-message-counts-error-dialog

The message was not found in the Message Box or the Tracking databases. This may be caused by one of the following conditions: (1) message tracking is not enabled; (2) the message(s) is no longer referenced by a running or suspended service instance; (3) the Message Box tracking tables have been automatically purged; or (4) the SQL Server agent is not running on the Message Box servers. (Microsoft.BizTalk.Administration.SnapIn)

It would appear that when the upgrade ‘upgrades’ the tracking databases, some have their data truncated (possibly to allowing the structure of the table to be changed) while others are left untouched. In the above case, tracked data written to the dta_MessageInOutEvents and dta_ServiceInstances tables remains untouched, while data written to the tracking_spool1 and tracking_spool2 tables is truncated (double-clicking a query result item causes the BizTalk Admin Console to issue a call to the ops_LoadTrackedMessages stored procedure, passing in the GUID of the MessageId in question; the stored proc in turn queries the two tracking spool tables and no data is returned).

Takeaway

Don’t rely on your tracking data being available after an upgrade to BizTalk 2009; take a backup of the data before you begin the upgrade and query that data in an offline mode.

Reblog this post [with Zemanta]
Advertisements

A Quick Walkthrough of the BizTalk 2006 R2 Upgrade to BizTalk 2009 RTM

Originally posted by Nick Heppleston at: http://www.modhul.com/2009/04/11/a-quick-walkthrough-of-the-biztalk-2006-r2-upgrade-to-biztalk-2009-rtm/

This post is an update to my original documenting the BizTalk 2006 R2 installation to the latest BizTalk 2009 Beta release. This post looks at the RTM’d version, rather than the beta release, of BizTalk Server 2009.

Installing Splash Screen

We start with the now usual Microsoft installation splash-screen, providing options to install BizTalk, UDDI and RFID on this computer. For this walk-though, I’m doing a default install (upgrade) of the existing BizTalk 2006 R2 installation that is present on my VM:

installation-splash-screen

The Upgrade Process

When the installer runs you need to provide the usual licence key and accept the licence agreement itself. Prior to performing the actual upgrade, you will be prompted to confirm the upgrade details, which are shown in the screenshot below.

A few points of interest are at this stage are:

  • All BizTalk Host Instances, the Business Rules Engine Service and the World-Wide-Web Publishing service must be stopped; BizTalk databases must also be backed-up.
  • Several features are not available in BizTalk Server 2009, including: Human Workflow, The BizTalk Deployment Command Line Tool (btsdeploy.exe) and MSMQT – I’m pleased to see that the MSMQT implementation has been dropped and that Microsoft have finally removed BtsDeploy.exe after it was superseeded¬† by BtsTask.exe in BizTalk 2006.
  • A Developer Edition of BizTalk Server 2006 R2 will be upgraded to BizTalk Sever 2009 Enterprise Edition – I don’t know if this is a beta feature or not (i.e. will the same happen with BizTalk Server 2006 R2 Branch Edition?) We are no longer prompted for this in the RTM version.
  • All BizTalk, Rule Engine and BAM databases are upgraded.

upgrade-screen

Prerequisites

Next comes the usual prerequisites screen, with options to automagically or manually install the prerequisites, or install from a previously downloaded CAB file. Interestingly, the beta release only prompted me to download and install the .Net 3.5 Framework – with this already installed on this test VM, I’m now prompted for two further prerequisites: MS SQL XML 4.0 with SP1 and MS ADO MD.Net 10.0.

If you want to download the CAB files before the install, Thiago Almeida has links to the latest versions on his Connected Thoughts blog.

The Upgrade

Before proceeding with the upgrade, you will be presented with an upgrade summary screen as shown below. If you’re happy with everything, click Upgrade.

upgrade-summary

Once you are happy with the upgrade details, the installer will proceed as shown in the screenshot below (I’ve enhanced the screenshot here to show the full upgrade process, so please excuse my Paint abilities):

installation-progress

With the upgrade complete, we now have a BizTalk 2009 Start Menu entry, containing the usual BizTalk Admin Console, BizTalk Server Configuration, Business Rules Composer etc. We also retain a BizTalk Server 2006 Start Menu entry containing a link to the BAM Portal website. We don’t however have a new directory in Program Files, although the contents of this directory have been updated to the BizTalk Server 2009 binaries. I was hoping that this would be resolved in the RTM version, but this doesn’t appear to be the case – possibly a bug?

Comparing an upgrade with a previous BizTalk 2006 R2 installation

Its interesting to compare an upgrade with an old installation: looking through the resources deployed in the BizTalk.System and BizTalk.EDI applications – even though one or two have been removed – of those that remain the assembly versions have not changed. Furthermore, existing custom Applications, Send Ports and assemblies are preserved.

Running existing BizTalk 2006 R2 Applications following an upgrade

Prior to the upgrade I deployed a very simple orchestration-based project and I’m very pleased to see that following the upgrade, this project works exactly the same in 2009 as it did in 2006 R2 – without modification. This is excellent news and means that there is little – if any – work that needs to be done to a 2006 R2 project before migrating to BizTalk 2009.

Conclusion

In conclusion, the upgrade process is very straightforward for anyone experienced with the BizTalk installer – there is no need for re-configuration, however only the BizTalk 2006 R2 elements of functionality that are installed will be upgraded.

Reblog this post [with Zemanta]