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

Cheng Wei — Fri, 20 Feb 2009 05:19:00 GMT

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

Managing VM hosts in a disjoint namespace environment

Cheng Wei — Wed, 28 Jan 2009 21:43:00 GMT

Greetings folks and Happy Chinese New Year to you if you celebrate that cultural tradition!

Today, I wanted to talk about a topic that many of our TAP customers have requested support for during our VMM 2008 release development phase. We’ve seen customers with distributed and geographically dispersed regional offices or storefronts tend to have a disjoint namespace environment.

In that environment, where the FQDN of a Windows server in AD does not match the FQDN of the same server in DNS, you will not be able to search the host’s DNS FQDN through VMM Add Host wizard, as it searches against your AD. More importantly, even if you selected “Skip AD query” option on the admin console, the regular “Add Host” job would still fail if required AD operation step is not taken. The root cause of the job failure is due to the fact that we need to use the DNS host name to connect to the host via WS-MAN, but the following authentication fails when we try to authenticate the host’s DNS FQDN against AD.

Hence, in order for hosts in this environment to be successfully added and managed by VMM, the instructions below should be followed:

· We recommend users to setup/install their VMM Server by making the VMM service running under a domain account (instead of the default server machine account);

· If you’re adding your host in disjoint namespace from Admin Console, at the 2^nd page of the AddHosts wizard, you will need to check the option “Skip Active Directory name verification”;

· The SPNs of the DNS host FQDNs must be added to AD;

· For clusters, you will need to add the hosts by using the “Add-VMHost” cmdlet (see sample code below).

PS C:\> $Credential = Get-Credential

PS C:\> Get-VMMServer -ComputerName "VMMServer.Contoso.com"

PS C:\> $VMHostGroup = Get-VMHostGroup | where {$_.Path -eq "All Hosts"}

PS C:\> Add-VMHostCluster -Name "VMHostCluster.Contoso.com" -VMHostGroup $VMHostGroup -RemoteConnectEnabled $TRUE -RemoteConnectPort 5900 -Credential $Credential

In VMM 2008 release, we require users to manually add the SPNs (use command “setspn –a” with appropriate AD privilege). Here is a reference Technet article with information on how to create SPNs. For a large environment, you may want to consult with your AD administrator to run a script to add the SPNs.

For VMM vNext, we’re working on a better solution, if the VMM server service account has AD privilege to add SPN, our AddHost logic will attempt to add the host’s DNS FQDN SPN when the authentication fails. With this new feature, if customers configure their AD properly, it will eliminate a lot of manual and tedious AD operations. Here is a KB article that talks about how to create AD permissions to allow a service account to add SPNs.

Hope this helps.

Thanks for reading!

Cheng

Cheng's Random Thoughts on System Management : Disjoint namespace

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

Managing VM hosts in a disjoint namespace environment