MSDTC problems between NSB app on non-clustered app server and SQL instance on separate app server

[Mark Dickinson]

Hi,

We have an NServiceBus application (4.6.1) hosted on an Windows Server 2012 R2 application server that needs to access a SQL Server 11.0 instance on a separate server.  This NSB app has worked fine on all of our tiers besides production, but our production tier is different in that the production SQL server box is clustered.  

We are getting the following exception when we try to access the database in our production tier:  

System.Data.EntityException: The underlying provider failed on Open. ---> System.Transactions.TransactionManagerCommunicationException: Communication with the underlying transaction manager has failed. ---> System.Runtime.InteropServices.COMException: The MSDTC transaction manager was unable to push the transaction to the destination 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. 

The local MSDTC configuration on our non-clustered production application server (on which our NServiceBus application is hosted):

The MSDTC configuration on our production SQL server box (clustered):

• local MSDTC instance: network DTC access ON, allow remote clients ON, allow inbound/outbound ON, no auth, enable XA checked
• clustered MSDTC instance: network DTC access ON, allow remote clients ON, allow inbound/outbound ON, no auth, enable XA checked

Firewalls are off on both machines, we've been able to ping each server from the other using both NetBIOS names and IP addresses, and network DTC access is definitely set to "ON" on both servers.  The SQL server instance is configured to use the clustered MSDTC on that server. DTCping is successful between the servers but the NSB application still gives us "the underlying provider failed on open". We've restarted both ServiceControl and our NServiceBus application to no avail.

As DTCping appears to be working correctly now, at this point we're basically looking for more ideas as to why our application encounters the MSDTC error when trying to access SQL on our clustered SQL server. One item we weren't sure of is if network DTC access should be turned ON for both the local MSDTC instance and the clustered MSDTC instance on the SQL server box.

Any thoughts or suggestions would be greatly appreciated! 

[Mauro Servienti]

Using EF? Check if this helps
http://stackoverflow.com/questions/1611950/msdtc-problem-with-transactions-in-ado-net-entity-framework

Sent from my Amazing not anymore Yellow Lumia, typos are guaranteed ;-)

---

From: Mark Dickinson
Sent: ‎05/‎11/‎2014 16:48
To: particula...@googlegroups.com
Subject: [particularsoftware] MSDTC problems between NSB app on non-clustered app server and SQL instance on separate app server

--
You received this message because you are subscribed to the Google Groups "Particular Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftw...@googlegroups.com.
To post to this group, send email to particula...@googlegroups.com.
Visit this group at http://groups.google.com/group/particularsoftware.
To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/a245b366-f49e-4e2a-8bf3-951a7d521ee2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mark Dickinson]

Sorry, I forgot to mention that we are using Entity Framework. Network access is enabled for DTC on both servers, and we definitely don't want to suppress the transaction scope as we are enlisting multiple resources (local MSMQ for NSB messages, SQL server on different machine) and definitely want the distributed transaction. As this works fine in all of our non-production tiers (all of which have a non-clustered SQL server box) and DTCping is successful on all tiers (including between our production app server and production SQL server), we're fairly confident it's related in some way to the clustering.

And to clarify, the application server on which our NServiceBus application is hosted is not clustered; only the SQL server box is clustered (and has both local and clustered MSDTC instances configured as described above).

On Wednesday, November 5, 2014 11:15:34 AM UTC-5, Mauro Servienti wrote:

Using EF? Check if this helps
http://stackoverflow.com/questions/1611950/msdtc-problem-with-transactions-in-ado-net-entity-framework

Sent from my Amazing not anymore Yellow Lumia, typos are guaranteed ;-)

---

From: Mark Dickinson
Sent: ‎05/‎11/‎2014 16:48
To: particula...@googlegroups.com
Subject: [particularsoftware] MSDTC problems between NSB app on non-clustered app server and SQL instance on separate app server

Hi,

We have an NServiceBus application (4.6.1) hosted on an Windows Server 2012 R2 application server that needs to access a SQL Server 11.0 instance on a separate server.  This NSB app has worked fine on all of our tiers besides production, but our production tier is different in that the production SQL server box is clustered.  

We are getting the following exception when we try to access the database in our production tier:  

System.Data.EntityException: The underlying provider failed on Open. ---> System.Transactions.TransactionManagerCommunicationException: Communication with the underlying transaction manager has failed. ---> System.Runtime.InteropServices.COMException: The MSDTC transaction manager was unable to push the transaction to the destination 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. 

The local MSDTC configuration on our non-clustered production application server (on which our NServiceBus application is hosted):

The MSDTC configuration on our production SQL server box (clustered):

• local MSDTC instance: network DTC access ON, allow remote clients ON, allow inbound/outbound ON, no auth, enable XA checked
• clustered MSDTC instance: network DTC access ON, allow remote clients ON, allow inbound/outbound ON, no auth, enable XA checked

Firewalls are off on both machines, we've been able to ping each server from the other using both NetBIOS names and IP addresses, and network DTC access is definitely set to "ON" on both servers.  The SQL server instance is configured to use the clustered MSDTC on that server. DTCping is successful between the servers but the NSB application still gives us "the underlying provider failed on open". We've restarted both ServiceControl and our NServiceBus application to no avail.

As DTCping appears to be working correctly now, at this point we're basically looking for more ideas as to why our application encounters the MSDTC error when trying to access SQL on our clustered SQL server. One item we weren't sure of is if network DTC access should be turned ON for both the local MSDTC instance and the clustered MSDTC instance on the SQL server box.

Any thoughts or suggestions would be greatly appreciated! 

--
You received this message because you are subscribed to the Google Groups "Particular Software" group.

To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftware+unsub...@googlegroups.com.
To post to this group, send email to particul...@googlegroups.com.

[Mark Dickinson]

It turns out that server was on a different VLAN than the clustered SQL server and had to be moved to the correct VLAN.  Once this happened and the server was restarted, our issue is resolved.

[Mauro Servienti]

Thanks for the feedback Mark and glad in the end the issue is solved.

.m

--

(no keyboard keys have been killed due to the really annoying OSX spell checker)

--

You received this message because you are subscribed to the Google Groups "Particular Software" group.

To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftw...@googlegroups.com.
To post to this group, send email to particula...@googlegroups.com.

Visit this group at http://groups.google.com/group/particularsoftware.

To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/a15e0d4d-f814-4c46-83a0-f248cae4a6ea%40googlegroups.com.