Self-Service Migration of First-Generation Horizon Cloud on Microsoft Azure Deployments to Horizon Cloud

When your Horizon Cloud environment is enabled for you, you can initiate self-service migration of a Horizon Cloud on Microsoft Azure deployment located in the first generation Horizon Cloud control plane to Horizon Cloud.

Note: At the time of this writing, first-gen environments where the pod fleet consists entirely of Horizon 8 pods, the Connection Server type of pods, are not included in this self-service migration process or in this accompanying migration guide. Their migration process is different from Horizon Cloud on Microsoft Azure pods. To obtain information about migrating Horizon 8 pods, please reach out to your Horizon 8 representative.

Where to Begin

Choose one of the links below to read, depending on how much of the migration process you have completed on your own or with the Horizon Migration team.

Attention: Self-service migration for on Microsoft Azure pods is a progressive rollout, done in waves by the Horizon Migration team. When eligible, you'll receive direct communication from Horizon Migration Communications.

• What if I don't have an email from Horizon Migration Team?

  Review the current eligibility criteria at Exclusions and Special Case Scenarios for Migration. Eligibility for enablement is based on specific factors. These factors evolve over time, making for a progressive rollout.

Checkbox	When...	Do next
☐	You've received an email from the Horizon Migration team about migration to Horizon Cloud, but... Haven't had an introduction to the process. Haven't done initial onboarding to Horizon Cloud.	Do: Fulfill the prerequisites described in this guide Do: Confirm with the migration team that your Horizon Cloud environment is ready for your initial onboarding and complete those initial onboarding steps
☐	After you've done initial onboarding to Horizon Cloud and you see the Migration UI, but... Haven't configured the identity provider for Horizon Cloud. Haven't paired your first-gen tenant with Horizon Cloud.	Do: Configure the identity provider. Do: Pair tenants.
☐	After configuring the identity provider and pairing, but... Haven't scheduled the maintenance window for a pod yet.	Do: Schedule maintenance window.
☐	After the maintenance window is scheduled, but before that date arrives.	Review: See the information about what happens during the pre-build phase. Do: Configure DNS records when you see that the new Unified Access Gateway instances are listed in the Horizon Cloud UI. Do: Use the pre-built test pools to pre-validate behavior. For each first-gen floating desktop pool, the system creates a test pool of one desktop in the Horizon Edge which mirrors the pool's configuration settings from its first-gen counterpart. You can use these test pools to pre-validate that each floating desktop pool will behave in line with your expectations.
☐	Just prior to the migration maintenance time until the maintenance period is over.	Review: See the information about what happens during the maintenance window.
☐	Right after the maintenance period.	Do: Perform post-migration activities
☐	After performing the post-migration activities.	Do: Finalize that migration. Do: Verify the private endpoint configuration for the App Volumes applications storage account, and configure if needed. If you have additional pods, plan for migrating the next pod.

Note: The terms Horizon Cloud on Microsoft Azure deployments and Horizon Cloud refer to the first generation of and that generation's cloud control plane. Other terms, such as v1 and first-gen, refer to the first generation of . The next generation of the service and control plane has the official name Horizon Cloud.

Browser Experience

The Horizon Universal Console is compatible with the most recent version (N) and N-1 and N-2 versions of Google Chrome, Mozilla Firefox, Microsoft Edge, and Apple Safari. The migration activities that are performed using the Horizon Universal Console are supported using those browser versions.

For migration activities that are performed in the first-gen Horizon Universal Console, such as obtaining the pairing key, use the browser versions that are compatible with the first-gen Horizon Universal Console, as described in the First-Gen Deployment Guide.

Phase 1 - Initial Onboarding to Horizon Cloud Environment

In this phase, you complete the initial onboarding steps in the Horizon Cloud environment. Those steps are almost the same as the steps when doing a brand new, greenfield deployment in the Horizon Cloud environment.

Note: If you have previously onboarded to your Horizon Cloud environment, you can skip this phase. When initial onboarding is complete, whenever you log in to the Horizon Cloud console, if the Migration page is not immediately displayed, you can click on the console's Migration entry in the left-hand navigation to display the page.

Perform the onboarding steps described in the page Onboarding for Horizon Cloud, through the step of selecting your Horizon Cloud region.

Organization Selection

At the onboarding workflow step where the UI flow asks you to select an existing organization or create a new one, specify the organization you decided on by following the guidance as described in Determine the Cloud Services Organization to Use.

Cloud Region Selection

After the organization, the region-selection UI appears.

Important: Once you select and save a region in this step, it cannot be changed later.

If you want to ensure that your control plane metadata remains in the same geographic region as was used for your first-gen tenant, then select the same geographic region that corresponds to your first-gen tenant's region.

The following screenshot illustrates the region-selection step with United States selected.

You can match your Horizon Cloud region selection to the region that you used for your first-gen tenant. Doing so provides a way to identify which first-gen control plane region you're using.

To match your Horizon Cloud region selection to the region that you used for your first-gen tenant, log in to the first-gen Horizon Universal Console, and after completing the authentication flow as described in Authentication to a Horizon Cloud Environment, examine the regional DNS name that appears in the browser's address field.

Note: This table is intended to list the supported first-gen regions and their Horizon Cloud counterparts. Over time, Horizon Cloud might support additional regions. Such regions will not be added to this table, because they would not have a first-gen counterpart.

First-gen Regional Name Begins With	Matching Horizon Cloud Region Selection
cloud.horizon. or cloud-us-2.horizon.	United States
cloud-eu-central-1.horizon. or cloud-eu-2.horizon.	Ireland
cloud-ap-southeast-2.horizon. or cloud-ap-2.horizon.	Australia
cloud-jp.horizon.	Japan
cloud-uk.horizon.	United Kingdom

After Region Selection

After you save in the preceding step, the console typically displays the Migration screen.

Note: If the Migration screen is not displayed, you can navigate to it by using Migration in the left navigation.

Next Steps

Follow the on-screen guidance. Complete the documented migration prerequisites and complete the pairing process.

Phase 2 - Pair Environments to Enable Migration Between Your Horizon Cloud and First-Gen Environments

To enable migration of a Horizon Cloud on Microsoft Azure deployment to your Horizon Cloud environment, you must pair your first-generation environment with your Horizon Cloud environment.

Note: To perform the steps in the Horizon Universal Console, you must have the Administrator role in the Horizon Cloud environment. Refer to the page Assigning Administrative Roles in the Horizon Cloud using guide.

Remember: Currently the console provides the migration banner, the Horizon Cloud Migration wizard, the Migration menu and the Migration page only when your first-gen deployments are made eligible for migration by the Horizon Migration Team.

About This Pairing Code

A pairing code is the system's way of associating your Horizon Cloud environment with your first-generation environment for the purposes of migrating your first-gen deployments.

You obtain a pairing code from your first-gen environment, copy that pairing code, and paste it into the migration panel in your Horizon Cloud environment.

Pairing Steps

