The MSDTC transaction manager was unable to pull the transaction from the source transaction manager due to communication problems

Question

I have hosted my WebApp on server 1 and my database on server 2

But I'm getting following error

Communication with the underlying transaction manager has failed.

I googled and found a post which mentioned that it is the issue of DTC(Distributed Transaction) I enabled DTC on server2(DB server) and made an exception of it in Firewall.

But still same error.

Here is the full stack trace

Message: System.Transactions.TransactionManagerCommunicationException: Communication with the underlying transaction manager has failed. ---> System.Runtime.InteropServices.COMException: 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) at System.Transactions.Oletx.IDtcProxyShimFactory.ReceiveTransaction(UInt32 propgationTokenSize, Byte[] propgationToken, IntPtr managedIdentifier, Guid& transactionIdentifier, OletxTransactionIsolationLevel& isolationLevel, ITransactionShim& transactionShim) at System.Transactions.TransactionInterop.GetOletxTransactionFromTransmitterPropigationToken(Byte[] propagationToken)

Kindly advice

Cherish

I'm having the same issue sometimes in windows 2088 and I don't know how to solve it. It happends sometimes. :( – Isomagnetic

Have you tried to set it up also on application server? You are configuring both Inbound/Outbound. It solved my problem. – Lonely

Answer 1

We had the exact same situation, and more than once. Each time, it was one of the following:

1. The IP address in the DNS for the server is outdated (as said in error message: "two machines cannot find each other by their NetBIOS names"). You can check if this is the case by trying ping servername from one server to another in the command prompt. If the ping by name fails and ping by IP succeeds (or ping by name returns the wrong IP), than you should talk to the System Admins to take a look at DNS/DHCP.

2. The servers are created as an image of preconfigured server (for example, if you are working with virtual machines, and instead of doing a fresh install for each of the servers, you simply clone the image). This is a problem because DTC has an internal "Identifier" - and in case of image cloning both your installations now have same DTC ID, and won't be able to communicate with each other. The solution is to simply uninstall and install the DTC again.

Hope it helps.

Lannielanning

#1 happened with two different networks. It helps to resolve it. thanks – Damsel

Had issues on a Virtual machine because #1 was happening on it and it was getting the wrong ip, setting its network configuration and double checking the ip with ping solved my issue. – Medication

Answer 2

I had the same problem while connecting to a remote SQl Server. The solution in my case was to add "enlist=false" to the connection string.

Justinajustine

this is not a solution, what it does is it essentially never enlists the connection in a elevated Transaction which means good luck rolling things back after a failure on one server or DB ( this is ofc important if you are running operations on more than one database within one transaction ). – Medication

This is definitely not a production solution, but it is the solution for a local environment where all databases are on the same server. In my case, a Docker Desktop for Windows SQL Server container. Setting up MSDTC is problematic in that setup. – Cypriot

Answer 3

Things to check:

• Have you done this configuration on both servers?
• Are both servers members of the same domain?
• Have you checked the event log?

Ledeen

Answer 4

I was missing quite a lot of things:

1. No authentication (as DB server and APP server and not within same AD domain)
2. Rule to Windows Firewall enabling msdtc.exe
3. Rule to firewall between DMZ and internal zone TCP 135,1024-65535 in both directions. The link tell you how to restrict the firewall policy to few ports only.
4. short / long server names to hosts or a shared DNS server. Eg. 192.168.1.1 app1 as well as 192.168.1.1 app1.domain.local

On the other hand based on this link my setup doesn't require:

• Allow Remote Clients
• Allow Remote Administration
• Enable XA Transactions (required prior Windows Server 2003 SP1)

Openmouthed

Answer 5

Solved after adding remote IP\machine name to files on server: hosts, lmhosts in folder C:\Windows\System32\drivers\etc

Myrwyn

This solved it for me but I did not need to edit hosts, only lmhosts. – Cloaca

Answer 6

One of our servers displayed this error after the Virtual Machine (VM) controlling our Domain Controller froze. Several related communication problems also started to pop up (like failed password resets). Resetting the frozen VM fixed the issue.

Malayan

Answer 7

Lots of helpful answers already given.

One problem for me was the presence of invalid (cyrillic) characters in the computer name.

And there is also a way to validate the connection between two servers (or between a server and a computer) using a small tool from Microsoft called DTCPing.

Aragonite