It has occurred to me that a workstation can connect to a printer in either of two ways:
- Printing directly to the IP of the printer with the print driver installed locally.
- Printing to a
\\Server\Printer1share with the print queue residing on the server.
Which way is preferred?
I would assume that printing directly to a network printer rather than going through the server would be the most efficient from the point of view of network traffic. On the other hand, a server printer share would be easier to manage with the correct driver automatically being downloaded to the workstations.
Also, what about using Group Policy Preferences to install this printer on the workstations? Does that require any specific way?
Another advantage of sharing the printer(s) on the print server is printer discovery. If you publish the printer in AD it makes it fairly easy for a user to discover and add the printer.
Also, this is my opinion but it's based on my experience in larger corporate environments: I think you'll find that sharing printers from a print server (or print servers) is the standard way of making them available to users. I've never seen a corporate environment (with more then a few users) that had users connecting directly to the printer. I would think that would make printer management, control and troubleshooting more cumbersome. A big part of managing any IT infrastructure is efficiency and having users connecting directly to the printers isn't very efficient from a manageability perspective.
SOHO environments, where there's no AD or servers of any kind are more likely to have users conected directly to the printer(s).
The answer may depend on the size of your network.
For a smaller network (perhaps no AD or servers) then users very well might just connect directly to a printer via IP. In that small of a network, it may well be better to connect directly rather than using a shared printer off of another workstation, in case the workstation sharing the printer were to be suddenly turned off.
For a small/mid-size network (with Active Directory), I usually use the AD as the printer server, load printer drivers (32 and 64 bit) on it and have them listed in Active Directory.
For larger networks, you should consider separating the print server (or have multiple) from the Active Directory, but listing them in the Active Directory is still a good idea. See the other comment in the responses regarding ACLs and permissions, as well.
Using the print server lets you manage printers centrally (for printer job/queue management), and the more printers you have, the more you'll want a print server to manage them. Being able to go into the printer from a central management point and clear a stuck job, check printer status or something is helpful sometimes.
It's nice for users to be able to auto-download drivers from the print server when you're installing a printer for the first time. Having them listed in AD also makes them easy to find for client workstations/end user and allows you to give the printer a common user-friendly name.
An alternative to listing/using AD (or even a printer server at all) that allows you to at least keep printer naming simple is to use a local network DNS name mapped to the printer's IP (and set the IP in the printer to be static). It's not too hard for a user to find a printer, add a printer, or know what it is if it has a friendly or easy to identify name.
Unless you have an unusually high volume of print jobs or an unreliable print server, going through a print server shouldn't be an issue.
Sometimes (rarely), I do print direct via IP when I'm dealing with Linux or Mac systems, to avoid having to set up connectivity with Samba on them, although these days Samba on Linux/Mac works really well.
EDIT: Updated based on feedback from comments below.
If the network printer has enough RAM and processing power then yes, printing direct via IP is the standard methodology. However, if you have a need to audit things such as department printing for charge-back to agents (common in Real Estate) or other metrics that are not provided by the device itself, then you will need to install the device to a print server (Windows or Linux) and share it out. Of course, the OS platform will depend on the auditing / monitoring software requirements.
The only real advantage of printing via a print server is that the documents can be managed much more easily, because it can be done from a central point. This can be significant when there's a problem. While in an ideal world all printing would be via the print server, even for that reason alone, Windows does not exist in an ideal world.
It's not at all uncommon to experience driver issues and odd behaviour when connecting via a print server. I've noticed that this is even common when mixing 32 and 64 bit operating systems and yet more common when you use 64 bits and one of the HP "universal" drivers. "Universal" in this context meaning that it doesn't work very well for anything.
What I prefer to do is start by configuring the print server and try to connect everyone that way. Only when problems arise that can't be readily solved will I connect them directly to the printer.
It depends on your site, and what sort of functionality that you need. If you don't need the extra functionality that the print server brings... why include it? You're only introducing another point of failure - with no extra redundancy.
If you're asking which is the most efficient in terms of network traffic, I really wouldn't worry about it unless you're printing a lot of documents... and if that's the case - go for the print server.
Further Investigation has revealed that a Computer Config GPP can map a TCP/IP printer directly, just that it needs a "Dummy" Printer Share to use to obtain it's print driver from. It doesn't actually use that Dummy print queue for printing, it does that directly to the network printer.