IT executives in large distributed enterprises have long been on a mission to centralize IT infrastructure and reduce the assets required in remote or branch locations. The benefits are obvious… it’s much easier and cheaper to maintain one big infrastructure in a central location than it is to have resources spread thinly over many locations.
Look around and you’ll see file storage being replaced with storage area networks; remote telephone exchanges being swapped for VOIP systems; virtualized desktops and thin clients replacing dedicated PCs. All are prime examples of the push to centralize.
One of the last areas to be addressed in this move is print servers, but it is an area now receiving a lot of attention. As such, it’s worth looking at the “do’s and don’ts” of print server consolidation.
The first question to ask is “where will I find print servers in my business that could be replaced?” Well, there are two places: branch offices and the data center. The second question to ask is “what document output is being managed by these servers?” Again, it will be documents generated by centralized business applications in the data center and documents being printed from distributed devices (which were historically just Windows PCs, but increasingly include mobile devices). However, there is an inter-dependency between these areas that greatly complicates the picture.
Let’s start by looking at the distributed workplace requirement. The traditional approach to office printing involved sending data from a PC to a print server located in that branch office. Desktops and laptops were not particularly powerful, so it was better to offload the processor burden of document rendering to a more capable server. It was also easier to manage printer definitions and printer drivers on hundreds of Windows print servers than it was on thousands of desktops. Normally, these print servers were also used for other things, such as file storage. But two things have happened – firstly, desktop devices are now often more powerful than the existing local servers and thus more suited to rendering print jobs. Secondly, the other functions of the server have been centralized, leaving very expensive machines doing nothing but acting as print servers.
So what’s the alternative? Well, Direct IP printing (or peer to peer printing) involves rendering print jobs on the desktop device and sending the output directly to the IP address of a network printer. Simple, yes, but you need a method of providing printer definitions for installation on a desktop along with managing printer drivers on thousands of desktops. With Windows Server 2012 and Windows 8.1, Microsoft provided tools for doing exactly that. So, if your only requirement is to consolidate Windows print servers for desktop output, you have free tools available to do so with your Windows operating systems. There are also now a number of commercially available tools that address this isolated problem, but it is debatable whether these offer significant added value above and beyond the basic Microsoft tools.
This Direct IP approach overlooks two fundamental issues, however. Firstly, your business systems likely contain many technologies that rely on the existence of Windows print servers. Centralized applications often overcome the complexities of printing by “throwing the print job over the wall” to a Windows print server. SAP, for example, deploys SAPSprint for this very purpose. Many pull printing products need Windows print servers to work (often numerous server instances). So, if you deploy Direct IP printing and take away the Windows print servers, these other technologies will cease to work.
The second issue is that your print servers are probably not all Windows-based. Your centralized applications will have UNIX or Linux servers. You may have CAD departments using Linux workstations or design departments using Apple Macs. And, of course, today you need to provide means for users to print from tablets and phones. How can you also consolidate print servers to meet all of these requirements?
A true Enterprise Output Server (EOS) will address all of these issues by providing a single place to collect and distribute centralized application output, regardless of platform. It will also offer a single place to define all print queues and manage all printer drivers. Those print queues can be defined by users on desktops without the need for admin rights (even if the desktops are virtualized, and printer definitions can be remembered from one session to the next). Those print queues can deploy Direct IP printing, or route output via the EOS. The EOS can also act as a spool for retaining pull print output, or can allow pull print jobs to be retained on desktops until users authenticate at a printer. Put simply, an Enterprise Output Server will allow you to replace all of your print servers with a centralized server installation — with failover in high availability mode — without disrupting any of your other systems.
Consolidating print servers? We know a thing or two about that. Contact us to learn how we’ve helped organizations centralize and optimize their printing systems.