XenApp 6.5 has reached end of maintenance and with the end of life date only a few months away, migrating your existing 6.5 environment(s) to XenApp & XenDesktop 7 is highly recommended.
This also means moving from the IMA architecture to FMA. In earlier 7.x versions, some 6.5/IMA features were not available, but rest assured, they were added throughout new releases. Because some features have been rebranded or have gone through some design changes and improvements, this blog article may assist you in finding the XenApp 6.5 feature you are looking for in XenApp & XenDesktop 7.
Below you can find a summary of all important XenApp 6.5 features and how they translate to the feature set of XenApp & XenDesktop 7.
|FILLER TEXT||XenApp 6.5||XenApp/Xendesktop 7.x||Added in version|
|Architecture||IMA – Mesh||FMA – Brokers + Workers||n/a|
|Centralised configuration||Datastore||Site Database||n/a|
|DB resilience||Local Host Cache (LHC)||Connection leasing – LHC||LHC added in 7.12|
|Load balancing||Load evaluators||Load balancing policies||n/a|
|Scaling||Zones||Zones and zone preference||7.7, zone preference: 7.11|
|Managing workers||Worker Groups||Delivery Groups, Application groups and Tags||7.9 (AG’s) – 7.12 (tags)|
|Restarting workers||Scheduled server reboot policy||Restart schedules||Improved in 7.12|
|Application streaming||Offline apps||Improved App-V support and integration||Improvements in 7.8 and 7.11|
|App and Desktop Session Sharing||Default behaviour||Reintroduced in 7.17 as default behavior||7.17|
|Authentication||Web interface: per site auth config||Storefront: per store auth config||SF 3.5|
|Provisioning||Provisioning services (PVS)||PVS, MCS, App Layering||n/a|
The Independent Management Architecture (IMA) used by XenApp 6.5 and earlier versions is a mesh architecture. The Flexcast Management Architecture (FMA) used by XA/XD 7.x on the other hand consolidates all brokering functionalities to the Desktop Delivery Controller (DDC). Applications and desktops are hosted on separate machines, the workers, where the Virtual Delivery Agent (VDA) is installed.
This means that the DDC will consolidate following backend roles found in the IMA architecture:
- Load management, replacing the Zone Data Collector (ZDC)
- Communication with WebInterface/Storefront (XML service)
- User and worker management
- Configuration and policy management (direct connection with the site database)
- Secure Ticket Authority: for secured external connections
Both the IMA Datastore and the Site Database allow centralized storage of the configuration data. XA/XD 7.x also supports a Configuration Logging Database.
XenApp 6.5 and earlier offered protection from datastore failure by using a Local Host Cache (LHC). Every XenApp server saved a copy of the datastore database in a locally stored MDB-file.
Prior to XenApp/XenDesktop 7.12, in addition to database mirroring, the Connection Leasing feature would offer a backup solution in case of site database failure. In short, it creates XML files containing user, client and resource information, locally stored and synchronized between DDC’s. In case the controller receives a connection request from Storefront and it detects an unavailable database, it would try to find the connection information for that user/resource in the XML files.
Connection leasing has quite some limitations during an outage of the DB:
- No connections possible to pooled VDI’s, users who have not been assigned a desktop are unable to log in.
- Users with leases not yet synchronized before the DB outage will be unable to connect.
- Session limits are not applied.
- No power management. Assigned desktops that are turned off will not start, risking a shortage of available desktops.
- No load management.
To deal with these limitations, XenApp/XenDesktop 7.12 not only reintroduced, but also improved the LHC.
Many Citrix administrators will be familiar with the command dsmaint recreatelhc, rebuilding a corrupt LHC. XA6.5 and earlier uses an MDB-file to store a local copy of the datastore which is prone to corruption.
The new LHC uses a more robust technology: LocalDB. This is actually a stripped down SQL Server Express instance designed to temporarily store data from an application or process. This data is only accessible locally and will be deleted when the service is restarted, making the LHC more secure and reliable. The new LHC will only be used in case of DB failure.
The DDC replaces the Zone Data Collector and will collect and manage the load of workers and will decide where a session will be launched. Load evaluators are replaced by Load management policies.
Zones, zone preference and Application Groups offer additional techniques to ensure your users connect to their application or desktop in the most efficient way.
The IMA architecture allowed XenApp servers to be assigned to zones in order to group servers in the same geographical location, avoiding unneeded WAN traversing.
XenApp/XenDesktop 7.7 reintroduced zoning by allowing administrators to assign DDC’s, host connections and machine catalogues to a zone. Version 7.11 extended the functionality of zones greatly by adding zone preferences:
- Location zoning: connect to a resource depending on the user’s location (Configured using Netscaler Gateway and Storefront)
- User zoning: launch the application or desktop on a machine closest to where the user’s data is located
- Application zoning: launch the application or desktop on a machine closest to where the application’s data is located
- Further reading
XenApp 6.5 uses Worker Groups to group XenApp servers together, streamlining application publishing, load balancing and policy assignment.
XenApp/XenDesktop 7.x uses Delivery Groups, containing one or more machine catalogues, for desktop and application assignment.
XenApp/XenDesktop 7.9 added an additional management layer: Application Groups. They can span multiple DG’s and support DG priorities and user assignment.
In order to give administrators even more granular control, XenApp/XenDesktop 7.12 added tags that can be assigned to individual machines, restricting application or desktop launch on workers with a specific tag assigned.
Scheduled automated reboots of a XenApp 6.5 server is configurable through a policy.
In XenApp/XenDesktop 7, restart schedules can be configured through the properties of a Delivery Group.
Release 7.12 adds a lot more granular configuration by introducing the Restart Schedules v2 . Configurable through Powershell, it allows administrators to configure multiple schedules per DG and, using tags, it is now possible to create a schedule for a subset of a delivery group.
Offline applications are no longer available in XA/XD 7. However, it offers better support and integration with Microsoft App-V. Citrix Studio allows you to connect with the App-V management console (dual management). Version 7.8 allows for placing App-V packages on a network share, removing the dependency on the App-V server (single management). 7.11 added support for isolation groups.
Web Interface Authentication configuration per site
Storefront has replaced the functionality of the Web Interface. At first, authentication was a global Storefront setting while you could define the authentication method per site using Web Interface. From Storefront 3.5, the possibility to configure authentication per store has been reintroduced.
Session sharing between a published desktop and application
This default behavior changed in XA/XD 7: when starting a published application within a published desktop (ICA in ICA), a new session for that application is always started, even if the application is available locally and published on the same Delivery Group.
Workarounds are available to change this behavior. 7.17 introduced a feature that not only enables the desktop-application session sharing again , it also gives you control over the preferred launch method on a per application basis.
Provisioning machines using PVS remains fully supported in XA/XD 7. Additionally, the Machine Creation Services (MCS) provisioning method is offered, now also supporting cache to RAM with fallback to disk . Platinum customers can also use App Layering to easily create and manage images and to dynamically assign application layers to users and machines (elastic layering).
Citrix EdgeSight offered detailed monitoring and troubleshooting tools for your XenApp farm. EdgeSight is a separate component and required an agent to be installed on the XenApp server.
In a XenApp/XenDesktop 7 environment, Citrix Director will take care of the performance data collection and monitoring of your environment and will provide you with the troubleshoot tools to quickly identify issues. No additional agents or components are required as monitoring data will be stored by default in the monitoring database.
Director has received many new features since it was introduced:
- Proactive monitoring and alerting
- SCOM integration
- Custom reporting
- SNMP support
- Application Analytics
- Disk and GPU monitoring
- Integration of HDX monitor
- Extended retention of data
Still in need for more data? No problem.
Using a Citrix policy, you can enable process monitoring on the workers you specify. CPU and memory data for each running process in the VDA will be saved in the monitoring database. Make sure to scale your database appropriately for the extra data.
If you are still missing a report or view from EdgeSight, you should consider looking into the custom reports of Director. It supports the Open Data Protocol (OData), giving you access to a wealth of information without having to write complicated SQL queries. You will be surprised how easy you can get very detailed data and create custom reports using the OData connector of MS Excel.
And a lot more extra features are waiting for you…
If you haven’t yet taken the step yet to upgrade your 6.5 environment, I hope this article has reassured you that you won’t have to miss any of the functionalities when moving to FMA. As a bonus, you will get dozens of new features and optimizations that were added since XenApp/XenDesktop 7 was released and added support for a wider range of operating systems and technologies.