XenApp/XenDesktop Upgrades

Navigation

• XenApp/XenDesktop Versions
  • Version Numbering
  • Release Notifications
  • Release Classifications – LTSR, CR
  • LTSR Programs
  • LTSR Licensing requirement
  • LTSR vs CR
    • Release Frequency
    • CR cons
    • LTSR cons
    • XenApp/XenDesktop Supported versions
    • Receiver Supported versions
  • Component Version Dependencies
• 7.x Upgrade Overview
  • 7.x Components
  • Component Upgrade Process
  • Upgrade Guidelines
• Upgrade XenApp/XenDesktop 7.x
  • Citrix Licensing Server
  • Delivery Controllers
  • App Layering (Unidesk)
  • Workspace Environment Management (WEM)
  • Session Recording
  • Provisioning Services (PvS)
  • Virtual Delivery Agents (VDA)
  • StoreFront
  • Director
  • Citrix Group Policy Management Plug-in
  • Profile Management Group Policy Templates
  • Receiver Group Policy Templates
  • Receiver
  • AppDNA
  • SCOM Management Packs
  • Federated Authentication Service (FAS)
  • Customer Experience Improvement Program (CEIP)
  • NetScaler Firmware
• Migrate From XenApp 6.5 to XenApp/XenDesktop 7.x
  • 6.5 to 7.x Considerations
    • Citrix XenApp licensing
    • VDA/Worker Operating System Version
    • New functionality in 7.x not available in 6.5
    • 6.5 to 7.x Changes
    • XenApp 6.5 functionality missing from XenApp/XenDesktop 7.x
  • Migrate from Web Interface to StoreFront first
    • StoreFront vs Web Interface
    • NetScaler Gateway vs Secure Gateway
    • Build StoreFront and NetScaler Gateway
    • Migrate from Web Interface to StoreFront
  • 6.5 to 7.x Migration Plan
    • New 7.x Infrastructure
    • New 7.x VDAs
    • Publish Icons, Pilot, Rollout, and Operations

XenApp/XenDesktop Versions

Version Numbering

The current versions of XenApp/XenDesktop are collectively known as 7.x, with the .x ranging from 7.0 through 7.14.

Since upgrading from 7.x to 8.x is perceived as a major upgrade, Citrix has no immediate plans to change the version to 8.x.

7.x upgrades are considered minor, and thus less resistant to upgrading/updating.

Release Notifications

Follow my Twitter or EUC Weekly Digests for new release notifications.

Sometimes release notifications are posted to Citrix Blogs, but this is far from comprehensive.

Watch Citrix Discussions and Citrix Support Knowledgebase to learn about known issues that are fixed in a later release.

Release Classifications – LTSR, CR

There are three classifications for on-premises releases:

• LTSR (Long Term Service Release) – these releases get 5 years of mainstream support, plus up to 5 more years of extended support
• CR (Current Release) – 6 months support. Updated quarterly.
• LTSR Compatible – Current Releases supported when running in a LTSR implementation. Normally all components must be LTSR versions. But this classification provides exceptions.

Citrix Cloud XenApp and XenDesktop Service releases are always Current Release. There is no LTSR option.

LTSR Programs

There are two different LTSR programs:

• XenApp/XenDesktop/XenServer LTSR – includes StoreFront, Provisioning Services, and Session Recording.
  • FAQ – https://support.citrix.com/article/CTX205549
• Receiver LTSR
  • More info at https://www.citrix.com/support/product-lifecycle/milestones/receiver.html.

LTSR Licensing requirement

LTSR requires you to be on Customer Success Services Select, formerly known as Software Maintenance.

LTSR vs CR

LTSR is supported for 5 years from the LTSR release date, plus 5 more years of optional extended support.

Only the two most recent CRs are supported.

• Don’t install CR if you don’t intend to upgrade every 6 months. Receiver too.
• You might assume that LTSR does not need to be upgraded. However, Cumulative Updates (patches) for LTSR are released periodically. Cumulative Updates for LTSR are installed exactly like upgrading to a newer CR, except you don’t get any new features.
• For XenApp/XenDesktop, you can migrate to Citrix Cloud XenApp/XenDesktop Service, and let Citrix upgrade Controllers, StoreFront, Director, and NetScaler Gateway for you.
• Or a managed services provider can do the upgrades for you.

Not supported means that Citrix Support will ask you to upgrade before they troubleshoot an issue.

Release Frequency

New LTSR versions are released every 18-24 months. Prior LTSRs are still supported for the full 5 years. New LTSR version gets new 5 year support from the new release date.

• Currently only LTSR 7.6.300 is available.
  • This post will refer to LTSR 7.6.300 as LTSR 7.6.
  • 7.6.300 has more features than base 7.6.0.
• Sometime in 3Q 2017, a new LTSR 7.15 will be released. See Citrix Blog Post XenApp and XenDesktop 2017 Release Schedule.

Cumulative Updates (CU) for LTSR are released every few months. Don’t forget to install these patches. I’ve seen CUs fix LTSR issues.

• CUs do not include new features.
• Citrix has released four Cumulative Updates for LTSR 7.6.300, bumping up the version to 7.6.4000.
• After LTSR 7.15 is released, Citrix will continue to release Cumulative Updates for LTSR 7.6.300.

New CR versions are released every quarter. Sometimes longer for Receiver. See Citrix Blog Post XenApp and XenDesktop 2017 Release Schedule.

Citrix Cloud XenApp and XenDesktop Service gets new CR releases every 3 weeks.

CR cons

New CRs add new features, and new bugs.

• The initial release of XA/XD CR 7.14 had some issues which required it to be pulled and re-released.
• CR 7.13 had issues (e.g. VDA registration error message), that weren’t fixed until 7.14.

No hotfixes will be released for CR. To get hotfixes, upgrade to the newest CR.

LTSR cons

Features not in LTSR – Personal vDisk and Local App Access are not included in LTSR 7.6. To use these features, you must deploy CR 7.x.

• Note: Personal vDisk will eventually be replaced by App Layering User Layers.

Features in CR but not LTSR – Many features have been added to CRs since LTSR 7.6 was released.

• If you want Long Term Support, then you won’t get these new features until the next LTSR.
• If you really need the new features, then you upgrade everything to CR.

XenApp 6.5 features added to CR but not LTSR – Much prior XenApp 6.5 functionality was added to CRs released after LTSR 7.6 – e.g. zones/local host cache, app limits, multiple license types, tags, idle time in Director, TLS 1.2. These features are not in the current LTSR 7.6. If you want these features, you’ll either have to wait for the next LTSR, or go with CR.

Don’t mix CR and LTSR components – As soon as you upgrade one LTSR component to CR, upgrade all other LTSR components to CR, and keep them updated with new CRs every 6 months.

• When the next LTSR is released, you can stop upgrading (except for Cumulative Updates).
• Or, deploy CR in a separate environment.
• Use Citrix LTSR Assistant tool to confirm LTSR compliance.
• Some app vendors require you to remain on LTSR.

Avoid temptation to upgrade to CR? – The only LTSR available today is 7.6 Feature Pack 3. In 3Q 2017, new LTSR version 7.15 will become available. LTSR 7.15 will be based on the features in CR 7.14. CR 7.16 will have new features that are not in LTSR 7.15. When you see the list of new features in 7.16, will you:

• Upgrade to CR 7.16, and every CR after that?
• Or, stay with LTSR 7.15, and not get the new features until the next LTSR release, probably in 2019?

LTSR “compatible” components require frequent upgrades – Some components, like Profile Management, are LTSR “compatible”, meaning there’s no LTSR version, but it’s OK to use them in an LTSR environment. Since they’re not CR, you’re expected to update the CR components to the latest release every 6 months.

• There’s no LTSR version of Citrix Licensing. Instead, always upgrade Citrix Licensing to the latest CR version.
• For Windows 10 support on LTSR 7.6, install the latest CR VDA, which is currently VDA 7.14. Other OS versions must use LTSR VDA 7.6.
• Each LTSR VDA 7.6 Cumulative Update includes newer Profile Management. 7.6.4000 includes Profile Management 5.8.

XenApp/XenDesktop Supported versions

