Introduction
After upgrading a Windows Server operating system, SQL Server administrators may encounter a situation where existing SQL Server logins appear to have disappeared from SQL Server Management Studio (SSMS).
A typical symptom is:
- SQL Server databases are online and accessible.
- The SQL Server service is running.
salogin exists.- Existing Windows logins and groups are not visible in SSMS.
- SQL Server administrator access appears to be lost.
- The server administrator has Windows local administrator privileges but no SQL Server
sysadminaccess.
This article explains how to recover SQL Server administrative access and restore visibility of existing logins without rebuilding SQL Server or restoring system databases.
Environment
Example scenario:
- Operating System: Windows Server 2016 upgraded to Windows Server 2025
- SQL Server: Existing SQL Server installation
- Authentication: Windows Authentication
- SQL Server service configured with a virtual/default service account:
NT SERVICE\MSSQLSERVER
instead of a dedicated domain service account:
DOMAIN\SQLServiceAccount
Problem Description
After the Windows Server upgrade, administrators noticed that SQL Server logins were missing in SSMS.
The issue appeared as:
- Security → Logins folder did not show expected accounts.
- Domain groups were not visible.
- SQL Server administrative tasks failed because there was no accessible
sysadminaccount. - Existing login permissions appeared to be lost.
However, the logins were not actually deleted.
The problem was related to SQL Server running under an account that could not properly resolve domain security principals.
Root Cause Analysis
SQL Server stores server-level security information in the master database.
This includes:
- SQL Server logins
- Windows logins
- Windows groups
- Server roles
- Server permissions
The Windows Server upgrade did not remove these objects.
The issue occurred because SQL Server was running under:
NT SERVICE\MSSQLSERVER
The virtual SQL Server service account has limited access to domain resources compared with a dedicated domain service account.
Because SQL Server could not properly communicate with the domain security infrastructure:
- Domain users/groups could not be resolved.
- Existing Windows login mappings could not be displayed correctly.
- SQL Server could not identify the expected administrator accounts.
The login objects remained in SQL Server but were not accessible through normal administration.
Recovery Solution
The recovery method is:
- Start SQL Server in single-user mode.
- Connect using Windows local administrator credentials.
- Restore SQL Server administrator access.
- Restart SQL Server normally.
- Verify that existing logins are visible again.
Step 1: Identify SQL Server Instance
Open Command Prompt as Administrator.
Run:
sc query type= service | findstr MSSQL
Example output:
SERVICE_NAME: MSSQLSERVER
SERVICE_NAME: SQLSERVERAGENT
For named instances:
SERVICE_NAME: MSSQL$INSTANCE01
Step 2: Stop SQL Server Service
Default Instance
net stop MSSQLSERVER
Named Instance
Replace INSTANCE01 with your instance name:
net stop MSSQL$INSTANCE01
Step 3: Start SQL Server in Single-User Mode
Single-user mode allows one administrative connection.
Default Instance
net start MSSQLSERVER /m"SQLCMD"
Named Instance
net start MSSQL$INSTANCE01 /m"SQLCMD"
The SQLCMD parameter ensures that SQLCMD receives the single available connection.
Step 4: Connect Using SQLCMD
Open another Command Prompt as Administrator.
Default Instance
sqlcmd -S localhost -E
Named Instance
sqlcmd -S localhost\INSTANCE01 -E
Successful connection displays:
1>
Step 5: Verify Current Access
Run:
SELECT SYSTEM_USER;
GO
SELECT IS_SRVROLEMEMBER('sysadmin');
GO
If the result is:
1
you already have sysadmin access.
Step 6: Create or Restore SQL Administrator Login
Create the required Windows login if it does not exist:
CREATE LOGIN [DOMAIN\SQLAdmins] FROM WINDOWS;
GO
Example:
CREATE LOGIN [DOMAIN\SCCMMGMT] FROM WINDOWS;
GO
Add the account to the sysadmin role:
ALTER SERVER ROLE sysadmin ADD MEMBER [DOMAIN\SCCMMGMT];
GO
Step 7: Verify Sysadmin Membership
Run:
SELECT
sp.name AS LoginName,
sr.name AS ServerRole
FROM sys.server_role_members rm
JOIN sys.server_principals sp
ON rm.member_principal_id = sp.principal_id
JOIN sys.server_principals sr
ON rm.role_principal_id = sr.principal_id
WHERE sr.name = 'sysadmin';
GO
Example output:
LoginName ServerRole
--------------------------------------
DOMAIN\SCCMMGMT sysadmin
Step 8: Exit SQLCMD
EXIT
Step 9: Restart SQL Server Normally
Stop the single-user SQL Server instance.
Default Instance
net stop MSSQLSERVER
Named Instance
net stop MSSQL$INSTANCE01
Start normally.
Default Instance
net start MSSQLSERVER
Named Instance
net start MSSQL$INSTANCE01
Important:
Do not use /m during normal startup.
Step 10: Verify Login Visibility
Open SSMS and connect using Windows Authentication.
Check server logins:
SELECT
name,
type_desc,
is_disabled
FROM sys.server_principals
ORDER BY name;
GO
Existing logins should now appear.
Example:
sa
DOMAIN\SQLAdmins
DOMAIN\DBAGroup
NT AUTHORITY\SYSTEM
##MS_SQLResourceSigningCertificate##
Step 11: Backup the Master Database
Because server-level security information is stored in master, create a backup after recovery.
BACKUP DATABASE master
TO DISK = 'C:\Backup\master_after_recovery.bak'
WITH INIT;
GO
Important Lessons Learned
1. Missing logins do not always mean deleted logins
If SQL Server login objects are missing from SSMS, first verify:
- SQL Server service account
- Domain connectivity
- Windows authentication
- sysadmin membership
The login objects may still exist.
2. Verify SQL service accounts before OS upgrades
Before upgrading Windows Server:
- Document SQL Server service accounts.
- Confirm domain service accounts.
- Verify SQL Server administrators.
- Backup system databases.
3. Always maintain a SQL Server recovery account
Maintain at least one emergency administrative account:
- Windows domain group
- SQL login with controlled access
- Documented ownership
This simplifies disaster recovery.
Conclusion
In this incident, the SQL Server logins were not deleted during the Windows Server upgrade.
The issue was caused by SQL Server running under a service account context that could not properly resolve existing domain security principals.
By starting SQL Server in single-user mode, restoring sysadmin access, and correcting the SQL Server service account configuration, all existing logins became visible again without rebuilding SQL Server or restoring databases.