-
Re: Trouble pushing updates out to Signup client(s)
1 of 1 people found this helpfulBrad,
The change control essentially serves to tell the SignUp server that some settings in the database have been changed and that the system should check back in to update the local settings. In other words, it is a soft reboot of the system, and it is dependent on firewall ports to issue the change control (28207 is the change control port on the workstation - or simply try disabling the firewall). Restarting the SignUp server service assigned to the branch that the offending computer belongs in followed by restarting the offending PC should be the equivalent of a hard boot of the system and force the config to take effect.
Questions & Things to Test/Double Check:
- Which version of Pharos are you running? (e.g. 7.x, 8.x, 9.x)
- What value is in the following registry key? ( HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Pharos\SignUp Server\Host Address ... remove the Wow6432Node part if on a 32-bit machine)
- What value is in the following registry key? ( HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Pharos\SignUp Client\ConfigFileDir ... remove the Wow6432Node part if on a 32-bit machine)
- Does your image have the Pharos SignUp product pre-installed?
- If pre-installed in your image, do you have security software like Deep Freeze or Smart Shield installed also?
- If security software exists, have you tried thawing/unrotecting it out to see if it makes a difference?
- Have you tried deleting the SUClientXxxxxxx.bin files and letting them recreate (see details in paragraph below)?
- If this is recently after a migration, do you possibly have an old Pharos server or two hanging around that might be sending instructions contrary to the ones you are trying to set in the current production system?
- Is IPv6 disabled on all your SignUp servers (it should be!)?
- Whether you use DHCP or static IPs and a HOSTS file, have you checked to make sure that everything is resolving properly (you should be able to telnet from the client to the server on port 2352 using the value found in step 2, and you should be able to telnet to the client on port 28202 from the server using the computer's network name as found in the Pharos Administrator)?
- Have you tried any of this with the firewall disabled on the workstation?
The only thing on the workstation that retains configurations are the SUClientXxxxxxx.bin files which are stored by default in the Pharos\Bin directory unless configured otherwise (as per the reg key in step 3). There are usually somewhere between 5 and 10 of them present on the workstation at any given time (replace Xxxxxxx with SessionData, BlockReservations, ScheduledReservations, and so forth). These files will recreate automatically on boot and they are safe to delete. This should force the client to re-populate these files from the server, but you would want to ensure that any security software is off or be certain that the security software is not wiping/replacing/restoring the folder with the bin files in it. The quickest way to verify behavior of security software would be to follow the instructions I provided in another thread Configuring SignUp to Work with Clean Slate.
Regards,
Steven
-
Re: Trouble pushing updates out to Signup client(s)
Hi Steven,
Thanks for the quick and thorough response - very much appreciated. I did actually have a fairly long response ready to respond to this yesterday, but life conspired against me, and I've had to go for it a second time around Answers to your questions below (slightly more detailed than they were yesterday, as I now have direct access to a "test" PC to test this stuff on):
- 8.2.6 - sorry, had 8.2 in the tags, but forgot the put the full detail in my question
- Set to the hostname of our primary Pharos server
- Set to the local "thawed" drive of the machine
- Not pre-installed per se - we're a MS house, using SCCM for imaging and application delivery. The base image goes onto a machine, and then the applications are layered on via MSI installs by SCCM.
- Yes, we are using DeepFreeze
- Yes, we've tried this, with no change in behaviour. As mentioned above, the bin files are also stored on the thawed partition.
- Yes - tried doing that just now. Moved the files to a sub folder so I could do size/date/time comparisons on them, then rebooted the PC. The files were re-created with todays date/time, but the issue remains.
- N/A
- No IPv6 on the server, but I've just checked and the client has IPv6 enabled. Will do some testing around that and see how I go.
- Haven't gone down the TELNET path, as the machine is communicating with the server - can enable/disable it via Nerve Centre, and can authenticate to it also.
- No firewall enabled on the machine, as the firewalling's done at an enterprise level.
I'm off to play with the IP settings for now - just wanted to get a response posted in here so you knew I wasn't ignoring your very helpful info I'll report back later once I'm done "playing".
Cheers,
Brad.
-
Re: Trouble pushing updates out to Signup client(s)
Quick update - no IPv6 on the servers, but our client machines, being Win7, have both IPv6 and IPv4 enabled on them. Is it worth investigating this as a possible cause, or does having it disabled on the servers remove that as an possible cause?
-
Re: Trouble pushing updates out to Signup client(s)
Brad,
The SignUp Server\Host Address key should have an IP address in it. If you issue a change control from the server, the client machine should receive that change control and one way or another the key should update to the IP address (I don't know if the change control result in the client receiving its updated info, but I expect it receives a command that tells it to reach back out to the server and to get it's new settings). If this fails to happen, it would indicate that things are breaking down either with the client being able to receive the change control command, or with the client being able to resolve the server's name (no duplicate entries in DNS for the server name in that key, right?).
You could try disabling IPv6 on the client to see if that resolves the change control problem, or you could try manually changing the key to the IP address of the appropriate SignUp server. It may be worth looking at the reg keys on the clients that are not having any problems to see what they have for the server's Host Address. If the issue is the client failing to reach out to the server, likely symptoms would include machines that appear to go faulty, but then interact just fine when you try to issue a command from the server. Essentially the communication is working from server to client, but not the other way around. The telnet tests should illuminate any DNS and/or firewall issues.
Regards,
Steven
-
Re: Trouble pushing updates out to Signup client(s)
Been a busy day and not had a chance to look into this myself today - but I did pass the info on to the Deployment officer that's having the issue with the VM, to see if he could test the bits and pieces you've suggested and try to determine the cause. Unfortunately, TELNET etc. all worked OK. Disabling IPv6 on the clients could be a tad problematic, with them being Win7, I'm going to have to do some reading up on that - I have an MS article on that set aside to have a read of a bit later.
The thing which is confusing me about this more than anything, is that the machines continue to have the issue even after a complete re-image/rebuild. You would think that, as part of the installation of the client, that the machines would "call home" to find out what they're meant to be...
I did have a thought that there may be a disconnect between what Pharos Admin is showing me, and what's in the database - but I had a poke around in there, and confirmed that the settings for the machines we've been looking at are indeed what they should be... they're just not picking up those settings, for whatever reason. Very frustrating.
I'm going to go through our Change process in order to get approval to restart the services on the boxes, as I've not done that yet. Wouldn't be surprised if that fixes it... but also won't be surprised if it doesn't, with it being such a selective issue on so small a sample size of our collection...
I've also tee'd up with our senior Security person to help me with some firewall log analysis on Wednesday if that doesn't work, to see if we can do some comparisons between calls made to/from a known good machine, vs one of the known-bad ones.
Will let you know how I get on.
Cheers,
Brad.
-
Re: Trouble pushing updates out to Signup client(s)
Brad,
I was wondering if you guys ever figured this one out, and the following thought crossed my mind when I reread the part about it being a VM. ESXi - like many other hypervisors I would expect - have an option in the VM config to discard all changes and revert to snapshot. That may be a long shot, but unless you have already figured it out, it might be worth having a look. I have worked with people in the past that made configurations to a large number of machines only to have it all get wiped out when the machine is rebooted. If the system is thawed and then refrozen in one reboot, maybe this is being overlooked.
Regards,
Steven
-
Re: Trouble pushing updates out to Signup client(s)
Hi Steven,
Thanks for the thoughts. Unfortunately, only the servers are VMs – the workstations themselves are fat clients – HP all-in-one touch-screen jobbies. They have DeepFreeze on them, which reverts them back to their previous system state on each reboot, in order to protect patrons’ privacy, and all that jazz.
However, the configuration side of things has been configured to reside on a hidden “thawed” partition, so that config changes etc. are able (theoretically!!) to be pushed out to the machines without the need to thaw them. Software updates and stuff are a different matter, obviously, as they need to put stuff on the system drive – to combat that, we have 2 maintenance windows/week where the machines are thawed overnight, and the updates pushed out to them via Microsofts’ SCCM.
And in answer to your question – no, we’ve not sorted it out. I’ve pretty much put it on the back-burner for now, in the hopes that a semi-planned upgrade will just magically make that particular issue go away. Unfortunately, we’re in the process at present of doing a replacement of one of our other more major systems than Pharos, so time/resources/money are a little lighter than they need to be in order to progress the Pharos upgrade.
Cheers,
Brad.
-
-
-
-