Fix XACT_E_CONNECTION_REQUEST_DENIED (0x8004D100) on Windows

You're trying to run a distributed transaction between two SQL Servers or between an app and a database, and you get this: XACT_E_CONNECTION_REQUEST_DENIED (0x8004D100). The exact message reads "The request to connect to the specified transaction coordinator was denied." I've seen this pop up most often when a .NET app on Server A tries to update a database on Server B within a TransactionScope, or when Linked Server queries fail in SQL Server Management Studio. The trigger is almost always a firewall blocking MSDTC traffic, or the DTC service not configured to allow remote connections.

Why this happens

MSDTC (Microsoft Distributed Transaction Coordinator) manages transactions that span multiple machines. When it says "denied," it means either the network port (usually 135 for RPC, plus dynamic ports for MSDTC) is closed, or the DTC security settings on the target machine explicitly reject incoming connections. Windows Firewall often blocks MSDTC by default. Also, if both servers aren't in the same domain or don't trust each other, authentication can fail silently.

Step-by-step fix

1. Enable MSDTC network access on both machines. Open Component Services (dcomcnfg), go to Component Services > Computers > My Computer > Distributed Transaction Coordinator > Local DTC, right-click and select Properties. On the Security tab, check Network DTC Access, Allow Inbound, Allow Outbound, and No Authentication Required (if you trust the network—otherwise use mutual authentication with Kerberos, but that's more setup). Click OK, then restart the MSDTC service from the command line: net stop msdtc && net start msdtc.
2. Open the Windows Firewall for MSDTC. Run wf.msc and add an inbound rule for Distributed Transaction Coordinator – you'll find it under the predefined rules list. Make sure Domain and Private profiles are enabled. If you're not on a domain, still turn on Domain profile—it's required for some versions. Also, ensure port 135 (RPC Endpoint Mapper) is open. Test with telnet 135.
3. Set MSDTC to use a fixed port range. Dynamic ports cause firewall headaches. In the same DTC Properties dialog, under Endpoints, specify a fixed port range (e.g., 5000-5020). Then add those ports to the firewall inbound rule. This makes troubleshooting consistent.
4. Verify authentication settings. If you checked No Authentication Required, make sure both machines have the same local account credentials or are in the same domain. For domain-joined servers, use Mutual Authentication Required and ensure Kerberos is working—run klist on both sides to see if tickets are present.
5. Restart everything. After changes, restart MSDTC on both servers, then restart the SQL Server service (if using SQL) and the app pool. A full reboot is overkill but works if you're stuck.

What to check if it still fails

• Third-party firewall or antivirus – Symantec, McAfee, or Windows Defender sometimes blocks MSDTC even with Windows Firewall off. Temporarily disable to test.
• Network segmentation – Are both servers on the same subnet? VLAN ACLs can block RPC traffic.
• Event Viewer logs – Look under Applications and Services Logs > Microsoft > Windows > MSDTC for more detailed errors (like MSDTC 4159 or 4185).
• DTCPing tool – Download the DTCPing utility from Microsoft and run it between both machines. It'll tell you exactly where the handshake fails (port, auth, or firewall).
• SQL Server Linked Server settings – If using Linked Servers, ensure the remote server's Enable Promotion of Distributed Transactions option is set correctly (usually disabled for simple queries).

Had a client last month whose entire print queue died because of this same error—turns out their AVG firewall was silently blocking MSDTC. Disabled it, rebooted, and the transaction worked. Rule of thumb: always check the firewall first.

That's it. If you follow these steps, 0x8004D100 should vanish. The key is methodical checking—firewall, then DTC settings, then authentication. Don't skip the DTCPing tool; it saves hours.