A gMSA no longer starts a service: causes and solut...

The service using a gMSA fails on startup.

Probable causes

host not allowed
KDS
SPN or right Log on a service

Verifications.

Limit the impact. — Identify whether an endpoint, service, or whole site is affected.
Collect evidence. — Keep the exact error message, timestamp, and associated logs.
Test the simplest hypothesis first. — Compare the affected system with a known-good path.
Correct the confirmed cause and validate the result. — Apply one controlled change at a time and retest.

Commands

Test-ADServiceAccount nomgmsa

Solutions.

Correct the confirmed cause rather than the symptom.
Document the change and its result.
Establish monitoring if the fault can recur.

When to escalate?

Escalate if the impact expands, data are at risk, or remediation requires an irreversible change.

gMSA service-start focus

A service using a group Managed Service Account depends on Active Directory being able to deliver the current managed password to the computer that runs the service. A valid account object alone is therefore not enough.

What to verify

Confirm that the host is allowed by the gMSA password-retrieval principals and that recent group membership changes have reached the computer token.
Use the platform gMSA test command to verify that the local machine can retrieve and use the account.
Check service logon configuration, required service rights and any SPN expected by the application.
Review domain-controller connectivity, DNS and Kerberos time synchronization if retrieval or authentication is intermittent.

Resolution path

Correct the permitted-host membership or service configuration, refresh the computer context when required, and avoid setting a manual password on a gMSA-backed service.

Validation

Start the service, confirm a clean service-control event, then verify the application can authenticate to its downstream resources using the gMSA identity.