Fix SQL Server does not exist or access denied error

You're sitting at your desk, trying to connect to SQL Server from SQL Server Management Studio (SSMS). You type in the server name—maybe it's something like MYPC\SQLEXPRESS or just localhost—and click Connect. Instead of getting a database, you see this: "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." The bottom line: SQL Server does not exist or access denied.

I've seen this happen most often when someone installs SQL Server with a named instance (like SQLEXPRESS or DEV2022) and then tries to connect from another machine. Or even from the same machine, if they're using a firewall or forgot to start the SQL Server Browser service. The error is frustrating because it doesn't tell you which part is broken. It's like your car won't start and the dashboard just says "problem." Let's cut through that.

Root cause

The real cause is almost always one of two things:

SQL Server Browser service is stopped. This service listens on UDP port 1434 and tells clients what TCP port each SQL Server instance is using. If it's off, the client can't find the instance.
TCP/IP is disabled for the SQL Server instance. Even if the Browser service is running, if TCP/IP is turned off in SQL Server Configuration Manager, the client can't connect over the network.

Sometimes it's both. Rarely, it's a firewall blocking port 1433 (the default TCP port for SQL Server). But let's start with the two most common issues.

How to fix it

Follow these steps in order. After each one, try connecting again. Don't skip ahead—each step builds on the last.

Open SQL Server Configuration Manager. You'll find it in the Start menu under "Microsoft SQL Server [year]" → "Configuration Tools." If you can't find it, press Windows + R, type SQLServerManager16.msc (for SQL Server 2022, use 16; for 2019, use 15; for 2017, use 14), and hit Enter.
Check the SQL Server Browser service. In the left pane, click "SQL Server Services." In the right pane, look for "SQL Server Browser." See its status? If it says "Stopped," right-click it and choose "Start." Wait a few seconds—you should see a progress bar, then the status changes to "Running." Now set it to start automatically: right-click again, choose "Properties," go to the "Service" tab, and change "Start Mode" to "Automatic." Click OK.
Enable TCP/IP for your instance. Still in Configuration Manager, click "SQL Server Network Configuration" in the left pane. You'll see a list of instances—like "Protocols for MSSQLSERVER" or "Protocols for SQLEXPRESS." Click the one that matches your instance. In the right pane, find "TCP/IP." If it says "Disabled," right-click it and choose "Enable." You should see a warning box pop up saying the change won't take effect until the service is restarted. Click OK.
Restart the SQL Server instance. Go back to "SQL Server Services" in the left pane. Right-click your instance (it'll be named something like "SQL Server (SQLEXPRESS)") and choose "Restart." This might take 10-20 seconds. After it restarts, the status should say "Running." Now close Configuration Manager.
Try connecting again. Open SSMS, enter your server name (use the same format as before), and click Connect. If you get in, you're done. If not, move to the next step.
Check Windows Firewall. Press Windows + R, type wf.msc, and hit Enter. In the left pane, click "Inbound Rules." Look for rules that mention "SQL Server" or port 1433. If you don't see any, you'll need to add one. Click "New Rule" in the right pane. Choose "Port," then click Next. Select "TCP" and type 1433 in the "Specific local ports" box. Click Next. Select "Allow the connection." Click Next. Make sure Domain, Private, and Public are all checked. Click Next. Give it a name like "SQL Server TCP 1433" and click Finish.
Test the connection again. In SSMS, if you're using a named instance like MYPC\SQLEXPRESS, try using the format MYPC,1433 (comma, not colon). If that works, the Browser service might still not be running, or the instance isn't listening on the default port. You can verify the port by going back to Configuration Manager: click "SQL Server Network Configuration" → "Protocols for [your instance]" → right-click "TCP/IP" → "Properties" → "IP Addresses" tab. Scroll to the bottom. Under "IPAll," look for "TCP Dynamic Ports." If it's blank, the instance is using the static port 1433. If there's a number there (like 49172), that's the dynamic port—and you'll need to either set a static port or ensure the Browser service is running.

What if it still fails?

If you've done all that and still can't connect, you're dealing with something trickier. Here's what to check:

Is the SQL Server service actually running? Open Windows Services (type services.msc in Run). Find your SQL Server instance service. If it's not running, start it.
Are you using the right credentials? Try "Windows Authentication" first. If that fails, check if SQL Server is in mixed mode—you can verify this in SSMS under server properties (but you need to be connected first, which is a chicken-and-egg problem). If you suspect credential issues, connect locally with Windows Auth first.
Is the instance name correct? Run SQLCMD -L from a command prompt. It lists all SQL Server instances on the network. If yours isn't listed, the Browser service is still off or the firewall is blocking UDP 1434.
Is there a third-party firewall? Antivirus software often includes firewall features. Temporarily disable it to test—if that fixes it, you'll need to add an exception for SQL Server.
Is this happening on the same machine? If you're trying to connect locally, try using . (dot) or (local) instead of the machine name. Sometimes a Windows update changes how hostnames resolve.

I've seen this error countless times, and it's almost always the Browser service or TCP/IP. Start there, and you'll save yourself hours.