The most recent XA/XD LTSR is based on version 7.6.300 (aka 7.6 Feature Pack 3).

• Several XA/XD LTSR Cumulative Updates have been released, resulting in version number 7.6.4000. The .4000 indicates the patch level, while 7.6 indicates the feature level.

The most recent XA/XD Current Release is version 7.14.

• There have been at least seven CR releases since XA/XD LTSR 7.6.300.

Examples of non-supported versions:

• XenDesktop 7.6.0 is older than LTSR 7.6 (7.6.300), so it’s not supported.
• XenDesktop 7.9 is a CR that’s newer than LTSR, but more than two releases behind the most recent CR (7.14), so it’s not supported.

Not supported means that Citrix Support will ask you to upgrade before they troubleshoot an issue.

Receiver Supported versions

The most recent Receiver LTSR is based on version 4.4.

• Several Receiver LTSR Cumulative Updates have been released, resulting in version number 4.4.5000. The .5000 indicates the patch level, while 4.4 indicates the feature level. See Citrix CTX200322 Additional Lifecycle Information for Citrix Receiver for Windows.

The most recent Receiver Current Release is version 4.8.

• There have been at least four CR releases since Receiver LTSR 4.4.

Component Version Dependencies

Director uses the Citrix Monitoring Service that is installed on the Delivery Controllers. New Director features don’t work unless Delivery Controllers, and sometimes VDAs are upgraded. See CTX224793 for details.

Provisioning Services – if you use the XenDesktop Setup Wizard, then PvS servers should be the same version as the Controllers. Otherwise, PvS version is independent of XenDesktop version.

Workspace Environment Management (WEM) – newer WEM can configure newer Profile Management features. Otherwise, WEM is separate from XenDesktop.

SCOM Packs should be the same version or newer than the components they are monitoring. Check each SCOM Pack release notes for supported component versions.

Receiver – Many XenApp/XenDesktop features require a specific version of Receiver. If you are deploying CR releases, then deploy the newest CR Receiver. If you are deploying LTSR 7.6 Cumulative Updates, then deploy the latest LTSR Receiver.

NetScaler  Gateway – Some Newer Citrix features require newer NetScaler Gateway firmware. For example:

• EDT (Enlightened Data Transport) / Adaptive Transport
• Gateway Configuration export/import with StoreFront
• Newer Receivers are checking SSL certificates more stringently. You might have to adjust your NetScaler certificates to accommodate newer Receivers. See CTX223949.

NetScaler builds have bugs that affect XenApp/XenDesktop experience.

• Currently, NetScaler 11.1 build 53 or 54 are recommended.
• NetScaler 12 must be avoided at this time.

XenApp 6.5 – The following components don’t have any XenApp/XenDesktop version dependency, and thus can be deployed for XenApp 6.5 too:

• StoreFront
• Provisioning Services
• License Server
• Profile Management
• Skype Optimization Pack
• Workspace Environment Management
• Citrix App Layering (Unidesk)
• SCOM Packs
• AppDNA

7.x Upgrade Overview

7.x Components

XenApp/XenDesktop is composed of multiple components, each of which is upgraded separately.

• Citrix Licensing Server
• Delivery Controllers
• App Layering (Unidesk)
• Workspace Environment Management (WEM)
• Session Recording
• Provisioning Services (PvS)
• Virtual Delivery Agents (VDA)
• StoreFront
• Director
• Citrix Group Policy Management Plug-in
• Profile Management Group Policy Templates
• Receiver Group Policy Templates
• Receiver
• AppDNA
• SCOM Management Packs
• Federated Authentication Service (FAS)
• NetScaler Firmware

Newer versions of Citrix components enable Customer Experience Improvement Program (CEIP) automatically. If you wish to disable CEIP, see http://www.carlstalhood.com/delivery-controller-7-14-and-licensing/#ceip.

Component Upgrade Process

In-place upgrades – 7.x components can be upgraded in-place. No need to rebuild like you did in XenApp 6.5 and older.

Here’s the general in-place upgrade process for each component. Detailed instructions for each component are detailed later.

1. In-place upgrade one (or half) of the component’s servers.
2. Upgrade the component’s database. Requires temporary sysadmin permission on SQL Server. Not all components have databases.
3. In-place upgrade the remaining component’s servers.
4. In-place upgrade the agents.
   1. Rebuilding of master images might be preferred, assuming you have time to automate it.

Mix and match VDA/Controller versions – You can upgrade VDAs without upgrading Controllers. Or vice versa.

• Newer VDA features sometimes require Citrix Policy to enable or configure. The newest Citrix Policy settings are included in Controller upgrades. Or, if you haven’t upgraded your Controllers yet, you can simply upgrade the Citrix Group Policy Management component.

VDA Operating System version Upgrade – Considerations when upgrading the VDA operating system version:

• App compatibility – Verify app compatibility with the new OS version:
  • Windows 2012 R2 = 64-bit Windows 8.1
  • Windows 2016 = 64-bit Windows 10
• Start Menu in published desktop – If you publish desktops, is the Windows 2012 R2 Start Menu acceptable to the users? Windows 2012 R2 Start Menu is the same as Windows 8.1 Start Menu.
  • Windows 2016 Start Menu is the same as Windows 10 1607 Start Menu
• GPO settings– Newer OSs have newer Microsoft GPO settings.
  • Copy the newer Microsoft ADMX templates to PolicyDefinitions (Sysvol or C:\Windows)
  • Configure the newer GPO settings.
• Profile version – Newer OS means newer profile version. Older profile versions do not work on newer operating system versions. For example, you can’t use Windows 7 profiles on Windows 10. This means that an OS upgrade results in new profiles for every user.
  • Write a script to copy profile settings from the old profiles to the new profiles.
• Remote Desktop Services (RDS) Licensing – if you are building RDSH (Server OS) VDAs, then every user that connects must have an RDS License for the RDSH operating system version. If RDSH is Windows 2016, then every user needs a Windows 2016 RDS License. Windows 2008 R2 RDS Licenses won’t work.
  • RDS Licensing Server – RDS Licensing is a built-in Windows Server Role. It must be installed on servers with the same or newer operating system version than the RDSH VDAs.
• Windows 10 Branches – Windows 10 Current Branch is not supported. CBB and LTSB are supported. See CTX224843.
• Upgrade Windows 10 Version – In-place upgrade of Windows 10 versions is not recommended. For example, upgrading from Windows 10 1511 to Windows 10 1607 broke several features. Rebuild is cleaner.
• Component Agents – ensure the component agents (WEM Agent, Profile Management, Session Recording Agent, App Layering Tools, etc.) are supported on the new OS version.

Considerations for upgrading the operating system version on component servers:

• Do not in-place upgrade the operating system version. Instead, build new VMs, and join them to the existing infrastructure.
• New OS version requires newer component versions. The required component version might be newer than what you’re currently running.
• When adding a server to the existing component farm/site, the new server must be running the same component version as the existing servers. That means you might have to in-place upgrade your existing component servers before you can add new components servers running a newer operating system version.
• For example:
  • Existing Delivery Controllers are version 7.9 on Windows 2012 R2.
  • You desire to build new Windows 20126 Delivery Controllers.
  • Only Delivery Controller 7.11 and newer can be installed on Windows 2016. But you can’t add Delivery Controller 7.11 to a Delivery Controller 7.9 farm/site.
  • Upgrade the existing Delivery Controllers to 7.11 or newer first.
  • Then you can add the new Windows 2016 Delivery Controllers VMs to the existing farm/site.

Here are general instructions to upgrade component server OS version. Detailed instructions for each component are detailed later.

1. In-place upgrade the existing component servers to a version that supports the new OS. Check the System Requirements documentation for each component to verify OS version compatibility.
2. Build new machine(s) with desired OS version.
3. Install the same component version as the existing component servers.
   • The new machine must be the same component version as the existing machines. You can’t add machines with newer component versions.
4. Add the new component servers to the existing farm/site/server group.
5. Migrate load balancer, VDAs, Targets from old to new. See below for detailed instructions for each component.
6. Decommission old servers.

Upgrade Guidelines

Test farms – Test Citrix infrastructure upgrades in separate test environments (separate test farms):

