Cloud Sync provisioning agent fails to start with a gMSA

This is a knowledge base item. I hope it will help you someday.

The issue#

When installing an additional Microsoft Entra Cloud Sync provisioning agent, the agent service (AADConnectProvisioningAgent) would not start. I ran into two different errors, depending on the gMSA option I picked in the installer.

When letting the installer create a new gMSA:

Unable to install service account pGMSA_8d7e77a5$ after 6 retries

When using an existing (custom) gMSA, in this example customgMSA:

Cannot start service AADConnectProvisioningAgent on computer '.'.

Unknown exception while starting service AADConnectProvisioningAgent: System.InvalidOperationException: Cannot start service AADConnectProvisioningAgent on computer '.'. ---> System.ComponentModel.Win32Exception: The service did not start due to a logon failure

In services.msc, the service was configured to run as the gMSA, but it simply failed to log on.

The cause#

The installer did not finish the gMSA setup on the new server. Two things can be missing, and either one alone causes a logon failure.

1. The service is not marked as using a managed service account. The registry value ServiceAccountManaged (set to 01 00 00 00) under HKLM\SYSTEM\CurrentControlSet\Services\AADConnectProvisioningAgent tells Windows to fetch the gMSA password from Active Directory. Without it, Windows tries to log on with a stored password, which a gMSA doesn’t have. On my working agent servers, the value was there; on the new server, it was not.
2. The server is not allowed to retrieve the gMSA password. The new server was missing from the gMSA’s PrincipalsAllowedToRetrieveManagedPassword list, so even with the flag set, it could not get the password.

For the new gMSA error, I’m honestly not sure what failed in the installer. The same error is described in this Microsoft Q&A post, where the cause is the missing ServiceAccountManaged flag (cause 1). The post also mentions Failed changing Windows service credentials to gMSA when using a custom gMSA, with the same fix. The author suspects it is related to Windows Server 2022/2025, but isn’t sure either.

There is also another cause for the new gMSA error. Bastien Perez describes it on ITPro-Tips: a domain GPO that only allows AES for Kerberos. By default, the installer creates provAgentgMSA with msDS-SupportedEncryptionTypes set to 0x1C (RC4, AES128 and AES256), which doesn’t match that policy. His fix: keep the installer window open, set the gMSA to AES, and click Confirm again in the wizard.

Get-ADServiceAccount -Filter "Name -eq 'provAgentgMSA'" | Set-ADServiceAccount -KerberosEncryptionType AES256

To find out which cause applies to you, check the installer trace logs in %ProgramData%\Microsoft\Azure AD Connect Provisioning Agent\Trace.

For the existing gMSA error, both causes applied in my case.

Some background first#

For high availability, you run multiple Cloud Sync agents. Microsoft recommends three. All agents in the same domain can (and usually do) run as the same group managed service account (gMSA). Nobody knows its password: Active Directory generates and rotates it, and only approved servers can retrieve it.

For the agent service to log on as the gMSA, Windows needs two things on each agent server:

1. Active Directory must allow the server to retrieve the password. The server, or a group it is a member of, has to be listed in the gMSA’s PrincipalsAllowedToRetrieveManagedPassword.
2. The service must know it uses a managed account. That is the ServiceAccountManaged flag on the service. It tells Windows to fetch the current password from AD at logon, instead of looking for a stored one.

The installer normally takes care of both and also sets the AD permissions on the gMSA. When something goes wrong halfway, you end up with a service that is configured for the gMSA but cannot log on. The steps you need depend on what you see:

Whatever you do, always finish with Step 3 to verify.

The solution#

Replace customgMSA with the name of your gMSA (or the pGMSA_xxxxxxxx account the installer created) and NEWSERVER with the name of the new agent server.

Step 1: Allow the server to retrieve the gMSA password#

Run this on a machine with the Active Directory PowerShell module, as a domain admin. Skip this step if the server is already listed.

$gmsaName = 'customgMSA'
$server   = 'NEWSERVER'

