Best Practices

Determining when to use the ThinPrint Output Gateway driver is best done by ruling out the scenarios it cannot be used with. Since the basic idea of this universal printer driver is to redirect the spool data from one Windows print subsystem to another one it is mandatory that the computer creating the print job and the computer receiving the print job run a Windows desktop or server operating system. For the use of the ThinPrint Output Gateway driver it doesn’t matter where the receiving computer* is located as long as the necessary printer queues are set up. In regards to print performance the following four guidelines will help a design decision in most environments:

* Unless a single central print server is used and print data is sent directly to the print devices without compression a ThinPrint .print environment will contain multiple receiving computers. The flexibility of ThinPrint .print allows picking the computers or appliances best suited in a particular environment to receive the print job.

• Network printers connected with sufficient bandwidth should be targeted via a central print server using ThinPrint’s V-Layer technology.
• In the case of limited bandwidth to network printers a device that runs the .print Client is required on the same side of a WAN link as the print device. For maximum compression this device should run a Windows server or client operating system. If that is not possible, then a central print server with V-Layer technology and a .print Client running on a workstation, thin client or appliance will suffice.
• Printers locally installed on a Windows based workstation which is used to connect to a central desktop are best served by setting up the ThinPrint Output Gateway directly on the terminal server or virtual desktop or by using a central print server with V-Layer and Virtual Channel Gateway technology.
• Printers attached to thin clients or workstations that do not run a Windows desktop operating system are best served by a central print server in connection with V-Layer and Virtual Channel Gateway.

A second requirement for the use of the ThinPrint Output Gateway printer driver is that the printing application supports the creation of EMF print data. It is basically up to the developer of the application to decide whether to render the print job directly or to hand off the EMF data to the print subsystem and have Windows process the print data in the background. Handling the printing directly provides slightly faster speed, however the user has to wait until the application is done printing. Handing printing off to the system can require a little more time but the application is available to the user faster. Most commercial applications use EMF printing; however, some applications chose between EMF and direct printing depending on the printer language of the printer driver, and some applications only print directly. Since it is impossible to say which applications render the print job directly, it is necessary to test all relevant applications before deployment. The architecture of ThinPrint .print allows selecting any printer driver as a universal driver for a group of users or printers. Picking a printer driver that provides a sufficient feature set and that is compatible with the relevant print devices - like a basic PCL3 driver – allows benefiting of the value of ThinPrint .print even in the rare occasion that the ThinPrint Output Gateway driver cannot be used.

A ThinPrint Port is a printer port. Like other printer ports it transmits print data out of the print subsystem to a print device, print server or other computer for further processing. Each ThinPrint Port can be configured with a variety of settings to fine-tune its behavior. Considering print protocols and bandwidth restrictions is sufficient in the majority of environments. The following 3 step process demonstrates how to determine number and basic configuration of ThinPrint Ports for most environments by:

Ⅰ. Determining the print protocols required
The first decision to be made when planning the set up of ThinPrint Ports is regarding the protocol that will be used for printing. This decision is based on how the printer is set up on the network, to be precise whether a .print Client can be used and whether central and/or remote print servers are involved. The diagram below visualizes this decision process. It can be applied to determine the required ThinPrint Port protocol for any kind of printer.

• The most important question is whether a .print Client will be involved in the print process. It is highly recommended to use the .print Client because of the compression, multi-protocol support and universal printer driver support it provides. Should it be necessary to print without a .print Client, then at least one ThinPrint Port configured for LPD protocol is required.
• By using .print Clients, several protocol options become available. It is now important to know where the .print Client will be installed. If the printers are installed on a remote print server running Windows or Linux OS or if a network appliance with built-in .print Client hosts the printers then at least one ThinPrint Port has to be configured for TCP/IP protocol. If the .print Client is not accessible via a TCP socket connection from the ThinPrint Port then the .print Connected Gateway can provide connectivity through firewalls and NAT’ed networks.
• Printers that are not set up on a remote print server or print appliance are assumed to be locally attached printers on a user’s workstation in this process. The most likely reason for using ThinPrint to print to a locally attached printer is that the user connects to a centralized desktop (Terminal Server, Virtual/Hosted Desktop, etc.) via a remote session protocol and prints back to the printer installed on the physical workstation. If this remote session protocol is not RDP or ICA with the support of OEM channels then at least one ThinPrint Port has to be configured for TCP/IP protocol. Should a TCP socket connection from the ThinPrint Port to the .print Client running on the workstation not be possible then the .print Connected Gateway can be used to achieve connectivity.
• In the case that the user does connect via ICA or RDP and wants to print to a locally installed printer at least one ThinPrint Port has to be set to Virtual Channel Gateway when a central print server is involved. In the case that no such print server is in place the ThinPrint Port can be configured to use either VC (Virtual Channel) or TCP protocol. The later one provides a slightly better performance due to less protocol overhead but also requires the .print Client to be accessible via a TCP socket connection.**

** By using the .print Connected Gateway a .print Client can be printed to via TCP/IP even when a direct socket connection from the ThinPrint Port to the ThinPrint Client is not possible.

Each print protocol determined by the steps above requires at least one ThinPrint Port. This is the only must-have requirement. All of the following considerations will “just” improve the performance of the print environment and in most cases significantly.

Ⅱ. Determining the bandwidth control limits based on network links
After the protocols are determined, the required bandwidth limitations for each protocol need to be specified. For each combination of bandwidth restriction and protocol one ThinPrint Port is required. This again is not difficult to determine and a simple table can be of help. Each print protocol takes one column and each bandwidth restriction takes one row. If a protocol requires a certain bandwidth limit then this cell will be marked. After the table is completed the number of marked cells tells not only the overall number of required printer ports but also how many ports need to be created for each protocol and how the bandwidth needs to be configured as a minimum.

Example:
It was determined that printing over the protocols TCP, VC and LPD is required. Based on the link speeds between the central print server and the printers it was decided to use bandwidth limits of 100 Kbit, 256 Kbit and unlimited. Checking which protocol would be used over what network link leads to this table:

It shows that at least the following five ThinPrint Ports need to be created in this environment:

• Two ports set to TCP protocol with one of them limiting bandwidth to 100 Kbit and the other one without bandwidth limit
• Two ports set to Virtual Channel protocol with bandwidth limitations of 100 Kbit and 256 Kbit respectively
• One LPD port without bandwidth restriction.

Ⅲ. Creating multiple ThinPrint Ports with identical configuration to improve performance
To finalize the specification of ThinPrint Ports the number of print jobs that are sent concurrently over the same protocol and bandwidth need to be considered. Because each printer port can only process one print job at any given time this could lead to unacceptable delays in printing when too many printer queues share a single printer port. On the other hand, setting up more than one printer port will result in higher bandwidth consumption because the actual bandwidth used for printing is the sum of the bandwidths of all ThinPrint Ports printing concurrently. This, however, is only problematic when several ports print over the same network link. Therefore a simple additional measure is to create one Printer Port per physical network link for each required protocol and bandwidth limit. This will increase the overall print speed by allowing concurrent print jobs over different network links to utilize the assigned bandwidth limitation for each connection.

The process described above will lead to a .print environment that is optimized for bandwidth control. It does not necessarily lead to the easiest administration. If bandwidth control is not very important then stopping the design process after the step I and adding additional ThinPrint Ports on demand is a perfectly valid approach.

More technical descriptions can be found here:

• The ThinPrint .print Product Family
• .print on the server, the network and the client
• Universal printer drivers
• How does ThinPrint .print help me with...