Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I bumped into this at work today, and I don't have a good answer. To elaborate, we have a windows print server sharing several printers. If you connect to this printer share with a windows client, it wants to install a printer driver. Why is this? One of the appeals of a print server is that you can send it a file, and have the processing done on the print server, rather than at your local machine.

This is a problem especially with older printers that do not have 64 bit drivers. As we migrate to windows 7, we are unable to use the printers, even though the print server can talk to them fine. Windows 7 cannot use them, because it can't get a 64 bit driver.

The only work around I have been able to find, is to set up a cups server that accepts everything as postscript, then does the correct processing for each printer. Why does windows work this way, and do I have another option?

share|improve this question
1  
If the printers are older the there is probably a built-in driver that is part of windows that will work. –  Zoredache Jan 18 '12 at 16:36

2 Answers 2

up vote 4 down vote accepted

You've answered this yourself with your CUPS server accepting everything as PostScript.

Each printer has different features, capabilities and support which is why different printers require different drivers. Remember, Postscript and PCL aren't mandatory.

It's easily circumvented when discussing text and a simple B&W laser printer, but take it to the extreme. You have a 50 page booklet in MS Word and you want to print to a big complicated multi function printer. Firstly, where would you configure Duplexing, which tray to get the paper from? These options come from the print driver - so is the print server expected to interpret the options and display it to the client somehow?

Secondly, when you click print, what exactly is MS Word meant to do with this document? Send it as a raw document - imagine the processing overhead? Or maybe MS could develop a custom universal driver - entirely possible, but it's unlikely to support complex features nor have any guaranteed success.

One of the appeals of a print server is that you can send it a file, and have the processing done on the print server, rather than at your local machine

I'd say this is untrue anyway. Print servers are about centralised management and distribution, not about offloading work.

Have you considered simply adding a different basic 64bit postrscript driver on the print server? This would probably get you the same result as the CUPS solution, with less mess.

share|improve this answer

The driver on the client pc basically transforms a print job into something the printer will understand - sometimes this may be something like PCL or PS, but in some cases it will be some more obscure only used by that brand/printer.

Basically the server just holds this prepared print job and queues them up before it can send it to the printer concerned. However the server also needs to know how to communicate with the printer, and it's handy to be able to print from the server, hence requiring the driver on the server.

One workaround I briefly looked into was setting up a 7x64 print server which seemed to do the trick, but the method I ended up using was to create images for the win7x64 pc's that already had all the print drivers in use in our organisation previously set up, so when deployed it needed to connect to a printer it already had the drivers.

Also I found a surprising amount of drivers successfully installed from server 2003/x86 servers to 7x64 clients, so the test 7x64 print server never actually went into production.

However these methods then end up with often mismatched driver versions on client and server which is not best practise at all, and using xp/x86 drivers on 7x64 also couldn't be considered best practise either, but this saved on upgrading loads of servers from 03 to 08 which at the time was the biggest reason to do so, so unfortunately I had to resort to those methods.

Also universal postscript drivers aren't always as good as you may hope - we had loads of HP business inkjet 2600's/2800's which weren't compatible with 7x64, tried using the HP universal ps driver which wouldn't work with them (I ensured to add a PS card to each printer before testing it).

+1 for built in drivers - I found some printers had no support for win7 on the manufacturer's website, yet Win 7 loaded a driver itself without issue.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.