Chapter 7 - Printing

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

The primary focus of this chapter is on local printing from the Windows NT Workstation itself. But you can also provide printing to as many as 10 peer-to-peer connections with the Windows NT Workstation functioning as the print server.

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 4.0 Workstation, refer to the following documentation.

Documentation Source	Descriptions
Microsoft Knowledge Base	An effective and consistent resource for troubleshooting printing problems.
Microsoft Technet	Microsoft White Papers, TechEd, and other articles are available on the Microsoft Technet CD.
Support Fundamentals for Windows NT, Chapter 13, "Printing with Windows NT"	A Microsoft Press® self-paced training manual.

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 Planning Guide. 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 so that it prints 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, ensuring that the print job can resume after power is restored. Despooling is the process of 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.

This chapter presumes that the print server is a Windows NT 4.0 Workstation.

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 Local printer option. You'll be asked to install the printer driver, specify a port, and give the printer a name.

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. Other print clients must "create" the printer shared by the Windows NT print server.

A print client is the computer that creates the print job sent to a Windows NT print server. The client can be a remote client sending the print job to the print server over a LAN. Or the client can be on the print server itself—a local client. This chapter presumes that most printing done with Windows NT Workstation is local.

A client application is any application that creates a print job. The client application can be local (on the print server) or it can be 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.

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.

Overview of the Printing Process

This section provides a general overview of printing at a Windows NT Workstation. Although the primary focus of this chapter is on local printing from the Windows NT Workstation itself, you can also provide printing to as many as 10 peer-to-peer connections with the Windows NT Workstation functioning as the print server. For more information about network printing using a Windows NT 4.0 Workstation as a print server, see "Network Printing Using Windows NT Workstation" later in this chapter.

1. The user at the Windows NT Workstation chooses to print a document.

   For the Windows NT Workstation or for a client running any Windows operating system and printing from a Windows application, the application calls the graphics device interface (GDI). GDI calls the printer driver associated with the target print device. Using the document information from the application and the print device information from the printer driver, GDI renders the print job in the printer language of the print device.

2. The print job gets passed to the spooler.

   The client side of the spooler (Winspool.drv) makes a remote procedure call (RPC) to the server side of the spooler (Spoolss.exe), which makes a direct application programming interface (API) call to the router (Spoolss.dll). The router passes the print job to the local print provider (Localspl.dll), which spools it (writes it to disk).

3. The print job is altered, if necessary, to print correctly.

   The local print provider (Localspl.dll) polls the print processors. When a print processor recognizes the job's data type, that print processor receives the print job and alters it (or not) according to its data type to ensure that the job prints correctly.

4. Control of the print job passes to the separator page processor, which adds a separator page, if specified, to the front of the job.

5. The job is despooled to the print monitor.

   If the print device is bi-directional, the monitor is a language monitor, which handles bi-directional communication with the printer and then passes the job to the port monitor.

   If the print device is not bi-directional, the job goes directly to the port monitor, which transmits the print job to the print device or to another server over a specific communications channel.

6. The print device receives the print job, translates it into a bitmap, and prints it onto paper or another medium.

Print Jobs

Print jobs are not simply data: They are source code that contains both data and the commands for processing the data. The client application (along 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.

Data Types

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 PostScript). To change the default data type, use the following procedure:

To change the default data type for a printer you have created

1. Click Start, and then click Settings.

2. Click Printers.

3. Click to select the printer for which you want to change the data type.

4. Click Properties on the File menu.

5. Click the General tab.

6. Click the Print Processor button

7. In the Default Datatype list, click the data type.

8. Click OK in each dialog box.

The following sections describe the different data types.

EMF

Print jobs from Windows NT 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 on 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.

RAW

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 non-Windows NT 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 in the 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 in the Print Processor dialog box to this type so that it affects jobs from Windows network clients.

TEXT

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.

Character	PC-850	ANSI	PC-437	Roman-8
Lowercase C Cedilla	135	231	135	181
Lowercase AE Diphthong	145	230	145	215
Lowercase N Tilde	164	241	164	183
Lowercase Eth	208	240	-	228
Lowercase Es-zet	225	223	225	222

PSCRIPT1

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

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

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:

