This page describes key items that are currently excluded from the self-service migration process for migrating first-generation Horizon Cloud on Microsoft Azure deployments to a Horizon Cloud Service - next-gen tenant. This page also describes some special cases of first-generation deployments.

Note:

This content is a living document. This information is updated as additional support becomes available.

Current Key Exclusions

Important: This content will not cite every possible exclusion. The items here are the large characteristics that are currently excluded from the migration process.
Included

As of this writing, the self-service migration process supports migrating a Horizon Cloud on Microsoft Azure deployment where it is the sole pod in your first-gen Horizon Cloud tenant's pod fleet and any external gateway configurations on that pod are deployed using the same Microsoft Azure subscription.

Note: The migration of the end-user desktop preferences set in the Horizon Client for each desktop is currently unsupported. To get their desired preferences after the migration, your end users can set those preferences again in their clients.
Excluded
  • Tenants with multiple Horizon Cloud on Microsoft Azure pods in their pod fleet.
  • External gateway configurations on the pod are in their own subscription, separate from the pod-manager instances
  • Pod has an internal gateway configuration
  • Pod where the management subnet CIDR is /27. At this time, a pod with a management subnet CIDR of /27 cannot be migrated to next-gen.
  • Pod where its subnets' IP address ranges conflict with or overlap with the virtual IP ranges that are required by the next-gen Horizon Edge. These IP ranges are listed in the section Virtual IP Ranges Required For next-gen's Horizon Edge in this migration documentation.
  • Pod configured with proxy
  • Tenant's pod fleet includes both pod types - Horizon Cloud on Microsoft Azure pods and Horizon 7 or Horizon 8 pods.

  • Tenant is configured for single-pod brokering and Workspace ONE Access is integrated with that tenant and its pods

  • Tenant is configured with Universal Broker and integrated with Workspace ONE Access and Intelligent Hub Services.
  • Situations that have a requirement for end users or their clients to use PCoIP with the Horizon Cloud on Microsoft Azure deployment.
    Note: The automated self-service migration cannot detect if you have end users that want or require PCoIP. You and your VDI admins must verify whether this situation applies to your end users.
  • Pods that have dedicated desktop pools in which multiple users are assigned to the same desktop.
  • Migration of historical Cloud Monitoring System (CMS) data is unsupported. If you require that historical data, VMware recommends that you export the reports prior to starting the self-service migration process.

Does Your First-Gen Deployment Make Use of Features Selectively Provided to You or Enabled by VMware Horizon Cloud Operations Team?

Some features might have been selectively enabled for your first-gen deployment by the VMware Horizon Cloud Operations Team. Some items might have been provided for your use under special conditions, such as private APIs.

Review in your team if your deployment involves any of these items.

  • Have you requested enablement for any features that the first-generation documentation states are available when your tenant is explicitly enabled for use of such features on a per-request basis? Examples of such features are use of LDAPS when registering the Active Directory domain, moving individual VMs between assignments in the same pod, narrow scope permissions to desktop assignments and farms for the built-in predefined roles. If the answer is yes, please file a support request to reach out to the VMware Horizon Cloud team for guidance.
  • Have you developed scripts relying on APIs that VMware provided for your use with the first-gen control plane? Those scripts or tools will need to be re-written using the next-gen control plane's APIs. See the Horizon Cloud Service - next-gen API documentation for those APIs.
  • Has your team or the VMware Horizon Cloud Operations team on your behalf configured specific features or properties in the deployment's Unified Access Gateway configuration? Examples of such configurations are syslog, advanced RADIUS options, custom routing on the management or tenant subnets, changed default MTU sizes on the Unified Access Gateway instances. If the answer is yes, please file a support request to reach out to the VMware Horizon Cloud team for guidance.
  • Has the VMware Horizon Cloud Operations team on your behalf configured specific properties related to the deployment's pod-manager instances? Examples of such configurations are changing the default user cache thread timeout value, disabling the Domain Join account permission validation. If the answer is yes, please file a support request to reach out to the VMware Horizon Cloud team for guidance.
  • Are there other items that the VMware Horizon Cloud Operations team has configured for your deployment that are not described in the first-generation documentation as generally available or per-request features? If the answer is yes, please file a support request to reach out to the VMware Horizon Cloud team for guidance.