What programs are candidates to be RPM filters

Not every program would be a good candidate to run as an RPM Remote Print Manager® ("RPM") filter. There are several things to consider, which we will discuss here.

First, it has to have a command line. At a minimum, there needs to be a way you can tell it to work on your particular print job. When RPM processes your job, it believes it is launching a program that will do something intentional with your print job. This is typically going to be a command-line argument. We support using standard input for print jobs, which we cover later.

If your program has no command line but reads a configuration file, then you will need to do some kind of scripting to automate that. The one thing RPM can do to support you is to limit instances of your program to one at a time, so at least you don’t overwrite your configuration file at the wrong time.

Second, RPM runs in the background so typically the programs it runs on your behalf are also run in the background, invisible. If your program is interactive, that is if it creates a window or if it depends on other windows, there is still a way to run it. RPM supports interactive users for an action. An interactive user will need to be logged in, or your program won’t run until that user is logged in.

Note that RPM tracks user login and logout for that reason, using Terminal Services in Windows. If your system does not support Terminal Services then this action will probably not work for you.

Third, RPM runs as a Windows service which means it uses the system account. The main limitation is that a system account doesn’t have access to shared folders or shared printers.

RPM provides a way past that with user credentials. You can assign a domain username and password to an action. RPM will emulate a login before it runs the action.

The caveat here is that when you update your password in the system you also have to update RPM. That’s probably the biggest problem we run into with credentials.

Fourth and finally, your program needs to be automated so that it doesn’t prompt for input. It should get all its configuration without asking the user in a text prompt or window. If need be, you should consider building some kind of shell or wrapper for your program that takes care of that. You would then run the shell or wrapper from RPM.

If you can make your program work, however it works, with a command line in a DOS command shell, then chances are it should work with RPM. We expect that PowerShell scripts also work, but we don’t have much experience with PowerShell.