Deployment Guide: Migrating Citrix Virtual Apps and Desktops from VMware vSphere to Citrix DaaS on Microsoft Azure

Overview

In this document, you’ll discover how to migrate from Citrix Virtual Apps and Desktops on VMware vSphere to Citrix DaaS on Microsoft Azure. Migrating to cloud resources modernizes your deployment, providing enhanced elasticity, scalability, and management.

The guidance documented here is based on a deployment in a Citrix- and Microsoft-reviewed and approved lab environment. The initial and final deployments represent typical customer environments.

We migrated these key products and components:

• Citrix Virtual Apps and Desktops on-premises to Citrix DaaS
  
• Workspace Environment Management on-premises to Workspace Environment Management service
  
• On-premises StoreFront and Citrix Gateway to Citrix Workspace and Citrix Gateway service
  
• On-premises vSphere workloads to workloads in Azure
  
• On-premises file servers to Azure
  
• Citrix workload in Azure
  

The following diagram shows the migration process.

The best migration path

In our experience and testing, the best migration path follows these steps:

1. Set up a basic Citrix Cloud environment
   .
2. Migrate on-premises Citrix Virtual Apps and Desktops to Citrix DaaS
   using the automated configuration tool developed by Citrix.
3. Migrate on-premises Workspace Environment Management to Workspace Environment Management service
   .
4. Configure the end-user access layer
   .
5. Prepare the Azure subscription
   to receive the workloads from your on-prem deployment.
6. Configure site-to-site connectivity
   .
7. Use Azure tools to migrate your on-premises servers to Azure
   .
8. Move your Citrix workload to Azure
   .

If you do the migration in the specified order, you’ll have a more organized and orderly migration. The specified order lets you run products, components, and services in a combination of on-premises and cloud deployments, minimizing the disruption to daily workloads.

The following diagram shows our migrated environment, with all workloads on Azure and using Citrix Cloud.

Audience

We’ve written this document for users who are

• Familiar with the administration of a Citrix Virtual Apps and Desktops or XenApp and XenDesktop site
• Familiar with the administration of a StoreFront environment
• Familiar with the basics of Azure

It’s also helpful if you know Citrix Cloud fundamentals and understand Citrix Gateway or NetScaler Gateway.

Lab details

We ran the migration workflow in our lab, using virtual machines that had the following components installed and configured:

• Domain controller, DNS, DHCP, certificate services
• SQL Server 2019 Standard
• Citrix delivery controller
• StoreFront 1912
• Citrix Director
• Remote Desktop Services (RDS) and Citrix License Server
• Citrix Workspace Environment Management server
• File server
• Windows 2016 master
• Windows 10 master
• Citrix ADC

Active Directory structure

Each component of the overall solution requires integration with Active Directory (AD) to provide authentication into the Citrix environment and personalization settings that are applied to user sessions via AD Organizational Units (OUs) in each part of the project.

Citrix recommends an OU structure like the one illustrated in the following image. Integrate the OU structure with your current structure. The OU structure hosts the machines and the user accounts for the Citrix Cloud environment.

Active Directory preparation

For our lab environment, we defined GPOs that:

1. Configure Citrix Workspace Environment Management to define the infrastructure server.
2. Configure the Citrix Workspace app to allow SSO and to populate applications on the user’s desktop.
3. Configure a logon script to apply a background using BGInfo. For the purposes of our demo, we apply different background settings based on the migration project’s phase.

With the basic lab setup in place, we’re ready to start the migration.

We recommend that you create the AD structure, GPOs, and link the GPOs that will host your Azure workload before you start the migration project. It’s also helpful to have checkpoints in place so you can validate the successful completion of each step.

Set up a basic Citrix Cloud environment

If you’re already using Citrix DaaS, you can skip to the section Workspace Environment Management service
.

We set up the Citrix Cloud environment in three steps:

Step 1: Onboarding

Step 2: Deploy Citrix Cloud Connector on two VMware ESX VMs

Step 3: Rename the resource location

Step 1: Onboarding

Ensure you have a valid Citrix DaaS subscription
.

To proceed, you need access to Citrix DaaS. If you don’t have access, contact a Citrix representative.

Step 2: Cloud Connector installation

