Compartilhar via


DTCPing: Troubleshooting MSDTC Connectivity Issues

In today's world, security hardening is causing many headaches to software developers and admins. Especially when you have an application that needs to go beyond the boundaries of the local machine. MSDTC is a distributed app by definition and thus, getting transacted app that uses MSDTC to work in your network is not as easy as one would expect. You either get "New transaction cannot enlist in specified transaction coordinator" or 8004d00a.

There is a tool that can help you troubleshoot MSDTC connectivity issues, and that tool is called DTCPing: https://www.microsoft.com/downloads/details.aspx?FamilyID=5e325025-4dcd-4658-a549-1d549ac17644&DisplayLang=en

It was initially created to troubleshoot firewall issues: https://support.microsoft.com/default.aspx?scid=kb;EN-US;Q306843 This KB article also gives you instructions on how to use DTCPing.

Most common errors that block MSDTC connectivity in a network are:
1. MSDTC Security settings are not configured properly: https://blogs.msdn.com/florinlazar/archive/2004/06/18/159127.aspx
 2. MSDTC is not in the exception list in the firewall
3. The two machines involved in the transaction cannot see each other by the NetBIOS name. Try ping-ing the machines by name. If that fails, MSDTC will fail. You can solve this by updating your system32\drivers\etc\hosts file.
4. If the machines were imaged improperly, the CID for MSDTC under HKEY_CLASSES_ROOT\CID may be the same on the two machines, while they need to be unique. The KB 306843 mentioned above gives the instructions to correct this issue.

Comments

  • Anonymous
    September 16, 2005
    DTCPing and DTCTester are both very useful tools in diagnosing DTC access issues. However, I believe they are pushed sometimes as the tools to use, instead of fixing the real problem: The DTC is way, way too poor at giving the caller good error codes/messages, and most of the time just downright fails with an E_FAIL or unknown error. Heck, it doesn't even leave a message in the machine's Event Log.

    I really wish you guys devoted some time to improving the internal diagnostic code in the DTC instead...
  • Anonymous
    October 03, 2005
    To: Tomas
    Thanks for the feedback. I agree with you. DTC was "born" as a service that was supposed to run in the background and you should never have to be concerned about it. Only COM+ or SQL Server will deal with it.

    With the amount of security hardening that happened in the last years, suddenly the scenarios using transactions started to fail and the users needed to be aware of DTC. How do I get it to work?

    We have the Tracing feature that might help a little but I know it's not enough. We are looking into improving the user experience and our troubleshooting story.