sql-serverdistributed-transactionsmsdtc

The operation could not be performed because OLE DB provider "SQLNCLI11" for linked server was unable to begin a distributed transaction

I'm trying to run a distributed transaction from my machine (SQL Server 2012) to a client server (SQL Server 2008).

I'm trying to run:

begin distributed transaction
select * from [172.01.01.01].master.dbo.sysprocesses
Commit Transaction

and I get:

OLE DB provider "SQLNCLI11" for linked server "172.01.01.01" returned message "No transaction is active.".
Msg 7391, Level 16, State 2, Line 2
The operation could not be performed because OLE DB provider "SQLNCLI11" for linked server "172.01.01.01" was unable to begin a distributed transaction.

I can run a SELECT to that server with data coming back, so at least I know the servers can see each other, and the Linked Server exists and is operating

Now, there are multiple posts on the web for this, but I can't get it to work. This is what I have tried so far:

  1. Set DTC properties to the following (on both server) enter image description here

  2. Restarted the Distributed Transaction Coordinator (MSDTC) from Control Panel -> Services (on both servers).

  3. Uninstalled and installed DTC (on both servers).

  4. Restarted the remote server.

  5. Turned off the firewall on both servers.

  6. Enabled sp_configure 'Ad Hoc Distributed Queries', 1 (on both servers).

  7. I ran DTCPing and it pinged successful.

  8. Linked server properties changed to the following: enter image description here

What else are there to try?

UPDATE: Running the transaction from another server to 172.01.01.01 works. Therefore the issue is not on the destination server, but on my machine which is the source.

Solution

  • If after configuring your MS Distributed Transaction Coordinator (MSDTC) on the two SQL server's according to the OP's original post, you still get "no transaction active", you should check that each host is reachable via the IP (assuming that's what you've used) registered in the linked server.

    For example; on a recent setup, two SQL servers were reachable through a network in the 192.168.200.x range (same subnet), but each server was also indirectly connected through an IP in the 10.x.x.x range. On one SQL Server, the DNS server it used kept resolving the target SQL server to it's 10.x.x.x IP (which was firewalled) even though the linked server entry used the IP in the 192.168.200.x of the target server.

    It appears that MSDTC uses the hostname of the server, while SQL server connects over any linked connection using the IP or hostname defined in the linked server entry, leading to this confusing behaviour of apparent connectivity when checking the target linked server within SQL Management Studio, but inability to execute remote procedures on the target.

    The solution was to add entries in the host file's (%windir%\system32\drivers\etc\hosts) to explicitly force each SQL server to resolve the other to the IP address on the 192.168.200.x network.

    On host 1 (IP 192.168.200.15):

    # TARGET SERVER
192.168.200.20    targetserverhostname.and.any.domain.suffix  targetserverhostname

    On host 2 (IP 192.168.200.20) 

    # SOURCE SERVER
192.168.200.15    sourceserverhostname.and.any.domain.suffix sourceserverhostname

    Don't forget to ensure MSDTC has been configured according to the OP's screenshot above allowing network access and (if required) No Authentication.