"Print Status" jobs killing Xerox printing on macOS 10.13 machines

[SAndersen]

Just FYI the following Terminal command seems to solve our issue with bi-directional communication by effectively disabling it for all applications on macOS:

sudo defaults write /Library/Preferences/.GlobalPreferences.plist BiDi Off

Please consider running it up your communcation chain as it would have saved us a lot of time, had it been the official response regarding "Print status" issues with the Xerox print driver.

Regards,

Simon Andersen

Aarhus University

[Joe Arseneau]

There is no documentation for things Xerox doesn't do.

Official standpoint from Xerox Engineering was posted in the first link you provide (by me) right here.

If you want a personalized response of the same information you would need to go through Xerox 2nd level support and get a Spar done (Escalate to Engineering to get an official decline to fix and why).

The multiple jobs thing is not new in 10.13 nor is it from the 4.X driver

The 10.13 and 4.x driver thing is the issue where the driver does not support 32 bit apps (Shows Printer Features instead of Xerox Features) and that just comes down to waiting for Apple to kill 32bit support in June 2018.

 Xerox admits fully they dropped 32 bit support in the 4.X driver set, Apple admits they are dropping 32 bit in June, Xerox just moved a little too fast here because of the launch of the new machines (AltaLink and VersaLink devices) coming sooner than the deadline.

The multijobs thing was a workaround by Xerox to get around the Bi-Directional limitation they (Apple) imposed on the drivers. Each manufacturer had to work around it, or eliminate Bi-DI, Xerox did so with the little files (Only causes an issue in SMB ports) , EFI built a software daemon that runs permanently in the background on the Mac, so their driver talks to the daemon and the daemon talks to the printer.

[SAndersen]

At the university where I do IT we have several Xerox MFP machines both WorkCentre and AltaLink models. Since the introduction of macOS 10.13 and subsequently Xerox printer driver version 4.x life has not been as pleasant as it used to.

The printers are isolated on a network separate from the client machines (because: Security. Not my call) and a "Windows Server 2016" is acting as print server for macOS clients who connect and authenticate with either kerberos or NTLM via the smb protocol.

Whenever a macOS machine attempts to print to a Xerox printer queue using the 4.x driver it generates a "Print Status" job internally and pushes it on the queue where it festers for some time before being removed and allowing the actual requested print job to be delivered... if you're lucky. Sometimes the "Print Status" job gets held indefinitely with the message "Unable to handle AUTH_INFO_REQUIRED" blocking the queue until it's manually removed or in graver situations it triggers an account lockout from our Active Directory due to it being submitted with invalid credentials.

I've tried various workarounds including the attempts to disable bidirectional communication mentioned here http://forum.support.xerox.com/t5/Printing/Xerox-7830-How-to-disable-Bi-Directional-Communication-on... But alas to no avail.

So here's a concrete example:
A printer called PRINTER_NO1 is using the Xerox WorkCentre 7835 version 4.14.0
A job is submitted by printing a random web page from Safari.
Eventually the printer queue on the Mac gets "Paused".
Checking the printer queue one finds that "Print Status" is "Unable to handle AUTH_INFO_REQUIRED".
Attempts to "Resume" the printer queue result in the "Print Status" jobs getting retried and once more blocking the printer.
Cancelling the individual "Print Status" jobs and resuming the queue eventually allows our actual printjob to get through.

Searching for a better solution we turn to the commandline:
Once again we try to print and find ourselves with a "Print Status" job blocking the queue.

"lpstat" reveals something interesting:

lpstat -l
PRINTER_NO1-10   macuser1          1024   Tor  8 Mar 13:14:04 2018
    Status: Unable to handle AUTH_INFO_REQUIRED
    Alerts: cups-held-for-authentication
    queued for PRINTER_NO1
PRINTER_NO1-11   macuser1          1024   Tor  8 Mar 13:14:08 2018
    Status: Unable to handle AUTH_INFO_REQUIRED
    Alerts: cups-held-for-authentication
    queued for PRINTER_NO1
