How to make DOS programs on Terminal Server printing to local or remote Windows printers
Introduction: This article explains how to use Printfil to allow a DOS or Windows-Console program, installed on a Windows Terminal Server, printing to a local or remote Windows printer, even if it's not DOS compatible, like a Windows-Only (GDI) USB printer or a virtual printer (like Fax printers, PDF writers, etc.)
It covers different topics:
How to install Printfil on Terminal Server environmentsOn WTS environments Printfil is installed only once, on the server, by using the standard Printfil setup program, while logged in as Administrator, either locally or even through an RDP (Remote Desktop Protocol) connection.
There isn't a different installer for Terminal Server because the unique Printfil version automatically detects whether it's running on a Windows Terminal Server or not, and behaves accordingly.
There's nothing additional to install on the remote client machines but the usual RDP client.
Once installed, a specific Printfil instance is run on the server for each user loggin in the WTS. That Printfil instance takes care of intercepting the user's specific jobs and redirect them to the user's specific choosen printer (either local or remote) with the user's specific settings: each user in fact normally have a different Printfil profile in his own home directory containing his own preferences, like the destination printer, page margins, text color, whether to show print preview or not, etc.
How to make different RDP users capturing the same LPT portIf your source Ms-Dos or Windows-Console program is already printing to file (a different file for each remote user), then you just have to point Printfil to those files (by the "File to check" entry in its own configuration dialog) without having to capture the LPT1: port.
Foe example, if the source program sends its print jobs to %HOMEPATH%\Spool.txt, then Printfil has simply to check for "[e:HOMEPATH]\Spool.txt" to capture the print jobs of each user.
If instead the source program only prints to LPT1:, then you'll have to configure Printfil to capture that parallel port. This is very easy: you just have to open the Configuration -> Standard Printfil's dialog, select the LPT port you want to capture (from LPT1: to LPT9:) and select Mode 0 (zero).
If you're using an old Printfil version, Mode 0 may not be available, and capturing a parallel port in your WTS is much harder. In this case we strongly suggest you to upgrade your Printfil installation to the newest version.
The DOS program prints to a single LPT1: port for all the Windows users, but you need to keep separate the jobs coming from different RDP users who are printing simultaneously.
To do that you just have to ensure that each remote user running Printfil on the WTS has its own Printfil configuration pointing to a different "File to check". That file infact is used as a temporary container for data captured from the selected LPT port. The default value for this field is [e:HOMEPATH]\filename.txt, which makes each user looking for a different Filename.txt in its own home directory, but you can also use a different path, provided the user running Printfil has write permission on that directory and each user is using a different file to contain the captured LPT output.
That's all. Now the print jobs captured from a single LPT1 port will be captured and printed separately for each remote user.
How to redirect the print jobs to the user's preferred printerEach time you log in a Windows Terminal Server via RPD, the remote printers gets a new name. For example: HP LaserJet (from REMOTE-PC) in session 1, the first time you login, and HP LaserJet (from REMOTE-PC) in session 2 after the same user logout the server and login it again.
If HP LaserJet (from REMOTE-PC) in session 1was selected in the user's Printfil profile, the next time that user log in the server, that printer might be "no more available" (because its name has changed) so Printfil sends the user's print jobs to the user's default printer.
That's usually enough for the average user, but sometimes you may want the jobs to be sent to a specific printer which is not the default one.
There are 3 ways to do this:
How to print to PDF through the "Printfil" virtual printerWhen it's setup to print in GDI mode, Printfil can export your DOS print jobs as PDF files (and eventually it can even automatically send them out via e-mail) by using GhostScript and the Printfil virtual printer, without having to install additional third party PDF writers on the server.
To do so Printfil makes use of the Printfil virtual printer, and a virtual disk drive (usually named "W:") which is automatically mapped by Windows to the specific user's home directory on the server (usually "c:\documents and settings\username\").
So, when running the "Create Printfil virtual printer" function, if that virtual disk is not already present in your WTS configuration, Printfil will ask you to automatically run the Terminal Services Script required to create it on your server. You'll have to answer "Yes, I want to create it now", and follow the onscreen instructions.
At the next step during the creation of the "Printfil" virtual printer you'll be asked to specify which temporary file you want to use to store the captured LPT output. You'll have to choose a file name in the virtual disk above (W: or whatever drive letter is configured on your WTS), like W:\Printfil.txt for example.
Attention Please: If you don't place the temporary file on the virtual disk above, cuncurrent PDF's created simultaneously by different RDP users may be overwritten or otherwise corrupted.
Supposing you've created the "W:" drive, but later on you choose to produce PDF files by using an external PDF writer and you want to remove the virtual drive from your Terminal Server configuration, then:
How to create a common configuration for the remote usersAs we've said above, each remote user who log in the Terminal Server via RDP will have his own Printfil instance automatically run on the server managing his own print jobs with the settings stored in his own %HOMEPATH%\WINDOWS\PRINTFIL.INI file.
The Printfil.ini file is created automatically by Printfil in the user's home directory, the first time that user log in the WTS and run Printfil. It contains the Printfil's default setting.
When you'll have completed your Printfil testing on your WTS you'll probably end up with a customized Printfil configuration which matches your source program (custom escape sequences for example) and your preferred settings (print preview, page margins, text color, the path where you want to archive the print jobs etc.)
So, instead of applying those custom configurations for each user on your WTS, you may want to have a "template" Printfil.ini which is automatically applied to any new user loggin in the Terminal Server.
To do so, you just have to create a single C:\WINDOWS\PRINTFIL.INI (In the real Windows directory, not the user's specific one), containing the standard settings. Each new user which will run Printfil for the first time will have a Printfil.ini created in its own Windows directory, containing your centralized (c:\windows) custom settings instead of the default Printfil ones.
The C:\WINDOWS\PRINTFIL.INI file does not necessarily have to be complete. For example it might contain only the [Sequences] section, and the "ArchiveRoot" entry in the [Options] section. If it contains only SOME settings, the newly created %HOMEPATH%\WINDOWS\PRINTFIL.INI file will contain those entries PLUS the missing entries filled out with the default Printfil values.
In this way you can to create a SINGLE printfil.ini which match your application when you first install Printfil on your Terminal Server Windows, then you can completely forget about new clients/users which might be added to the server later on.
This is particularly useful if you are an IT Professional building WTS servers for your Clients and the customer has an internal network administrator creating/deleting Windows users, because in this case you don't have to do nothing special for Printfil: the client configuration is built automatically.
How to enable Printfil for some users onlyUnless you've unticked the option when installing Printfil, by default the setup program places a shortcut in the "Commonstartup" Windows Folder (Start -> All Programs -> Startup) so that each user loggin in the WTS will start his separate Printfil instance automatically. It does it that way to make things simpler, because usually all the RDP clients needs to run Printfil.
Each Printfil instance running on the server will use a Printfil license from the total number of licenses installed on the server. If the installed licenses are not enough to cover all the users, the latest users loggin in the WTS server will receive a "Not enough Printfil licenses" message and Printfil will not run for them.
In some situations you may have some remote users who don't need to run Printfil, so you may want to avoid starting it for those users.
To do so, you'll have to remove the shortcut in the Commonstartup Windows folder (if you made Printfil creating it at installation time) and start Printfil only for the users you want it started. You can do this in different ways: