MSI file (r6684 with no HTTP)

Mon, 16 Nov 2015 12:26:23 +0000

From: Yann Guilbert
Sent: Friday, 13 November 2015 9:30
To: Pierre-Philippe Fouret pfo@efficy.com; Dave van der Heijden dvanderheijden@efficy.nl
Cc: Yannick Pierrard ypi@efficy.com; Alexandre Istratov ais@efficy.com; Audrey Levin ale@efficy.com; Alexis Duclos adu@efficy.com
Subject: RE: Efficy Incident | Side-bar 6640/ terminal server.

Hello,
I think there is some confusion that I need to clarify before answering :

The actual problem of the “new” standard sidebar (which provides a replacement for the former java/activeX FileHelper) communicates with the Efficy interface in HTTP (via ajax calls). To do so, the sidebar launches an embedded HTTP server which listens on localhost (127.0.0.1) on one static TCP port (56693 by default). The problem in TS/Citrix environment is that the socket (the network connection) is bound to the network interface, and thus shared amongst all citrix/TS sessions.

The resulting behavior is :
A first session launches the sidebar, which successfully launches the HTTP server because the port 56693 is not “locked” by any other process.
A second session tries to launch the sidebar, but it fails to open it on port 56693 because it’s already taken by the first session, so it tries the successive port, 56694.
etc, with an arbitrary limit at 5 ports.
So now in TS/Citrix, you have 5 users that are able to use the sidebar (again, only for the filehelper part), and the future users won’t.

This behavior of skipping to the next port is not a TS/Citrix feature, it is intended for improbable scenarios where another process is using the sidebar default port, as a non-blocking workaround. But this is not what we want to use as a solution for TS/Citrix environments, because it is highly dirty on what it would require on the interface side (launch 500 ajax connections on a range of port if a customer has 500 users ? we don’t want to do that) .
For TS/Citrix environment, there is a well-documented solution, which is called : Virtual Loopback (http://docs.citrix.com/en-us/xenapp-and-xendesktop/7-6/xad-deliver-virtual-ip.html). This solution exists precisely for our type of scenario, as we can read on this doc :

“Certain applications, such as CRM and Computer Telephony Integration (CTI), use an IP address for addressing, licensing, identification, or other purposes and thus require a unique IP address or a loopback address in sessions. Other applications may bind to a static port, so attempts to launch additional instances of an application in a multiuser environment will fail because the port is already in use. For such applications to function correctly in a XenApp environment, a unique IP address is required for each device.
[…]
Virtual loopback
Enabling the Citrix virtual IP loopback policy settings allows each session to have its own loopback address for communication. When an application uses the localhost address (default = 127.0.0.1) in a Winsock call, the virtual loopback feature simply replaces 127.0.0.1 with 127.X.X.X, where X.X.X is a representation of the session ID + 1. For example, a session ID of 7 is 127.0.0.8. In the unlikely event that the session ID exceeds the fourth octet (more than 255), the address rolls over to the next octet (127.0.1.0), to the maximum of 127.255.255.255.”

The current situation is that we didn’t have the time/chance to test it in a “real” Citrix environment. This test is planned but has not been done yet.
So until this test is done, what we did is provide a MSI of a sidebar compiled with no HTTP server, and set a SysStorage value (“IgnoreSidebarHttpd” = 1 ) to force the interface into ignoring the Sidebar HTTP feature, thus falling back to the java/activeX solution.

Now, as you must now understand, in theory, there is no “fix” to put in the sidebar, this is more an infrastructure configuration that needs to be set (virtual loopback) on the customer side.
But we need some testing to validate this.
In the meantime, the MSI I provided with no HTTP in it has been done to let the TS/Citrix customers be able to work “the old way”, while we confirm the configuration that needs to be made to make the sidebar work with the Citrix Virtual Loopback feature.
But we won’t do a NO-HTTP sidebar MSI at every build, no.

I hope it clarifies the current situation, and answers the question 
Feel free to ask questions if needed.

KR,

Yann Guilbert
R&D Developer

From: Pierre-Philippe Fouret
Sent: jeudi 12 novembre 2015 17:51
To: Yann Guilbert ygu@efficy.com
Cc: Dave van der Heijden dvanderheijden@efficy.nl
Subject: Efficy Incident | Side-bar 6640/ terminal server.

Hello Yann,

That Msi will be available on the next build or it’s very specific for Citrix server?

https://ivm.efficy.com/efficy.dll/dialog?page=remote/DialogOperation&action=View('Case',54613)&close=T
<efficyCase54613-1903940559/>

Regards,

Pierre-Philippe

Gray shaded box disappear on Agenda after doing custom css file

Thu, 29 Oct 2015 14:29:43 +0000

Dears,

I'm facing a problem when doing custom css for agenda actions according to "mode" value.

The Gray shaded area that appears usually for time before and time after is diappeared, the whole appointment becomes one block (including the time before and time after). as in snapshot.

this is the css custom i use:

.MeetingOut .fc-content{font-size:8pt; color:black; background-color:#FF7F27;
border:1px solid #888; overflow:hidden; z-index:99; filter:alpha(opacity=85); -moz-opacity:0.85; opacity:0.85;
-moz-border-radius:10px; border-radius:10px}

Please advise how to keep the gray shaded areas for time before and time after.

Thank you for your help.

Best Regards.

Efficy Overflow Q&A - Recent questions tagged after

MSI file (r6684 with no HTTP)

Gray shaded box disappear on Agenda after doing custom css file