Hello SCVMM Users, Michael Godfrey here again, Premier Field Engineer specializing in all things Private and Public Cloud including the Software Defined Datacenter.
It’s here, It’s here. The time has come for a new Long-Term Servicing Channel (LTSC) release of System Center 2019. I know first-hand that the Product Group behind Virtual Machine Manager has been hard at work bringing new features to make VMM a stellar part of your Private & Hybrid Cloud Deployment and I wanted to talk about one of my favorite new features before you begin the path to install VMM 2019.
In the past, VMM has had a requirement for a Service Account, this is the account that all VMM requests to the Hosts and Infrastructure components of VMM are made through. This has traditionally been a standard user account, that you or your Active Directory Administrator would create, set the password to a random string, and set the password to never expire. This was not a great idea in a modern infrastructure, especially when it came to security. This account has a lot of permissions, including local administrator rights on all of your hosts.
A wise manager once told me, “It’s not a problem, unless you have a solution.” So, in Windows Server 2012 a concept known as Group Managed Service Accounts was introduced, and these accounts are essentially a managed service account that provides automatic password management, provided by Active Directory. You can read more about them here.
What I am so excited to share with you today is after years of Microsoft products adopting GMSA’s, the time has finally come for System Center 2019. Now, as you prepare to install VMM 2019, you will have the option to supply a Service Account, a Local Account or a Group Managed Service Account. In this post, I want to share with you, exactly how you go about creating a GMSA and then use it to install VMM 2019. Here we go….
There are some prerequisites to creating a GMSA, there are great directions from our friends at Docs.Microsoft.Com; the link is here. The short end of it is, your AD Administrator will need to use PowerShell to create the Managed Service Account, you will need to provide the name of the account, and the “PrincipalsAllowedToRetriveManagedPassword.” This is quite simply the Computer Accounts that will be authorized to retrieve the password from Active Directory on an ongoing basis. In the instance of installing VMM, you will need to use all Servers that the VMM Server is installed on, so in a Stand-Alone environment, one machine. If you deployed VMM in a Highly Available Capacity, then all the nodes in the Cluster and the Cluster Computer Account Name itself will be included in this list. Here is an example command in PowerShell that can help you build the account on a domain controller.
New-ADServiceAccount SCVMMSVC -DNSHostName SCVMMSVC.Contoso.com -PrincipalsAllowedToRetrieveManagedPassword SCVMMCL, SCVMMNode1, SCVMMNode2 -KerberosEncryptionType RC4, AES128, AES256
Once you have the Managed Service Account Created and verified, you can use it for the install. When you get to the “Configure Service Account and Distributed Key Management” Page in the SCVMM 2019 Install Wizard, simply select the radio button; “Group Managed Service Account,” and enter the name of the service account. Please note this must be in the “FQDN\Service Account Name,” format, and be sure to include the dollar sign, $, at the end of the account name, as it is considered a computer account.
That’s it! Now continue through the wizard like normal and you will have set SCVMM 2019 with one of the newest features, GMSA. Now, the VMM Server will request the password from AD on a consistent basis and update the SCVMMService with the new Service Account password, all in the background, allowing you and your security team peace of mind that the Service account password is reset regularly and unknown to any humans.
I hope this helps and stay tuned for more blogs about new features in SCVMM 2019, as I will be posting new content on things like Storage Optimization, Azure Update Integration with VMM and Encrypting SDN VMNetworks in the future.
As always feel free to comment and reach out with any questions. Thanks again!