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. Moving quickly between devices and accessing the same applications at each logon is a priority for many mobile workers such as healthcare workers.
The features described in this article optimize the reliability of sessions, reduce inconvenience, downtime, and loss of productivity; using these features, mobile users can roam quickly and easily between devices.
You can also log a user off a session, disconnect a session, and configure session prelaunch and linger; see Manage delivery groups.
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 lost connectivity, 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 Workspace app 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 Citrix 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. Therefore, it does not prompt the user for reauthentication. As you extend the amount of time a session is kept open, the chances increase that a user might get distracted and walk away from the user device. Those actions can potentially leave 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.
- To prevent users from reconnecting 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 Workspace app 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 Workspace app attempts to reconnect to the session until there is a successful reconnection or the user cancels the reconnection attempts.
For desktop sessions, Citrix Workspace app attempts to reconnect to the session for a specified period, unless there is a successful reconnection or the user cancels the reconnection attempts. By default, this period is five minutes. To change this period, edit the following registry setting on the user device (where
seconds is the number of seconds after which no more attempts are made to reconnect the session).
HKLM\Software\Citrix\ICA Client\TransportReconnectRetryMaxTimeSeconds; DWORD;<seconds>
Enable and configure Auto Client Reconnect with the following policy settings:
- Auto Client Reconnect: Enables or disables automatic reconnection by Citrix Workspace app 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 without reauthentication is supported only for password authentication. If you use Federated Authentication Service or smart card authentication, Auto Client Reconnect without reauthentication is not supported. In such cases, users are redirected to the login screen.
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. The server also creates and sends a cookie containing the encryption key to Citrix Workspace app. Citrix Workspace app 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 Reconnect authentication setting. Instead, users are presented with a dialog box to users requesting credentials when Citrix Workspace app 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 Workspace app for Windows by using the icaclient.adm file. For more information, see the documentation for your Citrix Workspace app 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 earlier. 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 Workspace app.
- 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 Workspace app 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, this feature prevents Remote Desktop Services from disconnecting that session. Examples of no activity include no clock change, no mouse movement, no screen updates. 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 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 healthcare 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, plus 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 must 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, or 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 Workspace app 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 logged on to the session. For example, a healthcare worker logs off from a device in the emergency room and then logs on to a workstation in the 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.
The following information guides you to configure session roaming using PowerShell. You can use Web Studio instead. For more information, see Manage delivery groups.
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. Often, 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 use of a printer.
- When 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.
- When 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.
To configure session roaming, use the following entitlement policy rule cmdlets with the “SessionReconnection” property. Optionally, you can also specify the “LeasingBehavior” property.
For desktop sessions:
Set-BrokerEntitlementPolicyRule <Delivery-Group-name> -SessionReconnection <value> -LeasingBehavior Allowed|Disallowed
For application sessions:
Set-BrokerAppEntitlementPolicyRule <Delivery-Group-name> -SessionReconnection <value> -LeasingBehavior Allowed|Disallowed
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 setting:
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.
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 VDAs. Microsoft controls the logon timeout on machines with server VDAs.