Horizon Migration Tool – XenApp to Horizon (eek!)

Source: Fling Labs

Summary

The Horizon Migration Tool helps you migrate published applications and desktops from XenApp to Horizon View. One XenApp farm is migrated to one or more Horizon View farm(s).

The GUI wizard-based tool helps you:

  • Validate the View agent status on RDS hosts (from View connection server, and XenApp server)
  • Create farms
  • Validate application availability on RDS hosts
  • Migrate application/desktop to one or multiple farms (new or existing)
  • Migrate entitlements to new or existing applications/desktops. Combination of application entitlements are supported
  • Check environment
  • Identify incompatible features and configuration

screenshot
Click to enlarge

Windows 2008 R2 cluster Issue with Quorum drive to a new drive on SAN migration

Check out these two links.  Everything should work… but it doesn’t always.

http://www.ryanjadams.com/2011/07/move-cluster-quorum/#axzz3T5HU9X6N

http://blogs.technet.com/b/hugofe/archive/2012/07/04/windows-2008-2008-r2-san-migration.aspx

Shutdown the cluster

– Disconnect the iSCSI connections

– Move the LUNS on the storage side.

– Offline the old LUNS

– Connect a node to the new storage, check disks appear in disk management as ‘reserved’

– Start the cluster, make sure everything is OK then apply to other nodes.

I added a shutdown of one of the nodes in one of the following steps.

  1. From cluster manager,
  2. right click on the cluster
  3. go to More Actions,
  4. select Configure cluster Quorum Settings.
  5. Change from Node and Disk Majority and switch to only Node Majority.
  6. Once that is complete, disconnect the old LUN from the cluster.
  7. Add the new LUN to the cluster
  8. Go back to quorum configuration and switch back to node and disk majority.

Note:

The cluster software writes a disk signature to each drive (LUN) and that is how it keeps track of them.  If you preserve the complete contents of the LUNs, it should not have any issues recognizing them on a different IQN.

Citrix PVS database Move

CTX130499

How to Migrate a Provisioning Services Database to a New SQL Server

Objective

This article will cover the steps necessary to migrate an existing PVS database to a new database on an existing SQL server or to a new database on a new SQL server.

Instructions

  1. Backup the existing PVS database.
  2. Restore the PVS Database on the new SQL server following Microsoft best practices for database restoration.
  3. Shutdown all target devices.
  4. Run the configuration wizard on the first PVS server and choose “Join existing farm”.
  5. Specify the new server and database and finish running the wizard.
  6. Complete the previous step for all PVS servers in the farm.
  7. Begin booting the target devices.

My environment is using provisioning server 5.6. 1.1045 (soon to be upgraded).  Can’t wait to see the RAM overflow feature.

Services run as domain account =  service name

Citrix PVS Ramdisk Server = Manual

Citrix PVS Soap Server = Automatic

Citrix PVS Stream Service= Automatic

Convert XenServer XVA to VMDK for VMWare ESXi 5.1

Source: http://didyourestart.blogspot.com/2013/03/convert-xenserver-xva-to-vmdk-for.html?m=1

Convert XenServer XVA to VMDK for VMWare ESXi 5.1

During our conversion from XenServer to VMWare I had one machine that had a woopsy and would no longer boot in XenServer without BSOD.  Of course, this is the ONE machine I didn’t snapshot first HA.

Environment:
XenServer 5.6 SP2
ESXi 5.1

Cause:
During the conversion, I uninstalled the XenServer tools.  When I went to use VMConverter on the machine it couldn’t find the disk due to drivers on the SCSI controller.  So, I went to select a generic driver for the controller and low and behold, I selected the wrong one and rebooted.  ACK  Of course I was greated by the BSOD.