• VDA upgrades can usually be tested in production
• Everything else requires server-side upgrades first, so you can’t test them in production.
• Should the separate Test environments include multi-datacenter capabilities (StoreFront icon aggregation, GSLB, etc.) so those features can be tested?

Known upgrade issues – Read Citrix Discussions, or ask your Citrix Support TRM, for known upgrade issues. Don’t upgrade production immediately after a new version is released.

• Read the release notes, especially the known issues.

Smart Check the environment before upgrading. It’s free. Access it at https://smart.cloud.com.

Backup/snapshot – Backup databases, snapshot machines, etc. before starting the in-place upgrade.

• Have a rollback plan

License Server – Always upgrade the License Server before upgrading anything else.

• Check Subscription Advantage (SA) date on the installed licenses

In-place upgrade preparation:

1. Make sure other admins are logged off before starting the upgrades.
2. Close all consoles and PowerShell.
3. Snapshot the machines.

Upgrade XenApp/XenDesktop 7.x

All 7.x components can be upgraded in-place.

• CR upgrades are cumulative. You can skip intermediary versions.
• LTSR Cumulative Updates are also cumulative, hence the name.
• LTSR Cumulative Updates are performed using the same process as CR upgrades. The only difference is that you don’t get new features with LTSR updates.

Some components (Delivery Controllers, PvS, Session Recording, WEM, etc.) require the person doing the upgrade to have temporary sysadmin permissions on the SQL server so the database can be upgraded.

Upgrade order – For the most part, upgrade order doesn’t matter. That’s because there are few dependencies between each component, as detailed earlier.

• Before upgrading anything else, upgrade the Citrix License Server.
  • Install updated license files with non-expired SA dates.
• VDAs and Delivery Controllers can be different versions.
  • VDAs can be upgraded before Controllers, or vice/versa.
• If Zones, upgrade all Delivery Controllers in all zones at the same time
• For Director, upgrading Director won’t do you much good if the Controllers aren’t upgraded, since Director uses the Monitoring service that’s installed on the Controllers.
• For PvS, the servers must be upgraded before you upgrade the targets.
• For Session Recording, the server(s) must be upgraded before you upgrade the agent.
• For WEM, the server(s) must be upgraded before you upgrade the agent.

If upgrading to a version that has CEIP functionality, decide if you want to disable CEIP, or leave it enabled.

After upgrades, configure new functionality.

Citrix Licensing Server

It’s a simple in-place upgrade.

• After upgrading, download the latest license files from http://mycitrix.com, and install on the license server. Make sure the SA date hasn’t expired.

To upgrade the Licensing Server Operating System version:

1. Build a new VM with desired OS version.
2. Install the latest CR License Server.
3. At http://mycitrix.com, reallocate licenses to the new case-sensitive hostname, and install the license file on the new Licensing Server.
4. For 7.x sites/farms, in Citrix Studio, go to Configuration > Licensing, and change the License Server to the new Licensing Server.
5. For XenApp 6.5, in AppCenter > Policies, or a GPO with Citrix Policies, find the Citrix Policy that defines the Licensing Server name, and change it.
   1. Or, run the XenApp Server Role Manager on each server and change Licensing configuration.

Delivery Controllers

Both of the following types of upgrades/updates use the same process:

• Install latest LTSR Cumulative Update
• Upgrade to latest Current Release

To in-place upgrade Delivery Controllers:

1. If High Availability is configured correctly, then Delivery Controllers can be upgraded during the day.
2. Upgrade the Citrix Licensing Server if you haven’t already. Install current licenses if you haven’t already.
3. Ask a DBA for temporary sysadmin permission to the SQL server.
4. Prepare: run Smart Check, logoff other admins, close consoles.
5. In-place upgrade one (or half) of the Delivery Controllers. Either upgrade to the latest Current Release, or install the latest LTSR Cumulative Update.
6. Launch Studio. Upgrade the database when prompted.
7. In-place upgrade the remaining Delivery Controllers.
8. Run Smart Check again.
9. Temporary sysadmin permissions can now be removed.
10. For Studio that’s installed on administrator machines other than Delivery Controllers, in-place upgrade Studio by running AutoSelect.exe from the CR or LTSR XenApp/XenDesktop ISO.

To upgrade the operating system version of the Delivery Controllers:

1. In-place upgrade the existing Delivery Controllers to a version that supports the new operating system version. For Windows 2016, upgrade to version 7.11 or newer.
2. Build one or more new virtual machines with the new operating system version.
3. Install Delivery Controller software with the same version as the other Delivery Controllers.
4. Run Citrix Studio and join the new machines to the existing farm/site.
5. Push SCOM Agent with XAXD Agent to the new Delivery Controllers.
6. Reconfigure VDAs to point to the new Delivery Controllers. Edit the ListOfDDCs registry key.
7. Reconfigure Director server > IIS > Application Settings > Director path > Service.AutoDiscoveryAddresses to point to the new Delivery Controllers.
8. Reconfigure StoreFront > Store > Manage Delivery Controllers to point to the new Delivery Controllers.
9. Secure Ticket Authorities:
   1. Add the new Controllers to firewall rules between NetScaler SNIP and STAs.
   2. In NetScaler Gateway > Edit Virtual Server > scroll down to the Published Applications section > click the line to edit the Secure Ticket Authorities. Add the new Controllers as Secure Ticket Authorities. Don’t remove the old ones yet.
   3. In StoreFront Console, go to Manage NetScaler Gateways > edit each Gateway > on the Secure Ticket Authority page, add the new Delivery Controllers as Secure Ticket Authorities, and remove the old ones.
   4. In NetScaler Gateway > Edit Virtual Server > scroll down to the Published Applications section > click the line to edit the Secure Ticket Authorities. Remove the older Controllers as Secure Ticket Authorities.
10. In Studio, remove the old Delivery Controllers.
    1. Note: this might not fully work and you might have to manually evict the old Controllers from the SQL database.
11. Decommission the old Delivery Controllers.

App Layering (Unidesk)

To in-place upgrade Citrix App Layering:

• In-place upgrade the ELM appliance.
  • From 4.2 and newer, newer versions should be downloaded automatically. Just click the link to start the upgrade.
  • From 4.1 and older, download the upgrade package and upload it to the ELM.
• Upgrade the App Layering PvS Agent by uninstalling the PvS Agent and re-installing it.
• Create a new OS Layer version and install the latest OS Machine Tools.
• When the images are published, the drivers will be updated automatically by the ELM.

Workspace Environment Management (WEM)

To in-place upgrade Citrix Workspace Environment Management (WEM):

1. In-place upgrade the Citrix Licensing Server if you haven’t already.
   1. Ensure the installed licenses have a non-expired Subscription Advantage date.
2. Ask a DBA for temporary sysadmin permission to the SQL server.
3. In-place upgrade the first WEM Server. Consider removing it from load balancing before performing the upgrade.
4. Use the Database Maintenance tool to upgrade the WEM database.
5. Run the WEM Broker Configuration Tool on the upgraded Broker to point to the upgraded database.
6. In-place upgrade the remaining WEM Servers. Consider removing them from load balancing before performing the upgrade.
7. Temporary sysadmin permissions can now be removed.
8. In-place upgrade the WEM Console on all non-server machines where it is installed.
9. In-place upgrade the WEM Agents.
10. If you are upgrading from WEM 4.2 and older, in the WEM Console, add the Agents (computer accounts) to Configuration Sets instead the old WEM Sites.

To upgrade the operating system version of the Workspace Environment Management servers, it’s easier if you have a custom DNS name, or load balanced DNS name for WEM, instead of using a server name :

1. In-place upgrade the existing WEM servers to a version that supports the OS you intend for the new WEM servers.
2. Build new WEM servers with the same version as the existing WEM servers.
3. Configure the new WEM servers to point to the same database as the old WEM servers.
4. Cutover options:
   1. If you have a load balanced DNS name for WEM, reconfigure the load balancer to point to the new WEM servers.
   2. If you have a custom DNS name for WEM, change it to resolve to the new WEM server’s IP address.
   3. If you were previously using the actual server name, then you can either change the WEM Agent group policy to point to the new WEM server name, or delete the old WEM server and rename the new WEM server, or delete the old WEM server and reconfigure the old DNS name as a custom DNS name for the new WEM server.
