Netware Printing to Windows 2003

Hello
I have an "inhouse" application that is designed to work with Novell Netware print queues. (We do not have the source code)
This application prints reports to a printer connected locally to a PC with nprinter command running.
Now we need to replace Netware with Active Directory (No Netware anymore, :-s), but continue using this application.  
The app works well in Windows server, but we cannot print because the application sends the print job to a queue in our netware server.
Is there any way to redirect these print jobs to a shared printer in Windows?
How could I make it work, since we cannot change the source code (at least until we find the programmer)?
tsurugiAsked:
Who is Participating?
 
Computer101Connect With a Mentor Commented:
PAQed with points refunded (350)

Computer101
EE Admin
0
 
ShineOnCommented:
Is it a DOS app?  Do you capture the queue to an LPT port?
0
 
tsurugiAuthor Commented:
Hello
It's an app in FoxPro for Windows, and it doesn't capture to an LPT port.
I think it's sending the files directly to a queue of the netware server.
0
Introducing Cloud Class® training courses

Tech changes fast. You can learn faster. That’s why we’re bringing professional training courses to Experts Exchange. With a subscription, you can access all the Cloud Class® courses to expand your education, prep for certifications, and get top-notch instructions.

 
ShineOnCommented:
It's in FoxPro for Windows and it doesn't even use a Windows printer object?

NetWare 5.1, right?  I suppose you're using IPX because of this app's print queue requirements?   Nprinter doesn't matter much by the way - it's just a way to service the queue and send print to the printer.  Pserver probably would work too, if it's an old dot-matrix or line printer, or a laser printer that uses PJL.  The concern is how the program is getting the output into the queue.

Generally speaking, any app that prints to a NetWare queue does it through either port capture or by defining a special direct-to-NDS-object port within the Windows printing environment, so I'm surprised to hear it has nothing defined on the PC it's running on.

FoxPro runs on the client, regardless of where the database files are stored, so it is running on a pc, not on the server.  There's got to be some evidence - a capture command in the Novell login script or a printer object on the PC to which the stuff spools on its way to the legacy NetWare print queue.
0
 
tsurugiAuthor Commented:
I think it does a port capture, but maybe a temporal capture while running the app?
It works with nothing defined in the client.
In the login script there are only drive maps, and the printer used is not "installed" in clients.
I think I'll have to contact the original programmer to help us.
0
 
ShineOnCommented:
If it's doing a capture dynamically, from within the program, you're probably right.  The code would have to be changed to do a NET USE instead of a CAPTURE.
0
 
tsurugiAuthor Commented:
Yes.  But the idea was to redirect this capture to a printer without Netware, and without having to modify the code.  Maybe a 3rd party tool, or something.  Anyway, I could contact the programmer and he's willing to help us.
0
 
ShineOnCommented:
I understand what the idea was, but if the program is issuing a NetWare CAPTURE command, it will not work unless you're connecting to NetWare on the back end and have a Novell client (or the crapware(tm) client that comes with Windows) installed.

Windows Server 2003 does not have the old FPNW service that NT and 2000 Server did, so you can't make your Windows 2003 server act like a NetWare 3 server any more.  That's the only thing in a windows-only environment that would have fooled the program/client into thinking that there was a traditional NetWare queue available that could be captured using the CAPTURE command.

Since Windows does not natively support the CAPTURE command, but uses the old LanMan Server "NET USE" command, the program will have to change.

I was hoping the program used an LPT port that was captured in a login script.  You could've worked around that by using NET USE with persistence.
0
 
ShineOnCommented:
Of course, if you wanted to, you could write a program that issues NET USE based on the command-line string it receives, and call it "capture.exe."   Hmm.  I wonder if some enterprising Windows admin did that once upon a time...  I know that NetWare admins would do that kind of thing on the "other side of the aisle..."
0
 
tsurugiAuthor Commented:
After all, I contacted the original programmer and he made the modifications in the code.
It's working fine now.
Thank you.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.