Pharos has a mechanism to handle this but it sounds like it may have malfunctioned. There are a few ways to clear this up. On the computer hosting the Xerox Management Console:
- Reboot the computer
- Restart IIS - from an administrator command prompt, enter the command "iisreset"
- From Internet Information Services Manager restart the web site.
I would be curious to know the Pharos mechanism that handles this. Is there documentation on this? Perhaps it has simply malfunctioned but restarting the computer, site or IIS in production would have to wait for a maintenance window. However, I see that it may be the only way to clear the session.
Yes, it's not ideal to restart the services but restarting at a late hour may be a good alternative. This will minimize the impact on users. The restart is actually quite fast, only a few seconds but it will invalidate any existing user session so if someone was logged in when the restart happened, they may be forced to login again.
There is no documentation because it's part of the protocol specification between the client (MFP) and server (UP). In Pharos the concept of a release station exists and each release station is responsible for periodically pinging the Pharos server to keep the user locked. Otherwise, after 5 minutes of inactivity on the session the user is unlocked. Some solutions, like Canon, literally have code running on the MFP itself so the call originates from the MFP. Other solutions, like Xerox, don't have code running on the MFP. Instead the MPF is pointing at a web service that has all the business logic.
For Xerox the release station is a construct inside the web service and the web service manages a list of release stations. This allows some number of Xerox devices to all point at the same Management Console and the Management Console properly handles all interactions simultaneously. This arrangement relies on the MFP to notify the web service of pertinent events like login and logout so the web service can manage the user session within the context of the release station.
Because of the crash the web service either didn't get a logout event or some other side effect caused the release station to fail to terminate the session resulting in the periodic call to keep the user locked to remain running in spite of several safe guards to ensure it is eventually killed.
Going full circle, since all this happens in the web service, not the MFP, the only recourse is to restart the web service.
Thanks Nick for the detailed information. I agree that a restart of IIS would be the best fix. I experimented with recycling the Application Pool (to isolate the iMFP site folder) and this did reset existing sessions. In the end, the problem session eventually timed out, so I did not have to do the reset.