• A printer graphics driver. This file renders device driver interface (DDI) commands from the graphics engine to commands that a print device can understand. Each graphics driver renders a different printer language. For example, a Pscript.dll renders PostScript printer language.

• A printer interface driver. This file provides the user interface you see when you configure a printer.

• A characterization data file. This file provides information about the configuration capabilities of a specific make and model of print device, including what resolutions it is capable of, whether it can print on both sides of the page, and what paper sizes it can accept.

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 and Windows 95 client hardware platform. For example, when x86-based clients running Windows NT Workstation are served for printing by a Digital Alpha AXP-based Windows NT Server, you must install x86 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 drive. The print client 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."

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 Windows NT 4.0 on your print servers. A print server running Windows NT 4.0 can supply earlier version printer drivers to downlevel print clients, if necessary.

Platform-specific printer drivers are available with Windows NT 4.0 Workstation for the following:

• Intel x86-based computers running Windows NT 4.0, 3.5, or 3.51 and Windows 95

• MIPS RISC-based computers running Windows NT 4.0, 3.5, or 3.51 and Windows 95

• Digital Alpha AXP-based computers running Windows NT 4.0, 3.5, or 3.51 and Windows 95

• Power PC running Windows NT 4.0, or 3.51 and Windows 95

Print devices can be classified as either raster, PostScript, or plotter. To support these three classes of print devices, Windows NT provides the following generic printer drivers::

• Universal printer driver

• PostScript printer driver

• HP-GL/2 plotter driver

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:

• Rasdd.dll is the printer graphics driver for printer languages based on raster (bitmap) images, including PCL, and most dot matrix printer languages.

• Rasddui.dll is the printer interface driver.

• Raster minidriver is the characterization data file. The filename for this component depends on the print device or printer family. Check the documentation that accompanies your print device.

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:

• Pscript.dll is the printer graphics driver

• Pscriptui.dll is the printer interface driver

• x.ppd is the PostScript printer description (PPD) characterization data file

  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, but 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:

• Plotter.dll is the printer graphics driver.

• Plotui.dll is the printer interface driver.

• x.pcd is the characterization data file.

Establishing Printers

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:

• Click Start, point to Settings, and then click Printers

• In My Computer, double-click the Printers Folder

• In Control Panel, double-click the Printers icon

To establish a printer with the Add Printer wizard

• In the Printers folder, double-click the Add Printer icon. 

  The Add Printer wizard leads you through the process of setting up and configuring a printer. The only differences between establishing a network printer and a local printer are as follows:

  • If you are establishing a local printer, you must install a printer driver. This action "creates" the printer on your computer.

  • If you are establishing a network printer, you must specify the path to the network printer or browse to find its network location. This action "connects to" the printer on the network print server.

To establish a printer using Point and Print

1. Open the Printers folder.

2. Double-click Network Neighborhood.

3. Click the print server.

4. Drag the printer icon to your Printers folder.

   This action "connects to" the printer on the print server.

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.

Connection Method	Windows NT Sending Software	Required Network Protocols	Windows NT Receiving Software
Connect to network printer in Add Printer wizard	Spoolss.exe	TCP/IP, NetBEUI, NWLink	Spoolss.dll
Create local printer in Add Printer wizard and Print To options for a UNC device.	Windows NT Workstation Service (NetBIOS redirector)	TCP/IP, NetBEUI, NWLink	Windows NT Server service
Create local printer and Print To options for an LPR port	LPR (Lpr.exe) Port Print Monitor	TCP/IP	TCP/IP (LPD) Print Service
Create local printer using Chooser and Print To options for an AppleTalk device	AppleTalk Print Monitor	AppleTalk	Services For Macintosh

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

1. Click Start, point to Settings, and then click Printers.

2. Click to select the printer.

3. Click Properties on the File menu.

4. Click the Device Settings tab.

5. Double-click Available PostScript memory.

6. Type the value from Testps.txt in the Change Settings box.

7. Click OK.

Print Clients

Print clients, whether local (on the print server) or remote (on the network) send print jobs to a Windows NT print server. The print server services receive print jobs from remote clients as input/output (IO) requests that must be directed to the appropriate system process.

This chapter focuses on printing locally on the Windows NT Workstation and from Windows NT network clients. But, it also includes information about other network clients.

