Print servers can be complex beasts. Just ask anyone who’s spent time as an admin in a medium- or large-sized organization. Designed to make group printing easier, print servers have nevertheless managed to earn a (well-deserved) reputation for being difficult and resource-demanding. And that applies even to recent releases like Windows Print Server 2012 R2.
Things can be equally challenging when it comes to formulating best practices for print servers. There are hundreds of different possible implementations for a print-server-based infrastructure as well as different print server releases—anything from legacy server software up to and including Windows Print Server 2012 R2. This introduces a huge number of variables into the mix and makes one-size-fits-all solutions difficult. But not impossible, as we’ll see.
To begin with, let’s narrow our focus to Windows Print Server 2012 R2 and fairly common server implementations. Then we can consider three important best practices:
Limit the number of clients. Any print server can get overwhelmed when too many clients are connecting, and that’s no different for Windows Print Server 2012 R2. This makes perfect sense no matter what the situation: A bus that has to make 100 stops is going to run more slowly than one that only has to make ten along the same route. For that reason, you’ll want to account for the system resources (e.g., CPU, RAM) and restrict the number of clients to something manageable. Microsoft doesn’t mention any specific guidance on this in its own documentation for Windows Print Server 2012, but it does ask admins to keep in mind that print activity picks up substantially during the course of the working day.
Use client-side rendering where possible. Often it’s best to have the individual clients to do the heavy lifting than putting the combined load on your print server. Windows Print Server 2012 R2 gives you the option of having clients render print jobs into page description language (PDL) format before sending them to the spooler instead of the other way round, which can reduce the amount of processing the server is expected to do. This can not only speed up print times but prevent the spooler in Windows Print Server 2012 R2 from crashing as frequently.
Aim for fewer drivers as well as driver uniformity. Windows Print Server 2012 R2 uses the v4 driver model. This is supposed to be more efficient and more stable than earlier driver iterations. If you have to use v3 drivers or a large variety of drivers for different printer models, you run the risk of increased incompatibilities and more server-side rendering, which in turn increases the likelihood of crashes and printing errors. Therefore it’s best to migrate to as many v4 drivers as your environment will allow (keeping in mind that this can be problematic when using OS versions earlier than Windows 8) and keep the total number of drivers low regardless of the version.
Of course, because of those real-world variables, not all environments that rely on Windows Print Server 2012 R2 will be able to put these best practices into effect. For a true one-size-fits-all print management solution, there’s PrinterLogic. Our next-generation print management software is powerful and versatile enough to eliminate print servers completely—along with their attendant costs, limitations and headache—while delivering greater functionality, cost-effectiveness and centralized management.
With PrinterLogic, you don’t have to worry about limiting the number of connected clients because our solution is infinitely scalable with no hit to performance. It’s also far more robust toward driver incompatibilities and is capable of handling large driver repositories with ease or giving you powerful, flexible universal driver options to help streamline your printing environment further. So when you’re looking for best practices when dealing with Windows Print Server 2012 R2, there’s really only one to keep in mind: Implement PrinterLogic for smart, stable enterprise printing and be done with your print servers forever.