Written by Thomas Koetzing at Wednesday, 06 January 2010 | Article editor: Carl Webster
Ever heard of the Web Interface Session Sharing Key? Probably not but my guess is some companies are having issues with it without knowing. Of course they see sessions are not sharing and even open different sessions on the same XenApp server. I wrote an article about Understanding Citrix Seamless Engine some years ago and the article explains sharing issues with published applications but the Web Interface session sharing key is another story that I will explain here.
The Session Sharing Key plays a role when:
Using a Web Interface site and the online/offline plug-in at the same time
Using a Web Interface site to launch a session Desktop and within the online/offline plug-in
Using a Web Interface site to launch a VM Desktop (XenDesktop) and within the online/offline plug-in
Web Interface- and the Web Interface service site When Citrix was designing Web Interface they haden't thought that companies would use the online plug-in (PNAgent) and the Web Interface site at the same time (for the same user).
Another common thing, which I'm personally not a friend of, is that the Administrator used the online plug-in as a "start menu" replacement tool. So instead of building a common user start menu they hide it and just use the online plug-in for it. It seems easy and it is but a lot underestimate how many things are involved with that solution and what all can go wrong.
Understanding the Web Interface Session Sharing Key Now what, or better where, is the Session Sharing Key? You find the "SessionSharingKey" in the ica file that is used to launch the session downloaded from the Web Interface site or service. To get the file you have to do some things as described in the following articles CTX111820, CTX115304 or simply use Firefox as the browser.
Once downloaded look for SessionSharingKey in the ica file and you will find something like SessionSharingKey=-GFS55brCiGGp/Rlna9dWmB, or with older Web Interface versions something like SessionSharingKey=
The second key is coming from Web Interface 4.6. You should realize some values of the key but let me break it down for you: colors + "-" + encrypt + "-" + audio + "-" + domain + "-" + user + "-" + farm
So what's up with the first sharing key that comes from Web Interface 5.2? Well Citrix decided to encrypt the whole key with a hash. Most important to know is that the SessionSharingKey must be 100% the same for the user in order for session sharing to work!
Problems with the Session Sharing Key Right now some of you might still not see any problems with the sharing key but it gets nasty. Let's start with the obvious - the domain value! Let's assume the Administrator has pre-populated the domain in Web Interface with mydomain.local and the user launches a session desktop.
Now on the desktop the online plug-in is started with pass-through enabled. By default the logon domain at the server is just mydomain and not mydomain.local!
Now if the user starts an app through the online plug-in the session sharing key will not be the same as for the session desktop and ends up with additional sessions and logons (profile loading etc.) for the user! Very bad!
Same happens when using Web Interface and the online plug-in at the same time at the workstation. The company might decide to use the Web Interface site and will add additional information to it. At the same time they want users to launch doc and other files through content redirection and therefore using the online plug-in.
Not so obvious and what I would call actually mean is that the Web Interface site and the service site deliver different session sharing keys even through everything is the same for the user! This is a bug in Web Interface and so far I don't know if it still exists with the latest release (5.2)
How do I get the same Session Sharing Key First make sure the domain is the same in Web Interface and on the Server/Workstation. For the Server/Workstation you can use Microsoft group policies to pre-set the domain and/or an ica client registry key as described in article CTX368624. If you still have different keys, then you really need to troubleshoot the issue which I explain next.
Troubleshooting the Session Sharing Key The key with the hash value doesn't help at all so the hash must be disabled first. To do so use the Windows build-in search (make sure to search ALL files) and search within files for "SessionSharingKey". With Web Interface 5.2 you will find the "Include.java" and "LaunchShared.java" and looking into the first you will not really find anything helpful. In the LaunchShared.java you will easily find the following lines
// Put the encrypted hash in the ica file, if we successfully managed to create one. icaFile.setValue(ICAFile.SECTION_APPLICATION, ICAFile.VALNAME_SESSIONSHARING_KEY, sessionSharingKeyHash);
If you add "//" in front of the second line, then you disable the hash for the sharing key and as a result you will see the following even longer string:
Now you might have an Off where it should be On or vice versa!? The first several options you can manage (Publish options plus domain) but what's with the rest? Simply you add the right value to the default.ica file of the Web Interface or service site. Find details for each value in the ini file reference CTX107919.
As an example "comPortMapping" should be On, then add COMAllowed=On in the [wfclient] section.
Summary The session sharing key is very important when using the Web Interface site and the online plug-in in any combination. Make sure the domain authentication is set the same way for Web Interface as for the Server/Workstation (dom or dom.loc). At some point you might need to troubleshoot the exact issue to solve the problem because of a Web Interface bug.
All of the problems will result in session sharing not working. Multiple sessions for one user, multiple times the user profile is loaded, multiple logons, more server resources used and so on is what you get. So make sure YOU have the Session Sharing Key under your control, DO YOU? Let me know!
Comments
Thanks Written by Guest on 2010-02-01 08:37:22
We havbe been scratching our heads on this one for a while, now all good.
Hilfe bei WI for SP 2007 Written by Jürgen Streu on 2010-02-18 20:45:55evtl. können Sie mir weiter helfen?!?! Ich fasse mich gleich kurz:
Session sharing zwischen direkt vom WISP (also Web Part) gestarteten und durch Document Links (Client Server Redir. Office Docs) direkt im Share Point will einfach nicht klappen. Auch gibts keine Möglichkeit auf Sessions bereits gestarteter Apps durch WI und/oder PNAgent zu "kommen". Nach Untersuchung der launch.ica vom WISP (einmal erzeugt durch Launch.aspx und für Dokumente durch LaunchDoc.aspx) ist mir aufgefallen, dass der SessionSharingKey über die Launch.aspx mit Hash Wert und bei der von LaunchDoc.aspx im Klartext erzeugt wird. Nach manuellen angleichen dieser beiden Werte und danach manuellen ausführen/doppelklick der beiden launch.ica Files (innerhalb der Ticket Live Time) klappt das Session Sharing.
Auf diese Erkenntnis wäre ich nicht durch Ihren großartigen Artikel auf Ihrer Website gekommen, der SessionSharingKey beschreibt. Wäre es ein "normales" WI wäre somit auch mein Problem gelöst, jedoch finde ich beim WISP kein Pedant zur LaunchShared.java, wo ich der Launch.aspx das Hashing austreiben könnte.
Vielleicht wissen Sie ja, wo beim WISP diese oder ähnliche Dateien liegen?
Hilfe bei WI for SP 2007 Written by Thomas Koetzing on 2010-02-18 20:50:06Höchstwahrscheinlich ist dies bei WISP in eine DLL kompiliert und nicht anpassbar.
Comments
