Windows Protected Print (WPP) and Your Print Fleet: The Practical Path

A modeled estimate puts roughly 71% of active enterprise printers as WPP-capable today, with a legacy tail of 20 to 50% that still needs a plan. Current-generation MFPs are usually Mopria-certified, so the risk concentrates in older models, label printers, and specialty devices. The only number that matters for planning is your own, which you get by auditing your fleet against the Mopria directory.

Start by auditing every printer by driver type and checking each model against mopria.org/certified-products. Document the non-Mopria tail and the workflows it supports, audit your print servers for IPP-over-HTTPS, then pilot WPP on a small group of Mopria-only endpoints before expanding by site. Plan refreshes or a cloud-rendering bridge for the tail, and handle label and specialty workflows separately.

A Windows print server cannot transparently bridge WPP clients to legacy printers. If the server exposes an IPP-over-HTTPS endpoint for a queue, a WPP client connects without a local driver. If it only offers a traditional RPC or SMB share, that queue becomes inaccessible. Sharing V3 or V4 drivers back to a WPP endpoint just reintroduces the dependency WPP removes.

Possibly, depending on the printer. Advanced finishing such as stapling, booklet folding, and secure PIN release depends on driver-level features or a vendor Print Support App (PSA). Without a PSA for your model, the endpoint falls back to the generic IPP feature set, which may lack those options. Confirm PSA availability with each OEM before you enable WPP where finishing matters.

Most do not, at least not out of the box. Label printers typically use proprietary drivers (ZPL, EPL, TSPL) and rarely carry Mopria certification. ZebraDesigner, DYMO Connect, BarTender, and similar applications depend on third-party drivers that WPP blocks on the endpoint. The cleanest fix usually isn't making the printer WPP-compatible. It's redesigning how the application sends jobs, either by migrating to a network-direct TCP/IP path that bypasses the Windows print stack entirely, or by using a backend print API. ezeep's Print App for Services exposes that kind of API with ZPL and EPL passthrough.

V3 and V4 are Windows third-party driver architectures provided by the printer manufacturer, both blocked from loading on the endpoint when WPP is enabled. IPP with Mopria certification is the driverless path WPP requires. Mopria-certified printers expose a standardized IPP endpoint that Windows uses via the built-in IPP Class Driver, with no manufacturer driver installed on the endpoint at all. Any printer queue still backed by a V3 or V4 driver is removed from a WPP endpoint when the mode activates.

Run Get-Printer | Select Name, DriverName, PortName on each Windows print server to list every shared queue and its driver. Export the list and cross-reference each printer model against the Mopria certified-products directory at mopria.org/certified-products. A listed model is confirmed Mopria-certified and works under WPP through the IPP Class Driver. An unlisted model may still support IPP without formal certification, but that needs vendor confirmation. The output of this audit is the input to your WPP migration plan.