XACT_E_TIP_PULL_FAILED (0X8004D021) – Transaction Manager Can’t Talk to TIP

Quick Answer for Advanced Users

Enable inbound and outbound MSDTC on both servers, open TCP port 135 and dynamic RPC ports, and make sure the Network DTC Access option is checked with Allow Inbound and Allow Outbound. Then restart MSDTC service.

What’s This Error Really About?

So you’re running a distributed transaction across two servers—maybe a linked server query in SQL Server, or a COM+ component that talks to another database—and suddenly you hit XACT_E_TIP_PULL_FAILED (0x8004D021). The transaction manager couldn’t pull the transaction details from the other TIP (Transaction Internet Protocol) manager. That’s the short version.

Why does it happen? Most of the time, it’s a firewall blocking the MSDTC traffic, or MSDTC isn’t configured to allow network transactions. I had a client last month whose entire print queue died because of this—turns out their IT guy turned off MSDTC inbound by accident when patching. The error shows up when Server A tries to start a transaction that involves Server B, and Server B can’t respond because it doesn’t trust the incoming TIP call or the ports are closed.

The real fix is to make sure both sides can talk on the right ports and that MSDTC is set up properly. If you skip the network DTC settings, you’ll see this error again and again.

Step-by-Step Fix

Step 1: Check MSDTC Service Is Running

On both servers, open Services (run services.msc). Look for Distributed Transaction Coordinator. If it’s stopped, start it. Set startup type to Automatic. If it’s already running, move to step 2.

Step 2: Configure MSDTC for Network Access

Open Component Services. Press Win + R, type dcomcnfg, go to Component Services > Computers > My Computer > Distributed Transaction Coordinator > Local DTC. Right-click Local DTC, pick Properties.

• Check the Enable Network DTC Access box.
• Check Allow Inbound and Allow Outbound.
• Under Communication, set it to No Authentication Required (if both servers are in the same trusted domain, you can use mutual authentication—but No Auth is simpler for testing).
• Click OK. You’ll see a warning that MSDTC will restart. Click Yes.

Step 3: Open Firewall Ports

MSDTC uses two ranges: TCP 135 (the RPC endpoint mapper) and a dynamic range for the actual transaction traffic. On both servers, run these commands as admin:

netsh advfirewall firewall add rule dir=in name="MSDTC RPC Endpoint Mapper" protocol=TCP localport=135 action=allow
netsh advfirewall firewall add rule dir=in name="MSDTC Dynamic RPC" protocol=TCP localport=5000-5200 action=allow
netsh advfirewall firewall add rule dir=out name="MSDTC Outbound" protocol=TCP localport=135,5000-5200 action=allow

If you’re using a third-party firewall (like Windows Defender Firewall with Advanced Security), check that these ports are open for the Domain profile if both servers are domain-joined.

Step 4: Restart MSDTC and Test

Back in Services, restart Distributed Transaction Coordinator. Then test with a simple distributed transaction. For SQL Server, run:

BEGIN DISTRIBUTED TRANSACTION;
SELECT * FROM [LinkedServer].[Database].[dbo].[Table];
COMMIT TRANSACTION;

If it succeeds, you’re done. If you still get the error, move to the alternatives.

Alternative Fixes If the Main Steps Don’t Work

Alternative 1: Disable TIP Protocol (Last Resort)

Sometimes the TIP protocol itself is buggy, especially in mixed environments with different Windows versions (e.g., Windows Server 2012 talking to 2019). You can disable TIP by setting a registry key. On both servers:

reg add "HKLM\Software\Microsoft\MSDTC" /v TurnOffTIP /t REG_DWORD /d 1 /f
net stop MSDTC && net start MSDTC

This tells MSDTC to use LU 6.2 or other protocols instead. Downside: some older apps rely on TIP. If you disable it, they might break. Test in a non-production environment first.

Alternative 2: Check for Antivirus Interference

I’ve seen Symantec Endpoint Protection and McAfee block MSDTC traffic even if the firewall is open. Temporarily disable the antivirus or add an exception for msdtc.exe. If that fixes it, whitelist it in the AV settings.

Alternative 3: Verify Network Authentication

If both servers are in different domains or workgroups, set MSDTC to No Authentication Required in Component Services. Also check that the NetworkService account has proper permissions (it usually does, but sometimes group policies mess it up). Use dtcping.exe (from Windows SDK) to test connectivity:

dtcping -s ServerB -p 135

If it returns “pong”, the endpoint is reachable. If not, there’s a firewall or DNS issue.

Prevention Tip

Once you have it working, document the firewall rules and MSDTC settings. I keep a checklist for every new server deployment: enable Network DTC Access, open ports 135 and dynamic range, and set MSDTC to Automatic start. Also, if you’re clustering SQL Server, make sure the MSDTC resource is configured properly—otherwise you’ll see this error on failover. Test distributed transactions after any Windows update that touches networking or COM+.