Migrating a XenDesktop environment from VMware to Hyper-V

I have had a recent need to migrate a working XenDesktop environment from VMware over to Hyper-V. One thing that is important to this process is SCVMM.

Following are some guidelines that can be used by most anyone who is in this situation.

The (fully) Virtual Environment:

• XenDesktop 4 Desktop Delivery Controller (Windows 2003 R2, x64, 2vCPU, 4GB RAM, 1 NIC)
• Licensing Server (Windows 2008, x86, 1 vCPU, 2GB RAM, 1 NIC)
• Web Interface server (Windows 2008 R2, 2 vCPU, 4GB RAM, 1 NIC)
• Provisioning Server (Windows 2008, x64, 4 vCPU, 16GB RAM, 1 NIC)
• Master VM (the VM where the desktop image is installed, Windows 1, 1 vCPU, 1GB RAM, 1 NIC)
• PvS Template (the VM template that is cloned to create new Desktop virtual machines)
• Desktop VM (the actual virtual machines that the Provisioning Server image is streamed to and runs the users applications)

Manage vCenter from SCVMM:

1. Use the “Add VMware VirtualCenter server” option in SCVMM to place the vCenter environment under the management of SCVMM
1. Don’t fear, this does not take full control of the environment, by default it will just enumerate everything.
2. Update the Security Settings of each ESX host.
1. Right click each ESX host and add the security settings for the “root” account.
2. If these are new installation of ESXi the root password is blank by default, SCVMM does not accept blank, so a password must be set.
3. Wait a bit for “bake time” to happen
1. This is a bit of time for all of the elements in the environment to be enumerated and fully recorded properly.

Store each VM in the SCVMM Library:

1. Store a VM in the Library
1. Power Off a VM
2. Right Click and Select “Store in Library”
1. This will delete your VMs from the VMware ESX servers.
2. Set the MAC address of the VM
1. From the Library View select “VMs and Templates”
2. Right click the VM and select Properties
3. Select the Hardware Configuration tab and select the Network Adapter
4. Change the MAC address assignment to static (note that the Current address is set) and select OK
5. If the VMs are diskless and boot from a Provisioning Server be sure that the network adapter type is “Emulated”.

Deploy each VM to a Hyper-V hypervisor:

1. Convert each VM to deploy it on Hyper-V
1. From the Library View select “VMs and Templates”
2. Right Click the VM and select Convert Virtual Machine
3. Complete the wizard with one of your Hyper-V servers or clusters.
2. Repeat as necessary.
1. The conversions will have a job status of “Completed w/ Info” because these VMs do not contain boot volumes, so the conversion process does not find one.

Application Configuration Update:

1. Double check DNS and IP address settings
1. The conversion process will install the Integration Components into the VM and thus the OS in the VM will detect a new NIC. If the IP addresses are manually set, then they will need to be set again. If the IP addresses are assigned by DHCP the same IP address should be granted because you carried the MAC address forward (step 5).
2. The XenDesktop installation uses Fully Qualified Domain Names and therefore relies on DNS, so make sure that all of the machine names are resolving properly.
2. Double check all Provisioning Server Settings
1. If the IP address of the Provisioning Server VM has changed be sure to make that configuration change in the Server configuration of your Site.
2. Don’t forget that your VM images will need an “Emulated” network adapter for the network adapter that Provisioning Server will use to stream to the VM.

Update the Desktops and Desktop Groups

1. Update the vDisk Image from the Master VM
1. Be sure to set the vDisk to read / write mode in its settings in Provisioning Server.
2. A gotcha to be aware of: the PVS driver binds to the NIC driver of the machine when it is installed. Converting the VM to Hyper-V installed the Integration Components and removed the VMware tools; causing the NIC and / or driver in the VM to be changed and therefore breaks the PVS Image driver. To resolve this uninstall and re-install the PVS “Target Device” software on the Master VM.
3. Run XenConvert to update the vDisk with the latest working Master VM image.
4. Set the vDisk back to Standard Image mode.
2. Create new Desktop Groups
1. New Desktop Groups need to be created using the XenDesktop management console.
2. Or the old Desktop Groups need to be deleted and created again using the new Hosting Infrastructure.
3. Verify your Desktop Group is working
1. Now that all settings are in place; wait for the DDC to refresh the desktop groups and to spin up virtual machines for the idle desktop pool.
2. Check the console of a few VMs to see that the PVS image is streaming properly and connect to a desktop.

