Jeff Wouters's Blog

Printer Drivers

The printer drivers that you select to use in your environment can have a great impact on its performance, reliability, and scalability.
Performance and reliability can be improved by using robust, well-tested drivers. These drivers are less likely to crash and therefore require less maintenance.
Scalability is affected by the quantity of unique drivers on a specific server. By re-using the same driver for multiple printers, you lower the chances that drivers will interact in a negative way and reduce the amount of spooler process and registry space used.
Since most Printer Drivers can be used for multiple types of printers from the same vendor this can be realized, it will only take some investigating which driver can be used for which types of printer.

Drivers can be written in either user mode (also called version 3 drivers) or kernel mode (also called version 2 drivers). When a kernel mode driver crashes, it takes the whole system with it and so causes a BSOD (Blue Screen of Death).
Since the Windows 2000 Operating System, native drivers are run in user mode. So if possible, use the native drivers of the Operating System.

 The following types of drivers are recommended for achieving optimal performance, reliability, and scalability:
*) User-mode drivers
*) Unidrv-based drivers
*) Drivers with the Designed for Windows logo

The following driver types should be avoided:
*) Kernel mode or Microsoft Windows NT 4.0 drivers
*) Monolithic drivers (that is, neither a Unidrv nor PostScript-based driver)
*) Drivers without the Designed for Windows logo (unsigned drivers)
*) PostScript drivers
*) PCL6 Drivers

Next are some basic best-practices:
*) Uninstall Printer monitors
 Check the HKLM\System\CurrentControlSet\Control\Print\Monitors registry key. The default installed Printer monitors should be:

*) Do not use Kernel drivers
Yes, I say it again as most people forget about it!

*) Use only certified drivers
Neither Microsoft or Citrix officially certify printer drivers for use on a Terminal Server, so in theory no Printer Driver is certified for usage in a Terminal Server environment. If a manufacturer says they are, this only means that they have tested their driver in a Terminal Server environment. If they do not mention that they have a certified or supported driver; do not implement that one!

*) Keep the amount of Printer Drivers low
Try to limit the amount of drivers. This can be done by using the same driver for several printer types of printer.

*) Create a supported list of printers
Make a list of all the printers you can guarantee to work perfectly in your environment. This to make a clear statement and to, again, keep the Printer Drivers amount you use to a minimum.

*) Do not allow RDP auto created printer (if using Citrix Presentation Server)
This rule is one of the most important rules. The RDP Client is by default enabled in auto created client printers. Often administrators use this client to connect to the Terminal Servers for system management purposes. Because of the administrator rights the drivers which are locally available will be installed to support the auto created client printing functionally within the RDP protocol. Disable the support of this feature using a GPO policy. For a howto do this: http://www.virtualizationadmin.com/articles-tutorials/terminal-services/printing/windows-terminal-services-printing.html

*) Prevent normal users from adding printer drivers
Also prevent users from adding printer drivers. When using Citrix Presentation Server configure Citrix policies to use the universal printer driver if the native driver is unavailable (with auto created client printer) or make sure that the drivers on the print server, client and Terminal Servers are exactly the same.

*) Make sure that all Printer Drivers are available on all servers and that they are consistent.
You can use several technologies to make sure of this, SCCM, RES Wisdom, Altiris, scripts… so howto deliver those drivers is for you to decide, as long as you are consistent.

In many environments client printers are automatically mapped when a user logs on from a remote location… and the appropriate Printer Drivers are installed for the client printer. I think this is not desirable, since you can’t control which printer is attached to the computer the user makes use of outside your environment! A very good article about this is: http://www.virtualizationadmin.com/articles-tutorials/terminal-services/printing/windows-terminal-services-printing.html
In that post is, among other things, explained howto disable client printer mapping. There is also a good explanation in there about what Printer Drivers are preferred and which are not… please pay extra attention to that!

Client Printers
What if you still require client printers to be mapped? For example when you have remote users working at home that want to print?
My choice would be to disable the automatic installation of Printer Drivers and make the ones you want available in your environment. For example, with a policy you can configure that no Printer Drivers are automatically installed. But you can configure which Printer Drivers are available in your environment, so that you are able to manage it and prevent unwanted Printer Drivers from being installed.
This is also explained in this blog article: http://www.virtualizationadmin.com/articles-tutorials/terminal-services/printing/windows-terminal-services-printing.html

Finding a bad Printer Driver
Why should I write something when someone else has done it better already? http://www.virtualizationadmin.com/articles-tutorials/terminal-services/printing/hunt-bad-printer-driver.html

You can also use the analysis of a Memory Dump to find the bad driver. For a small guide, take a look at one of my previous posts: http://jeffwouters.nl/index.php/2010/01/troubleshooting-driver-bsods-in-windows-with-the-driver-verifier-default-rules/

Sources: http://www.virtualizationadmin.com ; http://resinside.blogspot.com ; http://technet.microsoft.com/ ; http://support.citrix.com

As I repeated several times in my last post, it is adviced to remove the configuration you’ve put into Driver Verifier when you are done troubleshooting.

That’s why I write this post in order to show you howto “clean you’re shit when you’re done”.
Trust me on this one, the end-users will thank you later. Especially on Terminal Servers if Driver Verifier has been fully configured…

Alright… here we go:

The Driver Verifier can be found at %windir%\system32\verifier.exe
You’ll momentarily see a Command Prompt window and then the Driver Verifier Manager will launch and display wizard-like GUI:

When selecting the “Delete existing settings” option, beware that ALL configurations you have made in Driver Verifier will be removed. So if you’ve created some previous configurations in it they will also be deleted, not just the ones you’ve put in the last time.
So perhaps you will want to configure those settings back when you’ve done.
But as I explained in my previous post, it is recommended to only configure Driver Verifier when needed and not just to get some more information in a MemoryDump just in case you get a BSOD.

Why? Performance loss!!
I just feel that I can’t mention it enough, but configuring Driver Verifier will create some performance loss.
Yes, even with custom settings, I shall explain those in future posts. It will not be much of a performance loss with custom settings, but still I would think you would make full use of your resources.

Back to the screen from Driver Verifier.
Click on “Finish”.

Next you will see this popup:

Now this is just a “Are you very sure you want to do this”-popup.

Click “Yes”, reboot the system and you’re done!