Tech Paper: CVAD LTSR Parallel Migration

Overview

A new Citrix Virtual Apps and Desktops Long Term Service Release (LTSR) is an exciting time. It also means many updates from the previous LTSR, as two years of previously developed, field-proven features are packaged together with a longer maintenance cycle.

When preparing for the next LTSR, several considerations and planning tasks need to occur for a smooth and successful migration. The following key factors should be considered when planning for a new LTSR:

Compatability. Software continuously updates, improves, and eventually goes End of Life (EOL). Knowing EOL dates for Citrix and other vendor software (like operating systems) is critical to make sure that your environment is supported. When planning for the LTSR, evaluating its compatibility with Windows OS releases, hypervisor versions, and SQL versions is important. If your environment OS, hypervisor version, or SQL version is incompatible with the latest LTSR, plan to migrate your environment to a supported version alongside the LTSR migration. If upgrading versions, it’s important to be aware of the EOL dates of currently supported software. Being aware of EOL dates makes sure that you don’t have to upgrade soon after the initial installation.
New Features. The best part of any new release is the new features - allowing your organization to do things that weren’t possible before, reduce costs, and improve security among other things. When migrating to the latest LTSR version, reference our LTSR to LTSR matrix to see which new features are included in the upcoming release. Evaluate which features make sense for your use cases. Plan to test and implement any new features as needed or applicable.
Migration Path. There are two main migration path options when transitioning to a new LTSR: In-place and Parallel.
- In-Place: In-place upgrades involve upgrading your existing Citrix infrastructure machines, VDAs, and related components. Documentation about how to upgrade in-place can be found in our product documentation. It is recommended to validate the upgrade process in a test environment and back up any production infrastructure before starting upgrades. Your users use the same infrastructure and resources, so configurations and users do not need to be migrated.
- Parallel: Parallel upgrades are conducted by building a separate Citrix Virtual Apps and Desktops site on the new LTSR version, independent from the existing site. These deployments require more infrastructure, server builds, firewall rules, networking configurations, etc. The configurations and users must then be migrated from the old Site to the new one. During this process, no longer required configurations can be cleaned up. This migration strategy is considered less risky, as you do not impact end users while upgrading. For this reason, parallel migrations are recommended when uptime is a priority (such as 24x7 healthcare environments). Especially when upgrading between multiple generations of LTSRs.

This tech paper focuses on compatibility, new feature considerations, and the migration strategy for a parallel Citrix Virtual Apps and Desktops site build. Information on how to migrate from Citrix Virtual Apps and Desktops to DaaS can be found in this deployment guide. This tech paper will not cover how to build a Citrix site from scratch. That information is found in product documentation. Instead, this paper focuses on what to consider when you upgrade, how to migrate site configurations, and how to migrate users to the new site.

Supportability

When upgrading, evaluating if any other parts of your environment need to be upgraded to maintain compatibility is critical.

Tracking when your Citrix software version goes EOL is important to make sure you upgrade in time to maintain support. Generally, LTSR versions are supported for up to 5 years after initial release. You can review our product lifecycle and EOL dates on our product matrix. EOL dates for Microsoft OS, hypervisors, and any other software in the Citrix deployment should be reviewed to make sure that your environment is fully supported. Unsupported software versions introduce the risk that if something goes wrong, the vendor cannot assist in resolving the issue.

Each Citrix Virtual Apps and Desktops (Citrix Virtual Apps and Desktops) release is supported on different Windows Operating Systems and SQL versions. You can review the product documentation for the latest LTSR to view what is supported. A notable callout is that Citrix Virtual Apps and Desktops 1912 LTSR is the last LTSR version to support Windows Server 2012 R2. If you have any applications still dependent on 2012 R2 or earlier, start planning that upgrade now.

While Citrix LTSRs are backward compatible for interoperability (e.g. 1912 VDAs can register with 2203 Delivery Controllers), machines with the 1912 software installed (infrastructure and VDA servers) will not be supported past the EOL date. Many features are VDA-dependent. For the best possible performance and security we recommend keeping your LTSR environments as “pure” and compliant as possible within a single version.

New Features

The best part of a new LTSR is the feature set introduced to the longer maintenance cycle. Generally, most of the prior Current Release (CR) features roll up into the LTSR version. To review the features released in the CR version, refer to our LTSR to CR product matrix. You can also refer to the ‘What’s New’ section of our documentation for our various products, such as Citrix Virtual Apps and Desktops, WEM, and Linux VDA. In general, new features or policies are off by default, but reviewing and testing new features is essential - policy settings especially!

Investigating any new features that may be a good fit for your environment or use cases is important. To test these features, you can install the latest version of the CR in your test environment before the LTSR release. Testing the CR gives you access to most new features that will be released under the LTSR. You can view our Tech Paper on DaaS testing for some examples and guidelines on testing.

Migration

To view the steps to build a new site, refer to our product documentation. Once the infrastructure of the new site has been set up, the process of migrating site configurations, VM images, and users over to the new site can begin.

There are two different ways to migrate a parallel site. One option is to migrate the access tier before the resources, and the other is to migrate everything simultaneously. Access migrations will be discussed in further detail in the next section.

