Pawel Serwan Blog

Citrix, Microsoft and other stuff

First Look: XenApp/XenDesktop 7.6 – Part 8 (Connection Leasing)


Welcome in the eighth part of First Look series on XenApp/XenDesktop 7.6. We did the following already:

In the first part – we installed first Delivery Controller and setup our new XenDesktop 7.6 site.

In the second part – we have configured first site.

In the third part – we prepared the template image of Windows Server 2012 R2 that will be used by MCS service for creation of new machines that will be hosting user desktops and applications.

In the fourth part – we upgraded XenApp 6.5 server to XenApp 7.6.

In the fifth part – we created machine catalogs and used previously prepared master image. We attached to the site as well upgraded XenApp 6.5 server.

In the sixth part – we delivered applications to the end users by creating delivery groups.

In the seventh part – we will configure StoreFront so that end users could launch their apps.

In the eighth part – we will check how Connection Leasing really works. Is it as good as our old Local Host Cache or not. As you remember with introduction of FMA Citrix decided to resign from using Access database as well as Oracle. One result of that was resign of Local Host Cache which in fact is just Access database stored on the Citrix XenApp server (of course till version 6.5). Each XenApp server (with IMA architecture) stores a subset of the data store in the Local Host Cache (LHC). The LHC performs two primary functions:

  • Permits a server to function in the absence of a connection to the data store.
  • Improves performance by caching information used by ICA Clients for enumeration and application resolution.

Local Host Cache is an Access database (Imalhc.mdb) stored, by default, in the <ProgramFiles>\Citrix\Independent Management Architecture folder. The following information is contained in the local host cache:

  • All servers in the farm, and their basic information.
  • All applications published within the farm and their properties.
  • All Windows network domain trust relationships within the farm.
  • All information specific to itself. (Product code, SNMP settings, licensing information)

More information about LHC you can find here. As you see LHC was/is pretty good stuff and in some way it increases availability of Citrix apps and desktops. I might be wrong but I think that most of Citrix XenApp farms stayed on 6.5 version only due to lack of that feature in XenDesktop 7.x. Citrix customers were loudly showing their disappointment and finally after quite long period of time Citrix announced the feature called Connection Leasing. I wrote about that here. At that point many people thought that old good LHC will be back. But to be honest it is not. There is no return to LHC in my opinion cause FMA really doesn’t allow that. I was going to write about Connection Leasing but I found this really great article from Bas van Kaam which I can only recommend to read:

Connection Leasing vs. Local Host Cache. Conclusion? CL doesn’t stand a chance!

Baas did a great comparison of Local Host Cache vs. Connection Leasing.

lhc_vs_clPicture taken from:

As you see Connection Leasing is just a half-measure. It just caches the connection information about the applications and desktops launched by user during last 2 weeks. This period is default one and can be changed of course. Each desktop or app launch generates a “lease”—an XML file containing the VDA’s address, application paths, and any other details stored in the database necessary for the session launch.  In many ways, a lease resembles much of the data in an ICA file.  The leases are then replicated among the controllers in the XA/XD site and cached on the local disk of each controller. A lease maps the user, resource, and (optionally) the client device from which the connection was launched to all the details needed to broker a connection.  If an FMA controller is unable to reach the database, it will check its local lease cache for the user and resource pair, and broker the user to their last-used VDA.  Leases also have an expiration date—14 days by default.  This means that as long as a user has launched a particular application or desktop within two weeks, they will continue to have access to that resource, regardless of the health of the FMA database. One important thing: Connection Leasing doesn’t work with Pooled Desktops. It supports only Shared Desktops (aka XenApp like desktops) or dedicated desktops (assigned permanently to specific person). You can read more about Connection Leasing: You can watch as well nice video from Citrix: We got some theory so let’s look now how Connection Leasing really works. I will start by launching few apps for my user account. xd1 We should check as well if Connection Leasing is enabled in XenApp/XenDesktop. We can do that by running Powershell. First we should load Citrix modules: Add-PSSnapin Citrix* Then we can check if it is enabled by running the command: Get-BrokerSite xd3 As you see below right now I have connection to the SQL database. xd2Let’s try now to find the place where XML files are stored. I was not able to find that information in Citrix documentation on eDocs but it was quite easy to find on the Delivery Controller. xd4As you see we have here 2 folders:

  • Enumeration – this folder contains XML file that stores information about launched application from the last 14 days (this is the default setting). As you see below it contains information about lease expiration date, user SID, applications that were launched and client device name – in my case this points to StoreFront interface.


  • Launch – this folder is a bit of a mistery 🙂 I was not able to find any information about it. It contains as well XML file that is generated/modified when you launch application. It contains as well information about your SID and lease expiration date. It has one interesting value: DesktopKind. As you already know Connection Leasing works only with Shared or Dedicated Desktops. So in my understanding here we have Shared when we were just using published apps or launched Citrix shared published desktop (so we used XenApp features) or we might have  Private when we are connecting to our dedicated desktop (XenDesktop).

