SQL Server Stuck on Starting: When gMSA Fails and Regular Domain Accounts Save the Day

on

 

The Problem

You followed Microsoft's best practices and configured SQL Server to use a Group Managed Service Account (gMSA) for your Always On Availability Group. You start the service, and... nothing. SQL Server sits in a perpetual "Starting" state, Process ID shows 0, and worst of all: no errors anywhere.

  • ERRORLOG? Empty.
  • Event Viewer? Clean.
  • Windows logs? Nothing useful.

It's a silent failure with zero diagnostic breadcrumbs. The gMSA that was supposed to make things more secure has instead made SQL Server completely unusable.

Sound familiar?

The Diagnostic Dead End

Here's what makes this issue particularly frustrating:

ERRORLOG: Completely empty. No errors. No warnings. Nothing. Not even the typical "SQL Server is starting" messages.

Windows Event Viewer (Application Log): Nothing helpful. No SQL Server errors indicating why the service won't start. Maybe a generic "service failed to start" message at best.

Services.msc: Just shows "Starting" with Process ID 0.

What you'd normally expect to see:

  • Error messages in ERRORLOG pointing to the problem
  • Event ID 17051, 17052, or similar service startup errors
  • Authentication failures
  • Permission denied messages

What you actually get: Complete silence.

This is the worst type of problem - SQL Server appears to be starting, but you have zero information about what's actually wrong. Traditional troubleshooting methods (checking logs, reviewing Event Viewer) lead nowhere.

When SQL Server fails this early in the startup process - before it can even initialize logging - you need a different approach.

The Only Way to See the Real Error

Instead of staring at Services.msc and empty log files, run SQL Server from the command line:

# Stop the service first
Stop-Service MSSQLSERVER -Force

# Run SQL Server in console mode
& "C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\Binn\sqlservr.exe" -c

Now you'll see the actual error messages in the console window.

The Solution: Use a Regular Domain Account

Instead of fighting with gMSA permissions, the simplest solution is to switch to a regular domain account or local Windows account:

# Stop SQL Server
Stop-Service MSSQLSERVER -Force

# Change to regular domain account
$svc = Get-WmiObject win32_service -Filter "name='MSSQLSERVER'"
$svc.Change($null,$null,$null,$null,$null,$null,"DOMAIN\SQLService","YourPassword",$null,$null,$null)

# Or use Local System for standalone instances (not recommended for AG)
# $svc.Change($null,$null,$null,$null,$null,$null,"LocalSystem",$null,$null,$null,$null)

# Start SQL Server
Start-Service MSSQLSERVER

Result: SQL Server starts immediately without any permission issues.

Alternative: Fix the gMSA Permissions (If You Want to Keep gMSA)

If you need to keep using gMSA for compliance or security reasons, you can grant the necessary permissions:

  1. Run secpol.msc
  2. Navigate to: Security Settings → Local Policies → User Rights Assignment
  3. Open: "Generate security audits"
  4. Add your gMSA: DOMAIN\SQLSvcAccount_gmsa$
  5. Restart the SQL Server service

Important: Do this on every node in your Availability Group cluster.

Choosing the Right Service Account

For standalone SQL Server instances:

  • gMSA (if you can configure it properly) - More secure, no password management
  • Regular domain account - Good balance of security and functionality
  • Local Windows account - Works for single-server setups
  • Local System - Works but has excessive permissions

For Always On Availability Groups:

  • gMSA (if you can configure it properly) - More secure, no password management
  • Regular domain account (recommended) - Can authenticate across servers, supports Kerberos
  • ❌ Local System - Cannot authenticate to remote servers, breaks AG functionality

This happens because Local System:

  • Cannot authenticate to remote servers
  • Breaks Kerberos authentication
  • Prevents AG synchronization

Prevention for New Deployments

Recommended approach: Use a regular domain account

# Create a domain service account (done by AD admin)
# DOMAIN\SQLService with appropriate permissions

# During SQL Server installation, use this account
# Or change after installation:
Stop-Service MSSQLSERVER -Force
$svc = Get-WmiObject win32_service -Filter "name='MSSQLSERVER'"
$svc.Change($null,$null,$null,$null,$null,$null,"DOMAIN\SQLService","Password",$null,$null,$null)
Start-Service MSSQLSERVER

If you must use gMSA:

# Verify the gMSA is accessible
Test-ADServiceAccount DOMAIN\SQLSvc_gmsa$

# Pre-grant audit permissions using secpol.msc
# (See solution steps above)

# Verify SPNs will register correctly
setspn -L DOMAIN\SQLSvc_gmsa$

# Test startup in console mode before relying on it
& "sqlservr.exe" -c

Grant necessary permissions to your service account:

  • Full control on SQL Server installation directories
  • Full control on data/log file locations
  • Backup directories access
  • If using Security Log audits, grant "Generate security audits" right

Key Takeaways

  1. Silent failures are the worst - No errors in ERRORLOG or Event Viewer doesn't mean "no problem"
  2. Always test startup in console mode (sqlservr.exe -c) when troubleshooting mysterious startup issues
  3. Empty ERRORLOG = very early startup failure - use console mode to see what's wrong
  4. gMSA can cause startup issues due to audit permissions - consider using regular domain accounts instead
  5. Regular domain accounts work reliably for both standalone and AG deployments
  6. Local System is NOT a solution for production AG environments
  7. Test your service account choice in console mode before going to production

Conclusion

While gMSA accounts are often recommended for SQL Server (especially in Microsoft documentation), they can introduce unexpected complications like audit permission issues. In practice, regular domain accounts provide a more reliable, straightforward solution for both standalone instances and Availability Groups.

When startup issues occur:

  1. Don't waste time staring at empty logs
  2. Run SQL Server in console mode (sqlservr.exe -c)
  3. See the actual error message
  4. Consider switching to a regular domain account for simplicity

The "best practice" isn't always the practical choice. Sometimes the traditional approach - a well-configured domain service account - is the better path.

Have you encountered gMSA startup issues? What service account strategy works best in your environment? Share your experiences in the comments below.

Comments

Post a Comment