Print Server Spec

We currently have 5 or so sites and each has its own print server.  We are looking to try and create a single print server for all our printers.  We currently have a little over 300 printers and at any one time we can have between 1000 and 3000 users logged on and possibly printing.

Will the one printer be sufficient to handle the workload and if so what should the spec be?  
Should we have a number of print servers to split the workload?

I think the issue we may face with having more than one is that we have a centralised print management solution which allows us to charge for printing if we have a sort of client agent on the print server.  However if we wanted this on additional print servers we would have to pay additional licence costs for this.
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

David_IngledewConnect With a Mentor Commented:
I have seen sites with that number of users and printers, and a single server can handle it given the right OS and specification.

I actually prefer central server install for a number of reasons:
Allow better control,
Simpler driver management
Ease of support - no remoting on when a printer doesn't work
Better overview of devices and costs
Devices have a limit to the number of direct IP connections at any one time.

There are a number of considerations here:

Can a single server handle that many queues?
How do I maintain resilience?
Can that same server then handle user confirmation or code selections?
How many jobs are expected?
What size of jobs are expected?
How long are these jobs to remain available for release (assuming secure release on some devices)
Are all the devices and users on a local LAN, or are WAN links a concern?
What range of devices need to be supported?

Ok, lets dig in :-)

"Can a single server handle that many queues?"

Yes. Windows 2003/2008 can theoretically handle all those devices, on a single server.
It would need to be reasonably powerful (Memory, CPU, HDD performance and Network speed) to ensure printing is of a reasonable speed, please also reference size and number of jobs as noted below.
Any server will peak CPU utilisation with a single job, it's allways worked hard to clear it out quick and be ready for the next, thus many busy print servers run at high CPU.

"How do I maintain resilience?"

Multiple options here. It could be clustered, an active-passive would offer redundancy but active-active would allow splitting of the load. A generous level of clustered disk space would need to be allowed for.
Virtualisation is definitely an option. A virtual server can be prescribed the correct memory/CPU for the job, and it's much easier to increase if needed. Also if you can add in automatic failover it allows for a hot standby without extra hardware, and these can provide very quick switching to ensure users are not affected.
"Can that same server then handle user confirmation or code selections?"

This is very much dependant on the solution used - will this be a user selected code at time of printing or automatic code based on the user. In the first instance you could have 3,000 workstations calling to the server every ~3 seconds to check if there are jobs which need "confirming". That will put additional load on the network and servers and needs to be accounted for.

Without knowing the details of what solution you are planning on, locations, user application and throughput it's difficult to advise. I know Pcounter, and in this situation I would probably suggest 2 servers - 1 for print and one for release/user confirmations to split the calls and streamline the release mechanism. These would be virtual with the Printer server having a minimum of two assigned CPU's and 4Gb. The Data/communication server could be lower spec, but given the cost of HW now would porbably keep them both the same. I would then employ hot failover to keep licencing effective and management simpler.

"How many jobs are expected?"
"What size of jobs are expected?"

Well. these are the million dollar questions...without monitoring it first you do not know...

In push printing, it's less important for number of jobs, but if pull printing is to be implements you need to sample current usage where possible and calculate the maximum load for 3 days worth of jobs. Have the solution remove any jobs not collected after 3 days to maintain a cushion within that allowance as 60% jobs will be released.

Size of job is important in both situations. Consider your users and applications..and devices.
From the user angle are they admin staff printing out invoices, or marketing people printing large graphical output.  A simple work document is only small, so won't stress out a server, but high quality output, especially if from design packages (including CAD) could reach over 1Gb in spool size therefore affecting performance for all - expect these documents for be the 100Mb mark as a general rule.

If there are a large number of "heavy" users, I would consider multiple print servers, even if it is higher cost and split the users/devices accordingly.

"How long are these jobs to remain available for release (assuming secure release on some devices)"

Always keep jobs for the minimum time required - this may be 8 hours if you are being harsh, to 3 days if you need to cover weekends. Users will get used to the controls set, and keeping it lower saves them from removing their own old jobs.
Without a server delete a server will eventually have problems wither in speed or spooler reliability.

"Are all the devices and users on a local LAN, or are WAN links a concern?"

All the above assumes a LAN or high speed resilient links.
If you have remote users (depending on printing requirements, upto ~15 in an office), have them print locally - if monitoring is required you could put in a workstation for monitoring which sent print data back to the main servers, or some solutions support a workstation client for local monitoring.

I have seen sites which are processing 10Gb per month over the WAN  per month (About 19k jobs, which averages out at about 0.5mb per job). Just be wary of this and ensure you have the bandwidth to support remote users. Remember the downstream may be rated much higher than the upstream.

"What range of devices need to be supported?"

My big bugbear. 300 devices, of the same model/manufacturer reduces the drivers required. The more drivers there are, the more likely you are to have problems. Universal drivers, although a wonderful idea need testing and may created problems with certain documents on certain devices.

Cross manufacturer printing is generally frowned upon, but if you can standardise on PCL 6 or PS, and all devices support this then the jobs should come out, although you may lose n-up options and other additional features. That said, in general Paper size, Colour.Mono and Duplex will generally travel quite well. This needs good testing, and is only a good idea if pull printing across multiple devices types is required.

*Extra Notes*
If using Citrix, ensure any clients are drivers are also supported.
32 or 64bit?? Good questions. Your choice....I prefer 32bit for core driver compatibility, but then 64bit is now the only options depending on server OS choice..and I have seen many 2008 R2 server handle 32 bit clients well.

OK, I'm going to stop drivelling on before you fall asleep!

Hope this helps!

Felicia KingConnect With a Mentor Commented:
Given the significant printing needs you have, you must have some high end copy machines as your printers. I would contact your copier vendor and see what software solution they have for metering. I am currently doing chargebacks based upon metering. You have program a print queue, such as the one on your server, to prompt for a 5 digit user code when a print job is sent. This code is then tied to a user and they are charged for jobs. You should also be able to grant or deny color printing access with these codes.

Regarding the print server setup .... I hate them, but that is a personal preference. I find it must more effective to simply install the print queues on the workstations. You may think I'm talking small potatoes. I used to manage an environment with 13,000 users this way. No print servers. In this way, there was no single point of failure (the print server). I wrote VB scripts to remotely install the print queues on the computers. Each department would have a set of printers that they would get. Uninstalls of the locally-installed print queues were as simply as an uninstall script. Customizations to the print queues were simply registry keys.

If you are doing printer pooling, then that's a whole different animal. You need a print server then. But if you are talking about a department that shares 3 or 4 printers without pooling, then I don't see the need.

I think that having a single print server for all 300 printers is a pretty huge single point of failure. If it went down, you have 3000 people that can't print. Regardless of the capacity, I would split the load of the shared queues as much as possible if you are dead set on the print server strategy.
Any feedback?
This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.
All Courses

From novice to tech pro — start learning today.