MSDTC Transaction Errors. What to check?

We've been working on a datacentre migration where we're moving several web applications over to a new virtual environment (VMware ESX Server) and everything had been running smoothly until we started to get this error a week or so ago.

Event Type: ErrorEvent
Source: AnApplication
Category: None
Event ID: 0
Date: 29/11/2007
Time: 15:39:33
User: N/A
Computer: ASERVER

Description:Message failed to import - moving to suspend queue: System.InvalidOperationException: An error occurred while enlisting in a distributed transaction.
Server stack trace: at System.Data.SqlClient.SqlInternalConnection.EnlistNonNullDistributedTransaction(ITransaction transaction) at System.Data.SqlClient.SqlInternalConnection.EnlistDistributedTransaction(ITransaction newTransaction, Guid newTransactionGuid) at System.Data.SqlClient.SqlInternalConnection.EnlistDistributedTransaction() at System.Data.SqlClient.SqlInternalConnection.Activate(Boolean isInTransaction) at System.Data.SqlClient.SqlConnection.Open()

Trawling Google shows a number of possibilities for this, most usually around incorrectly configured firewalls, DTC settings or connection strings however nothing had changed in our environment to prompt these errors.

After trying Microsoft DTCPing and verifying everything was working as expected we moved on to the DTCTester. DTCTester was failing with errors which we found a little bizarre as the DTCPing tools that tests connectivity was passing with flying colours.

The one thing that hadn't been on the check list on any if the support sites (that we'd found anyway) was the amount of machine resources required to support distributed transactions.

We hadn't changed any of the resource allocations to any of the servers since setting them up, the web servers had 2 vCpus + 2gB of RAM and the SQL 4 vCpus + 4gB RAM and they had been allocated fixed minimums in the VMware Virtual Infrastructure Client resource pools. Adding additional VMs into the mix had squeezed something in the ESX Server and started to cause us problems somewhere down the line. After shutting down a few VMs miraculously we were getting distributed transactions working again.

Anyway, if you've tried everything else and you're still having problems with you DTC failing make sure you've got plenty of welly behind your servers and you might just get rid of that pesky "An error occurred while enlisting in a distributed transaction" message.

BizTalk ESB AddNamespace Pipeline Component Bug

If you've not come across the ESB AddNamespace Pipeline Component it's really great for injecting a namespace into xml documents you have no control over.

We're using this component on a project at the moment to aid routing messages through the BizTalk Message Box. Having created a generic "AddNamespace Receive Pipeline" we're configuring the properties on the pipeline through the BizTalk Administration Tool for each of the receive locations.

Since we only want to add a default namespace, a'la xmlns="http://venturetechnologies.co.uk/schemas/ourdoc" there's no need to set the NamespacePrefix property, however if you leave it untouched (empty) you'll get an Null exception at run-time. To work around this simply enter a value in the property field, tab out back in and delete the value, "OK" the property editor and voila, no more errors.

If we get time we'll find a fix and post it up to the CodePlex site, but for now the workaround is quick and easy and doesn't pollute the ESB code base.

BizTalk 2006 on VMWare Workstation

A client I was working for wanted BizTalk 2006 running on VMWare Workstation 5. Easy I thought, so I installed Windows Server 2003 Std R2, SQL Server 2005 Ent + sp1 applied all hotfixes and service packs via Windows Update, followed the BizTalk install guide religiously but still couldn't get the BizTalk configuration to apply successfully.

The Basic configuration was failing with an SSO issue:

Failed to generate and backup the master secret to file: C:\Program Files\Common Files\Enterprise Single Sign-On\SSO0FAB.bak (SSO) Additional Information (0x80070005) Access is Denied.

After much head scratching and searching it appears to be a similar issue to that reported with Microsoft Virtual PC.


The work around to get the Basic Configuration applying correctly is pretty simple.

1. Un-configure the BizTalk installation using the option on the Wizard.
2. Delete the Databases that the un-configure didn't remove (SSODB + BusinessRulesdB) otherwise the config will fail again next time you try.
3. Create the SSO Administrators security group manually.
4. Add the installing user's account and the BizTalk Service account to this new group.
5. Reboot the VM
6. Re-run BizTalk Configuration and this time it should all work swimmingly.

Welcome to the Venture Technologies Company Blog

So what do we do? Well, to put it simply (and to save re-quoting our web site http://www.venturetechnologies.co.uk/) I like to think of us in the same vein as Venture Capitalists except that our "Capital" is Development Resource. We invest our technical skills in companies and entrepreneurs to help them get their new products and ideas to market.

The Venture Technologies Blog is going to be a place to let the world know some of the juicy 'ins and outs' of our investments as well as 'techie tit-bits' that we find in our day to day dealings with the Microsoft development platform.


Talking about the Microsoft development platform, our consulting business has really taken off in the last six months and we're spending an increasing amount of time working with companies who are implementing either Microsoft BizTalk Server 2006 or Microsoft Office SharePoint Server 2007. With both products having their own unique intricacies, I'm sure we'll build up a useful library of Do's and Don'ts that we will happily share with you.