How to tweak Connection Leasing in XenApp and XenDesktop 7.6

With the release of 7.6, Citrix has tried to provide some functionality to address the concerns that XenApp users have had in their migration efforts.  Some of those are welcome additions like folder structure in the applications.  One very interesting addition though is their attempt to replace the local host cache feature that was lost with the direct SQL requirements of XenDesktop.  The solution to that is called Connection Leasing.

As a refresher, the reason local host cache was a welcome (albeit at times troublesome) component was that it allowed the XenApp server to function for a period of time without the direct database connection.  In XenDesktop your SQL servers are your life and death.  If they go down, your entire farm is out of the water.  This has led to some serious SQL setups just to support what may be a very small but critical XenDesktop database.  The recommended configuration from Citrix is actually a clustered mirrored SQL farm with servers in 3 different locations for maximum uptime.  That’s a lot to ask in many use cases.

To be really clear, Citrix still recommends that you have a highly available SQL environment.  Connection Leasing isn’t a replacement for that but rather an augmentation that makes it less painful if and when your database does go down.  What connection leasing does is create a cache on the Delivery Controller of the user and their session connection.  That cache is actually replicated between every DC in the Site so that every delivery controller will have a copy of the cache in case of a failure.  With that cache in place when a user tries to make a connection while the database connection is down the user will be directed back to the machine they last connected to.  There are some caveats to this process:

1) This only works for static (1:1) VDI or XenApp.  It does not function with pooled desktops.

2) The machines must be running the 7.6 VDA.  That is the only one that will write back to the cache location on connection.

3) There is a time frame for the connections which defaults to 14 days (see below for tweaks).  If your user hasn’t attempted the connection within those 14 days then it isn’t cached and they will not be able to connect.

4) Connection Leasing totally ignores your load balancers.  It will always send the user back to the last box they connected to.  In case of XenApp apps that could lead to overloaded boxes since it won’t do anything to balance the connections out across the Site.

Connection leasing is enabled by default in 7.6.  This does increase the size of your database as well as the size of the install on your Delivery Controllers.  Each Delivery Controller must maintain a full cache copy.  Citrix has yet to provide any true sizing requirements for the feature other than to say that you should expect it to consume an additional 2GB per Controller in a normal environment.  Of course we don’t know what they mean by “normal” so make sure you have plenty of disk space and watch for yourself how big it gets.  The obvious question is “Where can I see how big it is?”  Honestly, I can’t find an answer to that.  There’s nothing I can see directly exposed in the Citrix directories where it would be caching.  I guess the answer is load it up and see where the growth is.  If you find out please let me know. **Found it! C:\ProgramData\Citrix\Broker\Cache\Leases\Enumeration**

As I said, Connection Leasing is enabled by default but you can disable it if you want to.  That is done through PoSH:

Set-BrokerSite -ConnectionLeasingEnabled $true|$false – Turns connection leasing on or off.

You can also display the Connection Leasing status for a particular Controller:

Get-BrokerServiceAddedCapability – Outputs “ConnectionLeasing” for the local Controller

There are several other PoSH commands around Connection leasing that I recommend you check out in the eDocs.  Unfortunately one of the key things you can’t do from PoSH is actually change the default time that a lease will be cached.  That can be controlled via a registry entry here:

***Modify at your own risk!***


You need to add a new entry LeaseExpirationTimeInMins and define the number of minutes the cache should be active (and on that note… seriously Citrix?  Minutes??? I guess I should be grateful it isn’t milliseconds like some things are).

But with many thanks to the Citrix employees who helped me through this there are even MORE fun tweaks that can be made to the lease process!

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.

There is one more very important key: EnumerationLeaseKeyMask.  This actually 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;)  Apparently this key can be modified to cache even more information like Smart Access tags.  Doing so will significantly increase the size of your cache however, and I haven’t played with it to give you an answer on how it works.

