Maintaining session activity is critical to providing the best user experience. Losing connectivity due to unreliable networks, highly variable network latency, and range limitations of wireless devices can lead to user frustration. Being able to move quickly between workstations and access the same set of applications each time they log on is a priority for many mobile workers such as health-care workers in a hospital.
Use the following features to optimize the reliability of sessions, reduce inconvenience, downtime, and loss of productivity; using these features, mobile users can roam quickly and easily between devices.
The Logon interval section describes how to change the default setting.
You can also log a user off of a session, disconnect a session, and configure session prelaunch and linger; see the Manage Delivery Groups article.
Session Reliability keeps sessions active and on the user’s screen when network connectivity is interrupted. Users continue to see the application they are using until network connectivity resumes.
This feature is especially useful for mobile users with wireless connections. For example, a user with a wireless connection enters a railroad tunnel and momentarily loses connectivity. Ordinarily, the session is disconnected and disappears from the user’s screen, and the user has to reconnect to the disconnected session. With Session Reliability, the session remains active on the machine. To indicate that connectivity is lost, the user’s display freezes and the cursor changes to a spinning hourglass until connectivity resumes on the other side of the tunnel. The user continues to access the display during the interruption and can resume interacting with the application when the network connection is restored. Session Reliability reconnects users without reauthentication prompts.
Citrix Receiver users cannot override the Controller setting.
You can use Session Reliability with Transport Layer Security (TLS). TLS encrypts only the data sent between the user device and NetScaler Gateway.
Enable and configure Session Reliability with the following policy settings:
- The Session reliability connections policy setting allows or prevents session reliability.
- The Session reliability timeout policy setting has a default of 180 seconds, or three minutes. Although you can extend the amount of time Session Reliability keeps a session open, this feature is designed for user convenience and therefore does not prompt the user for reauthentication. As you extend the amount of time a session is kept open, chances increase that a user may get distracted and walk away from the user device, potentially leaving the session accessible to unauthorized users.
- Incoming session reliability connections use port 2598, unless you change the port number in the Session reliability port number policy setting.
- If you do not want users to be able to reconnect to interrupted sessions without having to reauthenticate, use the Auto Client Reconnect feature. You can configure the Auto client reconnect authentication policy setting to prompt users to reauthenticate when reconnecting to interrupted sessions.
If you use both Session Reliability and Auto Client Reconnect, the two features work in sequence. Session Reliability closes, or disconnects, the user session after the amount of time you specify in the Session reliability timeout policy setting. After that, the Auto Client Reconnect policy settings take effect, attempting to reconnect the user to the disconnected session.
Auto Client Reconnect
With the Auto Client Reconnect feature, Citrix Receiver can detect unintended disconnections of ICA sessions and reconnect users to the affected sessions automatically. When this feature is enabled on the server, users do not have to reconnect manually to continue working.
For application sessions, Citrix Receiver attempts to reconnect to the session until there is a successful reconnection or the user cancels the reconnection attempts.
For desktop sessions, Citrix Receiver attempts to reconnect to the session for a specified period of time, unless there is a successful reconnection or the user cancels the reconnection attempts. By default, this period of time is five minutes. To change this period of time, edit this registry on the user device:
HKLM\Software\Citrix\ICA Client\TransportReconnectRetryMaxTimeSeconds; DWORD;<seconds>
where <seconds> is the number of seconds after which no more attempts are made to reconnect the session.
Enable and configure Auto Client Reconnect with the following policy settings:
- Auto client reconnect. Enables or disables automatic reconnection by Citrix Receiver after a connection has been interrupted.
- Auto client reconnect authentication. Enables or disables the requirement for user authentication after automatic reconnection.
- Auto client reconnect logging. Enables or disables logging of reconnection events in the event log. Logging is disabled by default. When enabled, the server’s system log captures information about successful and failed automatic reconnection events. Each server stores information about reconnection events in its own system log; the site does not provide a combined log of reconnection events for all servers.
Auto Client Reconnect incorporates an authentication mechanism based on encrypted user credentials. When a user initially logs on, the server encrypts and stores the user credentials in memory, and creates and sends a cookie containing the encryption key to Citrix Receiver. Citrix Receiver submits the key to the server for reconnection. The server decrypts the credentials and submits them to Windows logon for authentication. When cookies expire, users must reauthenticate to reconnect to sessions.
Cookies are not used if you enable the Auto client reconnection authentication setting. Instead, users are presented with a dialog box to users requesting credentials when Citrix Receiver attempts to reconnect automatically.
For maximum protection of user credentials and sessions, use encryption for all communication between clients and the Site.
Disable Auto Client Reconnect on Citrix Receiver for Windows by using the icaclient.adm file. For more information, see the documentation for your Citrix Receiver for Windows version.
Settings for connections also affect Auto Client Reconnect:
- By default, Auto Client Reconnect is enabled through policy settings at the Site level, as described above. User reauthentication is not required. However, if a server’s ICA TCP connection is configured to reset sessions with a broken communication link, automatic reconnection does not occur. Auto Client Reconnect works only if the server disconnects sessions when there is a broken or timed out connection. In this context, the ICA TCP connection refers to a server’s virtual port (rather than an actual network connection) that is used for sessions on TCP/IP networks.
- By default, the ICA TCP connection on a server is set to disconnect sessions with broken or timed out connections. Disconnected sessions remain intact in system memory and are available for reconnection by Citrix Receiver.
- The connection can be configured to reset or log off sessions with broken or timed-out connections. When a session is reset, attempting to reconnect initiates a new session; rather than restoring a user to the same place in the application in use, the application is restarted.
- If the server is configured to reset sessions, Auto Client Reconnect creates a new session. This process requires users to enter their credentials to log on to the server.
- Automatic reconnection can fail if Citrix Receiver or the plug-in submits incorrect authentication information, which might occur during an attack or the server determines that too much time has elapsed since it detected the broken connection.
Enabling the ICA Keep-Alive feature prevents broken connections from being disconnected. When enabled, if the server detects no activity (for example, no clock change, no mouse movement, no screen updates), this feature prevents Remote Desktop Services from disconnecting that session. The server sends keep-alive packets every few seconds to detect if the session is active. If the session is no longer active, the server marks the session as disconnected.
ICA Keep-Alive works only if you are not using Session Reliability. Session Reliability has its own mechanisms to prevent broken connections from being disconnected. Configure ICA Keep-Alive only for connections that do not use Session Reliability.
ICA Keep-Alive settings override keep-alive settings that are configured in Microsoft Windows Group Policy.
Enable and configure ICA Keep-Alive with the following policy settings:
ICA keep alive timeout. Specifies the interval (1-3600 seconds) used to send ICA keep-alive messages. Do not configure this option if you want your network monitoring software to close inactive connections in environments where broken connections are so infrequent that allowing users to reconnect to sessions is not a concern.
The default interval is 60 seconds: ICA Keep-Alive packets are sent to user devices every 60 seconds. If a user device does not respond in 60 seconds, the status of the ICA sessions changes to disconnected.
ICA keep alives. Sends or prevents sending ICA keep-alive messages.
Workspace control lets desktops and applications follow a user from one device to another. This ability to roam enables a user to access all desktops or open applications from anywhere simply by logging on, without having to restart the desktops or applications on each device. For example, workspace control can assist health-care workers in a hospital who need to move quickly among different workstations and access the same set of applications each time they log on. If you configure workspace control options to allow it, these workers can disconnect from multiple applications at one client device and then reconnect to open the same applications at a different client device.
Workspace control affects the following activities:
- Logging on: By default, workspace control enables users to reconnect automatically to all running desktops and applications when logging on, bypassing the need to reopen them manually. Through workspace control, users can open disconnected desktops or applications, as well as any that are active on another client device. Disconnecting from a desktop or application leaves it running on the server. If you have roaming users who need to keep some desktops or applications running on one client device while they reconnect to a subset of their desktops or applications on another client device, you can configure the logon reconnection behavior to open only the desktops or applications that the user disconnected from previously.
- Reconnecting: After logging on to the server, users can reconnect to all of their desktops or applications at any time by clicking Reconnect. By default, Reconnect opens desktops or applications that are disconnected, plus any that are currently running on another client device. You can configure Reconnect to open only those desktops or applications that the user disconnected from previously.
- Logging off: For users opening desktops or applications through StoreFront, you can configure the Log Off command to log the user off from StoreFront and all active sessions together, or log off from StoreFront only.
- Disconnecting: Users can disconnect from all running desktops and applications at once, without needing to disconnect from each individually.
Workspace control is available only for Citrix Receiver users who access desktops and applications through a Citrix StoreFront connection. By default, workspace control is disabled for virtual desktop sessions, but is enabled for hosted applications. Session sharing does not occur by default between published desktops and any published applications running inside those desktops.
User policies, client drive mappings, and printer configurations change appropriately when a user moves to a new client device. Policies and mappings are applied according to the client device where the user is currently logged on to the session. For example, if a health care worker logs off from a client device in the emergency room of a hospital and then logs on to a workstation in the hospital’s x-ray laboratory, the policies, printer mappings, and client drive mappings appropriate for the session in the x-ray laboratory go into effect at the session startup.
You can customize which printers appear to users when they change locations. You can also control whether users can print to local printers, how much bandwidth is consumed when users connect remotely, and other aspects of their printing experiences.
For information about enabling and configuring workspace control for users, see the StoreFront documentation.
By default, sessions roam between client devices with the user. When the user launches a session and then moves to another device, the same session is used and applications are available on both devices. The applications follow, regardless of the device or whether current sessions exist. In many cases, printers and other resources assigned to the application also follow.
While this default behavior offers many advantages, it might not be ideal in all cases. You can prevent session roaming using the PowerShell SDK.
Example 1: A medical professional is using two devices, completing an insurance form on a desktop PC, and looking at patient information on a tablet.
- If session roaming is enabled, both applications appear on both devices (an application launched on one device is visible on all devices in use). This might not meet security requirements.
- If session roaming is disabled, the patient record does not appear on the desktop PC, and the insurance form does not appear on the tablet.
Example 2: A production manager launches an application on the PC in his office. The device name and location determine which printers and other resources are available for that session. Later in the day, he goes to an office in the next building for a meeting that will require him to use a printer.
- If session roaming is enabled, the production manager would probably be unable to access the printers near the meeting room, because the applications he launched earlier in his office resulted in the assignment of printers and other resources near that location.
- If session roaming is disabled, when he logs on to a different machine (using the same credentials), a new session is started, and nearby printers and resources will be available.
Configure session roaming
To configure session roaming, use the following entitlement policy rule cmdlets with the “SessionReconnection” property. Optionally, you can also specify the “LeasingBehavior” property; see Connection leasing and session roaming below.
For desktop sessions:
Set-BrokerEntitlementPolicyRule <Delivery-Group-name> -SessionReconnection <value> -LeasingBehavior Allowed
For application sessions:
Set-BrokerAppEntitlementPolicyRule <Delivery-Group-name> -SessionReconnection <value> -LeasingBehavior Allowed
Where <value> can be one of the following:
- Always. Sessions always roam, regardless of the client device and whether the session is connected or disconnected. This is the default value.
- DisconnectedOnly. Reconnect only to sessions that are already disconnected; otherwise, launch a new session. (Sessions can roam between client devices by first disconnecting them, or using Workspace Control to explicitly roam them.) An active connected session from another client device is never used; instead, a new session is launched.
- SameEndpointOnly. A user gets a unique session for each client device they use. This completely disables roaming. Users can reconnect only to the same device that was previously used in the session.
The “LeasingBehavior” property is described below.
Effects from other settings
Disabling session roaming is affected by the application limit “Allow only one instance of the application per user” in the application’s properties in the Delivery Group.
- If you disable session roaming, then disable the “Allow only one instance …” application limit.
- If you enable the “Allow only one instance …” application limit, do not configure either of the two values that allow new sessions on new devices.
Connection leasing and session roaming
If you’re not familiar with connection leasing, see the Connection leasing article.
When a Controller enters leased connection mode, session reconnection reverts to its default value, reconnecting the user to only one of the active or disconnected sessions for the desktop or application.
For additional security, if you configured a nondefault session roaming value, and have multiple users who share the same logon credentials on multiple devices, consider disabling the connection leasing feature for the Delivery Group that includes that user account.
Why? In this scenario, one session is shared among all devices. This could be undesirable if, for example, one person has sensitive information displayed that is not meant to be seen by someone else who reconnects with the same credentials while the Controller is in leased connection mode.
Disabling connection leasing in the entitlement policy eliminates this possibility: a user will not be able to see the session of another user with the same logon, even when the Controller is in leased connection mode. Other entitlement policies can remain as-is; individual user accounts can use the connection leasing functionality through separate entitlements.
To disable connection leasing in an entitlement policy, add the “LeasingBehavior Disallowed” property to the entitlement policy cmdlet. If you disable connection leasing, you must manually delete any launch leases that have already been created and cached for that entitlement policy; otherwise, users will still be able to reconnect during a database outage.
If a virtual machine containing a desktop VDA closes before the logon process completes, you can allocate more time to the process. The default for 7.6 and later versions is 180 seconds (the default for 7.0-7.5 is 90 seconds).
On the machine (or the master image used in a Machine Catalog), set the following registry key:
Specify a decimal time in seconds, in the range 0-3600.
If you change a master image, update the catalog.
This setting applies only to VMs with desktop (workstation) VDAs; Microsoft controls the logon timeout on machines with server VDAs.