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

We have a student lab that uses a single color printer and multiple print queues to handle color and b/w prints. We're also using pcounter for our auditing. We're moving off of Novell's NDPS system and onto Windows 2008, and I've hit a bit of a wall in this instance. The printing managers want to have a single printer in this lab (a Ricoh printer in this case) and have two separate print objects for color and b/w jobs, and charge separately for either.

This is not a simple thing. PCounter's color detection is not reliable in this instance so we can't use that to keep color jobs out of the b/w queue. What seems to work is if we put two different printers on the lab-stations with locked down drivers. This model worked well in the Novell environment as students would have to add the Novell Client to their laptops in order to print color jobs to the b/w queue, and we never found any who did that. A Windows printing environment changes all that since just about anything can print to Windows Print objects these days.

Our students will be able to use personal non-domained machines on the wireless network (and maybe the dorms) to map drives to the central file-servers, and presumably the central print-servers as well. We have zero ways to manage these privately owned, non-domained laptops, so do not have any kind of driver-level control; especially for all those MacBooks running around. This is why driver-level solutions are not viable.

We have to allow the entire student body to print to these printers, but we'd really like it if the spooler would only accept jobs from specific work-stations as well. Does the Windows printing environment support a feature like that?

share|improve this question

4 Answers 4

up vote 1 down vote accepted

There is no functionality in the Windows Spooler Service to allow you to set permissions on print queues based on computer used to submit a print job-- only the user.

The only even halfway decent idea that I'm coming up with is to firewall the print server queuing for this printer such that only those computers permitted to submit print jobs can access TCP ports 139 and 445. That would be tedious to configure and could cause you to need more server computer instances to service different combinations of printer and permitted computers.

I thought about trying to hack Microsoft's Internet Printing Protocol (IPP) server, but that's a really long shot. It allows users to submit jobs through HTTP over IIS, which does have the ability to permit / deny requests based on source IP or DNS name. That's a long shot, thought.

I also thought about using a custom "front-end" process running, say, an HP "direct print" (TCP port 9100) server to authorize jobs based on submitting device. It could pick them up, authorize the job, and then submit it to the back-end Windows queue. The problem there is that per-user authentication and accounting would be lost.

I think you'd do well to buttoning-down your existing queue permissions and living with per-user security.

share|improve this answer

A Windows printing environment changes all that since just about anything can print to Windows Print objects these days.

When you share the printer from within Windows, there is a security tab that should allow you to set various permissions.

For your color/b&w issue, you should be able to install two separate printers for the one physical printer on the Windows, and assign different permissions to each. To make one just b&w, if you can't lock down the prefs, you can make the driver just a b&w PCL or PS driver that is compatible with that printer. For example, you could use the LaserJet 4 driver, which doesn't support color printing.

share|improve this answer
    
The problem is that if the printer-share is in the domain, any user that is allowed to print to it can print to it from any device with any driver they chose. Unless there is some way to restrict which computer objects are allowed to submit jobs. –  sysadmin1138 Jul 13 '09 at 23:14
    
I don't think the users can change the driver a printer uses without local admin rights, can they? And you can prevent them from installing new printers: technet.microsoft.com/en-us/library/cc938161.aspx. –  Adam Brand Jul 14 '09 at 0:42

Just a though and not one I've tested or am even in a position to test... Use security groups containing the devices, rather than users. Restrict the printing rights based on those groups.

share|improve this answer
    
The jobs are submitted with the user's access token, not the device. That won't do what sysadmin1138 is looking for. –  Evan Anderson Jul 14 '09 at 2:36
    
Another perfectly good theory down the drain. :( –  John Gardeniers Jul 14 '09 at 2:55

Reading the above, it sounds like the following scenario is what I'll need to do if I want to do what our printing-services folk want:

  • When creating print-shares, the printers that will be used for simultaneous color and B/W printing shall be set up for sharing on a print-server segregated from the rest of the plain old single-function printers.
  • This dedicated machine needs to use network controls (firewalls, router rules, whatnot) to keep Windows share traffic originating from where the students hang out from getting to it.

One thing I didn't make clear in the question is that our students will be able to use personal non-domained machines to map drives to the central file-servers, and presumably the central print-servers as well. We have zero ways to manage these privately owned, non-domained laptops, so do not have any kind of driver-level control; especially for all those MacBooks running around. This is why driver-level solutions are not viable.

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.