Link to home
Create AccountLog in
Avatar of silentreproach
silentreproachFlag for United States of America

asked on

Print job passes through Win7 LPD queue, but nothing prints.

We have some kind of unix (unknown) server that has for years sent print jobs to USB printers (different models: HP, Lexmark, Epson), each of which are attached to a Windows computer on the same network. The computers were upgraded to Windows 7 and since then, only one of 3 printers is working with Windows LPD. The computers were previously running Windows 2000 and 3rd party LPD server software.

Here is the setup on each computer:

- Each Windows 7 computer has all Windows Features turned on under Print and Document Services (including LPD, etc.).
- The ip addresses for each workstation are unchanged.
- In Devices and Printers, a separate queue has been added to handle LPD, with driver set as Generic Text Only and the share name set to the correct LPD queue name.
- The firewall is not blocking port 515 and in fact, print jobs seem to flush through the print queue, but nothing comes out on the printer.

How can I troubleshoot this and determine why it works on one computer but not another? Please note that I have little control on the server side, which we are trying to keep unchanged.
Avatar of tmoore1962

The setup on the workstations depends on your intended usage.  I can provide some detailed instructions but need some additional info. (at least question #1 answered)

  1- Do you want the Windows 7 PCs hosting the printers to be binary pass-through devices?        
      a- If yes, this puts the onus of having the print driver installed on the UNIX system or else you could be getting garbage. The PC basically becomes a traffic cop for print jobs and does not modify the content. This would be where having 2 different printers setup would be a good thing.  One normal and one pass-through.
      b- If no, then there is no need to have a separate printer defined on the workstation for each printer. The printer is installed on the PC using the driver for the printer.  The LPD service will just provide another way to get a job into the printer (print queue) and will be processed according to the driver settings of that printer.

  2-  What did you make the printer names on the PCs?  
      a- Some systems (AIX, etc) have limits on the number of characters that can be in a printer name.  I recommend 6 characters or less.
      b- I assume that the printer names did not change on the UNIX host. The OS on the PCs that host the printers was the only change.

  3- Does the UNIX host send to DNS names or TCP/IP addresses for it's printer definitions?
      a- If DNS names, then you would also need to ask if they are resolving to the DNS of your network or using a local host file.  
      b- Ask the UNIX Admin if he/she can just give you the:
             UNIX Printer Name
             the Host for the LPR output of each printer
             the port for the LPR output of each printer
Avatar of silentreproach


Use this site to confirm your LPD configuration:
Thanks! However, I see nothing new that helps. Our server setup is correct, since it has been working for years. Our Windows setup is correct, except that only one of the printers is working (even though all Windows computers are set up the same). Is there something specific in this document that you feel applies?
I have no idea about that document link but am willing to assist you in troubleshooting and resolving this issue.

  1- Since you said that you are using the Generic Text driver in Windows, do we know if the UNIX box is sending raw text or if it is using something like CUPS that loads a driver to send the correct printer control codes?  
        This is important because it determines whether or not the Windows printer needs to be setup as a binary pass-through printer.  That might have been setup on the old system and you would not have known unless you checked specific registry keys.  

  2- Can you manually LPR a text file to each PC/printer and does it print successfully?
         a- Create a text file with 5 or 6 lines of   This is a test  and save it as c:\temp\test.txt
         b- Open a Command prompt
         c- Send the test file using LPR -S PCipAddress -P PrinterName c:\temp\test.txt
     The results of this test will lead us in the right direction.
   Item 2 assumes that a workstation has LPR port monitor (Win 7&8) installed in order to perform this test.
eerwalters - I greatly appreciate your insightful comments! Some answers to your first batch of questions:

1. I'm not sure what you mean by binary pass-through device. I do know that at print time, the user typically sends the print file in plain text only. There is an option to send the print file with a few PCL5 escape sequences included to change fonts on Laserjet printers, but none of these printers understand PCL. Otherwise, there is no "driver" on the server side. So from this point of view, I suppose I'm expecting the print job to "pass through" and is the reason why Generic Text Only is the chosen driver on the Windows side.

a) The printer names correspond to the names as they were defined in the SDI LPD software they were previously using on the old computers. They are 6 character names, provided by the server admin (eg. ptrhp1). This is the other reason why I set up a separate printer driver/queue on Windows. It's my understanding that the printer/share name must be the same queue name defined on the server and that this is how Windows LPD knows which printer to send the output to (eg. printer named HP Photosmart 7400 would not be found, but printer named ptrhp1 would be).

