Print Spooler cleanup

Anyone else ever get that GRRRR feeling when a pattern starts to build up in your head, a pattern of stopping the Print Spooler, deleting the the contents of the PRINTER directory and starting the Print Spooler again? This can be caused by a number of problems like ridiculously large print jobs, print driver errors, corrupt print jobs... This is a 10 minute setup that may save you many more hours of "fixing" printer issues.

I've always dealt with it in a simple way, of course I manually do the clean up first to get the clients printing again, but then I whack in my script. Now I only ever run the script on a server because the clients are almost always connected to the shared printer object on the server. I'll run this usually once a week, say on a Saturday at midnight - when no one will be using the server.

Doing this during the middle of a work day on a Terminal Server where you have 50+ clients connected is going to cause you headaches. Even doing it manually. Simply because most clients won't be able to print at all if they were still connected when you performed the stop, delete, start on the spooler, rarely have I noticed clients still able to print after doing this procedure and I'm not even sure they hadn't disconnected and reconnect because they couldn't print - You have been warned!!! oh and if you have any printer objects setup to only allow certain people to print overnight if they would otherwise hog the printer, script it for a more suitable time when the print run would have finished.

So the script looks like this:

net stop spooler
del /F /Q C:\WINDOWS\system32\spool\PRINTERS\*.*
net start spooler

Simple isn't it?

Of course you could always use any of the other command line tools to stop and start services, such as sc, which will let you run the command on a remote computer, so you could script it & schedule it on your own PC and not have to login to the the printer server, you'd probably have to use psexec to do the deletion part or any other remote deletion commands.

If  you want to be fancy you can do things like write the events to the event log, which your monitoring software can look out for and alert you if it failed, if you are bothered, you can use the "if errorlevel" to hop, skip and jump your way around a complicated script that write events and retries if it fails and so on. I doubt it would fail, and I've not yet seen it fail but perhaps it could if the service hadn't successfully released it's file lock.

I hope this saves you time too!