I have a baffling issue with MSDTC
We have 4 machines in our development project but only 1 cannot negotiate a MSDTC transaction.
We are using WCF service, with multiple Linq-2-SQL DataContexts, so the transaction is being escalated to the DTC. 1 machine ( Windows 7 SP 1 ) out of 4 fails when invoking a second datacontext call.
The DB server is a Windows Server 2008 R2 / SQL Server 2008 R2
This is the event log
Source: MSDTC Client
Event ID: 4359
Task Category: MSDTC Proxy
General: “MS DTC is unable to communicate with MS DTC on a remote system. MS DTC on the primary system established an RPC binding with MS DTC on the secondary system. However, the secondary system did not create the reverse RPC binding to the primary MS DTC system before the timeout period expired. Please ensure that there is network connectivity between the two systems. Error Specifics:”
MSDTC is setup the same on all 4 machine,
Network DTC Access - Enabled
Client and Administration - Both Allow Remote Clients and Allow Remote Administration checked
Transaction Manager Communication - Allow outbound and Allow inbound checked, Mutual Authentication Required
Enable XA Transaction unchecked
Enable SNA LU 6.2 Transactions checked
All machines ( includeing the DB server ) has the DTC logon account set to NT Authority\NetworkService
I have checked that the failing machine can resolve the DB server by NETBIOS name, and that ping -a {IP} resolves the IP address back to the netbios name, and vise versa.
When the transaction is escalated to the DTC, I see an entry in the transaction list, on both client and DB server, in the form of user_transaction { SOME GUID }, which times out after about 1 minute
The DB is not logging anything on it's event logs
There is no difference if all firewalls are disabled.
Does anyone have any idea what to look at next ?
Cheers...
Robert
=== Update ===
MSDTC was incorrectly configured on the machine... the dev box was cloned from an image and replicated some internal GUIDs. Reinstalling MSDTC fixed the issue
msdtc -uninstall
msdtc -install
Related
I've got the following set up of servers:
Server A & Server B = Microsoft BizTalk 2020 servers
Server C & Server D = Microsoft SQL Server 2019 AlwaysOn Availability Group
I've set up a clustered MSDTC role and have installed Enterprise SSO on Server C & D.
I've clustered the Enterprise SSO on Server C & D (Created the SSO System on Server C, changed the server name to the MSDTC cluster accesspoint and joined the SSO system on Server D, after which I restored the master secret on that server as well).
Everything seems to be in order so far.
However, when I try setting up BizTalk on Server A and I try to Join the existing SSO System and point it to the SQL AG Listener and provide the AD user that I've set up for EntSSO I get this error:
The SSO master secret server 'clus-msdtc' specified by the SSO
database 'SSODB' on SQL Server 'clus-sql-ls' could not be found.
Without the master secret server the SSO Service cannot operate
correctly.
With a follow-up error stating:
(0xC0002A0F) Could not contact the SSO server '%1'. Check that SSO is
configured and that the SSO service is running on that server
Which in turn has a sub error:
Could not contact SSO server 'clus-msdtc'. Check that SSO is
configured and that the SSo service is running on that server. (RPC:
0x800706BA: The RPC server is unavailable)
I've tried pinging between Server A and Server C, Server A and Server D with DTCPing, works fine. The Enterprise SSO service is running and if I check the SSO Admin on Server C (the primary replica in the AG) it looks like this:
Any ideas because mine are running thin right now.
After some long and arduous troubleshooting we've finally found the root cause which was an incorrectly configured load balancer in Azure that made it fail in all RPC and MSDTC calls.
My application that runs on machine in domain uses TransactionScope (that relies on MS DTC). SQL Server runs on machine not included in domain. How to enable cooperation of MS DTC on computers that are in domain and computers not running in a Windows domain?
MSDN
When Microsoft Distributed Transaction Coordinator (MS DTC) computers are not running in a Windows domain, distributed transactions fail by default because the remote procedure call (RPC) security that MS DTC uses cannot be used in this environment. The same condition applies to MS DTC computers that are in untrusted domains. In Windows Server 2003 and Windows Server 2008, RPC security is not turned off. Therefore, distributed transactions fail in a workgroup environment or in untrusted domains
Open dcomcnfg
In the Distributed Transaction Coordinator folder under My Computer, right-click Local DTC, and then click Properties
on Security tab select the Network DTC Access check box, and then select No Authentication Required
I am trying to debug a stored Procedure from Microsoft SQL Server Management Studio 2008 which is connected to MS SQL Server 2008 Database Instance running on a different system.
System Information:
1. Remote system is running with Symantec End Point Security
I have done the following settings for running the remote debugger:
I have added the inbound Rules for TCP 139, TCP 445, UDP 137 and UDP 138 ports.
My local system's instance is running with sysadmin user role.
I have added the sqlservr.exe and svchost.exe at server windows firewall exception list.
I have added the svchost.exe and ssms.exe at client windows firewall exception list.
The SSMS and SQL server services are running in the same domain.
Following necessary services are running properly
TCP/IP NetBIOS Helper
Remote Registry
RPC Service
But after doing all these specified steps i am getting following error after clicking the debugger button in client SSMS.
Unable to start T-SQL Debugging. Could not attach to SQL Server process on 'remotesystem_name'. Click Help for more information.
If there is another alternative please let make me aware of that.
I solved this problem by creating a new login account (windows authentication account) on server for my machine.
I installed an instance of SQL Server 2008 R2 Express on my 32 bit Windows 7 machine. I can see it and connect to it with SQL Server Management Studio locally but not on the network.
SQL Server Configuration Manager Settings
SQL Server Browser is running (Log on As "NT AUTHORUITY\LocalService")
Named Pipes for this instance are Enabled
TCP/IP Enabled Dynamic ports are set to nothing the TCP Ports are set to 1433
In the Server Properties from SSMS
Connections --> I have the "Allow remote connections to this server" box checked
The Firewall is turned off for testing
When I try to see this instance with a command prompt (sqlcmd -L) from another computer I get a list of network servers. Sometimes it shows up and sometimes it doesn't. If it shows up I still can't seem to connect and the error message number is 26. If feels like there is some switch somewhere that needs to be turned on.
I am leaving this up there for any other users who have mental blocks occasionally... I had not turned off all the firewalls. In windows7 you have three different firewalls and you have to turn off the right one
I have SQL Server 2008 to which I can connect using domain user credentials. There are many computers in the network and if I login under that domain user I can successfully connect to SQL Server (using Windows Authentication).
The problem is when I use PowerShell remoting and establish remote session from computer A to computer B. When I run our dbtool that tries to connect to SqlServer (in remote session) "login failed for NT AUTHORITY\ANONYMOUS LOGON" error occurs.
It's strange, because I establish remote session under same domain user. Why ANONYMOUS is being passesd to SqlServer?
Thanks for help
And once again I'm answering my own question due to lack of other answers.
Computers communication chain: A -> B -> C.
So the problem is indeed with Kerberos authorization delegation feature (more there: http://alt.pluralsight.com/wiki/default.aspx/Keith.GuideBook/WhatIsDelegation.html). When I establish remote session from computer A to computer B, computer B sends to computer C null session (because delegation is disalloved). Thats why SQL Server on computer C sees me as NT AUTHORITY\ANONYMOUS LOGON.
My current workaround is to talk to SQL Server from computer A (copy necessary utilities there), because I have no way to enable delegation. For this scenarion computer A sends correct authorization token to computer C.
Have you tried enabling CredSSP (not supported on W2k3 though)?
## Client
Enable-WSManCredSSP -Role Client -DelegateComputer "*.domain.com"
## Server
Enable-WSManCredSSP -Role Server