Is anyone restricting any color printing queues to a list of usernames? Can you share with me any tips? Are you using a separate notification script?
I'm working on sort of morphing the default logon script which checks for valid usernames, and it will be checked against a specific username field, but I'm not yet sure how to apply it against just one individual queue.
We host Pharos on a Windows print server. If we want to restrict a printer, we create the printer in Pharos then go to Windows Administrative Tools > Print Management, get Properties > Security tab and assign allowed groups to the printer. Typically these are queues that are based on class group membership which are auto-populated in Active Directory. This has worked well for us.
We try to avoid assigning users but have in a few cases if there wasn't an appropriate group.
No separate notification or popup is used. Our generic message says that it is academic printing so use wisely.
Should have mentioned that we remove Everyone from the Security tab too.
Thank you for the info. I'm trying to test this on OS X using the popup and adldaplogon.exe plugin for auth and it is allowing all print jobs through, despite my small test group from AD being in place on the printer's security tab. Do you deploy your printers via AD as well? I feel like I have everything in place and not sure what is going wrong.
I tested and this method doesn't appear to be working anymore. Will test and update you if I find a method that uses groups like we used to.
Depending on how your system is configured you could use a script on the PrintJobArrive Plug-In event that has the value PlugIn.UserName value to check a user in some way. If the check fails you can then fail the event so the job gets dropped/deleted from the system. Finally you could follow this up with using our "Notify" component if Popups is installed on the client to send a message back to the end user that can inform them of something.
As the PrintJobArrive event also has PlugIn.Queue you can have the script only follow logic of checking a username if the Queue is of a certain value so it won't check the username for every print job coming into the system.
I wrote a quick script using the PrintJobArrive event denying jobs based on the queue name and GetProperty() return value, it works like a charm!
Now I am going to write a popup and logging function to make sure users know why their jobs are restricted. This will work great in our Epson photo printer labs where only Photo majors are supposed to be able to print.
Thanks for the tip Jeff!
Your welcome! Nice on the script work! There is a large variety of things that can be done through the scripting language if needed such as sending an email when a certain job arrives or what have you, just shy of having the Print Service kick start my coffee maker.
Again, wondering why a script and not just setting the access rights in the Pharos queue to the group of users desired?
Why are you not just putting the users in a group and setting permissions on the queue to the group? That's the design of the software, no need for custom scripting or going into Windows (which seems highly problematic at best as you'd be breaking Pharos so to speak)
Using domain security groups for printer access only works when the queue is being connected as a standard RPC queue by way of a Windows/SAMBA client computer utilizing a unique Windows domain login account. In a lot of sites, this isn't the case, so a Pharos script ends up being the appropriate "man in the middle" solution.
I agree with you: when the security model is all domain-based, this is the most elegant of solutions. But when it's not, we have a suitable alternative.
All the best,
I get your example, and yes in a mixed Mac and personal laptop environment AD credentials are not going to work. My question is still, why a script instead of the access times for groups in Pharos Admin? Is the scripting a way to get around the one group to one user limitation in the software? If so, does Pharos have an example script for this? We have been asking for multiple group membership for nearly a decade to resolve printer access issues, so if there is scripting that compensates for this limitation I would hope it would have been offered as a solution by now.
Uniprint also has a feature to restrict Color printing to all queues based on the users Uniprint Group membership.
Color Printing Allowed - Governs whether Users in this Group can perform color printing.
To specify whether or not members of a group can print color, select "Yes" or "No" from the combo box in this field. If "No" is selected, users of this group will not be permitted to print color. An error message will inform them of this when they attempt to print a color job.
Note: This feature works even if install packages are not installed on client PCs, for example, jobs will still be disallowed if required. However, you must install packages on your client machines to make best use of this feature. Packages installed on client PCs allow Pharos system to notify users if they are allowed or not allowed to print color jobs.
Retrieving data ...