Server not configured for transactions error 0X0000085D fix

You're running some query or batch job — maybe an old VB6 app, a SQL Server linked server query, or a .NET app using TransactionScope — and boom, you get error 0X0000085D (NERR_BadTransactConfig). The message says "The server is not configured for transactions." Happens often when you move a legacy app from a dev box to a production server that's locked down tight. I had a client last month whose entire inventory update script kept failing because their new Windows Server 2022 had MSDTC disabled by default.

What causes this

The error means the server you're connecting to isn't ready to handle distributed transactions. In Windows, that's handled by the Distributed Transaction Coordinator (MSDTC) service. If that service isn't running or isn't configured to allow network transactions, anything that uses transactions across multiple databases or servers — think BEGIN DISTRIBUTED TRANSACTION in SQL Server — will throw this code.

But it's not always MSDTC. Sometimes it's the SQL Server itself. If you're using SQLOLEDB or ODBC and the server's remote proc trans setting is off, or the XA transactions option in SQL Server is not enabled, you'll see the same error. I've also seen it with linked servers when the remote server's MSDTC isn't listening on the right ports.

The fix: step by step

First, confirm which service isn't happy. Here's the order I follow — don't skip steps.

Step 1: Check MSDTC status

Open Services.msc on the server that's rejecting transactions. Look for Distributed Transaction Coordinator. If it's not running, right-click and hit Start. Set Startup type to Automatic.

If it's running but the error persists, move to step 2.

Step 2: Configure MSDTC for network access

Open Component Services (run dcomcnfg). Drill down to Component Services > Computers > My Computer > Distributed Transaction Coordinator. Right-click Local DTC and choose Properties.

Go to the Security tab. Check these options:

• Network DTC Access — must be checked
• Allow Remote Clients — checked
• Allow Remote Administration — optional but helpful for diagnostics
• Transaction Manager Communication — pick either Allow Inbound or Allow Outbound or both, depending on which direction the transaction flows. For SQL linked servers, I usually check both.
• Enable XA Transactions — check this if you're using XA-compliant resource managers (like some Oracle or Sybase connections).

Click OK. A warning pops up about restarting MSDTC — click Yes. Then restart the MSDTC service from Services.msc.

Step 3: Verify firewall ports

MSDTC uses dynamic RPC ports by default, which is a nightmare. For production, fix the port range. In Component Services, under Local DTC Properties > Security, you'll see DTC Logon Account info — but the port config is in the registry.

Open regedit and go to:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC

Create a DWORD called ServerTcpPort and set it to a decimal value like 5000 (or whatever port you choose). Then open Windows Firewall and allow inbound TCP on that port.

Restart MSDTC again.

Step 4: SQL Server transaction settings

If your error comes from a SQL Server linked server or a remote query, check the SQL Server settings. Connect to SQL Server Management Studio (SSMS), right-click the server, go to Properties > Connections. Make sure Allow remote connections to this server is checked.

Then run this T-SQL:

EXEC sp_configure 'remote proc trans', 1;
RECONFIGURE;

Also check the linked server configuration. In SSMS, go to Server Objects > Linked Servers, right-click your linked server, choose Properties. On the General tab, ensure RPC and RPC Out are set to True. On the Server Options tab, set Enable Promotion of Distributed Transactions to True.

Step 5: Restart the application or test

After all that, restart the app that was throwing the error. If it's a SQL query, just rerun it. I usually test with a simple BEGIN DISTRIBUTED TRANSACTION to confirm the fix works:

BEGIN DISTRIBUTED TRANSACTION;
SELECT 1 AS Test;
COMMIT TRANSACTION;

Still failing? Here's what else to check

If you're still seeing 0X0000085D, check these:

• Application event logs — look for MSDTC errors like ID 4106 or 4159. They'll tell you exactly which piece of the chain is broken.
• Service accounts — MSDTC runs under Network Service by default. If your app uses a different domain account, make sure that account has rights to start MSDTC and access the network. I've seen a client where the app pool identity didn't have Log on as a service rights.
• Antivirus — some AV suites block MSDTC ports. Temporarily disable it to test.
• Time sync — if the two servers have clocks more than 5 minutes apart, Kerberos authentication fails and MSDTC refuses the transaction. Use w32tm /resync on both servers.
• SQL Server version — older SQL Server 2008 or 2008 R2 had a bug with XA transactions on Windows Server 2012+. Apply the latest service pack or upgrade.

One more thing: if you're using TransactionScope in .NET and the app is on a different machine than the SQL Server, you need MSDTC even for a single database (because the transaction is promoted to distributed). That catches a lot of people. If you can't enable MSDTC, rewrite your code to avoid distributed transactions entirely — use manual commit/rollback logic.

That's the real fix. No fluff, just the steps that work.