- What's new
- System requirements
- Technical overview
Install and configure
Prepare to install
- Microsoft Azure Resource Manager virtualization environments
- Microsoft System Center Virtual Machine Manager virtualization environments
- Microsoft System Center Configuration Manager environments
- VMware virtualization environments
- Nutanix virtualization environments
- Microsoft Azure virtualization environments
- Install core components
- Install VDAs
- Install using the command line
- Install VDAs using scripts
- Create a Site
- Create machine catalogs
- Manage machine catalogs
- Create Delivery Groups
- Manage Delivery Groups
- Create Application Groups
- Manage Application Groups
- Remote PC Access
- XenApp Secure Browser
- Publish content
- Server VDI
- Personal vDisk
- Remove components
- Prepare to install
- Upgrade and migrate
- Security considerations and best practices
- Integrate XenApp and XenDesktop with NetScaler Gateway
- Delegated Administration
- Smart cards
- Transport Layer Security (TLS)
- Federated Authentication Service
- General content redirection
- Work with policies
- Policy templates
- Create policies
- Compare, prioritize, model, and troubleshoot policies
- Default policy settings
Policy settings reference
- ICA policy settings
- Load management policy settings
- Profile management policy settings
- Receiver policy settings
- Virtual Delivery Agent policy settings
- Virtual IP policy settings
- Configure COM Port and LPT Port Redirection settings using the registry
- Connector for Configuration Manager 2012 policy settings
- Connections and resources
- Local Host Cache
- Connection leasing
- Virtual IP and virtual loopback
- Delivery Controllers
- VDA registration
- Use Search in Studio
- IPv4/IPv6 support
- User profiles
- Citrix Insight Services
- Get started with Session Recording
- Install, upgrade, and uninstall Session Recording
- Configure Session Recording
- Grant access rights to users
- Create and activate recording policies
- Create notification messages
- Disable or enable recording
- Enable or disable live session playback and playback protection
- Enable and disable digital signing
- Specify where recordings are stored
- Specify file size for recordings
- Log administration activities
- Install Session Recording with database high availability
- View recordings
- Troubleshoot Session Recording
- Manage your database records
- Configuration Logging
- Event logs
- Session Recording
- Advanced configuration
- Monitor deployments
- Alerts and notifications
- Delegated Administration and Director
- Secure Director deployment
- Configure permissions for VDAs earlier than XenDesktop 7
- Configure network analysis
- Troubleshoot user issues
- Troubleshoot applications
- Troubleshoot machines
- Feature compatibility matrix
- Data granularity and retention
- SDKs and APIs
- Citrix VDI Best Practices for XenApp and XenDesktop 7.15 LTSR
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 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.
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.
For more considerations, see XenDesktop 7.6 Connection Leasing Design Considerations.
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.