1 of 1 people found this helpful
In general, that message means that it's trying to communicate with the Signup server to gather it's settings. If that message stays up too long, it means it's having trouble making a connection to the server.
Some questions for you:
Does it continue to display this message indefinitely, or does it eventually connect (or timeout)?
You mentioned that a reboot does not help, have you found anything you can do to make this connect?
Is this a recent change in behavior or has it been going on for some time? Does this event correspond with any changes (updated versions, replaced computers, network changes, etc.)?
You mentioned that "a few stations" have this problem, is it always the same stations, or does it happen on all of them from time to time?
Does Deep Freeze seem to have anything to do with this issue? If you disable it (or remove it) on the offending machines, does that change the behavior?
Overall, what troubleshooting steps have you tried so far? Have you opened an incident with Pharos Support yet?
-Jeff Herald - Pharos Systems
hi Jeff, thank you for your reply.
here are the answers to the questions...
This message remains on the screen. it does not timeout.
no change related to updated versions, replaced PCs, or network changes.
it happens randomly to different stations.
the second question was skipped because i wanted to address it with the deep freeze question.
We've noticed that the only way to log in is by using windows remote desktop. and the deep freeze service is not started as it should. we have to go into services and manually start the service and reboot. this does not always correct the issue. but on some occasions it does. so maybe deep freeze is preventing the handshake with the server. have you heard of this happening?
and before i get with the sysadmin who handles the tickets that are put in with Pharos, i wanted to reach out here. i was able to address the issue with proper troubleshooting with the info provided in my last question about the console notifier.
we really appreciate it.
1 of 1 people found this helpful
Well, if you're able to connect via Remote Desktop, then we can assume the network is functional. If Deep Freeze in involved in the boot up of the system, and it fails to start correctly, it's possible the system is prevented from booting up to the point where the Signup Client can complete it's process. Of course I don't know if that's the problem, I'm not an expert in Deep Freeze. I'd sure like to know how well the Signup client works with Deep Freeze out of the way for a bit though. Is that something you can try for long enough to know if it makes a difference?
yes. we have a test area. it never went into that mode of the Signup client. its one of those strange instances were the same package of Deep Freeze could be installed on 3 different machines with the same config and one of those machines get the message and the other two work fine.
i was just curious any extra steps we could take being that once its on that window there's no way for us to log in locally. we have to get on another PC to try and shake it out of that mode.
as a side note we have also seen the Reservation station do the same thing while deep freeze is installed.
it will give the error "unable to connect to the pharos server". Our solution for that was do do away with deep freeze all together on the reservation stations.
so its mainly an issue some of these PCs have with deep freeze activated, and the step where the client tries to reach the pharos server.
it sounds like Deep Freeze is not launching the virtual drive for the ThawSpace which is where the SignUp client .bin files are stored.
Assuming the clients are 64-bit, please check the following path in the registry (doing this from memory, so it may not be perfect):
This key points to where the files are stored, and in my experience is traditionally the root source of the issue when seeing the message you are seeing (the SignUp client cannot find its local config files). Typically - though not necessarily exclusively - a network issue presents itself on the client as out of order (if standalone mode is disabled) or by triggering standalone mode.
You can try pointing the config files to a different path to see if that resolves it. The default folder for the bin files is C:\Program Files (x86)\Pharos\Bin.
If if that is not the issue, we can look at troubleshooting communications to and from client and server.
thank you, Steven. we will give that a try and get back with the results.