Standalone or Multi-Site

MyQ X can be deployed as a standalone Print Server for a single environment, or as a Central/Site architecture for larger or distributed environments. The right model depends on the number of locations, number of devices, user scale, network reliability, administration model, reporting needs, and expected growth.

Planning Limits and Terminology

In a standalone deployment, one Print Server manages users, devices, queues, jobs, reporting, and local system configuration.

A Site Server is a Print Server that is connected to a Central Server. The server component is functionally the same, but its role changes when it is managed as part of a Central/Site architecture.

In a Central/Site deployment, Central Server provides centralized licensing, consolidated reporting, user distribution, and selected shared configuration. Site Servers handle local print processing, scanning, device communication, embedded terminals, and other site-level operations. Site Servers still require some local configuration and maintenance.

MyQ X supports up to 30,000 managed devices across all connected sites. Use the current system requirements for per-server sizing, storage, and hardware recommendations.

Overview of Deployment Scenarios

Decision Factors

When choosing a deployment model, consider the following factors:

• Number of locations: Decide whether one server can reasonably serve the whole environment, or whether local servers are needed at individual sites.

• Device and user scale: Estimate the number of printing devices, users, Desktop Clients, embedded terminals, and mobile clients at each location.

• Network reliability and latency: Consider whether print jobs, authentication, scanning, and device communication can depend on network links between locations.

• Administration model: Decide whether administration should be centralized, delegated per site, or separated by tenant or organizational unit.

• Security boundaries: Consider whether sites, departments, or tenants require separate administration, access control, reporting visibility, or data handling rules.

• Reporting requirements: Consider whether reporting must be consolidated across multiple locations.

• Local print continuity: Decide whether users must be able to print or release jobs during network outages or server maintenance.

• Growth expectations: Plan whether the environment is likely to expand to more locations, more devices, or higher print volume.

• Data and reporting flow: Consider which data must be consolidated centrally, how often reporting data must be available, and whether sites can tolerate delayed synchronization during network outages.

• Upgrade and maintenance capacity: Consider how often servers, embedded terminals, Desktop Clients, and related components can be upgraded.

Scenario 1: Standalone Print Server

Use this scenario for a single-location environment where one Print Server can manage the required users, devices, queues, jobs, and reporting.

This is typically the simplest MyQ X deployment model. It is suitable when the organization has centralized operations, one main administrative domain, and no requirement for site-level separation or centralized management across multiple Print Servers.

Key characteristics:

• One Print Server manages the environment.

• Suitable for environments up to the recommended standalone Print Server capacity.

• Simpler installation, maintenance, backup, and troubleshooting.

• No Central Server is required.

This model is often a good starting point for small and medium deployments. If the environment later grows across multiple sites or requires centralized management of several Print Servers, it can be migrated to a Central/Site architecture.

Scenario 2: Multiple Print Servers at one site

Use this scenario for a large single-location environment where one Print Server is not enough, or where print services need to be separated by building, department, device fleet, or availability requirement.

Multiple Print Servers can be managed independently. If you need unified reporting, licensing, or administration across them, plan a Central/Site architecture instead (Scenario 3).

This model can help distribute load, reduce local bottlenecks, and support location-based print services. It may also be useful when different parts of the organization require separate administration or maintenance windows.

Key characteristics:

• Multiple Print Servers operate within one physical location or campus.

• Print services can be separated by area, department, or device group.

• Useful for environments with high print volume, many devices, or many Desktop Clients.

• Can support proximity printing and local segmentation.

Consider Central Server if you need centralized reporting, licensing, administration, or coordination across the Print Servers.

Scenario 3: Central/Site Architecture

Use this scenario for distributed organizations that need local print processing at each site and centralized management across the whole environment.

In this architecture, Central Server provides central management, licensing, reporting, and selected shared configuration. Site Servers handle local print processing, scanning, device communication, embedded terminals, and user interaction with printers.

This model is suitable when sites are geographically distributed, have their own printer fleets, or require local operation for performance, security, or resilience reasons.

Key characteristics:

• Central Server provides consolidated administration and reporting.

• Each site runs a local Site Server for local print and device operations.

• Sites can be managed with site-level rights and responsibilities.

• The architecture can scale across many locations and large device fleets.

• Site Servers still require local configuration, monitoring, maintenance, and backup planning.

Use this model when central control is important, but print processing should remain close to users and devices.

Scenario 4: Small branches served by one Print Server

Use this scenario when one Print Server can serve a main office and several smaller branches without placing a server at each location.

This model reduces infrastructure and maintenance effort at remote locations. It can work well for small branches with reliable connectivity, limited local IT resources, and lower print volumes.

Key characteristics:

• One Print Server manages devices and users across multiple locations.

• Remote locations do not require their own local MyQ server.

• Administration, backup, and maintenance are simpler than in a full Central/Site architecture.

• The model depends on reliable network connectivity between remote locations and the Print Server.

• Print jobs, authentication, scanning, and device communication may be affected by network latency or outages.

Use this model when your branch locations have reliable network connectivity and modest print traffic. If a branch requires local print continuity, has unreliable network links, or grows significantly, plan a transition to a local Site Server managed by a Central Server.

Multi-Site Planning Considerations

Multi-site deployments require additional planning for job mobility, local spooling, storage connections, administration, and configuration management. Planning with the following features in mind can help support your deployment in distributed environments.

Job Roaming

Use Job Roaming when users need to release jobs across multiple Site Servers.

With Job Roaming, users can view and release jobs from different sites, and jobs can be transferred between sites when required. This improves flexibility for users who move between locations, but it can also affect network traffic, storage, and job transfer behavior between servers.

Plan Job Roaming when users regularly work across multiple locations, or when the organization needs a consistent pull-printing experience across sites.

Local Spooling

Use local spooling to reduce dependency on server-to-site network traffic and help maintain print availability during network or server disruptions.

Client Spooling keeps print data on the user’s computer until release. This can reduce print data transfer through the server and may be useful when users print large jobs or when network links to the server are limited.

Device Spooling sends jobs directly to supported devices with embedded terminals. This can reduce server involvement during release, but support depends on the device vendor, model, and embedded terminal capabilities.

Plan to use local spooling when WAN traffic, server load, or outage tolerance are important deployment concerns.

Cloud Storage Connections

In multi-site environments, plan how users will connect to cloud storage services and whether those connections need to be available across sites.

If users move between locations, a consistent cloud storage experience can reduce repeated authentication and support effort. Before rollout, verify the required cloud integrations, authentication method, and site behavior for the target MyQ version.

Administrative Control

Use site-level administration when responsibilities need to be separated by location, tenant, department, or support team.

In Central/Site deployments, administration can be shared while still allowing selected responsibilities to be delegated at the site level. This supports least-privilege administration and can reduce operational dependency on a single admin team.

Plan the administration model before rollout, including who can manage users, devices, queues, reports, and site-specific settings.

Configuration Reuse

For deployments with many Site Servers, configure one Site Server as a reference server, then use the supported backup, restore, or settings-duplication features to reuse its configuration as a starting point for other Sites.

After restoring or duplicating settings, review site-specific settings such as printers, printer groups, IP addresses, network settings, authentication dependencies, local queues, certificates, and maintenance windows.

Before rollout, define which settings are part of the shared baseline, which settings are site-specific, and how updates to the baseline will be maintained.