Each time you generate the pairing code using the console, the code is valid for 30 minutes. If you do not complete Step 9 before 30 minutes has elapsed, simply repeat Step 5 to generate a new one to copy and paste in Step 9.

If you choose to view both consoles at the same time, a best practice is to use browser windows in private mode or incognito mode to avoid UI issues that might result from the browser cache of images or other cached page content.

1. Obtain the pairing code using one of these methods.

   • If your console displays the migration banner, you can click the banner's LET'S GO to start the Horizon Cloud Migration wizard and select Yes on the Get Started step to display the pairing code as depicted in the following screenshot.

     Note: The first-gen console displays this banner and wizard only when the Horizon Migration Team has enabled them in your first-gen environment.

     

   • Click your account name displayed in the console and select Pairing Code.

     

2. Copy the pairing code. The following screenshot illustrates the code redacted for privacy.

   

   This pairing code is valid for 30 minutes.

   If the code expires, the console has a refresh action for you to generate a new one.

3. Go to the Migration page in your Horizon Cloud environment.

   • From the Migration - Get Started wizard, you can click Start to launch the Horizon Cloud console displaying the Migration page.

   • Alternatively, you can open a browser window, log in to Cloud services, navigate into the Workspace ONE Cloud tile, locate the card within your set services, and then click the action to open the Horizon Cloud console from there. Then navigate to the Migration page using the using the left hand navigation menu's Migration entry.

     

     The following screenshot illustrates the console's Migration page.

   

4. Click the Pair Tenants link.

5. In the Pair Tenants window that appears, paste your copied pairing code into the Pairing Code field.

   The following screenshot illustrates this step. The pasted code is redacted here for privacy.

   

6. Click Pair.

   When the system has successfully paired the tenants, the Horizon Cloud UI indicates that pairing is successful.

   

Next Steps

Now that your first-gen tenant and Horizon Cloud tenant are paired, follow the on-screen guidance and connect an identity provider.

Phase 3 - Configure the Required Identity Provider Settings in Your Horizon Cloud Environment

In this phase of the migration workflow, you must input settings for an external identity provider. These settings register the identity provider for use with the Horizon Cloud environment.

Brief Introduction

The Horizon Cloud environment by design relies on having an external identity provider to provide the authentication required when end users attempt to access their entitled resources.

The Horizon Cloud architecture's use of an external identity provider allows for integration with third-party products and solutions to provide multi-factor authentication and SSO capabilities.

Attention:

Before registering the identity provider, verify that the to-be-migrated pod's AD domain is connected to your identity provider – the one that you'll specify for this Horizon Cloud environment.

Preparations

Ensure that your identity provider is set up and is connected to your AD domain as described in the page Setting Up Your Identity Provider located in the Horizon Cloud guide.

The Horizon Cloud tenant console UI requires input of an auxiliary domain join account. This is a difference from the first-gen tenant console, where the auxiliary domain join account was optional. Ensure that you have the name of an auxiliary domain join account before starting the domain registration steps in the UI.

Create the Identity Provider Connection

In the console for your Horizon Cloud tenant, navigate to the console's Identity Provider UI tab by clicking Connect in the Migration page.

Complete the console's Identity Provider flow to connect the Horizon Cloud tenant to an identity provider.

For the specific guidance about this Identity Provider UI, see the page Connecting Your Identity Provider located in the Horizon Cloud guide.

The following screenshot illustrates the completed state, where the identity provider is successfully connected (some values redacted for privacy).

Next Steps

In the Horizon Cloud console, navigate to the Migration page.

Now that the identity provider is connected, the console makes available the Start button, and you can click it to begin scheduling the automated migration.

Phase 4 - Schedule a Pod's Migration Maintenance Window

In this phase, you select the to-be-migrated pod, specify the details required for the system's build-out of the Horizon Edge, and reserve a calendar slot in which you want the migration maintenance window to take place.

This calendar slot is the maintenance window.

During the maintenance window you and other administrators cannot access the Horizon Universal Console of your first-gen tenant and your end users cannot access their desktops and applications that are provisioned by the migrating pod.

Before Beginning These Steps

Before starting this workflow in the console, make sure the following items are in place.

☐	All the prerequisites are in place
☐	You have determined which Horizon Edge Gateway deployment type - Single VM or AKS - to use: Decide on Your Deployment Type and Fulfill Its Requirements.
☐	In addition to the main prerequisites, you have fulfilled the prerequisites of your chosen Horizon Edge Gateway deployment type: Single VM type prerequisites AKS type prerequisites
☐	You have completed the steps in Phase 3 - Configure the Required Identity Provider Settings in Your Horizon Cloud Environment.
☐	Ensure that Azure policies related to tags and resource group creation, are lifted (turned off) and remain off until you see that the Horizon Edge Gateway and Unified Access Gateway instances are successfully deployed in the pod's subscription. The deployment activity starts after you complete the scheduling wizard. When successfully deployed, notification messages will appear in the Horizon Universal Console.
☐	As described in the prerequisites page, ensure that all of the first-gen pod's images are in a Published state and their VMs and snapshots are intact in Microsoft Azure.

Important: If a prerequisite is missing, the system's pre-validation checks will fail and the system cannot enter its pre-build phase, which will block the migration process.

The scheduling wizard's UI requires you to either select or input values for the following items.

Ensure you have this information and items in place before starting the wizard. These items are all described in the prerequisites pages.

☐	New Unified Access Gateway items: FQDN you'll enter into the wizard UI SSL certificate for the Unified Access Gateway configuration (PEM or PFX format) that matches the FQDN. Important: Ensure that the certificate's common name or FQDN precisely matches the FQDN that you plan to enter in the wizard. The wizard's validates the data within the certificate with the typed-in FQDN. If there is no match, the system will prevent the migration from being scheduled and you'll have to cancel out of the scheduling wizard. If the first-gen pod has both an external Unified Access Gateway configuration and internal Unified Access Gateway configuration, the post-migration Edge's Unified Access Gateway will have both its external FQDN and internal FQDN set to the same FQDN by default (the FQDN that you enter into the wizard here). When you want the internal FQDN to be unique from the external FQDN, then after the migration, you edit the Edge's Unified Access Gateway details to change its internal FQDN to that separate one, and specify network ranges to identify internal users. Note: If you plan to set the internal FQDN to be unique from the external FQDN, ensure that the SSL certificate you provide in this scheduling wizard reflects your planned internal FQDN in the certificate's data. Otherwise, a certificate that reflects both FQDNs will be needed at the time you edit the Edge's details to specify a unique internal FQDN. Currently the UI takes a single certificate.
☐ If using the AKS deployment type	For the AKS type, the wizard asks for: NAT gateway or route table associated with the management subnet, used for the Horizon Edge's AKS cluster outbound connections User-assigned managed identity The CIDRs to use for the Horizon Edge's AKS cluster (service CIDR, pod CIDR) Note: If you had to create a new VNet and management subnet for use with the AKS type to work around the AKS-restricted IP addresses, ensure you know their names so that you can identity and select them in the wizard UI.
☐ If using the Single VM deployment type	For the Single VM type, the wizard doesn't have any required input specific to the Single VM deployment type. In the rare case where your network has something like an Active Directory server already provisioned on a network segment that overlaps some system defaults, you'll want to specify custom values to replace the system-set defaults. For more details, see the section Single VM Deployment Type.
☐ If the pod's external gateway is using a private IP address	If the first-gen pod's external gateway deployment is configured to use a private IP address, have the new public IP address to use for the Horizon Cloud Unified Access Gateway deployment, as described in Prerequisites for Migrating a First-Gen Horizon Cloud Pod.. The wizard asks for that information.

