How to retrieve a print job's PrintTicket when using Client-Side Rendering with the Microsoft IPP Class Driver?

Hello Linh PHAM,

When clients perform client-side rendering the print server typically receives a fully rendered PDL stream and does not automatically receive a separate PrintTicket, so PrintTicket availability depends on how the client includes job metadata during submission Microsoft Learn. If the client includes an XPS/PrintTicket package in the job payload the server can extract the PrintTicket from the incoming job stream, otherwise the server will only see the final PDL and standard GDI/DEVMODE fields which may not reflect all user-selected options Microsoft Learn.

For solutions that require server-side awareness of user choices, implement a client-side step that submits or embeds the PrintTicket alongside the job, or configure the client/driver to submit the PrintTicket as part of the job metadata when possible Microsoft Learn. If you control the client environment, prefer driver models or deployment options that support PrintTicket round‑trips (XPS-based workflows) so server components can parse the PrintTicket and enforce policies or logging Microsoft Learn. On the server you can inspect incoming jobs for embedded XPS packages and parse the PrintTicket XML to read duplex, paper size, color mode, and other settings; the Microsoft Print Ticket documentation shows how Render Modules and drivers should handle PrintTicket processing Microsoft Learn. DEVMODE alone is not reliable for all modern features because many PrintTicket-backed options do not map one-to-one into legacy DEVMODE fields, which explains the discrepancies you observed. If embedding PrintTicket at job submission is not possible in your environment, consider a lightweight client agent that captures the user’s print preferences and transmits them to the server as separate metadata prior to or with the job.

If this answer helps, please hit Accept Answer so others can find the solution easily :)

Best regards,

VP

Hi Linh PHAM,

Has your issue been solved? If it has, please accept the answer so that others can benefit too. If not, is there anything I can help you with? Please let me know.

Vivian

In this mode, jobs are client-rendered and submitted over IPP/PDL. The server won’t receive a legacy PrintTicket in a way you can reliably parse from an SMB-shared queue, and DEVMODE won’t reflect modern options. To make the server aware of duplex, media, color, etc., you have two viable patterns.

Pattern A: Use IPP endpoints so the server receives IPP job attributes

What happens: When clients submit to an IPP printer/queue, the job includes structured IPP attributes (sides, media, print-color-mode, print-quality, finishings, copies).

Server visibility: Your IPP server (Windows print server with IPP exposed, or another IPP endpoint) can read these attributes directly before/alongside the PDL payload—no PrintTicket needed.

Requirement: Clients must print to an IPP endpoint (not just SMB shared queues). WPP and the IPP Class Driver are designed for this.

Pattern B: Use a Print Workflow app on clients to capture and send metadata

• What happens: A small Windows Print Workflow app intercepts the job on the client, reads the final user selections, and posts them (JSON) to your server before letting the job proceed.
• Server visibility: Your server gets a reliable metadata record of the user’s choices, correlated to the print job ID/user, even if the queue is SMB and only receives rendered PDL. Pattern A: Use IPP endpoints so the server receives IPP job attributes
  • What happens: When clients submit to an IPP printer/queue, the job includes structured IPP attributes (sides, media, print-color-mode, print-quality, finishings, copies).
  • Server visibility: Your IPP server (Windows print server with IPP exposed, or another IPP endpoint) can read these attributes directly before/alongside the PDL payload—no PrintTicket needed.
  • Requirement: Clients must print to an IPP endpoint (not just SMB shared queues). WPP and the IPP Class Driver are designed for this.
  Pattern B: Use a Print Workflow app on clients to capture and send metadata
  • What happens: A small Windows Print Workflow app intercepts the job on the client, reads the final user selections, and posts them (JSON) to your server before letting the job proceed.
  • Server visibility: Your server gets a reliable metadata record of the user’s choices, correlated to the print job ID/user, even if the queue is SMB and only receives rendered PDL.

So again regarding your questions:

1. Can you configure the IPP Class Driver to automatically include a PrintTicket with SMB jobs? No. Under WPP/IPP client-side rendering, you should not rely on PrintTicket arriving at the server.

2, Is there a supported way to get the user’s final options? Yes. Either consume IPP attributes at an IPP endpoint (Pattern A) or capture them via a Print Workflow app on the client (Pattern B).

3,Why don’t DEVMODE values match? Modern options are IPP/PrintTicket-backed and don’t map 1:1 to legacy DEVMODE fields, so discrepancies are expected.

Hope it helps you to some extent :) If it does, please accept the answer so that the community could benefit from it too. Thank you :)

VP