Martijn's blog - E-Commerce, EAI, BizTalk and .NET


Clustering under Virtual Server - Don't forget to update the SID!

When using Virtual Machines, I often copy an existing image to duplicate it. However, currently I'm clustering my BizTalk Server 2006 environment for high availability using Virtual Server 2005.

After setting up the cluster, adding the secondary node didn't work, it kept saying 'Access Denied'. Normally, things like changing the LanManServer parameters or LMCompatibilityLevel fix this, but in this case, no dice..

Until I remembered something trivial when using cloned images, the computer SID is the same in both images! Using the NewSID tool, I updated the SID, rejoined the domain and added the secondary node to the cluster without trouble.

Using my blog as a post-it note ;-)

Renaming your BizTalk Server and Sql Server Agent jobs

After renaming a BizTalk Server host, you need to configure the server using the BizTalk Server Configuration Wizard (in 2006). However, during the reconfiguration, you might encounter a state I did. In my case, a dialog came up stating

'Failed to create Management database "BizTalkMgmtDb" on server "...". Cannot add, update, or delete a job (or its steps or schedules) that originated from an MSX server.

SQL script file: "C:\Program Files\Microsoft BizTalk Server 2006\Schema\\btf_message_logic.sql"'

This failure is caused by the Sql Server Agent still having the jobs configured by the old server. You cannot simply delete/update those jobs as Sql Server doesn't allow you to.

A remedy to this situation is stated in this KB article.

However, this involves renaming the server back to the original name, rebooting, etc. A simpler solution is to update the msdb..sysjobs table and set the originating_server field to reflect the new name.

After this update, the BizTalk Server Configuration Wizard will complete it's work successfully.


Confusion regarding upgrading an Orchestration in BizTalk Server

There seems to be some confusion regarding upgrading Orchestrations. Doug Girard has documented this in a blog post here, but recent webcasts indicate to the contrary. I thought I'd save others some time and confirm that Doug's absolutely right, upgrading an Orchestration version is a fact of
  1. deploying and binding the new version
  2. unenlisting the current Orchestration (which doesn't suspend running Orchestration instances, but in fact removes instance subscriptions for the Orchestration)
  3. starting the new version
If you drop in a message between steps 2 and 3, BizTalk will fail with a "No Subscriptions Found" exception in the EventViewer. This means that to ensure your system will be able to pick up messages correctly, step 2 and 3 need to be executed within the scope of a transaction, as Doug suggests. All Orchestration actions for the v1 version will be dealt with appropriately.

Doug Girard mentions a script for performing steps 2 and 3 in a single transaction to avoid dropped messages.

The location of the script within the documentation is this (copy+paste the location, clicking will not work).

You can also find the C# code (it's not really a script) within the contents under Operations -> Managing BizTalk Server -> Deploying and Managing BizTalk Applications -> Updating BizTalk Applications -> Deploying and Starting a New Version of an Orchestration Programmatically.

UPDATE: A colleague of mine, Martin Rienstra, mentioned that in spite of documentation to the contrary, the last two version number elements do matter in side by side and upgrading scenarios. I've tested it and he is right.