The Citrix Cloud Connector lets you configure secure communication between your on-premises deployment and Citrix Cloud. To ensure that your Citrix Cloud Connector is set up to spec, review the System requirements
. You need two VMware ESX VMs to host two Citrix Cloud Connectors.

You can install the Cloud Connector software interactively
or using the command line
.

Step 3: Rename the resource location

Notes from the field:

When you have multiple resource locations, it’s best practice to have a distinct name for each resource location. That helps you identify it more easily.

1. Select your resource location, click … and select Rename.

   

2. Give your resource location a new name, for example, On-premises, and click Save.

   

Checkpoint: Citrix Cloud Connector

When your Cloud Connectors are deployed successfully and running, they are listed with a green bar on the left.

If the status is not what you expect, use the Citrix Cloud Services Connectivity Test Tool, for more information.

Migrate to Citrix DaaS

If you’re already using Citrix DaaS, you can skip to the section Workspace Environment Management service
.

If you’re using Citrix Virtual Apps and Desktops on-premises, you can use the procedures in this section as a guide for migrating to Citrix DaaS.

For the MCS provisioning method, the MCS migration
section provides detailed migration steps.

For the PVS provisioning method, go to PVS migration
.

The following diagram shows our cloud environment on Azure after we migrate to the Citrix DaaS.

MCS migration

Step 1: Preparation

To migrate successfully using the automated configuration tool, for on-premises MCS configured catalogs, you must replicate your on-premises configuration for hosting, machine catalogs, and delivery groups. The migration tool only creates and assigns applications and policies for MCS deployments.

During this migration phase, we recommend that you create only a few VMs for each machine catalog. Having just a few VMs allows you to validate machine catalog creation and then allows you to create delivery groups and run the Azure migration tool.

Because the objective is to migrate your Citrix Workload to Azure, it’s not necessary to create all the VMs with Citrix Virtual Apps and Desktop on-premises.

Use your on-premises master images to create Citrix DaaS machine catalogs and delivery groups.

Important:

To run the migration tool successfully, the delivery groups created in Citrix DaaS must have identical names to the existing on-premises delivery groups.

Establish host connection

The host connection is where you establish the network and the storage–the resources–for a connection. See Create and manage connections
for detailed information about connections.

Create machine catalogs

Use machine catalogs to manage collections of machines as single entities. For more information, see Create machine catalogs
. Machine catalogs are a prerequisite for creating delivery groups. When you run the Azure migration tool, the tool brings over all of your settings and creates all the VMs you need. To make sure you have placeholders for your delivery groups, create machine catalogs that contain a minimal number of VMs during this step. Usually, two VMs are enough to satisfy this requirement.

Create delivery groups

Use delivery groups to control access and delivery to machines, applications, and desktops. For details, see Create delivery groups
. Create delivery groups that have identical names to your existing on-premises delivery groups.

Step 2: Migration

We use a Citrix-developed tool, the Automated Configuration Tool, to migrate Citrix Virtual Apps and Desktops from on-premises to Citrix DaaS. You can download the automated configuration tool
from Citrix. Documentation for the tool is available on Tech Zone in Automated Configuration
.

Because our on-premises lab is using MCS, we only migrate the following:

• Applications
• Citrix Policies

Export the on-prem site configuration

Note:

Because we are using MCS and can only import applications and group policies, we use two options here: -Applications and -GroupPolicies to export only the required information.

Prerequisites

We run the automated configuration tool on a delivery controller, and we need .NET Framework 4.7.2 or later to be installed on that server.

You can download .NET Framework 4.7.2 from: https://dotnet.microsoft.com/download/dotnet-framework/net472
.

Install AutoConfig_PowerShell_x64.msi on the delivery controller. Installing the tool creates a desktop icon called Auto Config that launches the PowerShell command prompt. You run the Cloud automated configuration cmdlets from the PowerShell command prompt.

Export applications

1. Click the Auto Config icon.

   

2. Run the following command: Export-CvadAcToFile –Applications $true.

   

Export policies

1. Run the following command: Export-CvadAcToFile –GroupPolicies $true.

   

2. Ensure that the result is reported as True.

Import settings to Citrix Cloud

All the files that you edit are in the folder where you run the PowerShell command. The Auto Config tool creates the files when you run the export command.

Prerequisites

1. Edit and fill the CustomerInfo.yml file with Customer ID, Client ID, and Secret.

   

