Chapter 2 - Printing
By using Windows NT Server as your network print server, you have a seamless way to print, no matter what operating systems your networked computers use. If your workstation computers are running Windows NT 4.0, network printing is as easy as "point and print." For Windows NT and Windows 95 workstation computers, you don't need to install a printer driver manually on the workstation computer before printing with Windows NT. Print resources seem to be provided automatically from each application.
Note Although you can certainly print locally from a Windows NT Server print server, this chapter concerns itself primarily with remote printing and regards the Windows NT Server as a dedicated print server. For information about printing locally from a print server, see the Windows NT 4.0 Workstation Online Resource Guide.
This chapter begins with a glossary of terms used throughout the rest of the chapter. The glossary is followed by an overview of the Windows NT printing process and the flow of control. After you have a clear picture of the printing process and are comfortable with the terms, you can move on to read in-depth descriptions of each component of the printing architecture based on the network protocols and operating systems of your networked computers. The chapter concludes with sections on print security, troubleshooting, and some common questions and answers.
For additional information about printing with Windows NT Server or Windows NT Workstation, refer to the following documentation.
Glossary of Printing Terms
A print device is the actual hardware device that produces printed output—what you call a "printer" in casual conversation.
Print-device resolution is measured in dots per inch (DPI). The higher the DPI, the finer the resolution.
A printer, or logical printer, is the software interface between the operating system and print device. The printer determines how the document gets to the printing devices (for example, by means of a local port or to a remote print share) and to other parameters of the printing process. A single printer can send print jobs to multiple print devices, and multiple printers can send jobs to a single print device. For more detail about printers and print devices, see "Planning How Users Access Printers" in Microsoft Windows NT Server Concepts and Planninge. In the NetWare and OS/2 environments, this software interface is called a queue.
In Windows NT terminology, a queue is a group of documents waiting to be printed.
Print jobs are source code that contain both data and commands for print processing.
Print jobs are classified into data types based on what modifications, if any, the spooler must make to the job for it to print correctly. For example, one data type requires no modifications, whereas another data type requires the addition of a form feed to the end of the job.
The print spooler is a collection of dynamic-link libraries (DLLs) that receives, processes, schedules, and distributes print jobs.
Spooling is only one of the processes performed by the spooler. Spooling is the process of writing the contents of a print job to a file on disk. This file is called a spool file. In the event of power loss during printing, the spool file prevents loss of data so the print job can resume once power is restored. Despooling means reading the contents from a spool file and sending those contents to a print device.
Rendering means creating a print job. An application calls the graphics device interface (GDI). GDI takes the document information sent by the application, calls the printer driver associated with the target print device, and creates a print job in the printer language of the print device. The print device has "firmware" that interprets the submitted printer language and creates a bitmap for each page.
A print server is the computer that connects one or more print devices to the network and shares them with other networked computers. A print server can also be a special hardware device that connects a print device to the network with a net tap on one side and a parallel or serial port on the other side.
Although a Windows NT Workstation can function as a print server, and a Windows NT Server can function as a print client, this chapter considers the print server to be a Windows NT Server. For information about using a Windows NT Workstation as a peer-to-peer print server for a small LAN (10 or fewer connections), see the Windows NT 4.0 Workstation Online Resource Guide.
A downlevel server is a print server running a Windows product that is not Windows NT 4.0—for example, Windows for Workgroups or Windows NT 3.x.
Creating a printer means connecting to the print device, either over the network or over a serial or parallel port, naming the printer, and installing the printer driver. To create a printer, run the Add Printer wizard, and click the My Computer option. You'll be asked to install the printer driver and specify a port.
Connecting to a printer means connecting to the share on the computer that created the printer. To connect to a printer, run the Add Printer wizard, and click the Network printer option. You won't be required to install the printer driver. Only Windows NT and Windows 95 clients can "connect to" a printer shared out by a Windows NT 4.0 print server.
A print client is the computer that sends print jobs over the network to the print server. Print clients are sometimes also called client computers.
A client application is any application that creates a print job. The client can be an application on the print server or on a client computer on the network.
Network-interface printers are print devices connected directly to the network by means of their own network cards.
Print server services are software modules on the print server that receive print jobs and determine if the spooler should alter them. Different print server services support print jobs from various clients. For example, Services for Macintosh (SFMSRV) supports print jobs from Macintosh clients.
Printer drivers are software programs that enable applications to communicate fully and properly with print devices. Each print device can require unique codes and commnds to make available its special features, such as two-sided printing or custom paper sizes.
Anything described as local means that it exists on the same computer. For example, a print client seeks a printer driver locally (on the same computer) before downloading the driver from the print server.
Overview of the Printing Process
In the following overview of remote printing, Windows NT 4.0 Server is considered to be the print server. Some processes, or the software components that perform them, are slightly different for non-Windows NT print clients. For more details about different print clients, see "Print Clients" later in this chapter.
Figure 2.1 Windows NT Remote Printing Process
Print jobs are not simply data: They are source code that contains both data and the commands for processing the data. The client application (with the graphics engine and the printer driver) creates print jobs. For example, Microsoft Word 7.0 combines data objects such as text, fonts, and graphics with information from a printer driver to create source code for a document—the print job.
Because each type of print client (for example, UNIX clients and Windows NT clients) creates print jobs a little differently, a variety of print server services are required to receive and prepare the jobs. Some print server services assign print jobs a data type, which tells the spooler whether and how to modify the print job in order to print correctly. Some services leave the data type blank (in which case the default data type in the Print Processor dialog box on the print server is assigned).
If you create a printer, the default data type is EMF (if the printer is a PCL printer) or RAW (if the printer is Adobe PostScript). To change the default data type, use the following procedure:
To change the default data type for a printer you have created
The following sections describe the different data types.
Print jobs from Windows NT 4.0 clients are enhanced metafiles (EMF). Instead of the RAW printer data being generated by the printer driver, EMF information is generated by the Graphical Device Interface (GDI) before spooling. After the EMF is created, control is returned to the user, and the EMF is interpreted in the background on a 32-bit printing subsystem spooler thread and sent to the printer driver.
EMF files are more portable than RAW files. An EMF file can be printed on any print device, whereas a RAW file can be printed to only one print device model. In addition, the set of EMF files that represent all pages in a print job are typically smaller than a RAW file that contains the same print job.
The first portion of the print job's rendering is done on the client computer. The last portion is rendered on the print server. This is especially helpful when the print job is a very large file, because the client application is not tied up for the entire rendering time. This data type also ensures that fonts specified on the client computer are the same ones used by the print server.
The RAW data type tells the spooler not to alter the job at all—that the print job is ready to print as is. Most jobs from downlevel Windows clients are the RAW data type.
RAW [FF Appended]
This data type tells the spooler to assume the job is from an application that does not append a form-feed character (0x0C) to the end of each job. Without a trailing form-feed, the last page of the job does not print when sent to a PCL print device. The spooler appends a form-feed character to the end of the print job but makes no other alterations. None of the print server services supplied with Windows NT assign this data type, but you can set the default data type Print Processor dialog box to this type so that it affects jobs from Windows Network clients.
RAW [FF Auto]
This data type is similar to the RAW [FF Appended] data type, but RAW [FF Auto] tells the spooler to check for a form-feed character at the end of the job. It does not add a form feed if one is already present, and it makes no other alterations. None of the print server services supplied with Windows NT assign this data type, but you can set the default data type Print Processor dialog box to this type so that it affects jobs from Windows network clients.
The TEXT data type tells the spooler that the job consists of ANSI text. The spooler uses the current print device driver to create a new print job that prints the text of the original job using the print device's factory default font, form, orientation, and resolution listed in the Document Properties dialog box. This is useful when the print job consists of simple text and the target print device (for example, a PostScript printer) cannot interpret simple text jobs.
Text files consist of numeric values from 0 to 255, where each value is mapped to a particular character or symbol. Several character-mapping schemes (character sets) are in common use, and text files contain no indication of which character set to use when displaying or printing the file. The TEXT data type assumes the ANSI character set, so it might print some characters incorrectly if the application that created the job does not use the ANSI character set. Most character sets are identical for the values 0 through 127, so this problem usually affects extended characters (those with values from 128 through 255).
The following table shows five examples in which common character sets use different numbers to represent the same character. The PC-850 character set is commonly used by MS-DOS®-based applications in Europe; ANSI is used by Windows-based applications; PC-437 is commonly used by MS-DOS-based applications in the United States; Roman-8 is the default PCL character set.
This data type indicates that the print job consists of PostScript code from a Macintosh client and that the target printer is a non-PostScript print device. The spooler interprets the PostScript code and creates a bitmap of the page. GDI32 and the printer driver can convert the bitmap into the language of the target print device.
Print devices are the machines we call "printers." They produce hardcopy output by interpreting the printer language and creating a bitmap for each page.
Print devices have their own input and output channels; jobs can be directed to input channels such as parallel or serial cables or network adapters. Output can be produced on different media, including paper, film, or fabric.
Print devices have their own internal processors which can be proprietary or general-purpose (such as the Motorola 680xx-series chips in Apple LaserWriter devices). Incoming data is stored in the print-device RAM, which can range from a few bytes to a hundred megabytes. Each print device has software stored in ROM, called "firmware," which interprets the programming language of a print job's source code. Examples of programming languages are PostScript, PCL, and HP-GL/2.
Printer drivers are the software that enables an application to communicate with the variety of available print devices, regardless of the device type, model, or programming language interpreter.
In general, printer drivers are composed of three files that work together as a printer-driver unit:
These three files work as a unit. For example, when you set up and configure a new printer, the interface driver queries the characterization data file and then displays the available choices. Then, when you print, the graphics driver queries the interface driver about your selections so that it can create the proper printer commands.
Printer drivers are generally not binary-compatible across hardware-processor platforms. Consequently, printer drivers must be installed on the Windows NT print server for each Windows NT client hardware platform. For example, when x86-based clients running Windows NT Workstation are served for printing by a Alpha AXP-based Windows NT Server, you must install x86-based printer drivers on the Alpha AXP-based print server.
The Windows NT and Windows 95 print client first attempts to use a local printer driver. If none is available, the Windows NT print server downloads the printer driver to the client computer's hard disk. The client application then uses its copy to create the print job.
In previous versions of Windows NT, printer drivers ran in user mode. With Windows NT 4.0, printer drivers run in kernel mode, thus reducing memory requirements and improving performance. For more information about user and kernel modes, see Chapter 5 "Windows NT Workstation Architecture," in the Windows NT Workstation Resource Guide.
Note Print clients running Windows NT 4.0 won't be able to use printer drivers downloaded from a print server running an earlier version of Windows NT. You'll need to make sure that the client computer has the 4.0 printer drivers, or better yet, use 4.0 on your print servers. A print server running Windows NT 4.0 can supply earlier version printer drivers to downlevel Windows print clients, if necessary.
Platform-specific printer drivers are available for the following:
Print devices can be classified as one of three types: raster, PostScript, or plotter. To support these three classes of print devices, Windows NT provides the following generic printer drivers:
Universal Printer Driver
The Universal printer driver (Unidriver) is sometimes referred to as the raster driver because it supports raster graphics printing. The Unidriver can carry out requests on most types of printers. Each print device vendor provides a device-specific minidriver (called a characterization file) that works with the Unidriver to communicate with its print devices.
This driver includes support for 24-bit color, scaleable TrueType fonts, device fonts, compression-run length encoding (RLE), and Tag Image File Format (TIFF) version 4.0. It also includes mechanisms that provide for smaller, more efficient bitmaps. These mechanisms include ignoring whitespace and supporting rules. (Hewlett-Packard LaserJet and compatible print devices use rules to print repeating elements on a page—such as bullets in a list—by repeating the information from a single bit of source code.)
The Universal printer driver consists of the following component files:
The Windows NT Universal driver is a generic, text only (TTY) driver. It prints only text, and it prints it in the native font of the print device, regardless of any formatting in the original document.
PostScript Printer Driver
The Windows NT PostScript driver uses Adobe version 4.2-compatible PostScript printer description (.ppd) files. (Windows NT does not use the .wpd or .mpd files used by Windows 3.1). This driver supports key features, including binary transfer compression from Level II, resolution, and paper source.
The component files of the Windows NT PostScript printer driver are as follows:
Note PPD files are the only printer driver files that are generally binary-compatible across processors and platforms.
HP-GL/2 Plotter Printer Driver
The Windows NT plotter driver supports a variety of plotters that use the HP-GL/2 language. Windows NT does not support HP-GL. The output from the Windows NT plotter driver requires a plotting device that can process all of the enhancements built into the HP-GL/2 language.
The Windows NT plotter driver consists of the following component files.
With Windows NT 4.0 you can establish printers with the Add Printer wizard or by using Point and Print.
Windows NT 4.0 provides the Printers folder to manage printing. Within it, the Add Printer wizard simplifies the task of establishing printers You can open the Printers folder in the following ways:
To establish a printer with the Add Printer wizard
To install a printer using Point and Print
Creating vs. Connecting to a Printer
The method used to establish a printer on a client computer dictates the configuration of the client computer in relation to the printer. The following table details the various methods.
Notice that only Windows NT and Windows 95 client computers can actually "connect to" a network printer served by a Windows NT print server. When a Windows NT or Windows 95 print client initiates a print request, the required printer driver is downloaded from the Windows NT print server if it is not already on the client's hard disk. All other client computers must "create" the printer—that is, they must install the printer driver directly on their hard disks, specify a port, name the printer, and so on.
Windows NT and Windows 95 print clients can also create a remote printer served by a Windows NT print server. Each method has advantages and disadvantages. Connecting to a remote printer is easier and faster than creating one. If the Windows NT client has connected to a printer, the print job doesn't spool on the client machine, so no spool options are available. (Windows 95 clients always spool locally and again remotely.) The "connected" client also cannot queue print jobs locally. Creating a printer gives the user more control, but that control is not always needed.
Specifying Virtual Printer Memory
You can change the amount of virtual memory that your PostScript printer has available for storing fonts. The PostScript driver uses a default setting recommended by the printer manufacturer for virtual memory.
To determine the right value, copy the Testps.txt file (supplied with the Windows NT Resource Kit) to the printer, and use the recommended virtual memory value printed on the resulting page.
To change your PostScript printer's virtual memory
Print clients send print jobs to a Windows NT print server. The print server services or the spooler receive the print job as an input/output (IO) request that must be directed to the appropriate system process.
Each print server service uses different logic to determine how the job should be altered. The following sections describe protocols, general architecture, and process logic for each of the following types of print client:
All Windows print clients receive printer alerts confirming successful prints or indicating errors. To disable printer alerts on a specific machine, add the following entry to that computer's [Network] section of the System.ini file:
Note Disabling WinPopup does not disable printer alerts.
Windows NT Network Clients
Windows NT network clients can use any of the following network protocols to send print jobs to a Windows NT Server print server:
If the Windows NT client computer connects to a printer, it sends print jobs to the server by making remote procedure calls from the client's print router to the server's print router. If the client created the printer, the print server service handles delivery of the print job.
Windows NT print clients now use enhanced metafile (EMF) data type instead of RAW. EMF allows the print job to be spooled to the server and rendered at the server into the appropriate print format. Remote rendering significantly speeds up the client computer's return to task.
Windows NT network clients need not worry about printer drivers, because if the client doesn't have a needed driver, it is automatically installed on the client's hard disk from the Windows NT server when the client begins its print operation. If, however, the client computer is running Windows NT 4.0 and the server is running an earlier version, the printer drivers won't work. A Windows NT 4.0 print server can supply earlier version of printer drivers where necessary, but a Windows NT 4.0 client cannot use earlier versions of printer driver.
Windows 95 Network Clients
Windows 95 print clients send print jobs to a Windows NT print server by using one of the following MS Network client redirectors:
The MS-Network redirectors send jobs by using the following protocols:
Windows 95 generates EMF data type, which always spools locally. Spool files are played back locally to generate RAW data type before being sent to the print server. The print server spools the RAW file again.
The Windows NT print server receives print jobs from Windows 95 clients through the Windows NT Server service.
16-bit Windows Network Clients
There is little difference between the different versions of the 16-bit Windows platforms. They all support printing from MS-DOS-based applications and from Windows-based applications by using the 16-bit printer driver installed on the computer. They typically send jobs to a Windows NT print server by using one of the following MS Network client redirectors:
The MS-Network redirectors send jobs by using the following protocols:
The Windows NT print server receives the job through the Windows NT Server service, which typically does not alter the print job. 16-bit Windows clients might also run third-party software for sending jobs to other print servers, such as LPR software for sending print jobs to UNIX print servers. This software is often able to send jobs to Windows NT as well.
MS-DOS Network Clients
MS-DOS clients usually use an MS Network client redirector to send print jobs to Windows NT print servers. They typically use the NetBEUI or TCP/IP protocol, but they might also print with third-party software (such as an LPR utility). Some MS-DOS-based applications create print jobs that contain only ASCII text. Unlike Windows clients that share the same driver for a particular print device, those MS-DOS-based client applications contain an internal version of the driver for each specific print device. This internal driver might not be the correct version of the driver. Often you can modify the driver and printer settings within the MS-DOS-based application or by using an accompanying utility. Check the documentation for the application or utility.
MS-DOS-based applications might not be network-aware, meaning that the application does not allow for a network redirector to forward the print job over the network to a print server. Some network-unaware applications try to print by directly dictating to the parallel port hardware, or they might rely on MS-DOS to control printing and be unable to print correctly to a network print server. Other network-unaware applications assume that they have exclusive control of the printer and therefore don't properly terminate their print jobs. As a result, nothing else prints until the application terminates. You might need to consider upgrading to a network-aware application in order to print over the network.
Windows NT supports UNIX printing clients by providing the TCP/IP Print Server (LPD) service. This service can receive print jobs from UNIX systems or other operating systems—including Windows NT—that have LPR client software. The client software must support RFC 1179. This is problematic, because many systems do not support this specification. Others that claim to support it do not implement it entirely, or they supply private extensions to the specification that their users have come to rely on but that don't exist except on that system. For more information about how to correct problems printing from systems that don't comply with RFC 1179, see "Line Printer Monitor (Lpdmon.dll)" later in this chapter.
The LPR protocol does not pass detailed error status information back to the LPR client. If anything goes wrong, from severe problems (such as the server being too busy to process requests) to print device problems (such as running out of paper), the LPR protocol reports the same error condition.
NetWare clients use IPX/SPX-compatible transport to send print jobs over the network to the Windows NT print server. The server must have installed Microsoft File and Print Services for NetWare. This utility, which is a separate product from Windows NT, enables the NetWare client to see the Windows NT printers as print queues.
Macintosh clients send jobs over AppleTalk to a Windows NT print server. To the Macintosh client, the Windows NT computer looks like another AppleTalk device in a zone—either an AppleShare print server or a standalone print device. On the Windows NT Server computer, the SFMSRV receives the jobs. For more information about SFMSRV see, "Services for Macintosh Service" later in this chapter, and "Services for Macintosh Print Processor (SFMPSPRT)" and "Macintosh Port Monitor (SFMMON)" later in this chapter.
Print Server Services
Print server services are the software on the Windows NT print server that receive print jobs from specific types of network clients, determine whether the spooler should alter them, and then send them to the spooler by calling the spooler application program interface (API).
Each print server service uses different programmatic logic and makes different assumptions about print jobs from its supported print clients. These differences are detailed in the sections describing each service.
Windows NT Server provides the following print server services:
In addition, other print services may be installed, such as:
The following table lists each print server service and the type of print client processed by the service.
Windows NT Server Service
The Windows NT Server service receives jobs from applications and computers that are using the MS Network client and NetBIOS redirectors. This includes print clients using any of the following:
The Windows NT Server service does not set the data-type value when it submits the print job to the spooler. Instead, the spooler uses the default data type specified in the Print Processor dialog box on the print server. You can change the default data type. For more information, see "Data Types" earlier in this chapter.
Note If you select EMF or PSCRIPT1, the print spooler ignores this data and instead uses the RAW data type to process print jobs. Detailed information on print spooler processing of data types is provided later in this chapter in the "Print Processors" section.
TCP/IP Print Service (LPD)
The TCP/IP Print service is generally referred to as LPD, which stands for line printer daemon (or "service"). LPD receives print jobs from line printer remote (LPR) clients. LPR clients are often on UNIX systems, but LPR software exists for most operating systems, including Windows NT.
LPR is one of the network protocols in the TCP/IP protocol suite. It was originally developed as a standard for transmitting print jobs between computers running Berkeley UNIX. The LPR standard is published as Request For Comment (RFC) 1179. Previous versions of Windows NT supported TCP/IP printing as documented in RFC 1179, which describes an existing print server protocol widely used on the Internet for communicating between line printer daemons but does not specify an Internet standard. Different implementations support different options.
Windows NT 4.0 has added enhancements to support the most popular and requested options. Windows NT now suppots multiple data files per control file, and when used in "print through" mode as an intermediate spooler, it correctly passes the hostname parameter through the Windows printing subsystem. Windows NT 3.5x sent all TCP/IP print jobs from Windows NT computers from TCP ports 721 through 731. If enough jobs were sent in quick succession the ports could become a bottleneck causing a delay. For Windows NT 4.0 LPR print jobs are sourced from any available reserved port between 512 and 1023.
The LPR protocol does not pass detailed error status information back to the LPR client. If anything goes wrong, from severe problems (such as the server being too busy to process requests) to print-device problems (such as running out of paper), the LPR protocol reports the same error condition.
LPD receives jobs from LPR clients and submits them to the spooler. LPR clients always send a "control file" (actually, a data structure within the print job) containing administrative information with each print job. LPD assigns a data type based on the control commands in that control file.
If the client sends the f, o, or p control command, the LPD assigns the TEXT data type to the print job—which tells the spooler to edit the job to make sure it prints. If the client sends the l control command, the LPD assigns the RAW data type to the print job—which tells the spooler the print job needs no editing to print correctly. For more detail about data types, see "Data Types" earlier in this chapter.
Control commands are documented in the LPR specification, Request For Comment (RFC)1179, sections 7.17 through 7.29. For detailed information about RFC 1179, refer to the Windows NT Knowledge Base article, "Text of RFC1179 Standard for Windows NT TCP/IP Printing," reference number 124734.
Note Notice that all the control commands defined in RFC 1179 are case sensitive. Notice also that many printer languages, including PCL, rely heavily on the ESC control character, which the f control command causes to be filtered from the print job. Do not use the f control command when sending print jobs that contain printer commands.
Because LPD assigns a data type explicitly, the default data type found in the Print Processor dialog box has no effect on print jobs received by LPD. To change the behavior of LPD, you must reconfigure the LPR client application to send a different control command with the print job. To reconfigure a LPR client application, consult the documentation for the application.
File and Print Services for NetWare
Microsoft File and Print Services for NetWare (FPNW) is a Windows NT Server utility that makes Windows NT Server look like a NetWare 3.x-compatible file and print server to computers running NetWare client software. Windows NT Server integrates into NetWare environments with IPX/SPX Compatible Transport.
Using FPNW, NetWare clients can print to printers attached to Windows NT print servers or to NetWare-compatible printers attached directly to the network. The Windows NT printers appear as print queues on a NetWare network. To create printers, the NetWare client should select LPT1 port for a printer attached to the Windows NT print server. For a network-attached printer, the clients selects either NetWare_Pserver_0 or NetWare_Pserver_1 port.
Services for Macintosh Service
The Services For Macintosh service (SFMSRV) receives print jobs from Macintosh clients. From the client's perspective, a printer shared through this service looks just like a share on an AppleShare server or a stand-alone AppleTalk print device.
The SFMSRV assigns the RAW data type to all jobs targeted to PostScript printers and also assigns the PSCRIPT1 data type to all jobs targeted for non-PostScript print devices. For additional information about processing of Macintosh print jobs, refer to the section "Services for Macintosh Print Processor (SFMPSPRT)" later in this chapter.
The preceding sections described network print clients, print server services, print jobs, data types, and print devices. These are entities at the beginning and end of the printing process. The following sections describe the Windows NT print spooler components and the processing that takes place on a Windows NT print server after the print job is created and before the print job reaches the print device.
The following figure shows the main spooler components used to process jobs on a Windows NT print server. Each component uses the services of the component directly below it.
Figure 2.2 Print Spooler Components
As shown in the figure, the components below the client and above the print device are collectively called the spooler. The spooler is a series of 32-bit virtual device drivers and DLLs consolidated into a single architecture. It provides smooth background printing by using background thread processing. This means that the spooler passes data to the printer only when the printer is ready to receive more information. In Windows NT, the spooler components are implemented as a service that you can stop and restart from the Services icon on the Control Panel or from the command line by using the Net Stop Spooler and Net Start Spooler commands.
Important If you stop the spooler service, you will not be able to print until you start it again.
The spooler components reside on both the Windows NT print server and on the Windows NT client computer. Client computers running a different operating system might have different components, and they might interact differently with the Windows NT print server's spooler components. The following table lists the components of the Windows NT spooler:
Each spooler component is described in more detail in the following sections.
When a Windows NT application has a print job it wants to send to the printer, it communicates with the client side of the spooler (Winspool.drv). This file makes an RPC to the server side of the spooler (Spoolss.exe), which makes a direct API call to the router (Spoolss.dll—which is also on the server side of the spooler).
The router passes control of the print job to the appropriate print provider. In the case of local printing, the local print provider takes the print job. If the print job is going to a server on the network, the router passes the print job to the appropriate remote print provider—the Windows remote print provider or the Novell NetWare print provider.
Do not confuse the software router component of the Windows NT spooler with the physical hardware router used in networks.
Remote Print Providers
When a client computer connects to a remote printer and sends a print job to it, the router polls each remote print provider on the client computer. The router passes control of the print job to the first remote print provider that recognizes the printer name.
Windows NT supplies the following remote print providers:
Note Neither of these remote print providers performs spooling.
Windows Network Print Provider
If the local copy of the Windows network print provider, Win32spl.dll, recognizes the printer name, it performs additional processing based on the type of print server to which the job is going. If the print server is running Windows NT, Win32spl.dll makes remote procedure calls to the router (Spoolss.dll) on the print server. The router receives the print job over the network and passes it to the local print provider as if one of its own local clients had submitted it.
If the remote print server is a downlevel server, Win32spl.dll sends a message to the Windows NT NetBIOS redirector. The redirector forwards the job over the network to the downlevel server.
The functions provided by the Windows network print provider are illustrated in the following figure.
Figure 2.3 The Windows Network Print Provider (Win32spl.dll)
Novell NetWare Remote Print Provider
If the NetWare print provider (Nwprovau.dll) recognizes the printer name when polled by the router, it takes control of the print job. The NetWare print provider sends a message to the NetWare workstation service (Nwwks.dll), which in turn passes control to the NetWare redirector. The NetWare redirector transmits the print job over the network to the NetWare print server.
Note To send print jobs over Windows NT to a NetWare print server, you must install Gateway Services for NetWare. To receive print jobs from NetWare print clients, you must install File and Print Services for NetWare.
Figure 2.4 The NetWare Print Provider (Nwprovau.dll)
Local Print Provider (Localspl.dll)
The local print provider writes the print job contents to a spool (.spl) file and tracks administrative information (such as user name, document name, and data type) in a shadow (.shd) file. By default, both files are written to %systemroot%\SYSTEM32\SPOOL\PRINTERS.
If, however, the hard drive partition containing Windows NT Server doesn't have sufficient disk space to accommodate the spool files, you can change the location of spool files by changing the server properties.
To change the location of spool files
Note You must create a directory for the new spool file location. If you attempt to spool directly to the root (C:\ or D:\, for example) the spool file will revert to the default spool directory.
Spooling a print job to a file protects the print job by saving it on disk. Should the print server suffer a power failure or other serious event before printing all jobs in the queue, the spool and shadow files on the server's hard disk preserve each job and prevent any loss of data once processing resumes.
By default, spool and shadow files are deleted after the job prints. However, you can enable spooler event logging to get valuable information about printer traffic, hard disk space, and other printing maintenance issues.
To enable spooler event logging
Next, LOCALSPL polls the installed print processors (such as Winprint.dll and Sfmpsprt.dll) to see if one of them recognizes the job's data type set. If the data type is not set, the Winprint.dll print processor receives the job and uses the default data-type set Print Processor dialog box on the print server.
You can set a new default location or override the default location on a printer-by-printer basis by manually editing the Registry. However, before doing so, read the "Spool File Security" section later in this chapter.
Enhanced Metafile (EMF) Spool Files
Enhanced metafiles (EMF) are one type of spool file used by the default Windows NT print spooler. EMF spool files reduce the time between the initiation of a print request and when control is returned back to the operating system. This is done by storing only the GDI function calls that produce the graphic object the application wants printed. The much more time-consuming execution of function calls can then be carried out later, in the background, when the spool file is "played back."
The way EMF spool files are encoded also provides the advantage of printer device-independence. In other words, a picture measuring 2 inches by 4 inches on a VGA display and stored in an EMF maintains those original dimensions whether it is printed on a 300 dpi laser printer or on a 75 dpi dot matrix printer.
RAW Spool Files
If the print job's data type is RAW, the spool file's data type is RAW. These files are device-dependent. The spooled data is destined and formatted for a particular device and does not need to be printable on a different device. An example of a RAW spool file is an encapsulated PostScript (EPS) file, which is formatted to be understood by the PostScript printer for which it is destined, but which is just RAW data to the Windows NT spooler.
A print processor works in conjunction with a printer driver to despool the spooled print jobs during print spool file playback.
Print processors are the components that make necessary alterations to print jobs, based on the data type of the print job. A print processor might recognize only one data type, or it might recognize several data types. Windows NT supplies the following print processors:
A print device vendor might develop a custom print processors if:
Additional print processors can be supplied by third-party software vendors to support custom data types.
Windows Print Processor (Winprint.dll)
This print processor supports five data types: EMF, RAW, RAW [FF Auto], RAW [FF Appended], and TEXT. For a detailed description of each data type, see "Data Types" earlier in this chapter.
Services for Macintosh Print Processor (Sfmpsprt.dll)
This print processor is available only with Windows NT Advanced Server version 3.1 or Windows NT Server version 3.5, 3.51, and 4.0. By default, this print processor (SFMPSPRT) is installed only when Services For Macintosh is installed on the Windows NT Server computer.
SFMPSPRT supports the PSCRIPT1 data type. This data type indicates that the job is Level 1 PostScript code from a Macintosh client, but the target printer is not a PostScript printer. The spooler sends the PostScript code through a Microsoft TrueImage® raster image processor (RIP), supplied with Services for Macintosh. The raster image processor creates a series of one-page, monochrome bitmaps at a maximum of 300 DPI. The Windows NT print spooler sends the rasterized images, or bitmaps, to the print driver for the target printer. The print driver returns a job that prints the bitmaps on the page.
Because the RIP bitmaps are monochrome (black and white) and not more than 300 DPI, the target printer driver produces final output that is monochrome and not more than 300 DPI, even if the target printer driver supports color or higher resolutions. The restrictions are in the RIP software itself, not in the Windows NT printer drivers.
Several third-party Win32® RIP packages are commercially available for Windows NT version 3.1 and above for those who need a higher-end RIP.
Windows NT 4.0 supports two kinds of print monitors: language monitors and port monitors.
A language monitor is necessary to support bi-directional print devices. A bi-directional print device supports two-way communication between the print device and the spooler running on its print server. The language monitor allows the spooler to configure and monitor the status of a bi-directional printer. A language monitor can also add data (such as printer control information) to the print stream. When you create a printer, you install a printer driver. If a language monitor is associated with that printer driver, all data that flows from the printer driver to the print device goes through the language monitor before it goes through the port monitor and out to the printer.
Two-way communication between computer and print device allows a system administrator to configure the printer and to monitor printer status. The spooler running on the computer can request configuration and status information from the printer, and the printer can send unsolicited status information to the computer (such as the fact that the paper tray is empty). A common language is necessary for the two devices to understand each other.
The language monitor supplied with Windows NT 4.0 uses Printer Job Language (PJL). If a print-device vendor uses a printer language other than PJL, that vendor can develop a language monitor for it. A vendor might also develop a language monitor to add data, such as printer-specific control information, to the print stream going to a single directional printer.
Port monitors control the I/O port to which the physical print device is connected. The local print monitor executable (Localmon.dll) supplied by Microsoft controls parallel and serial I/O ports that may have a print device connected to them. Print devices connected to different types of I/O ports such as SCSI or Ethernet ports on a network card or adapter, are controlled by vendor-developed port monitors.
The print monitors supplied with Windows NT are described in the following sections.
The Ports tab of the Printer Properties dialog box lists the default Windows NT ports.
By default, the list includes only standard ports controlled by the local print monitor, Localmon.dll. When you want to print over other communications channels (to a network-attached printer, for example), you must create a new port.
To create a new port
Print monitors often depend on other software components and appear in this list only when you have installed the components they require. For example, the Hewlett-Packard Network print monitor transmits print jobs by using the DLC network protocol. This monitor appears in the list only if you have installed the DLC protocol.
Each monitor displays its own user interface, which you use to create a new port and configure a printer to use it. To reconfigure the new port (if the monitor allows reconfiguration), click the Configure Port button on the Ports tab of the Printer Properties dialog box.
When you read about each print monitor in the following sections, remember that each is associated with a data communications channel, not with the print device at the other end of that channel. In most cases, the port monitor is unaware of the make or model of the print device it is communicating with, nor does it need this information. Also, although different port monitors might use the same network protocol, this does not make them interchangeable. For example, both the Digital Network Port print monitor and the LPR Port print monitor use the TCP/IP protocol, but they send data over that protocol in very different ways.
Local Print Monitor (Localmon.dll)
The local print monitor, Localmon.dll, sends print jobs to local devices. These include familiar ports like LPT1 and COM1. Use of the less familiar FILE and Other ports are described below.
The FILE port appears in the default port list on the Ports tab of the Printer Properties dialog box. When you send jobs to a printer that uses this port, the local print monitor prompts you for the name of a file in which the print job should be stored.
If you select Other from the list of ports in the Print To box on the Printer Properties dialog box, and select the Local Port option, the local print monitor prompts you to enter a port name. Some possibilities include:
Hewlett-Packard Network Port Print Monitor (Hpmon.dll)
The Hewlett-Packard Network print monitor, Hpmon.dll, sends print jobs to HP JetDirect adapters. This includes both the network adapters commonly installed in print devices (such as the LaserJet 4 Si) and the JetDirect device (which connects a parallel print device to the network).
Although many JetDirect devices can communicate over several different network protocols, including DLC, IPX, TCP/IP, and AppleTalk, Hpmon.dll is specific to DLC; you must load the DLC protocol to use this print monitor.
The DLC protocol is bridgeable, but not routable. This means that if a Windows NT print server is on one physical subnet and a JetDirect device is on another physical subnet, the server can send jobs to the JetDirect if the two subnets are joined by a bridge but cannot send jobs if the two subnets are joined by a router.
The DLC protocol can be bound to multiple network adapters, but the HP print monitor software can only manage printers over one network adapter, and it must be either adapter 0 or adapter 1. If your Windows NT computer has multiple network adapters, make sure all the HP JetDirect-equipped printers are on the same physical subnet.
When you install, reinstall, or upgrade Windows NT, it assigns a number to each network adapter in your computer. The adapter with the lowest I/O base address is assigned the number 0; the adapter with the next lowest I/O base address is assigned the number 1, and so on. If you later add another network adapter, it is assigned the next unused number, regardless of its I/O base address. Later, if you upgrade or reinstall Windows NT, each adapter is again assigned a number based on its I/O base address. If the third adapter has a lower I/O base address than either of the other two, then the numbering changes. In this case, HPMON looks for JetDirect cards through the wrong network adapter on the server.
To correct adapter numbering after an upgrade
You can configure ports managed by Hpmon.dll as either job-based or continuous connection. The setting affects all ports at once:
Note If you configure two Windows NT print servers to send jobs to the same JetDirect device, configure both servers for job-based connections. If you configure one of the print servers for continuous connection, it prevents the job-based server from connecting to the print device.
Line Printer Port Monitor (Lprmon.dll/Lpr.exe)
Windows NT supplies a command line utility (Lpr.exe) and the LPR Port print monitor (Lprmon.dll). Both act as clients sending print jobs to an LPD service running on another computer. As mentioned previously, Windows NT also supplies an LPD service, the TCP/IP Print service, which receives print jobs sent by LPR clients, including UNIX computers and other Windows NT computers using the TCP/IP protocol.
To send print jobs, the LPR clients needs the network address of the LPD print server and the name that the LPD service associates with its print device. LPR sends print jobs to LPD along with instruction on how to process the job and the name of the print device.
When you add an LPR port while connecting to the LPR print server, you'll be asked in a dialog box to supply information identifying the print server (host) and the name of the printer. You can supply either the IP address or the host name of the server. The server can be one of the following:
For example, let's say you're connecting to a printer named LABLASER on a UNIX computer whose IP address is 220.127.116.11, and whose name (defined in the hosts file on your Windows NT computer) is UNIXBOX. You can enter either "UNIXBOX" or "18.104.22.168" (without the quotation marks) in the Name Or Address Of Host Providing LPD box. You would enter LABLASER in the Name Of Printer On That Machine box.
To obtain the IP address of a network adapter, check the adapter's documentation. Some adapters provide a character-based application that you can access either by network connection or by directly connecting to the adapter by means of a serial-to-serial port cable.
If the server is a UNIX computer, and you don't know a valid name for the printer, you can often find it by looking at the /etc/printcap file on the UNIX computer. Each entry corresponds to a print queue ("printer" in Windows NT terminology) on the UNIX computer. Fields in these entries are separated by ":" characters, and for readability an entry can be broken over several lines by ending a line with a "\" character and beginning the next line with a space or tab character. The first field of each entry lists valid names for the queue, separated by "|" characters.
Continuing the LABLASER example, we might find entries like the following in the printcap file on the computer named UNIXBOX:
lp|lablaser|The_Lab_Printer:\ :lp=/dev/ttya:br#9600:\ :lf=/usr/spool/lpd/lablaser-err:\ :sd=/usr/spool/lpd/lablaser:
The first line in this example defines a print queue with three valid names: lp, lablaser, and The_Lab_Printer. You can use any of these names in the second field of the LPR Port dialog box previously shown.
Note This example is provided for illustrative purposes only. The UNIX system documentation is your best source of detailed information on your system's printcap file. Also note that the term "queue" is the UNIX term. Its Windows NT equivalent is "printer."
When the LPR Port print monitor receives the LPD server's network address and the proper queue name, it can send print jobs and processing instructions.
The LPR Port print monitor sends the l command by default, whereas the command line Lpr.exe utility sends the f command by default. With the Lpr.exe utility, use the -o command if you want to override the default on a job-by-job basis. To change the default command for a particular printer controlled by the LPR Port print monitor, you must modify a Registry parameter. Use the Registry Editor (Regedt32.exe) to find the following key:
HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Control \Print \Monitors LPRPort\Ports\<portname>\<IP Address or Host name>:<printer name>
In this key, add a value named PrintSwitch with type REG_SZ, and enter the control command you want to use. For instance, enter the letter "f" (without the quotation marks) if you want to use the f command by default.
Some UNIX computers do not follow the control commands alone when deciding how to process a print job. For instance, if you send an ASCII text file with an l command (which tells the spooler not to alter the print job) to a PostScript printer, it does not print correctly. Consequently, many UNIX systems have added software that converts scans jobs that arrive with the l command. If the scanner finds PostScript commands, the job goes directly to the printer. If no PostScript is found, the added software adds the PostScript code so that the job prints correctly.
If you send PostScript jobs from a Windows NT computer using LPR, and the printer controlled by the UNIX server prints the PostScript code instead of interpreting it, the UNIX server might have a scanner that does not recognize the output from the Windows NT PostScript driver as valid PostScript code. If this happens, you might need to reconfigure Windows NT to use the o control command by default.
If the client sends the f, o, or p control command, the Windows NT TCP/IP Print service assigns the TEXT data type to the print job—which tells the spooler to edit the job to make sure it prints. If the client sends the l control command, the Windows NT TCP/IP Print service assigns the RAW data type to the print job—which tells the spooler the print job needs no editing to print correctly. For more detail about data types, see "Data Types" earlier in this chapter.
Control commands are documented in the LPR specification, Request For Comment (RFC)1179, sections 7.17 through 7.29. For detailed information about RFC 1179, refer to the Windows NT Knowledge Base article, "Text of RFC1179 Standard for Windows NT TCP/IP Printing," reference number 124734.
LPD-compliant print devices must supply one or more names for each of their print queues, even though these devices often have only one possible destination for the print jobs they receive. Each print-device manufacturer chooses naming conventions independently. Some, like the HP JetDirect adapter, accept any string as a legal print queue name. In comparison, the Emulex NetJet adapter accepts only two strings, and these are case sensitive, and default to TEXT and PASSTHRU. These strings are configurable. To find the names supported by any specific adapter, check its documentation, or contact the vendor's technical support group.
Remember that the local print provider spools print jobs, and that it despools them to the print monitors. In Windows NT, after LPRMON receives a job from the local print provider, it spools it a second time as a temporary file in the SYSTEM32 subdirectory. LPR must include an accurate byte count in the control file, and it cannot get that byte count from the local print provider. Instead, it respools the data to a temp file, finds the size of that temp file, and sends that size in the control file to the LPD server.
The most common problem people encounter when printing from UNIX systems to a Windows NT print server is that their print jobs are processed as TEXT data type instead of RAW data type, as they would be on a UNIX system. This happens because the UNIX systems almost always send the f control command, expecting that the control command isn't too important, because the TCP/IP (LPD) server parses the job to identify what data type to use and how to alter the job. However, Windows NT relies on the control command to determine the data type. As a result, the LPD service on Windows NT assigns the TEXT data type to most jobs.
To correct this problem, reconfigure the LPR client to send the l control command so the LPD will assign the RAW data type.
Macintosh Port Monitor (Sfmmon.dll)
The Macintosh port monitor, Sfmmon.dll, transmits jobs over a network using the AppleTalk protocol to network-attached print devices, such as the Apple LaserWriter family. It also lets you send jobs to AppleTalk spoolers, regardless of the print device that the spooler is attached to.
This monitor is available on both Windows NT Workstation and Windows NT Server computers and enables any Windows NT-based computer to send local print jobs to AppleTalk print devices. However, only Windows NT Server has a Macintosh print server component, so only a Windows NT Server computer can receive print jobs from Macintosh clients.
Some print devices process non-PostScript print jobs incorrectly if they receive those jobs over AppleTalk. Also, some print devices process PostScript jobs incorrectly if those jobs contain binary data and arrive over any protocol other than AppleTalk. These problems result from restrictions in those print devices; they do not indicate that the Windows NT Server print server is transmitting the jobs incorrectly.
Digital Network Port Monitor (Decpsmon.dll)
The Digital Network Port print monitor, Decpsmon.dll, sends print jobs to Digital Equipment Corporation's Digital PrintServer print devices and to other Digital Equipment Corporation print devices (such as the DEClaser 5100 and the DECcolorwriter 1000).
Windows NT supplies the TCP/IP network protocol, but does not supply the DECnet™ protocol. If you want to use DECnet, you must contact Digital Equipment Corporation to obtain it.
LexMark Mark Vision Print Monitor (Lexmon.dll)
LexMark's Mark Vision print monitor (Lexmon.dll) sends print jobs to LexMark MarkNet print devices (such as the MarkNetXL) and to network adapters (such as the MarkNetXLe). This print monitor uses any of the following protocols:
PJL Monitor (Pjlmon.dll)
The PJL Language Monitor, which Windows NT 4.0 supplies, "speaks" printer job language (PJL). Any bi-directional print device that uses PJL can use PJL Language Monitor. For example, PJL is the language that implements all the bi-directional communication between an HP LaserJet 5Si (a bi-directional print device) and its print server.
Bi-directional communication allows applications to query the print device directly to determine its capabilities. It also provides the benefit of configuring printer driver settings on the server without user intervention. The printer driver can automatically determine how much memory the printer has, what printer fonts are available, and so on.
Bi-directional print devices can send unsolicited messages to Windows NT and to applications. For example, the print device might send an "out of paper" or "printer offline" message. Bi-directional communication enables much more detailed status reporting on a wider variety of information, such as low toner, paper jams, maintenance needs, and so on.
To take advantage of bi-directional printing, you must have the following:
Printer properties include everything about a printer—from what port you use to what security features you want to implement. For detailed information, see "Setting Up Print Servers" in Microsoft Windows NT Server Concepts and Planning. For procedural information, see Help.
To set or change printer properties
Separator Page Files
Separator pages—also called burst pages, header pages, or banner pages—print before each print job. They typically identify the computer that created the job, the time it was created, and so on. The local print provider contains an interpreter that reads commands from a separator page file to produce separator pages.
By default, separator page files are stored in the %systemroot%\SYSTEM32 directory. To use a separator page file, click the Separator Page button on the General tab of the printer's Printer Properties sheet. Either type the name of the Separator Page file, or browse through the directories and select a file. Windows NT provides three separator page files; you can use them as is, or modify them to create your own custom separator page files.
The following table lists the separator page files included with Windows NT.
To create a custom separator page file, copy and rename one of the supplied files, and then edit it. The following table provides the escape codes you can use. The separator file interpreter replaces these escape codes with appropriate data, which is sent to the printer.
To limit user access to your network printers and spool file directory, use Windows NT security. You can provide additional security by managing print jobs from Macintosh clients or by forwarding print jobs to other print servers.
To specify security attributes on a printer-by-printer basis, use the Security tab in the Printer Properties dialog box. The most efficient way to establish security attributes is to assign permission levels to different user groups. For example, you could give all nonadministrative users in a department the Print level of permission and all managers Full Control permission.
The following table summarizes printer security permissions.
The installation-default printer permissions are different for Windows NT Server and Windows NT Workstation computers. By default, the following print permissions are assigned on a Windows NT Server computer:
To change security permissions
Security for Macintosh Clients
Although native Macintosh networking provides support for file security, it does not provide support for print device security. The AppleTalk protocol contains no mechanism that supports client user name or password. Macintosh clients, therefore, cannot identify themselves on the network, and the Windows NT print server cannot impose user-level security on Macintosh clients. If a Macintosh client is physically able to send a job to a print device or print server, that client implicitly has permission to do so.
You can, however, enforce one set of printer permissions on all Macintosh users as a group. The Macintosh client must start the MacPrint service by logging on using a user account. By default, it logs on as the System account. The System account has Print permission on all local print devices, so any Macintosh client can send a job to any of the Windows NT computer's local printers. To limit the permissions for Macintosh clients, create a new user account, giving it the printer permissions you want the group to have. Then set the Macintosh client MacPrint service to log on using this account.
Note The System account on one computer does not have permission to access resources on other computers. Macintosh clients that start the MacPrint service by logging on as System user cannot send jobs to printers that forward jobs to other print servers. The solution is to configure the Macintosh client MacPrint service to log on as another user, one which has permission to print on all the print servers to which print jobs are forwarded.
Spool File Security
To implement spool file security, change the default spool directory to an NTFS partition and directory where write permission is limited on a user-by-user basis.
When a print job prints locally, the local print provider spools the job to disk during processing. By default, the Everyone group has Change permission in the default spool directory. This allows all user print jobs write access to the default spooler directory.
A print job that cannot be spooled to disk during processing does not print. If the spool directory location is changed, all users who need to print must have Change permission for the new spool directory.
As described in the "Local Print Provider" section, the spool file (SPL_) and the shadow file (SHD) are written to the default spooler directory: %WINNT\SYSTEM32\SPOOL\Printers
For instructions on changing the default spool file directory, see "Local Print Provider" ealier in this chapter.
To override the default location for one specific printer
The change in the Registry takes effect after you stop and restart the Spooler service.
Most printing-related Registry settings reside in the following subkey:
HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Control \Print
An administrator can use the Registry Editor to assign read-only access to these subkeys. Users with read-only access cannot add or configure printers, because the read-only access does not allow changes of these subkeys.
Windows-based applications also use the following subkey in the Registry to find information about available printers.
HKEY_CURRENT_USER \Software \Microsoft \WindowsNT CurrentVersion\PrinterPorts
Users with read-only access to this subkey cannot add new printers that are recognized by Windows-based applications.
To forward a print job to a different Windows NT print server, a Windows NT print server uses a null session. By default, the null session is disabled, preventing job forwarding. To enable job forwarding and null-session support, manually edit the following Registry subkey:
\HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services LanmanServer\Parameters
In this subkey is a value named NullSessionShares. Add a new line containing the share name for the printer. This change does not take effect until you stop and restart the Spooler service.
Troubleshooting Printing Problems
Troubleshooting Windows NT printing problems can be a challenge because of the number of variables involved in printing and the number of different clients and print devices that Windows NT supports.
Windows NT has a modular printing architecture, with a module for each major task (such as receiving jobs from network clients). By adding new modules you can easily add functionality (such as support for a new type of network client). This modularity gives Windows NT a great deal of flexibility, making it able to support a wide variety of client operating systems, applications, data objects, network configurations, spooling options, and print devices. That flexibility comes at a cost, however, because each additional configuration adds its own possible points of failure.
Successful troubleshooting depends on your ability to quickly rule in or rule out general categories of points of failure. The modularity makes this fairly easy: Network printing, for example, consists of seven processes that always occur in the same order. By testing one of the processes, you can determine whether the problem is occurring in that process, before it, or after it.
The following are the seven basic processes involved in a network printing job:
The basic strategy for troubleshooting printing problems is to use problem symptoms to identify the process, or processes, that are creating the problems. If you still cannot correct the problem after you've located it, your Product Support engineer will be much better able to help you correct it if you have first isolated the process where the problem exists.
To troubleshoot printing problems
To help you implement this strategy, this section presents the seven basic printing processes and gives the following information about each process:
Printer Definition and Configuration
A print server administrator can use the Add Printer wizard to:
Both procedures install and configure a printer driver. Creating a printer gives more control over driver configuration than connecting to a printer, and the administrator can create new printer ports by entering values in the Print To field on the Printer Properties sheet. The administrator can also define form-to-tray mapping, security, and spooler options.
The problem is likely in this process if...
Client Computer Connects to a Shared Printer
A printer is established on a print client computer.
The problem is likely in this process if...
Client Application Creates a Print Job
A user on a client system runs an application that composes text and/or graphics to create a print job. The application may interact with a printer driver to create output in a printer language such as PCL, PostScript, or HP-GL/2.
The problem is likely in this process if...
If the problem persists when you send a simple textprint job from several clients' systems, the problem is likely caused by another printing process.
Client Sends Job to Spooler
The user on the client system sends the job over the network to the print server. The client system's application software or operating system sends the job to the client's transport protocol, to the network adapter, over the network hardware, to the transport software on the print server, and finally to the appropriate print server service on the print server. The print server service (Windows NT Server, Services for Macintosh, or TCP/IP Print) assigns a data type to the print job and submits the print job to the spooler, or leaves it blank.
The problem is likely in this process if the problem is limited to...
The problem is also likely in this process if...
Suspect a problem elsewhere if...
Print Server Spooler Processes Print Job
The spooler receives the job from the print server service. If the printer was established by selecting the Network Printer option in the Add printer wizard, the remote print provider sends the job to the print server. Otherwise, the job goes to the local print provider.
Unless otherwise configured, the local print provider spools the job to disk and checks the data type assigned by the print server service. The data type (for example, RAW or PSCRIPT1) determines which print processor receives the job. The data type also effects whether the print processor alters the job or not, and if so, how it alters the job. If the spooler is configured to append a separator file, it does so before sending the job to the print monitor for delivery to the print device.
The problem is likely in this process if...
Print Server Spooler Sends Job to Print Device
The print monitor receives the job and interacts with local hardware drivers and transport drivers to send the job to its destination. The components in this process are:
The problem is likely in this process if it is limited to...
The problem is also likely in this process if...
Print Device Interprets Job
The final processing at this point is completed by the print device. The print device receives the print job from a hardware port. The print device interpreter interprets the job and produces hardcopy output.
The problem is likely in this process if...
Questions and Answers
The following section presents specific questions and answers about Server Printing.
Does the Windows NT print server support UNIX clients running LPSSCHED?
No, it does not support UNIX computers running LPSSCHED. UNIX client computers must have an LPD program installed when used with a Windows NT print server.
How can platform-specific printer drivers be installed?
Microsoft places all new or updated printer drivers onto its electronic services for public download.
Also, a platform-specific printer driver is likely available on another computer in the network.
To install platform-specific printer drivers from another computer in the network
What kind of problems occur when a print job has been assigned an incorrect data type?
Typical problems that occur when there is some error in the data type assignment and consequent job alteration of a print job include the following:
How many printers can be supported by a Windows NT print server?
The limitation on the number of printers that can be attached to Windows NT print server is dependent on whether the print server is a Windows NT Workstation computer or a Windows NT Server computer. Windows NT Workstation and Windows NT Server have been optimized for different roles in the network:
The limitation on total printers attached to a Windows NT Server print server should be determined by daily requirements for print throughput. Print throughput is determined by the processor capabilities. For example, a print server with approximately 64 meg RAM and a 486/66 or higher processor with a high throughput network card can support 25 to 30 DLC printers or 40 TCP/IP printers.