Access Layer

For parallel builds, the access tier migration is the one with the most impact on the end users.

NetScaler

NetScaler has a separate update and lifecycle than Citrix Virtual Apps and Desktops. Your NetScaler may not need to be upgraded in tandem with the virtualization environment.

If your NetScaler is up-to-date with patches and is still supported, you can continue using your same appliance. If you use NetScaler load balancing, new load balancing VIPs need to be created for the new Site (for StoreFront, Delivery Controllers, Director, etc.). You can create a new NetScaler Gateway or plan to continue using the current production Gateway. Considerations around URLs are discussed in a later section. As always, if you’re changing a production appliance, you should make sure that the existing configurations are backed up before making changes.

If you decide to stand-up a new NetScaler appliance, you can either rebuild the configuration manually or import the configuration from the existing appliance. Considerations around URLs are discussed in a later section.

StoreFront

When performing a parallel Site migration you can either continue using your existing StoreFront (and upgrade it in place) or build a new, separate StoreFront.

If you’re upgrading in place, this upgrade must be done during a maintenance window. It’s also recommended to back up any customizations to any files, such as the web.config, default.ica, script.js, etc. These customizations will need to be re-implemented after the in-place upgrade. You can then add the new parallel Site into the StoreFront and use Site Aggregation settings to test and then migrate users to that site. These steps are discussed further in the later section.

If you’re building a net-new StoreFront, you can import the configuration from the current production environment, or you can build from scratch. If you allow favorites within your Stores, you must migrate those subscriptions to the new environment.Or you can enable a subscription sync between the server groups. If you use mandatory stores, you do not have to worry about migrating subscriptions. If you plan on migrating the access tier first in your migration method, you can also add the old production Site. Using site aggregation, you can migrate users to the new Site in a phased approach.

New vs Same URL

There’s a crucial decision to be made for the access tier: whether to maintain the same access URL or use a different URL for the new site. There are pros and cons to both options.

	Pros	Cons
Same URL	Less impact to the end users	Harder rollback should something go wrong
		Harder to do a phased migration (use redirection of groups, advanced DNS forwarding, etc.)
Different URL	Can conduct a phased migration to the new site	Requires new firewall rules, certificates, NetScaler configurations, etc.
	Easier rollback to old URL if things go wrong	May cause confusion to end users, more help desk ticekts, require end-user communications

While this section mostly specifies external connections via NetScaler, the content can also be applied to direct, internal connections via StoreFront.

Same URL

If you plan on using the same URL for the production users, a different temporary URL is required to allow test users to access the environment. This URL should be distributed to test users and administrators for access during testing. This testing should be completed via a test or development NetScaler.

Once the testing is complete, it’s crucial to back up your NetScaler configurations before making any changes for easy rollback. Update your NetScaler Gateway URL to your existing access URL and repoint your DNS records to this new Gateway vServer. If your users are accessing directly via StoreFront, you can update your StoreFront base URL and update the DNS records for the StoreFront servers or StoreFront load balancers.

Note:

Users accessing via a web browser may have the old DNS record cached on their machines. This means they can still access the old NetScaler Gateway URL until their DNS cache is cleared.

Once the end users have been migrated, monitor the help desk and support tickets for end-user feedback. If there are any concerns or issues, a rollback may be necessary. You can read more about rollback communications and migration preparation in our Tech Paper on End User communications. Once the migration has been completed and considered successful, you can begin decommissioning the legacy site.

New URL

If you plan on using a different access URL, your test users can use this new URL to test with . This URL must be communicated to test users for end-user testing.

Once testing is complete, it is time to migrate the end users. With a separate URL, you can consider implementing a phased migration. This method can be preferable as you can slowly roll out the new environment and address any issues on an ongoing basis. Phased migrations help make sure that your help desk isn’t overwhelmed with tickets. In the event of a rollback, fewer users are affected.

There are two different ways to do a phased rollout. One way is to migrate all users to the new URL and use site aggregation to continue to use the old site's resources. You can then migrate users to the new site over time by adjusting the aggregation settings. When done correctly, the users cannot tell they are accessing new resources.

The second way to do a phased rollout is to migrate to the new access tier, which points to the new site. To force users to use the new environment, you can consider removing their access from the old environment. Removing access can be done by disabling their applications or removing the AD group from the old Delivery Group. Removing access makes sure they have to use the new site and can’t use the legacy environment. You can also set up a DNS forwarder on the NetScaler to forward users to their new site. DNS forwarding can be done on a subnet level or implemented across all users.

Migration Path

As you can tell, there are quite a few options for migrating your access tier in a parallel Site build. This diagram walks through the decision tree for the most common pathways.

Because of the flexibility of our technology, there are many ways to migrate that aren’t captured in this documentation. If you have questions about migrating your specific environment, contact your Citrix representative or trusted partner.

Control Layer

The control layer comprises the core Citrix infrastructure components that make up a Citrix Site, as well as other core supporting technologies like Microsoft infrastructure.

Licensing