The following can all be print clients:

• Windows NT Workstation local clients

• Windows NT network clients

• Windows 95 network clients

• 16-bit Windows network clients

• MS-DOS network clients

• UNIX clients

Windows print clients receive printer alerts confirming successful prints or indicating errors. If a client doesn't want to receive printer alerts, you can disable them by adding the following entry to the [Network] section of the System.ini file:

SendPrintMessages=no

Note Disabling WinPopup does not disable printer alerts.

Windows NT Local Client

Windows-based applications and MS-DOS-based applications print in different ways and follow different rules. Windows-based applications send print jobs to printers added in the Printers folder. They typically use the printer drivers associated with those printers. However, some high-end desktop publishing or CAD applications have their own internal program copy of printer drivers.

In contrast, MS-DOS-based applications are unaware of the printers added in the Printers folder. They print to ports instead of to printers. This can cause problems. Whereas you could add several dozen printers in the Printers folder, most MS-DOS-based applications are limited to ports like LPT1–LPT3 and COM1–COM2. Windows NT accommodates MS-DOS-based applications in the following ways:

• If the port is controlled by the network redirector (for example, when a net use command redirects output to a shared resource), the redirector determines where the job goes.

• If the port is not controlled by a network redirector, but a printer prints to that port, the job is submitted to that printer, and that printer's spooling options take effect.

• If the port is not controlled by a network redirector, and no printer prints to that port, the job goes directly to the port device driver and prints (presuming, of course, that a print device is connected to that port).

EXAMPLE

Assume you are interactively logged on to a print server, and that there are two printers in the Printers folder and two print devices. The server is named \\PSERVER1, the printer named HPV prints to an LPT2 port supplied by a separate IO card, and the printer named HPIIISI prints to the FILE port. Both HPV and HPIIISI are shared on PSERVER1 over the network. There are print devices connected to both LPT1 and LPT2. You open a command prompt and type the following command:

NET USE LPT3: \\PSERVER1\HPIIISI.

When you copy a file to each of LPT1, LPT2, and LPT3, the following results:

COPY TEST.TXT LPT1: 

NTVDM checks with the redirector and finds that the redirector is not managing LPT1. It checks with the spooler and finds that neither of the defined printers prints to LPT1, so the job goes to the parallel port device driver.

COPY TEST.TXT LPT2: 

NTVDM checks with the redirector and finds that the redirector is not managing LPT2. It finds that the printer HPV is printing to LPT2. NTVDM submits the job to HPV and that printer's spooling options take effect as the job is printed on LPT2.

COPY TEST.TXT LPT3: 

NTVDM checks with the redirector and finds that the redirector is managing LPT3, so the redirector takes control. The redirector is set so that data sent to LPT3 is actually sent to the print share \\PSERVER1\HPIIISI. It sends the job to that share and once it arrives, HPIIISI's spooling options take effect. Although you usually use the net use command to assign a local port to a remote shared resource, it is perfectly legal to assign a local port to a local shared resource. This is often useful in testing and troubleshooting.

32-Bit Windows Network Clients

Windows NT and Windows 95 network clients can send print jobs using any of the following network protocols:

• NetBEUI

• NWLink

• TCP/IP

• AppleTalk

Windows NT 4.0 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 and Windows 95 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 4.0 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 print jobs always spool EMF locally and playback locally to generate RAW data type before being sent to the print server. The print server spools them 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:

• LAN Manager

• Microsoft Network Client 3.0 for Windows

• Windows for Workgroups built-in redirector

The MS-Network redirectors send jobs by using the following protocols:

• NetBEUI

• NWLink

• TCP/IP

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.

Network Printing using Windows NT Workstation

There are essentially two ways to implement printing using Windows NT Workstation as the print server:

• Workgroup printing

• Server printing

Workgroup Printing

With Workgroup printing, the assumption is that the printer or printers are connected directly to the network, and that each user on the LAN creates the printer on his or her own computer and does not share it. Each user then sets his or her own printer driver settings and each computer must have the printer driver installed.

The disadvantage to this configuration is that you can't be sure that, for example, the paper tray you've designated as letter-sized actually contains letter-sized paper unless you physically go check it right before you print. Someone may have designated that tray as legal-sized paper and recently replaced the letter-sized cartridge with a legal-sized cartridge.