5. Decommission the old WEM servers.

Session Recording

To in-place upgrade Session Recording:

1. In-place upgrade the Citrix Licensing Server if you haven’t already.
   1. Ensure the installed licenses have a non-expired Subscription Advantage date.
2. Ask a DBA for temporary sysadmin permission to the SQL server.
3. In-place upgrade the first Session Recording server to either the latest CR release or the latest LTSR release.
   1. There is an LTSR version of Session Recording. The install/upgrade process for LTSR is quite different than CR 7.14 and newer.
   2. Consider removing the Session Recording server from load balancing before performing the upgrade.
4. The upgrade of the first Session Recording server should automatically upgrade the database.
5. In-place upgrade the remaining Session Recording Servers. Consider removing them from load balancing before performing the upgrade.
6. Temporary sysadmin permissions can now be removed.
7. In-place upgrade the Session Recording Agents.
8. In-place upgrade the Session Recording Player on all machines where it is installed.

To upgrade the operating system version of the Session Recording servers, it’s easier if you have a custom DNS name or load balanced DNS name for Session Recording, instead of using a server name:

1. In-place upgrade the existing Session Recording servers to a version that supports the OS you intend for the new Session Recording servers. Windows 2016 support was added to Session Recording 7.11 and newer.
2. Build new Session Recording servers with the same version as the existing Session Recording servers.
3. Configure the new Session Recording servers to point to the same database as the old Session Recording servers.
4. Configure the new Session Recording servers to store recordings on the same UNC path as the old Session Recording servers.
5. The certificate on the Session Recording servers or load balancer must match the DNS name used by the Session Recording Agents and Player.
6. Cutover:
   1. If you have a load balanced DNS name for Session Recording, reconfigure the load balancer to point to the new Session Recording servers.
   2. If you have a custom DNS name for Session Recording, change it to resolve to the new Session Recording server’s IP address.
   3. If you were previously using the actual server name, then you can either: change the Session Recording Agents and Players to point to the new Session Recording server name, or delete the old Session Recording server and rename the new Session Recording server, or delete the old Session Recording server and reconfigure the old DNS name as a custom DNS name for the new Session Recording server.
   4. If the Session Recording DNS name changed, reconfigure Director to point to the new Session Recording DNS name.
7. Decommission the old Session Recording servers.

Provisioning Services (PvS)

Provisioning Services (PvS) servers must be upgraded before you can upgrade Target Devices.

To in-place upgrade PvS servers:

1. Make sure Provisioning Services High Availability (HA) is working for target devices. If HA is functional, in-place upgrade can be done during the day.
   • In the Provisioning Services console, you should see an even distribution of Target Devices across all PvS servers.
   • Check the WriteCache folders on PvS servers to make sure they’re empty. If any Target Device is caching on Server, then those Target Devices will not failover to another PvS server.
2. Get temporary sysadmin permissions to the SQL Server that hosts the PvS database.
3. On the first PvS Server:
   1. In-place upgrade PvS Console by running the CR or LTSR PvS Console installer. There is an LTSR version of Provisioning Services.
   2. In-place upgrade PvS Server by running the CR or LTSR PvS Server installer
   3. Run the PvS Configuration Wizard. The farm should already be configured, so just click Next a few times and let it upgrade the database and restart the services.
4. In-place upgrade the Console and Server software on the remaining PvS Servers. After installation, run the PvS Configuration Wizard, and click Next until the end.
5. Temporary sysadmin permissions can now be removed.
6. Target Device Software can now be upgraded.

There are several methods of upgrading the PvS Target Device Software that’s inside a vDisk:

• If Target Device Software is 7.6.1 or newer, in-place upgrade the Target Device Software while doing your normal vDisk update process.
• Completely rebuild the vDisk. An automated build process like MDT is recommended.
• If Target Device Software is 7.6.0 or older, then you must reverse image.
  • To upgrade VMware Tools (or any software that modifies the NIC), you must revers image.

To in-place upgrade Target Device software 7.6.1 and newer:

1. Create a new vDisk Maintenance version, or put the vDisk in Private Image mode. Then boot an Updater Target Device. This is the normal process for updating a vDisk.
2. Run the CR or LTSR Target Device software installer to upgrade the software. The Target Device software must be the same version or older than the PvS Servers.
3. Shut down the Updater. Promote the Maintenance version to Production, or change the vDisk to Standard Image mode. This is the normal process for updating a vDisk.

Reverse image methods:

• Boot from VHD – Build a VM. Copy PvS vDisk VHD/VHDX to VM. Boot from VHD/VHDX.
• Hyper-V can boot from a VHD directly. Copy PvS vDisk VHD/VHDX to Hyper-V host. Create a VM that boots from VHD/VHDX.
• Once VHD/VHDX is updated, copy the VHD/VHDX back to PvS, import to a PvS store, which creates a new vDisk, and assign the new vDisk to target devices. Takes effect at next Target Device reboot.

If using PvS Accelerator, keep XenServer patched.

To upgrade the operating system version of the PvS Servers:

1. In-place upgrade the existing PvS Servers to a version that supports the new operating system version. For Windows 2016, upgrade to version 7.11 or newer.
2. Build one or more new virtual machines with the new operating system version.
3. Install PvS Server software with the same version as the other PvS Servers.
4. Run PvS Configuration Wizard and join the new machines to the existing PvS farm and PvS database.
5. Copy the vDisk files from an existing PvS Server to the new PvS Servers. Check Replication Status of each vDisk.
6. Install the App Layering PvS Agent.
7. Push SCOM Agent with PvS Agent to the new PvS Servers.
8. In PvS Console, reconfigure Bootstrap to point to the new PvS Servers. Go to Sites > MySite > Servers > right-click each server, and click Configure Bootstrap.
9. Reconfigure DHCP Options or BDM to point to the new PvS Servers. Do one or more of the following:
   • Reconfigure TFTP load balancing to point to the new PvS Servers.
   • Change DHCP Scope Options 66/67 to the new PvS Servers.
   • Create a new Boot ISO with the new PvS Servers.
   • Use the PvS Console to update the BDM Partition on each Target Device.
   • Start the PXE Service on the new PvS Servers and stop the PXE Service on the old PvS Servers.
   • Reboot some Target Devices to make sure they work.
10. In PvS Console, delete the old PvS Servers.
11. Decommission the old PvS Servers.

Virtual Delivery Agents (VDA)

To in-place upgrade the Virtual Delivery Agent software:

• Either in-place upgrade the VDA software to the latest Current Release, or upgrade it to the latest LTSR Cumulative Update.
  • To run Windows 10 VDAs in LTSR 7.6, install the CR VDA on the Windows 10 machines. This means the Windows 10 VDAs must be upgraded every 6 months with the latest CR VDA.
• Upgrade the Workspace Environment Management Agent that’s installed on the VDA machines.
• Upgrade the Session Recording Agent that’s installed on the VDA machines.
• Upgrade the ShareFile Drive Mapper software that’s installed on the VDA machines.
• Upgrade the Connection Quality Indicator software that’s installed on the VDA machines.
• Upgrade the HTML5 Receiver PDF Printer software that’s installed on the VDA machines.
• Upgrade the Chrome Receiver File Access software that’s installed on the VDA machines.
• Upgrade the PvS Target Device software that’s installed on the VDA machines.

Instead of in-place upgrading the VDAs, you can also rebuild them with the new software versions. If rebuilding, use an automated method, like MDT.

To upgrade the operating system version of the Virtual Delivery Agents, it’s recommended to rebuild the VDA. But keep in mind the following:

• Windows 10 Current Branch is not supported.
• Windows 10 version upgrades should be a rebuild, not an in-place upgrade.
  • If you in-place upgrade, uninstall VDA software, upgrade Windows, then reinstall VDA software.
• Newer VDA operating system versions use newer profile versions, which means older profiles will not work.
• Newer RDSH operating system versions require newer RDS Licensing Servers and newer RDS Licenses.
• GPO settings– Newer OSs have newer Microsoft GPO settings.
  • Copy the newer Microsoft ADMX templates to PolicyDefinitions (Sysvol or C:\Windows)
  • Configure the newer GPO settings.

