Before you start the migration workflow UI, you must work with your IT team to ensure the requirements of a Horizon Edge deployment are fulfilled in the same Microsoft Azure environment where the first-gen deployment is located.

The self-service migration is designed to create the next-gen deployment using the same Microsoft Azure subscription, VNet and subnets that are used for the first-generation pod being migrated.

This design means that the same Microsoft Azure subscription and networking environment in use by the to-be-migrated first-gen pod must accommodate the next-gen requirements — such as allowing connections to specific endpoint URLs and ports through your firewalls, specific permissions in the service principal's role, internal network ranges for the Horizon Edge Gateway's AKS cluster, and so on.

  • For the endpoint URLs and ports information, see the following pages in the Horizon Cloud Service - next-gen documentation:
  • Each image is duplicated and migrated to next-gen. So you must have twice the amount of vCPUs per image in the family.

    For example, to migrate an image with Standard_DS2_v2 with 2 vCPU cores, two additional vCPU cores are required during migration, Hence, the Azure subscription must have at least 4 vCPU cores of the Standard DSv2 family on the corresponding region. However, since the images are migrated in batches of 20, this excess quota need not exceed 20 times the number of vCPU cores per image. In other words, you need your existing quota plus an excess quota of 20 times the image vCPU, not just a quota of 20 times the image vCPU.

  • During migration, you must provide the certificate for United Access Gateway deployment and the common name or FQDN in the certificate must match the FQDN provided for UAG deployment.
  • You may need to adjust your routing for internal access to desktops.
  • Read on for the other IT-related requirements.

Overview of Items Reused and Required New

Used from the existing first-gen deployment

In the migration process, these same first-gen deployment entities are also used for the next-gen deployment.

  • Microsoft Azure subscription ID, directory ID, service principal application ID and secret key.
  • VNet
  • Management subnet, tenant subnet, DMZ subnet
    Important: If the pod's management subnet CIDR is /27, the migration process cannot reuse that management subnet for the next-gen Horizon Edge Gateway. The Horizon Edge Gateway requires a management subnet CIDR of /26.

    If your pod's management subnet CIDR is /27, you must create a new management subnet of /26 or higher in the pod's same VNet. Then in the migration UI, you will select that new subnet for the system to use for the Horizon Edge's management subnet.

    When you create that new management subnet, you must ensure that the network connectivity for the newly created management subnet is equivalent to the network connectivity of the pod's existing management subnet, including:

    • That new subnet is in the same VNet as the pod's existing management subnet.
    • That new subnet must have the Microsoft.Sql service enabled as a service endpoint (as described in this first-gen documentation page about using existing subnets page of requirements)
    • You must ensure DNS is correctly configured and accessible for the new subnet equivalent as it is configured for the first-gen pod's existing management subnet.
    • You must ensure your firewalls or NSGs allow communication from the new subnet to the same Active Directory Domain Controllers as the first-gen pod is using, with equivalent connectivity as you have for the first-gen pod's existing management subnet. When the system creates the next-gen resources on the new subnet in the migration's pre-build phase, those resources need to be able to communicate with those Active Directory Domain Controllers.

    Also, the new management subnet must adhere to the same requirements described in this page, such as having either a NAT gateway or user-defined routes, no conflicts with the Horizon Edge's required virtual IP ranges, and the other requirements detailed below.

Remember:
  • As described in this first-gen documentation page about using existing subnets, the pod's management subnet should have the Microsoft.Sql service enabled as a service endpoint. Ensure that endpoint is configured on the pod's management subnet because this endpoint is also a next-gen requirement.
  • Verify that the first-gen pod's subnets' IP address ranges do not conflict with or overlap with the virtual IP ranges that are required by the next-gen Horizon Edge. As stated in Important Considerations For Exclusions and Special Case Scenarios, self-service migration of pods with subnets that conflict or overlap with those ranges is unsupported at this time.
