Fixing XACT_E_PARTNER_NETWORK_TX_DISABLED (0x8004D025)

1. MSDTC Security Configuration on Both Machines

What's happening here is simple: the remote DTC has been told not to talk to the network. The error XACT_E_PARTNER_NETWORK_TX_DISABLED (0x8004D025) pops up when you try to start a distributed transaction across two SQL Servers or between an app and a database, and the remote side's DTC is locked down. I see this most often with SQL Server linked servers or .NET TransactionScope across machines.

The fix is to enable network DTC access on both machines — the one initiating the transaction (client) and the one receiving it (server). Here's how:

1. Open Component Services (run dcomcnfg). Navigate to Component Services > Computers > My Computer > Distributed Transaction Coordinator > Local DTC.
2. Right-click Local DTC and select Properties.
3. Go to the Security tab.
4. Check Network DTC Access.
5. Under Transaction Manager Communication, check Allow Inbound and Allow Outbound.
6. Set Authentication to Mutual Authentication Required (the default). If both machines are on the same domain, leave it. If they're in a workgroup, you'll need No Authentication Required — but that's less secure.
7. Check Enable XA Transactions if you're using XA-compliant resources like Oracle or MSMQ. Skip it for plain SQL Server.
8. Click OK. A dialog says MSDTC will restart. Let it.

Repeat these steps on both the client and server machines. The reason both need inbound/outbound enabled is that DTC negotiates the transaction — each side acts as both coordinator and participant depending on the flow.

2. Firewall Rules Blocking DTC Traffic

Even if DTC is configured perfectly, a firewall can silently drop the traffic and return this error. DTC uses dynamic TCP ports in the range 49152–65535 by default, plus RPC endpoint mapper on port 135. If a firewall sits between the machines, you'll need to open those.

On Windows Firewall, there's a built-in rule group. Do this:

• Open Windows Defender Firewall with Advanced Security.
• Go to Inbound Rules.
• Sort by Group — look for Distributed Transaction Coordinator.
• Enable these rules: RPC-EPMAP (port 135) and TCP-In (dynamic ports).
• Do the same for Outbound Rules — enable the matching outbound rules.

If you're on a strict corporate network, talk to your network admin. Alternatively, you can pin DTC to a specific port range via registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC\Security
Name: ServerTcpPort
Type: REG_DWORD
Value: 5000 (or any port you choose)

Then open that single port in the firewall (e.g., TCP 5000) instead of the whole dynamic range. Restart MSDTC after changing the registry.

The error doesn't always show up immediately — sometimes the first transaction works, then the second fails because the firewall drops the coordination messages. That's a telltale sign of a firewall issue.

3. MSDTC Service Not Running or Misconfigured Clustering

Another cause: the MSDTC service itself stopped or is in a bad state. Check with sc query msdtc — should return STATE: 4 RUNNING. If it's stopped, start it: net start msdtc. If it fails to start, check the Application event log for errors like MSDTC 4199 or MSDTC 6329 — those usually point to corrupt log files.

To fix corrupt logs, stop MSDTC, delete the log folder contents, then restart:

net stop msdtc
rmdir /s /q C:\Windows\System32\MSDTC
net start msdtc

This recreates the log files. Do this only after backing up the folder if you have active transactions.

In clustered environments, you might see this error if DTC is not configured as a clustered resource, or if the network name is wrong. Verify the DTC resource in Failover Cluster Manager — it should use a dedicated IP and network name, not the default local DTC. If you're not clustering, ignore this.

Quick-Reference Summary Table