StoreFront

StoreFront is the most problematic component to upgrade.

• Newer CR versions of StoreFront installer are adding pre-upgrade checks to prevent known upgrade issues – e.g. stop SCOM Service

To in-place upgrade the StoreFront servers:

1. It’s critical that you snapshot the StoreFront machines before beginning the upgrade.
2. Prep: close consoles, close PowerShell, logoff other admins, stop SCOM Agent.
3. Remove one StoreFront server from load balancing and run the CR StoreFront installer, or run the LTSR StoreFront installer.
   1. If upgrade fails, review the install logs to determine the cause. Once the cause is determined, revert the VM to prior snapshot, and try the upgrade again.
4. Reconfigure the load balancer to only send traffic to the upgraded server.
5. Upgrade the remaining servers and add them to the load balancer again.
6. If Classic Experience is enabled, consider disabling it. However, this changes the UI in the browser.
7. If Unified Experience is not enabled, considering enabling it. However, this changes the UI in Receiver.
8. Remove snapshots.

To upgrade the operating system version of the StoreFront Servers:

1. In-place upgrade the existing StoreFront Servers to a version that supports the new operating system version. For Windows 2016, upgrade to version 3.7 or newer.
2. Build one or more new virtual machines with the new operating system version.
3. Install StoreFront software with the same version as the other StoreFront servers.
4. Push SCOM Agent with StoreFront Agent to the new StoreFront servers.
5. Run StoreFront Console on the new servers, and join the new machines to the existing Server Group.
   • Note: maximum servers in a Server Group is five. You might have to remove old servers before you can add too many new servers.
6. Reconfigure the load balancer to point to the new StoreFront servers instead of the old StoreFront servers.
7. In StoreFront console, remove the old StoreFront servers.
8. Decommission the old StoreFront servers.

Director

To in-place upgrade the Director servers:

1. Ensure the Delivery Controllers are already upgraded. There’s no point in upgrading Director if Delivery Controllers aren’t upgraded.
2. Run the CR Director install from the CR XenApp/XenDesktop ISO, or run the LTSR Director install from the LTSR XenApp/XenDesktop ISO.
3. Repeat for the remaining Director servers.

To upgrade the operating system version of the Director servers, it’s easier if you have a custom DNS name or load balanced DNS name for Director instead of using a server name :

1. Make sure Delivery Controllers are running a version that supports the OS you intend for Director. For Windows 2016, Delivery Controllers must be version 7.11 or newer.
2. Build new Director servers with the same version or newer than the Delivery Controllers.
3. Configure the new Director servers to point to the same Delivery Controllers as the old Director servers.
4. Copy the Director data files from the old Director servers to the new Director servers. Or point the new Director servers to the existing UNC path.
5. Cutover:
   1. If you have a load balanced DNS name for Director, reconfigure the load balancer to point to the new Director servers.
   2. If you have a custom DNS name for Director, change it to resolve to the new Director server’s IP address.
   3. If you were previously using the actual server name, then you can either inform users of the new Director server name, or delete the old Director server and rename the new Director server, or delete the old Director server and reconfigure the old DNS name as a custom DNS name for the new Director server.
6. Decommission the old Director servers.

Citrix Group Policy Management Plug-in

On any machine that has Group Policy Management installed, in-place upgrade the Citrix Group Policy Management Plug-in by running the installer from the CR or LTSR XenApp/XenDesktop ISO.

Profile Management Group Policy Templates

Profile Management service is included with Virtual Delivery Agent. Upgrading the VDA also upgrades Profile Management.

• There is no LTSR version of Profile Management. The latest LTSR VDA includes the latest CR Profile Management service.

New templates don’t break existing functionality – Upgrading the Profile Management group policy templates will not affect existing functionality. The templates do nothing more than expose new settings that can be configured. If you don’t upgrade the templates, Profile Management will continue to function like it always has.

To in-place upgrade the Profile Management Group Policy Templates:

1. Copy the newer Profile Management Group Policy Templates to the PolicyDefinitions folder: either Sysvol, or C:\Windows on every group policy editing machine.
2. Look for older versions of the templates and delete them. The template files have the version number in their name (e.g. ctxprofile5.8.0.admx). Older Profile Management versions will have different template files with different names (e.g. ctxprofile5.7.0.admx).
3. Edit the VDA GPOs that have Profile Management settings configured. Review the new settings, and configure them, if desired. Review the Profile Management release notes for the list of new features.

Receiver Group Policy Templates

New templates don’t break existing functionality – Upgrading the Receiver group policy templates will not affect existing functionality. The templates do nothing more than expose new settings that can be configured. If you don’t upgrade the templates, Receiver will continue to function like it always has.

To in-place upgrade the Receiver Group Policy Templates:

1. Copy the newer Receiver Group Policy Templates to the PolicyDefinitions folder: either Sysvol, or C:\Windows on every group policy editing machine. Overwrite existing template files.
   1. LTSR Receiver and CR Receiver have different group policy template files.
   2. LTSR group policy template files might not have changed between LTSR Cumulative Updates.
   3. CR Receiver template files include all of the LTSR Receiver settings, plus new settings that don’t apply to LTSR.
2. If deploying a newer CR Receiver version, edit the GPOs that have Receiver settings configured. Review the new settings, and configure them, if desired. Review the Receiver release notes for the list of new features.

Receiver

To in-place upgrade Receiver:

1. Use SCCM or similar to push CR Receiver, or LTSR Receiver, to internal machines.
2. If Receiver is offered directly from StoreFront servers, copy the newer CR Receiver to CR StoreFront, or newer LTSR Receiver to LTSR StoreFront.
   1. StoreFront, by default, does not offer Receiver upgrades to users. Offering of Receiver upgrades can be enabled. If Receiver upgrades are not offered, then Receiver is only provided by StoreFront if there’s no Receiver installed on the client device.
   2. For CR, enable Upgrade plug-in at logon at the same place you upload the Receiver files.
   3. For LTSR, edit C:\inetpub\wwwroot\Citrix\StoreWeb\web.config and set upgradeAtLogin  to true.
3. In Receiver 4.8 or newer, if Auto-Update is enabled, users with permissions will receive an update notification. Users can then manually initiate the Receiver upgrade.
4. Inform remote users to upgrade their Receivers by downloading the CR version from http://receiver.citrix.com.
   1. If Receiver was initially installed as an administrator, then only an administrator can upgrade it.
   2. If Receiver was initially installed without administrator permissions, then each non-admin user on the same machine has a different Receiver installation, and each user has to upgrade it separately.

AppDNA

To in-place upgrade AppDNA:

1. Run the AppDNA installer normally.
2. Run the AppDNA Configuration Wizard and upgrade the database.
3. Run the Modules Wizard to enable new modules.
4. Upgrade the AppDNA Clients (management console) that might be installed on machines other than the AppDNA Server.
5. Upgrade the AppDNA VM Configuration software on the Install Capture Machines.
6. Upgrade the VM Configuration and Self Provisioning software on the Self Provisioning Machines.

To upgrade the AppDNA Server operating system version:

1. Build a new AppDNA server, and point it to the same database used for the first server.
2. Reconfigure AppDNA Clients (management console) to point to the new AppDNA server.
3. Decommission the old AppDNA server.

SCOM Management Packs

Each SCOM Management Pack can be in-place upgraded:

1. From the latest SCOM Pack Bundle, run each management pack installer. At the end of the install wizard, select the option to automatically import the updated management pack.
2. Push the updated SCOM Pack Agent to the following:
   • Delivery Controllers
   • StoreFront
   • Provisioning Services

Federated Authentication Service (FAS)

To in-place upgrade the Federated Authentication Service (FAS) servers:

1. On the existing FAS servers, run AutoSelect.exe from the CR XenApp/XenDesktop ISO, and click the button to install Federated Authentication Service. It’s a simple Next, Next, Next process.
2. Newer versions of FAS might have newer group policy templates. If so, copy them to Sysvol, or C:\Windows\PolicyDefinitions on all group policy editing machines.

To upgrade the operating system version of the FAS servers:

