Product documentation
XenApp and XenDesktop
7.15 LTSR
View PDF

Connection leasing

April 23, 2021
Contributed by: 
C

Important:

Local Host Cache (LHC) is the preferred XenApp and XenDesktop high availability solution, instead of connection leasing. See Local Host Cache for details.

  • In this release, during a new installation of XenApp and XenDesktop, connection leasing is disabled by default.
  • Connection leasing will no longer be provided, beginning with the Current Release following this XenApp and XenDesktop 7.15 Long Term Service Release.

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 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.

Considerations and limitations

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.

When the Controller is in leased connection mode:

  • Administrators cannot use Studio, Director, or the PowerShell console.

  • Workspace Control is not available. When a user logs on to Citrix Receiver, sessions do not automatically reconnect; the user must relaunch the application.

  • If a new lease is created immediately before the database becomes unavailable, but the lease information has not yet been synchronized across all Controllers, the user might not be able to launch that resource after the database becomes unavailable.

  • Server-hosted application and desktop users may use more sessions than their configured session limits. For example:

    • A session may not roam when a user launches it from one device (connecting externally through NetScaler Gateway) when the Controller is not in leased connection mode and then connects from another device on the LAN when the Controller is in leased connection mode.
    • Session reconnection may fail if an application launches just before the database becomes unavailable; in such cases, a new session and application instance are launched.

  • Static (assigned) desktops are not power-managed. VDAs that are powered off when the Controller enters leased connection mode remain unavailable until the database connection is restored, unless the administrator manually powers them on.

  • If session prelaunch and session linger are enabled, new prelaunch sessions are not started. Prelaunched and lingering sessions will not be ended according to configured thresholds while the database is unavailable.

  • Load management within the Site may be affected. Server-based connections are routed to the most recently used VDA. Load evaluators (and especially, session count rules) may be exceeded.

  • The Controller will not enter leased connection mode if you use SQL Server Management Studio to take the database offline. Instead, use one of the following Transact-SQL statements:

    • ALTER DATABASE <database-name> SET OFFLINE WITH ROLLBACK IMMEDIATE
    • ALTER DATABASE <database-name> SET OFFLINE WITH ROLLBACK AFTER <seconds>

    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.

Configure and deploy

When configuring your 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.

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.
Connection leasing
April 23, 2021
Contributed by: 
C
April 23, 2021
Contributed by: 
C

In this article

Site feedback | Your privacy choices footer linkYour Privacy Choices | Privacy and legal terms | Cookie preferences | Consent settings | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.