Some Site-Related Points - Universal Broker Environments

Please keep these points in mind when you have a first-gen Universal Broker environment with multiple Horizon Cloud pods.

As described in the first-gen Administration Guide page Working with Sites in a Universal Broker Environment, when your first-gen tenant is using Universal Broker, you can configure sites and home sites.

• The system migrates the site configurations that exist in the first-gen tenant during the first pod migration. An example of site-related information is the mapping of a user to a home site.
• When you finalize that first pod's migration and then subsequently make changes to the site-related information in the first-gen environment, those changes will not become visible in the Horizon Cloud environment until the next pod migration.
• Any existing site-to-user and site-to-group mappings in the Horizon Cloud environment are the source of truth when a pod is migrated. If a user or group home site mapping for a user or group exists both in the Horizon Cloud environment and in the first-gen environment, the migration process ignores the first-gen site mapping. This information is included in the migration report.
• After each pod's migration, if you had any home site mappings, review the home site mappings in the Horizon Cloud environment and update as needed for your organizational needs.

When You Have Assignments Involving Multiple Pods

You might have first-gen assignments that involve multiple pods (the first-gen documentation uses the term multi-cloud assignments for such assignments). There are key things to be aware of when migrating pods that are involved in multi-cloud assignments. See When You Have Multiple Pods in First-Gen Assignments - Key Points.

Schedule Migration Workflow UI

Click Start on the Migration page to see the Schedule Migration workflow.

The console displays the set of first-gen Horizon Cloud on Microsoft Azure deployments that are in the pod fleet of the first-gen tenant paired with this Horizon Cloud tenant.

The system automatically validates that a first-gen deployment is compatible with the self-service migration. This criteria includes validating that pod manager instances are running an appropriate manifest version, the images, VDI desktop and farm VMs have the appropriate Horizon Agent versions, and that features used in the first-gen deployment are also compatible with the self-service migration's current abilities.

For each first-gen deployment, the console indicates whether the deployment meets the system's criteria for its automated migration. If the criteria are met, the UI indicates Ready to migrate.

If the deployment does not meet the criteria, you can click on the status column to display a window which describes the issues. After you address those items, you can use the Rescan action to rerun the system check of the first-gen deployment. For examples of the criteria the deployments must meet, see Exclusions and Special Case Scenarios for Migration.

Note: When you use the Rescan action, the page does not automatically refresh. You must click Refresh to see the latest status.

Select First-Gen Pod

When UI indicates the pod you want to migrate is ready to migrate, select the pod and click Next.

If you have multiple pods in your first-gen environment with a combination of internal-only gateways and external gateways, migrate the pods with external ones first.

After selecting a pod, click Next to proceed.

Horizon Edge - Add New, Select Existing

When you click Next, the system analyzes what is available in the Horizon Cloud environment for a Horizon Edge to represent the post-migration pod.

The wizard displays buttons:

• Add New
• Select existing

A grayed-out button means it cannot be used for this migration and the system-selected one must be used. A banner will display the reason.

If neither are grayed-out, and one is selected by default, this means the system recommends using the pre-selected one and you can override the system's recommendation and choose the other one for this migration.

The following sections briefly describe the purposes of Add New and Select existing in the Schedule Migration flow.

Button - Select Existing

When Select existing is selected, the wizard displays a list of the environment's existing Horizon Edges. Select the Horizon Edge to use for this migration and click Next. Proceed to Step 3 - scheduling the migration time period.

When using an existing Horizon Edge, the system scales the existing Unified Access Gateway deployment with the same number of Unified Access Gateway instances that are associated with the first-gen pod. The maximum limit of this scale is eight (8) Unified Access Gateway instances. When that limit is reached in the selected Horizon Edge, the Unified Access Gateway deployment won't be increased.

Also, about the following use cases:

• First-gen pod has the same subscription, same Microsoft Azure region, different app ID (service principal) than the selected Horizon Edge: The system scales the selected Horizon Edge's provider by adding the first-gen pod's app ID to that provider.
• First-gen pod has a different subscription, same Microsoft Azure region, different app ID (service principal) than the selected Horizon Edge has: The system adds a secondary provider to the selected Horizon Edge.

Button - Add New

When Add New is selected, the system will create a new Horizon Edge for this first-gen pod's migration.

In this case, the wizard requires you to complete the displayed options and fields for configuring the new Horizon Edge.

UI Fields	Description
Horizon Edge Name	Specify a name that will uniquely identify this Horizon Edge within your Horizon Cloud tenant. The name must start with a letter [a-Z], and contain only letters, dashes (-), and numbers.
Deployment Type	Click the choice that corresponds to the deployment type you decided to use for the Horizon Edge Gateway. Single Virtual Machine is the default. Single Virtual Machine - Deploys the Single VM type. Azure Kubernetes Service- Deploys the AKS type.

See the section below that corresponds to your chosen Deployment Type.

Single Virtual Machine Deployment Type

For the Single Virtual Machine deployment, there are no required fields, except for the rare scenario described in the following Note. The deployment uses the pod's management subnet for the Horizon Edge Gateway.

Note: A rare scenario is when you have something like an Active Directory server already provisioned on a network segment that has IP address space that overlaps system defaults. In this rare case, networking issues can happen as the Edge Gateway modules attempt to reach out to Active Directory. To prevent such conflicts, the wizard's Advanced section provides fields for you to specify custom values and avoid conflicts with the system-default internal network ranges. For more details, see Optional Advanced Settings.

Next is the Unified Access Gateway information.

Azure Kubernetes Service Deployment Type

Complete the fields. These are all required. The UI validates these all have entries before it will enable the Next button.

UI Fields	Description
Cluster outbound type	Two choices - NAT gateway or User defined routes. Select the choice that matches what your or your IT team decided to set up in Azure to meet this requirement, as described in section 'AKS Type - Configure Either a NAT Gateway or a Route Table and Associate to Management Subnet'.
User Assigned Managed Identity	Select the user-assigned managed identity that you or your IT team has set up in Azure to meet this requirement, as described in section 'AKS Type - Create User-Assigned Managed Identity'
Virtual Network and Management Subnet	If you see both of these fields, make the selections according to what you prepared to handle the prerequsites. These fields are displayed when the system's checks determine that the VNet overlaps the AKS-restricted IP ranges as described in 'Determine Whether the Pod's VNet or Connected Networks Contain AKS-Restricted IP Addresses'. Select the new VNet and management subnet in that VNet.
Service CIDR	Input the CIDR that you or your IT team decided on to meet the AKS service CIDR requirement, as described in section 'AKS Type - Reserve Required Virtual IP Ranges'.
Pod CIDR	Input the CIDR that you or your IT team decided on to meet the AKS pod CIDR requirement, as described in section 'AKS Type - Reserve Required Virtual IP Ranges'.

