RPM Overview
RPM Remote Print Manager® (“RPM”) is a Windows-native print server built for environments where “just print it” isn’t good enough — where jobs need to be routed, transformed, archived, emailed, or fed into other systems entirely. Below is what RPM does, capability by capability, with links to the full detail on each.
Print Server
RPM is a print server: it receives print jobs over standard protocols and routes them into named queues, where your configuration decides what happens next — anything from simple plaintext rendering to complex, multi-step processing. There’s no meaningful limit to how many queues you can run; customers operate 900+ queues with barely more overhead than five, because each is just a database entry.
Built for Reliability
Underneath, RPM is a spooler with one job: receive incoming print jobs as fast as they arrive, store them safely, and process them separately, out of band. The network thread never waits on processing — you can watch thousands of jobs queue up in the UI while earlier jobs are still being handled. Loss prevention comes first; everything else is optimization on top of that.
More Than Printing
Because RPM intercepts the print stream itself, it can do far more than print. One long-time client uses RPM purely to inject data into a database — their system just “prints” to what it thinks is a printer, and RPM runs a command line against that data instead. If your system only knows how to print, RPM can turn that into an integration point.
Talks to Everything
RPM accepts jobs over LPR/LPD, Telnet (including “quiet print” for streaming reservation-system feeds), AppSocket/JetDirect, folder watching, and a JSON-based RPC interface — each mapped to your queues the same way. LPD alone covers a huge share of legacy mainframe and AS/400 clients, and RPM’s extensive protocol logging exists because, frankly, a lot of client implementations don’t follow the spec cleanly.
Transform and Route on Your Terms
Before a job reaches its destination, RPM can run it through transforms — filtering, translating, or extracting data from the job contents — and use what it finds to make decisions, like routing a job to a different queue based on data pulled from the file itself. Nothing happens automatically that you didn’t configure, with one narrow exception: plain text sent to a text printer gets auto-prepared for correct positioning.
Nine Ways to Act on a Job
Once a job is ready, RPM can text-print it, raw-print it, email it, archive it to disk, run it through a custom program, copy it to another queue, forward it via LPR or IP print, or upload it to FTP — and a queue can run more than one of these actions on the same job.
Handles Shared Resources the Right Way
RPM runs as a Windows service, which by design can’t touch shared printers or folders without help. Give RPM credentials for an authorized user, and it can reach those shared resources properly — this is the same territory as the “log on as a batch job” permission that trips up a lot of sysadmins outside of printing entirely.
Scheduling That Scales
RPM’s job scheduler picks the “next eligible job” using one of four paradigms — received order, availability order, balanced across queues/devices, or a manual priority system — and automatically retries failed jobs (like a printer that’s momentarily offline) on a configurable schedule.
Ready to see it in action? Download the 21-day free trial → or talk to someone on our team →, especially if you’re working with an AS/400 or an unusual environment.