Moving a Unidesk Cachepoint (CP) from one datastore to another using standard VMware tools is problematic because the layers created by the CP are non-persistent independent disks. If these are moved with a storage vMotion, they will be transformed into normal disks attached to the CP and all the desktops using the CP will have the wrong path to the layer files. Also they will all be converted from Thin to Thick disks during the move.

The Unidesk Appliance Move Utility provides a mechanism to perform any of the following tasks

1. One Time Move Within A vCenter
2. One Time Copy To New vCenter
3. Synchronize Continuously

Where to download ?

Certain legacy Citrix tools are now available on request only. Please submit the request here - https://forms.gle/obA39PEz5qpDiSPq8

Once we verify your request, we will provide access to the download location. 

One Time Move Within a vCenter

This option should be chosen when migrating appliances to a new storage array or to split out CPs that were installed together on a datastore. This can also be used to split the boot datastore form the layer datastore if they were originally deployed together or to do the opposite and combine the boot datastore with the layer datastore because they were originally separated.

This option uses Storage vMotion to move the appliances without changing their VM-IDs. Before performing the migration of the appliances or desktops, all backup snapshots are deleted and all non-persistent disks are removed. For desktops these disks are re-added after the vMotion and the backups will be re-established during the next backup cycle. The old backups should still be functional. This ensures that the layers are safely migrated along with the appliances and desktops.

After performing the migration the only change required is to edit the CP properties to assign the new boot datastore and/or archive datastore.

It is important to make sure the desktops will not be started by View or Unidesk during the move process. The best way to do this is to from the UDMC: shutdown all the desktops on the CachePoint and place them in “Maintenance Mode”. Before starting the move process make sure there are no BICs running for those desktops.

One Time Copy to New vCenter

This option should be chosen to seed a new environment from an existing environment. Using this option the appliances will be cloned and the layers copied to the new datastore. This option also provides the ability to rename the appliances as they are cloned which will also rename all the associated vmdk, vmx, vmsd files and entries.

If selected the CP and Desktops will be shut down during the process and started back up at the end. For the MA you have a choice to shut down the MA prior to the copy or create a snapshot for the backup. If you choose to not shutdown the MA appliance before the copy, the appliance copy will be left in a “crash consistent” state which means that it is the same as if you powered off a server with the power button.

The restore process for this option is more complicated. See the Detailed Directions section of the PDF included in the downloadable file on this page for more information.

Synchronize Continuously

If the “Synchronize” option is used, then your primary MA, MCP and CPs can be synchronized on a scheduled to a backup version and only modified layers will be copied as well as a full version of the appliances and boot layers. This can be used to backup the MCP with shorter backup times than our MCP Backup utility or to keep a primary and DR version of the MA, MCP and Secondary CPs.

During this process the CP virtual machine and desktops will be shut down prior to the copy and started up after the copy. This ensures that the appliance will be safely processed. For the MA you have a choice to shut down the MA prior to the copy or create a snapshot for the backup. If you choose to not shutdown the MA appliance before the copy, the appliance copy will be left in a “crash consistent” state which means that it is the same as if you powered off a server with the power button. This is because a snapshot is taken, then the VM’s files are copied directly from the source but the snapshot is not copied.

In order to use this utility, you require:

• A VMware vCenter Administrator Account defined at the root of the vCenter
• The source and target datastores must be accessible from at least one host defined in vCenter but it does not have to be the same host
• vMotion must be enabled for hosts used in the process
• Windows 7,8,10 Client or Windows 2008 R2, 2012 or 2012 R2 Server to run the utility (utility host)
• This release has now been tested on vSphere 5.0 through 6.5.
• VMware PowerCLI 5.5 Release 2 or later installed on the utility host
  • Note PowerCLI 6 requires PowerShell 3.0 or 4.0 and .Net 4.5
  • Note PowerCLI 6.5.1 requires PowerShell 5.0 or later and .Net 4.5 or later.
  • When using vSphere 6.5 you can use PowerCli 6.0, 6.3 or 6.5. VMware made a major change to PowerCLI in PowerCLI 6.5.1. They removed the MSI installer and now use the PowerShell Gallery to install it. You may find it easier to use PowerCLI 6.3 R1 or 6.5 R1 as they have an MSI installer. All of these will work fine with vSphere 6.5. See the install section of the PDF included in the downloadable file on this page for more information.

If you are transferring from local storage to local storage or to storage not accessible from all hosts then you must move desktops and the CP together or the desktops layers will be orphaned when the CP is moved.

Please refer to the complete installation documentation included in the downloadable file at the top of this page.