1. Build one or more new FAS servers.
2. Request an Registration Authority certificate for each of the FAS servers.
3. Change the group policy object for FAS to point to the new FAS servers. Run gpupdate on StoreFront and VDAs.
4. Decommission the old FAS servers.

Customer Experience Improvement Program (CEIP)

Newer versions of XenApp/XenDesktop components automatically enable Customer Experience Improvement Program (CEIP). To disable, see the following:

• XenApp/XenDesktop CEIP
• License Server CEIP
• Virtual Delivery Agent CEIP
• Profile Management CEIP
• StoreFront CEIP
• Provisioning Services CEIP
• Receiver CEIP
• Receiver for HTML5 CEIP
• Session Recording CEIP
• AppDNA CEIP
• NetScaler CEIP

NetScaler Firmware

Test appliances – Ideally, NetScaler firmware upgrades should be tested on separate test appliances. VIPs on the test appliances should then be tested.

Downtime if no High Availability – If you only have a single NetScaler appliance, then upgrading the firmware will cause downtime while the appliance is rebooting.

GSLB and mixed versions – If GSLB Metric Exchange Protocol (MEP) is enabled, then the NetScaler appliances on both sides of the MEP connection can run different versions of firmware.

To in-place upgrade NetScaler Firmware:

1. Save the config. Then download a copy of the ns.conf file, or perform a backup of the appliance and download the backup file.
2. On the secondary appliance, install the newer firmware.
3. To test the new firmware, perform an HA failover.
   1. Configuration changes made on the primary appliance will not be synchronized to the secondary appliance until the firmware on the secondary appliance is upgraded.
   2. You can failover HA again to revert to the older firmware.
   3. To downgrade, on the appliance you’ve already upgraded, you can perform the firmware upgrade process again, but this time upload the older firmware.
4. On the primary appliance, install the newer firmware. A HA failover occurs automatically.

Migrate From XenApp 6.5 to XenApp/XenDesktop 7.x

XenApp 6.5 is End-of-life in June 30, 2018. End-of-maintenance (no new patches) after December 31, 2017. See the Lifecycle Announcement.

Citrix has a website devoted to 6.5 to 7.x migrations.

6.5 to 7.x Migration Considerations

Citrix XenApp licensing

Subscription Advantage Expiration date needs to be the same or newer than the 7.x release date.

Software Maintenance or Customer Success Services – Select is required for LTSR.

XenApp licenses can be traded up to XenDesktop licenses.

• XenApp Enterprise doesn’t have PvS, but XenDesktop Enterprise does get PvS.
• XenDesktop licenses add virtual desktops capability.

Mixed license types – In 7.13 and newer, you can mix license types, but not editions, in the same 7.x farm/site.

• LTSR 7.6 only supports one license type for the entire farm/site.

Director licensing – Some Director functionality requires Platinum Edition – e.g. alerting and custom reports

VDA/Worker Operating System Version

Stay with Windows 2008 R2? – Are you staying with Windows 2008 R2 on the 7.x VDAs? If so, you can uninstall 6.5 from the XenApp worker, and install VDA 7.x instead. No need to rebuild.

• One advantage of staying with Windows 2008 R2 is that you can reuse your existing profiles.
• Uninstalling 6.5 and installing VDA avoids a complete rebuild

Upgrade operating system version – If you are upgrading the workers to a newer operating system version:

• Every user will get new profiles.
• Applications must be compatible with the new operating system version.
• If you are publishing a desktop, then Windows 2012 R2 Start Menu is quite different than other operating system versions.
• The VDAs with newer operating system must be rebuilt from scratch.
• Make sure you own Remote Desktop Services CALs that match the newer operating system. Windows 2008 R2 RDS CALs cannot be used with Windows 2012 R2 or newer VDAs.
  • RDS Licensing Server must be the same OS version or newer than the VDAs.

You can mix and match operating system versions in the same 7.x farm/site. Primarily VDAs. But also infrastructure servers.

• One option is upgrade most of your VDAs to a newer OS version, but leave some at 2008 R2 so they can run apps that are not supported in the newer OS versions.
• For 16-bit apps, you can publish them from VDAs running 32-bit Windows 7.

New functionality in 7.x not available in 6.5

The following a selected list of new features in 7.x that wasn’t available in 6.5. Which of these would you like to enable after the upgrade?

• Hypervisor connection (e.g. vCenter) – for virtual machine power management
• Machine Creation Services (MCS):
  • Requires knowledge of hypervisor storage, clusters, etc. And Capacity Planning. Need to work with your hypervisor team.
• VDAs hosted in IaaS Clouds like Azure or AWS
• Virtual Desktops
• App-V integration with Citrix Studio
• EDT protocol (UDP-based ICA)
• GPUs
• Generic USB Redirection in RDSH
• SAML authentication
• Client IP/Client Name access restrictions
• AppFlow
• Remote PC

6.5 to 7.x Changes

Single product – In 7.x, XenApp and XenDesktop were merged into a single product. It’s the same installer for both. The only difference is the licenses. You can use the terms XenApp and XenDesktop interchangeably.

Delivery Controllers – XenApp 6.5 Controllers are now called Delivery Controllers in 7.x.

Virtual Delivery Agents – XenApp 6.5 Workers are now called Virtual Delivery Agents (VDAs) in 7.x. These are the machines that apps are installed on and users actually connect to. They’re called VDAs because you install Virtual Delivery Agent software on those machines.

Controller and VDAs are separate software – In XenApp 6.5, you install the same software on both Workers and Controllers. In 7.x, Delivery Controller software and VDA software are completely different.

VDA types – 7.x supports three types of VDAs: Remote Desktop Session Host (RDSH aka Server OS), virtual desktops (Desktop OS), and Remote PC (physical PCs). XenApp 6.5 primarily only supported one type of worker: RDSH.

• RDSH is the new name for Terminal Services.
• XenApp 6.5 administrators tend to think of the XenApp workers as “XenApp Servers“. Actually, it’s more accurate to call them Microsoft Windows Remote Desktop Session Hosts. Apps run on top of Windows (RDSH), not Citrix. XenApp is installed on top of RDSH. XenApp merely provides ICA connectivity to RDSH, instead of RDP.
• In 7.x workers, Virtual Delivery Agent replaces XenApp.

SQL/Licensing communication – In XenApp 6.5, every XenApp machine, including Workers, connects to database and licensing. VDAs in 7.x no longer talk to database or licensing. VDAs rely on Delivery Controllers to do that. This makes 7.x sites/farms much more scalable than 6.5.

Farm vs site – In XenApp 6.5, all Controllers/Workers that share a database belong to a single Farm. In 7.x, all Delivery Controllers that share a database belong to a single XenApp/XenDesktop site. The terms site and farm can be used interchangeably. However, the term “site” might not clearly indicate that it’s the same as a “farm”.

• VDAs belong to Delivery Controllers in a single site/farm. You use registry values (ListOfDDCs) to control which Delivery Controllers (and site/farm) a VDA registers with.

SQL availability is more important in 7.x. If SQL is down, then the 7.x farm is down. XenApp 6.5 did not have the same level of dependency on SQL.

• Local Host Cache in CR 7.x can maintain most functionality after a database outage. However, LHC is not available in LTSR 7.6.
• AlwaysOn Availability Groups (or Basic Availability Groups or Mirroring) is the preferred SQL HA method.

Zones vs Multiple sites/farms:

• In XenApp 6.5, it was very easy to stretch a farm to multiple datacenters by putting different XenApp 6.5 machines in different zones. That’s because access to SQL database was not particularly important.
• In 7.x, SQL database access is critical, making it difficult to stretch a site/farm across datacenters. CR 7.7 and newer added zones, which were greatly enhanced in CR 7.12 with the addition of Local Host Cache and Zone Preference. CR 7.14 enhanced Local Host Cache even more. There are still some scalability limitations, and missing virtual desktop functionality. And it adds complexity with no savings in the number of machines other than SQL.
• Zones and Local Host Cache are not available in LTSR 7.6.
• The alternative for 7.x is to build a separate XenApp/XenDesktop site/farm in each datacenter, and use StoreFront to aggregate the icons.