The summary

With one practice run I would feel confident in understanding the process to do this with a production environment – I would probably handle it in stages – but I would know enough to be able to properly plan.

The key to this process is that the VMs undergo a two-step process. First storing to the SCVMM Library and then converting to a Hyper-V hypervisor. The bonus is that the MAC address can be carried forward from the VMware environment. This makes no changes in the setup of Provisioning Server groups.

In Summary:

1. Manage vCenter from SCVMM.
2. Store the VM(s) in the Library
3. Set the MAC address of the VMs to static (to not change settings in Provisioning Server)
4. Convert the VM(s) to a Hyper-V hypervisor
5. Update the vDisk Image
1. Uninstall and re-install the PVS client due to the virtual NIC driver changing.
6. Re-create / create new desktop pools

Hyper-V Dynamic Memory as a tool for understanding your Applications

In case you missed it, MSFT is making a bit of noise about the new Dynamic Memory feature that is coming in the SP1 release for Server 2008 R2 / Hyper-V Server R2.

My angle on this is a bit different than most.

The way that Dynamic Memory has been implemented by the MSFT folks is rather interesting.  It is memory ballooning under the hood – but it is hooked into the operating system of the VM in a way that only Microsoft could (as it owns the OS in this case).

What I find most interesting is the way that the Dynamic Memory feature responds to the needs of the application that is running in the virtual machine.

If the application begins needing additional RAM, then Dynamic Memory attempts to give it some, once the application frees up the RAM, then Dynamic Memory takes it back away.

This has the net effect that your machine is always running in an optimal ‘sweet spot’ as far as RAM is concerned.

The most interesting part is that you can perform actions against your VM and you can see how Dynamic Memory responds and in turn understand how your application demands additional RAM.  You can load it to a certain level and get a really good baseline.

Considering that managing a virtual environment is still a bit of a black art this is highly useful in really understanding the demands of your workload in a way that means something.  This directly correlates to a resource – RAM of all things – a very finite resource in most cases.

The end result is that you get a really good indicator of the range of RAM that your workload really needs.

I have said for years that most folks give their servers too much RAM (especially VMs) – and this is a great tool to prove it and to give a really excellent indication of the true RAM utilization of your workload.

Yes, you have to observe the numbers (in the UI or through polling WMI) but I think the return that you get for your time spent doing that is well worth it.

Migrating a XenDesktop environment from VMware to XenServer

I have had a recent need to migrate a working XenDesktop environment from VMware over to XenServer.

Following are some guidelines that can be used by most anyone who is in this situation.

The (fully) Virtual Environment:

• XenDesktop 4 Desktop Delivery Controller (Windows 2003 R2, x64, 2vCPU, 4GB RAM, 1 NIC)
• Licensing Server (Windows 2008, x86, 1 vCPU, 2GB RAM, 1 NIC)
• Web Interface server (Windows 2008 R2, 2 vCPU, 4GB RAM, 1 NIC)
• Provisioning Server (Windows 2008, x64, 4 vCPU, 16GB RAM, 1 NIC)
• Master VM (the VM where the desktop image is installed, Windows 1, 1 vCPU, 1GB RAM, 1 NIC)
• PvS Template (the VM template that is cloned to create new Desktop virtual machines)
• Desktop VM (the actual virtual machines that the Provisioning Server image is streamed to and runs the users applications)

The Export:

