Staff Print Queues

Upon submission of the Add Printer form, two print queues will be created; a standard Windows print queue and an LPR queue.

No matter what queue/connection type is specified, the Papercut client must be installed, running and authenticated to print.

The queues will be created on papercut4.mps.sfu.ca, which is a VM running Windows Server 2008 R2 and a member of Campus Active Directory.

On a purely technical note, all queues are in fact LPR queues, with some "magic" that allows them to appear as conventional Windows queues as well as LPR queues.  There is therefore just a single queue on the print server, even though an external look appears to show two queues with two slightly different names. 

This strategy means that all settings (duplex, trays, permissions, etc.) will be the same for both queue types, hopefully reducing support issues. 

However, it also means that the physical printer itself must support LPR, as a Windows print server does not actually implement the LP protocol, it simply passes LP jobs through.  (Conventional Windows print jobs are converted by the server into LP jobs and then placed in the queue.)  Support staff must ensure that LPR is enabled in their printers before creating a print queue.

Printers that do not support the LPR protocol will not be able to participate in the current Papercut system.

Thankfully, all networkable printers produced in recent memory have LP capability, so this requirement should not affect anything but the very oldest or very cheapest of printers.

LPR Queues

LP is one of the oldest and most universal methods of printing via print queues, and print queues on a central server is both a requirement of using the Papercut system and just good practice in a large, shared computing environment.

The downside to LP is that there is no "list" to pick from; a person needs to know the name of the queue and the name of the server hosting the queue.

In the SFU Papercut system, we've tried to make this easy.  The server will be

papercut4.mps.sfu.ca

for all LPR queues.  And the queue name will be the OPS number (including the letters "OPS"), which a person can read right off the blue Konica Minolta tag.  

For the printer outside my office, the queue name is

OPS01542

For Linux and Mac users, this is the preferred method of printing.  

Windows users can also use this method, although it's not necessarily recommened.  Setup is more difficult as it requires the install of the LPR software from the Windows CD and also the download and install of a printer driver.  It does have the advantage though, of being able to pick a name for the print queue.  (Conventional Windows queues have the name fixed).  For people using LOTS of printers, being able to assign a name could make LPR worth the trouble.

End user instructions for Mac and Windows users are here.

No Linux instructions are available as there's just too many possible configurations of distros and versions; see your local guru.

It is again noted here that  the Windows server does not actually implement the LP protocol, it simply passes the job through to the printer.  The printer must therefore be able to accept LP jobs by having the port open inthe internal firewall, be listening on the port, have the LPD daemon running and so on.  

Just about every modern networkable printer is capable of doing so, but it's 50-50 whether this is enabled on the printer out of the box or not.  The local departmental IT person is responsible to configuring and enabling this functionality on their own printers.  (It's usually a very simple task; generally, click a box.)

Windows Queues

Form submissions will result in the creation of standard Windows print queues on Papercut4.  As stated above, the queue itself is actually an LPR queue, but Windows magic allows it to appear as a conventional Windows queue.

Queue permissions will be set to

  • allow the Everyone group to print (with the Papercut system limiting who can actually print)
  • (optionally) add a departmental group job management rights (to delete stuck jobs)
  • (optionally) add a departmental group queue management rights (to tweak driver settings)

The Windows queues will be named in a standard manner, conforming to the SFU Active Directory naming requirements.

All queue names will

  • begin with MPS and be followed by
  • the OPS number, including the letters OPS, followed by
  • MFD (when in fact the unit is a KM MFD), and finish with
  • BW or CLR as appropriate.

For example

MPS OPS01542 MFD BW

The resulting queue name will therefore remind the user of the capabilities.  (In the case of the example above, it's a Black and White Multi-Function device.)

Also, all queues will have the Location field in Active Directory populated.  

For users with Windows machines that are part of Campus Active Directory and are logged in with a domain account, using a Windows queue type is by far the preferred choice.  Finding the right queue is easy, as queues in the directory can be located by the MPS prefix or by the OPS # or by the location.  And once found, the correct driver will be automatically downloaded and installed.

It's also possible to use the Windows queue from a non-Campus AD connected machine.  It's a little more trouble to set up (although only a bit), but brings with it the automatic driver install; very handy.

End User instructions are here.

Macintosh and Linux users can also make use of Windows queues through Samba, but using an LPR queue, described below, is probably the better bet.