What happens to Print jobs destined for a Windows printserver if you restart the Print Spooler service? That is, If we have a print job that simply won’t clear from one of the printers on the printserver unless the print spooler is restarted, what happens to other print jobs destined for other printers on that server?
Thanks
Um, can you mention how or where you found documentation for same?
They stay in the print spool queue. This is a directory structure, usually under c:\windows\system32\spool\printers, but can be moved. In Windows 7 go to Control Panel, Hardware & Sound, Devices & Printers, (or Start, Devices & Printers), select a printer, then click Print Server Properties, and then Advanced. Different versions of Windows do it slightly differently.
Your print job that won’t clear sounds like an example of the print queue for that printer not being set up quite correctly. I’d need full details to help further.
I should have elaborated a bit more.
Through attrition, I inherited the job of Printserve admin. (Along with several other jobs for which I had no background or training)
There are perhaps 50 or so printers on that one printserver (Windows 2003 OS). And another 50 or so on another printserver. This one particular printer on the print server hangs regularly. The print queue has been deleted and re-built. Print drivers re-installed. JetDirect replaced. (That will give you a hint at which brand of printer). Our other printers behave fairly well, only giving us sporadic problems.
HOWEVER, even given all that, that’s not really what I am wondering. I think I should have to pay for trouble-shooting of that level. I’m more looking for help or direction to find documentation. When I try regular searches for this, I get a few things back that look promising, but then turn out to not quite be what I was looking for. Which is… If people are sending print jobs to other printers if and when I restart the printserver Print Spooler service, what happens (if anything) to any print job request that was incoming, and what happens to any other print job that may have been in process of printing when I restarted the print spool service.
From Quartz’s reply, it looks like the answer is essentially, “nothing bad”. I’m just looking for re-assurance that we are not missing or casting off print jobs unknowingly. If your BING or Google skills are better than mine, if you could point me at MS documentation regarding this, that would be great.
You have my sympathies. How is the box defined in the print queue and on the JetDirect box? LPR? RAW? HP?
**Quartz **can handle to complex stuff, but the IT lightweight version goes like this …
For round numbers, restarting the Spooler service is safe. Any print jobs already in queue will definitely stay there. They’re just temp files on the HD of the server. They won’t get lost or forgotten.
While the Spooler service is stopping & restarting, the server will refuse new print jobs. In fact, it will refuse to tell any clients that it even owns any printers. So you have a 5-10 second window where anyone clicking “print” on their workstation will get an error. But when they try again a few seconds later it will work. Not much harm, probably no foul.
If you have automated systems which spit out print jobs on their own (say a daily report generator) those systems may or may not be smart about dealing with an unresponsive print server. If they just try again in 30 seconds all will be well. OTOH, if they just fail silently and yesterday’s daily sales report simply never gets created & there’s no way to re-run it, then you have a problem.
The real fix to that is a smarter report generator, but that may be impractical depending on the rest of your IT situation.
An easier fix is a load-balancing print server cluster, so you can work on one box (e.g. stop & start the print spooler) while appearing to give seamless service to your clients.
Dead easy.
Even with the cluster, it’s not truely seamless. The failover from one node to another will briefly interrupt the printing services. The reality is though, on a system with so few printers, it won’t take very long, and the users won’t even notice.
Based on your brand, I’d highly recommend going to the HP UPD. I manage an environment with 6200+ queues on 8 servers, which is mostly HP, but has a number of Xerox devices. When we went to the HP Universal Driver (HP UPD), all of our spooler hang issues went away. We had previously had a lot of trouble with the 4250/4350 series of drivers, and the 4650 drivers. We had some PDF printing issues, related to firmware revisions on the printers (49.c02 errors), but upgrading to the current FW version on the devices took care of that. We use the PS version as our default, but the PCL6 version works fine too. We have a mix of each in the environment to accommodate some older applications. Currently we’re using UPD v4.5, as we’ve not come up with a good reason to go to v5. If I was starting fresh, I’d go with the current version, it has some nice features added since 4.5 was released. All of our HP devices have used this driver since late 2008, and since then we’ve printed something like 150 million jobs through all of our printers.
6 of the 8 servers in my environment are clusters, and the other two are NLB systems. (Network Load Balanced, but not clusters. Minor differences) The NLB systems will be replaced with clusters when the hardware goes EOL (end of life).
My take on the original question:
Jobs which are processing will be paused, and continue (or restart) upon the spooler coming back up. Jobs which were in an error state, but had not yet printing will attempt to restart. Jobs stuck “deleting” will be deleted once and for all.
This is one of my biggest problems as a PrintAdmin. Online searches give you hints of what’s happening, or what to do to resolve issues, but overall, printing isn’t really documented. It’s an under recognized area of IT, and generally is very simple… except when something happens, and the CEO is waiting to print a large document (which he’s had for 3 weeks) for his meeting (which is in 5 minutes). In some respects it’s a bit of an art, and when you get up into large environments (one of my clusters has 2400 queues) balancing maintenance & problem resolution against the overall user impact.
One other thing I thought of after my long above reply, is have you tried recreating the queue (including the port)? It shouldn’t make any difference, but I’ve seen odder things happen. Use the same share name, and the users won’t need to remap the queue.