2. Connect to Citrix Cloud and go to Identity and Access Management.

   

3. Click API Access.

   

4. Take note of your customer ID.

   

5. Provide a name and click Create Client.

   

6. Copy the ID.

   

7. Copy the secret

   

8. Paste the information in a document (it is not possible to see the information again, so keep the document safe).

   

9. When the file is filled, save it (insert your information between the quotation marks).

10. Edit ZoneMapping.yml using Notepad.

    

11. Replace the highlighted text with your Cloud resource location name as shown in the following example:

    

Note:

If the default Cloud resource location name has not been changed, it should be Primary.

The correct syntax for the primary zone is to keep a space between the colon : and the first quotation mark ", in keeping with standard YAML syntax. The name is case-sensitive and must be enclosed in quotation marks as shown.

Import applications

1. Run the following command in the Auto Config tool: Import-CvadAcToSite -Applications $true.

   

2. Enter yes to validate the action.

   

   The resulting output looks like the following image:

   

Import policies

1. Run the following command in the Auto Config tool: Import-CvadAcToSite -GroupPolicies $true.

   

2. Enter yes to validate the action.

   

   The resulting output looks like the following image:

   

3. Ensure that the result is True.

More details about each VDA reconfiguration option are available from Citrix product documentation in VDA registration

Checkpoint: Citrix DaaS migration using MCS

1. Connect to Citrix DaaS, go to Applications and ensure that applications have been created.

2. Go to Policies and ensure that your policies have been created and assigned.

If you’re using Workspace Environment Management, continue with Migrate to Workspace Environment Management service
.

If you’re not using Workspace Environment Management, the next step is to Configure the end user access layer
.

PVS Migration

We use a Citrix-developed tool, the Automated Configuration Tool, to migrate Citrix Virtual Apps and Desktops from on-premises to Citrix DaaS. You can download the automated configuration tool
from Citrix.

Documentation for the tool is available on Tech Zone in Automated Configuration
.

Export the on-prem site configuration

Prerequisites

We run the automated configuration tool on a delivery controller, and we need .NET Framework 4.7.2 or later to be installed on that server.

You can download .NET Framework 4.7.2 from: https://dotnet.microsoft.com/download/dotnet-framework/net472
.

Install AutoConfig_PowerShell_x64.msi on the delivery controller. Installing the tool creates a desktop icon called Auto Config that launches the PowerShell command prompt. You run the Cloud automated configuration cmdlets from the PowerShell command prompt.

Export settings

1. Click the Auto Config icon.

   

2. Run the following command: Export-CvadAcToFile. This command is the same as running the Export-CvadAcToFile -All $True command.

   

3. Ensure that the result is reported as True.

Import settings to Citrix Cloud

Prerequisites

1. Edit and fill the CustomerInfo.yml file with Customer ID, Client ID, and Secret.

   

2. Connect to Citrix Cloud and go to Identity and Access Management.

   

3. Click API Access.

   

4. Take note of your customer ID.

   

5. Provide a name and click Create Client.

   

6. Copy the ID.

   

7. Copy the secret.

   

8. Paste the information in a document (it is not possible to see the information again, so keep the document safe).

   

9. Add the following line at the end of the file: HostConnections: True to allow the hosting configuration.

   

10. When the file is filled, save it (insert your information between the quotation marks).

11. Edit ZoneMapping.yml using Notepad.

    

12. Replace the highlighted text with the name of your on-premises resource location defined in Citrix Cloud, as shown in the following example:

    

    Note:

    If the default Cloud resource location name has not been changed, it should be Primary.

    The correct syntax for the primary zone is to keep a space between the colon : and the first quotation mark ", in keeping with standard YAML syntax. The name is case-sensitive and must be enclosed in quotation marks as shown.

13. Edit CvadAcSecurity.yml using Notepad.

    

14. Fill the file with your credentials and save it. The correct format for the user name is domain\username.

Import settings

1. Run the following command in the Auto Config tool: Import-CvadAcToSite -All $true.

   

2. Enter yes to validate the action.

   

The resulting output looks like the following image:

More details about VDA registration options are available from Citrix product documentation in VDA registration

Checkpoint: Citrix Virtual Apps and Desktop service using PVS

1. Connect to Citrix DaaS, go to Machine Catalogs and ensure that your Machine Catalogs have been created and machines allocated.

