Important: Local Host Cache (LHC) is the preferred XenApp and XenDesktop high availability solution, instead of connection leasing. See the Local Host Cache article for details about the feature, and how to enable it. Do not have both features enabled at the same time.
To ensure that the Site database is always available, Citrix recommends starting with a fault-tolerant SQL Server deployment by following high availability best practices from Microsoft. However, network issues and interruptions may prevent Delivery Controllers from accessing the database, resulting in users not being able to connect to their applications or desktop.
The connection leasing feature supplements the SQL Server high availability best practices by enabling users to connect and reconnect to their most recently used applications and desktops, even when the Site database is not available.
Although users may have a large number of published resources available, they often use only a few of them regularly. When you enable connection leasing, each Controller caches user connections to those recently used applications and desktops during normal operations (when the database is available).
The leases generated on each Controller are uploaded to the Site database for periodic synchronization to other Controllers on the Site. In addition to leases, each Controller’s cache holds application, desktop, icon, and worker information. The lease and related information is stored on each Controller’s local disk. If the database becomes unavailable, the Controller enters leased connection mode and “replays” the cached operations when a user attempts to connect or reconnect to a recently used application or desktop from StoreFront.
Connections are cached for a lease period of two weeks. So, if the database becomes unavailable, the desktops and applications that the user launched in the previous two weeks remain accessible to that user through StoreFront. However, desktops and applications that have not been launched during the previous two-week lease period are not accessible when the database is unavailable. For example, if a user last launched an application three weeks ago, its lease has expired, and that user cannot launch that application if the database becomes unavailable now. Leases for long-running active or disconnected application or desktop sessions are extended so that they are not they are not considered expired.
By default, connection leasing affects the entire Site; however, you can revoke all leases for specific users, which prevents them from accessing any applications or desktops when the Controller is in leased connection mode. Several other registry settings apply on a Controller basis.
While connection leasing can improve connection resiliency and user productivity, there are considerations related to the availability, operation, and performance of other features.
Connection leasing is supported for server-hosted applications and desktops, and static (assigned) desktops; it is not supported for pooled VDI desktops or for users who have not been assigned a desktop when the database becomes unavailable.
Either statement cancels any pending transactions and causes the Controller to lose its connection with the database. The Controller then enters leased connection mode.
When connection leasing is enabled, there are two brief intervals during which users cannot connect or reconnect: (1) from the time the database becomes unavailable to when the Controller enters leased connection mode, and (2) from the time the Controller changes from leased connection mode to when database access is fully restored and the VDAs have re-registered.
If you configure a nondefault session roaming value, session reconnection reverts to its default value when a Controller enters leased connection node. For details, see Connection leasing and session roaming.
See the Zones article for information about where connection leasing data is kept.
For more considerations, see XenDesktop 7.6 Connection Leasing Design Considerations.
Connection leasing is enabled by default.