Product and service updates, tips & tricks and more.
Professional print
management for Terminal Services
These days, setting up a server based environment using Terminal
Services is an economical and efficient alternative to decentralized IT
structures. Based on modern, highly developed transmission protocols
like RDP from Microsoft or ICA from Citrix, even extremely low
bandwidth connections are adequate for central server farms to provide
entire satellite offices with all of the applications they need,
quickly and flexibly.
In this arena, .print Application Server Engine is an ideal and
complete solution that covers all aspects of printing in Terminal
Services environments.
Connection based bandwidth control, professional printer mapping, port
pooling for printer load balancing, and support for Windows Cluster
Services are just a few of the features that make
.print Application Server Engine the leader
in technology for printing from terminal servers.
The patented DRIVER FREE PRINTING technology in
.print Application Server Engine for example, makes
server-side installation of printer drivers unnecessary while at the
same time avoiding the disadvantages of a
“universal” printer driver. This .print technology
is complemented by a high-performance, adaptive compression, with which
the individual components of a document are analyzed and compressed
with the respectively best algorithm before being transmitted.
In combination with a dedicated print server, .print Application Server
Engine puts the print data into the ICA or RDP virtual channel and send
it directly to the client. This allows to target printers that are
hiding behind a firewall or a Network Address Translation (NAT) and
therefore can not be reached over TCP/IP.
The print management concept for every professional server farm
Print processing must be considered early on when planning a terminal server architecture to avoid later problems in runtime. Generally speaking, in larger systems with more than three terminal servers, it is intelligent to move the entire print process to a print server dedicated specifically for the purpose.
Running a dedicated print server has many advantages:
A dedicated print server is therefore recommended without reservation as the best concept for professional server farms.
The .print Server Engine enables setup of these dedicated print servers without sacrifices in functionality. The overall performance spectrum of the .print technology is also available for this architecture:
Registered delivery of print jobs
There are many circumstances in distributed networks that can delay or completely disrupt printing. Causes are usually short-term disturbances in the connection as often occur with DSL lines. Other problems that can be traced to the printer hardware (like a paper jam) can also prevent smooth print processing. In larger, trans-regional networks, there is often an added problem: printers or computers that are not running simultaneously because, for example, they are in different time zones cannot receive the print jobs at all. Even the user himself can instigate unsuccessful transmission of print jobs; for example, if he is working in a Microsoft Terminal Services or Citrix Presentation Server environment and closes his session before printing has been completed
.print Queue Manager offers the ideal solution to all of these obstacles. It enables transmission settings to be defined individually for each printer queue. Settings include the number and intervals of retries and the total amount of time retries are to be attempted before the print job is finally deleted.
There are two versions of .print Queue Manager available. Queue Manager AS is intended for use on application servers; Queue Manager PS can be run on dedicated print servers. An active .print Application Server Engine respectively .print Server Engine is necessary on the server.
Cut the cost of printing via WAN connections
The change from expensive leased and dedicated lines to cost-effective VPN connections, usually based on the affordable DSL standard, is nowadays a key requirement for every IT manager.
Printing via these VPN connections, nevertheless, presents a number of challenges in terms of administration. The need to abort all print jobs due to even the slightest instability in the DSL connection, the inability to address printers in masked networks, or the need for the drivers of branch office printers to be made available centrally are only some of the difficulties that administrators have to overcome. Moreover, the costs for volume-metered VPN connections can easily spiral, especially on account of the large data volumes required for print jobs.
The .print Connected Gateway offers the ideal solution for all these problems. It stabilizes the transfer of print jobs even in the event of a disconnection, for up to 90 seconds (the additional use of the .print Queue Manager is recommended for bridging longer distances). Unlike the standard communication direction, the Connected Client Gateway also enables connections from the remote location to the central server, and thus allows the addressing of network printers via TCP/IP also in masked networks. Thanks to an adaptive compression technology, these .print components allow the reduction of print data by up to 97 %, even in client gateway configurations. The patented Driver Free Printing technology also makes central administration of printer drivers unnecessary. In conjunction with the .print Engine, the Connected Gateway offers the ideal solution for simple, fast and cost-effective connection of remote offices.
Integration SAP and Unix spool servers in Microsoft Terminal Services and Citrix Presentation Server environments
Businesses running Microsoft Windows Terminal Services or Citrix Presentation Server today use the technology to access central businesses applications like ERP, PPS, or CRM systems. Unfortunately, though, exactly these systems often have a distributed architecture. Thus, although the user interface (e.g., the SAPGUI or a Unix emulation) is installed on the terminal server or accessed with a web browser, the application itself is nevertheless running on its own application server. In many cases, the print jobs are created on a spool server.
This creates a long list of problems:
When using SAPLPD:
The .print Host Integration Service resolves this issue. When a user creates a print job on a distributed system, the .print Host Integration Service first detects the terminal or presentation server on which the user is working. The print job is then forwarded via TCP/IP from the application server or spool server to the correct terminal server. There, it is compressed and sent across controlled bandwidth via ICA or RDP to the workstation. The print data is then decompressed and sent to the local printer, where it is printed with no loss of quality.
If the application server or spool server creates PDF files, these are sent in highly compressed form to the end device and immediately printed with the Adobe Reader.
The .print Host Integration Service offers the following advantages:
Need to use a ThinPrint solution right now?
Use the online shop to easily and instantly download and implement the solution you need in just minutes. Quick installation wizards and simple configuration options make this option a no brainer!