Skip to content

Print jobs sent to a logical printer that isn't mapped to a real physical printer (e.g. a 'PDFEMAILER'-style logical printer used purely so a custom event can pick up and email the PDF) get stuck in 'Remote Working' status in Cloud, instead of completing the way they did on-prem in Apps9. What's missing?

Answer

The logical printer still needs a PHYSICAL mapping entry in the Print Agent's configuration file pointing at some real print queue on the server, even if that queue doesn't actually print anything — a local, do-nothing print queue defined on the Print Agent host works fine as that target. Without a PHYSICAL mapping to something the Print Agent can recognize as an actual printer, jobs sent to that logical printer stall instead of completing, even though the report/archive side of the job works correctly.

← Browse Reporting and analytics questions