Product Documentation


May 25, 2017

To upgrade existing StoreFront 2.0 through 2.6.x deployments to this version of StoreFront, run the StoreFront 3.0.x installation file. Releases before StoreFront 2.0 cannot be upgraded directly. Instead, you must first upgrade StoreFront 1.2 to StoreFront 2.0 before upgrading to this StoreFront. Similarly, you cannot upgrade Receiver StoreFront 1.1 to this StoreFront directly. You must upgrade Receiver StoreFront 1.1 to StoreFront 1.2 and then again to StoreFront 2.0 before finally upgrading to this StoreFront.

When the upgrade process is started, it cannot be rolled back. If the upgrade is interrupted or cannot be completed, the existing configuration is removed but StoreFront is not installed. Before starting to upgrade, you must disconnect users from the StoreFront deployment and prevent users from accessing the servers while the upgrade is in progress. This procedure ensures that all StoreFront files are accessible by the installer during the upgrade. If the installer cannot access any files, they cannot be replaced and the upgrade fails, resulting in the removal of the existing StoreFront configuration. StoreFront does not support multiple server deployments containing different product versions. All servers in a group must be updated to the upgraded version before granting access to the deployment. Concurrent upgrade is not supported for multiple server deployments, servers must be upgraded sequentially. Citrix recommends that you back up your data before upgrading.

Uninstalling StoreFront removes the authentication service, stores, users' application subscriptions, Receiver for Web sites, Desktop Appliance sites, and XenApp Services URLs. If you decide to uninstall StoreFront, you must manually recreate your services, stores, and sites when you reinstall StoreFront. Upgrading enables you to preserve your StoreFront configuration and leaves users' application subscription data intact. Users do not need to resubscribe to all of their applications.

Upgrading the operating system version on a server running StoreFront is not supported. Citrix recommends that you install StoreFront on a new installation of the operating system.

To upgrade from StoreFront 2.0 through 3.0 to this version of StoreFront

  1. Disable access to the deployment through the load balancing environment. Disabling the load balancing URL prevents users from connecting to the deployment during the upgrade process.
  2. Back up all the servers in the server group.
  3. Remove one of the servers from the existing server group.
  4. Restart the server you removed.
    You can use a parallel load balancer to check the new server group while you build it. The variant that maximizes availability and minimizes risk involves removing and upgrading only one server from the original server group. You can then build the new group out of new machines rather than machines taken out of the original server group.
  5. Upgrade the server you removed using an administrator account that has no other installations running and a minimum of other applications.
  6. Check that the server you removed has upgraded successfully.
  7. Remove another one of the servers in the existing server group from the load balancer.
  8. Restart the server you removed for the same reasons noted in Step 1.
  9. Uninstall the currently installed version of StoreFront and install the new version of StoreFront.
  10. Join the newly installed server into a new server group consisting of all the upgraded servers and the freshly installed servers. Check the servers are functioning correctly.
  11. Repeat Steps 3 - 10 until the new server group has sufficient capacity to take over from the old server group. Point the load balancer at the new server group, and check that it is functioning correctly.
  12. Repeat Steps 3 - 10 for the remaining servers, adding each one to the load balancer after each successful upgrade.


If you want to maximize availability, you can maintain access to the original server group during the upgrade process until the new server group becomes available. To maintain access to the original server group during the upgrade process:

  1. Skip Step 1.
  2. Change Step 11 to include disabling access to the original server group using the load balancer. Export subscription data from the original server group and import it into the new server group. Enable access to the new server group using the load balancer.

This procedure ensures that any subscription changes made by users after Step 3 and before Step 11 are available in the new server group.

You can maximize availability by removing only one server from the original server group and upgrading it. Then build the new server group using new servers rather than servers removed from the original server group. When the new server group is in production, you can retire the old servers.