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:
- 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