Error 7391 – The operation could not be performed because OLE DB provider “MSOLEDBSQL” for linked server “xxx” was unable to begin a distributed transaction.

How to Fix SQL Server Error 7391: Distributed Transaction Issues with MSDTC

When executing updates through a linked server or performing operations that span multiple data sources in SQL Server, you may encounter the following error:

OLE DB provider "MSOLEDBSQL" for linked server "xxx" returned message "The partner transaction manager has disabled its support for remote/network transactions.".

Msg 7391, Level 16, State 2, Line 3
The operation could not be performed because OLE DB provider "MSOLEDBSQL" for linked server "xxx" was unable to begin a distributed transaction.

This article explains the background of Error 7391, the concept of distributed transactions, the role of MSDTC (Microsoft Distributed Transaction Coordinator), and practical steps to resolve the issue. The initial message “The partner transaction manager has disabled…” is a classic sign that MSDTC is either disabled or not allowed for network access.

Table of Contents

  1. What is a Distributed Transaction?
  2. The Role of MSDTC (Two-Phase Commit)
  3. Common Scenarios for Error 7391
  4. Resolution Steps (Checklist)
  5. How to Verify

1. What is a Distributed Transaction?

A local transaction is confined to a single database. However, when updates span across multiple data sources, a distributed transaction is required to maintain consistency. Examples include:

  • SQL Server → another SQL Server (via linked server)
  • SQL Server → another database product (Oracle / MySQL, etc.)
  • Cross-instance updates or combined operations with message queues

A distributed transaction guarantees all succeed or all roll back, across the network as a single unit of work.

2. The Role of MSDTC (Two-Phase Commit)

In a distributed transaction, multiple servers or databases participate in a single logical transaction.
If one server commits while another fails, data inconsistency occurs.
To prevent this, the Two-Phase Commit protocol (2PC) is used, coordinated by MSDTC.

Phase 1: Prepare

  1. When a transaction begins, MSDTC asks all participating servers: “Are you ready to commit?”
  2. Each server logs the transaction and responds either “Yes, I can commit (OK)” or “No (NG)”.

No data is actually committed yet — servers simply move into a “ready-to-commit” state.

Phase 2: Commit

  • If all servers respond OK: MSDTC instructs all participants to commit, and changes are finalized.
  • If even one server responds NG: MSDTC instructs all participants to roll back, ensuring no partial changes.

This ensures the transaction follows an All-or-Nothing rule, maintaining data integrity across systems.

Example Scenario

Suppose you insert an “Order” record on Server A and update “Inventory” on Server B within one transaction:

  • If Server A succeeds but Server B fails, the data is inconsistent.
  • With MSDTC and 2PC, either both succeed or both are rolled back, ensuring consistency.

3. Common Scenarios for Error 7391

  • Executing UPDATE/INSERT/DELETE through a linked server (even without explicit BEGIN DISTRIBUTED TRANSACTION, transactions may be implicitly promoted).
  • Running a transaction that spans multiple resources (databases, message queues, etc.).

4. Resolution Steps (Checklist for Both Servers)

4.1 Services and Basic Settings

  1. Start the MSDTC service
    Check in services.msc that Distributed Transaction Coordinator is running.
    You can also verify with: sc query msdtc
  2. Enable Network DTC Access
    dcomcnfg → Component Services → Computers → My Computer → Distributed Transaction Coordinator → Local DTC → Right-click Properties → Security tab:
    • Network DTC Access (On)
    • Transaction Manager Communication: Allow Inbound / Allow Outbound
    • Authentication: No Authentication
    • Restart the MSDTC service after changes
  3. (Optional) XA Transactions
    Enable only if required for XA-compliant systems. Not typically needed for SQL Server-to-SQL Server scenarios.
  4. DTC Logon Account
    The default Network Service is sufficient.

4.2 Firewall and Connectivity Tests

  • Allow TCP 135 (RPC Endpoint Mapper)
  • DTC also uses dynamic DCOM ports (default: 49152–65535/TCP). Consider narrowing the range or fixing ports per your security policy.
  • Enable the predefined Windows Firewall rule “Distributed Transaction Coordinator” for simplicity.

Connectivity test (one server to the other):

# Check if port 135 (RPC) is open
Test-NetConnection hostName -Port 135

4.3 Name Resolution (NETBIOS Names)

MSDTC communication requires NETBIOS short names (not FQDNs).

  • Resolution methods:
    • On the same subnet: resolution may occur via NetBIOS over TCP/IP or LLMNR.
    • To be certain: edit each server’s hosts or lmhosts file with IP <tab> HOSTNAME (do not use FQDN).
  • Verification commands:
    • ping HOSTNAME (short name)
    • nbtstat -a HOSTNAME (check NetBIOS name table)
    • ping -a <IP> (reverse lookup should return the short name)
  • Important: In some environments, DNS with FQDN may take precedence. Ensure short names are used (e.g., register only short names in hosts).

5. How to Verify

With two SQL Servers (linked server linkServerName), test with an update statement:

BEGIN TRAN;

-- Updating a remote table (updates are commonly promoted to distributed transactions)
UPDATE [linkServerName].[dbName].[dbo].[tableName]
   SET Col = 'value'
 WHERE Id = 1;

COMMIT;

If error 7391 does not occur, the distributed transaction has been successfully started.
To explicitly test:

BEGIN DISTRIBUTED TRANSACTION;

UPDATE [linkServerName].[dbName].[dbo].[tableName]
   SET Col = 'value'
 WHERE Id = 1;

COMMIT TRANSACTION;