>Please find the feedback as required by you:
>
>First, can you check that a Windows print job initiated via RDP comes out properly on the remote printer?
>Ans. Yes I checked the window printing.
>
>Second, assuming RDP print job forwarding is working OK, have you made the printer installed on the server shared? What is its share name?
>Ans. The share name is EpsonLQ
>
>Third, was the NET USE command in the batch file example I gave successful? After you run the batch file, you can start up a CMD window, and type NET USE. It will show you a list of all current redirections - both drive letters and DOS ports. Check that LPT1 has been redirected properly to the shared printer on the server.
>Ans.
>Status Local Remote Network
>---------------------------------------------------------------------------------------------------------------------
>OK P: \\192.168.2.110\e-server\packg Microsoft Windows Network
>OK R: \\192.168.2.110\e-server\abcraw Microsoft Windows Network
>OK LPT1 \\jebelaliserver\EpsonLQ Microsoft Windows Network
>The command completed succesfully.
>
>Come to think of it, could you tell us:
>
>- what is the server name?
>Ans. jebelaliserver
>
>- what is the printer's share name on the server?
>Ans. EpsonLQ
>- can you paste in here the contents of the batch file you created?
>Ans. I typed/copy & paste exactly whatever you mentioned. which is as follows:
>
>@ECHO OFF
>
>REM RemoteDOSPrint.CMD
>
>REM First, remove any existing LPT1 printer port redirection:
>NET USE LPT1 /DEL
>
>REM Now, redirect DOS printer port LPT1 to the local shared printer on the server:
>NET USE LPT1 \\jebelaliserver\EpsonLQ
>REM If you'd like this redirection to persist across logons, you can add /persistent:y to the end
>
>REM End of CMD file

Hmm, it looks like everything should be OK. Here are some other things to check:

1. Could it be a permissions issue? As a test, could you log on to the server console, using RDP, as the server administrator to see if that makes any difference?

2. Is there any security or firewall software running on the server that might be interfering with the spooling of DOS print jobs?

3. I briefly Googled the "local downlevel document" errors you listed earlier. It looks like, in some cases, configuration of the printer on the server could cause this. It appears that in some cases getting this type of error can "freeze" the queue, so if you can't clear the queue you may have to restart the Print Spooler service.

To troubleshoot this, the idea is to make the configuration as simple as possible. In the Printer Properties:

- on the Ports tab, make sure that "Enable bidirectional support" is NOT checked, and that "Enable printer pooling" is also NOT checked

- on the Advanced tab, by default Spooling is probably selected, with "Start printing immediately" currently selected. For one test, you could change the latter selection to "Start printing after the last page is spooled". For a second test, you could change the major choice to "Print directly to the printer".

- also on the Advanced tab, make sure "Enable advanced printing features" is NOT checked

- in the Print Processor section, the print processor should be WinPrint, and default data type should be RAW.

- If your application uses the Epson in graphics mode, you will need to continue to use your current Epson printer driver. If your application prints in plain text mode, you could try changing the printer driver to "Generic/Text Only" to see if that makes a difference

4. There is a Registry setting that affects spooling of MS-DOS print jobs. It is the LPT_Timeout value, as explained in http://support.microsoft.com/kb/102059 . By default, this value is 15 (seconds). With modern computers (say, faster than 1GHz), you can safely reduce this value to 5 seconds, or even 2 seconds with fast computers. This will reduce the time it takes for your application to print, and may help if a queue or RDP is timing out somewhere.

Another thing worth testing is whether the issue is with MS-DOS printing in general, or if it happens just with your application:

1. Log on to the server via RDP and run the RemoteDOSPrint.cmd file so you should be ready to print

2. Create a DOS text file somewhere on the server, named TextFile.txt

3. Instead of running your application, start up a manual CMD window. In that window:

a. use the CD command to navigate to the folder that holds TextFile.txt

b. run this command:

COPY TextFile.txt LPT1 /b

c. Check if the file prints on the remote printer. If not, check the status of the print job in the server print queue. Wait at least 15 seconds, unless you have reduced LPT_Timeout as per the MSKB article above.

d. If the job does not print while the CMD window is open, try closing the CMD window

If you find that the above COPY command spools and prints successfully, but your application does not, that will give us another clue.