Citrix Studio – In XenApp 6.5, you manage the farm using AppCenter. In XenApp/XenDesktop 7.x, you manage the site/farm using Citrix Studio. Both are MMC based consoles.

Director – In XenApp 6.5, help desk uses AppCenter to manage user sessions. In XenApp/XenDesktop 7.x, help desk uses a web-based tool called Director.

• Shadowing from Director uses Microsoft Remote Assistance.
• Director is also used by administrators to view historical performance and usage data.
• Director is similar to EdgeSight, but the monitoring service is built into Delivery Controller, and the monitoring agent is built into the VDA software.

Catalogs / Delivery Groups / App Groups can be confusing concepts.

• You first add VDA machines to a Catalog. You either add existing VDA machines to a Catalog, or MCS/PvS creates VDA machines and puts them in a Catalog.
• You add VDA machines from one or more Catalogs to a Delivery Group.
• You publish apps and desktops from one or more Delivery Groups.
• You aggregate multiple applications into an App Group. App Groups lets you configure identical settings across multiple published app icons. It also controls Session Sharing.
  • App Groups are in CR 7.9 or newer, and not available in LTSR 7.6.

Tags in 7.x simulate Worker Groups in 6.5. You assign a single tag to multiple VDAs. Then you publish an app to a tag, or publish an app to an App Group that has the tag selected. The published app launches on only the VDAs that have the tag. This lets you publish apps on a subset of machines in a Delivery Group, instead of load balancing across every VDA machine in the Delivery Group.

PowerShell commands in 7.x are different than 6.5. All 7.x configuration is performed using PowerShell. Changes made in Studio are actually performed using PowerShell. This focus on PowerShell makes it easy to automate XenApp/XenDesktop tasks (e.g. add a new VDA machine to Catalog and Delivery Group).

XenApp Streamed Applications was removed from 7.x.

• If you want to keep the Application Streaming functionality, then you’ll to need to repackage the streaming applications using Microsoft App-V or similar.
• If you don’t need app isolation, then App Layering Elastic Layers are another option since they are essentially streamed.

Session Recording – XenApp 6.5 Platinum Edition had SmartAuditor. XenApp/XenDesktop 7.x Platinum Edition has Session Recording. The latest CR version of Session Recording can do the following, which weren’t available in SmartAuditor:

• Record both RDSH and Desktop VDAs
• Integrate with Director – can enable or disable recording from Director
• More policy options for starting recording
• Load balance multiple Session Recording servers
• These newer Session Recording features are not available in LTSR 7.6, but instead require newer CR releases.

XenApp 6.5 functionality missing from XenApp/XenDesktop 7.x

Much prior 6.5 functionality was added to CRs released after LTSR 7.6. For example:

• Zones
• Local Host Cache
• App limits
• Multiple license types
• Publish apps on subset of machines in a Delivery Group
• Multiple reboot schedules for a single Delivery Group
• Idle time in Director
• Published Content
• TLS 1.2 in StoreFront

The following 6.5 functionality is still not available in 7.x:

• Custom ICA files:
  • The alternative is to script Receiver Self-Service. This assumes that Receiver is configured to connect to a StoreFront Store.
• SmartAccess per published application:
  • In 7.x, you enable Access Control filters at the Delivery Group level. It’s not possible to configure Access Control at the individual published application.
• Director is quite different from EdgeSight, but every CR release adds more Director functionality.
  • To get full Director functionality,  you need XenApp or XenDesktop Platinum Edition, and the latest CR.
  • Many useful CR Director features are not available in LTSR 7.6.
• Single Sign-on (aka Password Manager)
  • Self Service Password Reset was added to one of  the CR releases, but not LTSR 7.6.
  • The rest of the Single Sign-on functionality is missing from 7.x.

Migrate from Web Interface to StoreFront first

A challenging aspect of migration from 6.5 to 7.x is the StoreFront/NetScaler migration. But once on StoreFront, there should be no more need for major migrations on the client side.

Since StoreFront can connect to both 6.5 farms and new 7.x farms, you should migrate to StoreFront before you migrate the Workers and Controllers to 7.x. StoreFront has features that can help with farm migration:

• StoreFront can aggregate identical icons from multiple farms/sites.
• StoreFront can use AD Group Membership to control access to a farm/site.
• StoreFront can control access and routing to farm/sites and 7.x zones across multiple datacenters.

StoreFront vs Web Interface

StoreFront, Receiver Self-Service, and NetScaler Gateway are a major architectural change from Web Interface/Secure Gateway.

Receiver Self-Service vs PNAgent – If you are currently running PNAgent clients (aka Receiver Enterprise, aka pnagent.exe), then you will have to deploy a newer Receiver that has Self-Service capability. Self-Service is the client side of StoreFront.

• If you install Receiver on a machine that has PNAgent installed, then newer versions of Receiver should be able to remove PNAgent and install Self-Service instead. But this isn’t always successful, and you might have to manually remove PNAgent before Self-Service installs correctly.

Favorites – In StoreFront, users can mark icons as Favorites. The selected Favorites are stored on a database that is replicated to each StoreFront server. Web Interface never had this capability. Do you want to leave Favorites enabled? Or disable it so it’s not too much of a change for migrated users?

HTTPS – Receiver Self-Service and StoreFront require HTTPS.

Discovery – Receiver Self-Service downloads a XML-based discovery document from StoreFront, and uses the XML document to configure itself.

Beacons – Receiver Self-Service uses Beacons to determine if the client machine is internal or external. If external, Receiver Self-Service uses NetScaler Gateway to connect.

• Single FQDN – If you use the same DNS name for both internal and external, then DNS caching might affect machines that roam from internal to external and back again. Another option is to use different DNS names for internal StoreFront and external NetScaler Gateway.

StoreFront Server Group – Multiple StoreFront servers can be combined into a Server Group, which automatically replicates Favorites between each other.

• Configurations can be manually replicated from the StoreFront Console.
• Citrix does not support stretching a single StoreFront Server Group across datacenters. Each datacenter should be a separate Server Group.

Multiple Stores – StoreFront can host multiple Stores, which are somewhat like Web Interface sites.

• Some StoreFront components, like the Base URL, are shared across multiple Stores.
• When Receiver Self-Service performs Discovery, if the StoreFront server has multiple stores, then the user is prompted to select a store. Stores can be hidden (not advertised).

NetScaler Gateway required – For external access,Receiver Self-Service and StoreFront require NetScaler Gateway ICA Proxy instead of Secure Gateway.

Receiver configuration methods – There are multiple methods of configuring Receiver Self-Service: registry, group policy, StoreFront Account Services, and installer command line arguments.

Challenges of cutover – Because Receiver Self-Service is so different from PNAgent, cutovers are difficult. Receiver behaves differently when connected to StoreFront Stores vs PNAgent URLs.

HDX Optimal Routing – StoreFront supports sending ICA traffic for each site/farm to a non-default NetScaler Gateway URL. If a user launches an icon from Datacenter A, then you probably want ICA traffic to go through the NetScaler Gateway that is in Datacenter A. This is called HDX Optimal Routing and was never available in Web Interface. This feature requires datacenter-specific DNS names.

SAML Authentication – StoreFront and NetScaler Gateway support SAML authentication. Deploy Federated Authentication Services to support SAML.

LTSR or CR – If you intend to build LTSR XenApp/XenDesktop, then StoreFront should be the LTSR version, and Receiver should be the LTSR version.

NetScaler Gateway vs Secure Gateway

Not free – NetScaler Gateway is not free, except maybe the 5 Mbps Express Edition.

Networking skills – NetScaler is a networking device, which requires different skills than the server-based Secure Gateway.

PNAgent vs Self-Service through NetScaler Gateway – Windows Receiver with PNAgent stores don’t work through NetScaler Gateway. StoreFront stores (Receiver Self-Service) do work through NetScaler Gateway.

AppFlow – If ICA traffic is going through NetScaler, you can enable AppFlow, and send it to NetScaler Management & Analytics System and Director for monitoring and reporting.

• You can deploy NetScaler Gateway internally to get internal ICA traffic through NetScaler for AppFlow reporting.
• However, Receiver Self-Service does not support Single Sign-on through NetScaler Gateway, thus complicating designs.

Build StoreFront and NetScaler Gateway

