Fix XACT_E_CONNECTION_DENIED (0x8004D01D) – DTC error

When this error hits

You're running a distributed transaction—maybe linking two SQL Server instances, or sending a message through MSMQ while updating a database. Then boom: the transaction fails with XACT_E_CONNECTION_DENIED (0x8004D01D) and a message like "A request to establish a connection with the transaction manager was denied." This isn't a random glitch. I've seen it most often when a Windows service account tries to start a DTC transaction across a network boundary, especially after a Windows Update or a server migration. Last month I had a client whose entire inventory reconciliation script died after they moved their app to a new VM—same code, same SQL, but the DTC security settings didn't come along.

Root cause in plain English

The Distributed Transaction Coordinator (MSDTC) is the traffic cop for transactions that span multiple resources, like two databases or a database and a queue. When it refuses a connection, it's usually because of one of three things:

DTC security settings—it's locked down too tight. By default, DTC doesn't allow inbound or outbound communication over the network.
Firewall blocking port 135—DTC uses RPC dynamic ports, but the first handshake happens on 135. If that's blocked, no dice.
Authentication mismatch—the calling account doesn't have the right privileges, or Kerberos isn't set up correctly for cross-domain transactions.

Don't waste time reinstalling DTC. It's almost always a config or firewall issue.

The fix: step by step

Step 1: Open DTC security configuration

Run dcomcnfg to open Component Services. Expand Component Services > Computers > My Computer > Distributed Transaction Coordinator > Local DTC. Right-click Local DTC and select Properties.

Step 2: Enable network access

Go to the Security tab. Check these boxes:

Network DTC Access (required)
Allow Inbound
Allow Outbound
No Authentication Required—yes, this sounds insecure, but for many internal apps it's the only way. If your environment demands Kerberos, you'll need to configure delegation, but 90% of the time "No Authentication" works fine inside a domain.

Also check Enable Transaction Internet Protocol (TIP) Protocol and Enable XA Transactions if your app uses them (like with Oracle or older COM+ components).

Step 3: Restart MSDTC

Open an admin PowerShell or Command Prompt and run:

net stop msdtc && net start msdtc

Or restart from Services.msc if you prefer clicking.

Step 4: Fix the firewall

DTC needs port 135 (RPC Endpoint Mapper) open both ways. On Windows Firewall, run this as admin:

netsh advfirewall firewall add rule name="DTC Port 135" dir=in action=allow protocol=TCP localport=135

Do the same for outbound if your security policy allows it (dir=out).

For dynamic RPC ports, DTC usually uses a range like 49152-65535. To lock it down, you can configure a fixed port range in the registry (not covered here, but it's doable). Otherwise, just allow the full dynamic range or use the predefined Windows rule Distributed Transaction Coordinator in the firewall console.

Step 5: Verify the service account

If your app runs under a domain account, make sure that account has Access this computer from the network privilege on both machines (check Local Security Policy > User Rights Assignments). Also confirm the account can authenticate to the remote DTC service—Kerberos errors will show up in the System event log as Event ID 4097 or 4098 from MSDTC.

What to check if it still fails

Open Event Viewer and look under Applications and Services Logs > Microsoft > Windows > MSDTC > Admin and Operational. Common follow-ups:

Event ID 4159—"MSDTC encountered an error (0x8004D01D) while attempting to establish a connection"—this points straight at firewall or security config.
Check both machines. You need DTC running and configured on every node in the transaction. One misconfigured server will kill the whole thing.
Disable IPv6 on the network adapters if you're seeing intermittent failures. DTC has known issues with IPv6 in mixed environments.
Run the Microsoft DTC Ping utility (dtcping.exe) from both sides. It tests connectivity and will tell you exactly where the handshake breaks.

If you've done all this and it's still failing, chances are you've got a third-party firewall (like Symantec or McAfee) blocking DTC traffic, or a network appliance doing deep packet inspection. Disable it temporarily to confirm. That's how I found the culprit at a client site—their Cisco ASA was dropping RPC packets even though Windows Firewall was wide open.