I assume your Windows servers are at least Windows Server 2003 or Server 2008 ...
At the client/staff computers, setup the print connection as a "Local Printer" and use either LPR or "Local Port" to connect to the print queue at the server. You'll have to specify what driver to use and you may need to manually set some settings at the client computer ... but at the client's computer only that client's print jobs will be seen and only long enough for the print job to transfer to the server at which point the client's computer will no longer "see" the print job.
It's more work with each computer, but it effectively avoids exposing the list of print jobs to the end user.
Also, if you're using Server 2008 to drive your Domain controllers, you *might* be able to use Group Policies to "push" 'local' printer setups to the client computers. I know you can "push" out 'network' or 'shared' print connections to client computers by Group Policies (we use that to some extent) however with Server 2008 you *should* be able to also push out "local" printer setups (but we haven't tried that, couldn't help you with trying that).
One more option ...
Make a third print queue at the server (a queue that isn't controlled by Pharos) and set that queue to forward print jobs to your Uniprint queue (I usually use LPR to do that). Then have your clients connect to the "non-controlled" queue which simply passes the queue to Pharos. That way, the client's do not see all the other print jobs because as soon as the jobs arrive in the "non-controlled" queue the job is forwarded to the Pharos queue (which the client is no longer viewing). With this method, you can still have your clients connect by "network printer" plus there wouldn't see the job list, plus you wouldn't have to manually setup print connections at the client's computers. The only drawback would be the additional print queue at the server plus the (nominal) delay inherant in having to forward the print job one extra step - I'd probably re-name the Pharos queue to something different so that I could name the "non-controlled" queue to the queue name you'd like your clients to connect to.
Hope one of those helps.
Thanks for the ideas.
Server side we do have 2008. We have a mix of managed and unmanaged machines, with our latest managed desktop (windows7) being domain joined so group policies might be able to help us with a bit of investigation.
The last option of a third print queue sounds simpliest.
Future releases of Uniprint should reduce/eliminate the need for the various options listed above.
Uniprint 8.3 will manage print jobs differently from prior versions of Uniprint. Starting with Uniprint 8.3, print jobs will still be received in the Windows queue as they are today; however, they are then moved out of the Windows spooler and managed directly by the Uniprint system. End result is that print jobs will no longer be held in the Windows queue; they will onlyappear temporarily when they are transmitted from the client to the server.
An official availability date for Uniprint 8.3 general release is not available yet; the current target is approximately March/April 2012.
Great. Thanks for the information!
There is another solution in the mean time to hide document names from users who have access to the shaired queue, thought setting up a queue that does print job fowarding. This can be applied both on the server end and the local side.
Server name is "Printserver", and the queue name is "printer1" and the device name is "printer123"
Under a normal setup:
printer1 (Spool queue Pharos port) Fowards the jobs printer123 (device queue, Ip address port)
Queue job fowarding:
Manually create a queue on the server or on the local machine idential to Printer1 but have it create a local port called "\\printserver\printer1" for this example we will call the new queue Printer1secure
Printer1secure (local port called "\\printserver\printer1") fowards jobs to Printer1 (spool queeu Pharos port) fowards job to Printer123 (device queue, ip address port)
Charging will still work correctly and the queue can be either shaired out from the server or setup locally on the client comptuer. We have the queues setup on our server for easy managment.
The jobs that are sent from Printer1secure will appear in the queue of Printer1 with the name "remote downlevel document" and the real name will now be hidden from users. I wouldn't use theis as the primary queue since all the jobs will have exactly the same name, but it's good for security.
Hope this helps
To update this thread, uniprint 8.4 has come along now and hides the jobs! :O)
This was actually introduced with Uniprint 8.3, as Paul van Wichen noted on the 17th of April. Rather than maintain the jobs in a HELD state on the share, our Secure Release Service whisks each job out of the queue upon receipt, page counts it, and then moves it into a JobStore folder populated with subdirectories labeled as your user's names. When the user authenticates at a PC Station or Pharos terminal device, the Secure Release Service uses the User ID as a search, retrieving the jobs that match the user's ID.
Okay - thanks for clarifiying that point!