2. Go to Delivery Groups and ensure that your delivery groups have been created.

3. Ensure your VMs are registered in the Citrix Cloud studio console.

4. Go to Applications and ensure that your applications have been created.

5. Go to Policies and ensure that your policies have been created and assigned.

If you’re using Workspace Environment Management, continue with Migrate to Workspace Environment Management service
. If you’re not using Workspace Environment Management, the next step is to configure the end user access layer
.

Migrate to Workspace Environment Management service

This step applies only if you use Workspace Environment Management on-premises and want to migrate to the Workspace Environment Management service. If that does not apply to you, then skip to the next section, Citrix workload on Azure.

Step 1: Meet the system requirements

The toolkit supports the migration from Workspace Environment Management 4.7 and later. To migrate from an earlier version, upgrade Workspace Environment Management 4.x to Workspace Environment Management 4.7 or later, and then migrate the database to the Workspace Environment Management service.

For details about migrating to the Workspace Environment Management service, see Migrate
.

The following diagram shows the environment with our on-prem and Azure resources, now adding the Workspace Environment Management service to our cloud environment.

Notes from the field:

To verify that our VDAs switch from on-prem to Cloud, an easy trick is to create a setting that is only configured in the Workspace Environment Management service.

Step 2: Switch to service agent mode

Use the agent switch feature to switch from on-premises to service agent mode. For information about the agent switch, see Agent Switch.

Note:

The agent switch feature is available in Workspace Environment Management 1909 and later. For earlier versions, you must reinstall the agent or upgrade it to version 1909 or later before using the agent switch.

Alternatively, you can download the agent from the service’s Downloads tab and then manually reinstall the agent.

1. Connect to Workspace Environment Management Console on-prem.

   

2. In Advanced Settings, click the Agent Switch tab.

   

3. Check the box Switch to Service Agent, provide the Cloud Connector servers, and click Apply.

4. Restart the VDA to apply the new settings.

Checkpoint: Workspace Environment Management service migrationAs a verification step to confirm that our VDAs switched from on-prem to Cloud, we added an app, Notepad, that is uniquely available from the Workspace Environment Management service. We used the following steps to confirm the switch.

1. Open the Win 10 + Citrix DaaS Desktop.

2. Ensure that the new application configured with the Workspace Environment Management service (in our example, Notepad) is populated on the user’s desktop.

Configure the end user access layer

You have two options for configuring the end user access layer:

• Continue to use StoreFront with Citrix Gateway
  if you require specific StoreFront features
• Migrate to Citrix Workspace and Citrix Gateway service
  

StoreFront with Citrix Gateway

In this section, we configure the on-premises StoreFront and Citrix Gateway to integrate with Citrix DaaS. To support multiple StoreFront sites, we use multisite aggregation.

StoreFront

1. Add your Cloud Connector as a delivery controller in each configured store.

   

2. Add a delivery controller configuration by adding the Cloud Connector as the secure ticket authority (STA) in your Citrix Gateway configuration.

   

3. Aggregate resources. To learn more about multisite aggregation, Designing StoreFront Multi-Site Aggregation
   is a useful resource.

4. Map users to controllers.

Citrix Gateway

Add the Citrix Cloud Connector as the STA in your Citrix Gateway configuration.

Checkpoint: STA

Ensure that all STA servers have a status of UP as shown in the following image.

Now the STA servers are up and StoreFront is configured.

Checkpoint: Citrix DaaS migration with on-premises access layer

1. Ensure in Citrix Cloud that the VDAs are registered. The Citrix product documentation provides a deeper understanding of VDA registration
   .

2. Connect to your Citrix Gateway.

3. Launch a published resource.

Migrate to Citrix Workspace and Citrix Gateway service

In this section, we migrate to the Citrix Gateway service and Citrix Workspace, as shown in the following diagram.

Note:

When you evaluate the Citrix Gateway service and Citrix Workspace, make sure the customizations and configurations you need are available.

Configuration

1. Connect to Citrix Cloud.

2. Click Home > Workspace Configuration.

   

3. Edit the Workspace URL and provide a name that meets your requirements. Click Save.

   

4. Click Authentication.

   

5. The supported authentication methods are presented. Select the one you want and click Customize.

   

6. You can customize with two logos. One for the authentication page and one for the Workspace store.

   

