SQL Server service is stopped. The Windows service MSSQLSERVER (default instance) or MSSQL$INSTANCENAME (named instance) is not running. This is the most common cause — the service may have crashed, been stopped manually, or failed to start after a server reboot.. SQL Server is listening on a non-standard or dynamically assigned port. By default SQL Server uses TCP 1433, but named instances use a dynamic port assigned at startup. If the port changed (e.g. after a reinstall or config change) and the connection string still specifies the old port, every connection is refused.. SQL Server Browser service is stopped. Named instances rely on the Browser service (UDP 1434) to resolve the instance name to the correct TCP port. If Browser is stopped, clients cannot discover the port and fall back to 1433, which may not be where the named instance listens.. A firewall rule blocks the SQL Server port on the server side. Windows Firewall or a network-level firewall drops the incoming TCP packet, but unlike a silent drop the local Windows TCP stack returns a RST if the port has no listener — so the error manifests as 10061 rather than a timeout.. The connection string points to the wrong host or instance name. A stale hostname in a linked service, a DNS change that hasn't propagated, or a copy-paste error in the server name causes the connection to reach the right machine but the wrong port — or a machine that has no SQL Server at all.. SQL Server is bound only to a specific IP address (e.g. 127.0.0.1 or a secondary NIC) and the client is connecting via a different IP. This happens after network reconfiguration or when SQL Server Configuration Manager has specific IP bindings enabled and IPAll is disabled.. The SQL Server instance was installed on a non-standard port (e.g. 1434 is reserved for Browser, so DBAs sometimes choose 1435 or 14330) and a connection string template from another environment with port 1433 was reused without updating the port.

Step 1 — Confirm SQL Server is running on the target host. On the server: open services.msc and check that 'SQL Server (MSSQLSERVER)' or 'SQL Server (INSTANCENAME)' shows Status = Running. Remotely via PowerShell: Get-Service -ComputerName -Name 'MSSQLSERVER' | Select-Object Status. If stopped, right-click → Start, or run as admin: net start MSSQLSERVER (default) / net start MSSQL$INSTANCENAME (named).. Step 2 — Find the actual port SQL Server is listening on. Open SQL Server Configuration Manager → SQL Server Network Configuration → Protocols for → TCP/IP → double-click → IP Addresses tab → scroll to IPAll → read TCP Port (static) or TCP Dynamic Ports (if 0, a dynamic port was assigned). Alternatively query the error log: xp_readerrorlog 0, 1, N'Server is listening on'; the log line shows the actual port at startup.. Step 3 — Verify the port is reachable from the client. From the pipeline host or gateway machine run: Test-NetConnection -ComputerName -Port . A TcpTestSucceeded = False with 'Connection refused' confirms the port is closed. If TcpTestSucceeded = True, the issue is at the driver or authentication layer, not the TCP connection.. Step 4 — Check and fix the connection string port. In Azure Data Factory: open the linked service, expand Advanced, and confirm the port field matches what was found in Step 2. In Power BI Desktop: Data Source Settings → Edit → Server field — use the syntax , (comma, not colon). In SSIS: open the Connection Manager, edit the connection string property directly.. Step 5 — If using a named instance, confirm SQL Server Browser is running. On the server: services.msc → SQL Server Browser → Status should be Running. Start it with: net start SQLBrowser. Then retry the connection using the instance name (e.g. SERVER\INSTANCENAME) without specifying a port and let Browser resolve it.. Step 6 — Check firewall rules on the server. Run on the server: netsh advfirewall firewall show rule name=all | findstr -i '1433'. If no inbound rule exists for the SQL Server port, add one: New-NetFirewallRule -DisplayName 'SQL Server 1433' -Direction Inbound -Protocol TCP -LocalPort 1433 -Action Allow. For named instances, also open UDP 1434 for Browser.. Step 7 — Validate the fix end-to-end. From the pipeline host: sqlcmd -S , -U -P -Q 'SELECT @@VERSION'. A successful response confirms the port is open, the service is running, and credentials are accepted. Then trigger the ADF pipeline or Power BI refresh manually and confirm it completes without error 10061.

