Migrating Horizon 8 to a different capacity provider

Overview

Omnissa Horizon has evolved and now offers support and integration allowing Horizon to use multiple hypervisor vendors and capacity providers. This provides you with more flexibility and choice in the hypervisor or capacity provider that you use for your Horizon environments.

This guide covers some of the approaches, and considerations when migrating existing Omnissa Horizon 8 pod infrastructure components and workloads from one hypervisor or capacity provider to another one, including:

• Horizon 8 management pod components
  • Connection Servers
  • Enrollment Servers
  • Unified Access Gateways
• Horizon desktop pools
• Horizon server farms (and published applications)
• App Volumes
• Dynamic Environment Manager

Horizon 8 management components

Migrating a Horizon 8 environment to a new hypervisor or capacity provider requires balancing transition speed against user impact. Before executing a technical migration, select the strategy that best fits your risk profile:

• Greenfield build-out: Deploy a completely new Horizon pod on the new capacity provider. This is ideal for organizations looking to eliminate technical debt or those who cannot tolerate any risk to their existing environment.
• Pod federation (Cloud Pod Architecture): Build a new Horizon pod on the new capacity provider and federate it with the old Pod. This allows for a granular, group-by-group migration of users via Global Entitlements and provides a seamless rollback path.
• Deploy and replace (In-pod transition): Replace individual components within the existing pod. This is often the most efficient path for smaller environments, ensuring the management layer becomes native to the new environment without requiring a full redesign.

Connection Servers

While converting an existing Connection Server from one hypervisor to another is technically possible, the preferred method is to leverage the Horizon replica architecture. Rather than converting an existing legacy Windows Server VM, you should deploy a fresh Windows Server instance on the new hypervisor.

Use the following process, replace one Connection Server at a time, and ensure that you remain within the supported limit of seven Connection Servers per pod during this transition.

1. Deploy new server as a replica: Install the Horizon Connection Server software as a Replica Server, pointing it to an existing Connection Server in the pod.
2. Synchronize: Once AD LDS synchronization is complete, the new server becomes a peer in the pod.
3. Validate: Direct a portion of your load balancer traffic to this new node to verify functionality and stability.
4. Decommission: Once stability is confirmed, decommission the legacy Connection Servers one at a time.

For more information see, Upgrade to the Latest Version of Horizon Connection Server on a Different Machine.

Enrollment Servers

It is recommended that you deploy new Windows Servers onto the target hypervisor platform and replace the existing Enrollment Servers.

While you could convert an existing VM running the Enrollment Server service from the old hypervisor to the target hypervisor, it can introduce effort, risk, and downtime.

Unified Access Gateways

Unified Access Gateway (UAG) appliances are designed to be replaceable, easily deployed, with upgrades consisting of deploying a replacement appliance. You should replace existing UAG appliances with new ones deployed onto the target hypervisor or capacity provider.

Use the PowerShell-based deployment scripts and INI settings files to reproduce the configuration of your existing Unified Access Gateway appliances. This ensures that the security posture, authentication settings, and certificate chains remain intact while making the appliance native to the new infrastructure.

For more information, see Using PowerShell to Deploy Unified Access Gateway.

Golden images

It is recommended that you build new golden images on the target hypervisor or capacity provider. Converting existing golden images carries risk and can experience issues where legacy drivers remain in the Windows registry and cause micro-stutters or boot delays.

Desktop pool migration

A desktop pool cannot span multiple hypervisors or capacity providers. You need to build replacement desktop pools on the target capacity provider. You can optionally use Cloud Pod Architecture (CPA) and Global Entitlements (either within the pod or across federated pods) to assist in transitioning users from using an old pool to a new pool.

Depending on the desktop pool type, determine your preferred approach to reproducing existing desktop pools on the target capacity provider.

Linux support note: At the time of writing, Omnissa Horizon does not support the automated provisioning of Linux desktop pools on alternative hypervisors, such as Nutanix AHV. Organizations that require Linux virtual desktops on those capacity providers can utilize Horizon manual desktop pools.

Converting existing VMs

Where a new VM build is not feasible, you can evaluate migrating existing VMs using a VM conversion process and add them to a manual pool. This is more applicable to persistent desktops or full clone desktops where you cannot easily replace them with freshly built VMs.

A migration tool (such as Nutanix Move or similar block-level replication tools) can be used to convert the existing VMs. A high-level overview of this process is:

1. Install the target hypervisor’s guest drivers (e.g., VirtIO) while the VM is still on the source platform.
2. Synchronize the data blocks of the VM to the new capacity provider.
3. Perform a cutover, which shuts down the source VM and brings up the target.
4. Critical: Remove the legacy hypervisor tools (e.g., VMware Tools) and perform a clean install of the Horizon Agent.
5. Add the VM to a manual desktop pool.
6. Assign the VM in the pool to the user.

Server farm migration

A server farm cannot span multiple hypervisors or capacity providers. You need to build replacement server farms on the target capacity provider. With server farms, migration follows the same logic as desktop pools with the extra consideration of the Application Pools and RDS Desktop pools that are based on the server farms.

You can optionally use CPA global assignments to assist in transitioning users from using published application pools and RDS desktop pools based on the old server farm to those hosted on the new server farm:

1. Create a new server farm associated with the new capacity provider.
2. Create new Application Pools and/or RDS Desktop Pools using the new server farm.
3. Create CPA global assignments to provide users with an entitlement to both the new and old Applications or RDS Desktop Pools.
4. Disable the old server farm. Users will not be able to launch new sessions using the old server farm but will be able to continue to use existing sessions.
5. To accelerate the transition and drain sessions from the old server farm, set the empty session timeout (Logoff Disconnected Sessions) setting to Immediate.
6. As users log off from an application or RDS-based desktop, they will stop using the old server farm. New user connections will be directed to the new server farm and the servers hosted on the target hypervisor.

App Volumes migration

App Volumes supports two different integration types for machine managers, vCenter and VHD In-Guest Services.

• Integration using vCenter uses applications packaged into VMDK files which are stored on vSphere datastores.
• Using VHD In-Guest Services uses applications packaged as VHD files which can be stored on SMB file shares.

The recommendation going forward is to use VHD In-Guest Services for all deployments as there are technical benefits including:

• VHD packaged applications are more portable, can be used with any hypervisor platform, can be used with App Volumes tools to edit them, and can be scanned on the SMB share.
• Apps on Demand are more performant with VHDs on SMB and are more robust than using vCenter automation since machine reconfigurations are not necessary.

If you are already using App Volumes with VHD In-Guest Services, you can use your existing App Volumes instance and packages with your target capacity provider. The application packages are in VHD format and can be used across any supported hypervisor or capacity provider.

If you have an existing App Volumes deployment that uses a vCenter machine manager, there are some tasks required to use App Volumes and the application packages on alternative hypervisors.

1. Redeploy the App Volumes Manager instance to use VHD In-Guest Services as the machine manager type.
2. Convert existing applications packages from VMDK to VHD format.
3. Entitle users to the applications.

App Volumes Managers

You cannot use a single App Volumes Manager instance to integrate with both a vCenter machine manager and also use VHD In-Guest Services as a machine manager.

If your existing App Volumes Manager instance uses vCenter machine managers, you will have to deploy a new App Volumes Manager instance to use VHD In-Guest Services as the machine manager. Deploy these on Windows Server VMs hosted on the target capacity provider.

If you are already using App Volumes with VHD In-Guest Services, you can continue using the same instance for the target capacity provider. You should migrate or reproduce the App Volumes Managers VMs onto the target capacity provider.

App Volumes Applications

If you are moving from an existing App Volumes instance that used vCenter as the machine manager, the applications will be packages in VMDK files. You can convert existing App Volumes packages from VMDK to VHD format using the App Volumes Tools. For example:

appcapture.exe convert /file "C:\Source\Notepad++.vmdk" /format VHD /output "C:\Converted\"

For more information, see Windows Command-Line Arguments for the App Volumes Application Capture Command-Line Program.

App Volumes also has a standalone executable which automates the conversion of App Volumes VMDK application packages to the VHD format. For more information, see Automate VMDK to VHD Conversion for App Volumes Packages.

Application VHD files should be placed on high-performance SMB shares (such as Nutanix Files or Windows Scale-Out File Server) that are physically close to the desktop pools or server farms they will be used in.

Dynamic Environment Manager

Dynamic Environment Manager is hypervisor-agnostic. No changes are required to the DEM configuration itself. However, ensure that the SMB file shares hosting the user profiles and config files are migrated to a storage tier that matches the performance of the new hypervisor to prevent login delays.

Summary and additional resources

Changelog

The following updates were made to this guide:

About the author and contributors

• Hilko Lantinga, Staff Architect, Omnissa.
• Graeme Gordon, Senior Staff Architect, Omnissa.

Feedback

Your feedback is valuable. To comment on this paper, contact us at tech_content_feedback@omnissa.com.