|
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 environments
- How to let different users capturing the same LPT port
- How to redirect the print jobs to the user's preferred printer
- How to create a common configuration for the remote users
- How to enable DOS printing for some remote users only
On 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.
If 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. In this case the DOS program
prints to a single LPT1: port for all the users, but we need to separate the
jobs coming from different RDP
users who are printing simultaneously.
Printfil 5.5 or newer makes this 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)
You only have to ensure that each remote user running Printfil on the WTS
has its own Printfil configuration pointing to a different "File to check".
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.
If you're still using an older Printfil version, Mode 0 is not
available. In this case we strongly suggest you to upgrade your Printfil
copy.
Note: All the following description was for older Printfil versions, where only capture Mode 1, 2 and 3 were available.
To capture an LPT port in Mode 1, 2 or 3, 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 Printfil will create its own virtual printer to capture the LPT output, 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.
After creating the "Printfil" virtual printer this way, the jobs captured from a single LPT1: port will be forwarded to W:\Printfil.txt, which results in a different file for each RDP user. This way, the user's specific Printfil instance, which has been started automatically after the RDP logon, will manage its own print jobs separately from those of the other users.
So:
That's all. Now the print jobs captured from a single LPT1 port will be captured separately for each remote user. Other users eventually already logged in the WTS will have to logout the server and relogin again before having the "W:" drive automatically added to their own "My Computer" icons.
Supposing you've created the "W:" drive when configuring Printfil to capture the LPT output, but later on you've found that your source program can "print to file" itself and you want to remove the virtual drive from your Terminal Server configuration, then:
Each 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 1 was 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
sent to a specific printer which is not the default one.
The simplest way to do this is to enable the "choose" (printer) option in
the Printfil's standard configuration dialog. This way, each time Printfil
captures a source job, it will ask the end user for the desired destination
printer by the standard Windows "choose printer" dialog box, which contains all
the printers which are available to that user in that moment. With an additional
mouse click for each captured print job, the user can choose his preferred
destination printer, either local or remote.
Alternatively, if you wish to specify a particular printer without user
intervention, you have to make consistent the printer's names on different RPD
sessions, or you have to write a logon script to change the default printer for
that user or to specify the desired printer's name in the optional
Printfil.CFG file.
As 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 nothing special to do for Printfil: the client configuration is built
automatically.
The standard Printfil setup places a shortcut in the "Commonstartup"
Windows Folder (Start -> All Programs -> AutoStart) so that each user loggin
in the WTS will start their 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 which will login 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 doesn'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
and start Printfil only for the users
you want it started. You can do this in different ways:
C:\> EDIT START.BAT
START.BAT @echo
off |
Pricing
|
Special ! Free Choice of Complete Excel Training Course or Excel Add-ins Collection on all purchases totaling over $70.00. ALL purchases totaling over $119.00 gets you BOTH! Purchases MUST be made via this site. Send payment proof to [email protected] 31 days after purchase date.
Instant Download and Money Back Guarantee on Most Software
Excel Trader Package Technical Analysis in Excel With $139.00 of FREE software!
Microsoft � and Microsoft Excel � are registered trademarks of Microsoft Corporation. OzGrid is in no way associated with Microsoft
Some of our more popular products are below...
Convert Excel Spreadsheets To Webpages | Trading In Excel | Construction Estimators | Finance Templates & Add-ins Bundle | Code-VBA | Smart-VBA | Print-VBA | Excel Data Manipulation & Analysis | Convert MS Office Applications To...... | Analyzer Excel | Downloader Excel
| MSSQL Migration
Toolkit |
Monte Carlo Add-in |
Excel
Costing Templates