[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 646
  • Last Modified:

Network Users unable to print, map queues. Server 2008 r2

We manage the print server of a University. The server is running Windows Server 2008  r2 x64 Enterprise with SP1 installed.
The server has over 100 MFD's and MFP's. They are almost exclusively all Fuji Xerox devices. Combining the x86, x64, PCL and PS drivers, there are over 150 different drivers on the server.
The printers, ports and drivers are managed exclusively through the Print Management mmc.

The issue we have had for the last couple of months, is that sporadically, users have not been able to print or map print queues from the server. When this happens, existing print jobs are visible in the queues, but no action is being taken with them. It also sometimes causes users MS Office programs to lock up when trying to print. Logged on to the server, the admin is able to send a print job successfully and the job prints out at the MFD.

To restore service is simple, restart the print spooler. This instantly restores service and functionality to the users. Unfortunately, I don't know what is actually causing the 'lock up' to occur.

In the PrintService event log, when there is an issue there seems to be a lot of the following message
"An administrator moved document 182, Remote Downlevel Document owned by user to position 1 on print queue. This changes when the document will print. No user action is required. "
They are normally grouped in lines of 10 or more. This may mean that when the issue occurs, Mac users may still be able to print, or Mac users are stopping other users from printing.

If it is a driver causing these issues, is there a way to identify, isolate and then remove it? Or is it an RPC issue that is stopping users from making the connection to the print server?

  • 5
  • 4
2 Solutions
I just can say, that I had similar problems in the past with some printers. And these problems were connected to printer drivers as well as some settings inside the printer drivers, especially some enhance settings.
The effect was, that printings without such settings print fine, other documents with these settings stuck in the queue and blocket it --> restart printer spooler solved the problem.

The problem was solved in my case first not to use these enhanced settings and later my never drivers.

A more common problem, where the queue can stuck ist just the case, if some users print very large documents and the queue folders runs out of space.
GrattymantAuthor Commented:
Hi Bembi,
I'm fairly certain most of the printers have been set up to have advanced settings disabled but I will investigate this.
This issue has just started giving a new symptom: Of the 100+ queues, a couple are now coming up as "Printer is offline". However, from the print server, you are able to access the webpage and ping the printer. Restarting the print spooler allows the printer to resume connectivity immediately, but a different set of 4 or 5 printers become "Offline".
Running Wireshark, I can see that the server keeps requesting SNMP information every 5 or so seconds from the device but it is not receiving a response.
Have you checked the SNMP settings on these devices?
What happens, if you just switch off a printer an switch in on again?
Does it continue imediately or do you have to restart the spooler again?
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

GrattymantAuthor Commented:
Restarting the MFD doesn't do a great deal unfortunately, there is still no SNMP communication between server and MFD. Disabling SNMP traffic on the print queue port stops the server seeing the MFD as offline(as it assumes it's online) and allows it to print.
Things I'm planning to try for both the issues:
Ensure the time on the server matches the time on the rest of the network to rule out a Kerberos issue
Create a shared folder on the print server and see if users can connect to it when the first issue occurs as it might be a SMB stack issue
Disable SNMP on the ports of the newer MFD's (2006 and newer)
Your comments point me to SMB2, especially because you said, you have older printers.
Not quite sure this is an issue, but it is a try...

Other things I could find (beside drivers) is.....
Putting the printer in driver isolation mode...
Printing mode to RAW
Power Saving issues?

Here is a longer thread about such issues and troubleshooting:
GrattymantAuthor Commented:
As an update, we haven't had the print spooler lock up since disabling the SNMP requests on the print queues. While this doesn't explain why the SNMP issue is occurring (still visible with WireShark) it may explain why it was locking up (too many requests?).

Another avenue I'm also going down is:
As we are also getting large amounts of Event ID: 4625 logs.
Our Security Log was already set to Overwrite, but I have increased it to 1024MB
At least I checked my host servers and print servers for your last article.
...and can not find any of these errors...
...but set the log settings via policies...

What I could see is also
Axence Net Tools Pro
http://www.axencesoftware.com/de (freeware)
Beside other stuff, this tool can read the SNMP information from any device...
So, my idea would be to compare printers, which have this effect to other ones, which don't have.

Nevertheless, according to my experience with print queue errors, you may investigate, which kinds of documents force the queue to stop and if there is something in common.
As I said, I had some issues in the past whth some kind of documents, and after restarting the queue, I got sometimes a paper sheet with cryptic postscript errors, which could be solved by changing the printer settings / replacing drivers.

Have you ever inspected the error queue of the printer itself. Some printers have a error protocol, which can be read usually by the printers web interface.
GrattymantAuthor Commented:
Hi Bembi,
When the queues are going offline, it looks like it's purely server side as other servers on the same VLAN can still print to it (not external facing servers). When the spooler is restarted and/or SNMP is turned off for the queue, the printer resumes normal functionality with out so much as an error page or log on the printer itself.

I'll try out Axence and see if I can work out what SNMP message the server is sending to the printer and why it isn't getting one back. Regardless, thank you very much for your help

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 5
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now