Link to home
Start Free TrialLog in
Avatar of Grattymant
Grattymant

asked on

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

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

Thoughts?
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?

Thanks
ExpertsEx-1.JPG
Avatar of Bembi
Bembi
Flag of Germany image

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.
Avatar of Grattymant
Grattymant

ASKER

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?
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)
SOLUTION
Avatar of Bembi
Bembi
Flag of Germany image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
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:
http://www.aaronpalermo.com/wordpress/archives/96 
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
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
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
OK