Log in to create and rate content, and to follow, bookmark, and share content with other members. Not a member? Join Now!

AnsweredAssumed Answered

Trouble pushing updates out to Signup client(s)

Question asked by brad on Nov 19, 2014
Latest reply on Jul 8, 2015 by brad

Like • Show 1 Like1
Comment • 7

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.

No one else has this question

Outcomes

7 Replies

Steven English Nov 19, 2014 11:53 PM
Mark Correct
Correct Answer
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:
1. Which version of Pharos are you running? (e.g. 7.x, 8.x, 9.x)
2. 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)
3. 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)
4. Does your image have the Pharos SignUp product pre-installed?
5. If pre-installed in your image, do you have security software like Deep Freeze or Smart Shield installed also?
6. If security software exists, have you tried thawing/unrotecting it out to see if it makes a difference?
7. Have you tried deleting the SUClientXxxxxxx.bin files and letting them recreate (see details in paragraph below)?
8. 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?
9. Is IPv6 disabled on all your SignUp servers (it should be!)?
10. 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)?
11. 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
1 person found this helpful
Like • Show 2 Likes2
Actions
- brad @ Steven English on Nov 20, 2014 11:12 PM
  Mark Correct
  Correct Answer
  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.
  Like • Show 1 Like1
  Actions
  - brad @ brad on Nov 21, 2014 12:20 AM
    Mark Correct
    Correct Answer
    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?
    Like • Show 1 Like1
    Actions
    - Steven English @ brad on Nov 21, 2014 7:12 AM
      Mark Correct
      Correct Answer
      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
      Like • Show 1 Like1
      Actions
      - brad @ Steven English on Nov 24, 2014 1:29 AM
        Mark Correct
        Correct Answer
        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.
        Like • Show 1 Like1
        Actions
        Steven English @ brad on Jul 8, 2015 5:43 PM
        Mark Correct
        Correct Answer
        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
        Like • Show 1 Like1
        Actions
        brad @ Steven English on Jul 8, 2015 6:00 PM
        Mark Correct
        Correct Answer
        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.
        Like • Show 0 Likes0
        Actions

Trouble pushing updates out to Signup client(s)

Outcomes

Related Content

Recommended Content