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 -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?


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:


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:


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


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

XenServer tools install hangs after reboot

As promised this is a continuation of my previous post where I described the pain of trying to install XenServer tools on an SBS server, BSOD and the recovery. Hopefully you’re not at the BSOD point yet and just staring at a XenServer tools install that isn’t progressing at all.

If that’s the case you can cancel the installation but before you reboot your server there are two things to do:

1. Remove XenServer tools from Control Panel – Programs and Features.

2. Stop and disable the Exchange Transport Service

After this you can reboot the server, reinstall XenServer tool within minutes and all is fine.

I have so far failed to find any Citrix KB articles to this effect but it will definitely save you a lot of problems.

In my case this was an SBS server but if you’re not running Exchange it might be worth stopping/disabling all non essential services.

XenServer Tools Nightmare

I actually really like XenServer but some things are just plain annoying. The list of annoying things is fairly long and this is my latest addition. Following a very straight forward upgrade from XenServer 6.0.2 to 6.2 which has gone far smoother than I expected even though without license you have to use CLI to install updates I have done the next logical thing – started updating XenServer tools on all VMs. First couple machines couldn’t have been easier but the problems came on the last one which didn’t have XenServer tools installed at all – and I soon learnt why.

After the first part of the install the server (SBS 2008) asked for a reboot after which the installation continued – apart from the fact that it didn’t really and just appeared to be stuck. I am a fairly patient person but when the installer didn’t move for an hour, no errors anywhere to be seen and the client getting a bit frustrated that their SBS server had no network connection (due to the MS drivers being replaced with Xen PVS driver) I have decided to cancel the install. This has taken a few minutes and then asked for another reboot. When the machine rebooted I got the not so lovely BSOD 0x0000007B.


Citrix KB articles just tell you to use Last Known Good configuration or Safe Mode – neither of which worked in this case.

After much research and starting a backup import from the previous night I have come across the solutions below which worked a treat:

1. Boot from installation media.

2. Select Repair your computer.

3. Enter command prompt.

4. Navigate to c:\windows\system32\config

5. reg.exe load HKLM\TEST system

6. Locate and delete LowerFilters MultiSZ scsifilt from HKEY_LOCAL_MACHINE\Test\ControlSet001\Control\Class\{4D36E967-E325-11CE-BFC1-08002BE10318\

I have just searched for “scsifilt” and found it in ControlSet002 as well and deleted.

7. Disable the following services by setting the Start value to 4:

[HKEY_LOCAL_MACHINE\Test\ControlSet001\Services\scsifilt / xenevtchn / xenvbd / xensvc

8. Close registry editor and unload the hive: reg.exe unload HKLM\TEST

9. Restart the machine and you should be able to boot into windows normally.

What actually causes this issue is the partial installation of XenServer tools leaves some drivers on the system: scifilt, xenevtchm, xenvbd, xensvc.

So at this point my server is up and running again albeit with no XenServer tools. Which will be the subject of my next post.