1 of 1 people found this helpful
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.
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.
Application Support Officer
City of Gold Coast
T: 07 5581 7513 M: 0414 180 233
PO Box 5042 Gold Coast Mail Centre Qld 9729
1 of 1 people found this helpful
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!
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