Windows – Adding 64-bit Print Drivers to 32-bit Windows 2003 Server

There is no built-in mechanism to disable printer redirection for only specific printers.

I'd consider doing the following (it's convoluted as all get out, but it should give you what you want):

• "Share" the printers on each client computer that should be available to the Terminal Server.

• Add the "TCP/IP Print Server" service to each client computer (marking the service for automatic startup and opening port 515 in the local Windows Firewall on each client computer, if applicable).

• Create local printers on the Terminal Server (or other server computer) corresponding to each printer attached to client computers. These printers should use "Standard TCP/IP" ports configured for LPR, with the "Queue Name" set to the share name specified on the client comptuer for each given printer, and with the "LPR Byte Counting Enabled" check-box checked.

You have control of the print queue name using this method such that you can make the name appear as you'd like. You can set permissions on the queues to prevent users from sending jobs to the wrong printers if you so desire. You can completely disable client printer redirection, as well.

(I do the whole "TCP/IP Print Server" dance, as described above, rather than using "Local Ports" naming UNCs. Some people do the "Local Ports" but I've found throughout the years that I have severe reliability problems doing it that way. My method basically makes the PC act like a really expensive "JetDirect" box...)

You can remove printer drivers using the "Drivers" tab of the "Server Properties" accessible from the "File" menu of the "Printers" dialog.

Unfortunately, there's no built-in tool to "find bad printer drivers". I'd start by looking at printers that have jobs "jammed" in their queues when the CPU on the server begins to spike. If no jobs are being left "jammed" you might turn on "Log spooler information events" (on the "Advanced" tab of the same "Server Properteies" dialog) and start Performance Monitor logging "% Processor Time" to a file. You should be able to correlate the spike in CPU to print jobs logged in the event log by the print spooler.

Failing all of those methods, move half of the drivers / printers to another server (which may be painful, assuming you don't use scripts or Group Policy to populate client printer lists automatically) and perform a binary search (move half, move half of the half where the failure occurred, continue) until you find the failing driver.