You've answered this yourself with your CUPS server accepting everything as PostScript.
Each printer has different features, capabilities and support which is why different printers require different drivers. Remember, Postscript and PCL aren't mandatory.
It's easily circumvented when discussing text and a simple B&W laser printer, but take it to the extreme. You have a 50 page booklet in MS Word and you want to print to a big complicated multi function printer. Firstly, where would you configure Duplexing, which tray to get the paper from? These options come from the print driver - so is the print server expected to interpret the options and display it to the client somehow?
Secondly, when you click print, what exactly is MS Word meant to do with this document? Send it as a raw document - imagine the processing overhead? Or maybe MS could develop a custom universal driver - entirely possible, but it's unlikely to support complex features nor have any guaranteed success.
One of the appeals of a print server is that you can send it a file, and have the processing done on the print server, rather than at your local machine
I'd say this is untrue anyway. Print servers are about centralised management and distribution, not about offloading work.
Have you considered simply adding a different basic 64bit postrscript driver on the print server? This would probably get you the same result as the CUPS solution, with less mess.
I think this thread holds the answer to your question.
Yes, because the SYSTEM installed it, so this is the owner of the object, take a look inside the registry, the ACL on the printer connection inside HKCU should be set to owner=system.
Change Printer deployment from "publish printer" (which is rubbish by design) and use GPP Printers. On the common tab (every common tab) of the user configuration you can check: Run in user logged in credentials
If the use creates it, the user can delete it.
Mark
Best Answer
Use a group policy to point and print restriction.