Error Locating Server/Instance Specified (Error 26)

You connected to a named instance, something like SQLPROD01\SALES, and the client could not find out which port it listens on. Nothing reached SQL Server, so nothing was logged. Check the instance name, then the Browser service, then UDP 1434, or skip all three by putting the port in the server name.

That is the System.Data.SqlClient text, also listed on the network-related error page on MS Docs. sqlcmd and ODBC show the same fault as Error Locating Server/Instance Specified [xFFFFFFFF].

What the Client Was Trying to Do

A named instance has no port in its name. Before it can connect, the client sends a UDP message to port 1434 on the server, and the SQL Server Browser service answers with the instance’s TCP port, as the SQL Server Browser service page on MS Docs describes. No answer, or no instance by that name, and the client gives up with error 26 when the login timeout runs out. The default instance on the same machine still connects, because it does not need the Browser.

Check the Instance Name

A typo gets exactly the same error 26 as a stopped Browser, so rule it out first. On the server, the service name carries the instance name: MSSQL$SALES is the instance SALES, and MSSQLSERVER is the default instance, which you connect to with the machine name alone.

Get-Service MSSQL*

If the name is right, MS Docs lists one more server-side cause: the instance is hidden, so the Browser does not announce it. Clients then need the port.

Check the Browser Service Is Running

On the server:

Get-Service SQLBrowser

Stopped means no named instance on that machine can be found by name. Set it to Automatic and start it in SQL Server Configuration Manager. Some estates leave it off on purpose: the MS Docs firewall page recommends keeping the Browser stopped and connecting with the port number for the most secure setup. If that is your standard, the fix is the port, not the service.

Check UDP 1434 Is Open

The Browser can be running and still unreachable. The lookup is UDP, so a firewall rule for TCP 1434 does nothing, and Test-NetConnection cannot check it because it only tests TCP. Open UDP 1434 inbound on the server, plus the instance’s TCP port, as the firewall page sets out. To test UDP 1434 from the client, MS Docs uses PortQry.

Skip the Browser With the Port

Put the port after the server name and the client never asks the Browser:

sqlcmd -S "tcp:SQLPROD01,50123" -E -C -Q "SELECT @@SERVERNAME"

If the port works and the name does not, the Browser or UDP 1434 is the problem, the same test MS Docs gives. Two things to know before you hard-code it:

• The instance name is ignored once a port is given. On the lab, HPAI01\NOPE,1433 connected to the default instance, and there is no instance called NOPE. Check @@SERVERNAME on the connection.
• Named instances use dynamic ports by default, and a dynamic port can change on restart (MS Docs). Set a static port first; SQL Server Default Ports covers it.

Frequently Asked Questions