Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This is more of a conceptual question than a question about an actual setup in practice.

Let's say I have a network printer, a print server (server A) and workstations B and C that will use the print services. (All of them are in the same subnet).

When workstations B and C want to use the printer through server A, do they:

  1. Still need the printer driver from the network printer? If they do, then after they download the printer driver, do they still connect to server A for printing?

Or:

  1. Connecting directly to the network printer instead (since they are all in the same network)?

In general, is a print server used to:

  1. Just distribute the drivers to the workstations which will then connect to the network printer directly?

Or:

  1. Manage the printing to the printers, such that workstations will connect to the print server instead of the connecting directly to the printer? If so, why does the workstation still have the printer driver installed?
share|improve this question
up vote 21 down vote accepted

In general, print servers are used to both distribute drivers to client computer and centrally process and manage the print jobs. In large environments it's useful to have homogeneous drivers (which will usually contain certain printing configurations that are desirable to control centrally) in addition to having a central location for managing and logging print jobs. For example, the most common setting I see companies want to "push out" to client PCs from the print server is to default to black and white printing, rather than color printing (to save money on the more expensive color ink).

So yes, in the general case, the client computer will connect to the print server, acquire the printer driver from it, and then connect to the server to actually print to that printer. It is possible, though much less common, to connect to a print server just to get the right driver, install the printer directly, with that driver, and then bypass the print server by printing directly to that printer. But note that this is dependent on how the printer is installed on the client. It's either installed "directly" as a stand-alone printer on the client, or installed as a shared printer from the print server, and this is what determines whether the client connects to the printer directly, or through the print server instead. This is where the distinction between a physical printer ("print device") and a logical printer matters - it is actually possible to have the same physical print device installed multiple times as different logical printers. For example, by installing the same print device once directly, and once via the shared printer on the print server.

Since you tagged your question with Server 2012 R2, this Technet doc on Server 2012 Printer Sharing Technologies will probably be of interest. Note the section titled: Enhanced Point and Print, which is a technology that allows clients to print to compatible printers through a Windows Server 2012+ print server without installing a specific driver for the printer on the client. Meaning, of course, that it's also possible to use a print server so that clients don't need to install drivers for specific printers, but it's still most common that a print server will but distribute drivers to client and process/manage client print jobs.

share|improve this answer
3  
Good answer, +1. But I think it might be worthwhile to differentiate between a printer (logical), and a print device(physical). – Ben Plont Mar 6 at 6:44
2  
@BenPlont Ewww, printers. But a good point, so I added it in. – HopelessN00b Mar 6 at 6:51
    
@HopelessN00b thanks for the marvelous reply. just curious - how do we dictate how the driver is install on the client - "as a standalone, or as a shared printer" ? if both are being installed, do they appear as 2 difference devices to a user ? – tiongmaru Mar 6 at 16:08
    
@tiongmaru You dictate how the printer is installed when you install it - if you install by directly connecting to the printer, it's installed as a direct connection. If connecting to the shared [logical] printer on the print server, then it's installed as a logical printer accessed through the print server. (If you wish to use the driver on the print server, but install as a direct device, you download the driver form the print server, but install directly and specify the downloaded driver during the install.) – HopelessN00b Mar 6 at 23:41
1  
Client-side printer drivers are pretty much obsolete on *nix since cups got PDF printing. Basically just creating a PDF client-side, then sending that off to the printer server; it's his problem now – dom0 Mar 7 at 1:22

A printer shared using Windows' file and printing sharing is exported via the SMB/CIFS protocol, which by itself provide little more than a "networked pipe" to the printing device. In other words, the shared printer become nothing more than a networked device, with the client in need to install the correct drivers to use it. The printer-sharing server is in charge to store the required drivers and to provide them to the connection clients.

In recent Windows version, sometime the shared printer is exported via a standard protocol as IPP or WDS. In this case the client don't need to install 3rd party driver simply because Windows has the relative standard drivers already build-in.

Finally, it is sometime possible to configure the print server itself as a real print queue. In this case, the client passes the page's postscript definition to the server, asking it to print the uploaded page. In this case the client does not need any driver, but it is a far less common scenario (one possible drawback is the very limited printing option exported to the client). This requires very recent Windows version (Win8/Win2012+).

share|improve this answer
2  
Or pretty much any unix variant going back decades, but hey. – Shadur Mar 7 at 0:11
1  
True. The unix-way of doing things was sometime miles ahead of what available on Windows side... – shodanshok Mar 7 at 12:40

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.