Windows 2000 native printer drivers run in USER mode. However, in the course of installing and managing printer drivers for redirection on your Terminal Server, it may be necessary—and it is possible—to run Windows NT 4.0-style KERNEL-mode printer drivers on your server. This situation highlights an important difference between Windows 2000 drivers and Windows NT 4.0’s architecture for printer drivers. This section explains how this potential error condition can affect your server.
From a user perspective, both KERNEL-mode and USER-mode drivers look and operate the same. Only the symptoms from potential failures differ.
In Windows NT 4.0, fatal errors in the KERNEL mode space are not allowed. When this does happen, it produces what is known as a STOP error, or a blue screen. As a result, the kernel halts all processing, displays debug information on a screen, and perhaps also writes the debug information to a file on disk. Depending on how your server is configured, the kernel either sits at this screen or reboots, which disconnects all clients and causes a loss of productivity.
Windows 2000’s driver architecture was changed to make printer driver code run in USER mode, where a fatal error results in the loss of the Spooler process space only. A failure in a Windows 2000 printer driver means that only printing functionality is lost. The server remains running without losing client data, other than the data that was being processed through the Spooler.
Most OEM-supplied drivers that caused blue-screen errors in Windows NT 4.0 have been fixed, and the updated versions are available on the vendors’ Web sites.
As a best practice, if you choose to use KERNEL-mode printer drivers, you should make every effort to obtain the latest versions from the manufacturer wherever possible.
You can distinguish Windows NT 4.0 style KERNEL-mode drivers from USER-mode drivers by checking the UI on the Drivers tab under File, Server Properties in the Printers folder.
On this tab, Windows NT 4.0 drivers are listed with the following version:
“Windows NT 4.0 or Windows 2000”
Native Windows 2000 USER-mode drivers are displayed with the following version:
You should identify a KERNEL-mode driver vs. a USER-mode driver before you decide whether to run these drivers in your TS implementation or audit existing servers in your TS implementation.
Managing pools of drivers between TS servers in a farm
In a farm of Terminal Servers, you might have a large pool of clients with heterogeneous OS versions and a wide variety of client-side printers. If your client base is Windows 2000, your job is simple, because any in-box printer driver on the client side already exists on the server, in DRIVER.CAB. This file redirects any incoming client that uses a Microsoft-supplied driver when needed.
When you have mixed OSs and printer hardware, as in the HP DeskJet 722c scenario, you must investigate driver issues more thoroughly. In a farm with multiple nodes, this problem can affect many different server machines.
To manage the OEM printer drivers on the servers in your Terminal Server deployments, you can use Print Migrator. This tool allows you to create a .CAB file containing an image of all installed printer drivers on one server. The .CAB file can then be loaded on all Terminal Servers in the enterprise or the farm. Using Print Migrator ensures that consistent versions of OEM drivers are installed.
http://www.microsoft.com/windows2000/technologies/fileandprint/print/download.asp For more information, consult the accompanying README available on this download page.
Performance and scalability
Terminal Servers that perform a great deal of printer redirection will see loads applied in two distinct areas:
Server side memory/CPU
To understand how this load increases as the number of clients and complexity of jobs increases, use the following guidelines. These guidelines were established from tests to help you understand how these variables affect the scale of networks and servers for your particular implementation.
The following table displays the bandwidth performance results:
Time to Print
Time to Print Job
Pages per Minute
56 K Modem
56 K Modem
56 K Modem
56 K Modem
Explanation of Bandwidth Performance Results
The differences in rendering size on the server compared to the resulting client-side size underscore the need to plan for sufficient disk space for the Spooler folder on the Terminal Server. By default, this location exists in the following path:
This path resides on the same partition as the OS. If the OS is on a small partition, this can affect redirected printing, especially if disk space is exhausted under heavy load. You can move the Spooler folder location to another folder, or to a partition on another drive set. To change the location, open the Printers folder on the Terminal Server, choose File, Server Properties, and then choose the Advanced tab. This global setting applies to all queues on the server, including redirected queues.
Job sizes written to the Spooler folder on the server side are based primarily on the contents of the job. As the results show, large and complex PDF and Word documents that contain a great deal of text formatting and many bitmap images can swell the job to a size many times larger than the original file size.
The results emphasize that if you pause the server-side print queue and spool a print job, the job can appear very large when compared to other versions of the OS or when spooling the same job or document on the client side. This is because the spooled job on the server is written to disk in enhanced metafile (EMF) format and has not finished rendering to RAW (ready to print) format for transmission across the Virtual Channel down to the client.
Note: Do not use paused job sizes on the server side as a measure of how much data will be transmitted over the wire for a given print job. This measurement is not accurate, as demonstrated by the rendered size at the client.
The conversion of the spool files to RAW format requires additional memory and CPU resources. Most of the CPU load during these tests was seen within the printing applications themselves, with a negligible bump in Spooler usage. For more information about CPU loads, see Scalability Performance Results.
The results demonstrate that wire speed is a big part of the equation in terms of output speed on the client-side printer. In low-bandwith situations, further optimizations of output speed may be obtained by reducing client-side session screen depth, as well as eliminating any other unnecessary wire traffic over the slow link between client and server.