Has anyone had this message in the alerts of Uniprint on the server? If so do you know what causes it?
Andrew, Paul, and others:
When you are troubleshooting getting jobs to the printer via LPR (client) and LPD (device), you can use Troubleshooting LPR/LPD for Pharos Blueprint and Uniprint to assist. If you are attempting to send jobs via Pharos Popup to the Pharos Print Server, that action relies on the Pharos LPD Service, installed on the print server. There are several things to check at the server:
Messages like "connection reset by peer" and "the target machine actively refused it" indicate port blocking or some ACL in place that restricts connected hosts. Messages like "unable to locate the host address" indicate DNS problems.
Another cool place to find problems is in the Microsoft LPD Service that can be installed as a Print Server role service. If that service is started, it will be the one listening on 515, not the Pharos LPD Service. You can use netstat to see if anything is even listening on port 515:
netstat -ano | findstr 515
and you'll get something like this:
The number at the end is the Process ID (PID) of the listening process. You can use the same "| findstr" trick to isolate your response to the tasklist command:
tasklist | findstr 1132
and know exactly what's listening:
In this case, it is my server's "LPD Service" because that's what's running. It even tells me that it's sucking 3.7MB of RAM.
I hope that this helps.
I've seen that message, exact same description, and it is listed as Error Code 29100. Never found an answer.
Along with that, Error Code 29100 will also come up for:
Perhaps someone will have an idea that may help (I hope).
- Paul L.
So I should see stuff life this, correct?
Which tells me it is my Pharos LPD Service that is listening, and from the list of "Established" I would understand users are successfully connecting.
So... Since I'm still getting the LPD related problems (as reported in the OP and my earlier reply)... what should I do next?
You actually don't have anything with an "established" connection to :515 in your screen cap, but you are correct in that the Pharos LPD Service is the one listening on that port. But I can be listening and still can't hear you because a wall is in the way, so try this (my assumption, since you're using the LPD Service troubleshooting tip, is that your clients are having problems):
and see if that succeeds (NOTE: you may need to install the Telnet client, since a troubleshooting tool for determining open ports has been branded a security defect). If it does (the screen will just go blank; you can CTRL+C to get out), then core connectivity isn't your issue (most likely; at least not to TCP port 515). If it doesn't connect (some error message instead), then some aspect of a firewall or port white-listing defect is in the way. To validate, you can always try the "telnet" command locally on the server, too, since you know it is listening.
So... When I do the "telnet 10.9.160.20 515", if communication on port 515 is working, I should not get just this:
This was done with a command prompt on the server.
Argh! I created an ambiguity in my text. I've fixed it. If you are successful you should get a blank screen.
OK. Now I'm much more relieved. (Whew!)
Now I just need to isolate a system where the problem happens and see what I can find.
OK, I haven't isolated a system, but I believe I have it narrowed down to only users of the printer packages, and it's an intermittent problem. Here is a screen shot of the Administrator Alerts filtered to show the LPD errors.
This shows twice today, once on Saturday, 7 times on Friday (5 of them the same person), and so on. Everyone of these usernames are NOT known to our Pharos Uniprint therefore these users would most likely be package/popup users (only means to send a job under one username and still release it through Secure Release using a username know to the Pharos Uniprint). ... Unless I'm mistaken. I think it's interesting they were able to connect and send their job enough to have the server reject the job as if the LPD not installed or running and to also collect user, client, filename information.
As my previous posts show, the Pharos LPD is running and operation without the Windows LPD service interfering, and I've eliminated any possible firewall/port blocks.
Poor Jeff. That's some awesome data. Since these are not user names recognized by Uniprint, my assumption is that the computers these people are using are not school computers, but personal ones. If that assumption is true, then you may still have a problem, but not one you can readily fix. These computers are probably using something that isn't Windows Firewall (even though it may be running) in order to manage their security. If that's the case, we wouldn't be able to allow the connection to TCP 515 as part of the installation; it would have to be managed externally by the user (who is, hopefully, administrative). This could also be driven by routers from the public side of your network only allowing necessary ports through, but neglected to include TCP 515 in the mix.
It would be good to illustrate the behavior alongside others in the same time frame who are accessing the print server using a package, but on school computers that are "clear" for TCP 515 destination traffic.
What I really, really need.... is time. Got any?
Retrieving data ...