VDI Printing. Is it the Nemesis it was for Terminal Services? Part I

All the News That’s Fit to Print” is the motto of the The New York Times . Despite a proliferation of devices that allow you to take content with you wherever you go, despite e-mail, despite services like LinkedIn, Podio and Twitter there is still a driving demand  to generate hard copies of documents.

Printing is so common and fundamental that it is often overlooked as an IT service when migrating to virtualised desktops. How do your users connect to the printers they have? In fact, what printers do they use? What are the printer drivers and settings that are common or unique?

Early adopters of  the Windows server based computing solution Citrix WinFrame came to understand that desktop centralisation may well improve the configuration and management of desktops and applications but user services, especially printing, were a headache.  Printing integration with thin clients could be a pain. Such was the complexity that a sub-industry evolved to offer solutions assisting with managing and maintaining print services in a distributed environment. While various iterations of Citrix’s solution improved printing services, it is always something to knit the brows of architects – “the Truth shall make you fret” as it were.

Hosted Desktops are often hailed as “a better desktop solution than Presentation Virtualisation“, they being “designed to deliver a desktop operating system“. Yet, Hosted Desktops are a service that move functions away from the user’s device – and so often away from their printer. The users’ printers are still local (to them), their need to select their nearest printers still very much necessary, as is their expectation to print to whatever printer it is they have at hand.

VDI Printing. Is it the Nemesis it was for Terminal Services? If not, would client hypervisors help, or is it that traditional desktops delivery is the best method for dealing with printing requirements?

In this,  the first of two articles on VDI printing, we consider what are the issues with distributed printing and, what printing functions should you consider for your desktop architecture.

Issues with Distributed Printing 101

Any distributed desktop service has four core issues to deal with in order to create an efficient printing environment:

1) Bandwidth Availability – there is a great play on optimisation of bandwidth to enhance the user experience for Adobe Flash say, or real-time video. Yet, do not underestimate the need for printing bandwidth. A lack of optimisation for printing could manifest itself  in two ways: both incredibly character building. The print task can take an age to complete,  and it can even prevent other use of the remote connection. Neither lead to a good user experiences. Of course, this impacts remote users with low bandwidth connections most severely: will the users at that branch office on that low bandwidth remote link be impacted when Arthur decides to print out his 50-page presentation deck?

2) Printer Driver Management – a printer driver (or a print processor) is the software that converts the data to be printed to the form specific to the printer. The purpose of printer drivers is to allow applications to do printing without being aware of the technical details of each printer model. The issue here is, there are many printers, ergo many printer drivers. Accessing functions of the printer (for instance, duplex, colour, stapling, watermarks, print ordering, binding) can be specific to the printer. Indeed, how do you deal with multi-function devices – printing and scanning? There is often a requirement to use a specific printer driver. How does it get installed? If you’ve a standard build on your hosted desktop, are all the printer drivers  in it? Can you steam them like applications? Do all the drivers work together nicely? If a user needs a non-standard printer, how do they add that driver in?

3) Printer Selection. Where am I and where is the nearest printer? This is a pain for users who move around a great deal. Some organisations opt to let their users choose their printers: this can be very time consuming.  Far easier to automatically connect the nearest printer(s) when the user connects. Yet, does the printer selection requirement fall foul of the Printer Driver Management issue?

4) Local or Network Printing This is more than simply “printer selection” which deals with “which printer is closest?”. The closest printer maybe the one physically sat next to you, on your desk. You can see it. Look! Its there!  But, how is it connected to your device? Directly via USB (or even, and it still exists, a parallel cable)? Via a network? Does the device you’re using allow access to that printer? Some thin clients for instance, don’t support direct printer re-direction: if you want to replace PCs with locally attached printers, can your users still access their printers? What happens if their device is a tablet? What happens if they want to use their  home printer?

Nothing is Impossible

Alright, some things are impossible: “describing what yellow smells like” for instance and, sadly, “my football team’s ability to win”: however, I digress. In that “up and at ’em” ethos of a well-known sporting brand, these printing issues are not impossible to solve with proper consideration. When designing your desktop architecture’s print environment you should consider:

  • Bandwidth Prioritisation: can you contain or prioritise the remote bandwidth taken up by the printing protocol. Can you minimise the impact of requesting a print function for remote users?
  • Printer Driver Management: can you automate or manage the installation of printer drivers for users’ printers without impacting on the stability and usability of the environment they are working in?
  • Universal Printer Driver: indeed, do you need so many printer drivers? Can a single “universal printer driver” be used to replace the variety of drivers you have in place at the reducing complexity and management and enabling users to use their own local printer – whatever it may be?
  • Proximity Printing: you can rely on the option to “get the user to go an look at the label attached to the printer and use that one” – but this itself is a time consuming task. And time is money. Is it possible to connect the user’s most local printers automatically?
  • Printer Naming: When you create printers, how are they named? Some applications (which can be vitally important applications like “invoicing”, “ordering” and “dispatch”) have very specific printer name requirements. If that is necessary, how do you accommodate that?

What Next?

There is still a need to fit to the motto – print news. Taking a step back and considering your  print requirements is an important step in delivering a successful desktop virtualisation project.

In Part II we’ll consider the core printing options for the likes of Citrix XenDesktop, Quest vWorkspace and VMware View and how they match to our printing considerations. Do you still need third party products to make your print solution effective? We’ll take an overview of solutions from ThinPrint, triCerat  and UniPrint. Hopefully you’ll find it all interesting news and wish to print it.