Fix SQL Server Error 0X00001ABD (Transaction Manager)

You're running a cross-database transaction—maybe a linked server query or a distributed transaction involving MSDTC—and boom: ERROR_TM_IDENTITY_MISMATCH (0X00001ABD). This usually hits right after a SQL Server failover, or when you've restored a database to a different server, or when someone recreated the transaction manager (MSDTC) on the machine. I've seen it on a client's setup where they moved a database from a dev box to production and forgot to re-register DTC. The error message itself says something like “The identity of the Transaction Manager is not as expected.” Not helpful, right?

What's actually happening?

SQL Server uses MSDTC (Microsoft Distributed Transaction Coordinator) to manage transactions that span multiple servers or databases. When a transaction begins, the TM creates a unique identifier (a GUID) tied to the machine and the DTC instance. If that identifier doesn't match what SQL Server expects—because the server was renamed, DTC was reinitialized, or the transaction log was replayed from a backup—SQL Server throws this error. It's basically saying, "Hey, this transaction claims to come from a TM I don't recognize."

The root cause is almost always a mismatch between the DTC's current identity and the identity recorded in SQL Server's system tables or in the transaction log. It's not a network issue, not a permissions issue—it's a trust issue at the transaction coordinator level.

How to fix it

Here's the step-by-step that works in most cases. I've done this on SQL Server 2016, 2019, and 2022—same process.

Stop SQL Server and MSDTC. Open an admin PowerShell or Command Prompt and run:
```
net stop MSSQLSERVER
net stop MSDTC
```
If you're on a named instance, replace MSSQLSERVER with your instance name (e.g., MSSQL$SQLEXPRESS).
Clear the old DTC transaction log. The log file is usually at C:\Windows\System32\MSDTC\. Delete the files MSDTC.LOG and MSDTC.SOC—but back them up first just in case. I always copy them to a temp folder, not delete outright.
Restart MSDTC with a fresh identity. Run:
```
net start MSDTC
```
This will recreate the log files with a new GUID.
Restart SQL Server.
```
net start MSSQLSERVER
```
Test a distributed transaction. Run a simple linked server query or BEGIN DISTRIBUTED TRANSACTION to see if the error clears.

If you can't stop services (production, right?), you can try an alternative: force DTC to reset its identity without full stop. In an admin command prompt:

msdtc -reset

Then restart the DTC service. This sometimes works, but I've seen it leave stale identity behind. The full stop/start is cleaner.

When it still fails

If the error persists after a DTC reset, the problem is likely the transaction log in the SQL Server database itself. The transaction that failed might have written a record that references the old TM identity, and it's stuck. Check the error log for the exact transaction ID. If it's a one-off, you can just kill the session and move on. But if it happens repeatedly, you need to dig deeper.

Here's what I'd check next:

Cluster or AG failover issues. If you're on an availability group, ensure the DTC is configured to follow the AG—you need the MSDTC resource in the cluster. If not, after a failover, the new node's DTC identity won't match. You'll need to configure DTC in the cluster (a whole other article).
Linked server configuration. Check that the linked server's rmtoverride or remote proc transaction promotion settings are set correctly. Sometimes setting remote proc transaction promotion = false on the linked server can avoid the TM mismatch altogether if you don't actually need distributed transactions.
Check the TM identity in SQL Server. Run this query to see what SQL Server thinks the TM is:
```
SELECT * FROM sys.dm_tran_active_transactions WHERE transaction_type = 2
```
If the transaction_begin_time is from before your DTC reset, that's your culprit.

If none of that helps, you might be dealing with a corrupted transaction log. That's rare, but I had a client where a bad backup restore caused this to recur. In that case, you may need to restore from a clean backup or use DBCC CHECKDB to spot corruption.

One last thing: don't ignore this error. It's not one of those you can just retry and hope. It's tied to the system's transaction infrastructure, and left alone, it'll poison every distributed transaction from that point on. Fix it once, and you're good for months.