Policies let you define how you want clients to connect, including SSL or encryption requirements, and the properties for the user’s environments after the connection is established.
Citrix recommends using XenApp policies whenever possible to control connections. Connection settings defined through XenApp policies also supersede all other connection settings in your environment, including those at the operating system level, in TS Config, and specified when you publish an application
You can specify the types of client connections from which users can start sessions. For example, to increase security, you can specify that users must connect through Access Gateway Advanced Edition (Version 4.0 or later). This allows you to benefit from filters created in Access Gateway.
Connection limits, including the option to log denials resulting from connection limits, are configured in Computer policy settings. (You cannot configure connection limits in the plug-ins.)
By default, XenApp does not limit connections in any way.
To conserve resources, you can limit the number of concurrent connections that users are permitted to establish. Limiting connections can help prevent over-consumption of server resources by a few users.
Active sessions and disconnected sessions are counted for the total number of concurrent connections. For example, you can set a limit of three concurrent connections for users. If a user has three concurrent connections and tries to establish a fourth, the limit you set prevents the additional connection. A message tells the user that a new connection is not allowed.
Connection control affects users only if a connection attempt is prevented. If a user’s number of connections exceeds a connection limit, the plug-in displays a message that describes why the connection is not available.
You can also limit the number of connections on a farm by ensuring that session sharing is enabled.
When this setting is used, users can still launch additional sessions, as long as the limit has not been reached.
When this setting is used and the specified number is reached, the user cannot launch additional sessions, even if the server has availability.
The mode that you choose typically depends on the type of client device that your users will be using and whether you are publishing a desktop or individual applications. Desktops are typically published in non-seamless window mode. This table provides examples of when you might want to publish desktops and applications.
|If your users will be using...||then you...|
|Local computers||Might want to publish desktops or individual applications.|
|Local computers with locally installed applications||Might want to publish individual applications.|
|Thin clients||Must publish desktops.|
|Kiosks||Might want to publish desktops, which allows the user to have a more holistic experience and provide more control from a security perspective.|
When a user launches a published application, the plug-in establishes a connection to a XenApp server and initiates a session. If session sharing is not configured, a new session is opened on the server each time a user opens an application. Likewise, every time a user opens a new application, a new client connection is created between the client device and the server.
Session sharing is a mode in which more than one published application runs on a single connection. Session sharing occurs when a user has an open session and launches another application that is published on the same server; the result is that the two applications run in the same session. For session sharing to occur, both applications must be hosted on the same server. Session sharing is configured by default when you specify that applications appear in seamless window mode. If a user runs multiple applications with session sharing, the session counts as one connection.
If you want to share sessions, ensure all applications are published with the same settings. Inconsistent results may occur when applications are configured for different requirements, such as encryption.
Session sharing always takes precedence over load balancing. That is, if users launch an application that is published on the same server as an application they are already using but the server is at capacity, XenApp still opens the second application on the server. Load management does not transfer the user’s request to another server where the second application is published.
By default, XenApp does not limit the number of instances of a published application that can run at one time in a farm. By default, a user can launch more than one instance of a published application at the same time.
You can specify the maximum number of instances that a published application can run at one time or concurrently in the server farm. For example, you can publish an application and set a limit of 30 concurrent instances in the farm. Once 30 users are running the application at the same time, no more users can launch the application because the limit of 30 concurrent instances was reached.
Another connection control option lets you prevent any user from running multiple instances of a particular published application. With some applications, running more than one instance in a single user context can cause errors.
You can apply application limits independently to each published application. For example, you can apply the limitations on total concurrent instances and multiple instances by a single user to one published application. You can limit only the total concurrent instances of another application. You can configure a third application to limit launching of multiple instances by individual users.
For example, if you enter 10 and a user tries to launch the application when 10 instances are running, the server denies the connection request and records the time and the name of the published application in the System log.
Event logging records an entry in the System log each time a server denies a user connection because of a connection control limit. Each server records the data in its own System log. By default, this type of event logging is disabled.
To enable or disable logging of connection denial events, configure the Logging of logon limit events Citrix Computer policy setting.
You might want to prevent logons to a server when you install software or perform other maintenance or configuration tasks. This is helpful when you are installing applications that require there be no active sessions on the server. It also lets you restart the server without having to wait for users to disconnect.
By default, logons are enabled when you install XenApp and users can launch an unlimited number of sessions and instances of published applications. You can prevent users from connecting to a server in the farm by disabling logons.