I have application A and application B, both on the same server. Application A is calling WCF service, located in application B using netmsmqbinding and a private queue. B's service method, which is called, is using entity framework to make a call to the database. However, this exception is thrown in B:
System.Data.Entity.Core.EntityException: The underlying provider failed on Open.
---> System.Transactions.TransactionManagerCommunicationException: Communication with the underlying transaction manager has failed.
---> System.Runtime.InteropServices.COMException: The MSDTC transaction manager was unable to push the transaction to the destination transaction manager due to communication problems.
Possible causes are: a firewall is present and it doesn't have an exception for the MSDTC process, the two machines cannot find each other by their NetBIOS names, or the support for network transactions is not enabled for one of the two transaction managers.
This are the DTC settings - http://postimg.org/image/rzqxf17t3/
The server system administrator has ensured me it isn't a firewall issue. Therefore, I think it is this part of the exception message that I should check "the two machines cannot find each other by their NetBIOS names".
To summaries, my questions are:
How to check if the sys admin has told me the truth and check if the ports are open between the application and database server?
How to check if the problem is not related with the NetBIOS names?
If the computers are not visible with their NetBIOS names what should I do?
If I have missed to give some valuable information, then write me and I will add it.
Thank you in advance!
Related
I am trying to connect to Queue Manager using MQ api and I am able to connect to queue manager
MQQueueManager queueManager=new MQQueueManager(qmgrName);
queueManager.accessQueue(qName,MQOO_OUTPUT);
But when I try to connect to the same queue manager using JMS it fails with 2058 code.Not sure if I am missing something with JMS
MQQueueConnectionFactory qcf=new MQQueueConnectionFactory();
qcf.setQueueManager(qmgrName);
qcf.setPort(1414);
qcf.setHostname("localhost");
qcf.createQueueConnection();
You have two or more queue managers on the local host. In your first example you connect in bindings mode so the queue manager is selected by name and you get the right one. In the second example the connection is being made over a client connection and so is received by the QMgr listening on 1414 which is not the one that you intend so the connection is rejected.
Please note that if both QMgrs have a listener on 1414 the connection will succeed or fail depending on which QMgr was started first. Only one can bind to that port so the first one started on it gets to use it. This might lead to what appears to be inconsistent behavior.
Please see Connection modes for IBM MQ classes for JMS which advises "To change the connection options used by the IBM MQ classes for JMS, modify the Connection Factory property CONNOPT." The acceptable values are provided on the page but you almost always want it to set for Standard Bindings (MQCNO_STANDARD_BINDING).
As documented here, MQRC 2058 means an invalid queue manager name or the queue manager name is unknown. But as you mention, bindings mode connection using MQ Base Java is successful, the queue manager name appears valid.
Update:
Sorry, I was mislead by your code and thought you are trying to do client mode connection using JMS. You don't need to set host and port for bindings mode connection.
Since the transport type is not set, default, WMQ_CM_BINDINGS is used. Suggest you to verify the queue manager name.
To connect with "BINDINGS", the queue manager needs to be local. Are you trying to connect to a remote queue manager? If so you would need to connect as "CLIENT". Also, check to be sure the qmgr is listening on the port you specified.
We have moved our TFS data tier server to another machine. Everything was reconfigured and is working EXCEPT email alerts. Test emails are sent just fine. However, alerts are not happening. When I checked the event viewer, I'm seeing the following error:
ds:OLDSERVERINSTANCE db:Tfs_Configuration errors:-1 exception:System.Data.SqlClient.SqlException (0x80131904): A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)
So, it appears that the email is still looking at the old database (which has been retired). Where/how can I change this?
In case anyone else runs into this scenario. The TFSJobAgent wasn't smart enough on reboot to recognize the data tier change. Doing the following worked:
1. Stop iis
2. Stop the TFSJobAgent
3. Start the TFSJobAgent
4. Start iis
I have an application that can connect to the Principal, but can't connect to the Mirror during a failover.
(Note to moderator: please let me know if this question is more appropriate for serverfault. I posted it here because I found more questions similar to this issue than on serverfault.)
This is the error I receive when my application attempts to connect to the Mirror after a failover:
Named Pipes Provider: Could not open a connection to SQL Server [53].
Cannot open database "MY_DB_NAME" requested by the login. The login failed.
I am familiar with the fact that when initially connected to the Principal, the name of the Mirror server is cached to be used during the failover and that the failover partner I specify in my connection string is only used if the initial connection to the Principal fails.
This clearly describes the problem I'm having:
http://blogs.msdn.com/b/spike/archive/2010/12/15/running-a-database-mirror-setup-with-the-sqlbrowser-service-off-may-produce-unexpected-results.aspx
...but the SQL Browser Service is running and I can't figure out why the name won't resolve when connecting to the mirror.
I'm assuming there is a service that must be running to enable NetBIOS name resolution that is not running, because this is what I see in WireShark consistently without a response from the Mirror:
Source Destination Protocol Length Info
10.200.3.111 10.200.5.255 NBNS 92 Name query NB SQL-02-SVR-<00>
Question 1: What could be causing the problem? ;-)
Question 2: I really don't want to enable NetBIOS (for security reasons) and I'm using IP addresses (no FQDNs) in the mirror configuration and in the connection string. Given the caching behavior of the mirror partner when connecting to the Principal, is there a way to force TCP/IP to be used so the value that is cached is the IP address and not the name? Do I need to run the SQL Server Browser/Computer Browser services?
The configuration:
App Is Delphi XE2 using SDAC 6.5.9 (I don't think this is relevant to the component I'm using because it works in other installations with mirroring and has no issues)
SQL Server 2012 Enterprise installed as a default instance on Principal, Mirror and Witness in a non-domain configuration using certificate authentication.
Windows Server 2008 R2 SP1 64-bit on all machines
Firewalls disabled on Principal, Mirror and Client (where app is running)
TCP/IP and Named Pipes enabled on Principal and Mirror
SQL Server Browser service running on Mirror
Computer Browser service running on Mirror
Mirroring is configured for automatic failover with a witness and works properly (I can fail back and forth between mirror and principal without issue)
SQL Native Client 2012 installed on Client machine
Same app login (with same SID and user rights) exists on both Principal and Mirror
Correct server, failover partner, database name, user name and password verified in my app log
In connection string, principal server is 'tcp:10.200.3.15,1433' and failover partner is 'tcp:10.200.3.16,1433' using the SQL Native client
I can ping both servers from the Client machine
NetBIOS over TCP/IP has been enabled in the adapter under the WINS tab (on the Mirror and Client machines)
I've been able to get the application working with mirroring on several other installations, but this one is baffling me.
I found the problem, which was that the customer had the Principal and Mirror in one VLAN and the Client(s) in another. Although the IP addressing scheme was the same, the policy for communication between the VLANs prevented broadcast messages, which is why the NetBIOS query was failing on the client. A WINS or DNS server will be implemented to resolve this issue.
However, I am still interested in an answer to my Question #2, above.
We have a service that is hosted in IIS using WAS with the net.msmq binding. The service reads messages from a private transactional MSMQ queue. I need it to work by reading from a queue that is on a different machine to the service. I can get it working if the queue is on the same machine, but not if it is on a different machine.
Environment information
The servers are running Windows Web Server 2008 R2.
The servers are in a workgroup, i.e., they are not part of a domain.
MSMQ has been installed without the directory service integration feature.
I believe that the required Windows features are installed (WCF Non-Http Activation and Http Activation, Message Queuing Server, Multicasting Support, Message Queueing DCOM Proxy, Windows Process Activation Service, .NET Environment, Configuration APIs)
I have made the following registry changes on the machines:
NewRemoteReadServerAllowNoneSecurityClient = 1
NewRemoteReadServerDenyWorkgroupClient = 0
AllowNonauthenticatedRpc = 1
DTC has been enabled, with Network DTC Access, Allow Remote Clients, Allow Inbound, Allow Outbound, No Authentication Required and Enable SNA LU 6.2 Transactions all selected.
Firewall changes have been made.
Service configuration information
We are using netMsmqBinding.
The transport Security Mode of the netMsmqBinding is None.
ExactlyOnce is true
UseActiveDirectory is false
Durable is true
The queue address is net.msmq://the-host-computer-name/private/EmailAsyncService
WCF logging
There is a warning:
Cannot detect if the queue is transactional". The FormatName of the queue in the error is DIRECT=OS:the-host-computer-name\private$\EmailAsyncService
There is then an error:
An error occurred when converting the 'the-host-computer-name\private$\EmailAsyncService' > queue path name to the format name: Unrecognized error -1072824300 (0xc00e0014). All operations on the queued channel failed. Ensure that the queue address is valid. MSMQ must be installed with Active Directory integration enabled and access to it is available.
What I have tried
I can read messages from the remote queue from the machine the service is on if I manually create and use a MessageQueue instance.
I've tried hosting the service as a standalone console application. The error messages are the same.
I have tried disabling the firewalls involved.
I've tried the changes on http://msdn.microsoft.com/en-us/library/ms752246.aspx, which relate to running such services on a computer joined to a workgroup. ("both the activation service and the worker process must be run with a specific user account (must be same for both) and the queue must have ACLs for the specific user account... In workgroup, the service must also run using an unrestricted token.") The user account I'm currently using is Network Service.
Some thoughts
I don't believe that there is a firewall or permissions issue.
Despite the fact that the service configuration has UseActiveDirectory set to false, the queue address of net.msmq://the-host-computer-name/private/EmailAsyncService seems to be getting translated into the-host-computer-name\private$\EmailAsyncService, which AFAIK is a name format that requires lookup via Active Directory.
I'm a little late here, but since you have no other answers, I may still be of help.
You might want to try enabling Directory Service Integration, as I believe you need to muck with certificates to operate in Workgroup Mode.
Also, Juval Lowy's WCF book makes it clear that when you have queued services hosted in WAS you have to name the queue the exact same as the virtual path to your svc file. So if your service is actually hosted at /EmailAsyncService/EmailService.svc then that's precisely what you need to name your queue (without the first slash).
A little background:
I have a Windows .NET application that is in use by approximately 40 field employees across North America. This program allows the users to enter data while in the field (away form internet access) and then synchronizes to our Sql Server 2005 database at night. A couple days ago, two of my users reported getting the following error when they performed an action that would attempt to connect to our server database (which uses .NET's SqlConnection class).
System.Data.SqlClient.SqlException: A
network-related or instance-specific
error occurred while establishing a
connection to SQL Server. The server
was not found or was not accessible.
Verify that the instance name is
correct and that SQL Server is
configured to allow remote
connections. (provider: Named Pipes
Provider, error: 40 - Could not open a
connection to SQL Server)
Our field employees are typically operating on a hotel Wi-Fi connection, and at first I thought that they both coincidentally got on an "uncooperative" network the same day. The following day, having moved to different hotels, the problem went away for one of these users, but continued for the other.
Besides providing the error message, the purpose of this background is to point out that
this is the first time this issue has occurred in over a year of using this software, and
the majority of our users aren't having any problem connecting to our server database with the same software.
This makes me hesitate to think that the issue is at the server (most forums and blogs I've read on this error provide steps to ensure the SQL Server is configured properly).
Noticing the Named Pipes Provider portion of the error message, I guessed that maybe this user's computer or network was causing it to attempt connection via pipes rather than TCP, so I did try configuring the server to allow BOTH TCP/IP and Named Pipes for remote connections, where it was previously set to TCP/IP only. The error continued for this one user after changing this setting.
So now I'm left to brainstorm about what could be special about this one user's computer / software / internet connection that would hinder it from being able to connect to our SQL Server.
Our connection string does use our server's URL (not IP address), and I wondered if his laptop was having problems finding it by that address. However, he was able to access a website hosted from the same URL, so I guess the problem is somewhere else.
Any ideas would be greatly appreciated. Thanks!
You've probably long since solved this problem by now or moved on, but for those having similar problems with the Error 40/named pipes issue when connecting to a SQL server instance, the following simple solution worked for us:
You can force your client program to use TCP (or named pipes, or other available methods) by adding a prefix in your connection string.
For the .NET SQLConnection example, specify in the SQLConnection's connection string like so:
Server=tcp:192.168.0.1;Integrated Security=SSPI; database=sampledb
See this blog entry for more info.
Is it possible that they are being blocked by the hotel's firewall, which may only allow traffic on certain ports?