We've been having intermittent issues with some machines not getting updates pushed out from Pharos Admin, and I'm having trouble pinning down the cause... hoping someone has experienced similar and can offer some advice on where to look.
The scenario
(This has happened with multiple PCs - both virtual and physical - over time, from various sites, etc. with no commonality between them as far as we can tell. This example is just the latest of these instances)
One of our Deployment folks is working on some updates for our Catalogue PCs, and is working with his Pharos VM client machine. He wanted to change the machine from being a standard Public Internet PC to a Catalogue PC - made the changes in Pharos Admin, hit the Change Control and nothing happened. Rebooted multiple times, re-applied the changes, Change Controlled numerous times with no joy. Finally resorted to re-imaging the machine - to find it was STILL holding onto the old settings.
Disabling the PC from Nerve Centre works, confirming the communication between server and client are working fine.
What we've tried
- Multiple change controls, reboots, and a re-image
- Changed the Display name of the PC so it was a nice simple change which could be visually checked on the machine - no go
- Checked firewall logs between both servers (Signup and Database are on separate machines), and there are no dropped packets. A Change Control initiated a PING to the client, but didn't appear to be anything else?
- Change control to other machines in the system works fine (most of the machines, most of the time, at least)
So... putting this out there in the hope that it's something one/some of you have come across in the past and can pass on some knowledge/wisdom in the form of a silver bullet for our issue
Cheers,
Brad.
Brad,
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:
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