4 Replies Latest reply on Jul 28, 2015 11:12 PM by brad

    Pharos "Extend Session" setting occasionally not working?

    brad Pioneer

      Ok, this is a bit of a weird one (just for a change heh), so any insight, suggestions etc. would be much appreciated.


      Firstly, our client environment:


      Pharos SignUp 8.2.6005.502 (upgrade is in the pipelines)

      Win7 HP all-in-one touch-screen PCs with DeepFreeze (for patron security/privacy, etc)

      Configured in Pharos to Reboot on Logoff, Can Extend Session, reservation types are Immediate/Queued/Scheduled, configured for a max reservation time of 60 minutes

      The public user group is configured for a maximum of 120 minutes/day


      And now, the problem/question:


      We've had a couple of reports that the "Extend Session" side of things is not always working. Now, I've been through the criteria for the session being extended with the staff, and have established that there were no bookings at the time the session was cut "short" at 60 minutes, instead of being auto extended, and there were also a number of available workstations.


      I've had a look at the few things I could think of in logs, session info, etc. to try and determine what the cause might have been, but not been able to find anything. Wondering if anyone's able to suggest something I may have missed? It's obviously not a huge "world-is-ending" issue - but when you have a visitor logged in with a guest card come up and tell you that they've been warned about being booted off shortly, you tell them "It's fine, your session will extend", only to have them come back 5 minutes later to tell you that you were wrong... it's not an awesome customer service experience... so helping the staff to avoid that in future would be kinda nice





        • Re: Pharos "Extend Session" setting occasionally not working?
          Katherine Baynton Ranger

          Hi Brad


          One thing comes to mind which may be in play here - the possibility that the client can't talk to the server to check for new reservations.  When a client machine cannot talk to the server it will operate in 'standalone mode' - appearing to be a fully functioning client, relying on the most up to date information it last received from the server (about configuration, impending scheduled reservations, etc).  If the client can't connect to the server at the point in time when the current session is due to end, it will not allow the extension of the session because the client has no idea whether there are other users waiting to use the computer, so to be fair it will end the session at the standard time.


          There are some things you can do to see if this is happening.  First you can check the Nerve Center and see if clients ever show up in a 'Faulty' state for short periods of time.  The lack of connection may still be present even if the clients don't show up as faulty because the Server may always be able to talk to the client, whereas the client may fail to establish a connection to the server (for some reason).  'Faulty' states in the Nerve Center will indicate when the Server cannot connect to the client, but the client failing to connect to the server may be a different problem and may not show in the Nerve Center.  (Note that the client and server do not keep an ongoing open connection - they reestablish connection as needed to prevent too much network load.)


          One slightly more extreme way to determine if the clients sometimes have trouble connecting to the server is to disable the 'Standalone' mode.  In this case, when an idle client cannot connect to its server, it will display an orange screen with 'Out of Order' text.  The presence or otherwise of this out-of-order screen can at least highlight whether this type of issue exists.  This can be enabled and disabled in the Computer Groups context.


          The particular version of connectivity issue I mentioned above (ie only one-way from client to server connectivity problems) can be hard to track down because as soon as the server reaches out to the client, the client will again know how to talk to the server for a while and the problem will appear to go away.  Often the best way to track this down is via logging on the client machine.  I suggest if you do see some 'out of order' clients that you contact Pharos Support for assistance on capturing logging to track this down a little further.


          Hope that helps some.



          1 of 1 people found this helpful
            • Re: Pharos "Extend Session" setting occasionally not working?
              brad Pioneer

              Thanks for that, Katherine – certainly food for thought!


              We do have occasional brief periods where the machines show as offline in Nerve Centre, but that’s generally after the PCs have rebooted themselves as part of their log-off/DeepFreeze restore functionality – takes a while for the system to “recover” from not having been able to contact the machine whilst rebooting…


              These machines are configured for standalone mode (only done in the last year or so – prior to that they weren’t set up for offline mode and would go out of service), so what you say is a possibility. Will have to see what I can do.


              Being a public library service, I’m fairly limited in what I can do, as disruption to the patrons is to be avoided at (almost) all costs. I’ll see what I can rustle up.





              Brad Martin

              Application Support Officer

              Organisational Services

              City of Gold Coast


              T: 07 5581 7513 M: 0414 180 233

              PO Box 5042 Gold Coast Mail Centre Qld 9729





                • Re: Pharos "Extend Session" setting occasionally not working?
                  Steven English Guide



                  Here a few comments that might be useful.  First, if I recall correctly, the clock will actually cease to count down when a patron enters the extended state of their session.  From this point on, the user is dangling out on the tail end of the session (just the 5 minutes left).  As soon as one of the session extensions checks is denied or fails to receive a continuation from the server due to network issues or general communication failure, the clock will then resume its final countdown to zero and log the patron off.  If the user sees the clock ticking down, it should still be modifiable via the Nerve Center unless there is a communication issue (which would help narrow the problem down).  As a side note, that 5 minute time can be modified in the Pharos Administrator but it also would likely result in you needing to re-evaluate both the low time and the critical warning time.


                  In reference to the machines going faulty during a reboot, unless the grace period has been changed since 8.2, the client machine should have a full 5 minutes to boot up before it gets flagged as faulty (I am presuming that there is a successful final check in with the server prior to the reboot).  If the machine boots back up and STILL shows as faulty in the Nerve Center, I would recommend investigating the following reg key on a machine that is frozen and is not connected to the network.  The lack of network connectivity will prevent it from having the opportunity to update itself.  Also, if the machine is showing faulty after a reboot and recovers instantly when a change control* is issued or the machine is disabled then enabled via the Nerve Center, then I would suspect that the client is having issue with proper communications to the server.

                  *In the event that multiple machines are faulty, a change control is likely to cause all or most of them to rebound from their faulty state if the disable/enable "trick" works.


                  Successful communications with the server whether initiated by the client or by the server should result in faulty statuses going away.  If the reg key value below holds something other than the IP address of the SignUp server, then you might be encountering an intermittent DNS issue.  My recollection is that a successful change control will result in this registry key getting updated to match the IP address that the SignUp server detects itself to be running on though the machine.  Of course, Deep Freeze would need to be disabled / in the thawed state for this to take effect.  Also, I could be wrong about the change control - it may require a restart of the SU server service and the workstation or a combination of the above.


                  32-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Pharos\SignUp Server\Host Address

                  64-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Pharos\SignUp Server\Host Address


                  Other things to double check for are DNS resolution issues between server and workstation (and vice versa), and even the possibility of just regular bandwidth saturation that may result in dropped packets and the workstation check-in suffered the impact.  This would be especially note worthy if the issue only occurs on workstations that have a WAN connection back to the SU server as opposed to a server at the local branch.  I hope this is helpful!




                  1 of 1 people found this helpful
                    • Re: Pharos "Extend Session" setting occasionally not working?
                      brad Pioneer



                      Thanks for that - certainly a fair bit more to chew on. Will shelve this one for the next time I come across an "out of order" issue, and will hopefully have opportunity to act on it, in order to try and determine if any of what you've said applies. Unfortunately, our libraries are spread across a fairly large geographical area, so it's not quite as easy as I would like... but we'll see how we go


                      I do have a test PC here on my bench - but of course, that being situated in our primary building, it never has an issues, as that would be FAR too easy to resolve