Back in the XA 6.x (and earlier) releases, administrators had the ability to create folder hierarchies to organize applications to simplify management of these applications. The average enterprise customer typically has hundreds (and sometimes thousands) of applications published via XenApp. Inability for administrators to create application folder hierarchy within Studio and Storefront 7.6 brings back both session pre launch and linger and its stronger than ever with even more configurable parameters (see below) In earlier versions of XenApp/XenDesktop 7.x, this feature was not available. As a result when the user launches a published application, it launched instantly. With this feature enabled and configured, when the user logs in to his desktop and authenticates to receiver, a session is already established. To address this issue, XenApp 6.x introduced session pre-launch and session linger.
Depending on the environment, this could range from 5 seconds to in some cases, minutes. You can find a brief video that shows the configuration and demo of this feature here Lack of support for Session pre launch and lingerįor any user that is used to running local applications on their desktops and laptops, the first thing they would complain about in a Citrix environment was the launch time for the initial application. However, a separate Unauthenticated storefront store would be required. A Server OS based delivery group within XA/XD 7.6 can now be configured to allow anonymous access. This was another feature than was available in XenApp 6.5 and earlier, most commonly used by healthcare customers which enabled users to launch applications without first having to authenticate to Receiver or Storefront, thus enabling users to access applications from any available device. Here’s another great blog by Paul Stansel, that goes over various powershell commands to tweak Connection Leasing parameters No Anonymous User Access
One can argue that the connection leasing methodology is in some ways better than the old local host cache as you no longer have to deal with corrupt/stale cache issues and recreating the cache on all your servers.įor a quick overview of Connection Leasing check out this video on Citrix TV In the event of a DB failure, XenApp and Xendesktop can reference the user’s connection history and provide the user access to a previous connection. While larger customers addressed this issue by investing in highly available SQL infrastructures, smaller customers found this to be cost prohibitive in some cases.Ĭonnection leasing creates a lease file that holds information about a users active session, which is then replicated to all the other controllers within the site. With the XenApp/XenDesktop 7.x FMA architecture prior to the 7.6 release, a database connectivity issue or outage meant that users lost the ability to access applications and desktops during the period of the outage. In older versions of XenApp, with the Local Host Cache feature, users were able to enumerate and connect to applications and published desktops even if there was a database connectivity issue or a database outage. I want to highlight some of the common themes as to why customers were not ready to move to the 7.x architecture and zxhow they’ve been addressed in XenApp 7.6: No Local Host Cache under the new FMA architecture
And I would constantly hear about these gaps from my customers, who would then typically shoot down migration till these gaps were addressed by Citrix. While the 7.x architecture was most definitely a step in the right direction, some of the earlier releases definitely had some gaps that needed to be addressed. In my current role as a Sales Engineer covering some of the largest enterprise accounts, I have been preaching about the XenApp and XenDesktop 7.x architecture and benefits for about 1.5 yrs now.