Follow the guides on this site to build StoreFront, and configure NetScaler Gateway:

1. Build two or more CR or LTSR 3.0 StoreFront servers in each datacenter.
2. Configure StoreFront (Manage Delivery Controllers) to connect to existing XenApp 6.5 farm(s).
   1. Configure icon aggregation from multiple farms. The instructions for CR StoreFront are different than LTSR 3.0 StoreFront.
3. Configure a load balancer to load balance Storefront in each datacenter.
4. Configure NetScaler GSLB to load balance a single DNS name to StoreFront Load Balancing VIPs in both datacenters.
5. Configure NetScaler Gateway in both datacenters.
   1. Create internal NetScaler Gateway vServer for AppFlow reporting?
   2. Configure StoreFront Console > Manage NetScaler Gateways, and enable Remote Access on the Store. The instructions for CR StoreFront are different than LTSR 3.0 StoreFront.
6. Configure HDX Optimal Routing. The instructions for CR StoreFront are different than LTSR 3.0 StoreFront.
7. Configure NetScaler GSLB to load balance a single DNS name to NetScaler Gateway VIPs in both datacenters.
   1. Configure NetScaler GSLB active/passive for the HDX Optimal Routing DNS names.
8. Import a NetScaler Management and Analytics System virtual appliance.
   1. Use NetScaler MAS to enable AppFlow on the NetScaler appliances.

Migrate from Web Interface to StoreFront

Cutover DNS? – If you cutover an existing DNS name from Web Interface to StoreFront:

• StoreFront user interface and NetScaler Gateway user interface are different than the Web Interface user interface. A cutover might result in help desk calls from users that are not accustomed to the new user interface.
• If you cutover an existing DNS name, how do you reconfigure Receivers to use Receiver Self-Service Stores instead of PNAgent URLs? You’d have to ask every user to remove existing Receiver accounts and re-add them.
• Are you migrating from HTTP to HTTPS? It’s difficult to reconfigure Receivers and Browser Favorites to point to HTTPS instead of HTTP.
• Cutover night would have many changes. Be prepared for many support issues the next day.

New DNS names – A preferred alternative is to use a new DNS name(s) for StoreFront and NetScaler Gateway.  This lets you run Web Interface and StoreFront in parallel, and you can migrate users (and Receiver) at your leisure.

• Use group policy to point Receiver Self-Service to the StoreFront DNS name. This group policy setting does not apply to PNAgent (pnagent.exe).
• Deploy CR or LTSR Receiver to company-managed machines.
• Inform users of new external DNS name. StoreFront can be configured to offer Receiver upgrades.
• Inform users to remove existing accounts from mobile Receiver (iOS, Android), and re-add using the new DNS name. This changes the mobile Receiver to use StoreFront Store instead of PNAgent (Legacy).

6.5 to 7.x Migration Plan

This section assumes users have already been migrated to StoreFront/Receiver.

New 7.x Infrastructure

1. Upgrade Citrix License Server, and upgrade license files with Subscription Advantage date that has not expired.
   1. Alternatively, you can build a new license server and reallocate the licenses to the new license server. Point the 7.x farm/site to the new license server.
   2. You can either leave the 6.5 farm on the old license server, or reconfigure the 6.5 farm to use the new license server. If you use both old and new license servers, then the assumption is that you will migrate all users to the new 7.x farm/site in a timely manner so you don’t exceed your license count.
2. Build highly available SQL Servers. Typically AlwaysOn Availability Groups (or Basic Availability Groups in SQL 2016 Standard Edition).
   1. Separate SQL in each datacenter?
3. Build 7.x Delivery Controllers – at least two per datacenter. Connect them to the Highly Available SQL Servers.
   1. CR? Or LTSR?
   2. Separate sites/farms in each datacenter?
   3. Or are you stretching and configuring zones instead? Zones are not available in LTSR 7.6.
   4. Mixed license types in CR 7.x, but not LTSR 7.6?
4. Connect Citrix Studio to your hypervisor (e.g. vCenter). Import the vCenter certificate first.
   1. If using MCS, create Hosting Resources in Studio. These are a combination of hypervisor cluster, hypervisor storage, and hypervisor network.
5. Install Citrix Director, and configure them to point to the Delivery Controllers.
   1. CR? Or LTSR?
6. If PvS, and if using the PvS XenDesktop Setup Wizard, then either in-place upgrade PvS servers to the same version as XenApp/XenDesktop 7.x, or build new PvS servers with the same version as XenApp/XenDesktop 7.x.
   1. If new PvS servers, then they can be in a new PvS farm with a new database.
7. If you are upgrading the VDA OS version, then you might have to upgrade the App-V infrastructure.
8. If you intend to use Citrix App Layering, import and configure the ELM appliance.
9. Build Citrix Workspace Environment Management servers.
10. Build Citrix Session Recording servers. The instructions for CR 7.14 Session Recording are quite different than LTSR Session Recording.
11. Configure group policies and profiles for newer OS version.
    1. Move Citrix Policy settings from AppCenter to a group policy object (GPO) instead of Citrix Studio.
    2. If new profiles, create scripts to copy settings from old profiles to new profiles.
12. Implement Citrix and hypervisor monitoring tool(s)

New 7.x VDAs

1. Use AppDNA to analyze applications for compatibility with newer operating systems.
2. Create a master VDA – either CR or LTSR 7.6.
   1. If remaining on Windows 2008 R2, you can uninstall XenApp 6.5 (and all related components), and then install Virtual Delivery Agent 7.x.
   2. If upgrading OS version, then you must build from scratch with Windows.
   3. If App Layering, import the OS Layer to ELM with only Windows installed.
   4. If not App Layering, then install Applications, VDA, and Security software (e.g. antivirus) on the Master VDA.
3. If App-V, upgrade App-V packages, or create new App-V packages.
   1. CR 7.x can integrate App-V into Citrix Studio.
4. If Layering, use ELM to create Platform Layer and App Layers. Then push an image to PvS, or your hypervisor.
5. Use PvS or MCS to create Catalogs. Both options create new VDA machines, and put them in a Machine Catalog. If PvS,
   1. Convert the master VDA to a new vDisk.
   2. Use the PvS XenDesktop Setup Wizard to create multiple Target Devices that boot from the vDisk.
6. Configure scheduled reboots of RDSH VDAs. Citrix Studio has some reboot options. Or write a script.

Publish Icons, Pilot, Rollout, and Operations

1. Create Delivery Groups and Publish Applications/Desktops from the Delivery Groups. CR 7.x has more capabilities than LTSR 7.6.
   1. You can use Citrix Smart Migrate to copy applications and/or policies from 6.5 to 7.x. Also see the XenApp 6 migration tool.
   2. If CR 7.x, App/Desktop publishing is different than LTSR 7.6.
   3. If CR 7.x, limit application usage.
   4. If CR 7.x, create App Groups.
   5. Publish apps to anonymous users?
   6. If CR 7.x, create Published Content.
   7. If CR 7.x, use Tags to publish apps on a subset of machines in a Delivery Group.
   8. Enable multiple sessions from one user?
   9. Use Keywords to control icons in Receiver. You can even use Keywords to hide applications from StoreFront.
2. Add the 7.x farm/site to StoreFront > Manage Delivery Controllers
   1. Configure StoreFront user farm mapping (Map users to Controllers) so only members of an AD Group can see icons from the 7.x farm/site? The instructions for CR StoreFront are different than LTSR 3.0 StoreFront.
3. Help Desk:
   1. Add Help Desk users to Citrix Studio > Configuration > Administrators so they can use Director.
   2. Teach Help Desk how to use Director. CR Director and LTSR 7.6 Director have different capabilities.
4. Conduct pilot:
   1. Assign users to the apps and desktops published from 7.x. Since users are already using StoreFront, the new icons should show up in Receiver automatically.
   2. Solicit feedback and fix issues.
5. Rollout:
   1. Assign users to 7.x published apps/desktops, and unassign the users from the 6.5 published apps/desktops
6. Decommission the 6.5 farm.
7. Backup 7.x SQL databases, vDisks, master images, and NetScaler configurations.
8. Build test 7.x farm(s) so you can test Citrix infrastructure upgrades.