Solution:
I could have just rebuilt the machine, but it was one of those pain machines (ie, reconfiguring it would be more painful then spending an hour seeing if I could fix it).

  1. Export from XenServer to XVA format
    1. I tried to export to OVF, but it would fail and after some quick looking on the citrix forums it looked like it would likely be easier to export to xva then convert to ovf
  2. XenConvert v2.3.1  (version 2.5 doesn’t have the options necessary to do this)
    1. From = Xen Virtual Appliance
    2. To OVF
    3. This converts to OVF format which gives you 2 files, an OVF and a VHD
  3. WinImage v8.5 (http://www.winimage.com/download.htm)
    1. Disk dropdown
    2. Convert virtual hard disk image
    3. Select the OVF (vhd file)
    4. OK
    5. Type name and change save as type to vmdk
    6. When you click save the conversion starts
    7. At the end you don’t need to mount it with winimage
  4. Create a new virtual machine using the datastore that you want.
    1. Edit the VM and delete the Hard Disk
    2. Browse the datastore and delete the vmdk file
  5. Veeam FastSCP (I used the older version)
    1. Copy the 2 files that WinImage created to the datastore VM Folder
      1. both are vmdk files.  One will be large the other small.  Both are required for this to work (otherwise when you add a hard disk in the next step it won’t see it)
  6. Back in VMWare now
    1. Add hard disk
    2. Browse to the VMDK and select it
    3. Boot
    4. Login and install tools
    5. Restart
  7. Change the disk from IDE to SCSI
    1. In VMWare edit the VM and add a new hard disk of 1GB using SCSI (this pulls the controller into the image)
    2. Delete the disk you just created
    3. shutdown the VM
    4. Now we have to edit the vmdk, this can be done using vi, but I’m a windows guy so I used notepad++ on my workstation
      1. pull a copy of the small vmdk down to your local drive using Veeam FastSCP
      2. edit with notepad++
      3. modify the line “ddb.adapterType = “ide” change to “lsilogic”
      4. save and push the file back up to the datastore overwriting
      5. Delete the primary IDE hard disk
      6. Browse the datastore and delete the 1GB vmdk that we created earlier (for getting the LSI controller installed)
      7. Add new hard disk and point to the vmdk
      8. It will find it as SCSI / LSI Logic
      9. Note: if you have a CDROM, it will be IDE 0:1, so you’ll want to delete it and re-add it so that it picks up IDE 0:0
      10. Boot

Migrate XenServer VM to VMware ESXi 5.5

The following was found on Experts-Exchange

1. download and install VMware vCenter Converter Standalone 5.0
2. select convert machine
3. select source type “Powered-on machine”
4.put the details for the remote machine
5. enter the vCenter or ESXi/ESX host details
6. give it a name and select a location
7. select a datastore
8. finish and wait

Convert from XenServer 5.6SP2 to VMWare ESXi 5.

The following is taken from http://didyourestart.blogspot.com/2013/02/convert-from-xenserver-56sp2-to-vmware.html

It’s best practice to rebuild rather than convert.  I only converted machines that couldn’t be rebuilt, where being replaced soon (but not ready to replace just yet), or when I was short on time and had to move it immediately.

Server 2008 / 2008 R2

  1. Download and install VMWare Converter 4.3, yes, the older version
  2. Disable any services necessary (ie, IIS, etc)
  3. Ensure your logged in through the default view, not RDP.
  4. Uninstall XenTools and reboot
  5. Go into Device Manager
  6. You’ll see that the SCSI Controller doesn’t have a driver.
    1. VMWare converter won’t see the disks because of this
  7. Right click the SCSI Controller
  8. Update Driver Software
  9. Browse my computer for driver software
  10. Let me pick from a list of device drivers on my computer
  11. (Standard IDE ATA/ATAPI contoller)
    1. IDE Channel
    2. If you get the wrong one you’ll likely see a BSOD upon reboot
  12. Reboot
  13. Open VM Converter
  14. Convert Machine
  15. Select “This local Machine”
  16. Note that “View source details…” lights up. Click it
  17. Ensure that a Source disk is listed (if you didn’t change the controller driver then none will be listed and it will error when you attempt to convert)
  18. Type in the info for one of your VMWare hosts
  19. Select your datastore target
  20. Change RAM, CPU, etc as fit
  21. Finish and wait
  22. Once it’s completed shutdown the VM in XenServer
  23. In the VMWare console edit the VM.
  24. Delete the CDROM and Hard Disk
  25. Add a new Hard Disk as the SCSI 0:0 and point to the VMDK
  26. Add new CDROM with basic settings
  27. Start the machine and install tools
  28. Note that the VM Version is listed as 4
    1. Shutdown the VM
    2. Right click the VM and choose the option for “Upgrade Virtual Hardware”
    3. It should now show as a vmx-09
  29. Change the nic to vmxnet3 if desired
  30. Boot and change IP address if needed
  31. Uninstall VMWare converter

Since typing the Windows 2008 section, I tried something new that worked amazingly well with little downtime.  I did this with Windows 2008 RTM x32 and Windows 2008 R2 successfully.

  1. Download and install VMWare Converter 4.3.  New version may work better.
  2. Open VM Converter
  3. Convert Machine
  4. Select “This local Machine”
  5. Type in the info for one of your VMWare hosts
  6. Select your datastore target
  7. I had to edit the devices and change the controller to IDE
  8. Finish and wait
  9. At this point it’s extermely important to remember that we don’t want both VM’s on at the same time.  BUT I wanted to ensure that my new VMWare VM would boot…
  10. Change Settings
    1. Change network to an isolated network off production.
  11. Delete the CDROM and Hard Disk
  12. Add a new Hard Disk as the SCSI 0:0 and point to VMDK
  13. Add new CDROM with basic settings
  14. Start the machine
  15. Uninstall XenServer Tools
  16. Reboot
  17. Install VMWare Tools
  18. Shutdown
  19. Note that the VM Version is listed as 4
    1. Shutdown the VM
    2. Right click the VM and choose the option for “Upgrade Virtual Hardware”
    3. It should now show as a vmx-09
  20. Boot the server and ensure it boots
  21. Shutdown VMWare VM
  22. Shutdown XenServer VM
  23. Edit VMWare VM and change NIC to production network
  24. Boot and change IP address if needed
  25. Uninstall VMWare converter

Windows 2008: May have to delete the NIC (which was listed as Flexible) and add a new one for E1000.

Check IntialKeyboardIndicators key which may get messed up.
This is found under KHEY_USERS.DefaultControl PanelKeyboard
It would be set to 21474836648 after conversion
Changing this back to 0 made it work as expected.

Migrating Xenserver 6.1 to Vmware 5.1

Now this is the story all about how
Our life got flipped, turned upside down
And we’d like to take a minute, so just sit right there
And we’ll tell you how all how we moved to VMWare.

In Xenserver Enterprise born and raised
In the server room where we spent most of our days
Chilling out, maxing, relaxing all cool
And all shooting all the servers into the pool
When a couple of updates, they were up to no good
Started making trouble in our neighbourhood
We had numerous crashes and the users got scared
So we said “We’re moving all the servers onto VMware”

We asked for advice and it became clear
VMware is the game that we should play here
If anything I could say that this software was rare
But I thought nah, forget it, let’s get on VMware!

We started moving servers about seven or eight
And couple of days later we were almost straight
Looked at our kingdom we were finally there
Sitting all our servers on Vmware!

The real story of how and why we moved is slightly more complex.

We originally made the decision to invest in Xenserver in 2009 and by the end of that year had bought Xenserver Enterprise, 2 Dell R710 servers, a Dell AX4-5 SAN and also a QLogic 5602 fibre switch. We then had to wait for Xenserver 5.5 Update 2 to allow us to use our hardware. (Yeah I know we should have spent more time with the HCL.)

Well after waiting we soon had Xenserver up and running and over the next couple of month moved most of our infrastructure in Xen using the Xen convert tool. Things worked well and we had very little trouble. Towards the end of 2010 we put the 5.6 update on. Still no problems.

We then had a spate of issues with the hardware server mysteriously rebooting which we thought we nailed down to a faulty memory module and or a need hotfix. No big issue, we simply bought a new set of memory and applied the hotfixes. We then went and added a new HP P2000 SAN due to needing more storage. Again all was good. Update to Xenserver 6. Still all is good with the (virtual) world.

Fast forward to Feb 2013. Our virtual infrastructure needed expanding so we went and bought a spanking new HP DL380 hooked it into the infrastructure and then disappointment. We need the 6.1 update to add in our new server to the farm. No problem we think. One evening, shutdown the VMs, do a rolling upgrade, power up the VMs. 2-3 Hours work and then home.

Little did we know.

At first everything seemed to go well. The update went onto the server and the VM’s booted back up. The overall update time was about 5 Hours due to a small issue with a couple of VMs not wanting to power up. No biggy this kind of thing has happened before I know the fix.

However this was just the opening salvo in what would become a 2 week campaign of intimidation and fear from Xenserver. During the next 2 weeks I tried updating the Xen Tools on each VM (where it would let me), removing Xentools (again if it would let me), applying hotfixes to Xenserver. And throughout this VMs would hang, I would have to kill VMs and go through the destroy domain procedure, I would have to recover VM’s from snapshots, I would have to detach the VHDs rescan the SR and re-attach the VHD to recover the VM. The list of problems seemed endless.

After much research, reading of forums and speaking to people the only real solution seemed to be a move away from Xenserver. The question of which hypervisor to use was in no doubt – VMWare.

We went for VMware essentials as we couldn’t see us using more than 3 physical servers. Alongside this we decided to go with Veeam as our backup/DR solution.

So how did we do it.

We started off by trimming down the number of virtual boxes in our Xen environment so that they would run on just 2 older (Dell R710) physical servers. Then we took a server (HP DL380) that had been slated for Exchange (but not implemented) and upped its memory and rebuilt the RAID array. We then created our VMWare infrastructure using the 2 new HP DL 380s. This was nice and easy and didn’t cause any issues. Then came the most important part – moving the VMs.

This, as is turned out, was nice and straight forward. We just used the VMware converter and treated the Xen VMs as though they were physical boxes putting them onto the RAID array of one of the servers. Once we had converted about half the VMs we started on moving the remaining VHDs onto a single SAN (The older smaller Dell AX4-5).

Then came the fun. We removed the HP SAN from the Xenpool, reconfigured the zoning on the switch and then we reconfigured the P2000 from a 3.6 Tb RAID 10 to a 5.4 Tb RAID 5 config. There was a small issue installing the FC card and attaching the HBA in VMWare but a quick search online and a small update/hack later it was attached. We then moved all the VMDKs from the server to the SAN.

We moved the remaining VMs to the VMware infrastructure but left 1 of the Xenservers running because we had a completely screwed up Linux install that was happily running a webserver. We moved the last VHD to the local storage on the Xenserver and promptly put the whole nightmare out of our heads.

As for VMware – well what can I say 2 weeks later and everything is still running smoothly. We have Veeam doing a nightly back to a local server, our users aren’t complaining. The final stage of the move will involve removing the final Xenserver and then add the Dell into the mix. We will then use the AX4-5 as an offsite replica for Veeam to copy the essential VMs every night.

Bye bye Citrix XenServer

http://www.vmguru.com/2013/10/bye-bye-citrix-xenserver/

As we are in the week of the obituaries, let’s do another one. A few weeks ago when vSphere 5.5 was release I updated our Enterprise Hypervisor Comparison. As Citrix and Red Hat both had released a new version of their hypervisor product I also added those. Normally I only need to check for new features added or product limits which have been upgraded. But this time was different!

In the column with the new Citrix XenServer 6.2 I had to remove feature which were previously included in the product. WTF?

I rarely come across any XenServer deployments and when I speak to colleagues, customers, etc. I often hear Citrix XenServer is dead. Based on the number of XenServer deployments I see and the number of customers changing to Hyper-V or vSphere this seems to support this theory. Instead of adding new features and upgrading product limits, I had to retire numerous features.

Features retired in XenServer 6.2:

  • Workload Balancing and associated functionality (e.g. power-consumption based consolidation);
  • XenServer plug-in for Microsoft’s System Center Operations Manager;
  • Virtual Machine Protection and Recovery (VMPR);
  • Web Self Service;
  • XenConvert (P2V).


Features with no further development and removal in future releases:

  • Microsoft System Center Virtual Machine Manager (SCVMM) support;
  • Integrated StorageLink (iSL);
  • Distributed Virtual Switch (vSwitch) Controller (DVSC). The Open vSwitch remains fully supported and developed.

It has never been a secret that Microsoft and Citrix joined forces but as expected Citrix XenServer had no place there as Microsoft invested big on Hyper-V. But now it seems that Citrix has killed XenServer. With version 6.2 they moved XenServer to a fully open source model essentially giving it back to the community. Of course much of XenServer already was open source, using code from the Xen Project, Linux kernel and the Cloud Platform (XCP) initiative. But with the retirement of many existing features it seems that Citrix is stripping XenServer from all Citrix add-ons before giving the basic core back to the open source community.

Citrix still delivers a supported commercial distribution of XenServer but when an identical free version is available …… At the feature and functionality level, the only difference is that the free version of  XenServer will not be able to use XenCenter for automated installation of security fixes, updates and maintenance releases. Free Citrix XenServer does include XenCenter for server management, but not patch management. I doubt many customers will buy a version of XenServer for patch management alone.

It’s interesting to see Gartner has moved Citrix outside the leaders Quadrant and placed it in the visionaries Quadrant. Visionaries in the x86 server virtualization infrastructure market have a differentiated approach or product, but they aren’t meeting their potential from an execution standpoint.

Magic Quadrant for x86 Server Virtualization Infrastructure 2012.PNGMagic Quadrant for x86 Server Virtualization Infrastructure 2013.PNG

So it looks like Citrix has given up on XenServer and is going to focus on their core business, the desktop and the ecosystem of products around it.

Within their partnership with Microsoft they cannot or may not compete with Hyper-V although XenServer has,in the past, always been a better product than Hyper-V. With the battle on application delivery intensifying, their focus needs to be on their main portfolio. VMware is targeting Citrix’s application delivery platform with VMware Horizon Workspace and on the desktop front Citrix faces two enemies. Where Microsoft Remote Desktop Services is targeting their Server BAsed Computing/XenApp platform and VMware Horizon View is battling Citrix XenDesktop.

I wonder when we will hear that Citrix finally killed XenServer …..

How To Convert A Xen Virtual Machine To VMware

https://www.howtoforge.com/how-to-convert-a-xen-virtual-machine-to-vmware

This article explains how you can convert a Xen guest to a VMware guest. The steps descibed here assume advanced VMware and Xen knowledge.

Additional software requirements:

  • qemu
  • VMware Server 1.xx
  • VMware Converter
  • Knoppix LiveCD or the distribution’s first CD

Xen -> VMware VM Migration Steps (Kernel Step)

The kernel on the VM to be migrated must support fully virtualized operation. The kernels used for para-virtulized machines using RHEL/Fedora/CentOS as a guest do not support fully virtualized operation by default. The best way to deal with this is to also install a standard kernel in the machine, port the machine and finally remove the Xen kernel.

1. Since this is a highly risky procedure, FIRST CREATE A BACK-UP OF YOUR VIRTUAL MACHINE!!!

2. Download a kernel with the same version number and architecture as the Xen kernel, except it should be the a generic one. Use the distribution CD/DVD or any other repository to get it.

3. Use RPM tools to install the kernel.

4. Modify /etc/modprobe.conf to add the proper SCSI and network card modules:

alias eth0 xennet
alias scsi_hostadapter xenblk

will be replaced by

alias eth0 pcnet32
alias scsi_hostadapter mptbase
alias scsi_hostadapter1 mptspi
alias scsi_hostadapter2 ata_piix

Modify /etc/inittab by removing the # in front of the getty and puting a comment in front of the line containg the xen console:

1:2345:respawn:/sbin/mingetty --noclear tty1
2:2345:respawn:/sbin/mingetty
3:2345:respawn:/sbin/mingetty
4:2345:respawn:/sbin/mingetty
5:2345:respawn:/sbin/mingetty
6:2345:respawn:/sbin/mingetty

This is a one way action. Once modified the kernel modules, you won’tbe able to properly start the machine, and you will receive a Kernel panic error message.

Xen – > VMware VM Migration Steps (Disk Step)

To convert a XEN machine in a .vmdk format to be used with VMware, a tool called qemu will be used. QEMU is a generic and open source machine emulator and virtualizer. It is also a fast processor emulator using dynamic translation to achieve good emulation speed.

1. Download qemu from DAG repository. Use the EL5 package for any Fedora/RHEL5/CentOS5 that you use.

http://dag.wieers.com/rpm/packages/qemu/

2. Convert the XEN machine to VMware:

qemu-img convert <source_xen_machine> -O vmdk <destination_vmware.vmdk>

3. At this point, we have a valid VMware Server 1.xx disk image. This can be powered on onto any VMware Server. We need to do it anyway in order to build a .VMX file that will be later used. This stage also confirms whether the newly machine runs properly.

3.1 Create a new virtual machine. Do not create a new HDD, but use the previously created vmdk.

3.2 Power it on in order to validate that it is usable and to allow the machine to reconfigure itself.

4. Move the VMware Server virtual machine to a Windows workstation running VMwareConverter.

5. Using VMware Converter, convert the VMware Server virtual machine to VMware ESXi.

Xen -> VMware VM Migration Steps (ESX Step)

1. Configure the virtual machine to boot first from CD-ROM drive.

2. Modify the machine’s HDD SCSI controller type from BUS Logic to LSI Logic.

Edit Virtual Machine Settings > SCSI Controller 0 > Change type > LSI Logic.

3. Boot using Knoppix or the distribution’s first CD.

4. Mount the VM’s disk and chroot to it.

5. Get the disk architecture using fdisk -l, and modify /etc/fstab accordingly.

6. Create a new initrd image. You also must know the version of the running kernel. For example, if you are running kernel 2.6.18-1234, then the initrd command would look like this:

# mkinitrd -v -f /boot/initrd-2.6.18-1234.img 2.6.18-1234

7. Edit /boot/grub/menu.lst to boot from this initrd.

8. Keep your fingers crossed and reboot the machine.

Don’t forget to re-configure your network card.

External references:

http://communities.vmware.com/docs/DOC-8300

Expert-Exchange

xen isn’t one of the platforms directly targeted as a source image by converter, but you can use it to bring in the VM’s like they were running on a physical computer.  You will probably want to uninstall any Xen tools before beginning the conversion process so they don’t interfere when you boot the VM’s up the first time.

Converter converts LVM volumes to EXT3 partitions unless you use the cold cloning method, too.  vCenter Converter converting a Linux operating system does not maintain LVMs on the resulting virtual machine (http://kb.vmware.com/kb/1019398)

Citrix Migration XenAPP 6.0 to XenDesktop 7.6 / Upgrade a deployment

Migrate XenApp 6.x

Updated: 2014-12-04

Important: Review this entire article before beginning a migration.

The XenApp 6.x Migration Tool (the migration tool) is a collection of PowerShell scripts containing cmdlets that migrate XenApp 6.x (6.0 or 6.5) policy and farm data. On the XenApp 6.x controller server, you run export cmdlets that gather that data into XML files. Then, from the XenApp 7.6 Controller, you run import cmdlets that create objects using the data gathered during the export.

The following sequence summarizes the migration process; details are provided later.

  1. On a XenApp 6.0 or 6.5 controller:
    1. Import the PowerShell export modules.
    2. Run the export cmdlets to export policy and/or farm data to XML files.
  2. Copy the XML files (and icons folder if you chose not to embed them in the XML files during the export) to the XenApp 7.6 Controller.
  3. On the XenApp 7.6 Controller:
    1. Import the PowerShell import modules.
    2. Run the import cmdlets to import policy and/or farm data (applications), using the XML files as input.
  4. Complete post-migration steps.

Before you run an actual migration, you can export your XenApp 6.x settings and then perform a preview import on the XenApp 7.6 site. The preview identifies possible failure points so you can resolve issues before running the actual import. For example, a preview might detect that an application with the same name already exists in the new XenApp 7.6 site. You can also use the log files generated from the preview as a migration guide.

Unless otherwise noted, the term 6.x refers to XenApp 6.0 or 6.5.

New in this release

This December 2014 release (version 20141125) contains the following updates:

  • Exporting applications and policies from a XenApp 6.0 farm has been introduced as an experimental feature. If you encounter issues using the migration tool on a XenApp 6.0 farm, report them to the support forumhttp://discussions.citrix.com/forum/1411-xenapp-7x/, so that Citrix can investigate them for potential improvements to the tool.
  • New packaging – the XAMigration.zip file now contains two separate, independent packages: ReadIMA.zip and ImportFMA.zip. To export from a XenApp 6.x server, you need only ReadIMA.zip. To import to a XenApp 7.6 server, you need only ImportFMA.zip.
  • The Export-XAFarm cmdlet supports a new parameter (EmbedIconData) that eliminates the need to copy icon data to separate files.
  • The Import-XAFarm cmdlet supports three new parameters:
    • MatchServer – import applications from servers whose names match an expression
    • NotMatchServer – import applications from servers whose names do not match an expression
    • IncludeDisabledApps – import disabled applications
  • Prelaunched applications are not imported.
  • The Export-Policy cmdlet works on XenDesktop 7.x.

A video overview of the migration tool is available here.

Migration Tool package

The migration tool is available from a Citrix download site. The XAMigration.zip file contains two separate, independent packages:

  • ReadIMA.zip – contains the files used to export data from your XenApp 6.x farm, plus shared modules.
    Module or file Description
    ExportPolicy.psm1 PowerShell script module for exporting XenApp 6.x policies to an XML file.
    ExportXAFarm.psm1 PowerShell script module for exporting XenApp 6.x farm settings to an XML file.
    ExportPolicy.psd1 PowerShell manifest file for script module ExportPolicy.psm1.
    ExportXAFarm.psd1 PowerShell manifest file for script module ExportXAFarm.psm1.
    LogUtilities.psm1 Shared PowerShell script module that contains logging functions.
    XmlUtilities.psd1 PowerShell manifest file for script module XmlUtilities.psm1.
    XmlUtilities.psm1 Shared PowerShell script module that contains XML functions.
  • ImportFMA.zip – contains the files used to import data to your XenApp 7.6 farm, plus shared modules.
    Module or file Description
    ImportPolicy.psm1 PowerShell script module for importing policies to XenApp 7.6.
    ImportXAFarm.psm1 PowerShell script module for importing applications to XenApp 7.6
    ImportPolicy.psd1 PowerShell manifest file for script module ImportPolicy.psm1.
    ImportXAFarm.psd1 PowerShell manifest file for script module ImportXAFarm.psm1.
    PolicyData.xsd XML schema for policy data.
    XAFarmData.xsd XML schema for XenApp farm data.
    LogUtilities.psm1 Shared PowerShell script module that contains logging functions.
    XmlUtilities.psd1 PowerShell manifest file for script module XmlUtilities.psm1.
    XmlUtilities.psm1 Shared PowerShell script module that contains XML functions.

Limitations

  • Not all policies settings are imported; see Policy settings not imported. Settings that are not supported are ignored and noted in the log file.
  • While all application details are collected in the output XML file during the export operation, only server-installed applications are imported into the XenApp 7.6 site. Published desktops, content, and most streamed applications are not supported (see the Import-XAFarm cmdlet parameters in Step-by-step: import data for exceptions).
  • Application servers are not imported.
  • Many application properties are not imported because of differences between the XenApp 6.x Independent Management Architecture (IMA) and the XenApp 7.6 FlexCast Management Architecture (FMA) technologies; see Application property mapping.
  • A Delivery Group is created during the import. See Advanced use for details about using parameters to filter what is imported.
  • Only Citrix policy settings created with the AppCenter management console are imported; Citrix policy settings created with Windows Group Policy Objects (GPOs) are not imported.
  • The migration scripts are intended for migrations from XenApp 6.x to XenApp 7.6 only.

Security considerations

The XML files created by the export scripts can contain sensitive information about your environment and organization, such as user names, server names, and other XenApp farm, application, and policy configuration data. Store and handle these files in secure environments.

Carefully review the XML files before using them as input when importing policies and applications, to ensure they contain no unauthorized modifications.

Policy object assignments (previously known as policy filters) control how policies are applied. After importing the policies, carefully review the object assignments for each policy to ensure that there are no security vulnerabilities resulting from the import. Different sets of users, IP addresses, or client names may be applied to the policy after the import. The allow/deny settings may have different meanings after the import.

Logging and error handling

The scripts provide extensive logging that tracks all cmdlet executions, informative messages, cmdlet execution results, warnings, and errors.

  • Most Citrix PowerShell cmdlet use is logged. All PowerShell cmdlets in the import scripts that create new site objects are logged.
  • Script execution progress is logged, including the objects being processed.
  • Major actions that affect the state of the flow are logged, including flows directed from the command line.
  • All messages printed to the console are logged, including warnings and errors.
  • Each line is time-stamped to the millisecond.

Citrix recommends specifying a log file when you run each of the export and import cmdlets.

If you do not specify a log file name, the log file is stored in the current user’s home folder (specified in the PowerShell $HOME variable) if that folder exists; otherwise, it is placed in the script’s current execution folder. The default log name is “XFarmYYYYMMDDHHmmSS-xxxxxx” where the last six digits constitute a random number.

By default, all progress information is displayed. To suppress the display, specify the NoDetails parameter in the export and import cmdlet.

Generally, a script stops execution when an error is encountered, and you can run the cmdlet again after clearing the error conditions.

Conditions that are not considered errors are logged; many are reported as warnings, and script execution continues. For example, unsupported application types are reported as warnings and are not imported. Applications that already exist in the XenApp 7.6 site are not imported. Policy settings that are deprecated in XenApp 7.6 are not imported.

The migration scripts use many PowerShell cmdlets, and all possible errors might not be logged. For additional logging coverage, use the PowerShell logging features. For example, PowerShell transcripts log everything that is printed to the screen. For more information, see the help for the Start-Transcript and Stop-Transcript cmdlets.

Requirements, preparation, and best practices

Important: Remember to review this entire article before beginning a migration.
You should understand basic PowerShell concepts about execution policy, modules, cmdlets, and scripts. Although extensive scripting expertise is not required, you should understand the cmdlets you execute. Use the Get-Help cmdlet to review each migration cmdlet’s help before executing it. For example:

Get-Help -full Import-XAFarm

Specify a log file on the command line and always review the log file after running a cmdlet. If a script fails, check and fix the error identified in the log file and then run the cmdlet again.

Good to know:

  • To facilitate application delivery while two deployments are running (the XenApp 6.x farm and the new XenApp 7.6 site), you can aggregate both deployments in StoreFront or Web Interface. See the eDocs documentation for your StoreFront or Web Interface release (Manage > Create a store).
  • Application icon data is handled in one of two ways:
    • If you specify the EmbedIconData parameter in the Export-XAFarm cmdlet, exported application icon data is embedded in the output XML file.
    • If you do not specify the EmbedIconData parameter in the Export-XAFarm cmdlet, exported application icon data is stored under a folder named by appending the string “-icons” to the base name of the output XML file. For example, if the XmlOutputFile parameter is “FarmData.xml” then the folder “FarmData-icons” is created to store the application icons.

      The icon data files in this folder are .txt files that are named using the browser name of the published application (although the files are .txt files, the stored data is encoded binary icon data, which can be read by the import script to re-create the application icon). During the import operation, if the icon folder is not found in the same location as the import XML file, generic icons are used for each imported application.

  • The names of the script modules, manifest files, shared module, and cmdlets are similar. Use tab completion with care to avoid errors. For example, Export-XAFarm is a cmdlet. ExportXAFarm.psd1 and ExportXAFarm.psm1 are files that cannot be executed.
  • In the step-by-step sections below, most <string> parameter values show surrounding quotation marks. These are optional for single-word strings.
For exporting from the XenApp 6.x server:

  • The export must be run on a XenApp 6.x server configured with the controller and session-host (commonly known as controller) server mode.
  • To run the export cmdlets, you must be a XenApp administrator with permission to read objects. You must also have sufficient Windows permission to run PowerShell scripts; the step-by-step procedures below contain instructions.
  • Ensure the XenApp 6.x farm is in a healthy state before beginning an export. Back up the farm database. Verify the farm’s integrity using the Citrix IMA Helper utility (CTX133983): from the IMA Datastore tab, run a Master Check (and then use the DSCheck option to resolve invalid entries). Repairing issues before the migration helps prevent export failures. For example, if a server was removed improperly from the farm, its data might remain in the database; that could cause cmdlets in the export script to fail (for example, Get-XAServer -ZoneName). If the cmdlets fail, the script fails.
  • You can run the export cmdlets on a live farm that has active user connections; the export scripts read only the static farm configuration and policy data.
For importing to the XenApp 7.6 server:

  • You can import data to XenApp 7.6 deployments (and later supported versions). You must install a XenApp 7.6 Controller and Studio, and create a site before importing the data you exported from the XenApp 6.x farm. Although VDAs are not required to import settings, they allow application file types to be made available.
  • To run the import cmdlets, you must be a XenApp administrator with permission to read and create objects. A Full Administrator has these permissions. You must also have sufficient Windows permission to run PowerShell scripts; the step-by-step procedures below contain instructions.
  • No other user connections should be active during an import. The import scripts create many new objects, and disruptions may occur if other users are changing the configuration at the same time.

Remember that you can export data and then use the -Preview parameter with the import cmdlets to see what would happen during an actual import, but without actually importing anything. The logs will indicate exactly what would happen during an actual import; if errors occur, you can resolve them before starting an actual import.

Step-by-step: export data

A video of an export walk-through is available here.

Complete the following steps to export data from a XenApp 6.x controller to XML files.

  1. Download the XAMigration.zip migration tool package from the Citrix download site. For convenience, place it on a network file share that can be accessed by both the XenApp 6.x farm and the XenApp 7.6 site. Unzip XAMigration.zip on the network file share. There should be two zip files: ReadIMA.zip and ImportFMA.zip.
  2. Log on to the XenApp 6.x controller as a XenApp administrator with at least read-only permission and Windows permission to run PowerShell scripts.
  3. Copy ReadIMA.zip from the network file share to the XenApp 6.x controller. Unzip and extract ReadIMA.zip on the controller to a folder (for example: C:XAMigration).
  4. Open a PowerShell console and set the current directory to the script location. For example:
    cd C:XAMigration
  5. Check the script execution policy by running Get-ExecutionPolicy.
  6. Set the script execution policy to at least RemoteSigned to allow the scripts to be executed. For example:
    Set-ExecutionPolicy RemoteSigned
  7. Import the module definition files ExportPolicy.psd1 and ExportXAFarm.psd1:

    Import-Module .ExportPolicy.psd1

    Import-Module .ExportXAFarm.psd1

    Good to know:

    • If you intend to export only policy data, you can import only the ExportPolicy.psd1 module definition file. Similarly, if you intend to export only farm data, import only ExportXAFarm.psd1.
    • Importing the module definition files also adds the required PowerShell snap-ins.
    • Do not import the .psm1 script files.
  8. To export policy data, run the Export-Policy cmdlet.
    Parameter Description

    -XmlOutputFile “<string>.xml”

    XML output file name; this file will hold the exported data. Must have an .xml extension. The file must not exist, but if a path is specified, the parent path must exist.

    Default: None; this parameter is required.

    -LogFile “<string>”

    Log file name. An extension is optional. The file is created if it does not exist. If the file exists and the NoClobber parameter is also specified, an error is generated; otherwise, the file’s content is overwritten.

    Default: See Logging and error handling

    -NoLog

    Do not generate log output. This overrides the LogFile parameter if it is also specified.

    Default: False; log output is generated

    -NoClobber

    Do not overwrite an existing log file specified in the LogFile parameter. If the log file does not exist, this parameter has no effect.

    Default: False; an existing log file is overwritten

    -NoDetails

    Do not send detailed reports about script execution to the console.

    Default: False; detailed reports are sent to the console

    -SuppressLogo

    Do not print the message “XenApp 6.x to XenApp/XenDesktop 7.6 Migration Tool Version #yyyyMMdd-hhmm#” to the console. This message, which identifies the script version, can be helpful during troubleshooting; therefore, Citrix recommends omitting this parameter.

    Default: False; the message is printed to the console

    Example: The following cmdlet exports policy information to the XML file named MyPolicies.xml. The operation is logged to the file named MyPolicies.log.

    Export-Policy -XmlOutputFile ".MyPolicies.XML" 
    -LogFile ".MyPolicies.Log"
  9. To export farm data, run the Export-XAFarm cmdlet, specifying a log file and an XML file.
    Parameter Description

    -XmlOutputFile “<string>.xml”

    XML output file name; this file will hold the exported data. Must have an .xml extension. The file must not exist, but if a path is specified, the parent path must exist.

    Default: None; this parameter is required.

    -LogFile “<string>”

    Log file name. An extension is optional. The file is created if it does not exist. If the file exists and the NoClobber parameter is also specified, an error is generated; otherwise, the file’s content is overwritten.

    Default: See Logging and error handling

    -NoLog

    Do not generate log output. This overrides the LogFile parameter if it is also specified.

    Default: False; log output is generated

    -NoClobber

    Do not overwrite an existing log file specified in the LogFile parameter. If the log file does not exist, this parameter has no effect.

    Default: False; an existing log file is overwritten

    -NoDetails

    Do not send detailed reports about script execution to the console.

    Default: False; detailed reports are sent to the console

    -SuppressLogo

    Do not print the message “XenApp 6.x to XenApp/XenDesktop 7.6 Migration Tool Version #yyyyMMdd-hhmm#” to the console. This message, which identifies the script version, can be helpful during troubleshooting; therefore, Citrix recommends omitting this parameter.

    Default: False; the message is printed to the console

    -IgnoreAdmins

    Do not export administrator information. See Advanced use for how-to-use information.

    Default: False; administrator information is exported

    -IgnoreApps

    Do not export application information. See Advanced use for how-to-use information.

    Default: False; application information is exported

    -IgnoreServers

    Do not export server information.

    Default: False: server information is exported

    -IgnoreZones

    Do not export zone information.

    Default: False; zone information is exported.

    -IgnoreOthers

    Do not export information such as configuration logging, load evaluators, load balancing policies, printer drivers, and worker groups.

    Default: False; other information is exported

    -AppLimit <integer>

    Number of applications to be exported. See Advanced use for how-to-use information.

    Default: All applications are exported

    -EmbedIconData

    Embed application icon data in the same XML file as the other objects.

    Default: Icons are stored separately. See Requirements, preparation, and best practices for details

    -SkipApps <integer>

    Number of applications to skip. See Advanced use for how-to-use information.

    Default: No applications are skipped

    Example: The following cmdlet exports farm information to the XML file named MyFarm.xml. The operation is logged to the file MyFarm.log. A folder named “MyFarm-icons” is created to store the application icon data files; this folder is at the same location as MyFarm.XML.

    Export-XAFarm -XmlOutputFile ".MyFarm.XML" 
    -LogFile	".MyFarm.Log"
    

After the export scripts complete, the XML files specified on the command lines contain the policy and XenApp farm data. The application icon files contain icon data files, and the log file indicate what occurred during the export.

Step-by-step: import data

A video of an import walk-through is available here.

Remember that you can run a preview import (by issuing the Import-Policy or Import-XAFarm cmdlet with the Preview parameter) and review the log files before performing an actual import.

Complete the following steps to import data to a XenApp 7.6 site, using the XML files generating from the export.

  1. Log on to the XenApp 7.6 controller as an administrator with read-write permission and Windows permission to run PowerShell scripts.
  2. If you have not unzipped the migration tool package XAMigration on the network file share, do so now. Copy ImportFMA.zip from the network file share to the XenApp 7.6 Controller. Unzip and extract ImportFMA.zip on the Controller to a folder (for example: C:XAMigration).
  3. Copy the XML files (the output files generated during the export) from the XenApp 6.x controller to the same location on the XenApp 7.6 Controller where you extracted the ImportFMA.zip files.

    If you chose not to embed the application icon data in the XML output file when you ran the Export-XAFarm cmdlet, be sure to copy the icon data folder and files to the same location on the XenApp 7.6 controller as the output XML file containing the application data and the extracted ImportFMA.zip files.

  4. Open a PowerShell console and set the current directory to the script location.
    cd C:XAMigration
  5. Check the script execution policy by running Get-ExecutionPolicy.
  6. Set the script execution policy to at least RemoteSigned to allow the scripts to be executed. For example:
    Set-ExecutionPolicy RemoteSigned
  7. Import the PowerShell module definition files ImportPolicy.psd1 and ImportXAFarm.psd1:

    Import-Module .ImportPolicy.psd1

    Import-Module .ImportXAFarm.psd1

    Good to know:

    • If you intend to import only policy data, you can import only the ImportPolicy.psd1 module definition file. Similarly, if you intend to import only farm data, import only ImportXAFarm.psd1.
    • Importing the module definition files also adds the required PowerShell snap-ins.
    • Do not import the .psm1 script files.
  8. To import policy data, run the Import-Policy cmdlet, specifying the XML file containing the exported policy data.
    Parameter Description

    -XmlInputFile “<string>.xml”

    XML input file name; this file contains data collected from running the Export-Policy cmdlet. Must have an .xml extension.

    Default: None; this parameter is required.

    -XsdFile “<string>”

    XSD file name. The import scripts use this file to validate the syntax of the XML input file. See Advanced use for how-to-use information.

    Default: PolicyData.XSD

    -LogFile “<string>”

    Log file name. If you copied the export log files to this server, consider using a different log file name with the import cmdlet.

    Default: See Logging and error handling

    -NoLog

    Do not generate log output. This overrides the LogFile parameter, if it is also specified.

    Default: False; log output is generated

    -NoClobber

    Do not overwrite an existing log file specified in the LogFile parameter. If the log file does not exist, this parameter has no effect.

    Default: False; an existing log file is overwritten

    -NoDetails

    Do not send detailed reports about script execution to the console.

    Default: False; detailed reports are sent to the console

    -SuppressLogo

    Do not print the message “XenApp 6.x to XenApp/XenDesktop 7.6 Migration Tool Version #yyyyMMdd-hhmm#” to the console. This message, which identifies the script version, can be helpful during troubleshooting; therefore, Citrix recommends omitting this parameter.

    Default: False; the message is printed to the console

    -Preview

    Perform a preview import: read data from the XML input file, but do not import objects to the site. The log file and console indicate what occurred during the preview import. A preview shows administrators what would happen during a real import.

    Default: False; a real import occurs

    Example: The folowing cmdlet imports policy data from the XML file named MyPolcies.xml. The operation is logged to the file named MyPolicies.log.

    Import-Policy -XmlInputFile ".MyPolicies.XML" 
    -LogFile ".MyPolicies.Log"
  9. To import applications, run the Import-XAFarm cmdlet, specifying a log file and the XML file containing the exported farm data.
    Parameter Description

    -XmlInputFile “<string>.xml”

    XML input file name; this file contains data collected from running the Export-XAFarm cmdlet. Must have an .xml extension.

    Default: None; this parameter is required.

    -XsdFile “<string>”

    XSD file name. The import scripts use this file to validate the syntax of the XML input file. See Advanced use for how-to-use information.

    Default: XAFarmData.XSD

    -LogFile “<string>”

    Log file name. If you copied the export log files to this server, consider using a different log file name with the import cmdlet.

    Default: See Logging and error handling

    -NoLog

    Do not generate log output. This overrides the LogFile parameter, if it is also specified.

    Default: False; log output is generated

    -NoClobber

    Do not overwrite an existing log file specified in the LogFile parameter. If the log file does not exist, this parameter has no effect.

    Default: False; an existing log file is overwritten

    -NoDetails

    Do not send detailed reports about script execution to the console.

    Default: False; detailed reports are sent to the console

    -SuppressLogo

    Do not print the message “XenApp 6.x to XenApp/XenDesktop 7.6 Migration Tool Version #yyyyMMdd-hhmm#” to the console. This message, which identifies the script version, can be helpful during troubleshooting; therefore, Citrix recommends omitting this parameter.

    Default: False; the message is printed to the console

    -Preview

    Perform a preview import: read data from the XML input file, but do not import objects to the site. The log file and console indicate what occurred during the preview import. A preview shows administrators what would happen during a real import.

    Default: False; a real import occurs

    -DeliveryGroupName “<string>”

    Delivery Group name for all imported applications. See Advanced use for how-to-use information.

    Default: “<xenapp-farm-name> – Delivery Group”

    -MatchFolder “<string>”

    Import only those applications in folders with names that match the string. See Advanced use for how-to-use information.

    Default: No matching occurs

    -NotMatchFolder “<string>”

    Import only those applications in folders with names that do not match the string. See Advanced use for how-to-use information.

    Default: No matching occurs

    -MatchServer “<string>”

    Import only those applications from servers whose names match the string. See Advanced use for how-to-use information.

    -NotMatchServer “<string>”

    Import only those applications from servers whose names do not match the string. See Advanced use for how-to-use information.

    Default: No matching occurs

    -MatchWorkerGroup “<string>”

    Import only those applications published to worker groups with names that match the string. See Advanced use for how-to-use information.

    Default: No matching occurs

    -NotMatchWorkerGroup “<string>”

    Import only those applications published to worker groups with names that do not match the string. See Advanced use for how-to-use information.

    Default: No matching occurs

    -MatchAccount “<string>”

    Import only those applications published to user accounts with names that match the string. See Advanced use for how-to-use information.

    Default: No matching occurs

    -NotMatchAccount “<string>”

    Import only those applications published to user accounts with names that do not match the string. See Advanced use for how-to-use information.

    Default: No matching occurs

    -IncludeStreamedApps

    Import applications of type “StreamedToClientOrServerInstalled” . (No other streamed applications are imported.)

    Default: Streamed applications are not imported

    -IncludeDisabledApps

    Import applications that have been marked as disabled.

    Default: Disabled applications are not imported

    Example: The following cmdlet imports applications from the XML file named MyFarm.xml. The operation is logged to the file named MyFarm.log.

    Import-XAFarm -XmlInputFile ".MyFarm.XML" 
    -LogFile ".MyFarm.Log"
    
  10. After the import completes successfully, complete the post-migration tasks.

Post-migration tasks

After successfully importing XenApp 6.x policies and farm settings into a XenApp 7.6 site, use the following guidance to ensure that the data has been imported correctly.

  • Policies and policy settings

    Importing policies is essentially a copy operation, with the exception of deprecated settings and policies, which are not imported. The post-migration check essentially involves comparing the two sides.

    1. The log file lists all the policies and settings imported and ignored. First, review the log file and identify which settings and policies were not imported.
    2. Compare the XenApp 6.x policies with the policies imported to XenApp 7.6. The values of the settings should remain the same (except for deprecated policy settings, as noted in the next step).
      • If you have a small number of policies, you can perform a side-by-side visual comparison of the policies displayed in the XenApp 6.x AppCenter and the policies displayed in the XenApp 7.6 Studio.
      • If you have a large number of policies, a visual comparison might not be feasible. In such cases, use the policy export cmdlet (Export-Policy) to export the XenApp 7.6 policies to a different XML file, and then use a text diff tool (such as windiff) to compare that file’s data to the data in the XML file used during the policy export from XenApp 6.x.
    3. Use the information in the Policy settings not imported section to determine what might have changed during the import. If a XenApp 6.x policy contains only deprecated settings, as a whole policy, it is not imported. For example, if a XenApp 6.x policy contains only HMR test settings, that policy is completely ignored because there is no equivalent setting supported in XenApp 7.6.

      Some XenApp 6.x policy settings are no longer supported, but the equivalent functionality is implemented in XenApp 7.6. For example, in XenApp 7.6, you can configure a restart schedule for Server OS machines by editing a Delivery Group; this functionality was previously implemented through policy settings.

    4. Review and confirm how filters will apply to your XenApp 7.6 site versus their use in XenApp 6.x; significant differences between the XenApp 6.x farm and the XenApp 7.6 site could change the effect of filters.
  • Filters
    Carefully examine the filters for each policy. Changes may be required to ensure they still work in XenApp 7.6 as originally intended in XenApp 6.x.

    Filter

    Considerations

    Access Control

    Access Control Should contain the same values as the original XenApp 6.x filters and should work without requiring changes.

    Citrix CloudBridge

    A simple Boolean; should work without requiring changes.

    Client IP Address

    Lists client IP address ranges; each range is either allowed or denied. The import script preserves the values, but they may require changes if different clients connect to the XenApp 7.6 VDA machines.

    Client Name

    Similar to the Client IP Address filter, the import script preserves the values, but they may require changes if different clients connect to the XenApp 7.6 VDA machines.

    Organizational Unit

    Values might be preserved, depending on whether or not the OUs can be resolved at the time they are imported. Review this filter closely, particularly if the XenApp 6.x and XenApp 7.6 machines reside in different domains. If you do not configure the filter values correctly, the policy may be applied to an incorrect set of OUs.

    The OUs are represented by names only, so there is a small chance that an OU name will be resolved to an OU containing different members from the OUs in the XenApp 6.x domain. Even if some of the values of the OU filter are preserved, you should carefully review the values.

    User or Group

    Values might be preserved, depending on whether or not the accounts can be resolved at the time they are imported.

    Similar to OUs, the accounts are resolved using names only, so if the XenApp 7.6 site has a domain with the same domain and user names, but are actually two different domains and users, the resolved accounts could be different from the XenApp 6.x domain users. If you do not properly review and modify the filter values, incorrect policy applications can occur.

    Worker Group

    Worker groups are not supported in XenApp 7.6. Consider using the Delivery Group, Delivery Group Type, and Tag filters, which are supported in XenApp 7.6 (not in XenApp 6.x).

    • Delivery Group: Allows policies to be applied based on Delivery Groups. Each filter entry specifies a Delivery Group and can be allowed or denied.
    • Delivery Group Type: Allows policies to be applied based on the Delivery Group types. Each filter specifies a Delivery Group type that can be allowed or denied.
    • Tag: Specifies policy application based on tags created for the VDA machines. Each tag can be allowed or denied.

    To recap, filters that involve domain user changes require the most attention if the XenApp 6.x farm and the XenApp 7.6 site are in different domains. Because the import script uses only strings of domain and user names to resolve users in the new domain, some of the accounts might be resolved and others might not. While there is only a small chance that different domains and users have the same name, you should carefully review these filters to ensure they contain correct values.

  • Applications
    The application importing scripts do not just import applications; they also create objects such as Delivery Groups. If the application import involves multiple iterations, the original application folder hierarchies can change significantly.

    1. First, read the migration log files that contain details about which applications were imported, which applications were ignored, and the cmdlets that were used to create the applications.
    2. For each application:
      • Visually check to ensure the basic properties were preserved during the import. Use the information in the Application property mapping section to determine which properties were imported without change, not imported, or initialized using the XenApp 6.x application data.
      • Check the user list. The import script automatically imports the explicit list of users into the application’s limit visibility list in XenApp 7.6. Check to ensure that the list remains the same.
    3. Application servers are not imported. This means that none of the imported applications can be accessed yet. The Delivery Groups that contain these applications must be assigned machine catalogs that contain the machines that have the published applications’ executable images. For each application:
      • Ensure that the executable name and the working directory point to an executable that exists in the machines assigned to the Delivery Group (through the machine catalogs).
      • Check a command line parameter (which may be anything, such as file name, environment variable, or executable name). Verify that the parameter is valid for all the machines in the machine catalogs assigned to the Delivery Group.
  • Log files

    The log files are the most important reference resources for an import and export. This is why existing log files are not overwritten by default, and default log file names are unique.

    As noted in the “Logging and error handling” section, if you chose to use additional logging coverage with the PowerShell Start-Transcript and Stop-Transcript cmdlets (which record everything typed and printed to the console), that output, together with the log file, provides a complete reference of import and export activity.

    Using the time stamps in the log files, you can diagnose certain problems. For example, if an export or import ran for a very long time, you could determine if a faulty database connection or resolving user accounts took most of the time.

    The commands recorded in the log files also tell you how some objects are read or created. For example, to create a Delivery Group, several commands are executed to not only create the Delivery Group object itself, but also other objects such as access policy rules that allow application objects to be assigned to the Delivery Group.

    The log file can also be used to diagnose a failed export or import. Typically, the last lines of the log file indicate what caused the failure; the failure error message is also saved in the log file. Together with the XML file, the log file can be used to determine which object was involved in the failure.

After reviewing and testing the migration, you can:

  1. Upgrade your XenApp 6.5 worker servers to current Virtual Delivery Agents (VDAs) by running the 7.6 installer on the server, which removes the XenApp 6.5 software and then automatically installs a current VDA. See Upgrade a XenApp 6.5 worker to a new VDA for Windows Server OS for instructions.

    For XenApp 6.0 worker servers, you must manually uninstall the XenApp 6.0 software from the server. You can then use the 7.6 installer to install the current VDA. You cannot use the 7.6 installer to automatically remove the XenApp 6.0 software.

  2. From Studio in the new XenApp site, create machine catalogs (or edit existing catalogs) for the upgraded workers.
  3. Add the upgraded machines from the machine catalog to the Delivery Groups that contain the applications installed on those VDAs for Windows Server OS.

Advanced use

By default, the Export-Policy cmdlet exports all policy data to an XML file. Similarly, Export-XAFarm exports all farm data to an XML file. You can use command line parameters to more finely control what is exported and imported.

  • Export applications partially – If you have a large number of applications and want to control how many are exported to the XML file, use the following parameters:
    • AppLimit – Specifies the number of applications to export.
    • SkipApps – Specifies the number of applications to skip before exporting subsequent applications.
    You can use both of these parameters to export large quantities of applications in manageable chunks. For example, the first time you run Export-XAFarm, you want to export only the first 200 applications, so you specify that value in the AppLimit parameter.

    Export-XAFarm -XmlOutputFile "Apps1-200.xml" 
    -AppLimit "200"
    The next time you run Export-XAFarm, you want to export the next 100 applications, so you use the SkipApps parameter to disregard the applications you’ve already exported (the first 200), and the AppLimit parameter to export the next 100 applications.

    Export-XAFarm -XmlOutputFile "Apps201-300.xml" 
    -AppLimit "100" -SkipApps "200"
  • Do not export certain objects – Some objects can be ignored and thus do not need to be exported, particularly those objects that are not imported; see Policy settings not imported and Application property mapping. Use the following parameters to prevent exporting unneeded objects:
    • IgnoreAdmins – Do not export administrator objects
    • IgnoreServers – Do not export server objects
    • IgnoreZones – Do not export zone objects
    • IgnoreOthers – Do not export configuration logging, load evaluator, load balancing policy, printer driver, and worker group objects
    • IgnoreApps – Do not export applications; this allows you to export other data to an XML output file and then run the export again to export applications to a different XML output file.

    You can also use these parameters to work around issues that could cause the export to fail. For example, if you have a bad server in a zone, the zone export might fail; if you include the IgnoreZones parameter, the export continues with other objects.

  • Delivery Group names – If you do not want to put all of your applications into one Delivery Group (for example, because they are accessed by different sets of users and published to different sets of servers), you can run Import-XAFarm multiple times, specifying different applications and a different Delivery Group each time. Although you can use PowerShell cmdlets to move applications from one Delivery Group to another after the migration, importing selectively to unique Delivery Groups can reduce or eliminate the effort of moving the applications later.
    1. Use the DeliveryGroupName parameter with the Import-XAFarm cmdlet. The script creates the specified Delivery Group if it doesn’t exist.
    2. Use the following parameters with regular expressions to filter the applications to be imported into the Delivery Group, based on folder, worker group, user account, and/or server names. Enclosing the regular expression in single or double quotation marks is recommended. For information about regular expressions, see http://msdn.microsoft.com/en-us/library/hs600312(v=vs.110).aspx.
      • MatchWorkerGroup and NotMatchWorkerGroup – For example, for applications published to worker groups, the following cmdlet imports applications in the worker group named “Productivity Apps” to a XenApp 7.6 Delivery Group of the same name:
        Import-XAFarm –XmlInputFile XAFarm.xml –LogFile XAFarmImport.log
        –MatchWorkerGroup ‘Productivity Apps’ –DeliveryGroupName ‘Productivity Apps’
      • MatchFolder and NotMatchFolder – For example, for applications organized in application folders, the following cmdlet imports applications in the folder named “Productivity Apps” to a XenApp 7.6 Delivery Group of the same name.
        Import-XAFarm –XmlInputFile XAFarm.xml –LogFile XAFarmImport.log
        –MatchFolder ‘Productivity Apps’ –DeliveryGroupName ‘Productivity Apps’
        For example, the following cmdlet imports applications in any folder whose name contains “MS Office Apps” to the default Delivery Group.

        Import-XAFarm -XmlInputFile .THeFarmApps.XML -MatchFolder ".*/MS Office Apps/.*"
      • MatchAccount and NotMatchAccount – For example, for applications published to Active Directory users or user groups, the following cmdlet imports applications published to the user group named “Finance Group” to a XenApp 7.6 Delivery Group named “Finance.”
        Import-XAFarm –XmlInputFile XAFarm.xml –LogFile XAFarmImport.log
        –MatchAccount ‘DOMAIN\Finance Group’ –DeliveryGroupName ‘Finance’
      • MatchServer and NotMatchServer – For example, for applications organized on servers, the following cmdlet imports applications associated with the server not named “Current” to a XenApp Delivery Group named “Legacy.”
        Import-XAFarm -XmlInputFile XAFarm.xml -LogFile XAFarmImport.log
        -NotMatchServer 'Current' -DeliveryGroupName 'Legacy'
  • Customization – PowerShell programmers can create their own tools. For example, you can use the export script as an inventory tool to keep track of changes in a XenApp 6.x farm. You can also modify the XSD files or (create your own XSD files) to store additional data or data in different formats in the XML files. You can specify a nondefault XSD file with each of the import cmdlets.
    Note: Although you can modify script files to meet specific or advanced migration requirements, support is limited to the scripts in their unmodified state. Citrix Technical Support will recommend reverting to the unmodified scripts to determine expected behavior and provide support, if necessary.

Troubleshooting

  • If you are using PowerShell verison 2.0 and you added the Citrix Group Policy PowerShell Provider snap-in or the Citrix Common Commands snap-in using the Add-PSSnapIn cmdlet, you might see the error message “Object reference not set to an instance of an object” when you run the export or import cmdlets. This error does not affect script execution and can be safely ignored.
  • Avoid adding or removing the Citrix Group Policy PowerShell Provider snap-in in the same console session where the export and import script modules are used, because those script modules automatically add the snap-in. If you add or remove the snap-in separately, you might see one of the following errors:
    • “A drive with the name ‘LocalGpo’ already exists.” This error appears when the snap-in is added twice; the snap-in attempts to mount the drive LocalGpo when it’s loaded, and then reports the error.
    • “A parameter cannot be found that matches parameter name ‘Controller’.” This error appears when the snap-in has not been added but the script attempts to mount the drive. The script is not aware that the snap-in was removed. Close the console and launch a new session. In the new session, import the script modules; do not add or remove the snap-in separately.
  • When importing the modules, if you right-click a .psd1 file and select Open or Open with PowerShell, the PowerShell console window will rapidly open and close until you stop the process. To avoid this error, enter the complete PowerShell script module name directly in the PowerShell console window (for example, Import-Module .ExportPolicy.psd1).
  • If you receive a permission error when running an export or import, ensure you are a XenApp administrator with permission to read objects (for export) or read and create objects (for import). You must also have sufficient Windows permission to run PowerShell scripts.
  • If an export fails, check that the XenApp 6.x farm is in a healthy state by running the DSMAINT and DSCHECK utilities on the XenApp 6.x controller server.
  • If you run a preview import and then later run the import cmdlets again for an actual migration, but discover that nothing was imported, verify that you removed the Preview parameter from the import cmdlets.

Policy settings not imported

The following computer and user policy settings are not imported because they are no longer supported. The features and components that support these settings have either been replaced by new technologies/components or the settings do not apply because of architectural and platform changes.

Computer policy settings not imported

  • Connection access control
  • CPU management server level
  • DNS address resolution
  • Farm name
  • Full icon caching
  • Health monitoring, Health monitoring tests
  • License server host name, License server port
  • Limit user sessions, Limits on administrator sessions
  • Load evaluator name
  • Logging of logon limit events
  • Maximum percent of servers with logon control
  • Memory optimization, Memory optimization application exclusion list, Memory optimization interval, Memory optimization schedule: day of month, Memory optimization schedule: day of week, Memory optimization schedule: time
  • Offline app client trust, Offline app event logging, Offline app license period, Offline app users
  • Prompt for password
  • Reboot custom warning, Reboot custom warning text, Reboot logon disable time, Reboot schedule frequency, Reboot schedule randomization interval, Reboot schedule start date, Reboot schedule time, Reboot warning interval, Reboot warning start time, Reboot warning to users, Scheduled reboots
  • Shadowing *
  • Trust XML requests (configured in StoreFront)
  • Virtual IP adapter address filtering, Virtual IP compatibility programs list, Virtual IP enhanced compatibility, Virtual IP filter adapter addresses programs list
  • Workload name
  • XenApp product edition, XenApp product model
  • XML service port

* Replaced with Windows Remote Assistance

User policy settings not imported

  • Auto connect client COM ports, Auto connect client LPT ports
  • Client COM port redirection, Client LPT port redirection
  • Client printer names
  • Concurrent logon limit
  • Input from shadow connections *
  • Linger disconnect timer interval, Linger terminate timer interval
  • Log shadow attempts *
  • Notify user of pending shadow connections *
  • Pre-launch disconnect timer interval, Pre-launch terminate timer interval
  • Session importance
  • Single Sign-On, Single Sign-On central store
  • Users who can shadow other users, Users who cannot shadow other users *

* Replaced with Windows Remote Assistance

Application types not imported

The following application types are not imported.

  • Server desktops
  • Content
  • Streamed applications (App-V is the new method used for streaming applications)

Application property mapping

The farm data import script imports only applications. The following application properties are imported without change.

IMA Property FMA Property
AddToClientDesktop ShortcutAddedToDesktop
AddToClientStartMenu ShortcutAddedToStartMenu
BrowserName Name
ClientFolder ClientFolder
CommandLineExecutable CommandLineExecutable
CpuPriorityLevel CpuPriorityLevel
Description Description
DisplayName PublishedName
Enabled Enabled
StartMenuFolder StartMenuFolder
WaitOnPrinterCreation WaitForPrinterCreation
WorkingDirectory WorkingDirectory
FolderPath AdminFolderName
Note: IMA and FMA have different restrictions on folder name length. In IMA, the folder name limit is 256 characters; the FMA limit is 64 characters. When importing, applications with a folder path containing a folder name of more than 64 characters are skipped. The limit applies only to the folder name in the folder path; the entire folder path can be longer than the limits noted. To avoid applications from being skipped during the import, Citrix recommends checking the application folder name length and shortening it, if needed, before exporting.
The following application properties are initialized or uninitialized by default, or set to values provided in the XenApp 6.x data:

FMA Property Value
Name Initialized to the full path name, which contains the IMA properties FolderPath and DisplayName, but stripped of the leading string “Applications”
ApplicationType HostedOnDesktop
CommandLineArguments Initialized using the XenApp 6.x command line arguments
IconFromClient Uninitialized; defaults to false
IconUid Initialized to an icon object created using XenApp 6.x icon data
SecureCmdLineArgumentsEnabled Uninitialized; defaults to true
UserFilterEnabled Uninitialized; defaults to false
UUID Read-only, assigned by the Controller
Visible Uninitialized; defaults to true
The following application properties are partially migrated:

IMA Property Comments
FileTypes Only the file types that exist on the new XenApp site are migrated. File types that do not exist on the new site are ignored. File types are imported only after the file types on the new site are updated.
IconData New icon objects are created if the icon data has been provided for the exported applications.
Accounts The user accounts of an application are split between the user list for the Delivery Group and the application. Explicit users are used to initialize the user list for the application. In addition, the “Domain Users” account for the domain of the user accounts is added to the user list for the Delivery Group.
The following XenApp 6.x properties are not imported:

IMA Property Comments
ApplicationType Ignored.
HideWhenDisabled Ignored.
AccessSessionConditions Replaced by Delivery Group access policies.
AccessSessionConditionsEnabled Replaced by Delivery Group access policies.
ConnectionsThroughAccessGatewayAllowed Replaced by Delivery Group access policies.
OtherConnectionsAllowed Replaced by Delivery Group access policies.
AlternateProfiles FMA does not support streamed applications.
OfflineAccessAllowed FMA does not support streamed applications.
ProfileLocation FMA does not support streamed applications.
ProfileProgramArguments FMA does not support streamed applications.
ProfileProgramName FMA does not support streamed applications.
RunAsLeastPrivilegedUser FMA does not support streamed applications.
AnonymousConnectionsAllowed FMA uses a different technology to support unauthenticated (anonymous) connections.
ApplicationId, SequenceNumber IMA-unique data.
AudioType FMA does not support advanced client connection options.
EncryptionLevel SecureICA is enabled/disabled in Delivery Groups.
EncryptionRequired SecureICA is enabled/disabled in Delivery Groups.
SslConnectionEnabled FMA uses a different SSL implementation.
ContentAddress FMA does not support published content.
ColorDepth FMA does not support advanced window appearances.
MaximizedOnStartup FMA does not support advanced window appearances.
TitleBarHidden FMA does not support advanced window appearances.
WindowsType FMA does not support advanced window appearances.
InstanceLimit FMA does not support application limits.
MultipleInstancesPerUserAllowed FMA does not support application limits.
LoadBalancingApplicationCheckEnabled FMA uses a different technology to support load balancing.
PreLaunch FMA uses a different technology to support session prelaunch.
CachingOption FMA uses a different technology to support session prelaunch.
ServerNames FMA uses a different technology.
WorkerGroupNames FMA does not support worker groups.

Upgrade a deployment

Updated: 2015-01-08

You can upgrade certain deployments to newer versions without having to first set up new machines or Sites; this is called an in-place upgrade. You can upgrade:

  • From XenDesktop version 5 (or a later version) to the latest released (current) XenDesktop version
  • From XenApp version 7.5 (or a later version) to the latest released (current) XenApp version

You can also use the XenApp 7.6 installer to upgrade a XenApp 6.5 worker server to a XenApp 7.6 VDA for Windows Server OS. This is a supplementary activity to migrating XenApp 6.5; see Upgrade a XenApp 6.5 worker to a new VDA for Windows Server OS.

To start an upgrade, you run the installer from the new version to upgrade previously installed core components (Delivery Controller, Citrix Studio, Citrix Director, Citrix License Server) and VDAs. The installer determines which components require upgrading and then starts the upgrade at your command. After upgrading the components, you use the newly upgraded Studio to upgrade the Site database and the Site.

In this content, the word product refers to XenApp 7.x or XenDesktop 7.x, unless otherwise noted.

You cannot upgrade:

  • From an Early Release or Technology Preview version
  • From a XenApp version earlier than 7.5 (except replacing XenApp 6.5 software on a server with a current VDA for Server OS; see Migrate XenApp 6.x)
  • From a XenDesktop version earlier than 5.6; see Migrate XenDesktop 4
  • From XenApp to XenDesktop, or from XenDesktop to XenApp

Which product component versions can be upgraded?

Using the product installer and Studio, you can upgrade:

  • Delivery Controllers 5 or later
  • VDA 5.0 SP1 or later
    • Unlike earlier VDA releases, you must use the product installer to upgrade VDAs; you cannot use MSIs.
    • If the installer detects Receiver for Windows (Receiver.exe) on the machine, it is upgraded to the Receiver version included on the product installation media.
    • If the installer detects Receiver for Windows Enterprise (CitrixReceiverEnterprise.exe) on the machine, it is upgraded to Receiver for Windows Enterprise 3.4.
  • Director 1 or later
  • Database – This upgrades the schema and migrates data for the Site database (plus the Configuration Logging and Monitoring databases, if you’re upgrading from an earlier 7.x version)
  • Personal vDisk
Using the guidance in the feature/product documentation, upgrade the following if needed:

  • Provisioning Services (for XenApp 7.x and XenDesktop 7.x, Citrix recommends using the latest released version; the minimum supported version is Provisioning Services 7.0).
    • Upgrade the Provisioning Services server using the server rolling upgrade, and the clients using vDisk versioning.
    • Provisioning Services 7.x does not support creating new desktops with XenDesktop 5 versions. So, although existing desktops will continue to work, you cannot use Provisioning Services 7.x to create new desktops until you upgrade XenDesktop. Therefore, if you plan a mixed environment of XenDesktop 5.6 and 7.x Sites, do not upgrade Provisioning Services to version 7.
  • Microsoft System Center Virtual Machine Manager SCVMM. The current product supports SCVMM 2012 and SCVMM 2012 SP1; XenDesktop 5.x supports earlier versions. Use the following upgrade sequence to avoid downtime:
    1. If you have Controllers running versions earlier than XenDesktop 5.6 FP1, upgrade them to XenDesktop 5.6 FP1 (see the XenDesktop documentation for that version).
    2. Upgrade the SCVMM server to SCVMM 2012; see the Microsoft documentation for instructions.
    3. Upgrade XenDesktop components to the current version.
    4. Optionally, upgrade the SCVMM server to SCVMM 2012 SP1.
  • StoreFront.

Requirements, limits, and preparation

You must use the product installer’s graphical or command-line interface to upgrade core components and VDAs; you cannot import or migrate data from an earlier version.

If you install or upgrade any components to the new version but choose not to upgrade other components (on different machines) that require upgrade, Studio will remind you.

For example, if an upgrade includes new versions of the Controller and Studio, and you upgrade only the Controller (but you do not run the installer on the machine where Studio is installed), Studio will not let you continue to manage the Site until you upgrade Studio.

Before upgrading the Citrix License Server, be sure your Subscription Advantage date is valid for the new product version.

If you are upgrading from an earlier 7.x product version, the date must be at least 2013.0522.

You cannot upgrade XenDesktop Express Edition. Obtain and install a license for a currently supported edition, then upgrade it.

Before beginning any upgrade activity, back up the database, as described in CTX135207, so you can restore it if any issues are discovered after the database upgrade.

Optionally, back up templates and upgrade hypervisors, if used.

If you must continue to run earlier version Sites and current version Sites, see Mixed environment considerations.

If you have VDAs installed on Windows XP or Windows Vista machines, see VDAs on machines running Windows XP or Windows Vista.

If you do not plan to upgrade all VDAs to the latest version, review Mixed VDA support.

If your deployment includes Web Interface, Citrix recommends using StoreFront.

In addition to being a domain user, you must be a local administrator on the machines where you are upgrading product components.

You cannot upgrade from XenDesktop to XenApp, or from XenApp to XenDesktop.

Review the upgrade sequence below so you can plan for and mitigate potential outages.

Mixed environment considerations

When your environment contains Sites/farms with different product versions (a mixed environment), Citrix recommends using StoreFront to aggregate applications and desktops from different product versions. For details, see the StoreFront documentation.

  • Generally, the current Studio and Director versions manage/monitor only current Sites. (Although this version of Director can monitor XenDesktop 5.x VDAs, some data (including logon duration) will not be available for those VDAs.) For example, you cannot manage a XenDesktop 7.1 Site with Studio version 7.6. Similarly, you cannot manage a XenDesktop 7.6 Site with a Studio version 7.1.
  • You can use current VDAs in deployments containing earlier Controller versions. Keep in mind that in such cases, new features in the current release may not be available. See Mixed VDA considerations below.
  • Sites with Controllers at version 5.x and VDAs at version 7.x should remain in that state only temporarily. Ideally, you should complete the upgrade of all components as soon as possible.
  • In a mixed environment, continue using the Studio and Director versions for each release, but make sure that different versions are installed on separate machines.
  • If you plan to run XenDesktop 5.6 and 7.x Sites simultaneously and use Provisioning Services for both, either deploy a new Provisioning Services for use with the 7.x Site, or upgrade the current Provisioning Services and be unable to provision new workloads in the XenDesktop 5.6 Site.
  • Do not upgrade a standalone Studio version until you are ready to use the new version.

VDAs on machines running Windows XP or Windows Vista

You cannot upgrade VDAs installed on machines running Windows XP or Windows Vista to a 7.x version. You must use VDA 5.6 FP1 with certain hotfixes; see CTX140941 for instructions. Although earlier-version VDAs will run in a 7.x Site, they cannot use many of its features, including:

  • Features noted in Studio that require a newer VDA version.
  • Configuring App-V applications from Studio.
  • Configuring Receiver StoreFront addresses from Studio.
  • Automatic support for Microsoft Windows KMS licensing when using Machine Creation Services. See CTX128580.
  • Information in Director:
    • Logon times and logon end events impacting the logon duration times in the Dashboard, Trends, and User Detail views.
    • Logon duration breakdown details for HDX connection and authentication time, plus duration details for profile load, GPO load, logon script, and interactive session establishment.
    • Several categories of machine and connection failure rates.
    • Activity Manager in the Help Desk and User Details views.

Citrix recommends reimaging Windows XP and Windows Vista machines to a supported operating system version and then installing the latest VDA.

Mixed VDA support

When you upgrade the product to a later version, Citrix recommends you upgrade all the core components and VDAs so you can access all the new and enhanced features in your edition. For example, to use the session prelaunch, session linger, and unauthenticated users features in the 7.6 release, the VDAs must have a minimum version of 7.6 installed.

In some environments, you may not be able to upgrade all VDAs to the most current version. In this scenario, when you create a machine catalog, you can specify the VDA version installed on the machines. By default, this setting specifies the latest recommended VDA version; you need to consider changing this setting only if the machine catalog contains machines with earlier VDA versions. However, mixing VDA versions in a machine catalog can have unintended effects

As noted above, if your deployment includes Windows XP and Windows Vista systems, you must use an earlier VDA version, and the machine catalog containing those machines must specify VDA version 5.6 FP1. The VDAs will register successfully with the Controller, but those machines will be unable to use many of the new features in the 7.x versions (including StoreFront). This also applies to any machines you add to that catalog that have 7.x version VDAs. The following graphic illustrates this.

In the above case, if you must continue to use older VDAs, place them in a machine catalog by themselves.

If a machine catalog is created with the default recommended VDA version setting, and any of the machines in the catalog has an earlier VDA version installed, those machines will not be able to register with the Controller and will not work.

For example, assume the most recent VDA version is 7.6. You create a machine catalog with the default VDA setting: “7.6 (recommended, to access the latest features).” You add three machines to that catalog: two with VDA 7.6 and one with VDA 7.1.

In this example, the machine with VDA 7.1 will not register with the Controller. If you cannot upgrade that VDA, consider creating a separate machine catalog configured with a VDA setting of “version 7.0 or later” and adding that machine. Although that machine will not be able to take advantage of new 7.6 features, it will be able to register with the Controller.

Upgrade sequence

If components are installed on different machines, you run the installer on each of those machines.

The upgrade sequence is illustrated below; descriptions follow.

To run the product installer graphical interface, log on to the machine and then insert the media or mount the ISO drive for the new release. Double-click AutoSelect. To use the command-line interface, see Install using the command line.

  1. If more than one core component is installed on the same server (for example, the Controller, Studio, and License Server) and several of those components have new versions available, they will all be upgraded when you run the installer on that server. If any core components are installed on machines other than the Controller, run the installer on each of those machines (in the preferred order: License Server, StoreFront, and then Director).
  2. Upgrade the Provisioning Services servers and clients, using the guidance in the Provisioning Services documentation.
  3. Run the product installer on machines containing VDAs. Although you can upgrade VDAs before or after upgrading the Controllers, Citrix recommends you do so before, because it allows you to quickly enable new features after the upgrade.
    When upgrading VDAs from an earlier 7.x version that are installed on physical machines (including Remote PC Access), use the command-line interface with the parameter: /EXCLUDE “Personal vDisk”,”Machine Identity Service”. For example:

    C:x64XenDesktop SetupXenDesktopVdaSetup.exe /EXCLUDE
    				“Personal vDisk”,”Machine Identity Service”
  4. Run the product installer on half of the Controllers. (This will also upgrade any other core components installed on those servers.) For example, if your Site has four Controllers, run the installer on two of them.
    • Leaving half of the Controllers active allows users to access the Site. VDAs can register with the remaining Controllers. There may be times when the Site has reduced capacity because fewer Controllers are available. The upgrade causes only a brief interruption in establishing new client connections during the final database upgrade steps. The upgraded Controllers cannot process requests until the entire Site is upgraded.
    • If your Site has only one Controller, the Site is inoperable during the upgrade.
  5. If Studio is installed on a different machine than one of the Controllers you upgraded in the previous step, run the installer on the machine where Studio is installed.
  6. From the newly upgraded Studio, upgrade the Site database. For details, see Upgrade the database and Site below.
  7. From the newly upgraded Studio, select Citrix Studio site-name in the navigation pane. Select the Common Tasks tab. Select Upgrade remaining Delivery Controllers.
  8. After completing the upgrade and confirming completion, close and then reopen Studio.
  9. In the Site Configuration section of the Common Tasks page, select Perform registration. Registering the Controllers makes them available to the Site.
  10. After you select Finish when the upgrade completes, you are offered the opportunity to enroll in the Citrix Customer Experience Improvement Program (CEIP), which collects anonymous information about your deployment. That information is then used to improve product quality, reliability, and performance.
  11. After upgrading components, the database, and the Site, use Studio to:
    • Test the newly-upgraded Site. From Studio, select Citrix Studio site-name in the navigation pane. Select the Common Tasks tab and then select Test Site. These tests were run automatically after you upgraded the database, but you can run them again at any time.
    • Update all master images that use the upgraded VDA.
    • Upgrade machine catalogs and Delivery Groups.

Upgrade the database and Site

After upgrading the core components and VDAs, use the newly upgraded Studio to initiate an automatic or manual database and Site upgrade.

  • For an automatic database upgrade, the Studio user’s permissions must include the ability to update the SQL Server database schema (for example, the db_owner database role).
  • If the Studio user does not have those permissions, initiating a manual database upgrade will generate scripts. The Studio user runs some of the scripts from Studio; the database administrator runs other scripts using a tool such as SQL Server Management Studio.
Important: Citrix strongly recommends you back up the database before upgrading, as described in CTX135207.

During a database upgrade, product services are disabled. During that time, Controllers cannot broker new connections for the Site, so plan carefully.

After the database upgrade completes and product services are enabled, Studio tests the environment and configuration, and then generates an HTML report. If problems are identified, you can restore the database backup. After resolving issues, you can upgrade the database again.

Upgrade the database and Site automatically – Launch the newly upgraded Studio. After you choose to start the Site upgrade automatically and confirm that you are ready, the database and Site upgrade proceeds.

Upgrade the database and Site manually – This process includes generating and running scripts.

  1. Launch the newly upgraded Studio. After you choose to manually upgrade the Site, the wizard checks for License Server compatibility and requests confirmation. After you confirm that you have backed up the database, the wizard generates and displays the scripts and a checklist of upgrade steps.
  2. If you are upgrading from XenDesktop 5, run the following scripts in the order shown:
    Script Description
    DisableServices.ps1 PowerShell script to be run by the Studio user on a Controller to disable product services.
    UpgradeDatabase.sql SQL script to be run by the database administrator using a tool such as SQL Server Management Studio.
    EnableServices.ps1 PowerShell script to be run by the Studio user on a Controller to enable product services.
  3. If you are upgrading from an earlier 7.x product version, run the following scripts in the order shown:
    Script Description
    DisableServices.ps1 PowerShell script to be run by the Studio user on a Controller to disable product services.
    UpgradeSiteDatabase.sql SQL script to be run by the database administrator on the server containing the Site database, using a tool such as SQL Server Management Studio.
    UpgradeMonitorDatabase.sql SQL script to be run by the database administrator on the server containing the Monitor database, using a tool such as SQL Server Management Studio.
    UpgradeLoggingDatabase.sql SQL script to be run by the database administrator on the server containing the Configuration Logging database, using a tool such as SQL Server Management Studio. Run this script only if this database changes (for example, after applying a hotfix).
    EnableServices.ps1 PowerShell script to be run by the Studio user on a Controller to enable product services.
  4. After you complete the displayed checklist tasks, select Finish upgrade.