sa Login
Host: CLIENTPCNAME · Instance: CLIENTPCNAME\MARKSERVER · Windows Login: CLIENTPCNAME\WHOAMIUSERNAME
A step-by-step recovery path for error -2147203018, where the SQL Server login
policy has locked sa out after too many failed attempts. Two methods are covered,
chosen by whether your Windows account already holds sysadmin rights on the instance.
The fix branches in two directions depending on one fact: does CLIENTPCNAME\WHOAMIUSERNAME
already hold sysadmin rights on this SQL instance? Try Method 1 first — if it fails, you need Method 2.
Connect directly with Windows Authentication and unlock sa in one command. Fastest path — try this first.
Restart the instance in single-user mode, grant yourself sysadmin, then unlock sa normally.
Before starting: confirm the instance name is really MARKSERVER. Run sqlcmd -L from a command prompt, or check Services (services.msc) for a service literally named SQL Server (MARKSERVER). Swap the name into every command below if it differs.
Use this if CLIENTPCNAME\WHOAMIUSERNAME is already a sysadmin on the instance.
Right-click Command Prompt → Run as administrator.
The -E flag uses your current Windows credentials — no password prompt.
C:\> sqlcmd -S CLIENTPCNAME\MARKSERVER -E
A new password is required by ALTER LOGIN even if you plan to keep it similar — choose something strong.
1> ALTER LOGIN sa WITH PASSWORD = '8446606378' UNLOCK, CHECK_POLICY = OFF; 2> GO 3> EXIT
If this step returns a login failure instead of a syntax result, WHOAMIUSERNAME does not have sysadmin rights. Stop here and move to Method 2.
Use this when no Windows account currently has sysadmin rights on the instance. You will briefly restart SQL Server in a restricted mode that allows exactly one connection with implicit sysadmin access, grant yourself the role, then return to normal operation.
Run from an elevated command prompt.
C:\> net stop MSSQL$MARKSERVER
Adjust the binary path if your install folder differs. This runs in the foreground — do not close the window.
C:\> "C:\Program Files\Microsoft SQL Server\MSSQL10_50.MARKSERVER\MSSQL\Binn\sqlservr.exe" -m -sMARKSERVER
This is a separate window from step 2 — Window A must stay running.
C:\> sqlcmd -S CLIENTPCNAME\MARKSERVER -E
In single-user mode, the first connecting Windows login gets implicit sysadmin — this is what makes the grant possible.
-- If the login does not exist yet:
1> CREATE LOGIN [CLIENTPCNAME\WHOAMIUSERNAME] FROM WINDOWS;
2> GO
3> EXEC sp_addsrvrolemember 'CLIENTPCNAME\WHOAMIUSERNAME', 'sysadmin';
4> GO
5> EXIT
If the login already exists, skip the CREATE LOGIN line and run only the sp_addsrvrolemember line.
Switch back to Window A.
Ctrl+C Confirm terminate batch job? (Y/N): Y
C:\> net start MSSQL$MARKSERVER
Same command as Method 1, now that WHOAMIUSERNAME has sysadmin.
C:\> sqlcmd -S CLIENTPCNAME\MARKSERVER -E
1> ALTER LOGIN sa WITH PASSWORD = '8446606378' UNLOCK, CHECK_POLICY = OFF;
2> GO
3> EXIT
There's no separate "group policy for sa." SQL Server 2008 R2 ties the sa login to
the local Windows account lockout policy whenever CHECK_POLICY is ON. Two fixes exist, at two different scopes.
| Scope | What it changes | Recommended |
|---|---|---|
| Per-login CHECK_POLICY = OFF |
Exempts only the sa login from the Windows lockout/complexity policy going forward. |
Use this |
| Server-wide secpol.msc |
Sets Account Lockout Threshold to 0 for the whole machine — every local Windows account stops locking out, not just SQL logins. | Avoid unless required |
sqlcmd -S CLIENTPCNAME\MARKSERVER -U sa -P 8446606378 and confirm no lockout error appears.SELECT is_policy_checked, is_locked FROM sys.sql_logins WHERE name = 'sa'; — expect is_policy_checked = 0 and is_locked = 0.sa password somewhere secure — this is the credential your application connection strings depend on.