So that’s Connection Leasing.  It’s an interesting solution to the problem with lack of a local host cache, and doesn’t work in every use case.  In fact it’s got some pretty glaring weaknesses.  But it’s a nice step towards recovering a fairly critical XenApp feature and for many people will help lessen the blow of a SQL outage.  Full props to Cris Lau and team for delivering in 7.6 some of the features we have been asking for since 7.0 debuted.

, , , ,


  • Carl Stalhood says:

    Does Connection Leasing work with Anonymous authentication?

    Does the VDA need to be registered? What is the effect if the VDA is rebooted? Can a VDA register while SQL is down?

    • Paul says:

      Great questions! No, it won’t work with Anonymous. The cache file ties the user’s ID to the machine/app so if the database is offline and the user tried Anonymous it wouldn’t have any way to associate the correct session. That said I suspect it COULD be made to work if the cache file was modified to support say the user’s machine name instead of requiring the ID. But that requires some additional support from Citrix.

      The cache is only created if the SQL connection is up and the VDA is registered. It will not create a new cache entry once the SQL connection is offline. I haven’t honestly tested what happens if a VDA is unregistered, but I suspect it will still work because the DDC is returning the connection lease info and then you are making a direct connection to the ICA listener. But definitely worth testing.

  • […] 7.6 Citrix brings us Connection Leasing.  I won’t go into a ton of details on it, I already wrote this post the other day on it.  While Connection Leasing does allow for some connections to continue in case […]

  • Francis Guilbault says:

    Great article Paul! Were you able to validate if CL only cache the last session accessed by a user or all the one established in the past 14 days ? Thank you

    • Paul says:

      Hey sorry for the late reply. The CL caches every session within the window you define so in the case of published apps it would cache them all even from different servers. What it won’t do is cache pooled VDI.

  • […] another great blog by Paul Stansel, that goes over various powershell commands to tweak Connection Leasing […]

  • Richard H says:

    Paul, this is an excellent article. I have been looking for a deep dive on how CL works. Thanks! What is the maximum lease time? Please respond in milliseconds. 😉 Kidding!

    • Paul says:

      99999999ms! 🙂 Seriously I have no idea, and Citrix still doesn’t have a good calculator available. I know I have set mine to 21 days with no issue.

  • Richard H says:

    Ha! I set my DDC to 2 months. 60days x 24hours x 60 minutes = 86400 minutes. I rebooted my DDC and ran the “Get-BrokerServiceAddedCapability” command. It returned “ConnectionLeasing” and I don’t see any errors in the event logs for a misconfiguration.

    I wonder how pre-launch would play in to CL. If the pre-launch apps are launched, I imagine that they would be available during CL even if the user had not actually used them. My understanding is that, essentially, the ICA file information is cached. I wonder if it would require the generation of an ICA file to cache the pre-launched app. And if so, does pre-launch ever create an ICA file? Any ideas?

    Props to you for writing about this so soon. I have searched for the registry key name and the powershell commands and it looks like you are the only one to have written anything so far.



    • Paul says:

      Great question, I assumed PL apps would create the connection lease because they do in essence go through the logon process in the background. I don’t know if they would continue to PL if you are in a scenario where leasing is invoked though it seems like it might still work. It’s not like Anonymous where it wouldn’t have any idea at all. I guess the easiest way to test is to do it!

  • Richard H says:

    Thanks Paul! I also wondered if Connection Leasing has some security implications. Let’s say that yesterday I removed a user from a security group that granted access to a particular 7.6 application. Today, we have an SQL outage and he tries to connect to that same app. Will he get in? I know you can turn off CL for certain users but that would cover all apps for this user, not a specific app you had removed them from. Any thoughts? Thanks!

    • Paul says:

      I was curious so I just tested 🙂 In StoreFront it knows I am not assigned to the app anymore so it doesn’t allow me to launch it even though I have the cached connection. So I guess there’s not as much danger there.

  • Richard H says:

    Cool. Thanks for testing, Paul!

  • […] The default expiration time is 14 days (you can change this time. See here) […]

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">