In a previous post, I talked about an eConnect error that said “The transaction has already been implicitly or explicitly committed or aborted.”

I discovered that adding the parameter “Enlist=False” to the eConnect transaction string could sometimes resolve the error. However, this fix wasn’t ideal as it could lead to incomplete transaction processing. Another potential solution was changing the MSDTC Transaction Manager Communication security setting to “No Authentication Required.” Lastly, firewall or network configuration issues were also identified as potential culprits.

Today, I worked with the client to troubleshoot this issue, and unfortunately, the “Enlist=False” workaround was no longer effective. We encountered the same error even with that parameter set. Next, we tried setting both the server and client workstation to “No Authentication Required,” but that didn’t work either.

This led us to explore potential network configuration problems that might be causing the error.

While researching in various forums, I stumbled upon two free Microsoft tools designed to diagnose DTC network communication issues: DTCPing and DTCTester.

DTCPing examines different low-level network communication types between two machines to identify potential configuration issues hindering DTC functionality.

DTCTester, on the other hand, works at a higher level. It connects to SQL Server, creates a temporary table, initiates a transaction to insert data, and then commits the transaction - all while utilizing DTC.

Before testing in the client’s environment, I decided to test these tools on my development machines. After some adjustments, I got DTCPing to work correctly between two Windows Server 2003 HyperV virtual servers, demonstrating proper communication. However, when testing between my physical Windows XP workstation and a Windows 2003 HyperV virtual server, I encountered an error despite achieving some initial communication.

On my XP workstation, the output was:

RPC server is ready
Please Start Partner DTCping before pinging
++++++++++++Validating Remote Computer Name++++++++++++
Invoking RPC method on server1
RPC test is successful
++++++++++++RPC test completed+++++++++++++++
++++++++++++Start DTC Binding Test +++++++++++++
Trying Bind to server1
Binding call to server1 Failed
Session Down

Meanwhile, the server displayed:

RPC server is ready
Please Start Partner DTCping before pinging
Please hit PING button to complete the test
++++++++++++Start Reverse Bind Test+++++++++++++
Received Bind call from XP
Trying Reverse Bind to XP
Error(0x5) at ServerManager.cpp @453
-->RPC reverse BIND failed
-->5(Access is denied.)
Reverse Binding to XP Failed
Session Down

Even after disabling firewalls, double-checking IP addresses, and reviewing configurations, the “Access denied” message persisted, and the cause remained unclear. However, since I knew two of my servers could communicate flawlessly, I proceeded to test DTCPing in the client’s environment.

UPDATE: Reader ‘Maxim’ provided a fix for the “Access Denied” error. Adding or modifying the DWORD value “RestrictRemoteClients” to 0 in HKEY_LOCAL_MACHINE\ Software\Policies\Microsoft\Windows NT\RPC resolved the issue. This setting, apparently a security feature introduced in Windows XP SP2, restricts anonymous RPC access to a machine.

While running DTCPing on the client’s XP machine showed no errors, attempting to connect to the client from the server produced this error:

Error(0xB7) at nameping.cpp @43
-->gethostbyname failure

Pinging the client from the server also failed, confirming a connectivity issue. After examining the IP addresses, I discovered that the server associated the client workstation name with the wrong IP address, likely due to a recent network change that hadn’t been updated in the internal DNS server.

As a temporary workaround, I added a record to the hosts file in C:\Windows\System32\drivers\etc, specifying the workstation’s correct IP address and its Fully Qualified Domain Name (e.g., XP.DOMAIN.local). Subsequently, I used “nbtstat -R” to clear the name resolution cache and confirmed the server was now using the correct IP address.

Unsure if this resolved the original issue, I tested with DTCTester, which successfully completed its test.

We then ran the eConnect integration again, and it worked flawlessly without any transaction errors.

While a seemingly unusual cause for the problem, I’m hopeful that correcting the IP address resolved the issue permanently. However, with at least 35,000 more transactions awaiting import, we’ll know for sure soon enough.