Managing VM hosts in a disjoint namespace environment
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 2nd 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