b) Correct. Nothing changed on the unix host and the printer hardware is unchanged. The OS on the PCs that host the printers and of course the LPD software on the PCs are the only changes.

3. The server uses DNS names and are resolved using a local host file. The DNS names should be okay, since the ip addresses on the new PCs are the same as they were on the old PCs. Also, remember that one of the 3 printers does work, so at least that one is resolving correctly. The unix printer name "ptrhp1", host name is, LPR port is standard 515.
A binary pass-through device makes the Windows printer act more like a traffic cop because it just directs the incoming print job through the print queue and on to the printer without touching the contents of the job.  Just using a generic text driver does not enable this functionality.
  A normal Windows printer takes the incoming data and adds items from the driver to allow the correct control codes, etc. to be sent to the printer and sends the print job to the printer.
  In this instance, if the UNIX system is just sending raw text, I would recommend using the normal Windows print drivers for the installed USB printer to insure that it processes the jobs correctly.

  Please try the manual LPR tests specified earlier from another Windows machine to the PCs hosting the printers and let me know the results.
1. I tried the manual LPR test from another Windows machine and tested both queues:

a) Generic Text Only queue (using default print processor winprint, RAW):
LPR -S MYPC.mydomain.local -P ptrhp1 C:\temp\test.txt
LPR flushed the print job through the queue with no errors and no printer output. At least this indicates that the queue name I'm using is valid.

b) The normal Windows queue (using default print processor HP2600PrintProc, IMF):
LPR -S MYPC.mydomain.local -P "HP Color LaserJet 2600n" C:\temp\test.txt
The test file gets stuck in the queue. Tried with various print processors in Advanced settings, but nothing seemed to affect it. Also tried shortening the name to HP2600 - no luck.

I then used the LPR tool to send the same C:\temp\test.txt file to a known working Jetdirect printer - success! So, my test file is good and I seem to understand the syntax of the LPR command.

2. Just for kicks, I also tried to check the queues with the LPQ command:
LPQ -S MYPC.mydomain.local -P ptrhp1 -l
It listed an empty queue. But again, it appears that at least the queue name is valid.

LPQ -S MYPC.mydomain.local -P "HP Color LaserJet 2600n" -l
then it says "Windows LPD ServerError: specified printer does not exist". I guess LPR is okay with long printer names, but LPQ is not.

I'm having the problem with printers from 3 different manufacturers. The only printer that DOES work, so far, is an HP Photosmart 7400.
Ok, next step is to send a PCL test page via LPR (file attached).  This should work on any printer that supports PCL6.  Note the results.

Then change the Generic Text Only print queue to be a binary pass-through queue.  You will need to add a new registry entry.  Use the LPDPrinterPassThrough option for the individual printer.  (See the link below, yes it says NT4 and 2000 but the key is the same)
Be sure to restart the LPD Service and Print Spooler after adding the entry.

Send the PCL6test.prn file again and note the results.
Thanks for the additional insight! I'll try this the first chance I get.
Avatar of DansDadUK
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
Attached is a captured print file which is the result of invoking the Print Test Page action using the Windows 8 HP Color LaserJet 2600n driver, and capturing the result to a file.

