If you do distributed transactions across the network, you know about Allow Inbound and Allow Outbound security settings for DTC (available by running dcomcnfg or by opening Component Services).

The help describes these settings as:

• Allow Inbound: Select this check box to allow a remote computer to flow transactions to the local computer. Typically, this option is needed on the computer that is hosting the DTC for a resource manager such as Microsoft SQL Server.
• Allow Outbound: Select this check box to allow the local computer to flow transactions to a remote computer. Typically, this option is needed on the client computer, where the transaction is initiated.

Pretty straightforward: you set Allow Outbound on the client and Allow Inbound on the SQL Server box. Except, if you are using System.Transactions with SQL Server and you promote after the first connection to the database (which means DTC gets involved), the transaction will most likely abort. Why?

If you remember my previous post on promotable transactions, in this case, the distributed transaction gets initiated on the resource manager (SQL Server) side and gets flown back to the client, which means that you actually need to set Allow Outbound on the SQL Server box and Allow Inbound on the client.

I know, it's not the most intuitive setting. Allow Inbound/Outbound were created before System.Transactions, they are still doing what they were designed to do, except that they didn't evolve with System.Transactions.

When System.Transactions was being designed, between other goals one important one was to make it easy to use. And with that, the promotion part was supposed to be as invisible as possible - things will go fast, then on demand promote to DTC and continue without any user intervention. The legacy of managing DTC network settings couldn't be avoided and thus all these details had to be explained.