I have not seen this on a USB install ever, but, the reasoning is probably similar, and the workarounds at the end of this capture from the Xerox Engineering team may get you somewhere in eliminating the issue. The following words are not my own, and does not in fact deal with USB, but the underlying explanation should still apply.
Problem:
When printing from newer Mac OS's 10.7 and 10.8 a user will see additional print jobs appear in the Mac queue. This occurs when printing locally from a Mac
or when printing from a shared queue. (Example of a shared queue Windows 2008
server pointed via LPR://server ip/printershare)
What and Why the jobs now appear:
Our engineers have investigated this problem the print driver is working to meet new Apple OS design requirements.
As part of ongoing security measures, Apple operating systems starting in 10.6 prevent any application that does not need network access to complete its "work" from having network access. This includes print drivers inside of applications. All print drivers (Xerox and Competitors) are bound by the same rules and no longer have access to direct network communication. Xerox uses the "Printer Status job" as their way to meet this security requirement and still be able to gather the necessary device information. If the job is titled "Supply Levels" this job is created by the Mac OS and is required to capture Toner Levels. This also occurs because of the above description.
Why jobs may be stuck in a shared queue:
Xerox does not support the following configuration: an LPR connection between
a Windows print server and a Mac client.
The Xerox Mac OSX driver contains custom XBDS filters/commands which are used
to communicate directly with the device. When communicating from a Mac to a Windows server, via LPR/LPD, the printer status jobs can hang in the Mac OS print queue. This occurs because Windows server cannot resolve the communication being sent from the Mac client. The reason the Windows server cannot resolve the communication is because the information sent from the Mac is meant for a
printer and not a Windows OS.
Second Possible Reason for jobs being stuck in the Mac queue:
The Mac driver intends to send this print job to the device, however in this customer's case the Windows Server is between the client and device. Since the
Mac does not know it is not communicating with a printer it continues to send
the Printer Status job, via HTTP (port 80), waiting for a response back. The server does not know it is being asked to act like a "printer," and does nothing with the job, and eventually rendering the job stuck in the print queue until it
is manually deleted.
Workarounds to prevent the jobs from occurring:
- Disable Bi-Directional Communication (To configure a preset with bi-di disabled please perform the following)
- Open any application
- Select File > Print > Xerox Features
- Select Advanced > scroll down and select Bi-Directional Communication
- Select Off then Ok
- Select the Presets dropdown
- Enter a new name for this preset, select All Printers and select Ok.
Refer to the following link to describe how to set a custom preset as the new
defaults
- Configure the printer on the Mac using SMB instead of using LPR. Please refer to the following information on how to configure a printer via SMB
¢This is only valid for shared print queues¦
Below is a link with steps on how to add the printer on the Mac.
-This link offers the correct URLs for 2k3 and 2K8 windows servers to Mac OSX
all the way back to 10.4.
- Modify the driver PPD file and remove the following command cupsCommands:
"ReportLevels ReportStatus". Removing this command will also prevent any bi-di communication to occur between the device and driver.
The modified PPD can then be loaded onto the Mac clients
- Create the print queue using Bonjour instead of using an IP address. This problem only occurs if the print queue was created manually using an IP
address and it does not occur if the printer is installed via Bonjour
- If Port 80 or Port 443 is blocked please add an exception to the Mac OSX
proxy.
