Josh, did you ever find a solution for this? We seem to be experiencing this same issue were it started with only a few queues, but lately has seem to have gotten progressively worse.
1 of 1 people found this helpful
The "Error" status is one that is posted from the Print Spooler side of the operation. Here's the troubleshooting step by step:
- Make sure that no queue either using the same driver or the same port has "Bidirectional Support" checked on the Ports tab for the queue's Properties page.
- Ensure that no job queue has "auto" anything turned on for things like status, configuration, or SNMP function. Those options typically use the port information to access the printer (because in a non-managed world, they would be set up this way), and since the job queue uses the Pharos port, that would not work out well.
- Is there sufficient hard disk space wherever the SPOOL folder is located (by default, it is C:\Windows\System32\SPOOL\Printers)? If you need to check where your jobs are going, go to Print Server Properties (Windows 2008, Devices and Printers button in top bar) or Server Properties (Windows 2003 and lower, Printers and Faxes folder, File menu) and choose the Advanced tab. That drive path is where all of the jobs will be held until release.
- Is there a job in Error? That can also tie up the port monitor when several queues are using the same one. If you go to the Spool directory from item #3, check the dates of the SPL files in there.
If you need anything further, let us know. We're here to help.
Thank you for your responce. We have not found a solution yet but created a work around that seems to be working ok however accually fixing the problem would be better then a bandaid.
#1 and #3 are fine we did those steps before.
# 4 I checked the spool folder but i'm not very sure what i'm looking at. There are spl files that date back to october 2011 but those are connected to a printer that's not on the network and not connected to pharos. we should clean that up but it shouldn't be affecting the other queues
***# 2 there is silent auto configuration on for the queues. I'll try turning that off. and see if this fixes the problem. ***
I double checked the server and found that the kyocera queues all have auto configuration disabled when the port is set to the pharos port.
One key that might help is our work around:
We created a work around for people that needed to print from java programs.
- We created a duplicate queue identical to the queue they were wanting to use.
- we setup the port for the queue to be a Local port called \\server name\shaired queue name
- This fowards the jobs from the copied queue to the pharos queue, to the device queue.
By doing this we are hiding the error state and fowarding the jobs to the queue with the error state. This leads me to believe that the error has to do with the pharos port.
Another key that might help:
This error state goes away when students leave for the summer and during vacations. It has nothing to do with the load on the server hardware becasue our hardware is hardly noticeing the load of student printing. I can get an exact number but to give an example of: our main black and white queue that releases jobs to most black and white printers on campus can have up to 2000 jobs in queue during the school year but can be as low as 400 during the summer.
Is there a limit to the number of jobs that the pharos queue can handle per server or is there a limit to the number of pritners that the pharos software can handle per server?
If there is we can try moving our global queue to another server but that costs a lot of money and time and I can't get that approved to even test if I don't get some official number which i have been unable to obtain.
2000 jobs in a single queue is a bit much for Print Spooler to handle. The Print Spooler service has to manage each of those jobs that are in the Pharos queues waiting to be printed. This equates to additional RAM and processing resources just in job management, which can cause problems with other functions, like queue management. It is this concept of "too much" that (among other things) caused us to essentially bypass the underlying Windows print infrastructure outside of job acceptance through a queue in our more recent versions (Uniprint 8.3 to current version) vis-a-vis the Pharos Secure Release Service (SRS). In these versions, the Windows Spooler is still responsible for ensuring queue management, but once a job has been received from a client, the Pharos Secure Port/SRS combination whisks it away from the Spooler and into a secured JobStore on the local server. So jobs stay for only a short while in the queue, which approximates how Spooler is normally accustomed to handling things. Upgrading also has other benefits in terms of print job acceptance and overall system management:
- The number of print queues managed through Printers & Faxes (or Devices and Printers) is cut down significantly, as we no longer use "device queues". In Uniprint 8.3 and newer, the "device" is really just a database entry that includes an IP address to which the released job is sent.
- You can specify the JobStore on any volume you wish (even to disks that are on Storage Area Networks).
- It is much easier to engage a "cross server" job release workflow, if needed.
When Spooler has to work too hard, it slips (you must understand that the core Spooler software has not seen much updating since the Windows NT 4 days; some new things have been added, but this is more owing to the "plug-in" architecture of Spooler and not due to enhancing Spooler code), and you end up with what you have been dealing with. I encourage you to upgrade Uniprint to the most recent version to enjoy these benefits and added stability overall.
In regards to the number of queues that a server can manage: I have seen servers hosting in excess of 900 active queues. I would never recommend that many, but it can be done. When you are on a busy server, communications and server response can get bogged down. The "System" process in Windows is responsible for handling core driver input-output, including those of network interface cards, and more client connections means that the network card driver has more to manage, causing undue strain on this incredibly-dependent Windows process. It responds by consuming memory by the truckload. Also, it requires mentioning the incredible disk space needed to handle potential print peaks.
Does anybody have an official number of for the maximum of jobs that the pharos queue can handle per server?
Is there an official maximum number of printers the pharos software can handle per server?
Did this ever get solved? We have a similar problem and I have tried all the suggestions in this article. We use Toshiba MFDs - 3520Cs and 3540Cs. All have the latest drivers installed and in one case we have updated the firmware on the printers to the latest as well. I have run out of ideas.
No solution yet. We are still doing our work around. I have heard unofficialy that there is a limit to the number of printers the phros service can manage per printserver. (this is from a compnay called Tracsystems who works for Pharos) If this is true it might explain why the errors go away when the student's leave campus and most of the printers are nolonger being used. It might also explain why our work around putting a step before the queue with the pharos port works and the error doesn't travel to the new queue we created, becsue the new queue we created is not being managed directly by pharos. But I haven't seen any offical documentation to varify this, and we are not going to do a system wide change like this without it being varified.
Daniel D'Alessi, We were sugggested to limit 100 printers per print server to be managed by pharos. May I ask how many printers you have and if this issue started with an increase or printers? Maybe if I can get enough records of this problem we can either rule out or partically varify a limit on the service per print server.
We have always ran the same amount of printers since Pharos was implemented and never had this problem. We have increased the number of queues though, but no where near the 100 limit as you suggest. We have 9 physical printers and 18 print queues. This issue started occuring after we had a problem with our server. We ran out of disk space and the spool files were unable to be created which was causing an error on the printers. After resolving the issue and restarting the server all the errors went away, but when the printers started being used again, the errors came back.
It's important to note that the error status only occurs on the print queues. It's obvious to me that it has something to do with the Pharos port and I have even gone to the level of deleting all the printers and queues in Pharos and recreating them, but the errors still remain. I don't want to try anything more extreme until I know it will solve the problem.