Windows Live Alerts
EnglishDeutsch
|
Contact
|  
   
 
Start access
Article
Support Forum
SBC FAQ
XenApp/XenDesktop
Remote Desktop Services
Terminal Services
Web Interface
Tips & Tools
Sponsors 
 
ControlUp 4

Understanding Web Interface SessionSharingKey Print E-mail
Written by Thomas Koetzing at Wednesday, 06 January 2010 | Article editor: Carl Webster

Article Details 
 
User Rating:   | 517
PoorBest 
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=8-basic-basic--user@dom.local-farm1

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.

WI Domain

       

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!


Server Domain

       


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.


GPO default domain

       



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:

SessionsharingKey=8-basic-none-mydomain-user-farm-Off-Off--On-On

translated to: colors + "-" + encrypt + "-" + audio + "-" + domain + "-" + user + "-" + farm + "-" +            specialFolderRedirection + "-" + virtualComPortEmulation + "-" + comPortMapping + "-" + clientPrinterPortMapping + "-" + clientPrinterSpooling

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
:grin  
 
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:55
evtl. 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:06
Höchstwahrscheinlich ist dies bei WISP in eine DLL kompiliert und nicht anpassbar.


Web Interface 5.3
Written by Guest on 2010-09-07 15:40:03
How do you accomplish the same thing in 5.3 when you don't have the ICA files anymore? 5.3 moved to .aspx files for launching apps.


Web Interface 5.3
Written by Thomas Koetzing on 2010-09-10 13:46:25
>How do you accomplish the same thing in 5.3 
> when you don't have the ICA files anymore? 
WI still generates IC files and I did wrote how to get them in the article! See the follwoing CTXKB 
http://support.citrix.com/article/ctx115304 
http://support.citrix.com/article/ctx111820

Written by Guest on 2010-09-24 21:25:17
Very Nice! More then one session per server was causing adobe reader to not print. Using GP to set my domain without the .local worked for me!! 
 
Thanks


Session Sharing Key identisch - trotzdem
Written by Gast on 2011-07-20 12:06:27
Hallo Thomas, 
 
herzlichen Dank für den prima Artikel. Habe daraufhin für einen Anwender, der mehrere Sessions auf unterschiedlichen Servern offen hatte, einmal seine .ica-Dateien überprüft: trotz identischen Session Sharing Key wurden seine Published Apps (alle mit identischen Einstellungen!) auf verschiedenen Servern gestartet. 
 
Ich bin mir auch sicher, dass zum Zeitpunkt des App-Starts KEINE 'Überlastung' eines Servers auftrat. 
 
Wo könnte ich deiner Meinung nach noch Richtung Troubleshooting ansetzen? 
 
Unsere Konfig: WI 5.2, PS4.5 mit PS450W2K3R05, W2k3 SR2 
 
Herzlichen Dank, 
 
Rolf


netbios domain name
Written by Gast on 2011-11-24 08:43:58
guten Morgen Herr Kötzing 
Hoffe Sie können mir einen Tip bezüglich der Einstellungen geben, irgendwie bekomme ich das Ganze nicht so richtig zum laufen. 
WI 5.4, 2008r2, xa6 
ad name ist icb.ch  
netbios name ist dummerweise icb-dom 
Den GP Eintrag sehe ich, kann ich das ganze auf icb runterbrechen? 
Danke Ihnen für Ihre Bemühungen und verbleibe  
mit freundlichen Grüssen 
Thorsten

Written by Guest on 2011-12-29 18:45:05
Thomas - Please comment more on why you feel PNAgent sholdn't be used as a startmenu replacement for the end users. Application access restrictions are configured in AppCenter ( DSC, AMC Etc SO MANY NAME CHANGES !!! :) ) why have the admin go back and configure custom start-menu's and lock down user's to specific apps, when the plugin does this for us?  
 
Do you feel different about this with recent web interface versions?  
 
Thanks!


