This is going to be a long question. First my environment:
- 5 terminal servers (Dell PowerEdge M600) running Server 2008 (not R2) 64 bit SP2 in a TS Farm using session broker
- 1 print server (Dell PowerEdge M610) running Server 2008 R2 64 bit SP1
- Various printers installed on print server deployed via Group Policy
- Most documents are printed via Crystal Reports ActiveX Designer from our point of sale system to a group policy deployed network printer on the print server
The issue occurring is that all printing from the terminal servers to the print server ceases. The job appears to be send without error, attempting to print a Windows test page produces an immediate 'Failed to print' balloon.
The spooler server on the print server IS running and no errors are reported in Event Viewer (Spooler logging is enabled). The spooler service on the Terminal Server(s) IS running and no errors present in the event logs on the terminal server either.
The spoolsv.exe process on the terminal servers will hover at 13% processor (max of one core) for long periods of time while memory levels do NOT fluctuate. At random intervals the terminal server will pause (unresponsive at console and RDP) for all users, the Spoolsv.exe service will spike to 100% for a very brief moment and then return to 13% CPU.
The servers are located on the same physical gigabit switch, other network functions (file, ping, ODBC) are fully functional both during the pausing and the printing outage.
My only recourse so far is to restart the spooler service on the terminal servers to recover printing services.
This problem is beyond frustrating due to the lack of errors and the fact that the spooler service does NOT crash, but simply stops processing jobs.
Does anyone have an idea where to start?
More information on configurations, printer models, etc available, just ask.
Got symptom like that for a farm I have. The print job was sent when the spoolsv was hitting 100%. Thus error printing was reported.
It was random, and the problem was the GPO that publish the printer. When a user X logged in, the spooler work to install the printer, when that used too much cpu the error come.
To prevent that I did all printqueue local & removed printer importation rom the rdp client (with tcp port for the printqueue, not via the pritnserver as it's stored in the user profile if you install via the printserver)
I did a simple vbs script that map the default printer depending on the user group.
Logging from 90sec. falled to 15sec .... and most of all no more printing issue
To test out it was kinda some step in my case. Installed a demo Win2008, install your app, remove gpp for that server, isolate some user and make them work there to test out.
Or run a perfmon and check if the cpu spike fit when your user got difficulty printing.