1. Use vApp containers to export OVF packages as groups of machines
1. Organize the XenDesktop application tier machines into a vApp container named “Infrastructure”. This is so they can be exported as a group of machines in a single OVF package.
2. Power off the Infrastructure vApp (this can also be done individually by virtual machine).
3. Export the Infrastructure to an OVF package
1. Be sure to select the Infrastructure container and choose File, Export, Export OVF Template. Leave the option to export to an OVF (a folder of files) – this speeds up the process since there is no requirement for creating a single OVA file (which takes longer to export and import).
4. Export the Master VM
1. To keep the Master VM as uncluttered and clean as possible it is recommended to uninstall the VMware Tools prior to export.
5. Export the PvS VM Template
1. If for no reason other than documentation purposes because the OVF contains all of the settings of the original template. With XenServer it is recommended to use an included base template for optimal configuration.
6. Export the virtual desktops - an additional export consideration
1. Before exporting the currently deployed virtual desktops there are two options to think about. Do you export your existing virtual desktops (this is highly useful if they have local cache disks on the hypervisor) or do you not export your existing virtual desktops. In both cases you need to create new desktop groups on the Desktop Delivery Controller.
2. If your Desktop VM images were derived from a template (for example: using the XenDesktop Setup Wizard) the deployed desktop virtual machines probably have dynamic MAC addresses assigned to the VMs.
1. The VMware OVF does not record the currently assigned MAC address if it is set to dynamic. This means that when imported these machines will be assigned new MAC addresses.
3. If Provisioning Server is used; the “auto add” feature can be implemented, to automatically add the Imported desktop VMs to Provisioning Server or the MAC addresses of each VM can be updated in the XXX configuration of Provisioning Server.
4. If you choose to not export the existing Desktop virtual machines you can create new Desktop groups using the PvS Template with the XenDesktop Setup Wizard on the XenServer environment.

In this example I elected not to export the virtual desktops. Primarily because they are pooled and there is little benefit in doing so.

The Import

1. Import the OVF packages into XenServer using the fix-up option
1. From XenCenter select a target XenServer, Resource Pool, or folder and launch the Appliance Import Wizard from the File menu.
2. Browse to the Infrastructure OVF package and begin the import. Be sure to use the “fix-up” option because these machines were built on ESX server.
2. Install XenTools into each VM in the environment
1. Before powering on each VM be sure to check that the original VM is powered off (or disconnected from the network). Otherwise there will be two of the same machine on the network at the same time.
2. Log into each VM and install the XenServer tools, reboot, and proceed to manually fix any network settings. Don’t forget the Master VM.

Application Configuration Update

1. Make any setting changes to the XenDesktop and Provisioning Server applications
1. If you didn’t already do so login to the XenDesktop console and disable the Desktop Groups specific to the VMware environment
2. The XenDesktop installation uses Fully Qualified Domain Names and therefore relies on DNS, so make sure that all of the machine names are resolving properly.
2. Double check all Provisioning Server Settings
1. If the IP address of the Provisioning Server VM has changed be sure to make that configuration change in the Server configuration of your Site.

Update the Desktops and Desktop Groups

1. Update the vDisk Image from the Master VM
1. Be sure to set the vDisk to read / write mode in its settings in Provisioning Server. Also, modify the machine configuration in Provisioning Server with the new MAC address of the Master VM.
2. A gotcha to be aware of: the PVS driver binds to the NIC driver of the machine when it is installed. Migrating the VM to XenServer and installing XenTools and uninstalling VMware tools all cause the NIC and / or driver in the VM to be changed and therefore breaks the PVS Image driver. To resolve this uninstall and re-install the PVS “Target Device” software on the Master VM.
3. Run XenConvert to update the vDisk with the latest working Master VM image.
4. Set the vDisk back to Standard Image mode.
2. Use the XenDesktop Setup Wizard to create new Desktop Groups
1. Create a new VM in your XenServer environment (using a XenServer template)
2. Convert this to a Template
3. Run the XenDesktop Setup Wizard to build out a new set of replacement desktop images.
3. Verify it is working
1. Now that all settings are in place; wait for the DDC to refresh the new desktop groups and to spin up virtual machines for the idle desktop pool.
2. Check the console of a few VMs to see that the PVS image is streaming properly and connect to a desktop.

