Windows clients not printing, Error on server says "Pharos Notify not installed" - works on one lab but not another
Windows clients not printing, Error on server says "Pharos Notify not installed" - works on one lab but not another
The error from the server indicates that the server cannot contact the client to send the notify messages. This is usually because
1. The Pharos notify service is not installed or running on the clients
2. The windows firewall on client is blocking inbound requests to the notify port from the server.
3. The Pharos server is struggling to resolve the originating IP address of the client via DNS and is sending the notify requests somewhere else or not at all. (most commonly seen with very short DHCP leases)
You should be able to telnet to the notify service on the client from the server to establish if the Pharos notify service is listening and ready to receive communications. The default port for the notify service is 28201
Nic's points are spot on, though I will comment about my understanding of how point #3 works. My understanding however, is that the client provides it's IP address upon submission of a print job (rather than a network name) which keeps DNS from being the problem (which is a very good thing), but you can still have issues with routing. These are usually rare/very rare, but routing issues can come into play if V-LANs or VPNs are in use, as the server may be unable to route to the IP of the client when it there is not a provided route or it is NAT'd (e.g., server IP is something like 10.1.100.25, and the workstation is behind a separate router and has received an ip like 192.168.1.101).
Regards,
Steven
Thank you for your responses. It turns out there is an update to the popup
client that fixes the issue. We're on version 8.4.
Thanks-
Colleen
On Mon, Feb 20, 2017 at 2:55 PM, Steven English <pharos-ext@jiveon.com>
for clarification Steve, if you install notify with popups, the popup client correctly adds the ip address as popup data for the server to connect to the client. However without popups and depending upon how the jobs are submitted, it can be hit and miss. Sometimes ip, sometimes hostname. Far too many hours trawling log files reveals this...
Thanks for the clarification. I was only referring to systems that actually have the popups installed, but I realize that not everyone's environment is configured in such fashion. Thanks for pointing out that the absence of the popups introduces a variance there that would likely require DNS resolution back down to the workstation if Notify was being used although the Popup component was not.
Regards,
Steven
One more possible issue with the server contacting the client is if the client has more than one network connection defined. This can cause the Popup client to send a IP address in the job that causes the server is to not be able to find a route back to the client. That can be a hardware connection, wired or wireless, or it could be a connection created be virtual machine software like VMWare or Virtual Box for example. In most cases the wired or wireless connections can be dealt with by setting priority. With the Virtual software connections it is not as simple as setting the priority and they need to be disabled temporarily for the printing to be successful.
Thank you for your responses. It turns out there is an update to the popup
client that fixes the issue. We're on version 8.4.
Thanks-
Colleen
On Mon, Feb 20, 2017 at 2:55 PM, Steven English <pharos-ext@jiveon.com>