Aristotle, a man born in 384 BC, is known for the phrase “the whole is greater than the sum of its parts.” In the world of XenDesktop, we see this principle proven again. A virtual desktop delivered to a user is much greater than the sum of its parts, mainly because of its useful nature. We place greater value on what is useful to us and what makes our lives easier. What? Enough philosophy? OK.
A virtual desktop is comprised of various components and each has a name for identification purposes. The XenDesktop administrator will put a name to the desktop, the virtual machine, the target device, the vdisk and the AD Computer Account. With the XenDesktop Setup wizard, the target device in most cases is the same name as the AD Computer Account and the desktop name. This is because PVS adds the name of the target device into the Active Directory during the creation of the virtual desktop. From the DDC Farm Master, the pool management service talks to the host infrastructure and enumerates a list of virtual machine names. The DDC also talks to Active Directory through IMA subsystems and maps the virtual machine with an AD computer account. Where possible, the pool management service will correctly determine the mapping for the virtual machine to the Active Directory computer account by performing a DNS lookup on the virtual machine IP address.
When manually adding a virtual machine to a desktop group, you may sometimes see a problem with AD Computer Mapping. In some cases when this attempt fails, the SID may be displayed instead of the FQDN or the virtual machine does not map to the correct AD computer account.
In other cases, when you edit the mapping by browsing for the hostname you may get an error after clicking NEXT. The name mapping can fail for a number of reasons:
- DNS or Active Directory lookup failure
- Expired DHCP lease (if machine shut down)
- Other environment specific failures
The EDIT button is provided for these cases where the mapping is not automatically determined so the administrator can ensure all machines have assigned Active Directory computer accounts before proceeding.
Using Identical Copies of a Virtual Machine
Another reason for incorrect AD mapping occurs when using copies of virtual machines on the same host. The reason is that AD mapping gets written into the meta data of the VM. Virtual machine copies are often made and used in training and lab environments. In order to re-use a VM or copy of a virtual machine in the same host infrastructure, you will need to remove the AD mapping from its VM metadata. The data that is stored is the Active Directory SID of the operating system that has been installed on the VM and is used by the Desktop Delivery Controller to broker and manage the desktop. It ties together the DDC knowledge of the VDA and virtual machine.
Below are the steps for removing the SID from the virtual machine metadata in XenServer so that a new unique SID can be generated for the virtual machine copy.
- On the XenServer console run this command to get a list of virtual machines: xe vm-list |more (Get a list of UUIDs) uuid ( RO) : 336d086c-cc2c-fd18-a773-164ef11ad471
name-label ( RW): 02XD_VISTA
power-state ( RO): running
- After identifying the problem machine, use its UUID with the following command: xe vm-param-list uuid=336d086c-cc2c-fd18-a773-164ef11ad471 params=other-config |more other-config (MRW): last_shutdown_time: 20081016T15:35:11Z; last_shutdown_action: Restart; last_shutdown_initiator: external; last_shutdown_reason: rebooted; import_task: OpaqueRef:e583dfd7-53f5-01cc-ba2c-336502509551; mac_seed: ab2dd91b-55cb-b19c-479e-ea56aa29556c;GuestOsId: S-1-5-21-1444483920-1014756369-283082601-1126;
- Look for GuestOsId in the other config section and compare it to the AD SID. You will find that the copy of the vm has the same AD SID.
- Remove the GuestOsId using the following command: xe vm-param-remove uuid=336d086c-cc2c-fd18-a773-164ef11ad471 param-name=other-config param-key=GuestOsId
- Repeat this for every copy of the virtual machine that is running on the XenServer.
- Each machine must then be rejoined to the domain to get a new unique SID.
NOTE: For VMWare and Hyper-V, the parameter is called CTXGuestOSId and can be found and edited in the virtual machine metadata. Refer to VMware and Microsoft for further documentation.