Serving NT4 print drivers from Samba

T. William Schmidt wschmidt at starband.net
Mon Sep 17 11:21:06 GMT 2001


Hello Jerry,

>you definitley want Samba 2.2.1a (maybe even get the latest SAMBA_2_2
>cds)

I have not downloaded 2.2.1a nor read the docs yet, but I will 
ASAP.  However...

>Don't use the 'printer driver' parameter in smb.conf.
>It is deprecated.

...this seems counterintuitive, to deprecate the printer driver 
property.  How else will the Add Printer Wizard (APW) on the client PC know 
which driver to (automatically) grab?  Let me restate the scenario with a 
little more detail.

We have 300+ document authors using Word and Excel to create compound docs 
containing text, photographic images and fragments of CAD drawings.  We 
have defined a Samba printer share EngrSDPS and associated that share name 
with the HP printer HP DesignJet 750C/PS with the printer driver = 
property.  We will instruct each author to define with the APW the printer 
EngrSDPS so that his PC has the driver we wish to use to generate the 
Postscript intermediate files.  By replacing the standard lpr command with 
our own Perl program in the printer command = property, capture the spool 
files and send them off for Distiller post-processing.  Without something like

printer driver = HP DesignJet 750C/PS

in smb.conf, there is no way for the APW to know which driver we want to 
download.  Yes, I know one can manually browse any media one has access to 
that contains drivers, including a Samba print$ share, like the one I 
articulated in my original post.  But the point is to automate grabbing the 
driver files just as a standard, vanilla NT4 print server would do.  How I 
got the driver in the first place installed on a test PC running NT4 was to 
simply select a real printer share from our production NT printer 
environment, define the relevant HP printer and the APW downloaded the 
driver.  I did not have to browse any file system for drivers.  The printer 
I chose was visible in the Network Neighborhood as a function of its 
membership in the browse master list.  I simple had to choose it and the 
APW knew exactly which driver to get, and it did.  I then deleted that 
printer definition and created a new printer definition that referred to 
the Samba printer and exploited the fact that once NT4 downloads a driver 
it hangs on to it even if you delete the printer definition that uses that 
driver.  That's ok for me running a proof-of-concept test but we desire an 
automated process for those 300 users.

The next objective was to make the Samba server behave the same way, but 
instead of selecting it from a browse list, I am doing 
\\netbiosName\EngrSDPS expecting the APW to grab the driver associated with 
the printer driver = property, but that part fails.  I can then manually 
from the NT4 client APW browse the print$ share on the Samba server and 
select the driver, which does download.

The real issue is, is this the best I can expect?  I want the fully 
automated behavior from the Samba server that I get from the NT4 server and 
I don't want to disclose to PC users that they can get the driver from the 
print$, or any other similar Samba share.  This should be totally transparent.

>I don't understand what you mean here.  Do you mean the user
>who is connecting to the printer?

Yes, the user I am talking about is the NT4 PC user attempting to define 
\\SambaNetbiosName\EngrSDPS.  We don't want him to know anything about the 
structure of our Samba print$ share environment.  We only want him to know 
the share name of our preferred printer and let the interaction between the 
client's APW and the Samba print server automatically resolve downloading 
the required driver files (See detail above).  To be clear, when I refer to 
the APW I mean the Add Printer Wizard on the client PC.  It presents to the 
PC user lists derived from ntprint.inf but if these particular users have 
to resort to list navigation, then I have failed to build a behavioral 
clone of a real NT4 print server, of which we have seven serving up about 
200 printers and plotters.

>If I had guessed wrong, give me some more details on your
>exact problem.  I'm a little confused by your description
>as it is.

If the latest version of Samba does not behave the way I have described, 
then I intend to examine the Samba source and see if I can patch it so that 
it does.  My problem is managing my expectations and the expectations of 
others that I set.  I expect a Samba print server to behave exactly the way 
an NT4 print server does, and when it does not, I am not sure if it is my 
inadequate implementation of smb.conf or that Samba lacks the exact NT4 
functionality I am describing.

Thanks again for your help.  I hope I have explained the problem better 
this time so that you can tell me whether any Samba implementation can do 
it the way we desire.

>cheers, jerry
>  ---------------------------------------------------------------------
>  www.samba.org              SAMBA Team              jerry_at_samba.org
>  www.plainjoe.org                                jerry_at_plainjoe.org
>  --"I never saved anything for the swim back." Ethan Hawk in Gattaca--
>
>
>--
>To unsubscribe from this list go to the following URL and read the
>instructions:  http://lists.samba.org/mailman/listinfo/samba

Regards,
Will Schmidt
SW Engineer/Consultant
Kipe & Associates       currently on assignment @ Freightliner LLC
Portland, OR
(541) 462-3160
(541) 462-3899 fax
-------------- next part --------------
HTML attachment scrubbed and removed


More information about the samba mailing list