9 Replies Latest reply on Nov 25, 2014 1:43 PM by Scott Olswold

    Fixing error state on shared print queues

    Newbie

      Hello Community,

       

      Our Server is persistent in reporting an error state on the shared queues.  Users are still able to print but the server is reporting an error which triggers windows 7 and windows vista to inform the user that the printer is in "error state" or that there was "an error printing."  This information worries users and causes many calls to our help-desk.  Programs built on Java are unable to print as long as the queue is reporting an error.

       

      Has anybody experienced this before and found a solution?

       

      Print system configuration:

      Server:

      Intel Xeon x5650 2.66 ghz (2 processors)

      RAM 8 GB

      64bit OS

      Windows Server 2008

      Pharos 8.1.5293.56

       

      Printers Managed:

      251 printers bring managed

      160 Kyocera

      6 Konica

      53 Canon

      26 HP

      6 others

       

      Queue Structure brake down:

      4 held queues for 45 printers of same model for each queue

      example:

      B&W queue (driver kyocers FS-9530) is associated with Kyocera FS-9530 printers

      B&W_finishing queue (driver Kyocera TA-420i) is associated with Kyocers TA-420i printers

      Shared queues and device queues match in driver and printer model.

       

      234 direct queues

      The rest are not managed by phaors

       

      Settings:

      64 bit and 32 bit drivers are of the same version number

      SNMP status is disable on the ports

      Bidirectional support is disabled (per advice of phaors support)

       

       

      Server Load:

      Memory Usage 3 GB of 8 GB

      CPU Usage 0-2%

       

      We have been unable to find any useful log files... they only tell us that there was an error but doesn't give a cause.

       

      This is something that is affected by the usage of the print server however the server is not having any difficulty handling the load... for example there are no errors during the summer when students are not on campus but when students arrive the printing doubles and then the server starts reporting errors on the queues, even queues the students don't use and queues that didn't go up in usage.

       

      Thank you for your advice.

       

      Josh

       

      queue_errors.jpg

        • Re: Fixing error state on shared print queues
          Tony Fappiano Wayfarer

          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.

           

          Thanks

          Tony

          • Re: Fixing error state on shared print queues
            Scott Olswold Guide

            Josh,

             

            The "Error" status is one that is posted from the Print Spooler side of the operation. Here's the troubleshooting step by step:

             

            1. 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.
            2. 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.
            3. 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.
            4. 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.

             

            Regards,

            Scott Olswold

            Pharos Systems

            1 of 1 people found this helpful
              • Re: Fixing error state on shared print queues
                Newbie

                Scott,

                 

                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.  ***

                  • Re: Fixing error state on shared print queues
                    Newbie

                    Scott,

                     

                    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.

                    1. We created a duplicate queue identical to the queue they were wanting to use.
                    2. 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.

                      • Re: Fixing error state on shared print queues
                        Scott Olswold Guide

                        Joshua,

                         

                        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.

                         

                        -Scott

                  • Re: Fixing error state on shared print queues
                    Newbie

                    Does anybody have an official number of for the maximum of jobs that the pharos queue can handle per server?

                     

                    And/or

                     

                    Is there an official maximum number of printers the pharos software can handle per server?

                    • Re: Fixing error state on shared print queues
                      Daniel D'Alessi Newbie

                      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.

                        • Re: Fixing error state on shared print queues
                          Newbie

                          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.

                            • Re: Fixing error state on shared print queues
                              Daniel D'Alessi Newbie

                              Hi Joshua,

                               

                              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.