This is a public service announcement. I wasn't able to find a solution to this problem on the web (or Usenet), so here's the solution I worked out.

I was having this problem where our Windows XP box wasn't printing in color. In our setup, our Linux box is connected to our printer. The Linux box prints via CUPS, and the printer is made visible to our Windows box via SAMBA. Printing from the Linux box directly works great, but printing from the Windows box resulted in everything being converted to grayscale.

The weirdest part about this problem was that we had the problem back when I was running Fedora, and it persisted even after I switched to Debian (including a completely new reinstall of CUPS and SAMBA).

The first thing I tried was changing the printer driver on the Windows box. I was using the Adobe PostScript drivers, so I tried switching to something that was explicitly color. I chose the Apple Color LaserWriter 12/600, since it's definitely color, and Apple LaserWriter tends to use standard PostScript (as opposed to HP PostScript printers, for example). To make a long story short: that didn't help. At least, it wasn't enough to do the trick on its own.

I think that pretty much eliminated the Windows driver as a suspect, and both CUPS and the printer were eliminated by the fact that I could print from the Linux box in color. So that left SAMBA. I went through the advanced options one by one until I came across "use client driver", which was set to "no". I had no idea what this setting was for, and the documentation wasn't much help:

This parameter applies only to Windows NT/2000 clients. It has no effect on Windows 95/98/ME clients. When serving a printer to Windows NT/2000 clients without first installing a valid printer driver on the Samba host, the client will be required to install a local printer driver. From this point on, the client will treat the print as a local printer and not a network printer connection. This is much the same behavior that will occur when disable spoolss = yes.

The differentiating factor is that under normal circumstances, the NT/2000 client will attempt to open the network printer using MS-RPC. The problem is that because the client considers the printer to be local, it will attempt to issue the OpenPrinterEx() call requesting access rights associated with the logged on user. If the user possesses local administator rights but not root privilegde on the Samba host (often the case), the OpenPrinterEx() call will fail. The result is that the client will now display an "Access Denied; Unable to connect" message in the printer queue window (even though jobs may successfully be printed).

If this parameter is enabled for a printer, then any attempt to open the printer with the PRINTER_ACCESS_ADMINISTER right is mapped to PRINTER_ACCESS_USE instead. Thus allowing the OpenPrinterEx() call to succeed. This parameter MUST not be able enabled on a print share which has valid print driver installed on the Samba server.

Default: use client driver = no

I learned far more about Windows system calls than I really wanted to by reading that. In any case, despite the fact that this didn't mention anything about printouts being converted to black-and-white, it did mention the message "Access Denied; Unable to connect". Checking our Windows box, this message was showing up in the printer settings window. So I enabled the "use client driver" setting and it worked! Not only did the "Access Denied" message disappear, but our Windows box now miraculously prints in color.

I can hear the Mac users chuckling already...