web.sta – web-app, target browser is Internet Explorer 9 & 11

TextSystem – stand­alone desktop appli­cation, written in Java/Swing

Inter­me­di­ate­Layer – Client-Server app, linking web.sta and TextSystem together. 

web.sta can call TextSystem via the Inter­me­di­ate­Layer. Inter­me­di­ate­Layer creates an HTTP server for this purpose and web.sta simply sends GET or POST requests to the localhost. Inter­me­di­ate­Layer processes the request parameters and starts the TextSystem. There is no need for feedback calls, so the inter­action scheme is simple and robust enough.


In Citrix environment we can not create several listening sockets on the same IP address and port. It is necessary either to change the port, or to change the IP address. But Citrix provides a special mechanism for circum­venting this restriction, without changing the algorithm of the program. This mechanism is called Virtual IP Loopback. The admin­is­trator simply configure necessary appli­ca­tions in the Citrix config­u­ration panel and the appli­cation that uses localhost for socket connec­tions will receive not, but an IP address in the form 127.0.0. <SID + 1>, where SID is the session ID of the Windows user.

The Problem

All this worked fine under IE9 (and with other browsers too) on Windows Server 2008 R2. And then the clients wanted something new and Windows Server 2012 R2 appeared with IE11. And the whole system stopped working. Regardless of Citrix IE11 settings, when speci­fying “localhost” it always tries to establish a connection to, but nobody listens there. After a little research, we came to the conclusion that this is a bug in IE11.


If the virtu­al­ization for localhost does not work out of the Citrix box for IE11, then let’s write it ourselves!

For these purposes, we decided to write a windows service, which will be the simplest web server, listen to and redirect requests to the desired Inter­me­di­ate­Layer, based on the session number of the user. We did not find a simple solution to get the SID, but we immedi­ately found SESSIONNAME in the environment variables. In IE via ActiveX we get the environment variable, pass it as a parameter to the HTTP request. In RoutingService by the sessionname through wtsapi32.lib we get the session number. Then we redirect the HTTP request and return the response to IE.

Something went wrong

We began the testing and integration of our service. But not every­thing went as smooth as we would like.

As it turned out, the name of the session can be changed, although we did not under­stand in what condi­tions it happens. But often it happened that the session name changed, and IE11 only knows the initial value of the environment variable. And persis­tently passes this value to the RoutingService.

What is in the registry?

It is necessary to find another way to get the sessionname. We have looked for infor­mation about sessions in the registry and that’s what they found: in HKEY_CURRENT_USER \ Volatile Environment we can get a list of sessions of the current user.

If the user session is one, then every­thing is fine, we can read and use it. And if there are a lot of sessions for one user, then we need to somehow determine which session we are in. We could not come up with anything better than matching the path to the temporary files folder.

Here is an example:

In IE, we get the current path to TEMP using ActiveX Scripting.FileSystemObject.

This way we managed to get the name of our session. But that’s not all. The value of the keys under the Volatile Environment is, in fact, the SID is. That is, we can immedi­ately get the necessary IP address in JavaScript and send a request to it.

Shall we simplify it? 

Finally we can get the SID and establish a connection directly, without using RoutingService. But the solution still does not look beautiful. Studying the Internet showed that the problem exists, but the solution to this problem is not described anywhere. And the Microsoft keeps silence as well. 

We hope someone with this specific problem can benefit from our experience.