Critical severityconnection

SQL Server Error:
10061, SQL Server Not Running

Impact

Every pipeline run fails immediately with this error — ADF activities abort in under a second, Power BI scheduled refreshes fail at the first retry, and no data reaches downstream tables. If this error appears mid-day on a server that was working, treat it as an outage: the database is completely unavailable to all consumers, not just your pipeline.

ADF pipelines fail on the first Copy or Lookup activity touching the SQL Server source — no data is read, no sink is written. ADF retries according to the activity retry policy (default: 0 retries); if retries are configured the pipeline waits the backoff interval before each attempt, all of which fail identically. Downstream datasets that depend on refreshed tables remain stale for the entire outage window. If the pipeline feeds a Power BI dataset on a scheduled refresh, that refresh also fails, and reports show data from the last successful run without any in-product warning to end users.

What does this error mean?

Windows socket error 10061 (WSAECONNREFUSED) means the target host actively rejected the TCP connection — the port is closed, not filtered. In a data pipeline context this typically means the SQL Server service is not running or is bound to a different port than the connection string specifies. Unlike a timeout (10060), a connection refusal is immediate: the operating system on the target machine sends back a TCP RST packet. ADF activities fail within milliseconds, Power BI refreshes abort at the connection phase, and SSIS packages throw a pre-login error. The database never received the request.

Common causes

1SQL Server service is stopped. The Windows service MSSQLSERVER (default instance) or MSSQL$INSTANCENAME (named instance) is not running. This is the most common cause — the service may have crashed, been stopped manually, or failed to start after a server reboot.
2SQL Server is listening on a non-standard or dynamically assigned port. By default SQL Server uses TCP 1433, but named instances use a dynamic port assigned at startup. If the port changed (e.g. after a reinstall or config change) and the connection string still specifies the old port, every connection is refused.
3SQL Server Browser service is stopped. Named instances rely on the Browser service (UDP 1434) to resolve the instance name to the correct TCP port. If Browser is stopped, clients cannot discover the port and fall back to 1433, which may not be where the named instance listens.
4A firewall rule blocks the SQL Server port on the server side. Windows Firewall or a network-level firewall drops the incoming TCP packet, but unlike a silent drop the local Windows TCP stack returns a RST if the port has no listener — so the error manifests as 10061 rather than a timeout.
5The connection string points to the wrong host or instance name. A stale hostname in a linked service, a DNS change that hasn't propagated, or a copy-paste error in the server name causes the connection to reach the right machine but the wrong port — or a machine that has no SQL Server at all.
6SQL Server is bound only to a specific IP address (e.g. 127.0.0.1 or a secondary NIC) and the client is connecting via a different IP. This happens after network reconfiguration or when SQL Server Configuration Manager has specific IP bindings enabled and IPAll is disabled.
7The SQL Server instance was installed on a non-standard port (e.g. 1434 is reserved for Browser, so DBAs sometimes choose 1435 or 14330) and a connection string template from another environment with port 1433 was reused without updating the port.

How to fix it

