Microsoft KB Archive/944390

From BetaArchive Wiki
Knowledge Base


Error message when you connect to a named instance of SQL Server on a client computer that is running Windows Vista or Windows Server 2008: "Specified SQL server not found" or "Error Locating Server/Instance Specified"

Article ID: 944390

Article Last Modified on 11/12/2007



APPLIES TO

  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition



Important This article contains information that shows you how to help lower security settings or how to turn off security features on a computer. You can make these changes to work around a specific problem. Before you make these changes, we recommend that you evaluate the risks that are associated with implementing this workaround in your particular environment. If you implement this workaround, take any appropriate additional steps to help protect the computer.

SYMPTOMS

Consider the following scenario. On a client computer that is running Windows Vista or Windows Server 2008, you connect to a named instance of Microsoft SQL Server. The named instance is located on a remote server. In this scenario, the connection may fail.

Note This problem occurs when you connect to one of the following versions of SQL Server:

  • Microsoft SQL Server 2000
  • Microsoft SQL Server 2005

If you use Windows Data Access Components (Windows DAC) 6.0 to connect to the named instance, you receive the following error message:

[DBNETLIB]Specified SQL server not found.
[DBNETLIB]ConnectionOpen (Connect()).

If you use SQL Native Client to connect to the named instance, you receive the following error message:

[SQL Native Client]SQL Network Interfaces: Error Locating Server/Instance Specified [xFFFFFFFF].
[SQL Native Client]Login timeout expired.

This problem occurs when the named instance is a failover cluster instance. Additionally, this problem may occur if the remote server has multiple IP addresses.

CAUSE

When you connect to the named instance, the client network library sends a User Datagram Protocol (UDP) request packet to the IP address of the named instance. Then, SQL Server Browser returns a UDP response packet that contains the information about the connection endpoints.

However, in the UDP response packet, the source IP address may not be the IP address to which the UDP request packet was sent. If the named instance is a failover cluster instance, the source IP address is the IP address of the physical computer instead of the virtual IP address of the remote server. If the remote server has multiple IP addresses, the source IP address may be any of the IP addresses that are assigned to the remote server.

In Windows Vista, Windows Firewall does not allow for loose source mapping. Therefore, Windows Firewall drops the UDP response packet.

For more information about loose source mapping, see the "UDP connections" section of the following Microsoft Web site:

WORKAROUND

To work around this problem, use one of the following methods.

Method 1

In the connection string, specify the TCP port number or the named pipe name to connect to the named instance.

For more information about the syntax of the connection string, see the "Creating a valid connection string" section of the following Microsoft Web site:

Method 2

Warning This workaround may make a computer or a network more vulnerable to attack by malicious users or by malicious software such as viruses. We do not recommend this workaround but are providing this information so that you can implement this workaround at your own discretion. Use this workaround at your own risk.

In Windows Firewall with Advanced Security in Control Panel, create an outgoing rule for the application that connects to SQL Server. To do this, follow these steps:

  1. In Control Panel, double-click Administrative Tools.
  2. In Administrative Tools, double-click Windows Firewall with Advanced Security.
  3. In Windows Firewall with Advanced Security, click Outbound Rules, and then click New Rule.
  4. Click Program, and then click Next.
  5. Click This program path, specify the path of the application, and then click Next.
  6. Click Allow the connection, and then click Next.
  7. Complete the steps of the New Outbound Rule Wizard.

Method 3

Warning This workaround may make a computer or a network more vulnerable to attack by malicious users or by malicious software such as viruses. We do not recommend this workaround but are providing this information so that you can implement this workaround at your own discretion. Use this workaround at your own risk.

In Windows Firewall with Advanced Security in Control Panel, create an incoming rule that allows for traffic from all possible IP addresses of the remote server or from all possible IP addresses that are configured for the failover cluster instance. To do this, follow these steps:

  1. In Control Panel, double-click Administrative Tools.
  2. In Administrative Tools, double-click Windows Firewall with Advanced Security.
  3. In Windows Firewall with Advanced Security, click Inbound Rules, and then click New Rule.
  4. Click Custom, and then click Next.
  5. Click All programs, and then click Next.
  6. In the Protocol type list, click Any, and then click Next.
  7. Under Which remote IP addresses does this rule match, click These IP addresses, and then click Add.
  8. In the IP Address dialog box, type one of the IP addresses under This IP address or subnet, and then click OK.
  9. To add other IP addresses, repeat steps 7 through 8, and then click Next.
  10. Click Allow the connection, and then click Next.
  11. Complete the steps of the New Inbound Rule Wizard.


STATUS

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.

MORE INFORMATION

For more information about Windows Firewall with Advanced Security, visit the following Microsoft Web site:

Keywords: kbexpertiseadvanced kbtshoot kbprb KB944390