Print Nodes Configuration

An OptimiDoc Printing Node (OPN) is a lightweight print service you install close to your printers — typically at a branch office or on a dedicated machine on the print VLAN. It receives LPD and IPP print jobs locally, then hands them to the central OptimiDoc server for authentication, rules processing and accounting. Unlike a clustered server node, a printing node does not run the web console and does not connect to the database directly; it talks to the central server over HTTPS. This guide explains what a printing node is, when to deploy one, and how to install and configure it.

Printing Nodes vs Server Nodes

OptimiDoc has two distinct kinds of node, and both appear together under Diagnostics > Cluster Nodes. It is important not to confuse them:

If you are looking to make the web console and database highly available, see Failover Architecture. This page covers the printing node only.

Why Deploy a Printing Node?

• Remote and branch sites. Devices at a remote site submit jobs (LPR/IPP) to a local printing node over the LAN instead of across the WAN to the central server, reducing latency and WAN traffic.

• A local print entry point. The node exposes an LPD listener (raw/LPR) and a driverless IPP/IPPS endpoint on the local network, so client workstations and print servers have a nearby target.

• Resilience for used devices. The node caches the devices it has recently handled (used-devices.json), so it can keep spooling and accounting for known devices even when the central server is momentarily unreachable.

• Offloading the central server. Job reception, spooling and the initial page-count/preview work happen on the node rather than on the central server.

How a Printing Node Works

1. Registration. When the service starts it registers itself with the central server (POST api/Node, sending its hostname, address and version). The server stores it as a PrintingNode cluster entry and returns its node id. If the server is unreachable at start-up, the node retries automatically every five minutes until registration succeeds.

2. Listeners. Once running, the node hosts three listeners:

   • an LPD server (default TCP 515) for raw/LPR submission;

   • an IPP server (default TCP 631) serving both ipp:// and ipps:// on the same port for driverless printing;

   • a small internal HTTPS web server (default TCP 14261) that the central server calls back to for print previews, page counts, job deletion, log retrieval and accounting.

3. Job hand-off. When a job arrives (LPD or IPP), the node spools it locally and then submits it to the central server (Spooler/Accept, tagged with the node id). The central server applies the job owner, rules and accounting. If the server rejects the job, the node cleans up its local spool files.

4. Heartbeat. Every five minutes the node sends a heartbeat to the central server. The heartbeat keeps the node's last action timestamp current (so it shows as active in the console) and carries the information the node needs to keep its IPP queue configuration in sync (see below).

Driverless IPP on the Node

Each printing node runs the same dual-mode IPP server as the central server, so users can install a driverless printer that points at the node instead of the central server. A few node-specific behaviours are worth knowing:

• Deferred start. The node's IPP server does not start until the node has registered. This is because every IPP printer needs a stable UUID, and the node derives its printer UUID from the licence-based prefix with the node id folded into it, so the node must know its id first. Until then you will see a log line noting that IPP will start after registration completes.

• TLS certificate. IPPS (encrypted IPP) requires a certificate named optimidoc.p12 placed in the node's installation directory. If it is missing, the node logs a warning and serves plain ipp:// only.

• Queue configuration is pulled, not pushed. Named IPP queues and their print defaults are managed centrally (see Driverless Print (IPP) and IPP Queue). On each heartbeat the node checks whether the central configuration is newer than what it last applied; if so, it fetches each queue's attribute set from the freshest server and applies it to its own IPP server, persisting the sets as default.ipp and queue-{id}.ipp files next to the executable. The node performs an immediate pull at start-up as well, and only records success once every queue has applied — a partial failure is retried on the next heartbeat. Queues that no longer exist centrally have their local files cleaned up.

Client-side installation of a driverless printer (whether it points at the central server or a node) is covered in IPP Pull Printer Setup.

Prerequisites

• A working central OptimiDoc server, reachable from the node over HTTPS.

• A Windows machine on (or with a route to) the print network to host the node.

• Firewall openings on the node for the ports it listens on: 515 (LPD), 631 (IPP/IPPS) and 14261 (node callback web server, or your configured web.port).

• The optimidoc.p12 certificate in the node's install directory if you want IPPS.

Step 1 — Install the Printing Node

1. Obtain the printing-node package (the opn build artefact). .

2. Copy the folder to the target machine, for example C:\OptimiDoc\PrintingNode.

3. Install it as a Windows service (run the service executable with the standard InstallUtil/service-install method used in your environment) and set it to start automatically.

Step 2 — Configure the Node

All node configuration lives in the service's App.config (appSettings). The most important key is optimidoc.url, which points the node at the central server:

Set optimidoc.url (and, if you are not auto-detecting, ip), then save the file.

Step 3 — Provide the IPPS Certificate (Optional)

If you want encrypted ipps:// printing from the node, place a certificate file named optimidoc.p12 in the node's install directory before starting the service. Without it, the node still serves plain ipp://.

Step 4 — Start and Register

1. Start the OptimiDoc Printing Node Windows service.

2. On start-up the node registers with the central server and (once registered) starts its IPP server and performs its first IPP configuration pull.

3. On the central server, open Diagnostics > Cluster Nodes. The new node appears with type PrintingNode, its hostname, address, version, and a recent last action timestamp.

If the node does not appear, check that optimidoc.url is correct and reachable over HTTPS from the node, and review the node's log — registration is retried every five minutes.

Step 5 — Point Devices and Clients at the Node

• LPR/raw printing: configure the printer or client to send to the node's address on port 515.

• Driverless IPP: install a driverless printer pointing at the node's address on port 631 — see IPP Pull Printer Setup.

Verifying the Node

In Summary

A printing node is a small, database-free service that brings OptimiDoc's LPD and driverless-IPP entry points close to your printers and hands received jobs to the central server for processing. It self-registers, keeps its IPP queue configuration in sync by pulling from the cluster on a five-minute heartbeat, and appears alongside your server nodes in Diagnostics > Cluster Nodes as type PrintingNode. Deploy one per remote site (or wherever you want a local print entry point), point it at the central server with optimidoc.url, and open ports 515, 631 and 14261.

Related articles

• IPP Pull Printer Setup

• Driverless Print (IPP)

• IPP Queue

• Failover Architecture

• Cluster and Failover Issues

• Advanced Configuration