Print Jobs Not Releasing

Jobs that stay held on the server and never print at the device are one of the most commonly reported issues in pull-printing environments. This article explains the job states and the release pipeline first — because knowing whether a job is Waiting, Processing, Shared or Deleted usually identifies the cause immediately — then works through the specific reasons a job fails to release and how to fix each. Menu paths refer to the React web console.

How Held Jobs and Release Work

When a user prints to an OptimiDoc pull-print queue, the job is spooled and held on the server in one of these states:

When a user releases a job, OptimiDoc runs a short pipeline, and a failure at any stage leaves the job Waiting (so it can be retried) rather than lost:

1. Resolve the target queue/device — the queue resolver maps the request to a device or a named/shared queue the user is permitted to use.

2. Evaluate rules — rules in the Before Print and Release Job contexts run; a rule may reject the job or redirect it to another device.

3. Check quotas (if enabled) — a hard limit rejects the job; a soft limit may instead force monochrome or duplex.

4. Stream the spool data to the device.

"The job disappeared." Retention deletes held jobs on a schedule: unprinted jobs (Waiting and Shared) are removed after Hold unprinted jobs (default 7 days), and printed jobs after Hold after print (default 1 day). Both are configured in Settings > Print Settings (units are days or hours). A job that vanished overnight was very likely removed by retention, not lost to an error.

Symptoms

• A user authenticates at the device but sees no jobs, or jobs appear but do not print when released.

• Jobs remain in the Waiting or Processing state indefinitely in the job list.

• The device panel shows a release confirmation but no output is produced.

• Some jobs print and others do not (points to per-job causes — quota, rules, format).

Common Causes and Solutions

1. Device Offline or Unreachable

Cause: The device has lost network connectivity or is powered off, so OptimiDoc cannot deliver the spool data.

Diagnostic steps:

1. Check the device status in the Devices list.

2. Ping the device from the server and open its embedded web server in a browser.

3. Confirm the delivery port is open (IPP 631, raw/JetDirect 9100, or LPR 515 depending on the connector).

Solution:

• Restore connectivity or power, and confirm the device IP in OptimiDoc matches the actual device IP.

• Open the required ports in any firewall between the server and the device. For a deeper diagnosis, see Device Communication Failures.

2. Job Stuck in Processing State

Cause: A job enters Processing but never completes — usually because the server or node was interrupted (restart, crash, network drop) while sending the job.

How OptimiDoc recovers these automatically:

• A recovery task (FixProcessingJobs) runs at web-application startup and whenever a printing node registers — it is not a periodic timer. For the jobs owned by that node, it reverts each job stuck in Processing back to Waiting if the spool file still exists, or marks it Deleted if the spool file is gone. You will see a log warning such as "Found N job(s) in processing state.. restore them to waiting state."

• In practice this means a job stuck in Processing clears itself the next time the web application restarts or the relevant node re-registers.

Solution:

• If a job is stuck in Processing and you cannot wait for the node to re-register, recycle the OptimiDoc web application (or restart the node) to trigger the recovery task.

• If the same device repeatedly leaves jobs in Processing, investigate connectivity or device errors mid-transfer (cause 1).

3. Quota Denial

Cause: Quotas are enabled and the user has reached a limit. Quota checking happens after rules, so a rule that changed the job (e.g. forced colour) can affect the estimate.

How it behaves:

• Hard limit exceeded: the copy is marked Deleted with a reason such as "Quota '{name}' exceeded. Remaining: {n}" (or "All quotas exceeded" / "Combined quota exceeded"), and the job is returned to Waiting so it can be released again once quota is available. The server logs "Printing rejected by quota system: …". The reason text is generated dynamically and is in English only.

• Soft limit: instead of rejecting, OptimiDoc can force monochrome or force duplex, or simply notify — the job still prints.

Diagnostic and solution:

1. Check the job/copy in the job list — the copy's reason field states which quota was exceeded.

2. Review the user's usage under Printing > Quotas and Printing > Quota History.

3. Wait for the quota period to reset, raise the limit, or grant an exception. See Quotas.

4. Rules Engine Rejecting or Redirecting the Job

Cause: An active rule in the Before Print or Release Job context rejects the job (a Reject operation action), or redirects it to a different device.

Diagnostic steps:

1. Review active rules in the Before Print and Release Job contexts under Rules.

2. Look for the log line "Printing has been rejected by RBE." (RBE = the rules engine), or a redirect line "Redirecting job … from device … to device …" if the output appeared on an unexpected device.

3. Temporarily disable the suspect rule and retry.

Solution:

• Adjust the rule condition to permit the job, or explain the policy to the user.

• If a redirect rule is sending jobs to the wrong device, correct the rule's target. See Conditions and Actions Reference.

5. IPP Job Owner Could Not Be Resolved

Cause: For driverless/IPP printing, the job owner is the IPP requesting-user-name matched to an OptimiDoc login. If no login matches, the job is rejected — there is no password prompt on IPP.

How it behaves:

• OptimiDoc strips a DOMAIN\ prefix and retries the match; an optional login regex can further normalise the name.

• If it still cannot match a user, it records a failed attempt in Diagnostics > Unauthorised Accesses (a Source = Spooler entry whose value is the rejected login) and rejects the job.

Solution:

• Open Diagnostics > Unauthorised Accesses, find the Spooler entry, and either Assign to an existing user (this creates a Login credential for that user) or Create a new user (the login is pre-filled).

• Ensure users print with a user name that maps to their OptimiDoc login, or configure the login regex. See Driverless Print (IPP).

6. Shared Queue Behaviour Misunderstood

Cause: Jobs sent to a shared queue are held as Shared and behave differently from personal jobs — this is by design, not a fault.

What to expect:

• A Shared job is releasable by anyone with access to that queue.

• Accounting is attributed to the user who releases the job, not the submitter.

• Shared jobs are subject to the same unprinted-retention window as Waiting jobs.

If users report "my colleague's job printed under my account," that is the shared-queue accounting model working as designed. Use a personal pull-print queue instead if per-submitter accounting is required. See Shared Queue.

General Diagnostic Steps

If none of the above applies:

1. Check the logs: Diagnostics > System Logs (Web and Service tabs), filtered to the time the job was released; filter by thread ID to follow one request end to end.

2. Check the Windows Event Log for OptimiDoc service or IIS application errors.

3. Verify disk space for spooling on the server.

4. Recycle the OptimiDoc application pool to clear transient state (this also triggers the stuck-Processing recovery task).

5. Test with a simple document to determine whether the issue is job-specific or systemic.

In Summary

The job's state is the fastest diagnostic: Processing that never clears is a stuck transfer that the recovery task fixes on restart/registration; a job back in Waiting after a release attempt points at a quota denial or a rule rejection (check the copy reason and the log); a job that disappeared is almost always retention; and a driverless job that never appears is usually an unresolved IPP owner sitting in Unauthorised Accesses.

Related articles

• Device Communication Failures

• Driverless Print (IPP)

• Quotas

• Cluster and Failover Issues

• Database and Performance Issues

• Troubleshooting Guide