There are two interesting BizTalk 2006 bugs to be aware of – it seems like they would
be encountered fairly often, so I’m a little surprised that I haven’t seen more newsgroup/forum
activity around these.

The first bug is encountered when you attempt to start a BizTalk 2006 application
definition with orchestrations that have been bound to different hosts.  (Say,
OrchA in HostA, and OrchB in HostB.)  After the application has been deployed,
the first time the application is started (and ‘orchestration start/enlist’
is included in the start options) you will receive an error that looks something like
this:

Microsoft.BizTalk.ExplorerOM.BtsException: Could not enlist orchestration 'BizTalkSample.Orchestrations.Echo,BizTalkSample.Orchestrations,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=05a4a8d4071035d9'. Could not enlist
orchestration 'BizTalkSample.Orchestrations.Echo,BizTalkSample.Orchestrations, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=05a4a8d4071035d9'. Value does not fall within the
expected range.

You can work around this error by manually starting your orchestrations in the MMC,
either one-at-a-time or grouped by host.  The error only occurs the first time
you attempt to start – all future attempts will succeed.  This is because the
underlying bug has to do with the creation of subscriptions for the orchestrations. 

This is actually a regression from BizTalk 2004 – where you could in fact change multiple
orchestrations (across differing hosts) to a started state via the BtsOrchestration
‘Explorer OM’ class in a single transaction (i.e. before calling SaveChanges.) 
In addition to the behavior just described with BizTalk 2006, you can’t do this kind
of Explorer OM work once multiple hosts are involved in BizTalk 2006.

But hey, there is a hotfix.  Contact PSS and ask about KB927052.

The second bug is encountered when you have a BizTalk 2006 application with multiple
MSMQ receive locations.  You will find that restarting your host instances takes
an excessively long period of time.  This is due to a bug in the adapter which
was not allowing the host service to stop correctly (the Service Control Manager would
eventually just terminate the service…)  Contact PSS and ask about KB928222.