Skip to main content
Marios PavlidisPrincipal DBA
SQL ServerSQL Serversecurityadministrationaccess recoverysingle-user modesysadmin

SQL Server: Regaining Sysadmin Access When All Administrator Accounts Are Locked Out

Step-by-step procedure to recover sysadmin access to a SQL Server instance using single-user mode when all privileged accounts are disabled, deleted, or have unknown passwords.

8 min read

SQL Server: Regaining Sysadmin Access When All Administrator Accounts Are Locked Out

You inherit a SQL Server instance. There are no documented sysadmin credentials. The SA account is disabled. The Windows logins that had sysadmin were tied to accounts that no longer exist. The database is running and serving applications — you just cannot manage it.

This situation is more common than most teams admit: server migrations without documented credentials, staff departures, security hardening that disabled accounts without creating alternatives, or years of undocumented operational drift.

The answer

SQL Server can be restarted in single-user mode, which allows any member of the local Windows Administrators group to connect with sysadmin privileges. That connection is used to add a new sysadmin login, and then SQL Server is restarted normally. No SQL Server credentials are required — only local Windows Administrator access to the host machine.

What you will learn

  • Why single-user mode grants access to local Windows administrators
  • How to start SQL Server in single-user mode without consuming the connection slot before you can use it
  • How to connect with sqlcmd and add a permanent sysadmin login
  • How to restart SQL Server normally and verify access

Scope: SQL Server 2016, 2017, 2019, and 2022, on Windows. Requires local Windows Administrator access or RDP/console access to the host. Does not apply to Azure SQL Database or Azure SQL Managed Instance — those services do not expose single-user mode. For SQL Server on Azure VMs, this procedure applies as written.

Impact: Starting SQL Server in single-user mode disconnects all existing sessions. This is a disruptive operation. Plan for a maintenance window. Do not perform this on a production instance without change-control approval where applicable.

Why single-user mode works

SQL Server’s single-user mode (-m startup parameter) is a diagnostic startup option. When active, only one connection at a time is permitted. Microsoft documents that in this mode, members of the local Windows Administrators group automatically receive sysadmin privileges, regardless of whether a matching SQL Server login exists for them.

This is intentional: it provides a recovery path for the physical owner of the host when all SQL Server credentials are lost. The implicit grant is not available in normal multi-user mode, which is why a service restart is required.

The connection in this mode uses Windows Authentication — no SQL Server password is entered.

Prerequisites

  • Local Windows Administrator account (or a domain account that is a member of the local Administrators group on the SQL Server host)
  • RDP or console access to the host, or the ability to manage Windows services remotely
  • SQL Server Configuration Manager installed on the host (installed with SQL Server by default)
  • Change-control approval where applicable; this is a disruptive operation

Confirm the SQL Server instance name before starting. The default instance service is MSSQLSERVER; named instances follow the pattern MSSQL$<InstanceName>.

Step 1: Note the existing startup parameters

Open SQL Server Configuration Manager as a local Administrator.

In the left pane, expand SQL Server Services. Right-click the SQL Server engine service → Properties → Startup Parameters tab.

Note any existing startup parameters before making changes. Do not remove them.

Step 2: Add the single-user mode parameter

In the Specify a startup parameter field, enter:

-mSQLCMD

Click Add, then Apply.

Using -mSQLCMD instead of plain -m restricts single-user access to the sqlcmd utility. Connection pools and .NET applications using SqlClient will be refused, preventing an application from consuming the single allowed slot before you can connect. This is the recommended form.

Step 3: Stop dependent services

SQL Server Agent and any other services that depend on the SQL Server instance must be stopped first, or they will consume the single connection slot before you can use it.

# Default instance
Stop-Service -Name "SQLSERVERAGENT" -Force
Stop-Service -Name "MSSQLSERVER" -Force
# Named instance — replace <InstanceName>
Stop-Service -Name "SQLAgent$<InstanceName>" -Force
Stop-Service -Name "MSSQL$<InstanceName>" -Force

Confirm all dependent services are stopped before proceeding.

Step 4: Start SQL Server in single-user mode

# Default instance
Start-Service -Name "MSSQLSERVER"

# Named instance
Start-Service -Name "MSSQL$<InstanceName>"

Confirm the service started successfully. The Windows Event Log (Application) will show SQL Server startup messages. Look for the entry confirming the service is ready for client connections. The log will also record that single-user mode is active.

Step 5: Connect with sqlcmd

Open a command prompt as the same Windows Administrator account confirmed in the prerequisites. Connect to the instance:

