XenDesktop: Migrating dedicated catalog to another datastore

If you are looking to move your virtual machines to another datastore chances are you have already come across this Citrix article: How to Migrate Dedicated Catalog to Another Datastore.

Last week I have unsuccessfully attempted to follow it and thought I would clarify a couple of ambiguous points in the guide and it’s indented application.

First of all I need to point out that if you intend to move your base image file this guide isn’t going to do it for you. While you are asked to copy the base image to the new datastore it doesn’t tell you to delete it from the old location. This is because all the delta disks you move will still be referencing the original base image file location. So if you are hoping to decommission  some old storage and need everything to move, Citrix recommend you convert the linked clones to full clones – you can achieve this by a simple storage migration in vSphere. You can then remove them from the catalog and add again as existing. There is an inevitable increased storage requirement which is what you were probably trying to avoid in the first place but it is the safest and most reliable way of doing this.

You could also look at editing the vmdk configuration files of your moved VMs and setting parentFileNameHint to the new file path – I will delve deeper into this in a future post.

If the Citrix guide still fits the bill for you here are the parts that I found slightly unclear. Some of them may seem obvious but as I things weren’t working out for me I was questioning every step.

Step 5:

Copy vmdk to new storage.

VMware PowerCli command:

Copy-DatastoreItem 'vmstore:\vc-servername\source_datastore\ contosow7-baseDisk-datastore-11\*' 'vmstore:\vc-servername\dest_datastore\ contosow7-baseDisk-datastore-11\' -Force

After copy has been completed, base disk will be converted to thick format; diff disk will remain thin-provisioned.

What Citrix want you to do here is to copy all your machine’s deltas and the base image file over to the new datastore. The command above assumes they are all within the same folder (contosow7-baseDisk-datastore-11) but depending on how you have the files organised you might need to copy the base image file separately. You will also likely have your vmx and other configuration files in the same location and these will be copied over at the same time. These won’t be used for anything as when you recreate the machines a new folder will be create for each one. In effect there will a be some doubling up but nothing to worry about as the storage use will be negligible. You can also manually copy the files using the vSphere client and the effect will be the same.

Step 6:

Back up the base and diff disk folder defined in the filename column of the contoso_disk.csv file. Delete the machines to be migrated through the desktop studio console and choose the options to “Remove the accounts from the Catalog but do not remove them from Active Directory”.

You should already have  a copy of all this on your new datastore but you might want to backup within the same datastore to reduce the restore time if required. When you delete the machines from the catalog the diff disks will be deleted but the base image will remain intact anyway.

Step 7:

Create new machines with existing disks. (Import.csv) file is used with the columns shown in the following table.

VMName LastConnectionUser OldDiskPath NewDiskPath
contosow7AAA contoso\user1 [source_datastore] contosow7-baseDisk-datastore-11/contosow7-baseDisk-datastore-217-000005.vmdk [dest_datastore] contosow7-baseDisk-datastore-11/contosow7-baseDisk-datastore-217-000005.vmdk

VMware PowerCli command:
Import-Csv importcsv.csv -UseCulture | %{
$vm = New-VM -Name $_.VMName -VMHost 20.10.102.12 -MemoryMB 2048 -NumCpu 2 -GuestId “windows7_64Guest” -NetworkName “VLAN 123”  -Datastore “Dest_Datastore” -DiskPath $_.NewDiskPath
}

The OldDiskPath isn’t used during the machine creation at all so you don’t need to worry about it too much. The NewDiskPath is the path for the machine’s delta – not the base image file.

Hope this helps to avoid at least some of the confusion.

No XenDesktop license available?

Issue:

User can’t connect to XenDesktop, the session launches initially but stops at “Preparing your desktop” and then closes without any errors.

Event log errors on XenDesktop controllers:

No connection license available. To resolve, free licenses by closing sessions that are not needed, or add more licenses. Details: 
License Server Address: ‘LicenseServer.domain.local’ 
License Server Port: ‘27000’ 
Desktop ID: ‘CD8A4005’ 
User: ‘Domain\Username’ 
Client ID: ‘6F713A64’ 
Desktop Kind: ‘Shared’

Citrix Desktop Studio – Licensing:

image

If you’re scratching your head at this point thinking there’s no way you are using more licenses than you have the most likely cause is that Citrix Licensing Server allocated a few licenses to devices instead of users.

Citrix licensing server has a complicated algorithm for working out which type of license is going to work best for each session and allocates the license accordingly. Unfortunately this doesn’t always that well.

To check how you’re licenses are allocated logon to your license server, open command prompt and run

C:\Program Files (x86)\Citrix\Licensing\LS>udamin.exe –list

This will display all currently allocate licenses and look something like this:

image

As you can see there are 8 licenses allocated to devices which we need to delete using:

C:\Program Files (x86)\Citrix\Licensing\LS>udamin.exe –f XDT_PLT_UD –device 255C42F8 -delete

image

Just repeat this for each device name in the list and your license allocation should be back to normal.