Unified Access Gateway Information

UI Fields	Description
Unified Access Gateway FQDN	Type the FQDN for the Unified Access Gateway that you or your IT team decided to use for this deployment. The Horizon Agents in the virtual desktops and apps will connect to this FQDN. If the first-gen pod has both an external Unified Access Gateway configuration and internal Unified Access Gateway configuration with different FQDNs and certificates configured on those gateway configurations, the post-migration Edge's Unified Access Gateway will have both its external FQDN and internal FQDN set to the same FQDN by default (the FQDN that you enter into the wizard here). After the migration, you can edit the Edge's Unified Access Gateway details to change the internal FQDN to one you want used for internal users, and configure network ranges to identify internal users. Note: If you plan to update the internal FQDN to be unique from the external FQDN post-migration, ensure that the certificate you upload reflects both the FQDN that you enter into the wizard and your planned internal FQDN in the certificate's data. Otherwise, post-migration you'll have to upload a certificate that reflects both the external FQDN and internal FQDN.
Certificate Type	Two choices - PEM or PFX. Choose the type that matches the certificate you or your IT team obtained for this deployment, that matches the Unified Access Gateway FQDN. For PFX, an additional Password field displays for you to enter the password for the PFX certificate.
Certificate	Click the button to upload the certificate.
Manual Public IP	This field displays when the system detects the first-gen pod's external gateway deployment is configured to use a private IP address. Enter the public IP address that you want used for the Horizon Cloud deployment, as described in 'Prerequisites for Migrating a First-Gen Horizon Cloud Pod'. Note: This public IP must be different from the public IP already in use for the to-be-migrated first-gen deployment, to support rollback to the first-gen deployment state if rollback is needed. As part of the pre-build activities, the system will deploy the Horizon Cloud Unified Access Gateway deployment's load balancer with a private IP address. After the load balancer is deployed and its private IP address known, you must ensure that you set up the routing so that this public IP directs traffic to the deployed load balancer's private IP.

Optional Advanced Settings - Internal Network Ranges for the Single VM

Within the Single VM, there are system-set defaults used for internal network ranges. These internal networks are used by Kubernetes within the VM and are not accessible outside the VM. They should remain at the system-set defaults unless they overlap with your internal networks. In the rare situation where you have existing network segments overlapping the VM's internal ranges, use the wizard's Advanced section to specify custom values.

Input the CIDRs that you or your IT team decided on to meet the requirement in this special case, as described in Single VM Deployment Requirements.

• Service CIDR - A minimum of /27 is required.
• Pod CIDR - A minimum of /21 is required.

When all wizard required fields have entries

When all of the fields have entries, click the Next button to move to the next step.

Step 3 - Schedule Migration Time Period

In this step, you select a time period for the migration's maintenance window.

During the selected time period:

• Do not make any changes to the first-gen pod, its resources, settings, etc.
• Do not make any changes to the Horizon Cloud environment's deployment.
• The system will prevent access to the Horizon Universal Console.
• Your end users cannot access their desktops and applications that are provisioned by the migrating pod.
• Refrain from accessing the Horizon Cloud environment during the selected time period, to avoid disrupting the process.

The UI displays a calendar view that depicts those slots that the system makes available for the migration activities.

• The calendar view accurately reflects which days and time slots are available for migrating your selected first-gen pod.
• Generally speaking, the first day available for selection will be a minimum of 7 days in the future.
• You can scroll through this calendar view as needed to find a date and time slot appropriate for your team and organization's needs.
• Each time slot is a 6-hour block.

The following screenshot illustrates the UI calendar used for selecting the migration maintenance time window.

Hovering over one of the time blocks displays a pop-up that shows that slot's time in both your browser's local time and UTC.

The following screenshot illustrates a selected block. The system will begin its activities at this time.

When you have selected one of the time slots, you then click Save to save your choice.

What the System Does Next

After you save your selected time slot, the system will display a message that confirms your selected time window and describes the next steps.

After you click OK in the confirmation message, the system will:

1. Perform its pre-build activities.

   • When using Add New (migration to a new Horizon Edge)

     In this case, the system deploys the Horizon Edge and its associated resources (the Horizon Edge Gateway and Unified Access Gateway instances and associated load balancers).

   • When using Select existing (migration to an existing Horizon Edge)

When using an existing Horizon Edge, the system scales the existing Unified Access Gateway deployment with the same number of Unified Access Gateway instances that are associated with the first-gen pod. The maximum limit of this scale is eight (8) Unified Access Gateway instances. When that limit is reached in the selected Horizon Edge, the Unified Access Gateway deployment won't be increased.

Also, for the following use cases:

• First-gen pod has the same subscription, same Microsoft Azure region, different service principal app ID: The system scales the selected Horizon Edge's provider by adding the first-gen pod's app ID to that provider.
• First-gen pod has a different subscription, same Microsoft Azure region, different service principal app ID: The system adds a secondary provider to the selected Horizon Edge.

2. Copy the published images and App Volumes applications from the first-gen pod to the Horizon Edge.

A deployed Horizon Edge has a load balancer for the Horizon Edge Gateway instance and a load balancer for the Unified Access Gateway instances.

In the Add New use case, when the new Horizon Edge is deployed and you and your IT team can obtain the IP addresses for those load balancers and update your DNS to add a records that map the Unified Access Gateway FQDN load balancer IP address with the Unified Access Gateway FQDN specified in this Schedule Migration wizard. For more details, see Configure Required DNS Records After Deploying Horizon Edge Gateway and Unified Access Gateway in the Horizon Cloud documentation.

Note: If you entered a Manual Public IP, you must ensure you set up the routing needed from that public IP to the deployed load balancer's private IP address.

Clicking OK in the confirmation message returns you to the console's Migration page.

Your Next Steps

Most of your time during the system's pre-build phase is waiting for the system to finish its pre-build activities.

During the pre-build phase, you can use the Migration Status and Report columns in the console's Migration page to check on what is happening.

Tip: When the migration is adding a new Horizon Edge, the Horizon Migration Team recommends that when you see that the Unified Access Gateway instances and load balancer are deployed, you should configure the necessary DNS entries.

Even though these DNS entries can be configured after the maintenance actions are completed, the migrated environment isn't fully functional without the DNS entries that map your specified FQDNs to the underlying IP addresses allocated to these resources. See Phase 6 - Configure DNS Records for the Infrastructure Created in Self-Service Migration Phase 5.