7. You can change colors if necessary.

   

8. Click Save.

   

9. Click Service Integrations.

   

10. Enable Virtual Apps and Desktops.

    

11. Click Confirm.

    

12. Click Access.

    

13. To the right of the resource location, click the 3 dots … and select Configure Connectivity.

    

14. Select Gateway Service and click Save.

Checkpoint: Citrix Workspace and Citrix Gateway service migration

1. Ensure in Citrix Cloud that the VDAs are registered. The Citrix product documentation provides a deeper understanding of VDA registration
   .

2. Connect to your Citrix Workspace URL.

3. Launch a published resource.

Prepare the Azure subscription

The first step to migrating your workloads to Azure is to set up the Azure environment. If you’re new to Azure, or if your environment has some different components from our lab setup, Microsoft offers many helpful resources, like New to Azure? Follow these easy steps to get started
and the Azure Migrate documentation
.

For a detailed look at how to architect Citrix Virtual Apps and Desktops on Azure, see Citrix DaaS on Azure
.

We prepped the Azure environment in five basic steps:

Step 1: Select an Azure subscription model

Step 2: Select the Azure regions

Step 3: Create a resource group

Step 4: Create a virtual network

Step 5: Deploy a server in Azure, that in our case, acts as the domain controller. You can deploy any server type that’s easy for you, or skip this step altogether.

When our Azure subscription is set up and ready for the next step, our environment looks like the one in the following diagram. The resources and workloads are all on-premises and we have a resource group, a virtual network, and a server in Azure.

Step 1: Select an Azure subscription model

Set up your Azure subscription.

Selecting a subscription model is a complex decision that involves understanding the growth of your Azure footprint within and outside the Citrix deployment. Even if the Citrix deployment is small, you might still have a large amount of other resources that are reading/writing heavily against the Azure API. That heavy read/write activity can have a negative impact on the Citrix environment. The reverse is also true, where many Citrix resources can consume an inordinate number of the available API calls, reducing availability for other resources within the subscription. For information about Azure subscription limits and quotas, see Azure subscription and service limits, quotas, and constraints
.

Step 2: Select Azure regions

An Azure region is a set of data centers deployed within a latency-defined perimeter and connected through a dedicated regional low-latency network. Azure gives customers the flexibility to deploy applications where they need to. Azure is generally available in 60 regions and 149 countries around the world.Microsoft provides details in https://azure.microsoft.com/en-us/global-infrastructure/regions/
.

Step 3: Create a resource group

A resource group in Azure is a collection of assets in logical groups for easy or even automatic provisioning, monitoring, and access control, and for more effective management of their costs. The benefit of using resource groups in Azure is that you can group related resources that belong to an application. Because the application’s resources share a unified lifecycle from creation to usage and finally, de-provisioning, they can be managed together for efficiency.

The key to having a successful resource group design is understanding the lifecycle of the resources that are included in the resource groups.

If you need guidance setting up a resource group, Microsoft provides details in What is Azure Resource Manager
.

One or more resource groups can be applied to a machine catalog during initial creation. These resource groups cannot be shared across machine catalogs. Resource groups are limited to 240 Citrix MCS VMs due to the 800 per resource limit in a resource group. See CTX237504
for more details about this limitation.

Resource groups are tied to machine catalogs at creation time and cannot be added or changed later. To add resource groups to a machine catalog, the machine catalog must be removed and recreated.

Step 4: Create a virtual network in Azure

The virtual network is required to enable secure communication among the resources in your environment. For more information about creating virtual networks in Azure, see Quickstart: Create a virtual network using the Azure portal
. For help with configuring a virtual network, see What is Azure Virtual Network
.

Step 5: Deploy a server in Azure (optional)

With our resource group and virtual network established, we’re ready to deploy a server in Azure. We use this server as the domain controller. It helps us validate AD replication after we establish site-to-site connectivity. If you want more detailed information about how to set up virtual machines, see Quickstart: Create a Windows virtual machine in the Azure portal
. Microsoft also provides helpful guidance for choosing the right size VM for your workload in Sizes for virtual machines in Azure
.

Step 5 is optional. We deployed a server in Azure to better represent a typical deployment.

Now that we have our resource groups and virtual network created, and we have a server deployed, our next step is to configure connectivity between our on-premises and Azure environments.

Configure site-to-site connectivity

