0X8004D10A

Fix XACT_E_LU_NOT_CONNECTED (0x8004D10A) on DTC transactions

Network & Connectivity Intermediate 👁 0 views 📅 May 27, 2026

This error hits when a distributed transaction component can't reach a linked SQL Server. The fix is almost always a network or DTC misconfiguration.

Quick answer

Open firewall ports 135 (RPC) and a dynamic RPC range for MSDTC, then enable Network DTC Access in Component Services on both servers with mutual authentication required.

What's actually happening here

You're running a distributed transaction—say an INSERT across linked servers in SQL Server—and it bombs with XACT_E_LU_NOT_CONNECTED. The error message says "Subordinate creation failed". What that means in plain English: the Transaction Coordinator on your machine (the root) tried to spin up a sub-transaction on the remote server (the subordinate), but the handshake failed. The remote DTC either couldn't be reached or refused the connection. I've seen this most often when someone sets up a linked server but forgets to configure DTC on one end. The culprit is almost always a firewall blocking RPC or DTC not being allowed through.

Step-by-step fix

  1. Enable Network DTC Access on both servers
    Open Component Services (run dcomcnfg), go to Component Services > Computers > My Computer > Distributed Transaction Coordinator > Local DTC > Properties. Check Network DTC Access, Allow Inbound, Allow Outbound, and Mutual Authentication Required. Click OK and restart the DTC service.
  2. Open firewall ports
    Windows Firewall blocks DTC by default. You need:
    • TCP port 135 for RPC Endpoint Mapper
    • A dynamic RPC port range (default 1024-65535, but you can limit it) for DTC traffic
    On both servers, run these PowerShell commands as admin:
    New-NetFirewallRule -DisplayName 'DTC RPC Port 135' -Direction Inbound -Protocol TCP -LocalPort 135 -Action Allow
    New-NetFirewallRule -DisplayName 'DTC RPC Dynamic' -Direction Inbound -Protocol TCP -LocalPort 1024-65535 -Action Allow
    If you're paranoid, restrict the range. I use 50000-50200. But start wide, narrow later.
  3. Restart the DTC service
    On both servers: net stop msdtc && net start msdtc.
  4. Test the transaction
    Back in SQL Server, run a simple distributed transaction:
    BEGIN DISTRIBUTED TRANSACTION;
    SELECT * FROM [LinkedServer].[Database].[dbo].[Table];
    COMMIT TRANSACTION;
    If it completes, you're golden. If not, keep reading.

What to try if the main fix doesn't work

Check DTC security logs

Open Event Viewer, go to Applications and Services Logs > Microsoft > Windows > MSDTC > Admin. Look for error codes like 4157 or 4180. 4157 usually means mutual authentication mismatch. If you see that, try changing DTC security to Incoming and Outgoing Call Authentication with No Authentication Required (only for testing—don't leave it this way in production).

Ping the DTC endpoint

Use test-netconnection to verify port 135 is reachable:

Test-NetConnection -ComputerName RemoteServer -Port 135
If that fails, the firewall rule didn't take effect or there's a network appliance blocking it.

SQL Server linked server settings

In SQL Server Management Studio, right-click the linked server, go to Properties > Server Options. Set RPC Out to True and RPC to True. Without these, the linked server can't call back to the root.

Prevention tip

Before setting up any linked server that runs distributed transactions, configure DTC on both machines first. Add the firewall rules, enable network access, and restart the service. Test with a simple transaction before you wire it into a production SSIS package or stored procedure. Also, standardize your DTC configuration—use a group policy or PowerShell script so every server in the cluster has identical settings. Saves you a late-night call when the third node falls over.

Was this solution helpful?