1Step 1 — Confirm SQL Server is running on the target host. On the server: open services.msc and check that 'SQL Server (MSSQLSERVER)' or 'SQL Server (INSTANCENAME)' shows Status = Running. Remotely via PowerShell: Get-Service -ComputerName <server> -Name 'MSSQLSERVER' | Select-Object Status. If stopped, right-click → Start, or run as admin: net start MSSQLSERVER (default) / net start MSSQL$INSTANCENAME (named).
2Step 2 — Find the actual port SQL Server is listening on. Open SQL Server Configuration Manager → SQL Server Network Configuration → Protocols for <instance> → TCP/IP → double-click → IP Addresses tab → scroll to IPAll → read TCP Port (static) or TCP Dynamic Ports (if 0, a dynamic port was assigned). Alternatively query the error log: xp_readerrorlog 0, 1, N'Server is listening on'; the log line shows the actual port at startup.
3Step 3 — Verify the port is reachable from the client. From the pipeline host or gateway machine run: Test-NetConnection -ComputerName <server> -Port <port>. A TcpTestSucceeded = False with 'Connection refused' confirms the port is closed. If TcpTestSucceeded = True, the issue is at the driver or authentication layer, not the TCP connection.
4Step 4 — Check and fix the connection string port. In Azure Data Factory: open the linked service, expand Advanced, and confirm the port field matches what was found in Step 2. In Power BI Desktop: Data Source Settings → Edit → Server field — use the syntax <host>,<port> (comma, not colon). In SSIS: open the Connection Manager, edit the connection string property directly.
5Step 5 — If using a named instance, confirm SQL Server Browser is running. On the server: services.msc → SQL Server Browser → Status should be Running. Start it with: net start SQLBrowser. Then retry the connection using the instance name (e.g. SERVER\INSTANCENAME) without specifying a port and let Browser resolve it.
6Step 6 — Check firewall rules on the server. Run on the server: netsh advfirewall firewall show rule name=all | findstr -i '1433'. If no inbound rule exists for the SQL Server port, add one: New-NetFirewallRule -DisplayName 'SQL Server 1433' -Direction Inbound -Protocol TCP -LocalPort 1433 -Action Allow. For named instances, also open UDP 1434 for Browser.
7Step 7 — Validate the fix end-to-end. From the pipeline host: sqlcmd -S <server>,<port> -U <user> -P <password> -Q 'SELECT @@VERSION'. A successful response confirms the port is open, the service is running, and credentials are accepted. Then trigger the ADF pipeline or Power BI refresh manually and confirm it completes without error 10061.

Example log output

System.Data.SqlClient.SqlException (0x80131904): 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: TCP Provider, error: 0 - No connection could be made because the target machine actively refused it.) ---> System.ComponentModel.Win32Exception (0x80004005): No connection could be made because the target machine actively refused it
ActivityId: a3f1c2d4-..., Error Code: 10061

Frequently asked questions

SQL Server 10061 fix — what is the fastest way to resolve this in production?

SSH or RDP to the SQL Server host and run: net start MSSQLSERVER (or net start MSSQL$INSTANCENAME for a named instance). This takes under 10 seconds. If the service fails to start, check the SQL Server error log at C:\Program Files\Microsoft SQL Server\MSSQL<version>.MSSQLSERVER\MSSQL\Log\ERRORLOG for the reason — common causes are a full data disk or a changed service account password.

Error 10061 keeps coming back — how do I stop SQL Server from stopping itself?

Check the Windows Event Log (eventvwr.msc → Windows Logs → Application) filtered on source 'MSSQLSERVER' around the time the service stopped. Common repeating causes: Windows Update forcing a restart without SQL Server being in the startup sequence, a disk reaching 100% capacity triggering a shutdown, or a service account password expiring. Set the SQL Server service account password to 'Password never expires' in Active Directory and configure the service for automatic restart on failure in services.msc → Recovery tab.

10061 error on Azure SQL Database — is this the same issue?

Not exactly. Azure SQL Database does not expose a Windows service, but error 10061 can appear when: (1) the Azure SQL server is paused (serverless tier auto-pause after inactivity) — the first connection attempt is refused while the server resumes; (2) the connection string uses the wrong server FQDN (e.g. a server in a different region or a deleted server name); or (3) the Azure SQL firewall has no rule for the client IP. For serverless, the fix is to allow resume on first connection and add a retry policy. For firewall: Azure Portal → SQL Server → Networking → add the client IP.

How do I add a retry policy in ADF to handle transient 10061 errors during SQL Server restarts?

In the ADF pipeline, select the Copy or Lookup activity → Settings tab → Retry: set to 3, Retry interval (seconds): 60. This gives SQL Server up to 3 minutes to finish starting before the activity fails permanently. For Lookup activities used as pipeline guards, also enable 'First row only' to reduce load. Note: 10061 on a server that is fully down will retry and fail all attempts — retries only help during the brief startup window (typically 20-60 seconds for SQL Server to become ready).

Source · learn.microsoft.com/en-us/sql/relational-databases/errors-events/database-engine-events-and-errors