Spooling Strategy

By default, MyQ X routes print jobs through the Print Server. Jobs travel from the workstation to the server and are then handled according to the target queue type, for example held for release or sent to a device. This works well when network connectivity is reliable and bandwidth is sufficient. When connectivity is limited, or when resilience during server downtime is required, MyQ X provides local spooling and offline-continuity features that keep jobs and authentication closer to where they are needed.

These mechanisms are also relevant in cloud deployments, where routing large print files to and from a cloud-hosted server can increase WAN traffic, latency, and storage requirements. Plan your spooling strategy alongside your network architecture and resilience requirements – the two are closely linked.

Client Spooling

With Client Spooling, the MyQ Desktop Client intercepts jobs on the user's workstation before they reach the server. Only job metadata is sent to the server; the job file itself stays on the workstation. When the user authenticates at a device and releases the job, the Desktop Client sends the file directly from the workstation to the device.

From the user's perspective, the release experience can be similar to standard pull print in normal operation. The main difference is where the job data is stored and how it reaches the device. Accounting and selected MyQ controls can still be applied, depending on the configured workflow.

Use Client Spooling when:

• WAN bandwidth between the workstation and the Print Server is limited.

• Print data must not leave the local network segment or be routed through a central server.

• You are deploying in a cloud environment and want to avoid sending large print files over the WAN.

• You want to reduce server storage and processing load for print jobs.

To use Client Spooling, a user’s computer must have MyQ Desktop Client installed. If the user's computer is switched off or unreachable when a job is released, the job is paused on the server until the computer is available again – communicate this behavior to users and helpdesk staff before go-live.

Client Spooling is commonly paired with Fallback Printing. When the Print Server is unreachable and Fallback Printing is configured, the Desktop Client can redirect jobs to a configured fallback device.

Device Spooling

With Device Spooling, jobs are sent directly from the workstation to the device, where they are stored on the device's local storage and held for release. The print file is not transferred through the Print Server. Metadata, release coordination, and accounting synchronization still depend on the configured MyQ workflow and server connectivity.

Users release jobs by authenticating at the device in the normal way. If Device Spooling pull print is configured, jobs spooled on one device can be released from other supported devices on the same subnet. For this to work reliably, participating devices must have synchronized time.

Use Device Spooling when:

• Branch offices have limited or unreliable connectivity to the Print Server.

• You want print operations to continue independently of the server connection.

• Network traffic between branches and the central server must be minimized.

• You are combining with Offline Login for a fully server-independent print experience at a site.

Device Spooling has meaningful constraints that affect planning:

• Supported on Kyocera and Ricoh embedded terminals only. Verify support for your specific device models before including Device Spooling in your design.

• Project accounting is not supported – jobs are recorded without a project assignment.

• Job Roaming, favorite jobs, job archiving, and job preview are not supported.

• Pull print across devices is limited to the same subnet. Devices on different subnets cannot share spooled jobs.

• Device storage requirements are higher than in server-spooled deployments. Factor device storage capacity into your planning, particularly for sites with high print volume or large jobs.

Offline Login

Offline Login caches user credentials on the embedded terminal. When the terminal cannot reach the Print Server, users can still authenticate using their cached PIN or ID card and access device functions that do not require live server access.

Offline Login is not a spooling mechanism on its own – it handles authentication continuity, not job delivery. Its value is strongest in combination with Device Spooling: together, they can provide offline authentication and job release for supported Device Spooling workflows. Users can send jobs to a Device Spooling-enabled device, authenticate with cached credentials, and release those jobs while the server is unavailable.

Use Offline Login when:

• Sites must remain operational during server downtime or network outages.

• You are deploying Device Spooling and need authenticated job release to work offline.

• Users at a site must be able to use device-native functions (copy, scan) even when the server is unreachable.

Offline Login is currently supported on Kyocera, Ricoh, and Canon embedded terminals. PIN and ID card are the only supported login methods in offline mode – other authentication methods require a live server connection. Up to 100 users can be cached per device, and up to 3 ID cards and 3 PINs per user.

Plan the cache refresh interval as part of your configuration. Credentials are cached on a schedule; newly provisioned users or recently changed PINs will not be available for offline login until the next cache update runs.

Combining Spooling Mechanisms

These features can be combined. For a branch office or site with unreliable connectivity, a strong continuity pattern is:

Client Spooling + Device Spooling + Offline Login

In this configuration, job data never travels to the central server. Jobs are intercepted by the Desktop Client, sent directly to the device, and held there. Users authenticate using cached credentials. Accounting data is stored locally and reported to the server when connectivity is restored, provided the relevant terminal and Desktop Client reporting paths reconnect successfully

This combination requires MyQ Desktop Client on workstations, a supported embedded terminal (Kyocera or Ricoh for the full combination), and coordination between the Client Spooling port configuration and the Device Spooling port on the device.

The Fallback Printing feature extends this further by allowing the Desktop Client to redirect jobs to an alternative device when the primary server path is unavailable.

Spooling and Cloud Deployments

In cloud deployments, Client Spooling is often the preferred option for reducing WAN traffic. Jobs stay on the user's workstation and are sent directly to the local device at release, while only metadata is sent to the cloud-hosted server. This can reduce latency, bandwidth use, and server-side storage compared with routing full print files through the cloud server.

Device Spooling can complement Client Spooling at sites where workstation availability cannot be guaranteed at release time, but the vendor and terminal support constraints apply equally in cloud environments.