Windows NT Printing: Flow Of Control
| 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. |
By John Jacobs
ABSTRACT: This article explains the Windows NT printing architecture and helps system administrators troubleshoot printing problems.
On This Page
Introduction
Administrator Creates Local Printer on Server, and Optionally Shares It With the Network
Network Client Computer Makes Connection to Server's Shared Printer
Application Creates Print Job
Network Client Sends Job to Server's Shared Printer
Application Running on the Print Server Sends Job to Printer
The Spooler Receives the Print Job
Local Print Provider Receives the Print Job
Spooler Modifies Job, If Necessary
Spooler Sends Job to Locally-Controlled Port
Spooler Sends Job to Remote Print Server
Network Redirectors
Print Device Interprets Print Job
Troubleshooting
Conclusion
More Information
Introduction
One of the many challenges a mixed network presents to the system administrator is how to ensure that each client can print. Clients from different manufacturers or operating systems differ in how they create print jobs, how they send them to an output device or a print server computer, how much processing they allow or expect the print server to perform, and how they direct the print server to deliver the job to the target output device.
Windows NT's printing architecture makes it an effective mixed-network print server. The architecture's components perform specialized tasks, then pass control to other components, producing a complex flow of control during each print job.
When problems occur, the best troubleshooting technique is to alter the flow of control to identify the misconfigured or malfunctioning component. This article helps you troubleshoot printing problems by outlining the flow of control.
Windows NT Printing Terminology
Printer—A software interface to which applications send print jobs. A Windows NT printer associates a name with a driver, an output port, and various configuration settings. (Often referred to in other operating systems as a queue.)
Print device—A device that produces printed output.
Print server—A computer that shares its printers with network clients.
Remote printer—A printer that does not spool to disk the print jobs it receives. Instead, it sends its jobs directly to a print server.
Local printer—A printer that spools to disk the print jobs it receives. It then processes the jobs and sends them to a print device.
Network-attached print device—A device that connects parallel or serial print devices to the network, or a print device that has an internal network adapter. (Often referred to as a print server.)
Queue—A collection of print jobs received by a print server but not yet delivered to the target print device.
The Printing Process
The printing process includes different events in different situations. The flow of control is the same for Windows NT Server and Windows NT Workstation except that Windows NT Workstation cannot receive print jobs from AppleTalk clients or NetWare clients.
Administrator Creates Local Printer on Server, and Optionally Shares It With the Network
To use Windows NT as a print server, you must first create at least one local printer:
Windows NT 3.x—Run Print Manager and select Create from the Printer menu
Windows NT 4.0—Open the Printers Folder, start the Add Printer wizard, and select My Computer
Set configuration options such as the printer's logical name, its driver, the port it prints to, and whether to share the printer with Windows Network clients (and if so, the name of the print share).
Later in the printing process, when a job arrives at this printer, the flow of control will depend on the port the printer prints to.
When you first install Windows NT, the available ports include several LPT and COM ports, as well as the FILE: port. All of these ports are managed by a spooler component called the local port monitor.
Additional port monitors may be available; the list depends on the services and protocols you have installed. To view the list:
Windows NT 3.x—Select Other from the Print To list
Windows NT 4.0—Select the Ports tab from Properties, then select Add Port
Each port monitor provides an interface with which you create new ports; after you create a port its name appears in the Print To list or on the Ports tab.
To read about a port monitor and how it delivers print jobs, select the port type from this list, then return here to continue tracing the flow of control:
AppleTalk Port
Digital Network Port
Hewlett-Packard Network Port
LPR Port
PServer Compatible Port
Lexmark DLC Network Port
Lexmark TCP/IP Network Port
Local Port
You can also read tips on troubleshooting printer creation. The flow of control leads next to either of two steps: a network client that makes a connection to the server's shared printer, or a locally-run application that creates a print job.
Network Client Computer Makes Connection to Server's Shared Printer
To deliver print jobs, network client computers must make a connection to the print server's shared printer. They do this in several ways; each corresponds to a different way the client can send a print job, and each requires a different pair of client-side and server-side software.
Many network clients have only one type of client-side printing software. The way the client prints does not always depend on the client's operating system. Windows NT can act as any of the clients listed below and can receive jobs from them. The next step in the flow of control is creating a print job.
Click here for tips on troubleshooting these connections.
Windows NT—Remote Printer
A print server downloads the printer driver to the Windows NT client if all of these conditions are true:
The print server is running Windows NT
The print server has a printer driver designed for the client's platform (x86, Alpha, and so on) and compiled for the client's operating system version (3.1, 3.5, and so on)
The client does not have the driver already, or has a driver that is older than the one on the server
The Windows NT client automatically installs the downloaded driver. If any of the above conditions are not met, then the user on the Windows NT client computer is prompted to install a printer driver manually. In either case, the printer connection is available to Windows applications running on the Windows NT client.
Windows NT print servers can store and download drivers built for other Windows NT platforms and/or versions. For example, a DEC Alpha-based Windows NT 3.51 print server can store drivers for x86-based Windows NT 4.0 clients. However, Windows applications running on the print server require drivers built for both the server's platform and its version.
Microsoft Network
Microsoft Network client computers include MS-DOS computers running MS Network Client, as well as Windows for Workgroups, Windows 95, and Windows NT. These clients typically use a NET USE command to establish a connection to a server's shared printer. This command may be issued on the client's command line, or by a graphical utility such as Print Manager in Windows 3.11, Windows For Workgroups, or Windows NT 3.x, or the Printer folder in Windows 95 or Windows NT 4.0.
Windows NT print servers receive print jobs from these print clients using the Server service, which is installed by default on all Windows NT computers.
NetWare
NetWare clients include MS-DOS computers running software from Novell, as well as Windows operating systems (including Windows NT) running NetWare redirector software. To establish a connection to a server's shared printer, these clients use a CAPTURE command, which can be issued on the client's command line or by a graphical utility. Windows NT can be a NetWare client if you install Client Services for NetWare (CSNW) or File and Print Services for NetWare (FPNW).
Windows NT Server can receive print jobs from NetWare clients if you install File and Print Services for NetWare service, sold separately. This service is available only for Windows NT Server, not Windows NT Workstation.
LPR
Unlike most of the other clients, an LPR client does not establish a connection to a print server (an LPD server) until the client is ready to send its print job. LPR clients are often UNIX computers, although most operating systems that support TCP/IP have an LPR utility. Windows NT can act as an LPR client if you install the TCP/IP protocol.
Windows NT can receive print jobs from LPR clients if you install the Microsoft TCP/IP Printing service, which requires that you install TCP/IP on the Windows NT print server.
AppleTalk
AppleTalk clients are typically Apple Macintosh computers. These clients typically use the Chooser utility to select a zone, and then select a printer within that zone.
Both Windows NT Workstation and Windows NT Server can act as AppleTalk print clients if you install the AppleTalk protocol; this also installs a custom user interface that, like Chooser, lets you select AppleTalk print devices or servers on your network.
Windows NT Server can receive print jobs from AppleTalk clients if you install the Services For Macintosh service (available only for Windows NT Server).
Application Creates Print Job
The flow of control depends on how the spooler receives the job, not on the job's content. If the application runs on a network client, the next step is delivering the job to the Windows NT print server's spooler; if the application is running on a Windows NT computer, the next step is delivering the job to the local spooler.
Click here for troubleshooting tips.
Windows Application
A Windows application, on any Windows operating system, communicates with the Graphical Device Interface (GDI) to convert a document into a print job. GDI, in turn, obtains information about the target print device from the Windows printer driver. In most cases, this results in a job composed of printer-language commands, such as PCL or PostScript commands.
If, however, the application is running on Windows NT, GDI and the printer driver can perform a partial conversion. GDI then tells the application that the job has been created, and the application is free to continue interacting with the user. The spooler completes the conversion later, in the background.
Windows NT 3.x and 4.0 differ in three ways regarding this partial conversion:
Name—With Windows NT 3.x, the partial conversion creates a "Journal" file. With Windows NT 4.0, it creates an "Enhanced Metafile Format" (EMF) file.
When partial conversion is possible—Windows NT 3.x creates Journal files only if you established with the printer with Print Manager's Create command. Windows NT 4.0 creates EMF files if you enable the Metafile Spooling option in the Document Options section of the printer's Document Properties. By default, this option is enabled for PCL printers and disabled for PostScript printers.
Which computer completes the conversion—A Windows NT 3.x client's spooler completes the conversion before it sends the job to the print server. A Windows NT 4.0 client can send EMF files over the network, in which case the server's spooler completes the conversion: this offloads work from the client to the server.
Non-Windows Application
These applications have no way to interact with the Windows NT spooler or driver. They require their own driver software to create print jobs.
Network Client Sends Job to Server's Shared Printer
At this point, only two pieces of software are important to the flow of control:
The client-side redirector or utility that sends the job
The server-side service that receives the job
The client's application, operating system and hardware platform are not important.
The server-side service that receives the print job submits it to the Windows NT spooler, which assigns the job a "data type" value. This value tells other spooler components whether to alter the print job, and if so, how. This section outlines how the services receive jobs from different clients, and explains the logic in assigning data types. The next step in the flow of control is the same for all clients (the server-side service sets the data type and sends the job to the spooler), but the step after that is controlled by the job's data type.
Click here for general troubleshooting tips.
Windows Network
A Windows Network client sends a print job using its NetBIOS redirector software. The Windows NT print server receives the print job using its Server service.
Windows Network clients have no way to request a particular type of job alteration, so the spooler, not the Server service, requests it. As described below, the spooler will assign the Default Datatype value, which the administrator can set to any of the following:
RAW (default)
RAW [FF Appended]
RAW [FF Auto]
TEXT
If the administrator chooses NT JNL 1.000, NT EMF 1.002, or PSCRIPT1, the spooler will ignore the choice and assign RAW.
The Server service sends the print job to the spooler.
LPR
An LPR client sends a print job using an LPR utility, which uses the TCP/IP protocol to transfer both the print job and administrative information to the LPD service running on the print server. The Windows NT LPD service, officially called the Microsoft TCP/IP Printing service, usually uses administrative information sent by the LPR client to decide what alteration to request:
If the client sends an "f," "o," or "p" control command (requesting that the LPD service reformat the job), the Windows NT LPD service assigns the job the TEXT data type
Otherwise, the Windows NT LPD service assigns the job the RAW data type
Note: The SimulatePassThrough registry setting can override this behavior: it forces LPD to assign all jobs the RAW data type, regardless of the client's control command. This is important, because by default, most UNIX LPR clients send the "f" control command even if they do not want the LPD service to reformat the job.
LPD sends the print job to the spooler.
AppleTalk
An AppleTalk client uses a utility such as Chooser to send a print job using the PAP protocol of the AppleTalk suite. A Windows NT Server computer (but not a Windows NT Workstation) uses Services for Macintosh to receive the job.
AppleTalk clients are usually Macintosh computers, which almost always send PostScript print jobs. Services for Macintosh queries the spooler to determine the driver assigned to the target printer. If the driver is PostScript, then the job receives the RAW data type. Otherwise, it receives the PSCRIPT1 data type.
Services for Macintosh sends the print job to the spooler.
NetWare
A NetWare client uses an NCP redirector to send jobs to a server's shared printer. Windows NT receives these jobs using the File and Print Services for NetWare (FPNW) service, sold separately and for Windows NT Server only.
If the client's CAPTURE command requests tab expansion, FPNW assigns the job the TEXT data type; otherwise, it assigns RAW.
FPNW sends the print job to the spooler.
Windows NT 3.x
A Windows NT 3.x client that creates a remote printer, which in turn sends jobs to a Windows NT print server, delivers jobs directly to the server's spooler without the help of a server-side service. The jobs are assigned the RAW data type.
The Windows NT 3.x client's spooler sends the print job to the server's spooler.
Windows NT 4.0
A Windows NT 4.0 client that creates a remote printer, which in turn sends jobs to a Windows NT print server, delivers jobs directly to the server's spooler without the help of a server-side service. If the server's printer driver has the Metafile Spooling option enabled, the client sends an EMF file to the server, and the server assigns it the EMF data type. Otherwise, the server assigns the client's job the RAW data type.
The Windows NT 4.0 client's spooler sends the print job to the server's spooler.
Application Running on the Print Server Sends Job to Printer
The flow of control depends mainly on the type of application, and partly on whether the printer is local or remote..
Windows Application
If the target printer is remote then GDI renders the job completely and sends it to the client's spooler for delivery to the remote print server.
If the target printer is local then GDI partially renders the job and assigns a data type:
Windows NT 3.x—GDI renders the job to a Journal file, and assigns the Journal data type
Windows NT 4.0—GDI renders the job to an EMF file, and assigns the EMF data type
GDI then submits the print job to the local spooler.
Non-Windows Application
Non-Windows applications do not interact directly with the spooler. Instead of printing to a printer, they print to a port, such as LPT1. The flow of control depends on what other software is using that port.
If the target port is managed by a network redirector (the user has issued a NET USE <portname> \\<server>\<share> command) then the job goes to the appropriate redirector (the Windows Network redirector, or the NetWare Network redirector). The Windows NT spooler is not involved, so the job is neither spooled nor modified.
If the redirector isn't involved, and a local printer defined in Print Manager or the Printers folder prints to the target port, then the job goes to that local printer, and is assigned that printer's default data type.
If neither the redirector nor a printer are involved, then the job goes to the parallel or serial driver that controls the target port, and the print device receives the job. The Windows NT spooler is not involved, so the job is neither spooled nor modified.
LPR.EXE
Windows NT's LPR.EXE command line utility uses the TCP/IP protocol to send print jobs over the network to a print server's LPD service or a network-attached print device's network adapter. Other Windows NT printing components are not involved and the job goes directly to the LPD print server or device. The Windows NT spooler is not involved, so the job is neither spooled nor modified.
The Spooler Receives the Print Job
The Windows NT print spooler acts like a single service but has several components. The flow of control depends on which print provider component receives the job; this in turn depends on whether the printer is local or remote:
Local—Job goes to the local print provider
Remote—Job goes to a remote print provider
Local Print Provider Receives the Print Job
The local print provider is responsible for:
Spooling print jobs to disk
Passing control to a print processor for modification
Adding separator files
The administrator can alter job spooling:
Windows NT 3.x—In Print Manager, from the Printer menu select Properties, then Details to view options such as Print Directly to Ports, Hold Mismatched Jobs, Delete Jobs After Printing, Job Prints While Spooling, and Print Spooled Jobs First. This dialog also lets the administrator choose a separator file.
Windows NT 4.0—Open the Printers folder, select a printer, and select Properties from its Printer menu. Options on the Scheduling tab let the administrator change spooling behavior. The Separator Page option on the General tab lets the administrator choose a separator file.
After spooling the job to disk for safe keeping, the local print provider despools the job and delivers it to a print processor, which modifies the job, if necessary.
Spooler Modifies Job, If Necessary
The flow of control at this point depends on the job's data type.
If the job arrived without a data type the spooler assigned it the receiving printer's Default Datatype. The print server administrator defines this value:
Windows NT 3.x—Start Print Manager, select Properties from the Printer menu, then select Details, and choose a data type from the Default Datatype list.
Windows NT 4.0—Open the Printers folder, select a printer, select Properties from its Printer menu, select Print Processor, and select a print processor and default data type.
Next, the spooler polls the installed print processors, looking for one that recognizes the job's data type. That print processor receives the job, performs the appropriate modifications and returns the completed job to the local print provider. The local print provider prepends a separator file if the administrator has specified one, then delivers the job to the port monitor responsible for the printer's output port.
Continue reading below for descriptions of print processors and the data types they support, or click here for job modification troubleshooting tips.
WINPRINT
This print processor is installed by default. It supports the following data types:
RAW
This data type indicates that the spooler should not alter the job at all. The job returns to the local print provider, which adds a separator file, if necessary.
RAW is the default value for the Default Datatype.
RAW [FF Auto]
WinPrint checks for a form-feed at the end of the document. If it does not find one, it adds one. WinPrint then returns the job to the local print provider, which adds a separator file, if necessary.
RAW [FF Appended]
WinPrint adds a form-feed to the end of the document and returns the job to the local print provider, which adds a separator file, if necessary.
TEXT
This data type indicates that the print job consists of ANSI text to be printed as hardcopy output. WinPrint uses GDI and the printer driver to construct a new job that achieves this result.
TEXT alteration is useful when an application produces text as a print job but the target print device requires a printer-language job. PostScript print devices are the most common example.
If a job composed of printer-language commands arrives with this data type, the result is a new print job that prints the text of those printer-language commands on the page. Note that most UNIX LPR clients by default send print jobs with an "f" control command, which causes Windows NT's LPD service to assign the job this data type.
If the job is non-ANSI text some characters may print incorrectly, especially those not found in the English character set.
Next, the job returns to the local print provider, which adds a separator file, if necessary.
Journal
This data type exists only on Windows NT 3.x. It indicates that the job was created by a locally-run Windows application, and GDI has partially rendered the job. WinPrint uses GDI and the printer driver to complete the rendering. The result is a print job composed of printer-language commands. After this modification the job returns to the local print provider, which adds a separator file, if necessary.
EMF
This data type exists only on Windows NT 4.0. It indicates that the job was created by a Windows application, and GDI has partially rendered the job. WinPrint uses GDI and the printer driver to complete the rendering. In these respects EMF is similar to Journal, but these data types differ in two key ways:
Operating System Version—Journal is specific to Windows NT 3.x; EMF is specific to Windows NT 4.0
Client/Server Capabilities—A Windows NT 3.x client computer printing to a remote printer never sends a Journal file to the print server. If a Windows NT 4.0 client computer prints to a remote printer, and the receiving print server runs Windows NT 4.0, and the client's driver has the Spool Metafile option enabled, the client sends EMF files to the print server and WinPrint on the print server completes the rendering.
SFMPSPRT
This print processor is installed on Windows NT Server when you install Services for Macintosh. It recognizes only one data type.
PSCRIPT1
Jobs assigned this data type are assumed to contain Level 1 PostScript code sent by a Macintosh computer, targeted at a non-PostScript printer. SFMPSPRT is a PostScript Raster Image Processor (RIP) that interprets the job's PostScript code, producing a series of one-page, monochrome bitmaps, at resolutions up to 300 dots per inch. SFMPSPRT then submits these bitmaps as a single job to GDI. GDI and the non-PostScript driver create a print job that prints these bitmaps on the target print device. Thus, SFMPSPRT converts PostScript into any other printer language, such as PCL. After this conversion the job returns to the local print provider, which adds a separator file, if necessary.
Separator Page Prepended if Necessary
After a print processor has finished modifying the print job, the local print provider prepends a separator file if the print server administrator has specified one in Print Manager. (To view this configuration, select Properties from the printer menu, then select Details.) The local print provider then passes the job to the port monitor that controls the printer's output port
Spooler Sends Job to Locally-Controlled Port
Two spooler components send print jobs to print devices:
Windows NT 3.x—Port monitor
Windows NT 4.0—Language monitor (optional) and port monitor
"Port monitor" spooler components are responsible for delivering jobs to print devices attached to locally-controlled ports. Windows NT supplies port monitors for several different kinds of ports. For example, the local port monitor is responsible for delivering jobs to parallel and serial ports, and to local and remote file names. Other monitors are responsible for delivering jobs to network-attached print devices or print servers.
Port monitors are similar to business couriers who take a sealed message from one office to another, but do not know the content of the message or who at the receiving office will read it. Port monitors deliver print jobs over a communications channel without regard to content. The port monitor provides compatibility with communications hardware (such as the network adapter of a network-attached print device) and software (such as an LPD service), not with the print device itself. (Compatibility with the print device is the print driver's responsibility.)
Language monitors, available only with Windows NT 4.0, receive jobs from the local print provider, and pass them to port monitors. Language monitors implement bi-directional communication with print devices. Continuing the previous analogy, the language monitor is similar to a receptionist at the sending office who works with a courier to manage the flow of sealed messages, but like the courier, does not know the content of those messages.
The spooler can use a language monitor to obtain status information from the print device, such as how many pages have printed, or whether a paper jam is interrupting printing.
The flow of control depends on whether a language monitor is active, and which port monitor is responsible for the target printer's port.
Click here for general port monitor troubleshooting tips.
PJL Language Monitor
This language monitor communicates with PJL-capable print devices, including the HP LaserJet Series III Si, and all Series 4 and Series 5 devices, if connected to one of the server's parallel ports.
LPR Port
The LPR port monitor delivers print jobs to RFC1179-compliant LPD servers. These may be network-attached print devices or print server computers (if the print server runs Windows NT, the job goes to its LPD service). Some network-attached print devices that support TCP/IP are not compliant with RFC1179: some do not implement the entire specification, others implement a proprietary specification. The same is true of print server computers, including UNIX computers. This port monitor requires the TCP/IP protocol.
AppleTalk Printing Devices
The AppleTalk port monitor delivers jobs to network-attached print devices or to AppleTalk print servers. (Such print servers are typically Macintosh computers, but might be Windows NT computers running Services for Macintosh.) This port monitor requires the AppleTalk protocol.
Digital Network Port
This port monitor delivers jobs to DEC network-attached print devices, such as the PrintServer 17 print device or the 5100 Ethernet Card. Some of these devices can receive jobs over either TCP/IP or DECNet; others are TCP/IP-specific. The DEC port monitor requires either the TCP/IP or DECNet protocol.
Hewlett-Packard Network Port
This port monitor uses the Data Link Control (DLC) protocol to deliver jobs to HP JetDirect network adapters and stand-alone devices such as the HP JetDirect EX, which in turn deliver the jobs to their print devices. If the Windows NT computer has multiple network adapters, this monitor communicates through only one of them, regardless of how many are bound to DLC.
PServer-Compatible Print Device
This port monitor is supplied with File and Print Services for NetWare (FPNW). It creates "queues" from which PServer-compatible network-attached print devices pull jobs for printing. This port monitor requires the NWLink protocol.
Lexmark TCP/IP, Lexmark DLC
These Windows NT 4.0-specific port monitors deliver jobs to Lexmark network-attached print devices, such as the MarkNet XL network adapter and the MarkNet XLe external device. All Lexmark network-attached print devices in production can receive jobs over either TCP/IP or DLC, or both, and you must install the appropriate protocols to use them.
Local Port Monitor
The local port monitor delivers jobs using parallel and serial ports, the built-in FILE: port, and ports you create that print to file names or UNC names.
If the printer prints to a parallel or serial port, the local port monitor communicates with these ports' drivers to deliver the job to the print device. If the printer prints to the FILE: port, then when this port monitor receives a job it displays a dialog box asking which file it should write the job to.
When you establish a printer with the Create option, you can select Other from the Print To list, and then select Local Port to define a custom port. You can enter any of the following as a port name:
A path and file name—Jobs to this port are automatically written to the designated file. The printing process thus ends without delivery to a print device.
A UNC name—Jobs to this port are sent to the shared printer represented by the UNC name. The job is delivered to the print server through the Windows Network redirector or the NetWare Network redirector.
UNC name ports are useful when you want to deliver jobs to a remote print server, and you want the spooling or job modification options normally reserved for jobs to local print devices.
NUL:—Jobs to this port are deleted without being delivered to any print device. This is often useful for capacity testing: a printer that prints to this port can receive, spool, and modify thousands of test jobs without wasting any paper.
Spooler Sends Job to Remote Print Server
When you establish a printer with the Connect To option in Print Manager, the Windows NT client computer makes a connection to a print server on the Windows Network or NetWare Network. The printers on this Windows NT client receive jobs only from locally-run Windows applications (not from network clients or from locally-run non-Windows applications) which communicate with GDI to create fully-rendered print jobs (consisting of printer-language commands) which are delivered to the remote print server without being spooled or modified by the client's spooler.
The flow of control depends on the remote print server, as outlined below.
Click here for troubleshooting tips.
Windows NT Print Server
The Windows NT client delivers the job directly to the Windows NT print server.
NetWare Print Server
The Windows NT client uses its NetWare Network redirector to deliver the job to the print server. That server typically runs Novell NetWare, but might run Windows NT Server with File and Print Services for NetWare.
Non-Windows NT, Windows Network Print Server
The Windows NT client uses its Windows Network redirector to deliver the job to the print server.
Network Redirectors
Windows Network Redirector
This redirector sends print jobs to Windows Network print servers using any of several protocols, including TCP/IP, NWLink (IPX) with NWNBLink, and NetBEUI. These print servers typically run Windows NT, but may run Windows 95 or Windows for Workgroups. The print server may forward the job to yet another server, or may deliver it to a print device.
NetWare Network Redirector
This redirector sends print jobs to NetWare Network print servers using NWLink (IPX). These servers typically run Novell NetWare, but may run Windows NT with File and Print Services for NetWare. The print server may forward the job to yet another server, or may deliver it to a print device.
Gateway Services for NetWare (uses NetWare redirector)
This Windows NT service uses the NetWare Network Redirector to forward print jobs from network clients to NetWare print servers. Using the redirector alone for this purpose, without GSNW, usually causes jobs to arrive at the NetWare print server in the wrong security context, so they do not print. The print server may forward the job to yet another server, or may deliver it to a print device.
Print Device Interprets Print Job
A print device is a special-purpose, programmable computer. The print jobs it receives are programs written by other software, such as Windows' GDI, in interpreted languages such as PostScript and PCL. The print device runs built-in interpreter software on processor hardware that sometimes is comparable to a desktop PC. The print device produces hardcopy output by interpreting the print job, just as a PC might produce screen output by interpreting a BASIC program. The interpreter software, like any other software, may have bugs.
Few printing problems result from interpreter bugs, or from damaged or defective print device hardware, but keep the possibility in mind.
Troubleshooting
When troubleshooting printing problems, the most useful technique is changing the printing flow of control to avoid using a particular component: if this changes the symptoms then the component you isolated is involved in the problem. This section lists tests that are often useful in isolating components.
Creating a Printer, Connecting to a Printer
Create a new printer with a different, simpler name
Share the existing printer with a different, simpler name
Quit sharing a printer, then reshare it
Delete the printer that is malfunctioning, stop and restart the spooler service, and recreate the printer
Try a different client operating system, using the same type of connection
Try the same client operating system with a different type of connection
Try a different client operating system and a different type of connection; note that Windows NT can both send and receive jobs over any type of connection
Log on to the client as a different user, preferably a network administrator
Creating a Print Job
Create and print a new document containing only a few characters, formatted in one, commonplace font, with no graphics or embedded objects
Print from the same application running on a different client
Try another version of the same application
Test with a different application
Verify you have the right printer driver (make and model), configured to match the target print device's configuration (memory, fonts, paper trays, and so on)
If the device supports multiple languages (such as PCL and PostScript) try a driver for one of the other languages
Delivering the Job to the Spooler
See the suggestions for Creating a Printer, Connecting to a Printer. Also,
Print to a file on the client, and copy that file to the Windows NT print server. Log on at the print server, share the target printer, then from a command prompt copy the file to the print share. For example:
COPY CLIENT.PRN \\SERVER\PRINTER
If the symptoms change then the problem involves job delivery or modification.
Modifying the Job
Reconfigure the client so that the server-side service assigns a different data type
Use a different type of connection (Windows Network, NetWare, LPR, and so on) to force the job to receive a different data type
Change the Default Datatype value in Print Manager
Print to a file on the client, then send that file to a Windows NT printer that prints to FILE:. If the client's and server's output files are identical, the server didn't modify the job.
Delivering the Job to the Destination
Print to FILE: to verify that the local port monitor finishes processing the entire job
Print to the same device using a different type of port (many network-attached print devices support several port types)
Print to a different device of the same make, model, and configuration
Print to a different printer on the same remote print server
Print to a different remote print server
Print to a print server running a different operating system
Conclusion
Windows NT is a tremendously flexible print server, due to the modularity of its printing architecture. That modularity lets Windows NT receive jobs from many different clients, meet those clients' expectations, and deliver jobs to a wide variety of print devices and other print servers. Understanding the Windows NT printing flow of control lets you step through any Windows NT printing scenario to understand what components are involved, how they affect the print job, and how to alter the flow of control to isolate a misconfigured or malfunctioning component.
More Information
On TechNet
When troubleshooting a specific problem, make sure your queries include "Windows NT" and "print," as well as:
Error message text, if any
Descriptions of symptoms
A client type (such as LPR)
A server-side service (such as SFM, LPD, or FPNW)
A spooler component (such as local print provider, print processor, or portt monitor)
A data type (such as RAW or TEXT)
A port type (such as LPR Port)
A network protocol (such as TCP/IP, DLC, or AppleTalk)
For general information see:
- 132460, Troubleshooting Windows NT Print Server Alteration of Print Jobs
Microsoft TechNet
September 1996
Volume 4, Issue 9