How does ThinPrint .print Help Me with...

ThinPrint .print contains a virtual printer driver called the ThinPrint Output Gateway. The name “gateway” was chosen because this printer driver does not perform the typical task of rendering print information from Enhanced Metafile (EMF) format into a printer specific format like PCL or PostScript but redirects the EMF data directly to a printer port called ThinPrint Port. Not rendering the print job on the server side is also the reason why this technology is referred to as Driver Free Printing. Since the print information is in its original format when it leaves the server it can be put into the print subsystem of any Windows based computer on the network. The ThinPrint Port and the .print Client for Windows ensure that print jobs arrive with maximum speed and minimum impact to the network. The manufacturer’s printer drivers installed on the receiving system handle the rendering of the print job.

This technology allows an administrator to remove all printer drivers from a terminal server farm, virtual desktops or hosted desktops. Searching, testing and deploying suitable printer drivers that are compatible with the server operating system and the printer becomes obsolete, frees up valuable administrator resources and improves the service quality to users. The required printer drivers are in many cases installed on the client computers or remote print servers anyway so that client configuration is kept to a minimum and user training is not required.

One of the main challenges when upgrading an operating system is the risk of incompatibility of applications and drivers. Printer drivers are no exception and because printing is deeply integrated into the operating system using older printer drivers can be problematic for the stability of the print subsystem or might even be impossible. This situation becomes more complicated when a print job is handled by several machines like terminal servers or virtual desktops printing to rich clients or a computer utilizing printer shares from a print server. In these situations a compatible printer driver for the system to be upgraded has to be found, tested and deployed but the deployment also has to happen for all systems at the same time. That means in the case of an upgrade from 32bit to 64bit a major redesign, which involves high risk of interrupted services, is necessary.

ThinPrint .print is designed and certified to provide full printing compatibility between all Microsoft desktop and server operating systems. The ThinPrint Output Gateway driver works well with the 32bit and 64bit versions of Windows 2003, Windows 2008, Windows XP, Windows Vista, Windows 7 and older versions also provide compatibility with Windows NT4 and Windows 2000. This platform compatibility by ThinPrint’s universal printer driver allows upgrading each system separately which simplifies finding compatible printers drivers, eliminates the need to replace printers that cannot be supported by the new operating system and most importantly it allows for a transition from one platform to the next. The possibilities are endless. The following are examples that refer to common upgrade problems.

• Upgrading terminal servers from 32-bit to 64-bit to accommodate more user sessions without upgrading print servers or client PCs
• Upgrading terminal servers from Windows 2003 to Windows 2008 to benefit from new features without modifying print servers or client PCs
• Upgrading virtual desktops or physical desktops from Windows XP to Windows Vista without modifying the print servers
• Upgrading only some servers or desktops while keeping others on the older operating system or platform for compatibility reasons without setting up additional print servers to ensure print functionality for both sets of platforms
• Upgrading the print servers from 32bit to 64bit to benefit from additional performance without cleaning up printer drivers and remapping printer shares on terminal servers and desktop PCs

In the context of a central desktop deployment model in which the user connects to a terminal server or hosted desktop two types of roaming users exist.

The first kind uses different client computers to access the same desktop session from different locations while the second kind uses the same client computer from various locations. Both kinds of users need to be able to print and in most cases to a printer close by, which can either be a session printer (a printer locally installed on the client computer) or a network printer installed on a print server or another computer.

ThinPrint AutoConnect is a component of the .print Engine that manages printer mappings and printer queue creation for user sessions on terminal servers or hosted desktops. It ensures that printers (locally installed on the client machine or from a print server) are available in a user‘s session by utilizing two methods. Both are used each time ThinPrint AutoConnect is executed.

The first method requires the use of a .print Client on the client computer initiating the session. Based on the printer configuration on the client computer, it creates corresponding printer queues on the terminal server or hosted desktop with the best possible configuration for each client printer. This is done by polling the .print Client for information about each printer queue that has been selected to be available inside the user’s session. A name translation table which supports wild cards provides the necessary filters to allow for the configuration of a perfectly tuned operation.

Each mapping rule consists of the following criteria:

• IP range or client name of the computer the user logs in from
• Printer name or printer driver name of the printer queue on the client side
• Printer class name which can be assigned to a printer queue through the .print Client user interface
• The type of .print Client*

* Wildcards can be used with all criteria except the .print Client type and will reduce the length and complexity of the name translation table drastically.

The actual printer creation is either done by automatically copying and renaming a template printer queue or by mapping a shared printer from a print server.

The task of the administrator is to categorize client printers, configure template printer queues or shared printers and to create the mapping rule for each category. Since wildcards can be used for all mapping criteria a typical name translation table contains only a few lines. This generic rule for example can be used to point all client printers that are installed on a Windows desktop or server operating system to a template queue that uses the ThinPrint Output Gateway driver:

Even without .print Clients installed on the client system ThinPrint AutoConnect is able to map shared printers from print servers. Similar to the “Name Translation” table a "Map Additional Printers" table is used to create mapping rules for shared printers. IP Range and name of the client device can be used as mapping criteria.

ThinPrint .print compresses all print data that passes through a ThinPrint Port unless the port protocol is set to LPD and compression is turned off. This “normal” ThinPrint Port compression reduces print data by 60%-80% on average. When using the ThinPrint Output Gateway driver a second type of compression is applied. Because the print format the ThinPrint Output Gateway uses is EMF, it is possible to analyze the elements the print job consists of and apply different compression algorithms to different parts of it. This adaptive compression is very efficient and leads to a data reduction up to 98%, especially in connection with large pictures.

