Printing from ERP, CRM or EMR (HIS) Systems
In many companies, printing from backend systems is an important part of the printing environment and often also a business-critical process. This applies to ERP printing, for example from SAP as well as Oracle, as well as EMR printing from McKesson, Cerner or Epic in the medical sector.
ThinPrint offers solutions for high-performance output of print jobs from different backend systems. With its high availability feature, the new ThinPrint LPD Service ensures business continuity when printing from ERP, CRM or EMR (HIS) systems. ThinPrint also masters the challenges that arise in VDI/remote app scenarios.
Optimized LPR Printing with ThinPrint
Backend systems from different platforms (often Unix) send print jobs via LPR to the ThinPrint Engine, which runs on a Windows server. From the ThinPrint Engine, the print job is sent to the ThinPrint Client with all ThinPrint features such as compression, streaming, bandwidth control and, as an option, TLS encrypted. Particularly when printing over a WAN, this leads to an increase in performance and a reduction in the load on the connections. For many companies, this is a major advantage, as the backend systems are usually centrally located, while print output is often decentralized in branch offices.
High Availability Printing from Backend Systems
High availability for ERP, CRM or EMR (HIS) printing systems is critical in several industries because the backend systems support critical business processes and patient care. A failure in any of these systems can cause serious disruption. ThinPrint ensures continuous operation of the printing systems through high availability and failover.
The Problem: Server-Side High Availability when Printing via LPR
A special feature of printing from ERP or EMR systems is often that printer queues or printer names are permanently defined. This enables a high degree of automation or printing without additional user interaction. However, it leads to limitations when it comes to distributing the print volume across multiple Windows print servers or implementing a solution for high availability. Each Windows print server has its own spooler and thus, its own print queues.
In the past, Microsoft addressed this problem by supporting a print server cluster with virtual queues. However, support was discontinued back with the release of Server 2012, so there is currently no solution for this. More on high availability printing »
The Solution: The ThinPrint LPD Service Ensures High Availability
ThinPrint has addressed this challenge and also offers server-side high availability for printing via LPR. We are thus also closing a gap for customers who do not want to print over a WAN, i.e. those who do not need a ThinPrint Client.
In principle, in the scenario we have looked at so far, the integrated Windows LPD took over the print jobs from ERP or EMR systems. However, this service itself represents a single point of failure. If the service or the downstream spooler is not running, then printing is not possible.
ThinPrint solves this problem by implementing our own LPD with expanded functionality. We also combine proven ThinPrint high availability technology with a network load balancer (NLB). It does not matter whether the print environment is set up in an on-premise installation or in the cloud (such as Azure or AWS). The Microsoft Network Load Balancer or the cloud-based Network Load Balancer is used by the backend system instead of the physical node to address the print queues. ThinPrint’s own LPD then takes over these print jobs.
The ThinPrint high availability service on the print servers monitors the servers, their spoolers and all dependent services, including the ThinPrint LPD. Various health checks are continuously run for this purpose. In the event of an error, ThinPrint ensures that the faulty node is set to offline status. All print jobs are then accepted and processed by the alternative node (print server). This process is transparent for the sending backend system.
The issue of security in the print environment is also taken into account. On the one hand, it is possible to restrict the sending LPR clients via whitelisting, and on the other hand, white lists can also be created for the addressable printer queues.
Client-Side High Availability for Printing via LPR
The ThinPrint Client can also be set up for high availability to avoid a single point of failure. This can be done, for example, by addressing two printers with integrated ThinPrint Clients or by using a second instance when using the ThinPrint Hub. In this case, load balancing is also possible.
Printing From Virtual Desktops, Terminal Servers and Published Applications
Another challenge for backend printing is making print objects available to users in the respective applications. When accessing backend systems running in a Citrix XenApp/XenDesktop or Microsoft VDI/Remote App session, for example, users often log in from different locations and devices. However, printing from backend systems is usually static and only possible to predefined printers.
With ThinPrint AutoConnect as part of the ThinPrint Engine, this problem can also be solved. The ThinPrint Engine can either run on a Windows print server (as in the scenario above) or directly on the terminal server/RDSH. AutoConnect is responsible for the rule-based mapping of printers for users. Basically, two methods of printer mapping can be considered:
- Mapping local printers into the VDI/terminal server session.
- Mapping printers from central print servers.
Let’s look at the options in detail:
Mapping Local Printers to the VDI/Terminal Server Session
The ThinPrint Client (ICA or RDP) on the local workstation reports the local printers to the ThinPrint Engine on the server or virtual desktop. This creates the print objects for the session duration. ThinPrint can ensure that the printer names always remain the same for users, regardless of which terminal server/virtual desktop they log on to. This also works when disconnecting/connecting the session without logging off. This eliminates the need for constant reconfiguration in the back-end systems. For comparison, with Microsoft or Citrix’s own tools for connecting printers, a session ID is always included in the printer name. However, this changes with each new session setup.
Mapping Printers from Central Print Servers
A major strength of ThinPrint AutoConnect is the mapping of print objects from print servers into VDI/terminal server sessions. Various criteria, which can also be combined, can be used for this. In addition to AD users and AD groups, an IP address or a subnet can also be used as criteria for the rules. Especially mapping per subnet allows users who frequently change locations to access printers without admin involvement. The possibility of mapping printers for one or more clients (hosts) should also be emphasized. This means that the same printer is always connected, regardless of the user logging on. Classic use cases can be found here, especially in hospital or logistic environments.
And last but not least, ThinPrint also offers a self-service app for connecting printers. If so desired by the admins, this can give users more independence and flexibility. Users can select printers from their available pool and also define the default printer themselves.