:: Default instance
sqlcmd -S . -E

:: Named instance
sqlcmd -S .\<InstanceName> -E

-E uses Windows Authentication. No password is entered.

Verify sysadmin membership:

SELECT SUSER_SNAME(), IS_SRVROLEMEMBER('sysadmin');
GO

Expected output: your Windows login name and 1.

If the connection is refused, confirm that:

  • sqlcmd is being run as the local Windows Administrator account
  • The service started with the -mSQLCMD parameter (check SQL Server Configuration Manager)
  • No other connection consumed the slot (check for any services that were not stopped)

Step 6: Add a permanent sysadmin login

Choose the option appropriate for your environment.

Option A — Add the current Windows account as a sysadmin login:

-- Replace DOMAIN\Username with the actual account
CREATE LOGIN [DOMAIN\Username] FROM WINDOWS;
GO
ALTER SERVER ROLE sysadmin ADD MEMBER [DOMAIN\Username];
GO

Option B — Re-enable and reset the SA account:

ALTER LOGIN sa ENABLE;
GO
ALTER LOGIN sa WITH PASSWORD = 'ReplaceWithAStrongPassword';
GO

SA is already a sysadmin by default; enabling it is sufficient.

Option C — Create a new SQL Server login:

CREATE LOGIN [recovery_admin] WITH PASSWORD = 'ReplaceWithAStrongPassword';
GO
ALTER SERVER ROLE sysadmin ADD MEMBER [recovery_admin];
GO

Verify the login was added before disconnecting:

SELECT name, is_disabled
FROM sys.server_principals
WHERE IS_SRVROLEMEMBER('sysadmin', name) = 1
ORDER BY name;
GO

Confirm your new login appears in the results and is_disabled = 0.

Type exit to close the sqlcmd session.

Step 7: Remove the single-user parameter and restart normally

In SQL Server Configuration Manager → SQL Server service → Properties → Startup Parameters: select the -mSQLCMD entry and click Remove. Apply.

Restart the SQL Server service:

Restart-Service -Name "MSSQLSERVER" -Force

Start dependent services that were stopped in Step 3:

Start-Service -Name "SQLSERVERAGENT"

Step 8: Verify access in normal mode

Connect using the login created in Step 6 and confirm it works under normal multi-user operation:

SELECT SUSER_SNAME(), IS_SRVROLEMEMBER('sysadmin');
GO

Expected: the login name and 1.

Confirm application connections have resumed and no sessions are reporting login failures caused by the restart.

In practice

This scenario surfaces most commonly in:

  • Server migrations where the original team did not document SQL Server credentials and the handover relied only on OS-level access.
  • Security hardening exercises that disabled the SA account without verifying another sysadmin login was in place.
  • Staff departures where the only DBA administered SQL Server through a personal Windows domain account that was subsequently deleted.
  • Expired or rotated passwords on SQL logins where the new value was not recorded.

The recovery path in each case is the same: physical host access, local Windows Administrator membership, and a controlled service restart.

What this procedure cannot do

  • Azure SQL Database / Azure SQL Managed Instance: single-user mode is not exposed. Recover access through the Azure portal using the server admin account, Microsoft Entra admin settings, or an Azure support request.
  • Windows account locked or inaccessible: if the Windows Administrator account itself is inaccessible, the Windows OS must be recovered first. This is an OS-level problem, not a SQL Server problem.
  • SQL Server service will not start: if the service fails to start due to corruption, missing system databases, or misconfiguration, those conditions must be resolved before this procedure applies.

Do not do this

  • Do not leave -m or -mSQLCMD in the startup parameters after the recovery is complete. An instance restarted in single-user mode after the recovery will refuse all but one connection.
  • Do not leave an undocumented recovery login enabled. Assign it a documented owner or disable it once the primary administration accounts are restored.
  • Do not skip stopping dependent services before the restart. SQL Server Agent alone will consume the single connection slot before you can connect.
  • Do not perform this on a production instance without a maintenance window. Every session is dropped when the service restarts.

Official references

Conclusion

Losing access to a SQL Server instance is a recoverable situation provided you have physical or remote access to the Windows host. Single-user mode is built into SQL Server specifically for this scenario. The recovery requires no SQL Server credentials — only Windows Administrator membership, a controlled service restart, and sqlcmd.

Document the access recovery in your change log. Review why it was needed and ensure the restored access is formally owned, properly permissioned, and recorded before closing the incident.

Continue reading

Marios Pavlidis Principal Database Administrator