Important: When your first-gen tenant is a Universal Broker environment, avoid making any changes to the site-related configurations for users and groups that are already set in the first-gen tenant.

Migration Page Features

Now that one pod is scheduled for migration, the console's Migration page displays that status and makes available actions for rescheduling (Reschedule) and cancelling (Cancel) the scheduled migration time.

When you select one of those actions, follow the on-screen prompts.

The following screenshot shows the pod selected and the availability of the Reschedule and Cancel actions. The Finalize action in this screenshot is unavailable because this pod is not yet migrated.

Phase 5 - Pre-Build - Automated Actions Prior to Maintenance Window

During this phase, the system automatically performs pre-build migration activities in advance of the specified migration window. This front loading of activities seeks to minimize the amount of time needed in the migration maintenance window.

Brief Introduction

As described in What to Expect, using a pre-build shortens the amount of time it will take the migration to occur during the maintenance window.

For all migrations, the system deploys the required resources during the pre-build phase.

When the migration is using a new Horizon Edge, the system also deploys the resources for the Horizon Edge at the start of the pre-build.

Attention: Because the system creates resources in this pre-build phase, you are likely to see new resources appearing in your Azure subscription and in your Horizon Cloud environment during this time.

Be aware of these points:

• Even though the Horizon Cloud console does not prevent you from creating pools in the Horizon Cloud environment using those resources, we strongly recommend that you avoid creating pools or doing other creation workflow using those new resources until after the overall migration is completed.

  If those resources are used within the Horizon Cloud environment prior to the migration maintenance window, and then you subsequently cancel the migration or use the UI's rollback action, the system cannot return the Horizon Cloud environment to its original starting state. In this scenario, you might need to undertake additional manual actions in the environment to get it to a state where the system is then able to have you re-initiate the migration process.

• During the pre-build, the system first temporarily duplicates each first-gen published image in the first-gen pod's base-vms resource group, and performs agent update and other activities on these duplicates before publishing them in the Horizon Cloud environment. These temporary VMs use the naming convention MIGXXXXXXXXXXXX.

  As the system works with these temporary VMs and until they are published to the Horizon Cloud environment, you will see the MIGXXXXXXXXXXXX images listed on the first-gen console's Imported VMs page.

  It is important that you avoid performing any actions on these temporary VMs, because doing so can cause the migration pre-build phase to fail. For example, do not power off the temporary VMs.

This pre-build will not impact your existing pod or user sessions.

Important: When your first-gen tenant is a Universal Broker environment, avoid making any changes to the site-related configurations for users and groups that are already set in the first-gen tenant.

During the Pre-Build

During the pre-build:

1. If the migration is using a new Horizon Edge instead of an existing one, the system deploys the Horizon Edge, using the inputs you provided in the Schedule Migration UI (Phase 4.)

2. The system takes the first-gen configuration data that is stored at a pod level and in the first-gen control plane, transforms the data to match the Horizon Cloud control plane design, and stores the transformed data appropriately.

3. When this migration is the first one into the Horizon Cloud environment, the system takes the first-gen tenant's Active Directory (AD) domain configurations and creates the equivalent domain configurations in the Horizon Cloud environment.

   In the Horizon Cloud environment, the system registers all of the first-gen tenant's registered domains during the pre-build activities for the first scheduled migration. For subsequent pod migrations from the same first-gen tenant, the system re-verifies that the first-gen tenant configurations are in sync and skips registering domains that already exist in the Horizon Cloud environment.

   Note: The Horizon Cloud environment requires auxiliary accounts for both the domain bind and domain join account in the Horizon Cloud AD domain configurations. If a first-gen tenant's AD domain configuration is missing an auxiliary domain bind account or auxiliary domain join account, the system will automatically re-use the primary account information as the companion auxiliary account in the Horizon Cloud AD domain configuration.

   As a best practice, you should obtain service accounts in your AD domains for these auxiliary domain bind and domain join accounts, and after the pre-build activities, edit the AD domain configurations to add those auxiliary accounts.

4. The system copies the first-gen deployment's published images and App Volumes related files to the Horizon Edge, and configures the copies for use with the Horizon Edge.