To connect your on-premises environment to Azure, you have multiple options:

• Site-to-site VPN Detailed information is available in Create a Site-to-Site connection in the Azure portal
  .

• Citrix SD-WAN Step-by-step guidance for Citrix SD-WAN is available in the Proof of Concept Guide: Citrix SD-WAN Cloud-to-Data Center Connectivity
  .

• Express Route Step-by-step guidance for Express Route is in the Express Route documentation
  .

For the purposes of our demonstration, we used site-to-site VPN.

The following diagram shows how our Azure environment is set up to communicate with our on-premises environment.

Checkpoint: site connectivity

When you have connectivity implemented, a checkpoint is to communicate with Azure resources from your on-premises environment and conversely.

In our case, we used two methods:

Option 1: Test using the ping command between resources in each location.

Option 2: Join the deployed server in Azure to our on-premises AD Domain. If you omitted step 5, you can skip this option.

Now that we have site-to-site connectivity configured and validated, our next step is to migrate our on-premises workloads to Azure.

Migrate on-premises workloads to Azure

In a typical Citrix customer deployment, there are multiple components that can be migrated. Component types and migration plans may vary by customers.

To get a better sense of how to approach your migration, refer to the Microsoft Cloud Adoption Framework for Azure
.

In this section we cover the migration of components that are closely related to Citrix, such as the file server for profiles and folder redirection, and the master images for provisioning. For the purposes of this document, we limited the migration to the components in our lab environment. For your production environment, however, you have the option to move more of your infrastructure to Azure.

File server technologies

Azure offers several file server technologies that can be used to store Citrix user data, roaming profile information, or function as targets for Citrix App Layering network file shares. The Azure options include:

• Standalone file server using Azure files
  

• File servers using Storage Replica
  

• Scale out file server (SOFS) with Storage Spaces Direct (S2D)
  

• Distributed File System Replication (DFS-R)
  

• Third-party storage appliances (such as NetApp and others) from Azure Marketplace
  

Select file server technologies that best meet your business requirements. Introduction to Azure Storage
provides a list of storage types and corresponding use cases to help you determine what’s best for your situation.

Infrastructure cost management

Azure Reserved VM Instances (RIs) significantly reduce costs—up to 72 percent compared to pay-as-you-go prices—with one-year or three-year terms on Windows and Linux virtual machines (VMs). When you combine the cost savings gained from Azure RIs with the added value of the Azure Hybrid Benefit, you can save up to 80 percent. The 80% is calculated based on a three-year Azure Reserved Instance commitment of a Windows Server when compared to the normal pay-as-you-go rate.

While Azure Reserved Instances require making upfront commitments on compute capacity, they also provide flexibility to exchange or cancel reserved instances at any time. A reservation only covers the virtual machine compute costs. It does not reduce any of the additional software, networking, or storage charges. This is good for Citrix infrastructure and the minimum capacity needed for a use case (on and off hours).

Azure VM instance types

Each Citrix component uses an associated virtual machine type in Azure. Each VM series available is mapped to a specific category of workloads (general purpose, compute-optimized, and so forth), with various sizes controlling the resources allocated to the VM (CPU, Memory, IOPS, network, and others). The Virtual Machine Series
provides detailed descriptions of the series and their capabilities.

Most Citrix deployments use the D-Series and F-Series instance types. The D-Series are commonly used for the Citrix infrastructure components and sometimes for the user workloads when they require more memory beyond what is found in the F-Series instance types. F-Series instance types are the most common in the field for user workloads because of their faster processors, which bring with them the perception of responsiveness.

Why D-Series or F-Series? From a Citrix perspective, most infrastructure components (Cloud Connectors, StoreFront, NetScaler, and so on) use CPU to run core processes. These VM types have a balanced CPU to Memory ratio and are hosted on uniform hardware (unlike the A-Series) for more consistent performance and support premium storage. Certainly, you can and should adjust your instance types to meet your needs and your budget.

The size and number of components within your infrastructure always depends on your requirements, scale, and workloads. However, with Azure we can scale dynamically and on-demand. For the cost conscious, starting smaller and scaling up is the best approach. Azure VMs require a restart when changing size, so plan these events only within scheduled maintenance windows and under established change control policies. Citrix provides a more detailed analysis in The scalability and economics of delivering Citrix Virtual App and Desktop services on Azure

