We have ran into the same issues, and have had a ticket open for it. We have done some testing with Pharos, and it looks like the issue may happen a few different ways. What we originally found was users swiping their ID with the device being asleep would usually result in an error: null being displayed and then they would be locked onto the device until you rebooted the device or restart IIS. Pharos found that issue, and supplied us with a test release of the Ricoh MFP software, which resolved that issue. It was still occurring intermittently at that point, and they are working on a new release that completly fixes this issue from the last update in our ticket.
Unified Technology Support
Ball State University
Hopefully Pharos will get to the bottom of the issue as to why the users get locked on the devices in the first place.
But in the meantime if you have lots of locked users and you need to unlock them, I wrote a little tool to it at my previous company as it happens more often than you'd think, comes with no support or warranty, but setup and usage instructions are in the readme
This is an issue that seems to rear it's head every so often across various platforms. We had the same issue a year or two ago with our Canon fleet on Campus and the only way to "unlock" the user was to reboot the device they were locked on or restart IIS on the server (not an ideal solution). Like you were worked with Pharos and they provided us with an update iMFP for the Canon devices and we haven't seen the issue since. Hopefully you get this resolved quickly
IT Systems Engineer
Robert Gordon University
This happened to us this week and we currently have a ticket open with Pharos support.
I've seen this issue many times over the past few years. It is usually correlated with a printer alert event (like running out of paper) while a user is logged in. I have not made a 100% correlation with printer alert events, but some of my printer hosts on campus have observed a trend in that direction. The flow looks like this:
1. printer is idle, and low on paper.
2. user sends a print job to the queue and badges in at a printer.
3. user selects print job and printing commences.
4. printer runs out of paper before job is complete.
5. user session on printer times out.
6. user is unable to login to any other printer, instead seeing the "account locked at terminal" error.
7. a variable amount of time must pass before the user account is no longer locked at the terminal. Sometimes minutes, sometimes days.
8. if I go into Pharos Admin, archive the user's information, and delete the user's account, this effectively solves the problem, but then requires the user to re-register at the next badge authentication at the printer.
We are running Pharos Uniprint 9.1 with new (as of Jan 2017) Ricoh printers.
Kourt de Haas
In our system it is the CSGold that only allows a card to be active at one location at a time. The vast majority of the time a user will be automatically logged off the iMFP after 60 seconds (time set during device setup). However, about once a month there is a convergence of the stars, or gremlins or jams or something, and an iMFP retains a user's card swipe for an indefinite period. We also have seen an occasional correspondence with an event at the iMFP, although nothing like a direct correspondence. When this happens, the iMFP must be reset in order to clear the users credentials: I do this from the comfort of my desk.
We also have a fleet of Ricohs. We have observed this for several years over many different models of printers and with Uniprint 8.1, 8.3, and 9.0.
I thought I would chime in here. The real reason a User is locked on a Terminal is because when a User logs into the system at a Terminal, the Terminal solution makes a call to the Pharos EDI Service that tells it to "lock" the user. The EDI then retains this association of the User to the Terminal until the Terminal makes a call to the EDI named UnlockUser() to remove this lock. This is when the EDI service (that which lives in IIS as a web application) then removes the link between the User and the Terminal.
Now, why does the Terminal not unlock a user out when they logout? Well, it will vary based on the iMFP solution. For the Ricoh solution the on-box solution what we have seen is that the user logs in but the application throws an exception just after this so the application fails to make the required UnlockUser() EDI call, thus the user remains locked in the EDI to that Terminal.
*Sometimes the user simply did not logout but the device timer should kick in and fire off the UnlockUser call.
For the solutions that have "middle-ware" so to speak like the Xerox iMFP and KM iMFP things are not much different. We expect the KM device to send us a command telling us that the user pressed the logout button or the 1 minute timer on the device to kick in and send a command to the server that the user has logged out. This command originates from the device then to the Application Service which in turn would communicate this logout to the EDI. When the user is not unlocked it is somewhere in that pathway that starts with the device.
If you can reliably reproduce this it would be helpful to troubleshoot.