Share via

When should I consider running my VMM Service by using a domain account?

  • Article

Greetings folks!

 

Hope you all had a good Valentine weekend last week!

If you noticed, during your VMM Server installation, there is an option of allowing you to select a different account to run VMM Server service (VMMService) from the default computer account.

 

 

“When should I consider using this non-default option? ”, you may ask.

You may have other reasons / policies to run VMMService by using a domain account. However, based on some of our recent CSS reports, choosing your own domain account to run VMMService should be a preferred option for customers who are running a more restrictive AD environment. Here is why:

· With default install option, VMMService is run under the VMM Server local system / computer account.

· When adding trusted domain-joined VM hosts (whose domain has two-way trusts with the domain VMM Server is in), VMM Server adds its computer account (the account it uses to run VMMService) into the local administrator group of the target VM hosts, as part of the Add-VMHost process.

· In a more restrictive AD environment, we find it common for customers to have a “Restricted Groups” group policy that disallows machine accounts to be part of the local administrators group. Hence, when the GP is in effect, the machine account will be removed by this GP.

· And when this happens, the affected VM Hosts will show up in VMM console as “Needs Attention” (and the agent status will be “Not Responding”), since the VMM Server will no longer be able to authenticate with the hosts. Here is error message that you will see from the failed host refresher job (BTW, we’ll be updating this error message in our vNext):

Error (2927)

A Hardware Management error has occurred trying to contact server servername.domainname.com.

 (Unknown error (0x80338104))

Recommended Action

Check that WinRM is installed and running on server servername.domainname.com. For more information use the command "winrm helpmsg hresult".

When users get into this situation, there are a few options they can do to fix this issue:

1. Check with your IT security group and see if it’s possible to disable the “Restricted Groups” group policy in your Active Directory environment; or

2. Check with your IT security group and see if it’s possible to modify the group policy to allow the VMM machine account in the Local Administrators group; or

3. Check to see if it’s possible to move the VMM Server machine account to its own organizational unit (OU) and block the group policy from being applied to that OU; or

4. If making changes to your group policy (or negotiating with your IT security group J) is next-to-impossible, the only option left is to reinstall the VMM server and choose the option to run the VMM service by using a domain account with admin privilege on your VMM Server computer (in this case, you will need to remove and re-add all your VM hosts, or choose to reinstall your VMM Server without retaining data).

Hence, I highly recommend users to evaluate your IT security (AD) policies before deploying your VMM server into production environment, as those factors do directly affect how VMM performs operations within that environment. And, if you do have a more restrictive AD environment, I suggest you to use a domain account to run VMM Server service. Also, if you have a disjoint namespace environment, it's also recommended to use a domain account to run your VMM Server service.

Before I close on this subject, there is one restriction that I think folks should be aware when using a domain account to run your VMM Server service:

· Users cannot use the same domain user account to add or remove hosts.

o Say, you configured VMM Server to use account “foo\bar” to run VMM Server service.

o And it also happens to be part of the local admin group for a host “MyNewHost” that you want to add to VMM.

o When we go through AddHost wizard (or through our cmdlet), you will be asked about a credential with admin privilege for us to install agent.

o At this point, it’s disallowed to use the same user account “foo\bar” to add the host. And yes, we actually block you from doing such operation.

o The same is true for host removal, it’s disallowed to use the same account “foo\bar” to remove the host.

· Why do we not allow this?

o During host addition, we add the service account to the local admin group on the host. When removing the host, we need to remove the account from the local admin group.

§ If we remove the account first, we won't be able to talk to the agent.

§ If we remove the agent first, we leave the account behind.

§ Thus, users need to use a different account for host removal.

o During host addition, we add the service account to the local admin group on the host.

§ In case of failure during the agent install process as part of the AddHost task, we need to be able to roll back and successfully remove the agent.

§ To do that, we need the same requirement.

· So, the proper process is that if you use “foo\bar” to run your VMM Server service, you will need to use a different account with admin privilege to add or remove your host.

Hope this helps and thanks for reading!

Thanks,

Cheng

Comments

  • Anonymous
    May 25, 2012
    I strongly disapprove one part: There is no need for REINSTALLATION! You could simply run>services.msc and change Logon details for the "Virtual Machine manager" and "Virtual machine manager agent". I've done it- it's 100% working now.