Running AGPM with a Managed Service Account (MSA or gMSA)


Service accounts are dead. Long live MSAs! But where can you actually use MSAs/gMSAs? One place that often pops up is Advanced Group Policy Management (AGPM) from the Microsoft Desktop Optimization Pack (MDOP).

The installer for AGPM requires that you create a service account and enter its password manually. In a correctly configured AGPM GPO environment, no one will have access to edit the GPOs except this account. So knowing its password is a bad thing. But how can we get past the installer, so we can run AGPM using an MSA/gMSA?

Here’s how. Note this isn’t an official endorsement. I did this in my lab and it works fine. I checked with a few trusted colleagues and they think it’s fine too. If you really are moving away from manual service accounts, then try this out in your lab. You’ve now been warned.


There are 2 scenarios:

  1. A fresh install of AGPM
  2. An existing install of AGPM

The steps are almost identical. I’ll call out the differences as we go though the core steps.


1. Create the KDS rootkey for gMSAs if one doesn’t exist in the forest:

  • Only needed if using gMSAs in Windows Server 2012 or later AND the key hasn’t already been created

Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))

2. Create a gMSA called gMSA-AGPM$ with samaccountname = gMSA-AGPM$

3. Create a temporary user account (for use during AGPM installation) called svc-AGPM (if AGPM is already installed, you skip this step)

4. Assign both svc-AGPM and gMSA-AGPM$ “Logon as a Service” right on the AGPM server.

  • Note that this right may be defined a GPO, so local policy changes may be ignored. Set this right on the PO if needed.

5. Install AGPM using svc-AGPM (if AGPM is already installed, you skip this step)

6. Once the installation is done, stop the service “AGPM Service”

7. Remove the ServicePrincipalNname (SPN) for AGPM from the AD users ‘svc-AGPM’ and place it on gMSA-AGPM$ instead

8. Set the registry value at HKLM\Software\Microsoft\AGPM\ArchiveOwner to have the SID of gMSA-AGPM$

  • Use psgetsid.exe from Sysinternals to convert a username to a SID

9. Set the permissions on the AGPM data folder (by default this is C:\ProgramData\Microsoft\AGPM) and on the folder %windir%\temp to grant ‘Full Control’ on these 2 folders and all sub files and folder to gMSA-AGPM$

10. Set permissions on all GPOs to grant gMSA-AGPM$ full control using:

Set-GPPermission -All -PermissionLevel GpoEditDeleteModifySecurity -TargetName CONTOSO\gMSA-AGPM$ -TargetType Computer

11. Set permissions to the root of each domain to all gMSA-AGPM$ to have “Link GPO” rights to all OU objects:

$agpmserviceaccountname = “gMSA-AGPM$”

$domaindn = (Get-ADDomain).distinguishedname

$agpmaccountsid = (get-adserviceaccount $($agpmserviceaccountname)).sid

$newsddl = "(OA;CI;RPWP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;;$($agpmaccountsid))"

$objsecurity = get-acl -Path "ad:\$($domaindn)"


Set-Acl -Path "ad:\$($domaindn)" -AclObject $objsecurity

12. Remove all other accounts as having Editor rights to all GPOs.

  • Take care with this step in production as many files ACLs will be changed causing SYSVOL to re-replicate all data. Also, when you are removing permissions you may also accidentally remove “Apply GPO” and “Read” rights where they have been specifically set as a way of targeting GPOs to specific users, groups and computers.

13. Add gMSA-AGPM$ as a member to the AD group “Group Policy Creator Owners” and “Backup Operators”

14. Install the Service Account gMSA-AGPM$ as a managed account on the AGPM server using this cmdlet:

  Install-ADServiceAccount -Identity gMSA-AGPM$

  • Note that you will need the feature for AD PowerShell Module installed first to run the cmdlet Install-ADAccount

15. Set service properties for AGPM Service to logon as CONTOSO\gMSA-AGPM$ (keep the password fields blank)

16. Start the service “AGPM Service”

17. Remove “Logon as a Service” right for the temporary account svc-AGPM

18. Delete/disable the account svc-AGPM in the domain

19. Delegate rights in AGPM to domain users/groups to be admins/editors/approvers/reviewers as normal in AGPM

20. Delegate “Link GPO rights” for OUs to Admins in AD as normal

Comments (10)
  1. Mark says:

    Thanks for the article Craig.
    Have followed all steps but at the end when I try to Start the AGPM service I get a an error message.
    "The AGPM Service service on Local Computer started and then stopped. Some services stop automatically if they are not in use by other services or program."

    Are you able to identify what might be wrong?

  2. @Mark: If I had to guess I would think there was a permissions problem in the file system or registry. Retrace the steps above and if you can’t find your error, use Process Monitor and filter on "Process is AGPMService.exe AND Result is ACCESS DENIED".
    If you can’t find your error after that, roll back your changes. This isn’t an officially supported configuration and blog comments aren’t an effective forum for troubleshooting.

  3. wfdrde says:

    Thank you.
    And please correct step 11:
    $agpmaccountsid = (get-aduser $($agpmserviceaccountname)).sid to
    $agpmaccountsid = (get-adserviceaccount $($agpmserviceaccountname)).sid
    Get-AdUser can’t search gMSA

  4. @wfdrde: Thanks for the catch. I’ve updated the post with the correction.

  5. wfdrde says:

    One more thing: in step 14 we should use "gMSA-AGPM$" instead of "CONTOSOgMSA-AGPM"
    Install-ADServiceAccount -Identity gMSA-AGPM$
    (Such error with "CONTOSOgMSA-AGPM": Cannot find an object with identity: ‘CONTOSOgMSA-AGPM’ under: ‘DC=CONTOSO,DC=com’.)

  6. @wfdrde: Thanks again, updated step 14 accordingly.

  7. wfdrde says:

    Thank you. We have realized this scenario successfully for our AGPM servers. So I have one question: on domain delegation tab I see Full Control for original (old) agpm service account, and it’s inherited (from somewhere I don’t know) so I can’t remove
    it (even on the advanced tab with removing inheritance). It’s not critical but it will be more "glance" if there will be no old account in list. As I understand this is previous archive owner which we have changed on step 8 but that step don’t remove original
    account from domain delegation tab. Can you comment this?

  8. Frank says:

    Thanks for article.
    Script will not set the acl for the domain:
    set-acl : This operation is not supported for RootDSE
    InvalidOperation: (//RootDSE?:String) [Set-acl], NOtSupportedException

    Any ideas?

    1. You are hitting RootDSE when you run “get-addomain” which sounds like you aren’t running as a domain account. You need to get back your domain when you run “get-addomain”

  9. Alan Doran says:

    Has anyone been able to get this running in a single forest/multi domain scenario with the AGPM Server in the Forest Root domain?

Comments are closed.

Skip to main content