3 Replies Latest reply on Aug 11, 2014 3:27 PM by Yadin Flammer

    Print Server Update breaks service

    Yadin Flammer Navigator
    Yadin Flammer Aug 7, 2014 12:54 PM

      I have now replicated several times that trying to update Pharos Print Server (PServer.exe) 8.4 to the Rev 94 update breaks the system in some way for no known or explained reason.  Once you update this (along with the secure release service), while the server appears to be working, and Administrator shows all lights are green, the Pharos Print Server service is not running, so the server is not actually working.  This seems to be a design flaw where it's not properly showing and reporting a major issue.  The service will not start giving error 1064: An exception occurred in the service when handling the control request.  You can not roll back to fix the problem, whatever the update did breaks the service entirely for any version it seems.  This happens 100% of the time, so I am baffled how this has not been fixed, or if there is a known work around why that has not been published.  But, it tells me people must have an answer for this since everyone must have encountered it, and hopefully someone here can lend a hand as I have not been able to get a response from support.

      Thanks!

      • 179 Views
      • Categories: Version 8.4
      • Tags:
        • Re: Print Server Update breaks service
          Steven English Guide
          Steven English Aug 8, 2014 10:24 AM (in response to Yadin Flammer)

          Yadin,

           

          I have updated multiple dozens of print servers and do not recall ever encountering the scenario you are describing.  The 1064 error is a licensing error.  Check to verify that you have not exceeded the number of active printers assigned to your license.  Another possibility for a 1064 error is incorrect version numbers being installed (e.g. an 8.4 hotfix on an 8.3 or 9.0 server).  You might consider looking in the Pharos\Bin folder, going into detailed view, and then enabling the file version column to see if one or more of your major components (executables such as your license server, print server, etc...) are of different versions.  Follow the instructions in the hotfix to confirm the version numbers for the SecureRelease service.  The print service is dependent on the SRS, so if it won't start, neither will the print server.  I do not expect that to be the case here simply because you are getting a license check error.

           

          Regards,

          Steven

          • Re: Print Server Update breaks service
            Scott Olswold Guide
            Scott Olswold Aug 11, 2014 3:12 PM (in response to Yadin Flammer)

            Yadin,

             

            Please ensure that either the ZIP from which you extracted the PServer.exe update, or the updated EXE itself, is not "blocked". This is a "feature" of the Windows operating system that tags files copied from "wild" or restricted zones such that they cannot be immediately used without explicit user action. To see if it is, simply go to the Properties page of the suspect file and look at the General tab. If you see a button like the one here:

             

            BlockedFiles.png

             

            outlined in red, simply click that button to restore common access to the file and carry on.

             

            -Scott

            • Re: Print Server Update breaks service
              Yadin Flammer Navigator
              Yadin Flammer Aug 11, 2014 3:27 PM (in response to Yadin Flammer)

              Thanks for the replies, the issue has been identified.  It's actually due to a bug in the software (8.4 rev94) where it does not write a needed key to the registry, so it can't find itself.  This has been reported to support.

               

              For anyone else who hits this, the problem is that the MachineName string value is not written under the parent Pharos key.  This must match the value in Pharos Administrator under Server Configuration -> Host Name, which must be the aname of the system in DNS or it's IP (it can NOT be a cname).  By default this is set to the machine name, but to work properly cross subnet (historically) this needs to be set to a FQDN.  Because of the bug however, changing this breaks the print server service unless you also update the registry value.

              Under 8.1 this could be a cname, apparently that was removed for some reason.  Using a cname will not stop the print server from starting as having these values mismatched will, but it will cause the system to be unable to find the print drivers for some reason.  I'm guessing at some level this may be due to the replacement of Windows printing with Secure Release.

              Also noted was that if the print server service is stopped, Pharos Administrator lists almost all services as stopped even though they are started.