Summary
This article explains session sharing and discusses some common scenarios.
Session sharing is the ability of a seamless published application to be executed over the same connection.
Session sharing occurs if there is an open session and another application is launched and published to the same server as the first session. Consequently, additional published applications work in the same fashion. Session sharing for managed applications is enabled by default in MetaFrame 1.8 Service Pack 1 and MetaFrame XP for Windows Terminal Server 4.0 and MetaFrame 1.8 and MetaFrame XP for Windows 2000.
Note: The session sharing check is done prior to the connection going through load balancing.
Ensure all applications are published with the same settings. Varying results may happen when applications are set for different requirements, such as encryption.
Citrix currently does not support session sharing on the PocketPC client, meaning WinCE for certain handheld devices, with or without the Program Neighborhood Agent. As of October 17, 2005, the Windows Based Terminal (WBT) or WinCE for terminals, version 9.x now supports session sharing.
CTX114169 – Case Study: Session Sharing Failures
Example of Session Sharing
Suppose you publish, separately, each application (Word, Outlook, Access, and Excel) in Microsoft Office Suite to a load-balanced server farm with five servers. This means, you have a published application for WinWord.exe, Outlook.exe, Access.exe, and Excel.exe.
A user logs on to WinWord, potentially accessing any server in the farm (we will use Server 3 for our example) and now the user would like to import an Excel spreadsheet. The user launches the published application for Excel.
According to the rules of session sharing, if the first application is launched as a seamless application and if Excel is also published on Server 3, Excel runs as another program within the same session, as opposed to a new session being launched on this server or another server. From Citrix Server Administration, you can see only one session and one license in use.
Support for this Feature
Session sharing is a feature of the Program Neighborhood Client. It occurs when you run an application as a seamless application. It will not function from a separate window or if launched through an ICA file with Wfica32.exe. Running Wfcrun32.exe can also be used for session sharing.
This feature enhancement introduces support for session sharing on fully loaded servers. Without this fix, session sharing does not work on fully loaded servers. Instead and as designed, users are load balanced to less busy servers. To enable this feature enhancement, you must set the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Citrix\wfshell\TWI\
Name: SeamlessFlags
Type: REG_DWORD
Data: 0 x 100
[From MPSE300R04W2K3016][#120874]
Search the Knowledge Base for 120874 for its platform equivalent.
Disabling Session Sharing
In some instances, you may want to disable session sharing. One example might be for security reasons and another common one is for using Packeteer’s Packet Shaping products with ICA.
To disable session sharing, the following registry key must be present along with the following updates:
Caution! This fix requires you to edit the registry. Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it.
Add the following value to disable this feature (this value does not exist by default):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Citrix\Wfshell\TWI\:
Type: REG_DWORD
Value: SeamlessFlags = 1
To re-enable the feature, delete this key.
Download one of the following hotfixes or service packs to resolve this issue:
MetaFrame 1.8 Service Pack 3 for TSE - ME183T036 or later
MetaFrame 1.8 Service Pack 3 for Windows 2000 - ME183W041 or later
MetaFrame XP for TSE - MetaFrame XP Service Pack 2 for TSE or later
MetaFrame XP Feature Release 2 - XE102W029 or later
Reconnecting to a Disconnected Session with a New Application
With MetaFrame XP Feature Release 1, the same client name launches the new application in the original application’s disconnected session.
The feature works as follows:
1. When a new seamless application is launched and there are disconnected sessions for this client, the browser checks whether or not any of those sessions are on a host that also publishes the new application and directs the client to that host.
2. Wsxica.dll on the host causes a reconnect to a suitable session.
3. The seamless module, Seamls20.dll, launches the application in the reconnected session.
4. The feature is on by default and can be disabled on each server by adding a value to the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Citrix
Type: REG_DWORD
Type: ReconnectWithNewApplication = 0
This value is on by default in MetaFrame XP with Feature Release 3.
Session Sharing and Novell Directory Services
The following is an excerpt from the Advanced Concepts Guide for MetaFrame XP Feature Release 2:
“Session sharing works correctly with Novell Directory Services (NDS) users only if the application permissions are assigned at a user or container level. Session sharing does not work if assigned at the group level.
The session sharing feature is not currently supported for custom ICA connections that are configured with NDS user credentials (under Properties > Login Information). To use the session sharing feature for custom ICA connections, do not specify user credentials for a connection on the connections Login Information tab.”
Custom ICA Connections
When users run the Add New ICA Connection wizard, they must enter a distinguished name in the user name field and a password in the password field, and place the NDS tree name in the domain field. Users running earlier versions of ICA Win32 Clients can also enter credentials in this manner.
NDS Issue
When using Version 6.3x or the Version 7.0 Program Neighborhood Client in a pass-through session from a MetaFrame XP Feature Release 2 / Service Pack 2 or later server to connect to NDS published applications on the same or a different Feature Release 2 or later server, the following behavior sometimes occurs:
The first published application that is connected to the Program Neighborhood Client through the pass-through session may not be session shared with the initial connection to the pass-through session.
Each subsequent connection to an NDS published application is session shared with the first connection to an NDS published application.
This problem does not occur when connecting to applications published to Windows NT users.
NDS Resolution
Install Version 8.x Program Neighborhood Client for this issue.
Attempts to Share Sessions May Consume More Than One Connection
1. Multiple sessions can be opened if multiple configured seamless Windows applications are started in rapid succession and the MetaFrame server has custom logon scripts that take longer than 20 seconds to complete. To extend this time-out value, enter the following information in the Appsrv.ini file under the <WFClient> section:
SucConnTimeout = xx
Where xx is the time in seconds. Alternatively, you can apply Service Pack 3 for MetaFrame 1.8.
CTX114379 – Session Sharing Does Not Occur if You Click on Multiple Applications at the Same Time
2. From the ICA Client 9.2 readme:
When launching multiple applications simultaneously, session sharing may fail and in some cases generate a duplicate session. The issue occurs because of the way the session launch event is created and because it is possible to call the launch status procedure more than once. This fix ensures that the session launch event is initialized properly and that the launch status procedure prevents incorrect statuses. [#125980]
3. When using the pass-through client Version 985 from a MetaFrame server in a workgroup to connect to one or more seamlessly published applications and connect to the first published application, two connections are registered on the server. Use the server’s computer name instead of the workgroup name in the domain field of the Program Neighborhood Application Set logon box.
4. The Prompt for Password check box or default Windows NT authentication is configured on the ICA listener.
5. Applications are published with different settings – or – custom ICA connections have different settings.
Some properties that must match on both Applications for Session Sharing to function are:
• Color depth
• Screen Size
• Access Control Filters (for SmartAccess)
• Sound
• Drive Mapping
• Printer Mapping
Example:
Two seamless defined custom ICA connections from the Program Neighborhood Client with the identical settings will share a session.
If the properties of one of the custom ICA Connections are changed to use a different color depth, one connection 16 and the other connection 256, they will no longer share a session.
6. Ensure the template.ica file contains SessionsharingKey=[NFuse_SessionSharingKey].
7. The 6.30.1050 and 6.30.1051 clients may not behave correctly, with respect to session sharing, in a pass-through mode. Apply the Version 8.x ICA Win32 Client.
8. See the Known Issues section.
9. CTX111059 – How to Honor Zone Preference and Failover Over Session Sharing
Session Sharing as of MetaFrame XP Feature Release 2
There are misconceptions about how the Citrix Management Console displays shared sessions. For example, a user running two session-shared applications shows two entries in the console, but the sessions have the same session number: ica-tcp#1.
Using the Win32 Client 986 or later, a connection from a workstation to two or more seamlessly published applications on the same server shows as being session-shared. This happens for either custom connections or an application set. However, if the applications are accessed non-seamlessly, two separate session numbers, for example ica-tcp#1 and ica-tcp#2, are used and shown.
When connecting to the pass-through 986 or later client that is either published or run from inside a desktop session, and then a published application connection is made to an application published on the same server from which you launched the pass-through client through an application set, only one session, ica-tcp#1, is shown.
For example:
1. Connect to a server desktop through ICA (session ica-tcp#1).
2. Open up an application set.
3. Seamlessly launch an application that is published on the same server as the server desktop session.
4. Notice that a new session is not created. The application executable shows as executing inside the server desktop session, ica-tcp#1. In effect, all applications “share” the same session.
If a published application connection is made by a custom connection with the pass-through client, the pass-through session and the custom connection session show as two separate connections, for example ica-tcp#1 and ica-tcp#2. Then each subsequent connection to another published application residing on the same server as the custom connection session, ica-tcp#2, is shared with the custom connection session, ica-tcp#2.
CTX107503 – Session Sharing Fails in Pass-through Session
Symptom 1
Under certain circumstances, Program Neighborhood Agent Versions 1050 and 1051 fail to session share.
For example:
When launching Microsoft Word from NFuse/Web Interface and then double-clicking a local Word document to invoke Program Neighborhood Agent, two connections are listed on the server with the same session ID and one instance of Word is displayed on the client device with both documents loaded. This indicates session sharing is working.
When doing the reverse, two instances of Word are displayed on the client device and the server has two connections with different session IDs. This indicates session sharing is not working.
Resolution 1
Download and install/upgrade to Program Neighborhood Agent Version 8.0 or later.
Symptom 2
Session sharing is broken when starting an application from ICA files and then Program Neighborhood / Program Neighborhood Agent Client respectively or the reverse.
Cause 2
The ICA Client uses browser address lists to ensure the connections are to the same farm.
Resolution 2
The connections should either use the browser address list or not at all.
Note: Program Neighborhood Agent doesn’t use browser address lists, so for session sharing with Program NeighborhoodAgent connections, ICA files used by the user should not have any browser address lists entry.
For example, users can add a TCP/IP server location in Program Neighborhood Classic Settings with the IP xx.xx.xx.xx. Then users must add TcpBrowserAddress= xx.xx.xx.xx into a custom ICA file under the <WFCLIENT> section of the ICA file. Most importantly,if you use an IP (not a DNS name) in Program Neighborhood you have to use the same exact IPin the ICA file.
When not using any server list and selecting auto locale (this works for the same subnet), remove TcpBrowserAddress from the custom ICA file.
The above comments are valid for HttpBrowserAddress or other protocol browser addresses (for example, NetBiosBrowserAddress).
CTX826951 – Error 2314 and HTTPBrowserAddress Entries May be Ignored in ICA Files
Symptom 3
Seamless connections using Program Neighborhood Agent automatically share existing sessions using the Web Interface (and vice versa) from the same client device, regardless of the user credentials specified for the second connection. When launching a seamless connection using Program Neighborhood Agent while a session using the Web Interface from the same client device is already active (or vice versa), the second connection shares the initial session.
Cause 3
The issue occurs because the session sharing checks performed by the client were incorrect.
Resolution 3
Download and install/upgrade to Program Neighborhood Agent Version 9.0 or later.
[92447]