xd6No we should know a bit more about Connection Leasing XML files. Let’s simulate now network connection problem with our SQL server by stopping SQL service. xd7Now let’s try to launch the apps. xd8As you see applications launched despite the lack of connection to the SQL database. Below you can find some important information about deploying and tweaking Connection Leasing.

When configuring deployment to accommodate connection leasing:

  • VDAs must be at minimum version 7.6, and the machine catalogs and Delivery Groups that use those machines must be at that minimum level (or a later supported version).
  • The Site database size requirements will increase.
  • Each Controller needs additional disk space for the cached lease files.

Connection leasing is enabled by default.You can turn connection leasing off or on from the PowerShell SDK or the Windows registry. From the PowerShell SDK, you can also remove current leases. The following PowerShell cmdlets affect connection leasing; see the cmdlet help for details.

  • Set-BrokerSite -ConnectionLeasingEnabled $true|$false – Turns connection leasing on or off. Default = $true
  • Get-BrokerServiceAddedCapability – Outputs “ConnectionLeasing” for the local Controller.
  • Get-BrokerLease – Retrieves either all or a filtered set of current leases.
  • Remove-BrokerLease – Marks either one or a filtered set of leases for deletion.
  • Update-BrokerLocalLeaseCache – Updates the connection leasing cache on the local Controller. The data is resynchronized during the next synchronization.

More information can be found HERE. If you want to change the default expiration period for Connection Leasing you have to play with Registry Key changes. Under the HKLM\SOFTWARE\Citrix\DesktopServer\ConnectionLeasing key you can create the following registry entries with required values:

  • LeaseExpirationTimeInMins – Controls the time the lease is valid.
  • LeaseMarkedDeletedTimeInMins – Controls the number of minutes before they get marked in the database as expired after reaching the expiration date. This defaults to 30.
  • SyncCleanupDelaySecsregistry – Controls the time (by default 2 minutes) that it queries expired leases to delete and begins that process.
  • DeletionCheckItemLimitPerCycle – Controls the number of objects deleted each cycle (defaults to 100). So even if the SyncCleanupDelaySecsregistry cycle runs and marks an object for deletion it may hang out for a little while longer until it is processed.
  • EnumerationLeaseKeyMask – Controls the type of data that is cached for each connection. By default that is only caching the user ID, what it connected to, and the connection type (gateway, direct, etc;) This key can be modified to cache even more information like Smart Access tags

That would be all regarding Connection Leasing. Do you enjoy this new feature? What do you think about it? Is that something you might use in your environment? Please comment below and see you in the next post. Cheers!


10 thoughts on “First Look: XenApp/XenDesktop 7.6 – Part 8 (Connection Leasing)

  1. Pingback: First Look: XenApp/XenDesktop 7.6 – Part 1 (Overview and Installation) | pawelserwan

  2. Pingback: First Look: XenApp/XenDesktop 7.6 – Part 2 (First Site Configuration) | pawelserwan

  3. Pingback: First Look: XenApp/XenDesktop 7.6 – Part 3 (template image creation) | pawelserwan

  4. Pingback: First Look: XenApp/XenDesktop 7.6 – Part 4 (upgrade from XenApp 6.5) | pawelserwan

  5. Pingback: First Look: XenApp/XenDesktop 7.6 – Part 5 (Machine Catalogs creation) | pawelserwan

  6. Pingback: First Look: XenApp/XenDesktop 7.6 – Part 6 (Delivery Groups creation) | pawelserwan

  7. Pingback: First Look: XenApp/XenDesktop 7.6 – Part 9 (PowerShell) | pawelserwan

  8. Pingback: First Look: XenApp/XenDesktop 7.6 – Series summary | pawelserwan

  9. Hi Pawel, Great article.. Well depicted..
    In the above example can you Pl help me understand why do we need to separate the databases of XenApp/XenDesktop and storefront server. My understanding is that SF doesn’t require any database. Pl clarify.


  10. hi Koupadhy,

    Thanks for noticing that. You are right. StoreFront 2.6 uses database but it is not SQL database but flat file for storing subscriptions. You can find more info about that here:
    I’ve changed the article.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s