Group Managed Service Accounts alias gMSA

This article will show the process I did to get my managed service account registered for using services like SQL and Task Scheduler.

Managed service accounts have been around for a while but was limited and only worked in the local security context of the windows server. Which meant that you couldn’t use the same account in a cluster of servers.

Usually only limited to Task Scheduler or simple applications.

Please read the following for a quick view on how the old technology worked for Managed service accounts:

Windows 2012 introduced Group Managed Service Accounts which meant, that it could be shared between servers this is great news and shows potential for other applications Like SQL 2012.

I used the following TechNet article to setup my first Group Managed Service Account which I’m going to use for SQL 2012: (Please look for my next blog post on how I installed SQL 2012 with my group managed service account.)

Ok let’s start


Please read the requirements from the article above. I’m only going to highlight the high level requirements.

To enable Group Managed Service Accounts Windows PowerShell is used and it requires to be run from a 64bit instance. I had a Windows 2012 Domain controller in my test environment so using the PowerShell from that server was sufficient. You also require the powershell AD Tools to be installed on the machine you are using.

Before you start

Before you start creating the group managed service account you need to know if the following:

  • Does the application service support gMSAs
  • Does the service require inbound or outbound authentication
  • The computer account names for the member hosts for the service using the gMSA
  • The NetBIOS name for the service
  • The DNS host name for the service
  • The Service Principal Names (SPNs) for the service
  • The password change interval (default is 30 days).

Step 1: Provisioning of group Managed Service Accounts

You can create a gMSA only if the forest schema has been updated to Windows Server 2012, the master root key for Active Directory has been deployed, and there is at least one Windows Server 2012 DC in the domain in which the gMSA will be created.

Important: Master root key is the tricky part. You can force the creation but when the master root key is created you’ll need to wait for AD Replication to complete. Will take up to 10 hours to complete just enable it and leave it for the next day.



  1. Check if a KDS root key exists “Get-kdsrootkey”
  2. If none exist create a new one “Add-KdsRootKey –EffectiveImmediately”
  3. Wait 10 hours or more (Enable it and leave it for a day)
  4. Test the KDS Root Key “Test-kdsrootkey –keyid <GUID from above>”
  5. Create a Security Group in AD which the computer accounts will be a member of to have access to retrieve the managed password. Important: Remember to reboot the computers once you have made them a member of a group.

  6. Add computer accounts as members to new group

    1. Reboot the server/s
  7. Create the gMSA “New-ADServiceAccount SQL2012Managed -DNSHostName -PrincipalsAllowedToRetrieveManagedPassword Allowed-SQL2012ManagedServiceAccount-Access -ServicePrincipalNames MSSQLSvc/SQL2012:1433,MSSQLSvc/”

  8. Success now you can start using the Managed Service Account for other installations.
  9. Open “Active Directory Administrative Center” to confirm Managed Service account creation


Step 2: Add the new service account to the required machines


Once you have created the Managed Service Account you need to assign it to all the required machines.

  1. Open Windows Powershell on the Server in my exsample I’ll open it on the SQL2012 Server that I’m going to use.
  2. Run the following command “Install-ADServiceAccount SQL2012Managed”

  3. To Confirm the account try to change a service to run under the newly created account

  4. Please see my next blog post on how to install SQL 2012 using managed service Accounts.

Leave a Reply

Your email address will not be published. Required fields are marked *