AnsweredAssumed Answered

Print Server Update breaks service

Question asked by Yadin Flammer on Aug 7, 2014
Latest reply on Aug 11, 2014 by Yadin Flammer

Like • Show 1 Like1
Comment • 3

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!

Yadin Flammer Aug 11, 2014 3:27 PM

Correct Answer

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.

See the reply in context

No one else had this question

Outcomes

Steven English Aug 8, 2014 10:24 AM

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

Actions

Scott Olswold Aug 11, 2014 3:12 PM

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:

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

-Scott

Actions

Yadin Flammer Aug 11, 2014 3:27 PM

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

Actions

3 Replies

Steven English Aug 8, 2014 10:24 AM
Mark Correct
Correct Answer
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
Like • Show 0 Likes0
Actions
Scott Olswold Aug 11, 2014 3:12 PM
Mark Correct
Correct Answer
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:

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

-Scott
Like • Show 0 Likes0
Actions
Yadin Flammer Aug 11, 2014 3:27 PM
Unmark Correct
Correct Answer
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.
Like • Show 0 Likes0
Actions

Print Server Update breaks service

Outcomes

Related Content

Recommended Content