Additionally required for the next-gen's Horizon Edge deployment
A Horizon Edge deployment consists of a minimum of one Horizon Edge Gateway and two Unified Access Gateway instances.
  • Additional Azure resource providers that must be registered in the subscription (in addition to the ones that should already be in place for the existing first-generation deployment): Microsoft.ContainerService
  • Additional permissions needed in the service principal's role: if your first-generation deployment's service principal uses a custom role, ensure that custom role includes the permissions required for the next-gen's Horizon Edge deployment. Compare the role's configured permissions with the Horizon Cloud Service next-gen required custom role permissions.
  • Microsoft Azure user-assigned managed identity. This identity must be created in the first-generation pod's Microsoft Azure subscription prior to the self-service migration. The Horizon Edge requires this item. See this page's next section User-Assigned Managed Identity.
  • Additional capacity (quota) in the subscription for 4 Standard_D2s_v3 VMs (for the Horizon Edge Gateway machines) and 2 Standard_F8s_v2 VMs (for the Unified Access Gateway machines)
  • Either a NAT gateway or user-defined routes for the Horizon Edge Gateway's AKS cluster's outbound connectivity. This item must be created in the first-generation pod's Microsoft Azure subscription prior to the self-service migration. The migration workflow UI requires selection of a cluster outbound type, either NAT gateway or user-defined routes.
    • If you want to use a NAT gateway for the AKS cluster outbound type, configure a NAT gateway on the first-gen pod's management subnet. As per the Microsoft Azure documentation, creation of a NAT gateway requires either a public IP address or a public IP prefix or both.
    • If you want to use user-defined routes for the AKS cluster outbound type, configure a route table on the management subnet. Have the default route 0.0.0.0/0 pointing to a next hop of type VirtualAppliance or VirtualNetwork Gateway.
  • Public IP capacity, so that have the self-service migration create an additional public IP for the load balancer connected to the Horizon Edge's Unified Access Gateway instances.

User-Assigned Managed Identity - For next-gen's Horizon Edge

Before starting the migration workflow UI, you or your IT team must have a user-assigned managed identity in the Microsoft Azure subscription in which your deployed Horizon Cloud pod-manager instances reside.

You or your IT team can create and configure this identity using the Azure Portal. In the Microsoft Azure documentation, refer to its Create a user-assigned managed identity section.

This user-assigned managed identity must be configured with the following characteristics:

  • Network Contributor role at the scope of the VNet's resource group, the VNet in which the pod-manager instances currently reside.

  • Managed Identity Operator role at the scope of the Microsoft Azure subscription, the subscription in which the pod-manager instances currently reside.

The reason why this managed identity is needed is because in the migration workflow, the system deploys a Horizon Edge. The next-gen architecture uses a Horizon Edge. By its design, the Horizon Edge uses an Azure Kubernetes Service (AKS) cluster. According to the Azure environment design, an AKS cluster requires an identity to access Azure resources. Therefore, this identity is needed for the migration workflow to deploy the Horizon Edge that is used by the next-gen architecture.

Reserve Virtual IP Ranges Required For next-gen's Horizon Edge

The migration workflow UI will require you to input two CIDRs in fields named Service CIDR and Pod CIDR.

These are virtual IP ranges that must be reserved for the Horizon Edge Gateway's use.

  • You need to reserve the IP space in your IPAM (IP address management) for these two CIDRs (/27 for Service CIDR and /21 for Pod CIDR)
  • You do not have to create subnets with this range.

These virtual IP ranges will live inside the Horizon Edge Gateway's AKS cluster. By design, Kubernetes creates virtual networks with the cluster to host the containers that run inside it.

Even though these virtual networks are not actually on the management network, they do connect to the management network (management subnet).

As a result, these CIDRs cannot overlap with any other networks within your network, because that would affect routing to these AKS-cluster-internal networks from services that run outside the AKS cluster. For example, the Horizon Agents in VDI desktops need to send data to services running in this AKS cluster.

Also, these CIDRs must not overlap or otherwise collide with each other.

Important: Per the Azure documentation, these CIDRs must not use the following ranges:
  • 169.254.0.0/16
  • 172.30.0.0./16
  • 172.31.0.0/16
  • 192.0.2.0/24
Service CIDR
Decide on the IP range to be used for the Horizon Edge's AKS cluster's service CIDR. Addresses from this virtual IP range will be assigned to the services running inside the AKS cluster. A minimum of /27 range is required.

Reserve the IP space in your IPAM. As stated above, this is a virtual IP range and you do not have to create a subnet with this range.

Because the AKS cluster's virtual network will connect to the management network, you must ensure that IP addresses in this CIDR range are not already in use in that network by other machines or items.

Ensure this CIDR range does not conflict with other key IP addresses in the network, such as the DNS server IP, AD server IP, or IPs used by the first-generation deployment's Unified Access Gateway instances connected to the management subnet.

Pod CIDR
Decide on the IP range to be used for the Horizon Edge's AKS cluster's pod CIDR. Addresses from this virtual IP range will be assigned to the services running inside the AKS cluster. A minimum of /21 range is required.

The /21 range size is required because it is related to the number of nodes the AKS cluster will have. Each cluster node gets pre-allocated with 256 IP addresses from this range.

Reserve the IP space in your IPAM. As stated above, this is a virtual IP range and you do not have to create a subnet with this range.

Because the AKS cluster's virtual network will connect to the management network, you must ensure that IP addresses in this CIDR range are not already in use in that network by other machines or items.

Ensure this CIDR range does not conflict with other key IP addresses in the network, such as the DNS server IP, AD server IP, or IPs used by the first-generation deployment's Unified Access Gateway instances connected to the management subnet.