Storage

Just like any other computer, the virtual machines in Azure use disks as a place to store an operating system, applications, and data. All Azure virtual machines have at least two disks – a Windows operating system disk and a temporary disk. The operating system disk is created from an image, and both the operating system disk and the image are stored within Azure as virtual hard disks (VHDs). Virtual machines may also have other disks attached as data disks, also stored as VHDs
.

Azure Disks are designed to deliver enterprise-grade durability. You can select from two performance tiers for storage exist when you create disks: Premium SSD Disks and Standard HDD Storage. The disks may be either managed or unmanaged. Managed disks are the default and are not subject to the storage account limitations like the unmanaged disks.

Microsoft recommends managed disks over unmanaged disks. Unmanaged disks should be considered only for exceptions. Consider that Standard Storage (HDD and SSD) includes transaction costs (storage I/O) but has lower costs per disk. Premium Storage has no transaction costs but has higher per-disk costs and offers an improved user experience.

The disks only offer an SLA when an Availability Set is used. Availability Sets are not supported with Citrix MCS. When you create VMs for Citrix Cloud Connector, Citrix ADC, or StoreFront on Azure, use Availability Sets.

Azure Migrate services overview

Azure Migrate provides a set of tools to assess and migrate to Azure on-premises servers, infrastructure, applications, and data. For detailed information, see About Azure Migrate
. We used Azure Migrate to migrate our file server and master images.

The following diagram shows the locations of our resources when we migrate to Azure.

We recommend a three-step process:

Step 1: Discovery

Step 2: Assessment

Step 3: Migration

Note:

For PVS users, specific steps are required to prepare your environment before you migrate to Azure. Follow those steps in the next section. MCS users can go directly to Discovery
.

Prerequisite for PVS-specific image preparation

For each PVS image, it’s necessary to remove the VM from Provisioning and to temporarily configure it so it is hosted on VMware vSphere only. You do this using reverse imaging. There are multiple methods for reverse imaging. One is described in detail in CTX202159: How to Perform Reverse Imaging on a Provisioning Services Target Device for Windows and its Applicable Usages
.

Step 1: Discovery

The first step is to create a migration project and select the tools to use. You need to set up the appliance for the discovery process. For more details, see Discover machine apps, roles, and features
.

Microsoft provides two methods for setting up the appliance:

• OVA template (a downloadable file)

• Script

The Azure Migrate appliance connects to the vCenter Server to discover and migrate VMs using agentless migration.

After the appliance is deployed and you’ve provided credentials, the appliance starts continuous discovery of VM metadata and performance data, along with discovery of apps, features, and roles. The duration of app discovery depends on how many VMs you have. It typically takes an hour for app discovery of 500 VMs.

Step 2: Assessment

Based on the discovery results, you create an assessment of all on-premises resources on your vCenter.

For the assessment (which Microsoft recommends), you have multiple options. The two that interest us most for Citrix workloads are:

• Azure Migrate: Server Assessment
  

• Movere
  

We use Azure Migrate: Server Assessment in this project.

The migration tool provides an overview of your environment with details like:

• Name
• IP Address
• Applications installed
• Dependencies
• Cores
• Memory
• Disks
• Storage
• Operating System

During the assessment configuration, you have access to assessment properties that allow you to:

• Select Target Location
• Select Storage Type
• Select if you want to assess based on reserved instances
• Select Sizing criteria
• Select Performance History
• Select Percentile utilization
• Select VMs Series
• Select Comfort Factor
• Select Pricing details

For dependencies to be discovered, you need to deploy software on the VMs. See Analyze machine dependencies (agentless)
.

Dependencies are helpful to know when you want to migrate application or database servers. Knowing the dependencies lets you determine exactly which servers need to be migrated to ensure a persistent and secure connection between your servers.

To facilitate the migration, we have created a group that only contains the VMs that we intend to migrate.

Step 3: Migration

For server migration, Microsoft provides options for agent-based and agentless approaches. Our focus here is on the agentless approach, as describe in Migrate VMware VMs to Azure (agentless)
. To determine the best approach for your business, see Select a VMware migration option
.

The migration process starts with an initial replication of the on-premises VMs to Azure.

The duration of the process depends on the size of the disks associated to your VMs and your bandwidth. The duration also depends on

