We had a very strange emv reader situation yesterday and I’m wondering if anyone has seen something similar. For background, we’re RAMP, Worldpay and often use remote desktop/roaming profiles.
During the day, we had users at windows 1, 2, and 3 (these are essentially their assigned windows and they sit in the same places every day). Everything was working fine. For show time, user 3 went home, and user 1 turned off his PC and moved over to window 3, logging into the PC and Tessitura with his own credentials. He mentioned something about his emv reader not working, so I suggested restarting the tripos service. When he did that, the emv reader back at window 1 was affected. He did a pc reboot and same thing- even though he was now at window 3, the emv on window 1 was being affected.
We then tried having someone else log into the pc at window 3 and having the user log into Tess. That didn’t make the emv at window 3 work. Only when someone else logged into the PC AND Tessitura at window 3 did the emv at window 3 work.
I’m just very confused as to how the emv reader worked fine for nearly everyone, but when this one user logged into the pc and or tess at window 3, it was affecting the emv at window 1!
Thanks,Kathleen
We had this happen once when we were using Worldpay. We finally figured out that the user was not logging out of Tessitura on window 1 then came back from back and logged back into window 2. Even if Tessitura timed out, it still hung onto the session. Our best solution was to have them do a full logout of Tessitura AND the PC on window 1 before leaving if they planned on switching workstations.
Apparently those Worldpay readers somehow hold onto a session if you dont logout properly. It might take some trial and error to replicate it, that's what we ended up having to do.
Kathleen,
(We are also RAMP) Similar to Grant. Two things: 1) for your Windows/Office instance, are you using roaming profiles? And 2) when user 1 turned off his PC and moved over to window 3, did he have to actually re-login into the Tessitura application, or did it just "come up"? Let me explain that last one. Being the IT/tech guy at our organization, I am frequently logging into and/or sitting down at different computers. I have noticed that, if I am logged into Tessitura on one computer, but have not disconnected the session, then log onto RAMP on a second computer and open Tessitura, it will not "log on" to Tessitura but essentially just yank the existing instance of Tessitura over to the new computer. And it will do that such that it will even be open already to the same exact order or customer account that I had open on the other computer. Essentially, the RAMP instance of Tessitura was never closed, but the computer to which I was connected simply changed.
In situations like that, I have seen it happen where, on that second computer, I could still control the EMV reader from the initial computer, and reverse. Our Box Office supervisors usually sit in the back, behind a wall, and so I have made sure to instruct them that when they need to move up front to work with patrons directly that they need to actually log OFF first in the back before logging back in up front otherwise they will not be able to use the EMV readers properly.
John
Hi everyone -
As John and Grant have noted, this is a particular idiosyncrasy of Windows and how we serve the Tessitura application in Citrix. When you open Tessitura in the hosting environment, you are essentially logging in to a terminal server which then opens the Tessitura client. The terminal services connection caches the Windows machine name that you are logging in from, and passes that to Tessitura, which then determines which EMV device (from TR_MACHINE_SETTINGS) is activated. This is true with Windcave and Worldpay EMV devices.
If you jump from one computer to another without logging out of Tessitura and Citrix, your existing terminal services connection is re-established on the new computer (this is why Tessitura just "pops up") and the Windows machine name is not re-cached in the session. Doing a full logoff (or even ending your session in the Self Service tool) is a good way around this for users who move around frequently.
This is noted on the Defect List under "Reported Defects that Won't be Fixed" using key DEVOLD-4285 - as it is related to something in Windows that is beyond our control.
Thanks!
Patrick
Thanks, all. At least I can now cross off *this* mystery from my plate!