Previous | Table of Contents | Next |
Step 1: Check the Application
Your first step when facing a printing problem will be to check the application. Although this sounds rather silly, I see a lot of printing problems where, say, a database is producing no output for the spooler to process. One would think that the database manufacturer might clue the user in that his or her report parameters produced no output, but thats not always the case. (You can always disable the queue and print again to see whether a job is even being generated.)
This might sound crazy, but check to make sure that a Windows 95 user has logged in to the network before you do any of these steps.Windows 95 allows a user to bypass the login window by pressing Esc; therefore, a user might be trying to print to a network printer without being logged in to the network.
More complex problems can occur when an application is either improperly configured or has DLL problems that do not manifest themselves in other ways. For example, I have seen an application that needed special DLLs to print a file; when these DLLs were corrupted, either by another application installing its own versions of these DLLs or by simple hard drive problems, the application stopped printing, even though it otherwise behaved flawlessly.
You can find out whether the printing problem stems from the application by printing from another applicationfor example, Notepad or the WordPad. In UNIX, type the following to check printing outside of a given application:
lp -dprintername /etc/services
Step 2: Check the Driver
If two programs on a given workstation are not printing, I like to introduce another printer into the picture. In particular, I like to set up a local printer with a destination of LPT1. If the workstation has no printer attached to LPT1, dont despairjust set it up with a destination of FILE, which will simply direct the output to the hard drive. You can then view that file and make sure its okay.
To make sure that the print file is actually okay, you can transfer it to another workstation that does have a printer directly attached and then type something such as this:copy /b PRINTFILE LPT1:
To rule out driver problems, make sure to use a different driver for your test printer. I like to use Generic/Text only for some things, but, of course, this wont work too well if your application is graphical. Because youre ruling out the driver, it doesnt really matter which print driver you use, as long as youre fairly confident that its a good driver.
Sometimes, even though you have a good driver, your workstation might be running out of gas while the driver is processing the metafile. Check the resources as we discussed in Hour 8, Hard Basics: Guide to Being a Hardware Geek.
Step 3: Check the Spooler
Can someone else spool to the server queue? If so, your first guess might be that the problem lies with the workstation. In this case, I want to make darn sure that the printer, as set up on the workstation, is going to a valid queue and has not lost its mind.
To do this, I usually go ahead and set up another printer on this workstationpointing to the correct server queuejust to make sure. If that doesnt work, I set up another queue to another server, just to prove that queuing is messed up on this workstation. If this works, it means that the problem might not lie with the workstation; youve probably got some sort of communication or security problem between this workstation and the original server queue.
Check whether you can see the server in any other way: Can you log in to it? Ping it? Check your security rights to this queue, or, even better, try to spool to it as someone else.
Step 4: Check the Server
The server might show that its getting the spool file just finewhereupon the output just disappears into thin air. A couple things might cause this that arent limited to communication errors between the workstation and the server. In this case, you might want to rule out a communications problem.
One way you can verify that the server is getting passed a good spool file is by taking a look at it at the moment the server gets it. You can do this by putting the printer in question offline, because the server will delete the spool file after it thinks the printer has processed it. Because youre blocking the printer, spool files will be left alone. You can then take a gander at the spool file thats being passed to the server. Where does the spool file live? Table 18.1 gives you an idea.
Operating System | Spool Files Kept In |
---|---|
Windows 9x | %WINSYSDIR%\spool\printers\jobnum.spl |
Windows NT | %SYSTEMROOT%\system32\spool\printers\jobnum.spl |
(Intra)NetWare | QueueVol:SYSTEM\QUEUENUM.QDR |
UNIX | /usr/spool/lp/temp (actual queue files) /usr/spool/lp/requests (control files) |
Previous | Table of Contents | Next |