Each computer also has its own printer queue displaying only those print jobs sent from that computer. This is a disadvantage for determining where your print job is in relation to all the print jobs (including those from other computers), and gives the user no feedback about when a particular print job might actually print.

Another disadvantage to this setup is that errors (such as paper jams or no paper in the tray) appear only on the queue for the current print job. No other computer gets the error message. If the user at the computer getting the error message has left for lunch, printing could be held up for some time.

Server Printing

The second way to set up printing is to have one Windows NT Workstation function as print server. One computer in the LAN creates the printer and shares it with other computers.

Windows NT Workstation can support a small (maximum 10 connections) local area network (LAN) for printing. Because it is not designed to provide server functions, Windows NT Workstation has the following limitations that you need to understand in order to get satisfactory network printing performance.

1. Services for Macintosh and File and Print Services for NetWare are not available with Windows NT Workstation. Consequently, Macintosh computers and NetWare network clients can't print to a print device served by a Windows NT Workstation.

2. Spooling is given a lower priority on Windows NT 4.0 Workstation than on Windows NT 4.0 Server. This means that a Windows NT Workstation functioning as a print server will print somewhat slower than a Windows NT Server. Also, if the print server is also used as someone's work machine, that person may find his or her applications running a little sluggishly while someone is printing.

3. You are limited to 10 connections, and they must be within the same LAN.

