STATUS_TRANSACTION_PROPAGATION_FAILED (0XC0190010): Fix Transaction Propagation Errors

Quick answer: Enable MSDTC network access on both servers, open port 135 in Windows Firewall, and ensure the SQL Server service account has Kerberos delegation rights. If the transaction still fails, check the linked server's RPC settings and the DTC log file path.

This error—STATUS_TRANSACTION_PROPAGATION_FAILED (0XC0190010)—pops up when SQL Server tries to run a distributed transaction across linked servers or remote databases. I've seen it most often in SQL Server 2019 on Windows Server 2022, especially after a server migration or a firewall update. The core problem: the local transaction manager (MSDTC) can't talk to the remote one. It's not a SQL Server bug—it's a Windows-level communication issue that trips up even senior DBAs.

You'll see this error in SSMS when running a BEGIN DISTRIBUTED TRANSACTION or a query that implicitly spans linked servers. The transaction starts locally, then fails at propagation. Frustrating? Absolutely. But the fix is systematic.

Fix Steps

1. Check MSDTC service status on both servers. Run services.msc, find "Distributed Transaction Coordinator", and ensure it's running (startup type: Automatic). If it's stopped, start it. If it fails to start, check Event Viewer for DTC-related errors—sometimes the log file at C:\Windows\System32\MSDTC is corrupt, and you'll need to msdtc -resetlog from an admin prompt.
2. Configure DTC for network transactions. Open dcomcnfg → Component Services → Computers → My Computer → Distributed Transaction Coordinator → Local DTC → right-click Properties. On the Security tab, check: Network DTC Access, Allow Inbound, Allow Outbound, and set Authentication to "No Authentication Required". I know some guides say to use Mutual Authentication Required—skip that unless your domain admin explicitly set up Kerberos. No Authentication works fine in most trusted environments and avoids headaches.
3. Open Windows Firewall port 135 on both servers. Add an inbound rule for TCP port 135 (RPC Endpoint Mapper). Also add rules for DTC dynamic ports: typically TCP ports 5000-5100, but you can lock DTC to a static port via registry (HKLM\Software\Microsoft\MSDTC\Security\LocalTransactionPortRange). If you're on a locked-down network, request the firewall team to open these ports for the specific IPs of your SQL servers.
4. Verify the linked server configuration. In SSMS, right-click the linked server → Properties → Server Options. Set "RPC Out" and "RPC" to True. For remote transactions, also set "Enable Promotion of Distributed Transaction" to True. If this option is missing (SQL Server 2014 or older), you'll need to set sp_serveroption 'linkedservername', 'remote proc transaction promotion', true.

If the error persists after these steps, move to the alternatives below.

Alternative Fixes

Fix 1: Switch to Kerberos authentication

If your environment uses domain accounts, No Authentication might fail in high-security setups. Register a Service Principal Name (SPN) for the SQL Server service account on both servers. Run setspn -A MSSQLSvc/hostname.domain.com:1433 domain\svc-sql on each. Then, in DTC properties, set Authentication to "Mutual Authentication Required". This requires the SQL Server service accounts to have Kerberos delegation rights (Trusted for Delegation in AD). I've had to do this on financial systems where No Auth was blocked by group policy.

Fix 2: Bypass the transaction altogether

This is a hack, but it works when you're stuck: If your query doesn't need atomicity across servers, set SET REMOTE_PROC_TRANSACTIONS OFF before the query. This tells SQL Server not to promote the transaction to a distributed one. Each server runs its own local transaction. Use this only for read-heavy operations or when you can tolerate partial commits.

Prevention Tip

Once you've fixed this, prevent recurrence by standardizing DTC configuration across all SQL Server instances. Create a PowerShell script that checks MSDTC service state and DTC security settings, and run it as a scheduled task. Here's a baseline snippet:

Get-Service MSDTC | Set-Service -StartupType Automatic -Status Running
Set-ItemProperty -Path "HKLM:\Software\Microsoft\MSDTC\Security" -Name "NetworkDtcAccess" -Value 1
Set-ItemProperty -Path "HKLM:\Software\Microsoft\MSDTC\Security" -Name "NetworkDtcAccessTransactions" -Value 1
Set-ItemProperty -Path "HKLM:\Software\Microsoft\MSDTC\Security" -Name "NetworkDtcAccessOutbound" -Value 1
Set-ItemProperty -Path "HKLM:\Software\Microsoft\MSDTC\Security" -Name "NetworkDtcAccessInbound" -Value 1

Also, document your firewall rules for port 135 and any DTC static port ranges. When a new server joins the cluster, apply these settings before linking it. That small step saves hours of debugging later.