# Back up the current list
$gmsa = Get-ADServiceAccount $gmsaName -Properties PrincipalsAllowedToRetrieveManagedPassword
$gmsa.PrincipalsAllowedToRetrieveManagedPassword | Out-File C:\temp\gmsa-principals-backup.txt

# Add the server to the existing list
$new = (Get-ADComputer $server).DistinguishedName
Set-ADServiceAccount $gmsaName -PrincipalsAllowedToRetrieveManagedPassword (@($gmsa.PrincipalsAllowedToRetrieveManagedPassword) + $new)

# Verify
Get-ADServiceAccount $gmsaName -Properties PrincipalsAllowedToRetrieveManagedPassword |
  Select-Object -ExpandProperty PrincipalsAllowedToRetrieveManagedPassword

Be careful: -PrincipalsAllowedToRetrieveManagedPassword sets the complete list. There is no add option, so always include the existing entries. Otherwise, your other agent servers lose access to the gMSA.

Step 2: Mark the service account as managed#

Run this on the new agent server.

# Back up the service key
reg export HKLM\SYSTEM\CurrentControlSet\Services\AADConnectProvisioningAgent C:\temp\provagent-svc-backup.reg

# Set the flag and check it
sc.exe managedaccount AADConnectProvisioningAgent true
sc.exe qmanagedaccount AADConnectProvisioningAgent

The service logon account should be DOMAIN\customgMSA$, with the trailing $ and empty password fields.

Step 3: Verify and start the service#

Run this on the new agent server.

# Refresh the computer's Kerberos tickets
klist -li 0x3e7 purge

# Should return True
Test-ADServiceAccount customgMSA

# Start the agent
Start-Service AADConnectProvisioningAgent
Get-Service AADConnectProvisioningAgent

If Test-ADServiceAccount returns False, wait a few minutes for AD replication or reboot the server. After that, the agent showed up as active in the Entra admin center under Cloud Sync agents.

Tip: Use a group instead of individual servers#

I tested it in my lab to be sure: Set-ADServiceAccount -PrincipalsAllowedToRetrieveManagedPassword really overwrites the list. There is no append parameter, and the generic -Add parameter doesn’t help either. The attribute behind it, msDS-GroupMSAMembership, holds one security descriptor, so AD can only replace it as a whole.

The better approach is to make a group the only principal on the gMSA. Adding a new agent server is then just a group membership change.

# One-time setup
New-ADGroup -Name 'gMSA-CloudSync-Hosts' -GroupScope Global -GroupCategory Security
Add-ADGroupMember 'gMSA-CloudSync-Hosts' -Members (Get-ADComputer SERVER1), (Get-ADComputer SERVER2)
Set-ADServiceAccount customgMSA -PrincipalsAllowedToRetrieveManagedPassword 'gMSA-CloudSync-Hosts'

# Adding a server later
Add-ADGroupMember 'gMSA-CloudSync-Hosts' -Members (Get-ADComputer NEWSERVER)

A new group member needs a fresh Kerberos ticket before it can retrieve the password, so reboot the server or run klist -li 0x3e7 purge on it. When switching existing agents to the group, add them to the group and refresh their tickets before you set the group as the principal. Otherwise they lose access.

A word on security#

All your agents share the same gMSA, and the installer gives that account a lot of permissions, including replication rights on the domain root and password reset on users. Every server that can retrieve the gMSA password effectively holds those permissions, so treat all agent servers as Tier 0.

• Keep PrincipalsAllowedToRetrieveManagedPassword limited to your agent servers only.
• If you use the group approach, protect that group like Domain Admins and monitor its membership. Whoever can add members can get the gMSA password.
• Run Test-ADServiceAccount customgMSA on your existing agent servers too. If the list was ever overwritten, they keep running until the next restart or password rotation, and then fail.

Wrap-up#

Two small things, a missing registry flag and a missing entry on the gMSA, and the agent would not start. The error messages don’t really point you in that direction, so I’m writing it down for the next time I (or you) run into it.

Stay safe!