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

If you are encountering driver related BSOD’s in Windows, chances are that your system is suffering from the effects of a deficient driver.

Normally a vendor will submit their driver to Microsoft for certified testing. If the driver passes the tests, a digital signature will be provided to the vendor for that specific driver.

Now let’s go to the cool part: Driver Verifier!
No, it is not a new tool. However, since Windows Vista it has some great features which can be used when toubleshooting BSOD’s.

Microsoft Windows comes with two versions of the Driver Verifier — a command-line version and a GUI version. Because I love GUI´s, I will only cover the GUI version in my upcomming posts.

Once configured the Driver Verifier will go and do it’s job in the background. What does it do? Basically it performs a serie of extreme stress tests on the selected driver(s) in an atempt to cause the BSOD. So if you are setting this up on a terminal server in a production environment then you will experience loss of performance on that server!
If there is a problem with the selected driver, the stress tests may not be enough to cause the driver to fail.
So, this tool does not give you instant results… you have to wait for the driver to fail. If, after a while, the driver hasn’t failed then perhaps the cause lies not with the selected driver?

What if it’s a driver you can’t go without? Contact the vendor of the driver and provide them with the memorydump. The vendor can use that information to troubleshoot their code. And please do tell them that you’ve used Driver Verifier, and which settings you have used!
Ow yeah, don’t forget to disable the Driver Verifier once you are done troubleshooting! Else it will remain active in the background… and again, you will experience performance loss.

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:

As you can see, the “Create Standard Settings” option is selected by default, and in most cases this option is the best way to start. When you use this option, the Driver Verifier selects a “Standard set of driver verification” options.

If you later decide that you want to perform more specific tests, you can select the “Create Custom Settings” option, which will display all the available driver verification options and allow you to select the ones that you want to employ.
I future posts I will go into those custom settings in more detail…

As I mentioned, you will have to disable the Driver Verifier Manager once you are done troubleshooting. To do so, use the “Delete Existing Settings” option.

As its name implies, selecting the “Display Existing Settings” option will show the driver verification options that have been activated and will list the drivers being tested.

Using the Create Standard Settings option

Since the Create Standard Settings option is the most common way that you’ll use the Driver Verifier Manager, I’ll cover this option. In a future post I will tell you of using the Driver Verifier’s “Create Custom Settings” option. When you leave the default setting selected and click Next, you’ll be prompted to select the drivers that you want to test:
Unsigned drivers are most likely in some way causing the issue so the “Automatically Select Unsigned Drivers” option is selected by default and this setting will only show drivers that do not have a digital certificate provided by Microsoft. 

If you want to see all the drivers installed on the system and be able to pick and choose which ones to test, choose the “Select Driver Names From A List” option.

On my test system, I selected the “Automatically Select Unsigned Drivers” option and clicked Next.

To initiate the testing, I clicked “Finish” and was prompted to restart my system.

Again, when you’re done testing please disable the Driver Verifier settings in order not to experience performance issues caused by these settings!

Big fat note

Note that as of Windows 7 and Windows Server 2008 R2, the default Driver Verifier rules have been changed. Things a lot of programmers did in their drivers, may work… however perhaps for the same action there is a more elegant approach.
That’s why Microsoft has made the default rules of Driver Verifier in Windows 7 and Windows Server 2008 R2 more strict.

Therefor a lot of drivers will not pass the Driver Verifier test when you use the default rules in Windows 7 or Windows Server 2008 R2. Most vendors are rewriting their drivers to comply with the new stricter rules.

Contact the vendor of the driver for more details.

More information about Driver Verifier in Windows 7 can be found here: http://www.microsoft.com/whdc/devtools/tools/Win7DriverVer.mspx

This article is based on: http://blogs.techrepublic.com.com/window-on-windows/?p=827