I always like to install software and get productive with it right away. I’m generally 3-4 steps out, planning what to do with this, and how to extract that, and where the PDF goes. It’s just my nature.
I’ve set up RPM Remote Print Manager® (“RPM”) any number of times, and so far I’ve only been stumped once. However, this question is one we hear more often than some:
How do I get my print jobs to show up in RPM?
It’s straightforward. In this article, I’ll describe the few steps you need and how to test whether it’s working or not.
Step 1: Install RPM
I admit--that’s obvious! You don’t have to be an IT professional to know the software is not going to receive print jobs if it’s not on your system.
When you install RPM on your Windows PC, the installer launches the service automatically. The user interface is optional; the installer asks, do you want to run RPM Remote Print Manager, etc. but you do not need to because the service is already running and by default, it will receive jobs for you.
When RPM first runs, it creates a listening port for LPD print jobs. We describe this in the article How Network Ports and Protocols work in RPM
The main point here is that by the time you install RPM, it should be ready to receive LPD print jobs.
Step 1(a): if someone has gotten there first
There is one reason why this would not be true: another software is using port 515.
You can review the event log (click the "Events>>" button at the bottom of the user interface), or launch message log viewer (Log / Launch Log Viewer) and scroll through the log. If RPM fails to create its LPD port, you should find it quickly this way. If another service is using port 515, stop that service and restart RPM.
Step 2: get your PC hostname or IP address
RPM has created port 515 for you. At this point, another program on your network should be able to send a print job to port 515 on your PC. The only thing we need now is your PC’s hostname or IP address.
How do you get the IP address?
The short answer is to do a web search on this phrase:
how to find my ip address on windows
I tried this search on both Google and DuckDuckGo.com; I got different first results, but both results seemed to work.
If you are using Windows 10, for instance, like I am, you should select the search phrase:
how to find my ip address on windows 10
Step 3: set up your remote system to send print jobs to RPM
Here is another example where you can and should use your search skills. I did the following searches in Google just now:
- How to print lpd from as/400
- How to print lpd from CUPS
- How to print lpd from AIX
- How to print lpd from hp3000
Each of these searches produced what appear to be meaningful results. The AIX search, for me on this particular day, delivered a text snippet with step by step instructions.
My point is that we have little to no hands-on experience for most user’s remote systems, except that we have an AS/400 in-house (and we are not experts).
Please note: RPM is a print server and we have a great deal of expertise with it. When we say “we don’t support your print client,” we mean the software you print from, not the software you print to. RPM is the software you print to.
With all that said, we have a page on our site with sample setup steps for a variety of remote systems.
Step 4: picking a queue name
As a general point of interest, when you set up the “print client,” you are going to need one or more of the following:
- the hostname or IP address of the Windows PC where you installed RPM
- you may need to know it’s port 515
- you’ll probably want a queue name.
Typically your system administrator will assign a queue name for the outgoing prints destined for RPM. When RPM receives the LPD print request (which includes a queue name), it will create that queue if it doesn’t already exist. That’s the default behavior. If you want to change that, we have an article How to prevent queue names appearing in RPM
If you're going to create a queue name, you can do that on the remote system by sending the job. If you prefer, you can create the queue name in RPM first. The article above shows how to create a queue.
Step 5: run the UI, it may show something
Let’s say you have done all that and have sent a bunch of jobs to RPM. You run the user interface, but you don’t see anything:
Here I’ve posted 801 jobs to a queue I called “archive.” But I don’t see anything.
Looking closer, I see an empty printer symbol. When I click on the name “archive,” I now see this:
Now I see plenty of jobs, and if I were to count to the bottom, there would be 801 jobs in that queue.
The reason they are sitting there (and the empty printer symbol) is that I haven’t configured the “archive” queue yet to do anything with those jobs. But, RPM received the jobs, which is the point of this article.
Step 6: If jobs don’t come through, use these tests to make sure jobs can get there
If you have access to a Linux based system, then follow these steps.
The telnet test
Just now I went to an Ubuntu server in our network and typed the following at the command line:
telnet 192.168.89.132 515
The IP address is that of my laptop. Note that I added “515” so that telnet would use my LPD port instead of its default telnet port.
Telnet displayed the following:
Trying 192.168.89.132... Connected to 192.168.89.132. Escape character is '^]'.
I hit the “enter” key and then a couple of other keys until I remembered which one I needed to exit. It turns out that Ctrl+Z did the job for me.
In the RPM user interface I clicked the “Events>>” button near the bottom, and saw the following:
Queue - 2018-10-16 13:39:14.533 enabled queue not found: -1 LPD command - 2018-10-16 13:39:12.861 unknown command -1 LPD command - 2018-10-16 13:38:35.341 unknown command 13
While this looks like a lot of complaining, it’s a good sign because it shows that print jobs can flow directly from that Ubuntu host to RPM on my Windows PC.
In general, if you can find a Unix emulation or a telnet utility, try to connect to your PC using port 515 after your IP address (or hostname). The fact that RPM registers an error is good because it means it was listening and heard your request (however ill-formed).
We have a page on doing telnet from a mainframe although we have not tried this (because we don't have a mainframe).
If you only have access to Windows systems:
The testlpr script
Using the RPM UI, add a queue named "brookstest". Now in a command window, go to the install folder and run the script "testlpr.bat" This uses the pylpr program we include with the RPM install. We won't demonstrate sending print jobs across the network, but we will show whether RPM is ready to receive prints or not.
Step 7: firewall
If your telnet utility says something along the lines of not being able to connect, then you either have the wrong IP address, or your route is blocked. You need to talk to your IT staff about the firewall.
When RPM installs, it attempts to create an exception for port 515 in the firewall on that PC. There is no guarantee this will work, and indeed, there’s no way for RPM to know about firewalls between that machine and the origin of your print jobs.
You could always call us and ask for help, but are you sure you want to talk with someone who can see the inside of your network from the outside? Right, I wouldn’t, either.
Step 8: How to tell if RPM is receiving
If you are not sure you are receiving jobs, then the easiest way to tell is by running the user interface.
Remember the user interface snapshots above? In the first one it “appeared” that there were no jobs. But, there were 801 jobs; the queue “archive” had a couple of numbers next to it. One is the current jobs, which is the number of jobs currently in the queue. The other is the total number of jobs the queue has received.
When I clicked on the queue, as the second image shows, then I could see all the jobs for that queue.
So:
- If new queues appear, then you are receiving jobs
- If the job count for one or more of your queues increases, then you are receiving jobs
- If the job count goes up, then goes back down, but the job total keeps going up over time, then you are receiving AND processing jobs
Remember that if you are running the user interface watching for something to happen, you also have to make sure that someone is sending print jobs to your machine. It would be great if RPM could go to your other systems and grab a print job, and pull it down, but that’s not the way these things work.
Step 9: do I need to turn on host access or any other permissions?
Here is the short answer. No, you don’t.
To get to the Host Access form, go to Configure / Security Settings:
Host Access is intended to control which machines on your network have permission to print to RPM. By default, every address is allowed to send to RPM. Some customers wanted to prevent RPM from being wide open to their network (it was probably a university). We made a way, and that’s the entire story.
Host access does NOT enable anything. It doesn’t get you print jobs where you couldn’t before.
Many customers have told us “we tried host access and that didn’t help”. That makes sense because host access is for restricting, not enabling.
Step 10: I still can’t print--what are the likely culprits?
First, if you have done all the above, then there’s a chance that you installed RPM more than 21 days in the past and never licensed. RPM will not receive beyond the trial period if you don't activate the license.
Second, it’s relatively common that you may have an LPD already on your system, either Windows’ optional "LPD Services" or a third party one installed with another piece of software. You can check if you have another program listening on port 515 like this:
From an elevated command prompt use the command “netstat -abn | more” then page through the results. If you see a line identifying 0.0.0.0:515 and the next line doesn’t say [rpmsrv.exe], another program already had the port and is blocking RPM from listening. Stop that other service and then restart the RPM service to try again. You should have better luck the next time.