The summary

With one practice run I would feel confident in understanding the process to do this with a production environment – I would probably handle it in stages – but I would know enough to be able to properly plan.

In Summary:

1. Use vApp containers to export OVF packages that contain groups of machines.
2. Import the OVF packages into XenServer and use the fix-up option.
3. Install XenTools into each VM in the environment.
4. Double check network settings (including DNS) of each infrastructure VM.
5. Make any modifications I needed in Provisioning Server settings for new VM MAC addresses and Server IP address changes.
6. Update the vDisk Image
1. Uninstall and re-install the PVS client due to the virtual NIC driver changing.
7. Re-create the desktop pools

The Video Companion

For the impatient among us I have outlined the basic steps and gotchas in the following video:  http://www.citrix.com/tv/#videos/2748

Machine domain accounts and snapshots

Every now and then this particular issue creeps into the forums.  A VM is reverted to a previous snapshot and domain membership is broken.  Or a new VM is created using a base image that is domain joined.  Or some other related scenario.

The first point to always remember is that a snapshot is a moment in time.  When you revert to a snapshot you go back to that previous moment in time and all of the settings that were active at that point in time (as far as the OS in the VM is concerned).

This most commonly manifests itself with machines that are domain joined at the time the snapshot was taken, then the machine runs for a period of time, during this time the machine account password is changed.  Thus when the VM is reverted to a previous snapshot the machine account password in the VM no longer matches the machine account password in Active Directory.

The machine is denied access to domain resources, but runs, it has a machine account in Active Directory.  Nothing looks out of place until the access denied behavior is noticed either by users or through trolling Event Logs.

There is some good background information from the Directory Services blog about machine accounts and Active Directory that you can review here:  Machine Account Password Process

There are two ways to deal with this situation:

1. Un-join the VM form the domain, delete the computer account from AD, and then re-join the Domain.
2. Prevent machine account password from changing prior to taking any snapshots: Disable machine account password changes

Keep in mind – the machine account passwords are designed to change silently in the background for a reason.  To prevent an un-trusted, malicious machine from impersonating a trusted machine and thus gaining access to your domain.  So don’t take changing this default behavior lightly.  By modifying this default behavior you are making a conscious decision to increase risk and decrease security in your environment.

Installing and configuring Test Agents when not in the same domain as the Test Controller

I think that the title says a lot in this case. 

I have a Team Foundation Server and I have a Test Controller registered to it. 

I also have Test Agents – they hang out in the lab (not in the production domain with the TFS Server or the Test Controller) so I need to have authenticated communication between the Agents and the Controller.

The most likely scenario is; the Test Controller is in the same domain as the TFS application server (assuming the TFS application server is in your production domain) and the Test Agents are not, nor is there a domain trust.

The Agents could be / should be in most any domain and most likely will execute their tests within an isolated test domain.

Installation and configuration of the Test Agent always requires local administrator rights, it is registration of the Test Agent with a remote Test Controller that can involve unique combinations.

If the Test Agent machine and the Test Controller machine are not joined to the same Active Directory domain or they are not joined to fully trusted domains (or the Agent machine is not domain joined) then:

1) Create local computer account on the Test Controller and each Test Agent machine to provide authentication.

2) This local account should have the same username and password across the Test Controller and Test Agent machines.

3) The “password never expires” check box should be checked.

4) When configuring the Test Agent username do not include the name of the local machine (machinename\username) use only the username (username).

Installation using the common local user account:

a. If this local user account is used to install the Test Agent software then the user account should be assigned to the local administrator security group of the Test Agent machine.

i. If this local user account is used to configure the Test Agent and register it with the Test Controller the local user account should be assigned to the local administrator security group on both the Test Agent and Test Controller machines.

Installation using an administrator account (not the common local user account):

1) The local administrator account can be used to install the Test Agent on the agent machine(s) as long as the local administrator user account password is the same on the Test Controller and Test Agent machines.