In this scenario, printer driver settings are controlled by the print server computer. A single queue appears on every computer connected to the printer, letting each user see where his or her print job is in relation to others waiting to print. Error messages, therefore, appear on everyone's computer, so that anyone can know to refill the paper tray, clear the paper jam, or plug the printer back in. This method also allows you to have a single administrative log if you audit your printing events.

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 interfaces (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 Workstation provides the following print server services:

• Windows NT Server Service

• TCP/IP Print Server Service, known as Line Printer Daemon (LPD)

Client applications on the Windows NT Workstation print server itself use these additional software modules:

• Windows NT Virtual DOS Machine (NTVDM)

• Graphical Device Interface 32-Bit (GDI32)

The following table lists each print server service and the type of print client processed by the service.

Service	Registry Name	Supported Clients
Windows NT Server service	Srv.sys	MS Network clients using NetBIOS redirectors on MS-DOS, Windows, Windows for Workgroups, or Windows NT computers.
TCP/IP Print service	Lpdsvc.sys	LPR (line printer) clients on UNIX or Windows NT computers where the TCP/IP protocol is used.

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:

• Windows NT

  The Windows NT Server service only receives jobs from Windows NT clients if the client has created the printer in his or her own machine. If the client has connected to the printer, the print job goes directly to the server's spooler. For more information about creating versus connecting to a printer, see "Creating vs. Connecting to a Printer" earlier in this chapter.

• LAN Manager

• MS Network Client (often used on clients running MS-DOS alone or MS-DOS with Windows Versions 3.0, 3.1 or 3.11)

• Windows For Workgroups

• Windows 95

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 EMFor 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 supports 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.

Windows NT Virtual DOS Machine (NTVDM)

MS-DOS-based applications run in a special Win32-based component referred to as a Windows NT virtual DOS machine (NTVDM). The NTVDM component translates MS-DOS operating system calls into calls used by the WIN32 subsystem.

If you print from a locally-run MS-DOS-based application or from a Windows NT command-line utility that sends data to a printer port, NTVDM receives the job. What happens next depends on whether the Windows NT redirector or the spooler manages the port:

• First, NTVDM queries the redirector to find out whether it is managing the target port. This would be the case if someone had issued a NET USE LPT1:\\SERVER\SHARE command. If so, the redirector takes control of the print job, and none of the spooler options affect the job.

• If the redirector is not managing the port, and someone has assigned a printer to that port using the Add Printer wizard, the job goes to that printer. In this case, the default data type of the print server and its spooling options are in effect.

• If neither the redirector nor printers are managing the port, the job goes to the port device driver unaltered. Naturally, this presumes a print device is physically connected to the port. If not, you'll get an error message.

For example, suppose one printer prints to COM1, and none of the printers print to LPT1 (but a print device is connected to LPT1). Also, suppose that you issue a net use command to redirect output from LPT2 to a network print share. If an MS-DOS-based application prints to LPT2, the job is sent to the network print share. If the application prints to COM1, NTVDM submits the job to the printer that prints to COM1, and that printer's default data type is used. If the application prints to LPT1, NTVDM submits the job directly to the parallel port device driver, and no print job alteration occurs.

Windows NT Graphical Device Interface (GDI32) for 16-Bit Applications

On a Windows NT computer, Windows 3.x-based (16 bit) applications are supported by a Graphical Device Interface 32 (GDI32) engine. The GDI32 engine translates print and display application programming interface (API) calls to 32-bit WIN32 services.

The GDI32 graphics engine (Gdi32.dll) is the printing component that provides What You See Is What You Get (WYSIWYG) support across devices. The graphics engine communicates with Windows-based applications through the Windows Graphics Device Interface (GDI) and with printer drivers through the Device Driver Interface (DDI).

When a Windows-based application creates a print job, it describes the output it wants in a series of GDI commands. The GDI32 graphics engine is the component that translates these GDI commands into the DDI commands understood by components such as printer drivers and print processors.

The GDI32 graphics engine queries the printer driver to identify the capabilities of the print device, including supported fonts. Using this information, the GDI32 graphics engine uses other DDI commands to specify the positioning of each character in the document by the print device. The GDI32 graphics engine also uses DDI commands to define how the print device should draw and fill graphics and how to manipulate and print bitmaps.

The GDI32 graphics engine provides services to the printer driver, including compatibility with the environment subsystem (for example, MS-DOS or OS/2) and performance optimization, caching, client-server communications, and ANSI-to-Unicode conversion.

The GDI32 graphics engine calls the printer driver and provides information about the type of print device needed and the data type used. In response, the printer driver provides the graphics engine with the fully qualified path name for the print device and printer-setting information. This information is passed to the spooler.

Print Spooler

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 7.1 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:

Spooler Component	Desciption
Router	Winspool.drv, Spoolss.exe, Spoolss.dll.
Local Print Provider	Localspl.dll
Remote Print Providers	Win32sp.dll for Windows print servers. Nwprovau.dll for NetWare print servers.
Print Processors	Winprint.dll Sfmpsprt.dll
Print Monitors	Localmon.dll Hpmon.dll Lprmon.dll Sfmmon.dll Decpsmon.dll Lexmon.dll Nwmon.dll Pjlmon.dll

Each spooler component is described in more detail in the following sections.

Router

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 of the remote print providers 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:

• Windows Network print provider (Win32spl.dll) transfers jobs to Windows Network print servers (such as print servers running Windows NT or Windows for Workgroups).

• Novell NetWare print provider (Nwprovau.dll) transfers jobs to Novell NetWare print servers.

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 7.2 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 7.3 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

1. Create a new spool file directory.

2. Click Start, and then point to Settings.

3. Click Printers.

4. Click Server Properties on the File menu.

5. Click the Advanced tab.

6. In the Spool Folder box, type the path for the new spool file directory.

7. Click OK.

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

1. In the Printers folder, click the printer to select it.

2. Click Server Properties on the File menu.

3. Click the Advanced tab.

4. Click Enable spooler event logging to add a check mark.

5. Click OK.

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 "Spooler 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 are used to 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.

Print Processor

The print processor is the component that make necessary alterations to print jobs, based on the data type of the print job. The print processor (Winprint.dll) works in conjunction with a printer driver to despool the spooled print jobs during print spool file playback.

A print device vendor might develop a custom print processors if

• The vendor develops its own printer driver, or

• The vendor supports a data type different from those supported by the Microsoft print processor.

Additional print processors may be supplied by third-party software vendors to support custom data types.

Print Monitors

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. 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.

• Local print monitor (Localmon.dll)

• Hewlett Packard Network Port print monitor (Hpmon.dll)

• Line Printer (LPR) Port print monitor (Lprmon.dll)

• Macintosh print monitor (Sfmmon.dll)

• Digital Network Port print monitor (Decpsmon.dll)

• LexMark Mark Vision print monitor (Lexmon.dll**)** 

• NetWare Print Monitor (Nwmon.dll)

• PJL Language Monitor (Pjlmon.dll)

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

1. Click the Start button, and then point to Settings.

2. Click Printers.

3. Click Add New Port.

4. Click to select the port monitor that controls the type of communications channel you want to use.

5. Insert the disk or type the network path to the port monitor files.

6. Click OK in each dialog box.

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:

• An explicit filename, such as C:\dir\filename. All jobs sent to this port are written to the named file. Each new job overwrites the last one.

• The name of a print share, such as \\server\printer. Jobs sent to this port are transferred over the network to the named share by the network redirector. This can be useful if you need to send jobs to a network print server, but you want the job to spool locally as well as on the print server.

• The NULL port. Use this port to test whether network clients are able to send jobs. Simply pause the printer set to use this port, send a job from a network client, look at the printer in Print Manager to confirm that it arrived, and resume the printer. Jobs sent to NULL are simply deleted from the system without wasting paper or delaying real print jobs.

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

1. Click Start, point to Settings, and then click Control Panel.

2. Double-click the Network icon.

3. Click the Adapters tab.

4. Remove each adapter that has an incorrect number.

5. Add the adapters back in the order that corresponds with their I/O addresses (the lowest address getting the lowest number).

6. Click OK.

   You'll need to restart the computer before the changes take effect.

You can configure ports managed by Hpmon.dll as either job-based or continuous connection. The setting affects all ports at once:

• With job-based connection, a print server connects to the JetDirect adapter, sends a print job, and disconnects when the job is finished printing. This enables other print servers to connect and print.

• With continuous connection, a print server connects to the JetDirect adapter and maintains the connection until either the print server or the adapter is rebooted, preventing other servers from connecting. The main advantage of continuous connection is that all users are validated by the Windows NT security model, and every print job access can be audited.

  For more information about auditing printing, see the Windows NT 4.0 Workstation Online Resource Guide. 

  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:

• UNIX computer

• Windows NT computer

• Windows for Workgroups computer with a third-party LPD

• network adapter, such as an HP JetDirect or Emulex NetJet

For example, let's say you're connecting to a printer named LABLASER on a UNIX computer whose IP address is 11.22.33.44, and whose name (defined in the hosts file on your Windows NT computer) is UNIXBOX. You can enter either "UNIXBOX" or "11.22.33.44" (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 RFC 1179 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 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 DECnetprotocol. If you want to use DECnet, you must contact Digital Equipment Corporation to obtain it.

LexMark Mark VisionPrint 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:

• DLC

• TCP/IP

• IPX

NetWare Print Monitor (Nwmon.dll)

NetWare's print monitor (Nwmon.dll) sends print jobs to Pserver print devices. Pserver is a print-device standard developed by Novell.

In most situations, the print server drives the trnsport process of delivering the print job over the port. In the case of a Pserver print device, Nwmon.dll manages the communication between the device and the server. The Pserver "grabs" the print job from a passive print queue.

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 Printing

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:

• A bi-directional print device.

• An IEEE 1284-compliant cable (a cable that has "1284" printed on it).

• A correctly configured port. (Some parallel ports are set to IBM AT-compatible mode by default; in this case, you need to set the port to IBM PS/2 mode.)

Printer Properties

Printer properties include everything about a printer from what port you use to what security features you want to implement.

To set or change printer properties

1. Click Start, and then point to Settings.

2. Click Printers.

3. In the Printers window, click the printer to select it.

4. Click Properties on the File menu.

5. On the Printer Properties sheet, click the tab you want.

   The tabs are described in the following table.

6. Click OK.

Tab	Description
General tab	Displays general information about the printer, such as its physical location, a descriptive comment, and the printer driver installed. You can also add or customize a separator page, select a vendor-supplied print processor, and print a test page.
Ports tab	Displays the computer's physical ports. You can also add, configure, and delete virtual ports.
Job Scheduling tab	Displays the times the printer is available, its priority level, and spooling options.
Sharing tab	Displays the share status and share name.
Security tab	Permissions button lets you set the level of access for different types of users. Auditing button lets you set up printing users and events to be tracked. Ownership button displays printer owner.
Device Settings tab	Displays everything from paper tray sizes to font substitutions table for that printer. Use it to download soft fonts, install font cartridges, increase printer virtual memory, etc.

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.

Filename	Purpose	Compatible with
Sysprint.sep	Prints a page before each document	PostScript
Pcl.sep	Switches dual-language HP printer to PCL printing	PCL
Pscript.sep	Switches dual-language HP printer to PostScript printing	PostScript

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.

Escape code	Function
\	The first line of the separator file must contain only this character. The separator file interpreter considers this the separator file command delimiter. This table assumes that character is a \ character.
\N	Prints the user name of the person who submitted the job.
\I	Prints the job number.
\D	Prints the date the job was printed. The representation of the time is the same as the Time Format in the International section on the Control Panel.
\Lxxx	Prints all the characters (xxx) following it until another escape code is encountered.
\Fpathname	Prints the contents of the file specified by path name, starting on an empty line. The contents of this file are copied directly to the printer without processing.
\Hnn	Sets a printer-specific control sequence, where nn is a hexadecimal ASCII code sent directly to the printer. To determine the specific numbers, see your printer manual.
\Wnn	Sets the width of the separator page. The default width is 80 characters; the maximum width is 256. Any printable characters beyond this width are truncated.
\B\S	Prints text in single-width block characters until \U is encountered.
\E	Ejects a page from the printer. Use this code to start a new separator page or to end the separator page file. If you get an extra blank separator page when you print, remove this code from your separator page file.
\n	Skips n number of lines (from 0 through 9). Skipping 0 lines simply moves priting to the next line.
\B\M	Prints text in double-width block characters until \U is encountered.
\U	Turns off block character printing.

Print Security

You can limit the access that users have to your network printers and spool file directory by using Windows NT security. You can provide additional security by forwarding print jobs to other print servers.

Printer Security

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.

Type of permission	Level of access
Full Control	Enables complete access and administrative control.
Manage Documents	Enables a person to change the status of any print job submitted by any user. Does not permit control of the printer status.
Print	Allows user to send print jobs to the printer and to control pause, resume, or delete for his or her own jobs.
No Access	Explicitly denies access to a specific printer.

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 Workstation computer:

• Full Control permission for the Administrator

• Manage Documents permission for the Creator Owner group

• Print permission for all users

To change security permissions

1. Click Start, and then point to Settings.

2. Click Printers

3. Click to select the printer whose settings you want to change.

4. Click Properties on the File menu.

5. Click the Security tab.

6. Click Permissions.

7. Click to select the group whose permission you want to change, and then select the permission level from the Type Of Access dropdown list.

   To add a group, click the Add button. To remove a group, select it, and then click the Remove button.

8. Click OK in each dialog box.

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 section "Local Print Provider," 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

1. Start the Registry Editor (Regedt32.exe).

2. Find the following key: 

   HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Control
   

Print\Printers

3. Find the key for the printer:

   HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Control
   

Print&lt;Printername>

4. Add a new SpoolDirectory setting, and as its value provide the path to the spool directory that this printer should use.

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.

The change in the Registry takes effect after you stop and restart the Spooler service.

Registry Security

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.

Forwarding Jobs

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:

1. An administrator creates a print share on the print server.

2. A client system connects to that share.

3. The client system creates a print job.

4. The client system sends the print job to the print share on the print server.

5. The print server receives, spools, and sometimes modifies the print job.

6. The print server sends the job to the print device.

7. The print device interprets the job and produces hardcopy output.

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 technical 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

1. If possible, reconfigure the process to avoid the problem in the short term.

2. Implement long term solutions.

To help you implement this strategy, this section presents the seven basic printing processes and gives the following information about each process:

• A basic description of what the process involves

• A list of variables that can affect the process

• Symptoms that would suggest a problem in this process

• Tests to prove or disprove the suspicion

Printer Definition and Configuration

A print server administrator can use the Add Printer wizard to:

• Create a local printer

• Connect to a remote printer

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...

• You cannot launch the Add Printer wizard, or you cannot browse printers in the Add Printer wizard.

• You cannot create a new local printer or a new local printer port.

• The port name and port do not show up or are intermittent.

• The problem is specific to one printer or to a subset of the printers.

• You can create another printer (with the same driver, port, and configuration options, but a different name) and the problem does not occur with that new printer.

• You cannot install a particular printer driver, or the driver for that printer doesn't exist.

• You cannot share a printer.

• You cannot establish security on printers.

• You have problems with forms, separators, pages, fonts, halftones, or printer options.

• You can delete the printer, stop and restart the spooler, recreate the printer with the same name and configuration, and the problem no longer occurs.

Client Computer Connects to a Shared Printer

A printer is established on a print client computer.

The problem is likely in this process if...

• You have problems with forms, separators, pages, fonts, halftones or printer options.

• You can connect to another shared printer, on the same print server, and the problem goes away.

• You cannot connect to a remote printer.

• You cannot browse printers in the Add Printer wizard.

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...

• The error in one particular print job is not reproducible.

• You create a simple test document and print it to a file. Transfer that file to a different client system, and print it to a different printer on a different print server, and there it continues to fail.

• What you see on the screen is not the output that you get.

• The problem is limited to one particular user or the users in a specific group; one particular client operating system; a particular vendor's printer driver (or a particular version of the printer driver); a particular font or fonts from a particular vendor; certain extended ASCII characters; a particular graphic object, a particular graphic file format (such as EPS, BMP, or TIF); jobs created by a particular application or version of that application; color or shading; incorrect resolution (dots per inch); or the print job is missing line feeds or form feeds.

• A different driver works fine.

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...

• One particular client redirector (one vendor's software, or one version of that software).

• One particular network transport (for example, TCP/IP, NWLink, NetBEUI).

• One particular make or model of network adapter, or one firmware level.

• One particular intermediate system for example, one specific router, bridge, hub, or gateway.

• One particular kind of intermediate system, for example, all jobs from clients on the other side of any router, bridge, or gateway.

• One particular kind of client, for example MS Network or LPR clients.

The problem is also likely in this process if...

• The print job is not started until the application is exited.

• Pages come out incomplete.

• The print server has run out of disk space.

Suspect a problem elsewhere if...

• The print job prints fine on another printer of the same make, model, or version.

• You send a print job to the spooler in a different way and the problem does not go away.

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...

• Page size, font, or character set is wrong because of incorrect data type (UNIX).

• Disk space is limited.

• You get extra form feeds or no form feed.

• Changing the default data type affects the problem with MS-Network.

• The job gets stuck in the printer.

• The problem is specific to one type of client.

• The problem occurs only when the printer was established using the Add Printer wizard.

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:

• Print monitors, LOCALMON, redirector, LPRMON, DECMON, HPMON, NWMON, or LEXMON

• Transport protocols (either TCP/IP, NWLink, NetBEUI)

• Network hardware (routers, bridges)

The problem is likely in this process if it is limited to...

• All print devices accessed by a particular print monitor.

• All print devices on one segment of the LAN.

• One make/model/version of a particular print device.

• One parallel/serial cable.

The problem is also likely in this process if...

• Sending the same job to the same device by means of a different communication channel by using a different protocol, serial, or parallel port produces a successful print.

• Trying different parallel or serial cable produces a successful print.

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...

• The problem is specific to a specific print device, or a print device that is a variation of the same model, make, or revision.

• Sending same print job to another print device of same make, model, and revision produces a successful print.

Questions and Answers

This 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 for a print client on a hardware platform different than the Windows NT print server?

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

1. Log on the client computer using an user account that has Full Control permission.

2. Double-click Network Neighborhood.

3. Double-click the print server.

4. Click to select a printer.

5. Click Properties on the File menu.

6. Type the location of the printer driver in the Printer Properties dialog box. The printer driver is installed on the print server where it is available to any client computer with the same hardware platform, that is connected to the Windows NT print server.

7. Click OK.

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:

• LPR client print jobs include PCL or PostScript code, include incorrectly printed extended characters, or print in the print device's default font.

• Extra page prints after a Microsoft Network client print job.

• Microsoft Network client print jobs include PCL or PostScript code, include incorrectly printed extended characters, or print in the print device's default font.

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:

Windows NT Workstation is limited to 10 connections from other computers and should be used as a print server in small-network situations.

Windows NT Server has been optimized as a print, file, and application server.