Upgrading an enterprise Horizon 8 deployment involves several high-level tasks. Upgrading is a multistage process in which procedures must be performed in a particular order.
Attention: For supported upgrade paths, see the Product Interoperability Matrix.
You must complete the upgrade process in a specific order. Order is also important within each upgrade stage.
Note: This overview relates to upgrades for major, minor, and maintenance releases.
How many of the following tasks you need to complete depends on which components of Horizon 8 you use in your deployment.
-
If you have features that are no longer supported in the latest version of Horizon 8, you must uninstall some of these features before proceeding with the upgrade. See Uninstalling No Longer Supported Features.
-
Upgrade the Omnissa Horizon Client software that runs on end users' client devices. See Upgrade the Client Application.
-
Make backups and record different settings on the machines that host Omnissa Horizon Connection Server instances. See Preparing Horizon Connection Server for an Upgrade.
If you have multiple Horizon Connection Server instances in a replicated group, make backups and record configuration settings for only one instance in the group. For other preparation tasks, you can perform the tasks for one instance at a time, just before you perform the upgrade of that server instance.
-
Upgrade Horizon Connection Server instances. See Upgrade Horizon Connection Servers in a Replicated Group.
In a typical production environment that consists of two or more Horizon Connection Server instances fronted by a load balancer, you need to remove Horizon Connection Server instances from the load balanced cluster while they are upgraded.
Important: After you upgrade a Horizon Connection Server instance to the latest version, you cannot downgrade that instance to an earlier version. After you upgrade all Horizon Connection Server instances in a replicated group, you cannot add another instance that runs an earlier version.
-
Upgrade the Horizon Edge appliance.
After all Horizon Connection Servers in the pod are upgraded, upgrade the Horizon Edge Appliance to the same Horizon version. Do not upgrade the Edge Appliance before upgrading the Connection Servers.
For environments with multiple Edge Appliances, upgrade them one at a time to minimize service disruption.
-
Upgrade the group policies used in Microsoft Active Directory. See Using Group Policy Administrative Template Files.
-
If you are also upgrading VMware vSphere components, upgrade vCenter Server. See Upgrade vCenter Server.
During the vCenter Server upgrade, existing remote desktop and application sessions will not be disconnected. Remote desktops that are in a provisioning state will not get powered on during the vCenter Server upgrade, and new desktops cannot be launched during the vCenter Server upgrade.
-
If you are also upgrading vSphere, upgrade the VMware ESXi hosts and virtual machines. See Upgrade ESXi Hosts and Their Virtual Machines.
ESXi hosts can be upgraded with zero down time by vMotioning the virtual machines to another host in the cluster, if hosts are configured under clustered environment.
-
If you currently use Windows Terminal Services servers as desktop sources, verify that the RDS Host role is installed. See Upgrade RDS Hosts That Provide Session-Based Desktops
-
Upgrade the Horizon™ Agent software that runs on the physical or virtual machines that are used as templates for desktop cloning, as full-clone desktops in a pool, and as individual desktops in a manual pool. See Upgrade Horizon Agent.
-
Use the newly upgraded virtual machine desktop sources to create upgraded pools of desktops. See Upgrading Published and Virtual Desktops.
-
If you use the Cloud Pod Architecture feature, see Upgrading a Cloud Pod Architecture Environment.
Because certain commands can simultaneously upgrade more than one stage, Omnissa recommends that you thoroughly understand the irreversible changes at each stage before you upgrade your production environments.
When upgrading to version 2512
The installer now records and checks a schema-version property in both the local and global AD LDS instances. The installer will read that value and only attempt a schema update when the directory’s version is older than the installer’s version. This avoids unnecessary schema work and shortens the upgrade time for deployments that are at the correct schema level. The installer also includes the command-line option SKIP_SCHEMA_VERSION=1 which forces the upgrade of the schema partition.
If a schema update is required, the installer verifies the availability of the schema master role. When appropriate and safe, the role transfers to the local instance before stopping or uninstalling services. This prevents situations where the upgrade might fail due to schema master not being available after the existing Horizon services have been removed.
When upgrading to version 2503
During an upgrade, the existing Horizon Directory Services (AD LDS) partition names are retained.
After upgrading your Horizon Connection Servers to version 2503, we recommend that you plan and perform updating the partition names to the new ones.
Starting with Horizon Connection Server release 2503, the application partition names in both local and global AD LDS instances are updated. In version 2503, the partition name has changed from its pre-2503 name to horizon.
To assist customers with existing Horizon deployments with this transition, Omnissa provides a migration script that updates the partition names while ensuring data integrity. After all pods are upgraded to Horizon version 2503, you can run the migration script to permanently update your deployments to the new application partition naming convention. For details, refer to Omnissa KB article 6000797.
Deploying an Extended Service Branch
About once a year, Omnissa designates one Horizon 8 release as an Extended Service Branch (ESB). An ESB is a parallel release branch to the existing Current Releases (CR) of the product. By choosing to deploy an ESB, customers receive periodic service packs (SP) updates, which include cumulative critical bug fixes and security fixes. Most importantly, there are no new features in the SP updates, so customers can rely on a stable Horizon 8 platform for their critical deployments.
For more information on the ESB and the Horizon 8 versions that have been designated an ESB, see Omnissa Knowledge Base article 86477.
Was this page helpful?