Working with MSDTC...

Introduction

If you tried to search for MSDTC, the first result will describe MSDTC as an acronym for Microsoft Distributed Transaction Coordinator. As the name says, MSDTC is a Windows service providing transaction infrastructure for distributed systems. In this case, a transaction means a general way of structuring the interactions between autonomous agents in a distributed system. However, in my simple definition, it is a service from Microsoft that you need to deal with whenever you want to do transaction processing, and it is very hard to identify and troubleshoot any of the problems that you may face while interacting with it.

Background

Doing transaction processing in your code is a very simple to do task, all that it needs to surround is the part that you want to be executed as one transaction with one Transaction scope and commit it whenever you finish all parts.

But with the default setup on your machine, most likely, you will end up with the below common MSDTC error:

Network access for Distributed Transaction Manager (MSDTC) has been disabled. 
Please enable DTC for network access in the security configuration for MSDTC using the 
Component Services Administrative tool.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Inner Exception:
The transaction manager has disabled its support for remote/network transactions. 
(Exception from HRESULT: 0x8004D024)

Using the Code

However, because of number of elements inside your and the server environment / network / firewall, which will interfere with MSTDC, and the lack of clear error reporting from the DTC itself, this task will become much harder.

Basic Setup

Since the most common scenario is to have Database / Application servers, having your code working fine on your machine does not means that it works fine once you deploy it on the server. When you connect to another server or DB server, that server needs to enable Distributed Transaction for network access on it as well.

Below are some of the basic setups that you need do first in order for the MSDTC to work fine:

Still Not Working?

If you are trying to connect to another server, and you are getting an error simillar to the below, this means that it's time to start cross machines investigation. Follow the below steps to do more investigation about why it is not working.

Communication with the underlying transaction manager has failed.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Inner Exception:
The MSDTC transaction manager was unable to pull the transaction 
from the source transaction manager due to communication problems. 
Possible causes are: a firewall is present and it doesn't have an 
exception for the MSDTC process, the two machines cannot find each other 
by their NetBIOS names, or the support for network transactions is not enabled 
for one of the two transaction managers. 
(Exception from HRESULT: 0x8004D02B)

Port 135

MSDTC uses port 135 to connect to other servers; a simple telnet command on port 135 should help you identify the problem, the command should be executed from both machines, as the port should be opened for both directions.

In the below example, let's imagine that your server IP address is 10.10.10.1 and your IP address is 10.10.10.2, both commands below should be working fine.

From your machine:

telnet 10.10.10.1 135

From server:

telnet 10.10.10.2 135

IP Address vs Machine Name

You need to make sure that both machines see each other using the same IP address, this problem usually occurs due to some domain configuration where they disable IP Address resolving within the network.

In order to identify this problem, you need to compare the results from running IPconfig command on machine A and a ping to the same Machine. The output IP address should be matching. In case it’s not, you need to modify the host server on machine B to have the IP corrected.

In the below example, let's imagine that your server IP address / name is 10.10.10.1 / Server1 and your IP address / name is 10.10.10.2 / MyMachine.

From Your Machine

C:\>Ipconfig

//you will get results similar to

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : x.com
   IPv4 Address. . . . . . . . . . . : 10.10.10.2
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 10.10.10.x

From Server

C:\>ping MyMachine

Pinging ENPAYSAFEDEVDB [10.10.10.2] with 32 bytes of data:
Reply from 10.10.10.2: bytes=32 time=1ms TTL=127
Reply from 10.10.10.2: bytes=32 time=1ms TTL=127
Reply from 10.10.10.2: bytes=32 time=1ms TTL=127
Reply from 10.10.10.2: bytes=32 time<1ms TTL=127

The IP address should match, if not, the host file needs to be changed on server.

# localhost name resolution is handled within DNS itself.
#    127.0.0.1       localhost
#    ::1             localhost
10.10.10.2        MyMachine

Track Your Transactions

In order to exactly figure out what is happening, you need to track where your transaction is stuck at, the below methods can help you in this process:

If you are using SQL server, it is very easy to identify if the transaction has reach the database side or not. To do so, the below SQL command needs to be executed:

SELECT * FROM sys.sysprocesses WHERE open_tran = 1

The output will be something similar to:

The main keys listed below will help you understand this output:

• lastwaittype: Check this reference to show what every waittype exactly means.
• status: Current status for this transaction.
• hostname: The source server/machine of this transaction.
• cmd: The current command for the transaction is as follows:

  While Connecting	Running
  When Connect Completed	Sleeping / Awaiting Command
  Query e.g. select "1"	Running
  When select completed	Sleeping / Awaiting Command

At your side, you can also see the transactions from Component Services >> local DTC screen as follows:

This screen also gives the option to Commit, Abort and Forget this transaction.

DTCPing

DTCPing is very helpful tool which can be downloaded directly from Microsoft website, this tool can assist you trhough debugging and diagnosing DTC issues, as it can simulate a DTC between two machines.

Run DTCPing on both servers, put the other server name in the box and click PING.

Do the same thing from the other side and watch the result in the log.

DTCPing can be downloaded from this link.

VM Cloning

In VM environment, IT tends to clone VMs whenever they are preparing multiple servers, which is usually our case when we need DB / Application.

Cloning VMs can cause the below error for MSDTC:

To solve this issue, you need to uninstall / install MSDTC again, use the below command running on administrator privileges:

Stop the MS DTC service
Go to the command line and run: MSDTC -uninstall
Go to the command line and run: MSDTC -install
Start the MS DTC service

History

• 5^th March, 2018: Initial version
• 30^th May, 2023: Updated