PRINTER_NO1-12   macuser1          1024   Tor  8 Mar 13:14:27 2018
    Status: Unable to handle AUTH_INFO_REQUIRED
    Alerts: cups-held-for-authentication
    queued for PRINTER_NO1
PRINTER_NO1-13   macuser1          1024   Tor  8 Mar 13:14:29 2018
    Status: Unable to handle AUTH_INFO_REQUIRED
    Alerts: cups-held-for-authentication
    queued for PRINTER_NO1
PRINTER_NO1-14   macuser1         22528   Tor  8 Mar 13:18:07 2018
    Status: Waiting for job to complete...
    Alerts: job-printing
    queued for PRINTER_NO1

...not only are there no less than 4 jobs blocking the queue (the Printer window in the macOS GUI only showed 1) but they're also all reported as having the same (tiny) size: 1024

Using the command "cancel" we can get rid of the "Print Status" jobs:

cancel PRINTER_NO1-10 PRINTER_NO1-11 PRINTER_NO1-12 PRINTER_NO1-13

...and then we enable the printer queue by the command "cupsenable".

cupsenable PRINTER_NO1

...or by simply clicking the "Resume" button in the Printer GUI window. Huzzah! Paper with properly placed toner dust eventually exits the printer.

The annoying creation of unusable print status jobs eventually affects enough people and Macs that the process above has to be automated. So here's what I did:

First a script called "local.printjobsanitizer.py" in "/Users/Shared/Scripts" that identifies (sort of) all the tiny "Print Status" jobs.

#!/usr/bin/python

import subprocess
import re
import os
import pwd

consoleuser=pwd.getpwuid(os.stat('/dev/console')[4])[0]
task=subprocess.Popen(["/usr/bin/lpstat","-l","-u",consoleuser],stdout=subprocess.PIPE, stderr=subprocess.PIPE)
taskoutput=task.communicate()
lines = taskoutput[0].split("\n")
jobids=[]
printers=[]
for line in lines:
    matchobj=re.match("(([^ ]+)-([0-9]+)) +"+consoleuser+" +([0-9]+)",line)
    if matchobj:
        if not matchobj.group(2) in printers:
            printers.append(matchobj.group(2)) 
        if matchobj.group(4) == "1024":
            jobids.append(matchobj.group(1))
for jobid in jobids:
    subprocess.Popen(["/usr/bin/cancel"]+jobids).communicate()
if len(jobids) > 0:
    subprocess.Popen(["/usr/sbin/cupsenable"]+printers).communicate()

Then a launch daemon definition to be placed in "/Library/LaunchDaemons" that gets triggered by modifications to "/private/var/spool/cups" (where print jobs get spooled locally on the Mac)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>local.printjobsanitizer</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/bin/python</string>
        <string>/Users/Shared/Scripts/local.printjobsanitizer.py</string>
    </array>
    <key>WatchPaths</key>
    <array>
        <string>/private/var/spool/cups</string>
    </array>
</dict>
</plist>

...reboot the Mac and once it's back up "Print Status" jobs get cancelled on sight and users have the experience of printing unproblematically (their machines are doing a lot of unnecessary work however)

But please Xerox why did you make me resort to jumping thorugh all those hoops? The code above is band-aid on an ugly wound at best. Printing seems to happen happily irregardless of the missing status reports.

In an "enterprise" environement such as ours why can't we disable bidirectional communication when it seems to block printing?

Why can't we do something like:

lpoption -p PRINTER_NO1 -o XRBiDiCommunication=Off

...and be done with it?

Browsing around this forum one gets the impression that a certain amount of fingerpointing is going on with Xerox representatives blaming Apple and Apple users blaming Xerox (http://forum.support.xerox.com/t5/Printing/quot-Xerox-Features-quot-driver-doesn-t-load-in-Safari-10... ...not entirely related, but still an example of Apple changing stuff and making Xerox look bad in the process)

Maybe all my work has been a waste of energy and if I could just connect my client machines (100s of them) and Xerox printers directly on the same LAN subnet the software would function with no issues what so ever. Alas, I'm not so fortunate and have to work with the boundaries set by the rest of the IT department.

Can you point me to an official Xerox support document that states that using authenticated smb with a Windows printserver is not supported on macOS?