• The number of concurrent migrations
• Your bandwidth on vCenter
• The availability of storage (for the agentless approach)
• Your network bandwidth

During the replication process, you need to select:

• VMware vSphere
• Appliance to use
• Select Virtual machines to migrate (import the Assessment, select Group)
• Select Target Settings
• Select Compute
• Select Disks

When the delta replication begins, after initial replication, you can run a test migration
before running a full migration to Azure.

We highly recommend that you run a test migration at least once for each machine before you migrate it.

• Running a test migration checks that migration works as expected, without impacting the on-premises machines, which remain operational, and continues replicating.

• Test migration simulates the migration by creating an Azure VM using replicated data (usually migrating to a non-production VNet in your Azure subscription).

• You can use the replicated test Azure VM to validate the migration, perform app testing, and address any issues before full migration.

Complete the migration

Follow Microsoft’s guidance to Complete the migration
and for Post-migration best practices
.

1. After the migration is done, right-click and select VM > Stop Replication. This command stops replication for the on-premises machine and cleans up replication state information for the VM.

2. Install the Azure VM Windows or Linux agent on the migrated machines.

3. Perform any post-migration app tweaks, such as updating database connection strings, and web server configurations.

4. Perform final application and migration acceptance testing on the migrated application now running in Azure.

5. Cut over traffic to the migrated Azure VM instance.

6. Remove the on-premises VMs from your local VM inventory.

7. Remove the on-premises VMs from local backups.

8. Update any internal documentation to show the new location and IP address of the Azure VMs.

Post-migration best practices

• For increased resilience:

  • Keep data secure by backing up Azure VMs using the Azure Backup service. Learn more in Back up a virtual machine in Azure
    .
  • Keep workloads running and continuously available by replicating Azure VMs to a secondary region with Site Recovery.  Learn more in Set up disaster recovery for Azure VMs
    .

• For increased security:

  • Lock down and limit inbound traffic access with Azure Security Center - Just in time administration
    .
  • Restrict network traffic to management endpoints with Network Security Groups
    .
  • Deploy Azure Disk Encryption
     to help secure disks, and keep data safe from theft and unauthorized access.
  • Read more about securing IaaS resources
    , and visit the Azure Security Center
    .

For monitoring and management, consider using Citrix Application Delivery Management service
.

Consider deploying Azure Cost Management
 to monitor resource usage and spending.

Checkpoint: Azure Migration

1. Validate the IP address assigned to the file server on Azure after migration.

2. Ensure the IP address has been updated on the DNS server.

3. Connect to the Citrix Gateway with a new user account.

4. Open the Citrix DaaS desktop.

5. Close the session and ensure that the user’s profile has been created on the file server in Azure.

Move Citrix workload to Azure

Next we move our Citrix workload to Azure.

The following diagram shows the Azure and Citrix Cloud components that have been migrated and our remaining on-premises environment.

Step 1: Prerequisites

1. Deploy two Cloud Connectors on Azure.

   

2. Create a resource location in Citrix Cloud.

   

3. Deploy Cloud Connector software on the servers and attach them to the new resource locations.

   

Step 2: Create Citrix workload

1. Create the basic configuration
   1. hosting
   2. machine catalogs
   3. delivery groups
   4. publish applications
   5. bind Citrix policies

Step 3: Configure the end user access layer

Note:

If you are not using Citrix Workspace and Citrix Gateway service, follow these steps.

1. Connect to the on-premises StoreFront server to add the Azure Cloud Connectors as delivery controllers on each store.

   

2. Configure user mapping and multi-site aggregation
   (during the transition step) for the internal store.

   

3. Configure user mapping and multi-site aggregation for the external store.

   

4. Add the Azure-hosted Cloud Connectors as the STA in the Citrix Gateway configuration in StoreFront.

   

5. Add the Azure-hosted Cloud Connectors as the STA in the Citrix Gateway Virtual Servers configuration on Citrix ADC.

   

6. Ensure that all STAs are UP.

Checkpoint: Citrix workload

1. Connect to your Citrix Gateway.

2. Open the Azure-hosted Citrix Virtual Apps and Desktop service published desktop.

3. Ensure that the name of the desktop is the one you provisioned on Azure.

4. Launch apps to make sure they launch. Make note of app performance. If your apps perform poorly, you may need to adjust your Azure machine sizing.