Filter FAQ • History • Candidate programs • Setup • Standard output • Standard input • Idle timeout • Command line • Quoted arguments • Testing • 32 & 64-bit • System acct • Migrating • Troubleshooting
RPM Remote Print Manager® ("RPM") runs as a system service and by default, it uses the Windows system account. This gives it access to all the files on the local hard drives.
However, system accounts notably do not have access to shared printers or shared file systems. Shared resources such as printers and file systems are designed by Microsoft to require user rights, specifically logged in user rights.
You never run into this distinction as a Windows user, because it’s nearly impossible for you (as a user) to do anything with a printer or file unless you are logged into your Windows account.
However, RPM is never run from a logged-in user account[*], nor does it wait around for logged in users in order to start. The system starts RPM when it runs all the services, typically moments after boot time. In order for RPM to be available, that’s the way it works. Originally in Windows 3.1 RPM was a user program you launched from an icon, but those days are long gone.
Now and then we see user RPM configurations using printers such as "\\computername\printername". This always makes us nervous because an administrator has to specifically grant access to those printers in ways Microsoft probably would not recommend, or support.
We always advise that you configure RPM to use login credentials to print to shared printers even if you are copying a file to your printer from a script you run from a filter action. Note that the filter action setup allows for credentials:
We see customer scripts that run a program to produce some kind of output, then copy that output to a printer using a UNC as shown above. This is fine, just please use credentials in the filter setup.
[*] Actually it is possible to run RPM from a user account, and some do, but it causes far more problems than it solves and we strongly recommend against it.