SQL error -1: SQL Network Interfaces: Error Locating Server/Instance Specified [xFFFFFFFF]. Server : Server A\SQL01 Windows authentication 04/10/2012 17:13:12: Failed to connect to SQL Server instance: Server A\SQL01
Another observation made when testing connectivity to the SQL 2005 Instances using the Surface Area configuration tool, was that when directed to a specific cluster name such as ClSvr01 it would return the instance name of SQL02 which is not present within ClSvr01. This would be the case for all instances that I tried to connect to while on Server A, performing the same actions from Server B worked as would be expected.
By disabling Named Pipes for the specified instance and this seems to have resolved the issue with the Surface Area Configuration tool but not the backup software.
Connection to all instances via SSMS using TCP/IP or Named Pipes is fine, and running queries such as SERVERPROPERTY and @@SERVERNAME return the results I would expect to see with regards to the server knowing who it is. There are no entries in the host files or anything like that.
I am unable to replicate this issue within any of my testing VM systems so am not 100% sure where else to look.
I have now found a workaround that gets the node that was causing me a problem up and running. If you go into the properties of the SQL Backup agent clustered resource and check the option to "Use Network Name for computer name" it should get you up and running.
I am still looking into why this worked on one node and not the other with it unchecked, and should I find anything I will post a comment to this.
I stumbled over this while doing a totally manual install of the cluster components.
answered Oct 08 '12 at 01:03 PM
I recall having to go through a server rename process on older versions of SQL Server to change the servername from the individual server within the cluster to the name of the cluster.
You'll need to carry out the process with SQL running on each of the two servers in the cluster.
We had similar problems with Quest's LiteSpeed for SQL Server, and this fixed it.
Check for entries in an LMHOSTS or HOSTS file.
answered Oct 04 '12 at 05:13 PM