Deployment

Printing with MyQ

Before configuring queues or deploying drivers, decide how print jobs will move through your environment. This decision affects network load, server resource requirements, spooling infrastructure, accounting accuracy, and what happens when the server is unavailable.

The two fundamental models are server spooling and direct IP printing. Most deployments use one as the primary model, with the other available for specific use cases.


Server Spooling

In server spooling, jobs travel from the user's workstation to the MyQ Print Server, where they are processed, associated with the user, and handled according to the target queue type. The server applies policies, collects accounting data, and manages the release workflow.

This model gives you full control over the print environment – policies, quotas, job routing, reporting, and secure hold print all depend on jobs passing through the server. It is the right default for most deployments.

Consider server spooling when:

  • You need centralized accounting, quota enforcement, or policy application.

  • Users require secure hold print or pull print across multiple devices.

  • You want automated printer provisioning and driver deployment.

  • Your environment has reliable network connectivity between workstations and the Print Server.

The main constraint is network dependency. Every print job travels to the server and back to the device. In environments with limited WAN bandwidth, high print volume, or branches with unreliable links, this can become a bottleneck. Client Spooling and Device Spooling address this without abandoning the server model.

Direct IP Printing

In direct IP printing, jobs are sent from the workstation straight to the device, bypassing the server. MyQ can still monitor and account for direct print jobs when an appropriate monitoring method is used, such as MyQ Desktop Client, embedded terminal reporting, or counter checking. The print data itself is sent directly from the workstation to the device, not through the MyQ server.

This model suits environments where keeping print data local is a requirement, where network links to a central server are insufficient for print traffic, or where a small number of devices does not justify server-mediated spooling.

Consider direct IP printing when:

  • Print data must not leave the local network segment.

  • Network connectivity to the Print Server is unreliable or bandwidth-constrained.

  • Users print to a small number of local devices with no requirement for pull print or hold print.

The main constraint is management overhead. Without the server in the job path, driver deployment, queue configuration, and print monitoring must be handled separately. MyQ Desktop Client in Client Spooling mode can reduce this overhead: jobs are delivered directly to the device while metadata is reported to the server, supporting accounting and selected MyQ controls without routing the full job data through the server. This is the recommended approach when direct printing is required for network or data-residency reasons.

Decision Factors

Factor

Favors Server Spooling

Favors Direct IP

Accounting and quota enforcement

Yes

Requires MDC

Secure hold print / pull print

Required

Not available

Policies and job modification

Full support

Limited

Automated driver deployment

Via MDC or GPO

Via MDC Client Spooling

Network bandwidth to server

Sufficient

Constrained

Print data residency

Flexible

Must stay local

Server availability dependency

Higher

Lower

In most environments these two models are combined: server spooling for the majority of users and queues, with Client Spooling enabled for sites or user groups where bandwidth or residency requirements apply.