Fix XACT_E_NOENLIST (0x8004D00A) in 3 Steps

What causes XACT_E_NOENLIST (0x8004D00A)

You get this error when your application tries to join a Microsoft Distributed Transaction Coordinator (MSDTC) transaction but can't. The transaction coordinator either can't see the target resource manager—like SQL Server, a COM+ component, or a queue—or the resource manager refuses to join.

I've seen this pop up most often in two scenarios:

• You're running a .NET app that uses TransactionScope with a remote database, and the transaction tries to escalate from a local LTM transaction to a full DTC transaction.
• You're using a legacy VB6 or C++ COM+ component that calls ITransactionDispenser::BeginTransaction and then tries to enlist another resource.

The error code 0x8004D00A literally means "unable to enlist." The enlistment call fails before any real work starts. No partial data committed—it just bombs out at the start.

Below I walk you through three layers of fixes. Start with the first. If it works, stop. No need to go further.

Fix 1: Quick network name check (30 seconds)

This is the number one cause. The machine's network name doesn't resolve to the IP address the transaction coordinator expects. I've fixed this more times than I can count just by checking hostname resolution.

1. Open a Command Prompt as Administrator. Hit Windows key, type cmd, right-click, choose "Run as administrator."
2. Type hostname and press Enter. Write down what it shows—something like DB-SERVER-01.
3. Now type ping <your-hostname> (replace with the name you just got). Example: ping DB-SERVER-01.
4. Look at the first line that says "Pinging ..." It shows the IP address. If it shows ::1 (IPv6 loopback) or 127.0.0.1, that's bad. DTC needs a real network IP.

If you see a loopback address:

Go to your hosts file. Open Notepad as Administrator, then open C:\Windows\System32\drivers\etc\hosts.

Check if there's a line like this:

127.0.0.1 DB-SERVER-01
::1 DB-SERVER-01

Delete any line that maps your machine's hostname to 127.0.0.1 or ::1. Save the file.

After editing, run ping DB-SERVER-01 again. You should see your actual IP address like 192.168.1.50. Now try your app. If the error's gone, you're done.

Fix 2: Moderate fix—configure DTC security (5 minutes)

If the network check didn't help, the problem is almost certainly DTC security settings. Windows 10, Windows Server 2016/2019/2022 all lock down DTC by default. You need to turn on network access.

Wait: If the app and the database are on the same machine, skip this step. You don't need network DTC for local transactions. Go to Fix 3 instead.

1. Press Windows + R, type dcomcnfg, press Enter.
2. In the Component Services window, expand Component Services > Computers > My Computer > Distributed Transaction Coordinator.
3. Right-click Local DTC, choose Properties.
4. Click the Security tab.
5. Check these options:
   • Network DTC Access — must be checked.
   • Under Transaction Manager Communication:
     • Check Allow Inbound
     • Check Allow Outbound
     • For Authentication: choose Mutual Authentication Required if both machines are in the same domain. If they're not in a domain (workgroup), pick Incoming and Outgoing Caller Authentication.
   • Enable XA Transactions — check this only if you're using XA-compliant resources like some older SQL Server drivers or Oracle. Otherwise leave it off.
6. Click Apply, then OK.

You'll see a popup: "The changes have been saved. Do you want to restart the service now?" Click Yes.

Now test your app. If the error's gone, stop here. If not, move on to Fix 3.

Fix 3: Advanced fix—firewall ports and service account (15+ minutes)

This fix digs into two things DTC can't work without: the right ports open and the correct service account permissions.

Step 3a: Open DTC ports in Windows Firewall

DTC uses a range of RPC dynamic ports by default (49152-65535 on Windows Vista and later). It also uses a fixed endpoint mapper port 135. You need both.

1. Open Windows Defender Firewall with Advanced Security. Press Windows key, type "wf.msc", press Enter.
2. Click Inbound Rules on the left.
3. Click New Rule... on the right.
4. Choose Port, click Next.
5. Select TCP, then Specific local ports. Type 135, 49152-65535. Click Next.
6. Choose Allow the connection, click Next.
7. Check all profiles (Domain, Private, Public) and click Next.
8. Name the rule DTC - RPC Endpoint Mapper and Dynamic Ports. Click Finish.
9. Repeat steps 2-8 but for Outbound Rules. Same port numbers, same allow setting.

Pro tip: If your network team restricts dynamic ports, you can configure DTC to use a fixed port range. That's a separate topic, but for most environments the default dynamic range works fine.

Step 3b: Check the DTC service account

The MSDTC service runs as NT AUTHORITY\NetworkService by default. It needs the right to impersonate the client account and access network resources.

1. Press Windows + R, type services.msc, press Enter.
2. Find Distributed Transaction Coordinator in the list.
3. Right-click, choose Properties.
4. Click the Log On tab.
5. Make sure Local System account or NT AUTHORITY\NetworkService is selected. Avoid changing it to a domain user unless you really know what you're doing—it causes more problems than it solves.

Step 3c: Restart the service clean

After all changes, restart MSDTC from an elevated Command Prompt:

net stop msdtc
net start msdtc

Then test your app again. If it still fails, you're looking at a deeper issue—maybe the remote machine's DTC isn't configured right, or there's an authentication mismatch between domain and workgroup machines. Check the Application event log under Event Viewer > Windows Logs > Application. Look for MSDTC event ID 4099 or 4159—those usually tell you exactly which side is failing.

When nothing above works

If you've gone through all three fixes and the error persists, don't panic. The issue might not be DTC config at all—some applications cache connection strings with transaction settings. Reboot both machines. Or check if your app is explicitly setting Enlist=false in the connection string—that disables transaction enlistment entirely, which throws XACT_E_NOENLIST if the app then tries to participate in a transaction.

Also verify that both machines are on the same time within a few seconds. DTC uses Kerberos for mutual authentication if you chose that option, and Kerberos requires time sync. Run w32tm /resync on both machines if you suspect time drift.