Share via

Why is Universal Print showing successful Print jobs but nothing comes out of the Printer?

Queston Juarez 20 Reputation points
2025-09-23T22:57:56.1733333+00:00

We currently have Universal Print configured with an on-prem connector setup on a print server (windows server 2022). Multiple printers are enrolled and we have properly created mappings and groups to allow users to connect and print to the various printers. About half of the users that have tried it are successful. They are able to map printers that they have access to and print whatever jobs they want. The other half of our users are able to map the printers and print to them but the job is never actually printed at the printer itself. I've monitored all of the queues as one of the users attempts to print and it behaves like so:

  1. Universal Print receives the Print job and sends it to the connector, job shows as pending
  2. The connector picks up the job, successfully authenticates for impersonation (Hybrid Environment), and sends the job to the print spooler
  3. Print Spooler returns and event log saying "Print Document owned by
Windows for business | Windows Server | Devices and deployment | Other
0 comments

Answer accepted by question author

Joseph Tran 4,080 Reputation points Independent Advisor
2025-09-24T09:07:40.7833333+00:00

From what you’ve described, Universal Print itself is healthy (users can see printers, jobs make it to the connector, connector impersonates successfully). The breakdown is happening at the print server spooler > physical printer handoff. The clue is the Event Log entry “Print Document owned by …” which usually means the job was submitted to the Windows spooler, but never leaves the queue (or gets discarded).

So I have some steps you should have a check and let me know the result :

  1. Verify whether jobs are reaching the local print queue
  • Open Print Management on the 2022 server.
  • Watch the queue of the affected printer as the failing user prints.
  • Does the job appear and then disappear immediately, or does it remain stuck?
    • Disappears immediately → The spooler thinks it printed but the printer never saw it (common with driver/permissions mismatches).
    • Remains stuck → Connectivity/driver issues between server and printer.
  1. Check connector impersonation account rights
  • Universal Print Connector impersonates the user and submits jobs with their token.
  • On the print server, that means the user (not SYSTEM) needs Print and ideally Manage Documents rights on the queue.
  • For users that fail:
    • Compare their AD group memberships to the working users.
    • Right-click the printer → Printer Properties → Security tab.
    • Ensure those users/groups have proper print permissions.
  1. Driver isolation and compatibility
  • Half the users working, half failing often points to a driver issue (mode of rendering).
  • Universal Print Connector supports Type 3 (user-mode) drivers only. If the queue is using a v4 or vendor driver, jobs may render differently depending on the application or user profile.
  • Try:
    • Switching the printer to the Microsoft IPP Class Driver or a Type 3 universal driver.
    • Enabling Render print jobs on client computers in printer properties → Advanced.
  1. Spooler / Event Logs

Check Event Viewer > Applications and Services Logs > Microsoft > Windows > PrintService > Operational for:

  • Event ID 808 / 842 (job received/printed).
  • Event ID 372 / 808 / 6161 (job failed, access denied, rendering errors). See if the failing users have consistent error codes.
  1. Network path to physical printer

Make sure the print server itself can always reach the device:

  • ping the printer.
  • Try printing a test page from the server (not Universal Print). If that fails, it’s between server and printer.
  1. Test with service account / SYSTEM

As a control, temporarily configure the connector to submit jobs as the connector host account (instead of impersonation). If printing works, the issue is purely user rights/token.

Was this answer helpful?

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Queston Juarez 20 Reputation points
    2025-09-24T22:48:19.55+00:00

    For now the following solution is working for us:

    1. Test with service account / SYSTEM
    • Went ahead and disabled the Hybrid AD configuration on the connector and confirmed that a user that COULDN'T print before CAN print now.

    Fortunately, the Universal Print reporting is still accurate with the users UPN but anything on-prem utilizes the SYSTEM account. I'm still checking to see if this will cause any issues with legacy software that needs that information but, for now, leaving the Hybrid config turned off allows everyone to print without issue.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.