Client Side Rendering – Is it a viable Enterprise Print Solution?

Oh man! Client side rendering, who thought this was a great idea?

Ok so you basically turn your entire client machine base into print servers right!?

Well, yes because that’s effectively what you are doing if you adopt a client side rendering print method.

So why is client side rendering so popular in many IT communities and why is it pushed so heavily by the printer hardware vendors?

Simply put, it reduces print servers and prevents print traffic from traversing the WAN.

These reasons sound great, but for all intents and purposes it creates more printing issues than you had in the first place.

Let’s look at the scenarios why client side rendering is employed and see what the effect is:

So, we don’t want print servers, like… anywhere!

What is Client Side Rendering?

Client side rendering solutions have been widely adopted in recent years and there are many companies with products that can help achieve the management ‘overhead’.

These solutions are sometimes called Direct IP printing or Serverless Printing.

You start by having a centralised server. Ok we failed at the first hurdle, right? Yes, you need a server to implement Server Less Printing *Sigh*.

This server manages all printer and user information like which user wants which printer and the associated information about those printers, drivers, IP addresses etc.

Then a software client is installed on the user’s machine which communicates to the centralised server and is responsible for mapping printers for the user that’s logged in.

When a printer is required to be mapped the software client downloads the driver from the centralised server with which it then installs a direct IP printer.

Printing is now between the user machine and the printer, there is no remote provider involved in this printing process.

Is Client Side Rendering a Print Solution?

To answer let’s look at the Pros and Cons on client side rendering:

Client Side Rendering Pros

1. No localized print servers to manage either central (if you exclude the management server) or at the local offices for the users.

2. If you adopt a Cloud architecture, then the print data remains local to the client machine and print traffic does not travel outside of the LAN.

Client Side Rendering Cons

1. Client OS support. If you must download a printer driver, then the client OS must be compatible with the centralised server. In short, it needs to be a Windows client machine.

2. With this architecture, all client machines have themselves been transformed into print servers, duplicated print servers at that.

3. If you adopt a VDI or remote application strategy, then print isn’t generated on your client machine so an additional print management solution is required.

4. Printing in the cloud will inevitably send print traffic across the WAN which contradicts this implementation in the first place.

5. Mobile printing in this architecture requires direct line of sight to the printer devices limiting user experience and options.

As you can see, this is no way near an enterprise print solution.

Interested in learning more about software defined printing solutions? Check out this free webinar on consolidating printer servers and reducing costs!

Client Side Rendering with Secure Pull Printing

Let’s now introduce the wildest adopted printing strategy; Secure Pull Printing.

If you are attuned with the world of managed print services, then you will undoubtedly be aware that every printer vendor and printer provider wants to lock you into their contracts.

They leverage the IT industries attraction to software by having secure pull printing software solutions of their own.

However, they are scared…

For print savvy IT people, you know why they are scared when implementing their MPS solutions in our modern architectures.

We don’t like print drivers, but they need them.

We also don’t like print data swamping our networks and chewing up our compute power for fun, but that’s what their solutions do.

So, to manage their fear they rely on… you guessed it… Client Side rendering.

When you hit print using an MPS providers secure pull printing solution, the print job remains on the users client machine.

Only a ticket of the job information is sent to the centralised management software.

Great!

No print data is required to traverse the WAN and print drivers are kept locally on the user’s client machine, genius!

Slight problem… My client machine is a laptop and you have it turned off in your bag because you are on the way out of the office for a very important meeting and you want to collect my print job as you leave.

What do you do?

You can’t access your print job because your laptop is turned off.

The solution to this that inevitably will come back from the MPS vendor is: ‘use local print servers’.

OMG!

I am not going to continue to write about the vast amount of issues I get told about the solutions out there as I feel you get the point I am trying to make here.

You see the problem is not; keeping drivers away from centralised IT applications, VDI’s or published web application servers, nor is the problem print data traversing the WAN.

The problem is that when you look to find a solution and start at the hardware you natively end up creating more issues than you started with.

In today’s modern IT we never start building our solutions or strategy from the hardware.

We look at things purely through software nowadays and the hardware is irrelevant.

The solutions we build are omni-channel regarding the user and their user experience should be uniform.

Printing is no different.

Software Defined Printing

To manage a printing problem or to build a printing strategy don’t start with the hardware, start with building a software defined printing strategy.

What you will find is that printer hardware dependencies like drivers and print data become secondary concerns.