Compression for ThinPrint Output Gateway queues can be configured by an administrator. Four levels are available to find the best balance between print quality and compression.**

** A fifth option “No Images” delivers the smallest print data possible by eliminating all pictures. A 20 page document still prints as 20 pages; blank spaces the same size of the removed pictures show.

Printing is frequently the heaviest traffic that crosses a WAN link. This leads to bandwidth shortages especially over limited connections that a remote user is likely to use from home or shares with other users from branch offices or retail locations. Even though print traffic can take up large amounts of network bandwidth, it is rarely time critical to get the print data to the printer. To avoid a negative impact on the performance and quality of VoIP calls, terminal server sessions, hosted desktop sessions, real-time access to databases, etc. controlling the bandwidth that is used for print data is required.

ThinPrint .print can provide the upper bandwidth barrier for all print jobs passing through a ThinPrint Port. Each ThinPrint Port can be configured to limit the maximum amount of print data leaving that port per second. Bandwidth limits between 1,000 bps and 1,000,000 bps can be chosen.*** The bandwidth setting corresponds with a time interval that the ThinPrint Port waits between sending each data package. Since a high bandwidth limitation implies that more network bandwidth is available, ThinPrint .print automatically increases data package size and reduces processor intense compression routines. Selecting a small bandwidth limit is interpreted as a limited connection. In this case, the ThinPrint Port invests additional processing time to achieve maximum compression. Because the time interval between each data package leaving the ThinPrint Port is larger the impact of the additional compression routines to the server is minimal. The ThinPrint Port also reduces the package size when a low bandwidth limit is set so that a single package doesn’t block the network link for a significant amount of time.

*** ThinPrint .print’s bandwidth control can be turned off completely for printing in networks with sufficient bandwidth.

Printing on a Windows based operating system means rendering a set of commands that describe the position and size of elements on a page into information that is understood by a specific printer. This process not only requires heavy resource utilization on the computer it is performed on but also the installation of the correct printer driver for each possible printer. In most centralized desktop environments it is either impossible to predict what printers will be used on the client end of an RDP or ICA channel or the diversity of print devices renders installing all printer drivers impossible without consuming valuable time for administration and negatively impacting stability and performance.

ThinPrint .print provides a driver free printing technology that allows the system to redirect EMF print data to any other Windows based print system on the network. The core of this technology is the ThinPrint Output Gateway which looks like a printer driver to the user and the application but does not fulfill the function of a printer driver: rendering print data in EMF format into a format the print device understands. Instead it passes the original format on to a ThinPrint Port which then sends it to the print server or work station that has the correct printer driver installed for rendering. This approach removes printer drivers from the hosted desktops and terminal servers, relieves the server of CPU spikes, hard drive and memory utilization during printing and lets the administrator pick the machine best suited to render the print job. A print server would be the likely choice for network printers and locally attached session printers on non-Windows clients and the user’s PC is likely best suited to handle print job rendering for locally attached printers when it runs a Windows desktop operating system.

It is important to understand that the ThinPrint Output Gateway is just one option to print with a universal printer driver. ThinPrint .print’s modular structure allows making any printer driver the universal driver for a group of printers. This is achieved by creating a printer template queue which holds all the necessary information about printer driver, printing properties and printer ports that ThinPrint AutoConnect needs to create session printers for selected client printers.

A name translation table with several filters and wild card support provides the user with an interface to fine tune which template printer queue is going to be used for a particular printer, network segment, client, etc. In reality a single rule using a template with the ThinPrint Output Gateway driver can take care of all client-printing to Windows based desktop systems. Other client devices can be supported by either adding additional template queues or by utilizing a print server with V-Layer and Virtual Channel Gateway technology.

Many older applications were designed to print to static network printers or a specific printer port instead of dynamically created session printers. ThinPrint .print offers two ways to print from these applications in terminal server or virtual desktop environments.

The first way deals with legacy applications that are running on the terminal server or virtual desktop. It is built-in into the .print Engine. When the ThinPrint Port is configured to print to a client PC via RDP or ICA the ThinPrint Port is looking into the print job for the user name who created the print job. It then requests the session ID assigned to this user from the operating system and moves the print job into the correct RDP or ICA session stream. This behavior allows a user to print to their locally installed printers through a static printer queue that is set up for virtual channel printing with ThinPrint. An application that requires a static printer object for printing can be configured to print to such a printer queue and as long as the application runs in the context of the individual users the print jobs will arrive at the client side. In connection with Print Port redirection via the net use command, applications that are hard coded to print to LPT or COM ports can also print to client printers.

The second option allows an application hosted on a separate server to print into the session printers of a user’s RDP or ICA session. This is done by the Host Integration Service (HIS) which was developed by ThinPrint to incorporate back-office print systems with terminal server session printing. The host system prints to the Host Integration Service via LPD/LPR. The Host Integration Service checks the control file of the LPD print job for a user name or queue name and matches it to a user name on the terminal server. When the correct user is found the .print Engine can determine the correct session ID of that user and moves the print job into the RDP/ICA channel.

ThinPrint’s Queue Manager is an add-on to the .print Server Engine which monitors the status of print jobs in ThinPrint printer queues. Should a print job fail to transmit Queue Manager will hold it for a specified amount of time and retry sending it. The number of retries and the duration between tries can be set by the administrator. The benefit of this member of the .print product family is significant when unstable network connections are in use or it is unknown to the user whether the print device is operational or not.

More technical descriptions can be found here:

• The ThinPrint .print Product Family
• .print on the server, the network and the client
• Universal printer drivers
• Best practices