5. For each of the following first-gen items, the system creates a test pool in the Horizon Edge.

   • RDSH desktop farms
   • RDSH app server farms
   • Floating desktop assignments (pools) from single-pod broker tenants. (Multi-cloud assignments won't have test pools.) Each test pool contains one machine and mirrors the pool's configuration settings from its first-gen counterpart.

   You can use these test pools to pre-validate that the pool's machines will behave in line with your expectations, before the pool is fully migrated during the maintenance window.

   Note: Because the system rebuilds floating and RDSH pools, if you have licensed third-party solutions in your environment where the license is tied to the identity of the VM more of those licenses might be consumed.

The pre-build activities end at this point. The system starts its next activities at the start of the scheduled maintenance time period. To provide for the event of rollback, the first-gen deployment's published images and App Volumes related files remain in place until when you later confirm the end-to-end migration is completed.

Your Next Steps

After the resources are built in your subscription, please perform the activities described in the following sections.

When migrating to a new Horizon Edge, configure the required DNS entries

At the point when you see that the new Horizon Edge's Unified Access Gateway and Horizon Edge Gateway instances are up and running, you should configure your DNS with records that map the FQDN that you specified in the migration UI to the relevant IP addresses. See Phase 6 - Configure DNS Records for the Infrastructure Created in Self-Service Migration Phase 5.

Typically those instances are up and running within 48 hours of the scheduled migration maintenance window.

Note: If your first-gen pod has both an external Unified Access Gateway configuration and internal Unified Access Gateway configuration, the resulting Edge's Unified Access Gateway will have its access type set to Internal and external access with both the external FQDN and internal FQDN set to the same FQDN by default (the FQDN that you entered into the scheduling wizard). If you want to use a different FQDN for internal access, you edit the Edge's Unified Access Gateway details to change its internal FQDN to the one you want used. Please note that the certificate must include that internal FQDN in the certificate's information.

Pre-validate pool behavior using the test pools

Locate the test pools in the Horizon Universal Console by navigating to Resources > Pools.

Each test pool will have a single machine that you can use to pre-validate the Horizon Cloud experience for that pool.

Note: To pre-validate the test pools created for the first-gen RDSH app server farms, you must explicitly entitle users or groups to those test pools within the Horizon Cloud environment. For the first-gen RDSH app server farms, the pre-build process doesn't replicate the first-gen user or group entitlements on the test pools.

AD domains - auxiliary domain-bind and domain-join accounts

As described in the previous section, if a first-gen tenant's AD domain configuration is missing an auxiliary domain bind account or auxiliary domain join account, the system will automatically re-use the primary account information as the companion auxiliary account in the Horizon Cloud AD domain configuration.

As a best practice, you should obtain service accounts in your AD domains for the auxiliary domain bind and domain join accounts, and after the pre-build activities, edit the AD domain configurations to add those auxiliary accounts. In the Horizon Cloud console, you edit the domains on the Integrations page (Integrations > Manage > Domains).

Phase 6 - Configure DNS Records for the Infrastructure Created in Self-Service Migration Phase 5

In this phase, you or your IT team updates your DNS with records that map the FQDNs that you specified in the Schedule Migration UI to the appropriate IP addresses.

Note: You can skip this step of configuring DNS records when the migration is using an existing Horizon Edge.

Same as for a greenfield Horizon Edge deployment, you are responsible for creating the DNS records. The self-service migration cannot perform that update on your behalf.

Even though the DNS records that map the IP addresses to their FQDNs can be done at a later date, it is a best practice to create those records as soon as the IP addresses are assigned to the instances.

The reason for putting the mapping into place sooner than later is because lack of the records that map your chosen FQDNs to the instances' underlying IP address will prevent your Horizon Cloud environment from being fully functional for the post-migration validation steps.

For the details about which IP addresses need to be mapped to the FQDNs, see the page Configure Required DNS Records After Deploying Horizon Edge Gateway and Unified Access Gateway in the Horizon Cloud documentation.

In the Horizon Universal Console, the FQDNs and relevant load balancer IPs are displayed in the Horizon Edge's details page. You can drill-down to the Horizon Edge's details from the console's Capacity page (Resources > Capacity > Horizon Edges).

Next Steps

When the starting time for the scheduled migration maintenance window arrives, the system begins the remaining migration activities.

Phase 7 - Migration Maintenance Window

At the start time of your scheduled migration window, the system automatically starts its final automated migration steps. During this time, administrator and end-user access is prevented to the administration console and end-user entitled resources in the first-generation tenant.

While the migration is in progress, the console's Migration page displays the status for the migrating pod.

Restricted Activities

During this maintenance window:

• Do not make any changes to the first-gen pod, its resources, settings, and so on.
• Do not make any changes to the Horizon Cloud deployment.
• The system will prevent access to the first-gen Horizon Universal Console.
• Your end users cannot access their desktops and applications that are provisioned by the migrating pod.
• Refrain from accessing the Horizon Cloud environment during the selected time period.

The self-service migration requires the above restrictions because, during this time, the system is actively transferring resources from the first-gen deployment to the Horizon Cloud environment.

The System's Automated Actions

The active operations that occur during this maintenance window include:

• Shrinking the first-gen deployment's floating desktop pools and farms until they no longer use any capacity.

• Correspondingly, expanding floating desktop pools and farms in the Horizon Cloud environment to match the capacity they had in the first-gen deployment.

• Pairing the desktop VMs from the first-gen deployment's dedicated desktop pools with the Horizon Cloud environment.

  Note: The migration actions for dedicated desktops might automatically power on the desktop VMs as needed, even if the time is outside of the dedicated desktop pool's power management schedule. As part of the migration, the Horizon agent in the desktop VMs must unpair from the first-gen deployment and pair with the Horizon Cloud environment, which might require powering on the VMs.

  Also, if you access the Horizon Cloud console during the maintenance window, on the Pools UI, you might see displayed Error status for the migrating dedicated pools. This behavior is expected during the maintenance window.

If the system detects any failure, it automatically attempts to revert the changes made up to that point. For details about the reversal process, see page Rolling Back a Migration.

When the actions are completed successfully and the maintenance window end time is reached, you'll see the pod's Migrating status change on the console's Migration page.

Tip: The system reflects this status because the first-gen pod infrastructure of its pod manager instance and Unified Access Gateway instances still exist until you confirm deletion of the pod.

Special Notes about Dedicated Desktop VMs

At the end of the maintenance window, unless you finalize the migration:

• The monitoring data for dedicated desktop VMs will not be published to Omnissa Intelligence.

• The Horizon Cloud console will prevent you from updating or reinstalling agents for any dedicated desktop pool or dedicated desktop VM.

  The reason for preventing agent updates and agent reinstalls until the migration is finalized is because changes to the agents in the dedicated desktops could cause problems in the event of rollback. If you attempt to roll back the migration from the Horizon Cloud environment to the first-gen deployment state, and the agents were modified in the Horizon Cloud environment, the dedicated desktops might not work properly in the rolled-back first-gen deployment.

To finalize the migration, see Finalize the Migration.

Perform Post-Migration Activities to Confirm Migration Success

When the system completes its actions in the migration maintenance window, all the resources are now within the Horizon Cloud environment and your end users are able to access their desktops and applications.

At this point, the system lifts the restrictions it set for the maintenance window.

• You and your other admins can access the first-gen Horizon Universal Console.
• Your end users can access their desktops and applications, which are now provisioned by the Horizon Cloud environment.

Important: Because the URL or server address used to access end-user resources is different in the Horizon Cloud environment, you must inform your end users of the new address to use in their Horizon Clients and when using Horizon Web Client (the browser). Refer to the page Launch a Desktop in the Horizon Cloud documentation.

Avoid Doing These Activities Until You Have Finalized the Migration

While some activities are allowed prior to finalizing the migration, taking such actions can cause issues.

• Avoid renaming sites that were migrated until you have finalized the migration.

  Do not rename sites prior to finalizing the migration flow. If you roll back the migration from the Horizon Cloud environment back to the first-gen tenant, and the migrated site name was renamed in the Horizon Cloud environment, then when that rolled-back pod is later migrated and that migration ultimately finalized, the Horizon Cloud environment will display both site names: the original first-gen site name, now empty, from the earlier migration and the new site name when it was renamed. If this scenario happens, delete the empty original first-gen site name from the Horizon Cloud environment.

Recommended Activities and Things to Know

To ensure that the Horizon Cloud environment is functional from your organization's business perspective, you and your VDI admins should complete the activities described in the following sections.

The following sections also describe characteristics of the migrated deployment. Review those characteristics for understanding of things you'll see in the Horizon Cloud environment post-migration.

Download and Review Migration Report

Post-migration, download and review the migration report.

The migration report is available from the Reports column on the console's Migration page.

This migration report provides details about the migrated resources and where changes were made in the migration process.

Typical changes include a resource's name change. The migration might change a resource's name if the resource from the first-gen deployment is migrated to a Horizon Cloud environment where the same name is already in use. In such situations, the self-service migration automatically renames those first-gen resources to avoid name clashes.

Confirm End User Experience

Confirm that end users can launch their floating desktops, dedicated desktops, and remote apps according to their entitlements.

Tip: For a video illustration of the end-user experience, see the Tech Zone video located within Log in to a Horizon Cloud Desktop or App as an End User.

The end-user experience of launching desktops and applications in a Horizon Cloud deployment is described in the Using Horizon Cloud guide:

• Browser: Launch a Desktop Using Horizon Web Client and Launch an Application Using Horizon Web Client
• Native Horizon Client: Launch a Desktop with Horizon Client and Launch an Application with Horizon Client.

If you haven't customized the end-user client URL for your Horizon Cloud environment, the default starting address is cloud.omnissahorizon.com. If the client URL or subdomain is customized, use the custom URL. The customization is described in the Horizon Cloud documentation at Configure Branding.

The Horizon Cloud authentication flow is also different from the first-gen one, because in a Horizon Cloud environment, the end users are required to login using the configured identity provider, rather than the Active Directory domain login workflow that is used in the first-gen deployment.

Remember: As described in Exclusions and Special Case Scenarios for Migration, migration of the end-user desktop preferences set in the Horizon Client for each desktop is currently unsupported in this self-service migration. After the migration, your end users can choose to reselect their desired preferences again in their clients if they want to.

Confirm Admin Login Experience

Confirm that admins logging in to the Horizon Cloud console can see the pools and other resources that they expect to see from the migrated first-gen deployment.

Management access to the Horizon Universal Console is through Omnissa Connect (connect.omnissa.com).

1. Log in at https://connect.omnissa.com/ and navigate to My services to locate the Workspace ONE Cloud card.

   

2. Launch that service to see the card displayed among your services. Click Manage on that card to launch the Horizon Universal Console.

Update and Republish Images with Administrator Passwords of Fewer than 12 Characters

Duplicate the VM of the image, change the administrator password to 12 characters or more, publish the VM, and delete the original VM.

Minimum VM Setting From the Pod's VDI Desktop Assignments and Farms

The migration process is designed so the first-gen VDI desktop assignments and farms have equivalent power management settings in their equivalent entities in the Horizon Cloud environment.

For the first-gen VDI desktop assignments and farms, the equivalent Horizon Cloud entities are pools and pool groups. In the Horizon Cloud environment, the power management settings are made at the pool-group level. In the pool group's power management settings, the Minimum VMs is based on the percentage of VMs to keep powered on relative to the total VMs in the pool group. In the first-gen environment, the setting named Min VMs directly represents the minimum number of VMs desired in the VDI desktop assignment or farm.

Post-migration, when you edit the pool groups that the system created from migrating those first-gen assignments and farms, the console displays those pool groups' Minimum VMs setting as the percentage converted from the first-gen Min VMs value. The functionality continues to adhere to the Min VMs number based on the converted percentage.

AD Domain Configurations

The Horizon Cloud environment requires auxiliary accounts for both the domain bind and domain join account in the Horizon Cloud AD domain configurations.

During the pre-build activities, if a first-gen tenant's AD domain configuration is missing an auxiliary domain bind account or auxiliary domain join account, the system will automatically re-use the primary account information as the companion auxiliary account in the Horizon Cloud AD domain configuration.

If this is your scenario, then post-migration obtain service accounts in your AD domains for the auxiliary domain bind and domain join accounts and edit the AD domain configurations to add those auxiliary accounts. In the Horizon Cloud console, edit the domains by navigating to Integrations > Manage > Domains.

Attention: Once the system has migrated the first-gen tenant's AD domain configuration to the Horizon Cloud environment during the first pod's migration, you are responsible for maintaining any attribute changes for the configured domains in both the first-gen and Horizon Cloud environments. The system does not automatically propagate changes you make in one environment to the other. For example, if you update the password for the domain bind account in your first-gen tenant, then you need to perform the same update in the paired Horizon Cloud environment.

Site-Related Settings - Multi-Cloud Assignments

When your first-gen environment had multi-cloud assignments, perform the following actions post-migration.

• Review the home site mappings

  After each pod's migration, if you had any home site mappings, review the home site mappings in the Horizon Cloud environment and update as needed for your organizational needs.

• Review the site-related settings in the pool groups created from migrating multi-cloud assignments

  The migration process defaults some of the settings in the pool groups that are created from migrating the first-gen multi-cloud assignments to Horizon Cloud pool groups. These defaults are chosen to ensure end users could get to their desktops when the migration window ends.

  Post-migration, you should carefully review these settings and ensure the defaults meet your requirements, or adjust them as needed to fit your organizational use cases. These settings are located within the pool group settings.

  • The Scope setting is set to Any site by default and the setting to require the home site is switched off.
  • The home site overrides from the first-gen assignment are not migrated over to the pool group.

When your first-gen environment has multi-cloud assignments that involve multiple pods, also take guidance from the points in When You Have Multiple Pods in First-Gen Assignments - Key Migration Points.

App Volumes - Post Migration

Post-migration:

• App Volumes: Bulk application entitlements

  In the Horizon Cloud architecture, the system manages the entitlements differently than in the first-gen architecture. During the migration process, the system handles the resolution of any bulk application entitlements that were in the migrated first-gen deployment. This resolution ensures that the bulk entitlements are migrated into the form appropriate with the Horizon Cloud environment's management of entitlements. End users will still have access to the same set of App Volumes applications as they were entitled to in the first-gen environment.

• App Volumes: Pod migrations

  During the successive migration of Horizon Cloud pods over time, the system takes care of all of the App Volumes entities from the first-gen pods into the Horizon Cloud environment.

  For example, you have the Notepad++ application as an App Volumes application with your first-gen pods and is used in both pod-1 and pod-2, and there are multiple versions of the application, with npp v7.8.1 in pod-1, npp v7.8.2 in both pod-1 and pod-2, and npp v7.8.3 in pod-2.

  During pod-1's migration pre-build, the system copies the App Volumes application Notepad++ along with the npp v7.8.1 and npp v7.8.2 to the Horizon Cloud environment, as those are the two versions used in pod-1. The other pod (pod-2) is yet to be migrated at this point.

  At this point, you have both environments and you want to make changes to the App Volumes entities in both the first-gen environment and Horizon Cloud environment. For these entities, during migration the system does not delete what it has already copied to the Horizon Cloud environment. If there are conflicts in App Volumes entities between the first-gen and Horizon Cloud environments, the entities present in the Horizon Cloud environment take precedence.

  To illustrate, in the first-gen environment, you delete the package npp v7.8.2 in pod-2 before migration and add a new package npp v7.8.4. Then when you schedule pod-2's migration, the system copies the packages currently used by pod-2 (npp v7.8.3 and npp v7.8.4) to the Horizon Cloud environment. The npp v7.8.2 package in the Horizon Cloud environment that was copied there during the pod-1's migration remains in the Horizon Cloud environment, even though that npp v7.8.2 was deleted from the first-gen environment.

Remote Apps from First-Gen Application Farms

As described in the first-gen documentation here, remote apps are provided by application farms from the first-gen pod. The Horizon Universal Console has new terminology and its labels reflect that.

Post-migration:

• One-to-one mapping is retained between the first-gen application farm and the resulting pool in Horizon Cloud.

• A pool is created for each migrated farm, using the farm's name.

• The migration process also creates a pool group for each pool, using the pool's name, which in the case of migration is also the original farm's name.

• Each pool group displays the information about the user entitlements migrated from the first-gen applications assignments, according to the apps associated with that pool group's pool.

• The first-gen applications assignment name is not visible in the Horizon Cloud console. When a first-gen applications assignment contains remote apps from multiple farms, then to see the remote apps and end-user entitlements within the Horizon Cloud console, you can view each pool group that was created with the farm names, or use the console's Desktop & App Catalog > Published Apps.

  Note: If you had installed the manual apps directly on the first-gen farm VMs, even though their metadata is migrated as part of the migration process, such apps won't be installed by default on the Horizon Cloud environment's pool VMs. For such apps, you'll have to re-install them on the pool VMs in the exact specific paths where they were installed in the first-gen farm VMs.

Consider:

• First-gen applications assignment Assign-1 has apps app1, app2 from farm Farm-1, and user User-1 is entitled for app1 and app2.
• First-gen applications assignment Assign-2 has apps app1 from Farm-1 and app3 from farm Farm-2, and user User-2 is entitled for app1 and app3.
• Meaning that app1 is entitled to both User-1 and User-2, app2 is entitled to User-1 only, and app3 is entitled to User-2 only.

After migration to Horizon Cloud:

• You see a pool named Farm-1 and a pool group named Farm-1 created for that pool. In that pool group, you see applications app1 and app2 (those were the applications from that first-gen farm).
• You also see a pool named Farm-2 and a pool group named Farm-2 created for that pool. In that pool group, you see application app3.
• The migrated entitlements are:
  • app1 from pool group Farm-1 entitled to User-1 and User-2
  • app2 from pool group Farm-1 entitled to User-1
  • app3 from pool group Farm-2 entitled to User-2

After Post-Migration Activities - Finalize

When you have confirmed that the Horizon Cloud environment is operating satisfactorily, the final pod-migration action is to finalize the migration.

During finalization, the Azure resources that the first-gen pod is still consuming from your Azure subscription are deleted.

Tip: You must finalize the migration as soon as possible to avoid your cost of running both the Horizon Edge's resources and the first-gen pod's resources in parallel. Finalizing reduces your costs because it deletes those Azure resources that the first-gen pod is still consuming.

After a pod is migrated, every time you log in to the Horizon Universal Console, the UI prompts about finalizing that pod's migration.

Finalize the Migration

Finalizing the migration is the last step in migrating a first-gen Horizon Cloud on Microsoft Azure pod.

Benefits of Finalizing

By finalizing:

• You avoid additional Microsoft Azure costs because finalizing deletes the remaining resources consumed in Azure by the first-gen pod.
• The system lifts the restrictions it placed on dedicated desktops when the maintenance window began:
  • Monitoring data for dedicated desktop VMs starts publishing to Intelligence.
  • You can run the agent update and agent reinstall operations on dedicated pools and VMs.
• You can safely make updates to the migrated images and pools without concerns of impacting rollback to the first-gen pod.

After finalizing, the migration cannot be rolled back from the Horizon Cloud environment back to the first-gen deployment state.

Before Finalizing - Perform Recommended Post-Migration Activities

Before finalizing, you should ensure the recommended post-migration activities are done. Those activities are described in the page Perform Post-Migration Activities to Confirm Migration Success.

Best Practice - Finalize Within a Few Days After Migration

It is a best practice to finalize the migration of each pod within a few days of completing the migration process because of the following factors:

• Until the first-gen pod is deleted by finalizing the migration, you are incurring Microsoft Azure subscription costs for running the first-gen resources, including pod manager instances and Unified Access Gateway instances.

• Until you finalize the migration, the Horizon Universal Console prevents you from using the agent update operations on dedicated pool groups and from using agent reinstall on dedicated VMs (Agent > Update Agent or Agent > Reinstall).

  Attention: When your Horizon Cloud environment has a non-finalized migration, the console prevents running the update agent and reinstall agent operations for all dedicated pool groups and dedicated VMs, whether they were ones migrated from first-gen or ones newly created in the Horizon Cloud environment. In this scenario, the console displays a guidance message about the need to finalize the migration.

  The reason for preventing agent updates and agent reinstalls until the migration is finalized is because changes to the agents in the desktops could cause problems in the event of rollback. If you attempt to roll back the migration from the Horizon Cloud environment to the first-gen deployment state, and the agents were modified in the Horizon Cloud environment, the desktops might not work properly in the rolled-back first-gen deployment.

• As time elapses and you and your VDI admins make changes in the Horizon Cloud environment, the ability to rollback the migrated environment to a first-gen deployment state that would satisfy your end users becomes degraded. For example, as you expand dedicated desktop pools in the Horizon Cloud environment and assign end users to new desktops, and then try to rollback to the first-gen pod, issues might occur for those new desktops on the first-gen side.

Finalizing Steps

You finalize the migration using the Finalize action on Horizon Cloud console's Migration page.

After you click Finalize, the console displays an approval window for you to approve deletion of the source first-gen pod.

To complete the migration process and confirm to the system that the first-gen pod can now be deleted, click Approve.

After Finalizing - Verify Private Endpoint Status for App Volumes Applications Storage Account, and Configure As Needed

After finalizing, it is strongly recommended to verify configuration of the Microsoft Azure private endpoint for the App Volumes applications storage account, and configure it if you see it is not already configured for the Horizon Edge.

Although the migrated environment works without this private endpoint configuration, configuring the private endpoint will further enhance the security for this storage account.

To verify the status in the Horizon Universal Console, navigate to the Horizon Edge details and look for the App Volumes Application Storage section.

If you see Not Configured or if you want to change the configuration, follow the guidance described at these locations in the Horizon Cloud Using guide.

• Azure Private Endpoint for App Volumes Application Storage Accounts page
• The steps within the section Configure Private Endpoint for an App Volumes Application Storage Account in the View Deployed Horizon Edges page.

As an illustration, the following screenshot depicts the UI showing a single storage account and where you can see if the private endpoint is configured. In this case, the private endpoint is not yet configured for this storage account.

The following screenshot shows the location of the menu for configuring the private endpoint. When you click the configure choice, follow the on-screen guidance. The steps are documented in Configure Private Endpoint for an App Volumes Application Storage Account.

Note: If you want, you can have the private endpoint use a subnet different than the Horizon Edge Gateway's management subnet, and in a different VNet if you prefer. In that case, you must ensure network peering is established between the VNet you choose for the private endpont and the VNets that have the Edge Gateway's management subnet and VNets of the desktop pools' subnets (if those subnets are in VNets different from the Edge Gateway's management subnet). For more information, see Azure Private Endpoint for App Volumes Application Storage Accounts page.

The following screenshot illustrates when the private endpoint is configured.

Pod Migration Completion

A finalized migration is a successful migration, congratulations!

For more information about day-2 operations, see the guide Using Horizon Cloud.

Remember: As described in the Scheduling page's section of Site-Related information, avoid making any changes to the site-related configurations for users and groups that are already set in the first-gen tenant. When you finalize the first pod's migration and then subsequently make changes to the site-related information in the first-gen environment, those changes will not become visible in the Horizon Cloud environment until the next pod migration.