SQL Server | Server Error 26 | Liongard Support Portal

Overview 💥

Error :

Connectivity test failed. Exception: 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)

What it means: The client (Liongard Inspector / agent host) could reach the machine but could not locate the requested SQL Server instance — either because the instance name is wrong, the SQL Browser/service that resolves named instances is not available, network/firewall is blocking access, or the instance isn’t listening on the expected port.

Why this happens? 🤔

Incorrect Instance name entered in the Inspector template (including extra path, trailing slash, or whitespace).
SQL Server service is stopped on the target host.
Named instance is used but SQL Server Browser service is stopped (so client can’t discover the port).
TCP/IP (or Named Pipes) protocol is disabled for that instance.
Firewall or network rules blocking the SQL port (default TCP 1433 for default instance; named instances use dynamic ports unless configured).
DNS or routing issues (hostname not resolving).
If the Instance field is left when you intended to target the default instance (or vice-versa).

Quick guidance 🤩

If you want the default instance, leave the Instance field empty in the Inspector.
If you target a named instance, ensure the exact instance name (e.g., SQLSERVER01\SQLEXPRESS) is used and SQL Browser is running or a static port is set and used.
Verify the SQL Server service and networking (TCP) are enabled and reachable from the Agent host.

Steps To Resolve 👨‍💻

1️⃣ Confirm the basic facts

Confirm the hostname/IP and instance name that the Inspector is using.
- If the Inspector template's Instance field is empty → it will try the default instance.
- If you specified MACHINE\INSTANCE, ensure that is exactly correct.

2️⃣ Can the Agent host reach the server (network)?

Run these from the Agent server (the machine that runs Liongard’s agent).

Test DNS:
nslookup <sql-hostname>
or
ping <sql-hostname> (ping may be blocked by firewall but useful if it responds)
Test port connectivity:
- PowerShell: Test-NetConnection -ComputerName <sql-hostname> -Port 1433
- telnet (if available): telnet <sql-hostname> 1433
- Linux: nc -zv <sql-hostname> 1433

If the named instance uses a non-standard port or dynamic port, replace 1433 with the configured port.

3️⃣ Confirm SQL Server service & instance name on the target host

On the SQL server (or ask the DBA):

Open SQL Server Configuration Manager or Services.msc and verify the SQL Server instance is running.
Verify the correct instance name (e.g., MSSQLSERVER is the default instance — do not use MSSQLSERVER in the Inspector Instance field; leave it empty for default).

4️⃣ SQL Server Browser (named instances)

Named instances often use dynamic ports. The SQL Server Browser service tells clients what port a named instance listens on.
- Ensure SQL Server Browser is Running.
- If you cannot run SQL Browser (security policy), assign a static port to the instance and use that port in the Inspector configuration.

5️⃣ Verify network protocols (TCP/IP / Named Pipes)

In SQL Server Configuration Manager → SQL Server Network Configuration → Protocols for <INSTANCE>:
- Ensure TCP/IP is Enabled (most Inspectors use TCP).
- If using Named Pipes, ensure Named Pipes is enabled and accessible; TCP is preferred.
If you enabled TCP/IP, restart the SQL Server service after changes.

6️⃣ Firewall and routing

Ensure the SQL Server host allows inbound traffic on the instance port:
- Default instance: TCP 1433 (inbound)
- Named instances: dynamic port (or configured static port) — open the port used
If reverse proxies, NAT, VPNs, or ACLs exist, validate port forwarding and routing.

8️⃣ Try explicit port (if Browser is not available)

If SQL Browser is not running or you prefer explicit ports, set the Inspector host URL using the port:

Example: sqlserver.example.com,14330 (use hostname,port format where supported)
When using explicit ports, the Inspector will connect directly and not rely on SQL Browser.

8️⃣ Confirm “Allow remote connections”

In SQL Server Management Studio (SSMS): Server → Properties → Connections → Allow remote connections to this server must be checked.

9️⃣ Re-run the Inspector in Clear Cache + Debug mode

After making changes, run the Inspector with Clear Cache + Debug to collect fresh logs and to confirm success.

Useful commands 🤩

From Agent server (Windows PowerShell):

# DNS
nslookup sqlserver.example.com

# Test TCP port (replace port if needed)
Test-NetConnection -ComputerName sqlserver.example.com -Port 1433 -InformationLevel Detailed

From Linux agent or workstation:

# DNS
dig +short sqlserver.example.com

# Test TCP port
nc -zv sqlserver.example.com 1433

# or
telnet sqlserver.example.com 1433

On SQL Server host (check service & Browser):

Services.msc → check SQL Server (<INSTANCE>) is Running
Services.msc → check SQL Server Browser is Running (for named instances)

Check instance port (SQL Server Configuration Manager):
SQL Server Network Configuration → Protocols for <INSTANCE> → TCP/IP → IPAll → TCP Port (set static port if desired)

Troubleshooting quick-reference 🚀

Symptom	Likely cause	Quick fix
Error 26, Inspector uses `MACHINE\INSTANCE`	Named instance name incorrect or SQL Browser off	Verify exact instance name; start SQL Server Browser, or set static port
Telnet / Test-NetConnection fails to port 1433	Firewall/routing blocking	Open port on firewall; check NAT/port forwarding
Connection works locally on SQL server but not from Agent host	SQL server listening on localhost only / TCP disabled	Enable TCP/IP and restart SQL service
Default instance intended but ‘Instance’ field filled	Inspector targets wrong instance	Clear Instance field to target default instance

When to contact Liongard Support 🦁

Contact Support if you’ve tried the steps above and Inspector still fails. Include:

Inspector name & Environment in Liongard.
Exact error message and a screenshot of the Inspector log.
Clear Cache + Debug run logs (attach the debug output).
Results of network tests run from the Agent host:
- Test-NetConnection or telnet/nc output to the SQL host & port.
- nslookup or dig results.
SQL Server information:
- OS host FQDN or IP; SQL Server version (e.g., SQL Server 2019 CU#).
- Instance name and whether SQL Browser is running.
- Whether the instance uses a static port (and which port).
Any recent changes: firewall rules, SQL patching, DNS changes, or NAT changes.

Having these in advance speeds triage and resolution.

Additional notes & best practices 🌟

For default instances, leave the Inspector Instance field empty.
For named instances, use the exact instance name: HOSTNAME\INSTANCE.
If security policy prohibits SQL Browser, configure a static port and open that port through firewalls. Document that port in your runbook.
Prefer TCP/IP protocol and explicit ports for reliability.
Keep a small troubleshooting checklist near the environment (service status, SQL Browser, TCP enabled, firewall rules, DNS).

Summary 🧑‍🏫

Agent → resolve hostname? ──No──> Fix DNS/routing
            │ Yes
            ▼
   Test port (1433 / configured) ──No──> Open firewall / check NAT / confirm port
            │ Yes
            ▼
  Is instance named? ──Yes──> Is SQL Browser running? ──No──> Start Browser or use static port
            │                                │ Yes
            │                                ▼
            └─No─────────────────────────────> Confirm TCP/IP enabled & Allow remote connections

References (for further reading) 📚

Third-Party Link Disclaimer ‼️

We may reference external third-party resources solely as additional guidance.

Liongard does not own, control, or guarantee the accuracy, security, or reliability of third-party sites. Please use them at your own discretion and risk.