cups-lpr from Windows Server 2003

[John A. Murdie]

(Disclaimer: I'm not a Windows administrator, and leave such matters to others here, but I do manage the Solaris install of our CUPS print server.)

We have had a long-running organisational problem resulting from Windows Server 2003 apparently not being able to publish IPP printers to our several hundred Windows desktop clients. Thus to add another Windows desktop printer configuration means finding some way of updating the printer configurations of all the clients in one operation. I'd love to be able to make the Windows Server use IPP to CUPS, and publish the CUPS printers to the Windows clients. Drivers could be supplied to the Windows server with the CUPS extension of IPP for this task. Since this is not possible, the only practical possibility is having the clients use IPP directly to the CUPS server is by copying all 150Mb (!) of Windows printer drivers and configurations to each of them, and changes when those come along, but the Windows admins (and I!) think that is messy and too much trouble. Nor can we take the Windows clients away from their users to re-Ghost them when a printer configuration changes.

So, as a work-around we had the Windows server use Berkeley LPR protocol for printing to cups-lpr on the CUPS print server, forked from inetd. The printer configurations can be published to the clients. Is there a bottleneck here - inetd can fork as many cups-lpr processes as are required for simultaneous connnections, but is there a pinch point in this situation (more than it would be for configured multiple IPP connections to cupsd)?

The advantage of having Windows clients print through CUPS is that it is one way to achieve common printing on site - all users can use the CUPS web pages to see all the jobs waiting to be printed by a particular printer. Were we not to have Windows clients printing to CUPS, we'd have two parallel print systems using printers in common and no way of seeing a listing of waiting jobs sent for printing from the 'other side'. Users from one side get annoyed when their job is at the top of the queue marked as 'printing', but the job emerging from the printer is from the 'other side'!

A disadvantage of using cups-lpr from the Windows server is that jobs vanish from the Windows queues once spooled, to the reasonable chagrin of the Windows users. Is there a solution?

Has anyone a better way to work a mixed Unix/Windows operation? I'm starting to think that two completely separate sets of printers might be the only reasonable solution!

John A. Murdie