Troubleshoot SQL Server setup, startup, and authentication failures with gMSAs

Applies to: SQL Server on Windows

Summary

This article is the entry point for SQL Server installation, upgrade, service startup, SQL Server Agent, failover cluster instance (FCI), Kerberos, linked server, and availability group failures that occur when SQL Server services run under a group managed service account (gMSA). Most of these symptoms have the same root causes whether or not a gMSA is involved, so each scenario article isolates the gMSA-specific checks and links to the canonical troubleshooting article for the rest.

Start with the quick validation checklist. Then use the troubleshooting path that matches the observed failure to find the scenario article that has the diagnostic and resolution steps. For background on selecting and configuring service accounts for SQL Server, including managed service accounts and gMSAs, see Configure Windows service accounts and permissions. For gMSA creation and management in Active Directory, see Manage group managed service accounts.

Prerequisites

Local administrative access to each affected SQL Server host or cluster node.
Access to SQL Server Setup Bootstrap logs, the SQL Server error log, the SQL Server Agent error log, and the Windows application and system logs.
The Active Directory PowerShell module for Get-ADServiceAccount and Test-ADServiceAccount. If the module isn't present, see Install and manage Remote Server Administration Tools in Windows.
Appropriate Active Directory permissions, or assistance from an Active Directory administrator, to validate password retrieval, service principal names (SPNs), delegation, and authorized hosts.
Permission to run Transact-SQL diagnostic queries when the Database Engine is available. The diagnostic queries in this article and in the scenario articles read server-scoped dynamic management views and catalog views. For the required permissions, which vary by version, see System dynamic management views and functions.

Important

Collect evidence before you change service accounts, security policy, registry values, SPNs, or failover cluster settings. Record the failure time and the server time zone. Run the host validation commands locally on every affected standalone server, cluster node, or replica, and then compare the results. Replace the example account, service, instance, and domain names with values from your environment.

Quick validation checklist

Run these checks on every affected host before you open a scenario-specific article. For an FCI or availability group, run them on every possible owner node or replica and compare the results.

Confirm the configured SQL Server and SQL Server Agent service identities by reviewing the Log On As value in SQL Server Configuration Manager and the SERVICE_START_NAME output from sc.exe qc.

For a default instance, run the following commands.
```
sc.exe qc MSSQLSERVER
sc.exe qc SQLSERVERAGENT
```
Expected result: SERVICE_START_NAME identifies the intended gMSA. For a named instance, use MSSQL$<InstanceName> and SQLAgent$<InstanceName>. Replace <InstanceName> with the instance name.
Confirm that Active Directory can find the gMSA by running Get-ADServiceAccount and verifying that it returns the intended account.

Run the following command in an elevated PowerShell session.
```
Get-ADServiceAccount -Identity 'SQLgMSA' -Properties PrincipalsAllowedToRetrieveManagedPassword
```
Expected result: Get-ADServiceAccount returns the intended account and lists the host.
Confirm that the host computer account, or a group that contains it, is listed in PrincipalsAllowedToRetrieveManagedPassword.
Test password retrieval from every affected host or possible owner node by running Test-ADServiceAccount locally and confirming that it returns True.

Run the following command in an elevated PowerShell session.
```
Test-ADServiceAccount -Identity 'SQLgMSA'
```
Expected result: Test-ADServiceAccount returns True on every host that can run the SQL Server service.
Confirm that Service Control Manager treats the service account as managed by running sc.exe qmanagedaccount for the exact SQL Server or SQL Server Agent service name and verifying that it reports TRUE.

For a default instance, run the following commands.
```
sc.exe qmanagedaccount MSSQLSERVER
sc.exe qmanagedaccount SQLSERVERAGENT
```
Expected result: qmanagedaccount reports TRUE.
Confirm DNS, domain-controller discovery, secure-channel health, and time synchronization.

Run the following commands. Replace contoso.com with the Active Directory domain name.
```
nltest /dsgetdc:contoso.com
nltest /sc_verify:contoso.com
w32tm /query /status
```
Expected result: a domain controller is discovered, the secure channel succeeds, and time status is healthy.
If SQL Server starts, confirm the current authentication scheme by querying sys.dm_exec_connections from a remote Windows-authenticated session.

For additional host-level gMSA checks that aren't specific to SQL Server, see Troubleshoot gMSAs for Windows containers.

Choose a troubleshooting path

Observed symptom	Refer to
Setup rejects the gMSA or can't validate it	Troubleshoot setup and upgrade failures with gMSAs
Setup fails with 0x84BB0001 or "Access is denied"	Setup fails with error 0x84BB0001
Error 1069, Event ID 7041, or Event ID 7038	Troubleshoot service startup failures with gMSAs
Service fails only during boot	Troubleshoot service startup failures with gMSAs
`IsManagedAccount` or `qmanagedaccount` is `FALSE`	Troubleshoot service startup failures with gMSAs
SQL Server Agent starts but jobs fail	Troubleshoot SQL Server Agent job failures with gMSAs
FCI setup, add-node, startup, or failover fails	Troubleshoot failover cluster instance failures with gMSAs
NTLM fallback, SPN error, ANONYMOUS LOGON, or availability group endpoint authentication failure	Troubleshoot Kerberos and authentication failures with gMSAs
Upgrade fails with error 29569	SQL Server upgrade fails with error 29569

Collect diagnostic data

If the quick validation checklist and the scenario-specific checks don't isolate the cause, collect the following diagnostic data before you continue the investigation or open a support case. Gather every artifact from the same failure interval so that the evidence correlates.

Collect the following gMSA-specific evidence from every affected host, node, or replica:

Get-ADServiceAccount output, including PrincipalsAllowedToRetrieveManagedPassword.
Test-ADServiceAccount result.
sc.exe qc and sc.exe qmanagedaccount output for the SQL Server and SQL Server Agent services.
nltest /dsgetdc, nltest /sc_verify, and w32tm /query /status output.
Effective user-right assignments and gpresult output.
SPN ownership and duplicate checks for the gMSA.
For an FCI, the cluster log covering the resource transition.

Collect the following standard SQL Server diagnostic data for the same interval:

Setup logs, including Summary.txt, Detail.txt, and feature-specific logs. See View and read SQL Server Setup log files.
Current and archived SQL Server error logs, SQL Server Agent logs, and failed job history.
System, Application, and relevant Security event logs.

For tool selection and automated collection, see Troubleshooting and diagnostic tools for SQL Server. You can use SQL LogScout to automate collection when it's appropriate for the investigation.

Feedback

Was this page helpful?

Last updated on 2026-10-01