Waclaw Chrabaszcz
... there is no spoon ...

XenApp and XenDesktop 7.6 - connection leasing under the hood

Saturday, November 1, 2014 3:18 PM

Some time ago Citrix introduced XenDedexktop and XenApp version 7.6. One of key improvements, and the best one for me is the Connection Leasing. Lastly Citrix delivered any replacement for good old LHC (Local Host Cache). Since XD 7.0 to XenDasktop&XenApp 7.5 many admins refused to migrate into the most resent version due to lack of session sharing (all your apps within one ICA channel), session pre-launching ( 2000 users tries to logon at 9:00 AM J ) and lack of any database resilience mechanism. In old Xenapp 6.5 every servers (not in a worker mode) was able to store local copy of the data store, and in case of database absence, to use his local cache to launch requested application. Static data were stored in in this (small) database, where us all dynamic e.g. current load, were handled by Data Collectors.

After merging of XenApp with XenDesktop this situation became much more complicated. Tens of thousands VDI machines instead of hundreds of servers, tones of user to machine assignments and billions of state changes when machine is powered on or user just logged in. Database 7.x is very dynamic, because it plays the role not only of the DataStore but the DataCollector as well. Of course you can protect your database by SQL AlwaysOn, Mirroring, or Clustering, however even well protected database can collapse. And even if your database runs, your network might fails. In this case, all actives sessions remains, but no one new can launch the session, until the database will be back.

XenDesktop 7.6 introduces Connection Leasing … and XenApp it is just a different licensing model for the same product. Citrix not documented yet Connection Leasing, all we know is, that it is stored in some XML file. Connection Leasing is enabled by default, you can easy validate it using followed PoSH command:

If you would like to change default behavior you can disable/enable this feature:

Set-BrokerSite –ConnectionLeasingEnabled $false
Set-BrokerSite –ConnectionLeasingEnabled $true

Let's try to view current leases, we see two launch leases and one enumeration.

If we would like to update local data on demand we can execute:


But where really this data is stored in case of database absence?

In hidden folder c:\ProgramData\Citrix\Broker\Cache you will find followed folders:

Each of them stores some (pseudo-random?) folder and XML file with definitions of related Item. As an example I will present the Calc app.

Let's take a look on example enumeration of available resources for user on particular device (please keep in mind policy filters for the endpoint)

And an example application lease

We can find here when exactly this lease expires, after this date, in case of database failure, user will be unable to re-launch the app. Users and worker machine SID, based on it in case of DB failure user will be redirected to exactly the same worker, and I assume if any load evaluator is applied, there must be enough capacity for the new session. Session sharing key, yeah! Session sharing is really back! The last remaining question is: where is the information about the application delivered by this session. In my opinion it is hidden behind RSApps, but as you can see, there is no direct answer.


# re: XenApp and XenDesktop 7.6 - connection leasing under the hood

Go against the grain, refuse to conform, take the road less traveled instead of the well-beaten path. Laugh in the face of adversity, and leap before you look. Dance as though EVERYBODY is watching. http://indiavisitonline.in/complete-himachal-tour-package 12/5/2016 11:43 AM | Gali Parker

# re: XenApp and XenDesktop 7.6 - connection leasing under the hood

I did not understand Gali Parkar comment but it is ok Citrix introduced XenDedexktop read your article or share with my friends i have some problem after reading your article. http://manalitour.in 5/25/2017 9:38 AM | mukeshjain

Post a comment