Resilience, Fallback & High Availability

MyQ X provides several features that can help keep printing operational during server downtime or degraded connectivity when they are enabled and configured before an outage. Choosing and configuring the right combination requires decisions that depend on your device fleet, your deployment of MyQ Desktop Client (MDC), and your availability requirements.

This article covers resilience and high-availability planning. For information about configuring Fallback Printing, spooling, Microsoft Failover Clustering, or VM high availability, see the relevant product documentation.

Feature Overview and Vendor Constraints

The available features divide into two categories: those that reduce server dependency during normal operation, and those that maintain print capability during complete server downtime.

Fallback Printing Compatibility

Whether a device will accept jobs routed via Fallback Printing depends on the device vendor and model. Some devices reject print jobs that do not originate from their configured accounting server. In some cases this can be overridden in the device's own settings – look for an option to accept unauthorized jobs or jobs from unknown sources. Always test Fallback Printing against your specific devices before rollout. Do not assume it works because it is configured.

Client Spooling vs. Device Spooling

These serve different purposes and are not alternatives to each other. Client Spooling reduces network load and keeps jobs off the server; Device Spooling enables printing directly to a device during server downtime. They can be used together.

Choosing the Right Features for Your Environment

The vendor constraints in the table above are the primary filter. If your fleet does not include Kyocera or Ricoh devices with embedded terminals, Device Spooling is not available. Offline Login may still be available on supported terminals, such as Canon, but it does not provide Device Spooling-based job release on its own. Plan around what your fleet actually supports.

If your fleet supports Device Spooling (Kyocera/Ricoh with embedded terminals):

The most complete MyQ continuity pattern for supported fleets combines Offline Login, Device Spooling, Client Spooling, and Fallback Printing. During normal operation, Client Spooling reduces server load. During server downtime, users can still authenticate via Offline Login, release jobs spooled to the device via Device Spooling, and fall back to a designated printer via MDC if needed. Accounting data can be reported after connectivity is restored: the embedded terminal reports Device Spooling job statistics to the server, and MDC reports fallback jobs when it reconnects.

This combination requires MDC to be deployed to user workstations and embedded terminals to be active on the target devices. Configure it before rollout.

If your fleet does not support Device Spooling:

If MDC is deployed, Fallback Printing is the main MyQ-managed print continuity option for fleets that do not support Device Spooling. Users whose jobs cannot reach the server are routed to a fallback printer. Authenticated pull print and delegated print are not available during the outage. Accounting is preserved once the server is reachable again.

If MDC is not deployed:

Neither Fallback Printing nor Client Spooling is available. Continuity depends entirely on whether your devices support Offline Login and Device Spooling. If they do not, MyQ-managed print continuity is not available during a server outage, except for any printing paths outside MyQ that the organization maintains separately.

Server Failover and Clustering

For environments where print server availability is a hard requirement, MyQ supports infrastructure-level approaches that go beyond print-and-device fallback features.

Microsoft Failover Clustering

MyQ can run in a Windows Server Failover Cluster using an active/passive configuration. The cluster manages MyQ services across multiple nodes; if the active node becomes unavailable, the cluster switches to a passive node automatically. Microsoft Failover Clustering primarily protects against node-level failure. Do not assume that every MyQ application or service failure will trigger cluster failover; include application-level monitoring and recovery in the operational design.

Microsoft Failover Clustering is appropriate when high availability of the MyQ server is a business requirement and your organization already has, or is prepared to operate, Windows Server clustering infrastructure. It introduces greater infrastructure and operational complexity than a standalone MyQ server or VM-level high availability.

Before choosing this approach, verify the current MyQ system requirements, supported Windows Server versions, storage requirements, and cluster prerequisites in the MyQ X Server documentation.

Client Hostname Configuration

Client applications, such as MyQ Desktop Client and MyQ Mobile Client, should be configured to connect to the cluster hostname or IP address, not to an individual node. If clients are pointed at a node directly, they will lose connectivity when that node fails over, regardless of whether the cluster itself is functioning correctly. Confirm this before rollout.

Virtual Machine High Availability (VMHA)

When MyQ runs in a virtual machine, hypervisor high-availability features can provide infrastructure resilience by restarting or moving the VM after a host failure.

This approach is generally simpler than deploying MyQ in a Windows Failover Cluster because it does not require application-level Windows clustering. Recovery depends on the virtualization platform detecting the failure and restoring the VM, so the achievable recovery time depends on the HA platform and its configuration.

Consider VM-level HA when protection against host failure is required but the additional complexity of Microsoft Failover Clustering is not justified.

Choosing a Server HA Approach

Choose the approach according to the failures you need to tolerate, required recovery time, existing infrastructure, and operational expertise.

Server HA and print fallback address different failure scenarios and can be used together. HA restores the MyQ server service; Offline Login, Device Spooling, and Fallback Printing can preserve selected user workflows while the server is unavailable.