Licensing is a crucial part of a Citrix site. On the Citrix side, you can upgrade your license server to the newest version, and point both the old and new sites to the server. If you prefer to keep things separate or are moving to new hardware, you can stand up a new License Server for the new site.

During testing, you can re-allocate a portion of your licenses to the new site to support test users. During the migration process, you can have two different licensed sites using the same licensing file for up to 90 days per the EULA. You can also use the license grace period to aid in the migration of the licenses.

If you’re using multi-session VDAs, you need Microsoft RDS licenses to support your environment. If you’re upgrading the OS of your VDAs in tandem with this migration, be sure to update your RDS CALs. You can continue to use your production RDS License server for your new environment, provided it has enough licensing capacity. Depending on your organizational goals, you can stand up a new RDS License server.

Active Directory

It’s recommended that you have a separate section of your OU for the new Site. This helps make sure that it is easy to track and administer the new site from an AD perspective. After creating this OU, evaluate and migrate any required GPOs that will be needed. Some examples of GPOs to be implemented are profile GPOs, drive mappings, optimizations, exclusions, etc.

Some GPOs need to be tweaked for the new environment. For example, if you use a ListofDDCs GPO for VDA registration, you need to make sure that the policy for the new environment points towards the new Delivery Controllers.

Delivery Controllers

Once your new LTSR Delivery Controllers (DDCs) have been set up, the site configuration must be migrated.

If you are migrating to 2305 and above, you can use our Automated Configuration Tool (ACT) to migrate your site information to your new build. See our POC guide for steps on how to complete that migration. The ACT can migrate all aspects of the site, including hypervisor connections, policies, delivery groups, and so on. The ACT can also be used to back up the existing configuration. There are some limitations on what it can migrate (like Machine Creation Services catalogs), so review our product documentation to see the limitations. See our guide if you want to migrate the site configuration more granularly.

If you do not want to use the ACT, for example, if you are making significant changes to your site or want to start with a clean slate, you can manually migrate configurations.

Resource Layer

The resource layer for your parallel build generally involves net-new VDAs deployed via the new site infrastructure. There are different considerations for the different VDA types.

Citrix Workspace app

It’s critical to keep your Citrix Workspace app up-to-date for both security and feature functionality. Often, new features depend on a minimum version of the Workspace app. Review our lifecycle matrix to see if your Workspace app version is still supported.

Citrix Workspace can be updated via the Global App Config service. This service is available for both DaaS and Citrix Virtual Apps and Desktops customers. It can be used to prompt for app updates across both managed and BYOD devices. It can also be deployed using other methods such as SCCM.

Manual VDAs

Any manual VDAs (or VDAs not using Citrix image management) need to be re-created within the new site when doing a parallel migration. If you use dedicated, persistent machines (including MCS made persistent machines), those machines can be updated in-place. These machines require the new LTSR VDA installer and should register with the LTSR DDCs when you are ready for users to access the new site.

Remember to implement any image optimizations as necessary, such as Citrix Optimizer, AV Exclusions, Microsoft Teams Optimization, etc.

Machine Creation Services VDAs

When migrating Machine Creation Services (MCS) non-persistent VDAs, you can replicate or clone the golden images from the legacy compute infrastructure to the new infrastructure. These golden images should be updated with the new LTSR VDA. You can then use these golden images to deploy new MCS catalogs into the LTSR site.

Citrix Provisioning VDAs

After setting up the Citrix Provisioning (PVS) farm in your new site, you can migrate the vDisk images. You can export the images from the old farm and import them into the new one. Once in the correct farm, complete the VDA and PVS target device software upgrade on the image via this process. Once the vDisk images have been updated, you can create and begin streaming to target devices.

App Layering

Ensure that your App Layering appliance is upgraded to a compatible version for the LTSR. For App Layering-based images, create a new Platform Layer with the new version of the VDA installer. Then, publish a new image with that layer to use in the new environment. This method supports creating MCS and PVS machines based on the App Layering image.

Site Testing

Before onboarding users, the new environment needs to be validated from an infrastructure and end-user perspective.

Functional Testing

Before introducing test users to the environment, conduct functional testing of the new site. This testing should involve high availability (HA) configurations like Local Host Cache and infrastructure VM failover. Testing of basic functionality like authentication, enumeration, and launching, targeted features, and policy settings should be conducted at this stage. Examples of items to be tested can be found in our DaaS Test Plan. While some information is DaaS specific, the methodology and things tested also apply to Citrix Virtual Apps and Desktops configurations.

End User Testing

Once functional testing has been completed, it’s time for the end users to test the environment. Test users must validate the workflows for all the use cases in the environment. This testing should include access to peripherals, required data, printing, and dependent applications. Anything a user requires to complete their job function needs to be tested. For further details about user testing and how to communicate changes to users, refer to our End User Communications Tech Paper. The next section will cover details about how to give test users access to the LTSR site.

Summary

A new LTSR allows you to revamp and refresh your Citrix environment. Following this guide ensures that your environment is compatible and ready to implement the new features according to established leading practices. A smooth transition helps make sure end-user satisfaction and reduces the burden on infrastructure teams.