If you examine the contents, you can see that it is not ASCII, and not PCL XL (it starts with a 'signature' of JZJZ - I'm not sure what this signifies) .
The printer that does work (HP PhotoSmart 7400) supports the printer languages:


Support for PCL3-GUI may (I'm not sure) imply that it provides a limited plain ASCII text capability.
This link provides an overview of host-based printing with HP Color LaserJet 2600.

Note the statement "Host-based printing requires a software print engine in the host operating system, and unlike a PDL (Printer Description Language) printer, cannot accept ASCII text direct from a computer. "

This implies that, in order to print to the HP Color LaserJet 2600, one or the other of the original (*n*x) host, or the intermediate (Windows) host, must (using an appropriate model script or driver) convert the original plain text document into the requisite host-based format.
DansDadUK is correct that I forgot about the 2600 not supporting PCL.  I have all of my test pages scripted for each model that requires custom code, and didn't notice it in my last reply.

  Just use the attached file in testing the 2600 with the previous next step message.
- I sent the non-PCL test page (2600test.prn) to the normal Windows driver queue, via LPR from another Windows computer on the network. No registry keys edited yet at this point. It printed!

- Then, I changed the value of the LpdPrinterPassThrough registry key to 1 for the Generic Text Only queue. Restarted LPD and Print Spooler services. The non-PCL test page prints okay through both queues.

- However, the original raw text file, c:\temp\test.txt, still flushes through the binary pass-through queue (Generic Text Only driver with modified registry key) immediately without printing when submitted via LPR.

- Thank you for the details on GDI printing, interesting! Yes, the HP Photosmart 7400 does work via LPR.
- The printers that previously worked (using SDI LPD software on older versions of Windows), but are now non-working printers are: HP Color LaserJet 2600n, Lexmark Platinum Pro905, Epson Stylus CX4800, Epson WF-2540.
Ok, good info!!
 So we know that the properly coded job prints correctly to the 2600 from either queue.

 I would expect the raw text file to fail using the binary pass-through queue as that queue now only passes the print job to the printer and doesn't modify it.

 Does the raw text file print or fail going thru the normal Windows queue via LPR?
     If it prints, then we can move on to the source of the file
     If it fails, create another or modify the current text file so it is more than 66 lines long and send it.  What are those results?

 Does the PC hosting the 2600 have the latest version of the driver installed?
I'm not sure that the tests so far, although providing some useful information, are addressing the original problem, which (as far as I can make out is):

"Sending print jobs from a *n*x system, via lpr, to a Windows PC set up with an LPD responder, which directs received requests (via the specified queue-name) to the appropriate PC-connected non-PCL printer".

What we don't appear to have established yet (although eerwalters has made reference several times) is whether the plain text source documents are (supposed to be) translated to the appropriate (printer-specific) printer language at the *n*x end, or at the Windows end.

As far as I can make out, the referenced printers don't understand PCL, and probably (almost certainly in the case of the LJ 2600n) do not understand plain ASCII text, so translation of text to target printer language (JZJZ for LJ2600n, ESC/P for the Epsons, etc.) is required at one end or the other.

If the *n*x end is doing the translation (which would have to be specific to each target printer model), then the Windows end needs to use binary pass-through drivers; one way of doing this (as eerwalters outlined) is to use a "Generic/Text only" driver with the LPDPrinterPassThrough registry setting.
If the *n*x end is not doing the translation, then the Windows end needs to use the appropriate printer-specific driver for each queue and target printer; a "Generic/Text only" driver is of no use in this case.

We could perhaps find out what the *n*x end is sending, by temporarily taking the Windows-connected printer off-line, then sending a 'print job' from the *n*x system, and examining the content of the .SPL file created in the relevant spool folder (I think that this will be in the relevant sub-folder within the %WinDir%\system32\spool folder.

As a matter of interest, what was the "3rd party LPD server software" previously used?
The LPD mechanism defines routing, but (apart from a rudimentary distinction between text and binary data) does not provide any print data manipulation.
Avatar of LeeTutor
Not enough information to confirm an answer.
This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.