Windows Server 2003 printing without Samba to CUPS

[Kurt Pfeifle]

> Kurt Pfeifle wrote:
>> Forgot to insert an important sentence here: "However, the original
 > question had mentioned a 'without going through Samba'-condition."  :-)
>
> If it's just a matter of the Solaris CUPS server joining the domain as an "AD member server" then the data won't actually go "through" Samba, I presume - I was worried about the extra spooling step involved.

It is Samba that joins the domain. And as a domain member, it uses the
"winbind" component to verify user authentication for any access to its
shares and resources (winbind asks the Domain Controller if users should
be OK-ed).

While CUPS provides the heavy lifting of print job processing, it is
Samba which "publishes" and shares the printers towards the Windows
clients. The Windows clients send their jobs to Samba (which knows if
the user is an authenticated member of the domain). Samba hands the
job to CUPS (which decides independently  -- according to its own
configuration --   if a Samba-submitted user name [or the group he belongs to] should be given access or not).

So there is indeed an extra spooling step. Samba uses  -- *must* use! --
its own spool directory. But that spooling is only "raw" and therefor
very fast. Samba does not do any job format conversion.

CUPS in turn helps Samba to offer the right printer drivers to the
Windows print clients. (When the Windows clients install the printers
in this setup, they think they use a Windows print server and therefor
they want their usual semi-automatic driver installation.) For this
end, there is the "cupsaddsmb" utility which adds CUPS driver details
into Samba's driver repository in a way that the Windows clients will
be able to understand.

>>> The other alternative (like Mike explained) is to install the native
>>> Windows drivers onto the Windows server, and let the queue's "port
>>> monitor" (that is roughly analogous to what on CUPS is called "backend")
>>> point to each URL "http://cups-server-name:631/printers/printername"
>>> (don't forget the "631").

>> "This indeed does do the job without Samba (but requires to not need
>> any authentication for submitting jobs to CUPS)."

> The problem with this, again I presume, is that the Windows Server has to be updated manually each time a new printer is added to or removed from the Solaris CUPS server.

Right.

> It seems that using Samba might be the way forward, if I understand, though as Mike (Sweet) pointed out, it'll still be necessary to add the Windows printer drivers by hand, because "CUPS doesn't (yet) support the undocumented Microsoft IPP extension for driver download, but that works with Win2k, WinXP, and Win2k3".

Not exactly.

Mike described how to access the CUPS server without Samba. That implies
to install the native Windows printer drivers manually to the Windows
server. The job will be readied (into its final file format) on the
Windows side. When CUPS receives it, the job will be printer-consumable.
CUPS will only be a "raw" spooler.

> All a new area to me - an old Unix hand.

Have a look at these flow diagrams -- maybe they help you understand a
bit more about the various processes:

  http://us4.samba.org/samba/docs/man/Samba-HOWTO-Collection/images/1small.png
  http://us4.samba.org/samba/docs/man/Samba-HOWTO-Collection/images/2small.png
  http://us4.samba.org/samba/docs/man/Samba-HOWTO-Collection/images/3small.png
  http://us4.samba.org/samba/docs/man/Samba-HOWTO-Collection/images/11small.png
  http://us4.samba.org/samba/docs/man/Samba-HOWTO-Collection/images/12small.png
  http://us4.samba.org/samba/docs/man/Samba-HOWTO-Collection/images/13small.png
  http://us4.samba.org/samba/docs/man/Samba-HOWTO-Collection/images/14small.png


> John A. Murdie

Cheers,
Kurt