PNAgent sholdn't be used as a startmenu
Written by Thomas Koetzing on 2011-12-29 18:52:43
I will write an article about it but it has nothing really to do with Web Interface!  
Many people for one don't know how easy it is to build a central access controled start menu and secondly how many possible issue using PNAgent (Online Plug-in) as start menu replacement has.

Written by Guest on 2011-12-29 19:12:34
Thomas - Thanks for the reply. My question in relation to web interface was specifically around the session KEY, do you find it still being an issue when using PNAgent inside of the published desktop? ( i'm having that issue right now older version of cag)  
 
I would love to know the potential issues that you are speaking about in regards to PNAgent being used as start menu replacement. If an organization has lets say 20 applications all with different level of access, from my understanding each of those icons would need to be given ACL's to reflect who can have access? It won't take to long to configure, but when speaking with other's and testing it out PNAgent appeared to work great and resolved giving user's the apps they require access to and handles the icons. I've always done the PNAgent and a lot of other folks i know do it as well. understanding the impact of doing this would be great to know.  
 
I'm having a session sharing issue that your describing right now, has to do with VPX 4.6.2, and XA 6.5. Session sharing breaks when using receiver 3.0. I believe it's the same issue your describing above. CAG uses DOMAIN.local and PNAgent pass-through is using netbios name "DOMAIN". If I check the Use Kerberos check box it forces FQDN, and session sharing works. I didn't enable any of the delegation or anything, just checked the box so PNAgent would authenticate using FQDN.  
 
I haven't seen this issue with newer version of CAG. It seems to happen with the 4.6.2 version.  
 
Really looking forward to your post regarding the PNagent...


WI 5.4 and Session sharing key (SSK)
Written by Thomas Koetzing on 2011-12-30 07:25:12
Yes the SSK is still an issue with Web Interface 5.4 and even worse, since Citrix removed the option to disable the hash as described here. Therfore troubleshoting has become a guess game to find out what the problem is.


Disabling hash on WI 5.4
Written by Guest on 2012-01-14 00:42:40
Has anyone figured out a way to disable the hash process for WI 5.4?


Lösung für WI 5.4 bzw. ohne den Hash zu
Written by Jens on 2012-06-21 16:15:46
Bei dem WI 5.4 hilft das CDFCONTROL Tool von Citrix weiter. Man erhält auch nicht nur den SessionSharingKey sondern auch die entsprechende Fehlermeldung warum das SessionSharing nicht funktioniert.  
 
Gruß 
Jens 
---------------------------------- 
 
1.) Das CDFControl Programm auf dem WI Server starten. 
 
2.) Im Menü "Tools>Options" die Option "Enable real-time viewing while capturing trace" aktivieren. 
 
3.) Im Menü "Tools>Download TMF Files" die Dateien herunterladen oder die Option "Dynamic TMF Download - Enable" aktivieren. 
 
4.) In der Dropdawn-Box "Trace Categories" "Session Disconnects" oder wenn mehr als zur Fehlersuche "All Modules" auswählen. 
 
5.) "Start Trace" 
 
6.) Neue Session/Anwendung auf Client starten 
 
7.) Im CDFControl z.B. nach Early, SharingSettings, SessionID, Domainname, Key, SSK oder Session suchen.


Lösung für WI 5.4 bzw. ohne den Hash zu
Written by Thomas Koetzing on 2012-06-22 09:53:03
Das ist leider so nicht ganz richtig. Auf einem Server NUR mit Web Interface gibt es keine Möglichkeit eines CDF Trace (für WI). Du hast ein Trace auf einem XenApp Server MIT Web Interface ausgeführt und dabei CDF Trace genutzt.  
Was Du da Traced ist also vom XenApp Server und zeigt nicht wirklich die Auflösung des SessionSharingKey aber zumindest ein Anhaltspunkt. 
 
Danke für den Hinweis!


NOTE  
NOTE  You have to register in the Forum to post comments with your name.

Write Comment
Name:Guest
Title:
BBCode:Web AddressEmail AddressBold TextItalic TextUnderlined TextQuoteCodeOpen ListList ItemClose List
Comment:




Code Verification
CAPTCHA Security Code Security Code *


 
find or follow me @