trying to get HEAD building again. If you want the code

prior to this merge, checkout HEAD_PRE_3_0_0_BETA_3_MERGE
(This used to be commit adb98e7b7cd0f025b52c570e4034eebf4047b1ad)

1 files changed, 3232 insertions, 775 deletions

diff --git a/docs/docbook/projdoc/printer_driver2.xml b/docs/docbook/projdoc/printer_driver2.xml
index da3eb838f2..11231e6c9a 100644
--- a/docs/docbook/projdoc/printer_driver2.xml
+++ b/docs/docbook/projdoc/printer_driver2.xml
@@ -1,1037 +1,3494 @@
 <chapter id="printing">
 
 <chapterinfo>
-	&author.jerry;
 	<author>
-		<firstname>Patrick</firstname><surname>Powell</surname>
+		<firstname>Kurt</firstname><surname>Pfeifle</surname>
 		<affiliation>
-			<address><email>papowell@lprng.org</email></address>
+			<orgname> Danka Deutschland GmbH </orgname>
+			<address><email>kpfeifle@danka.de</email></address>
 		</affiliation>
 	</author>
-	<pubdate> (3 May 2001) </pubdate>
+	&author.jerry;
+	<pubdate>May 32, 2003</pubdate>
 </chapterinfo>
 
-<title>Printing Support</title>
+<title>Classical Printing Support</title>
 
 <sect1>
-<title>Introduction</title>
-	
-<para>Beginning with the 2.2.0 release, Samba supports 
-the native Windows NT printing mechanisms implemented via 
-MS-RPC (i.e. the SPOOLSS named pipe).  Previous versions of 
-Samba only supported LanMan printing calls.</para>
-
-<para>The additional functionality provided by the new 
-SPOOLSS support includes:</para>
-	
-<itemizedlist>
-	<listitem><para>Support for downloading printer driver 
-	files to Windows 95/98/NT/2000 clients upon demand.
-	</para></listitem>
-	
-	<listitem><para>Uploading of printer drivers via the 
-	Windows NT Add Printer Wizard (APW) or the 
-	Imprints tool set (refer to <ulink 
-	url="http://imprints.sourceforge.net">http://imprints.sourceforge.net</ulink>). 
-	</para></listitem>
-		
-	<listitem><para>Support for the native MS-RPC printing 
-	calls such as StartDocPrinter, EnumJobs(), etc...  (See 
-	the MSDN documentation at <ulink 
-	url="http://msdn.microsoft.com/">http://msdn.microsoft.com/</ulink> 
-	for more information on the Win32 printing API)
-	</para></listitem>
-		
-	<listitem><para>Support for NT Access Control Lists (ACL) 
-	on printer objects</para></listitem>
-	
-	<listitem><para>Improved support for printer queue manipulation 
-	through the use of an internal databases for spooled job 
-	information</para></listitem>
-</itemizedlist>
+<title>Features and Benefits</title>
 
 <para>
-There has been some initial confusion about what all this means
-and whether or not it is a requirement for printer drivers to be 
-installed on a Samba host in order to support printing from Windows 
-clients. As a side note, Samba does not use these drivers in any way to process 
-spooled files.  They are utilized entirely by the clients.
+Printing is often a mission-critical service for the users.  Samba can
+provide this service reliably and seamlessly for a client network
+consisting of Windows workstations.
 </para>
 
 <para>
-The following MS KB article, may be of some help if you are dealing with
-Windows 2000 clients:  <emphasis>How to Add Printers with No User 
-Interaction in Windows 2000</emphasis>
+A Samba-3.0 print service may be run on a Standalone or a Domain
+member server, side by side with file serving functions, or on a
+dedicated print server. It can be made as tight or as loosely secured
+as needs dictate. Configurations may be simple or complex.  Available
+authentication schemes are essentially the same as described for file
+services in previous chapters. Overall, Samba's printing support is
+now able to replace an NT or Windows 2000 print server full-square,
+with additional benefits in many cases. Clients may download and
+install drivers and printers through their familiar "Point'n'Print"
+mechanism. Printer installations executed by "Logon Scripts" are no
+problem. Administrators can upload and manage drivers to be used by
+clients through the familiar "Add Printer Wizard". As an additional
+benefit, driver and printer management may be run from the command line
+or through scripts, making it more efficient in case of large numbers
+of printers. If a central accounting of print jobs (tracking every
+single page and supplying the raw data for all sorts of statistical
+reports) is required, this is best supported by CUPS as the print
+subsystem underneath the Samba hood.
 </para>
 
 <para>
-<ulink url="http://support.microsoft.com/support/kb/articles/Q189/1/05.ASP">http://support.microsoft.com/support/kb/articles/Q189/1/05.ASP</ulink>
+This chapter deals with the foundations of Samba printing, as they
+implemented by the more traditional UNIX (BSD- and System V-style)
+printing systems. Many things apply to CUPS, the newer Common UNIX
+Printing System, too; so if you use CUPS, you might be tempted to jump
+to the next chapter -- but you will certainly miss a few things if you
+do so. Better read this chapter too.
 </para>
 
-</sect1>
+<note>
+<para>
+Most of the given examples have been verified on Windows XP
+Professional clients. Where this document describes the responses to
+commands given, bear in mind that Windows 2000 clients are very
+similar, but may differ in details. Windows NT is somewhat different
+again.
+</para>
+</note>
 
+</sect1>
 
 <sect1>
-<title>Configuration</title>
+<title>Technical Introduction</title>
 
-<warning>
-<title>[print$] vs. [printer$]</title>
+<para>
+Samba's printing support always relies on the installed print
+subsystem of the Unix OS it runs on. Samba is a "middleman". It takes
+printfiles from Windows (or other SMB) clients and passes them to the
+real printing system for further processing. Therefore it needs to
+"talk" to two sides: to the Windows print clients and to the Unix
+printing system. Hence we must differentiate between the various
+client OS types each of which behave differently, as well as the
+various UNIX print subsystems, which themselves have different
+features and are accessed differently. This part of the Samba HOWTO
+Collection deals with the "traditional" way of Unix printing first;
+the next chapter covers in great detail the more modern
+<emphasis>Common UNIX Printing System</emphasis>
+(CUPS).
+
+<important><para>CUPS users, be warned: don't just jump on to the next
+chapter. You might miss important information contained only
+here!</para></important>
+</para>
+
+<sect2>
+<title>What happens if you send a Job from a Client</title>
 
 <para>
-Previous versions of Samba recommended using a share named [printer$].  
-This name was taken from the printer$ service created by Windows 9x 
-clients when a printer was shared.  Windows 9x printer servers always have 
-a printer$ service which provides read-only access via no 
-password in order to support printer driver downloads.
+To successfully print a job from a Windows client via a Samba
+print server to a UNIX printer, there are 6 (potentially 7)
+stages:
 </para>
-	
+
+<orderedlist>
+<listitem><para>Windows opens a connection to the printershare</para></listitem>
+
+<listitem><para>Samba must authenticate the user</para></listitem>
+
+<listitem><para>Windows sends a copy of the printfile over the network
+into Samba's spooling area</para></listitem>
+
+<listitem><para>Windows closes the connection again</para></listitem>
+
+<listitem><para>Samba invokes the print command to hand the file over
+to the UNIX print subsystem's spooling area</para></listitem>
+
+<listitem><para>The Unix print subsystem processes the print
+job</para></listitem>
+
+<listitem><para>The printfile may need to be explicitly deleted
+from the Samba spooling area.</para></listitem>
+
+</orderedlist>
+</sect2>
+
+<sect2>
+<title>Printing Related Configuration Parameters</title>
+
 <para>
-However, the initial implementation allowed for a 
-parameter named <parameter>printer driver location</parameter> 
-to be used on a per share basis to specify the location of 
-the driver files associated with that printer.  Another 
-parameter named <parameter>printer driver</parameter> provided 
-a means of defining the printer driver name to be sent to 
-the client.
+There are a number of configuration parameters in
+ controlling Samba's printing
+behaviour. Please also refer to the man page for smb.conf to
+acquire an overview about these. As with other parameters, there are
+Global Level (tagged with a "<emphasis>G</emphasis>" in the listings) and
+Service Level ("<emphasis>S</emphasis>") parameters.
 </para>
 
-</warning>
- 
+<variablelist>
+<varlistentry><term>Service Level Parameters</term>
+<listitem><para>These <emphasis>may</emphasis> go into the
+<parameter>[global]</parameter> section of
+. In this case they define the default
+behaviour of all individual or service level shares (provided those
+don't have a different setting defined for the same parameter, thus
+overriding the global default).</para></listitem>
+</varlistentry>
+
+<varlistentry><term>Global Parameters</term>
+<listitem><para>These <emphasis>may not</emphasis> go into individual
+shares.  If they go in by error, the "testparm" utility can discover
+this (if you run it) and tell you so.</para></listitem>
+</varlistentry>
+</variablelist>
+</sect2>
+
 <sect2>
-<title>Creating [print$]</title>	
+<title>Parameters Recommended for Use</title>
+
+<para>The following &smb.conf; parameters directly
+related to printing are used in Samba-3. See also the
+&smb.conf; man page for detailed explanations:
+</para>
+
+<formalpara>
+	<title>List of printing related parameters in Samba-3</title>
+<para>
+<itemizedlist><title>Global level parameters:</title>
+<listitem><para><parameter>addprinter command (G)</parameter></para></listitem>
+<listitem><para><parameter>deleteprinter command (G)</parameter></para></listitem>
+<listitem><para><parameter>disable spoolss (G)</parameter></para></listitem>
+<listitem><para><parameter>enumports command (G)</parameter></para></listitem>
+<listitem><para><parameter>load printers (G)</parameter></para></listitem>
+<listitem><para><parameter>lpq cache time (G)</parameter></para></listitem>
+<listitem><para><parameter>os2 driver map (G)</parameter></para></listitem>
+<listitem><para><parameter>printcap name (G), printcap (G)</parameter></para></listitem>
+<listitem><para><parameter>show add printer wizard (G)</parameter></para></listitem>
+<listitem><para><parameter>total print jobs (G)</parameter></para></listitem>
+<listitem><para><parameter>use client driver (G)</parameter></para></listitem>
+</itemizedlist>
+
+<itemizedlist><title>Service level parameters:</title>
+<listitem><para><parameter>hosts allow (S)</parameter></para></listitem>
+<listitem><para><parameter>hosts deny (S)</parameter></para></listitem>
+<listitem><para><parameter>lppause command (S)</parameter></para></listitem>
+<listitem><para><parameter>lpq command (S)</parameter></para></listitem>
+<listitem><para><parameter>lpresume command (S)</parameter></para></listitem>
+<listitem><para><parameter>lprm command (S)</parameter></para></listitem>
+<listitem><para><parameter>max print jobs (S)</parameter></para></listitem>
+<listitem><para><parameter>min print space (S)</parameter></para></listitem>
+<listitem><para><parameter>print command (S)</parameter></para></listitem>
+<listitem><para><parameter>printable (S), print ok (S)</parameter></para></listitem>
+<listitem><para><parameter>printer name (S), printer (S)</parameter></para></listitem>
+<listitem><para><parameter>printer admin (S)</parameter></para></listitem>
+<listitem><para><parameter>printing = [cups|bsd|lprng...] (S)</parameter></para></listitem>
+<listitem><para><parameter>queuepause command (S)</parameter></para></listitem>
+<listitem><para><parameter>queueresume command (S)</parameter></para></listitem>
+<listitem><para><parameter>total print jobs (S)</parameter></para></listitem>
+</itemizedlist>
+</para>
+</formalpara>
 
 <para>
-In order to support the uploading of printer driver 
-files, you must first configure a file share named [print$].  
-The name of this share is hard coded in Samba's internals so 
-the name is very important (print$ is the service used by 
-Windows NT print servers to provide support for printer driver 
-download).
+Samba's printing support implements the Microsoft Remote Procedure
+Calls (MS-RPC) methods for printing. These are used by Windows NT (and
+later) print servers. The old "LanMan" protocol is still supported as
+a fallback resort, and for older clients to use.  More details will
+follow further beneath.
 </para>
+</sect2>
 
-<para>You should modify the server's smb.conf file to add the global
-parameters and to create the 
-following file share (of course, some of the parameter values,
-such as 'path' are arbitrary and should be replaced with
-appropriate values for your site):</para>
+<sect2>
+<title>Parameters for Backwards Compatibility</title>
 
-<para><programlisting>
-[global]
-    ; members of the ntadmin group should be able
-    ; to add drivers and set printer properties
-    ; root is implicitly a 'printer admin'
-    printer admin = @ntadmin
-
-[print$]
-    path = /usr/local/samba/printers
-    guest ok = yes
-    browseable = yes
-    read only = yes
-    ; since this share is configured as read only, then we need
-    ; a 'write list'.  Check the file system permissions to make
-    ; sure this account can copy files to the share.  If this
-    ; is setup to a non-root account, then it should also exist
-    ; as a 'printer admin'
-    write list = @ntadmin,root
-</programlisting></para>
-	
-<para>The <ulink url="smb.conf.5.html#WRITELIST"><parameter>
-write list</parameter></ulink> is used to allow administrative 
-level user accounts to have write access in order to update files 
-on the share.  See the <ulink url="smb.conf.5.html">smb.conf(5) 
-man page</ulink> for more information on configuring file shares.</para>
-	
-<para>The requirement for <ulink url="smb.conf.5.html#GUESTOK"><command>guest 
-ok = yes</command></ulink> depends upon how your
-site is configured.  If users will be guaranteed to have 
-an account on the Samba host, then this is a non-issue.</para>
-
-<note>	
-<title>Author's Note</title>
-
-<para>
-The non-issue is that if all your Windows NT users are guaranteed to be 
-authenticated by the Samba server (such as a domain member server and the NT 
-user has already been validated by the Domain Controller in 
-order to logon to the Windows NT console), then guest access 
-is not necessary.  Of course, in a workgroup environment where 
-you just want to be able to print without worrying about 
-silly accounts and security, then configure the share for 
-guest access.  You'll probably want to add <ulink 
-url="smb.conf.5.html#MAPTOGUEST"><command>map to guest = Bad User
-</command></ulink> in the [global] section as well.  Make sure 
-you understand what this parameter does before using it 
-though. --jerry
+<para>
+Two new parameters that were added in Samba 2.2.2, are still present
+in Samba-3.0. Both of these options are described in the
+&smb.conf; man page and are disabled by
+default. <emphasis>Use them with caution!</emphasis>
 </para>
-</note>
 
-<para>In order for a Windows NT print server to support 
-the downloading of driver files by multiple client architectures,
-it must create subdirectories within the [print$] service
-which correspond to each of the supported client architectures.
-Samba follows this model as well.</para>
+<variablelist>
+<varlistentry><term><parameter>disable spoolss(G)</parameter></term>
+<listitem><para> This is
+provided for better support of Samba 2.0.x backwards capability. It
+will disable Samba's support for MS-RPC printing and yield identical
+printing behaviour to Samba 2.0.x.</para></listitem>
+</varlistentry>
 
-<para>Next create the directory tree below the [print$] share 
-for each architecture you wish to support.</para>
+<varlistentry><term><parameter>use client driver (G)</parameter></term>
+<listitem><para> was provided
+for using local printer drivers on Windows NT/2000 clients. It does
+not apply to Windows 95/98/ME clients.</para></listitem>
+</varlistentry>
+</variablelist>
 
-<para><computeroutput>
-[print$]-----
-        |-W32X86           ; "Windows NT x86"
-        |-WIN40            ; "Windows 95/98"
-        |-W32ALPHA         ; "Windows NT Alpha_AXP"
-        |-W32MIPS          ; "Windows NT R4000"
-        |-W32PPC           ; "Windows NT PowerPC"
-</computeroutput></para>
+<formalpara>
+<title>Parameters "for backward compatibility only", use with caution</title>
 
-<warning>
-<title>ATTENTION!  REQUIRED PERMISSIONS</title>
-	
 <para>
-In order to currently add a new driver to you Samba host, 
-one of two conditions must hold true:
+<itemizedlist>
+<listitem><para><parameter>disable spoolss (G)</parameter></para></listitem>
+
+<listitem><para><parameter>use client driver (S)</parameter></para></listitem>
+</itemizedlist>
+</para>
+</formalpara>
+
+</sect2>
+
+<sect2>
+<title>Parameters no longer in use</title>
+
+<para>
+Samba users upgrading from 2.2.x to 3.0 need to be aware that some
+previously available settings are no longer supported (as was
+announced some time ago). Here is a list of them:
 </para>
-		
+
+<formalpara>
+<title>"old" parameters, removed in Samba-3</title>
+
+<para>
+The following &smb.conf; parameters have been
+deprecated already in Samba 2.2 and are now completely removed from
+Samba-3.  You cannot use them in new 3.0 installations:
+
 <itemizedlist>
-	<listitem><para>The account used to connect to the Samba host 
-	must have a uid of 0 (i.e. a root account)</para></listitem>
-		
-	<listitem><para>The account used to connect to the Samba host
-	must be a member of the <ulink 
-	url="smb.conf.5.html#PRINTERADMIN"><parameter>printer 
-	admin</parameter></ulink> list.</para></listitem>
+<listitem><para><parameter>printer driver file (G)</parameter></para></listitem>
+<listitem><para><parameter>total print jobs (G)</parameter></para></listitem>
+<listitem><para><parameter>postscript (S)</parameter></para></listitem>
+<listitem><para><parameter>printer driver (S)</parameter></para></listitem>
+<listitem><para><parameter>printer driver location (S)</parameter></para></listitem>
 </itemizedlist>
+</para>
+
+</formalpara>
+
+</sect2>
+</sect1>
+
+<sect1>
+<title>A simple Configuration to Print with Samba-3</title>
 
 <para>
-Of course, the connected account must still possess access
-to add files to the subdirectories beneath [print$]. Remember
-that all file shares are set to 'read only' by default.
+Here is a very simple example configuration for print related settings
+in the  file. If you compare it with your
+own system's , you probably find some
+additional parameters included there (as pre-configured by your OS
+vendor). Further below is a discussion and explanation of the
+parameters. Note, that this example doesn't use many parameters.
+However, in many environments these are enough to provide a valid
+ which enables all clients to print.
 </para>
-</warning>
 
+<para><programlisting>
+ [global]
+         printing = bsd
+         load printers = yes
+
+ [printers]
+         path = /var/spool/samba
+         printable = yes
+         public = yes
+         writable = no
+</programlisting></para>
 
 <para>
-Once you have created the required [print$] service and 
-associated subdirectories, simply log onto the Samba server using 
-a root (or <parameter>printer admin</parameter>) account
-from a Windows NT 4.0/2k client.  Open "Network Neighbourhood" or
-"My Network Places" and browse for the Samba host.  Once you have located
-the server, navigate to the "Printers..." folder.
-You should see an initial listing of printers
-that matches the printer shares defined on your Samba host.
+This is only an example configuration. Many settings, if not
+explicitly set to a specific value, are used and set by Samba
+implicitly to its own default, because these have been compiled in.
+To see all settings, let root use the <command>testparm</command>
+utility. <command>testparm</command> also gives warnings if you have
+mis-configured certain things. Its complete output is easily 340 lines
+and more. You may want to pipe it through a pager program.
+</para>
+
+<para>
+The syntax for the configuration file is easy to grasp. You should
+know that  is not very picky about its
+syntax. It has been explained elsewhere in this document. A short
+reminder: It even tolerates some spelling errors (like "browsable"
+instead of "browseable"). Most spelling is case-insensitive. Also, you
+can use "Yes|No" or "True|False" for boolean settings. Lists of names
+may be separated by commas, spaces or tabs.
+</para>
+
+<sect2>
+<title>Verification of "Settings in Use" with <command>testparm</command></title>
+
+<para>
+To see all (or at least most) printing related settings in Samba,
+including the implicitly used ones, try the command outlined below
+(hit "ENTER" twice!). It greps for all occurrences of "lp", "print",
+"spool", "driver", "ports" and "[" in testparm's output and gives you
+a nice overview about the running smbd's print configuration. (Note
+that this command does not show individually created printer shares,
+or the spooling paths in each case). Here is the output of my Samba
+setup, with exactly the same settings in 
+as shown above:
 </para>
+
+<para><screen>
+&rootprompt;<userinput>testparm -v | egrep "(lp|print|spool|driver|ports|\[)"</userinput>
+ Load smb config files from /etc/samba/smb.conf.simpleprinting
+ Processing section "[homes]"
+ Processing section "[printers]"
+ 
+ [global]
+        smb ports = 445 139
+        lpq cache time = 10
+        total print jobs = 0
+        load printers = Yes
+        printcap name = /etc/printcap
+        disable spoolss = No
+        enumports command =
+        addprinter command = 
+        deleteprinter command = 
+        show add printer wizard = Yes
+        os2 driver map =
+        printer admin =
+        min print space = 0
+        max print jobs = 1000
+        printable = No
+        printing = bsd
+        print command = lpr -r -P'%p' %s
+        lpq command = lpq -P'%p'
+        lprm command = lprm -P'%p' %j
+        lppause command =
+        lpresume command =
+        printer name =
+        use client driver = No
+
+ [homes]
+
+ [printers]
+        path = /var/spool/samba
+        printable = Yes
+
+</screen></para>
+
+<para>
+You can easily verify which settings were implicitly added by Samba's
+default behaviour. <emphasis>Don't forget about this point: it may
+be important in your future dealings with Samba.</emphasis>
+</para>
+
+<note><para> testparm in Samba-3.0 behaves differently from 2.2.x: used
+without the "-v" switch it only shows you the settings actually
+written into ! To see the complete
+configuration used, add the "-v" parameter to testparm.</para></note>
+
 </sect2>
 
 <sect2>
-<title>Setting Drivers for Existing Printers</title>
+<title>A little Experiment to warn you</title>
+
+<para>
+Should you need to troubleshoot at any stage, please always come back
+to this point first and verify if "testparm" shows the parameters you
+expect! To give you an example from personal experience as a warning,
+try to just "comment out" the <parameter>load printers</parameter>"
+parameter. If your 2.2.x system behaves like mine, you'll see this:
+</para>
+
+<para><screen>
+&rootprompt;grep "load printers" /etc/samba/smb.conf
+ #      load printers = Yes
+        # This setting is commented ooouuuuut!!
+
+&rootprompt;testparm -v /etc/samba/smb.conf | egrep "(load printers)"
+        load printers = Yes
 
-<para>The initial listing of printers in the Samba host's 
-Printers folder will have no real printer driver assigned 
-to them. This defaults to a NULL string to allow the use
-of the local Add Printer Wizard on NT/2000 clients.
-Attempting to view the printer properties for a printer
-which has this default driver assigned will result in 
-the error message:</para>
+</screen></para>
 
 <para>
-<emphasis>Device settings cannot be displayed.  The driver 
-for the specified printer is not installed, only spooler 
-properties will be displayed.  Do you want to install the 
-driver now?</emphasis>
+Despite my imagination that the commenting out of this setting should
+prevent Samba from publishing my printers, it still did! Oh Boy -- it
+cost me quite some time to find out the reason. But I am not fooled
+any more... at least not by this ;-)
 </para>
 
+<para><screen>
+&rootprompt;<userinput>grep -A1 "load printers" /etc/samba/smb.conf</userinput>
+        load printers = No
+        # This setting is what I mean!!
+ #      load printers = Yes
+        # This setting is commented ooouuuuut!!
+
+&rootprompt;<userinput>testparm -v smb.conf.simpleprinting | egrep "(load printers)"</userinput>
+        load printers = No
+
+</screen></para>
+
 <para>
-Click "No" in the error dialog and you will be presented with
-the printer properties window.  The way to assign a driver to a 
-printer is to either
+Only when setting the parameter explicitly to
+"<parameter>load printers = No</parameter>"
+would Samba recognize my intentions. So my strong advice is:
 </para>
-	
+
 <itemizedlist>
-	<listitem><para>Use the "New Driver..." button to install 
-	a new printer driver, or</para></listitem>
-	
-	<listitem><para>Select a driver from the popup list of 
-	installed drivers.  Initially this list will be empty.</para>
-	</listitem>
+<listitem><para>Never rely on "commented out" parameters!</para></listitem>
+
+<listitem><para>Always set it up explicitly as you intend it to
+behave.</para></listitem>
+
+<listitem><para>Use <command>testparm</command> to uncover hidden
+settings which might not reflect your intentions.</para></listitem>
+
 </itemizedlist>
-	
-<para>If you wish to install printer drivers for client 
-operating systems other than "Windows NT x86", you will need 
-to use the "Sharing" tab of the printer properties dialog.</para>
-
-<para>Assuming you have connected with a root account, you 
-will also be able modify other printer properties such as 
-ACLs and device settings using this dialog box.</para>
-
-<para>A few closing comments for this section, it is possible 
-on a Windows NT print server to have printers
-listed in the Printers folder which are not shared.  Samba does
-not make this distinction.  By definition, the only printers of
-which Samba is aware are those which are specified as shares in
-<filename>smb.conf</filename>.</para>
-  
-<para>Another interesting side note is that Windows NT clients do
-not use the SMB printer share, but rather can print directly 
-to any printer on another Windows NT host using MS-RPC.  This
-of course assumes that the printing client has the necessary
-privileges on the remote host serving the printer.  The default
-permissions assigned by Windows NT to a printer gives the "Print"
-permissions to the "Everyone" well-known group.
-</para>
 
-</sect2>	
+<para>
+You can have a working Samba print configuration with this
+minimal :
+</para>
 
+<para><screen>
+&rootprompt;<userinput>cat /etc/samba/smb.conf-minimal</userinput>
+        [printers]
 
-<sect2>
-<title>Support a large number of printers</title>
-		
-<para>One issue that has arisen during the development
-phase of Samba 2.2 is the need to support driver downloads for
-100's of printers.  Using the Windows NT APW is somewhat 
-awkward to say the list.  If more than one printer are using the 
-same driver, the <ulink url="rpcclient.1.html"><command>rpcclient's
-setdriver command</command></ulink> can be used to set the driver
-associated with an installed driver.  The following is example
-of how this could be accomplished:</para>
-		
-<para>
-<prompt>$ </prompt><userinput>rpcclient pogo -U root%secret -c "enumdrivers"</userinput>
-<programlisting> 
-Domain=[NARNIA] OS=[Unix] Server=[Samba 2.2.0-alpha3]
- 
-[Windows NT x86]
-Printer Driver Info 1:
-     Driver Name: [HP LaserJet 4000 Series PS]
- 
-Printer Driver Info 1:
-     Driver Name: [HP LaserJet 2100 Series PS]
- 
-Printer Driver Info 1:
-     Driver Name: [HP LaserJet 4Si/4SiMX PS]
-</programlisting>				  
-<prompt>$ </prompt><userinput>rpcclient pogo -U root%secret -c "enumprinters"</userinput>
-<programlisting>
-Domain=[NARNIA] OS=[Unix] Server=[Samba 2.2.0-alpha3]
-     flags:[0x800000]
-     name:[\\POGO\hp-print]
-     description:[POGO\\POGO\hp-print,NO DRIVER AVAILABLE FOR THIS PRINTER,]
-     comment:[]
-				  
-</programlisting>
-<prompt>$ </prompt><userinput>rpcclient pogo -U root%secret -c "setdriver hp-print \"HP LaserJet 4000 Series PS\""</userinput>
-<programlisting>
-Domain=[NARNIA] OS=[Unix] Server=[Samba 2.2.0-alpha3]
-Successfully set hp-print to driver HP LaserJet 4000 Series PS.
-</programlisting></para>
-</sect2>
+</screen></para>
 
+<para>
+This example should show you that you can use testparm to test any
+filename for fitness as a Samba configuration. Actually, we want to
+encourage you <emphasis>not</emphasis> to change your
+ on a working system (unless you know
+exactly what you are doing)! Don't rely on an assumption that changes
+will only take effect after you re-start smbd!  This is not the
+case. Samba re-reads its  every 60
+seconds and on each new client connection. You might have to face
+changes for your production clients that you didn't intend to apply at
+this time! You will now note a few more interesting things. Let's now
+ask <command>testparm</command> what the Samba print configuration
+would be, if you used this minimalistic file as your real
+:
+</para>
 
+<para><screen>
+&rootprompt;<userinput> testparm -v /etc/samba/smb.conf-minimal | egrep "(print|lpq|spool|driver|ports|[)"</userinput>
+ Processing section "[printers]"
+ WARNING: [printers] service MUST be printable!
+ No path in service printers - using /tmp
+
+        lpq cache time = 10
+        total print jobs = 0
+        load printers = Yes
+        printcap name = /etc/printcap
+        disable spoolss = No
+        enumports command =
+        addprinter command =
+        deleteprinter command =
+        show add printer wizard = Yes
+        os2 driver map =
+        printer admin =
+        min print space = 0
+        max print jobs = 1000
+        printable = No
+        printing = bsd
+        print command = lpr -r -P%p %s
+        lpq command = lpq -P%p
+        printer name =
+        use client driver = No
+ [printers]
+        printable = Yes
+
+</screen></para>
 
-<sect2>
-<title>Adding New Printers via the Windows NT APW</title>
-	
 <para>
-By default, Samba offers all printer shares defined in <filename>smb.conf</filename>
-in the "Printers..." folder.  Also existing in this folder is the Windows NT 
-Add Printer Wizard icon.  The APW will be show only if
+testparm issued 2 warnings:
 </para>
 
 <itemizedlist>
-	<listitem><para>The connected user is able to successfully
-	execute an OpenPrinterEx(\\server) with administrative
-	privileges (i.e. root or <parameter>printer admin</parameter>).
-	</para></listitem>
-	
-	<listitem><para><ulink url="smb.conf.5.html#SHOWADDPRINTERWIZARD"><parameter>show 
-	add printer wizard = yes</parameter></ulink> (the default).
-	</para></listitem>
+<listitem><para>because we didn't specify the
+<parameter>[printers]</parameter> section as printable,
+and</para></listitem>
+
+<listitem><para>because we didn't tell it which spool directory to
+use.</para></listitem>
+
 </itemizedlist>
 
 <para>
-In order to be able to use the APW to successfully add a printer to a Samba 
-server, the <ulink url="smb.conf.5.html#ADDPRINTERCOMMAND"><parameter>add 
-printer command</parameter></ulink> must have a defined value.  The program
-hook must successfully add the printer to the system (i.e. 
-<filename>/etc/printcap</filename> or appropriate files) and 
-<filename>smb.conf</filename> if necessary.
-</para>
-
-<para>
-When using the APW from a client, if the named printer share does 
-not exist, <command>smbd</command> will execute the <parameter>add printer 
-command</parameter> and reparse to the <filename>smb.conf</filename>
-to attempt to locate the new printer share.  If the share is still not defined,
-an error of "Access Denied" is returned to the client.  Note that the 
-<parameter>add printer program</parameter> is executed under the context
-of the connected user, not necessarily a root account.
-</para>
-
-<para>
-There is a complementary <ulink url="smb.conf.5.html#DELETEPRINTERCOMMAND"><parameter>delete
-printer command</parameter></ulink> for removing entries from the "Printers..."
-folder.
-</para>
-
-<para>
-The following is an example <ulink url="smb.conf.5.html#ADDPRINTERCOMMAN"><parameter>add printer command</parameter></ulink> script. It adds the appropriate entries to <filename>/etc/printcap.local</filename> (change that to what you need) and returns a line of 'Done' which is needed for the whole process to work.
-</para>
-
-<programlisting>
-#!/bin/sh
-
-# Script to insert a new printer entry into printcap.local
-#
-# $1, printer name, used as the descriptive name
-# $2, share name, used as the printer name for Linux
-# $3, port name
-# $4, driver name
-# $5, location, used for the device file of the printer
-# $6, win9x location
-
-#
-# Make sure we use the location that RedHat uses for local printer defs
-PRINTCAP=/etc/printcap.local
-DATE=`date +%Y%m%d-%H%M%S`
-LP=lp
-RESTART="service lpd restart"
-
-# Keep a copy
-cp $PRINTCAP $PRINTCAP.$DATE
-# Add the printer to $PRINTCAP
-echo ""				 			>> $PRINTCAP
-echo "$2|$1:\\" 					>> $PRINTCAP
-echo "  :sd=/var/spool/lpd/$2:\\" 			>> $PRINTCAP
-echo "  :mx=0:ml=0:sh:\\" 				>> $PRINTCAP
-echo "  :lp=/usr/local/samba/var/print/$5.prn:" 	>> $PRINTCAP
-
-touch "/usr/local/samba/var/print/$5.prn" >> /tmp/printadd.$$ 2>&amp;1
-chown $LP "/usr/local/samba/var/print/$5.prn" >> /tmp/printadd.$$ 2>&amp;1
-
-mkdir /var/spool/lpd/$2
-chmod 700 /var/spool/lpd/$2
-chown $LP /var/spool/lpd/$2
-#echo $1 >> "/usr/local/samba/var/print/$5.prn"
-#echo $2 >> "/usr/local/samba/var/print/$5.prn"
-#echo $3 >> "/usr/local/samba/var/print/$5.prn"
-#echo $4 >> "/usr/local/samba/var/print/$5.prn"
-#echo $5 >> "/usr/local/samba/var/print/$5.prn"
-#echo $6 >> "/usr/local/samba/var/print/$5.prn"
-$RESTART >> "/usr/local/samba/var/print/$5.prn"
-# Not sure if this is needed
-touch /usr/local/samba/lib/smb.conf
-#
-# You need to return a value, but I am not sure what it means.
-#
-echo "Done"
-exit 0
-</programlisting>
+However, this was not fatal, and Samba-3.0 will default to values that
+will work here. But, please!, don't rely on this and don't use this
+example! This was only meant to make you careful to design and specify
+your setup to be what you really want it to be. The outcome on your
+system may vary for some parameters, since you may have a Samba built
+with a different compile-time configuration.
+<emphasis>Warning:</emphasis> don't put a comment sign <emphasis>at
+the end</emphasis> of a valid  line. It
+will cause the parameter to be ignored (just as if you had put the
+comment sign at the front). At first I regarded this as a bug in my
+Samba version(s). But the man page states: <quote>Internal whitespace
+in a parameter value is retained verbatim.</quote> This means that a
+line consisting of, for example,
+</para>
+
+<para><screen>
+printing = lprng     #This defines LPRng as the printing system"
+</screen></para>
 
+<para>
+will regard the whole of the string after the "="
+sign as the value you want to define. And this is an invalid value
+that will be ignored, and a default value used instead.]
+</para>
 </sect2>
+</sect1>
+
+<sect1>
+<title>Extended Sample Configuration to Print with Samba-3</title>
+
+<para>
+Here we show a more verbose example configuration for print related
+settings in an . Below is a discussion
+and explanation of the various parameters. We chose to use BSD-style
+printing here, because we guess it is still the most commonly used
+system on legacy Linux installations (new installs now predominantly
+have CUPS, which is discussed entirely in the next chapter of this
+document). Note, that this example explicitly names many parameters
+which don't need to be stated because they are set by default. You
+might be able to do with a leaner .</para>
+
+<tip><para>
+if you read access it with the Samba Web Administration Tool (SWAT),
+and then write it to disk again, it will be optimized in a way such
+that it doesn't contain any superfluous parameters and comments. SWAT
+organizes the file for best performance. Remember that each smbd
+re-reads the Samba configuration once a minute, and that each
+connection spawns an smbd process of its own, so it is not a bad idea
+to optimize the  in environments with
+hundreds or thousands of clients.</para></tip>
+
+<para><programlisting>
+ [global]
+         printing = bsd
+         load printers = yes
+         show add printer wizard = yes
+         printcap name = /etc/printcap
+         printer admin = @ntadmin, root
+         total print jobs = 100
+         lpq cache time = 20
+         use client driver = no
+
+ [printers]
+         comment = All Printers
+         printable = yes
+         path = /var/spool/samba
+         browseable = no
+         guest ok = yes
+         public = yes
+         read only = yes
+         writable = no       
+
+ [my_printer_name]
+         comment = Printer with Restricted Access
+         path = /var/spool/samba_my_printer
+         printer admin = kurt
+         browseable = yes
+         printable = yes
+         writeable = no
+         hosts allow = 0.0.0.0
+         hosts deny = turbo_xp, 10.160.50.23, 10.160.51.60
+         guest ok = no
+</programlisting></para>
+
+<para>
+This <emphasis>also</emphasis> is only an example configuration. You
+may not find all the settings in your own
+ (as pre-configured by your OS
+vendor). Many configuration parameters, if not explicitly set to a
+specific value, are used and set by Samba implicitly to its own
+default, because these have been compiled in. To see all settings, let
+root use the <command>testparm</command>
+utility. <command>testparm</command> also gives warnings if you have
+mis-configured certain things..
+</para>
+</sect1>
+
+<sect1>
+<title>Detailed Explanation of the Example's Settings</title>
 
+<para>
+Following is a discussion of the settings from above shown example.
+</para>
 
 <sect2>
-<title>Samba and Printer Ports</title>
+<title>The [global] Section</title>
 
 <para>
-Windows NT/2000 print servers associate a port with each printer.  These normally
-take the form of LPT1:, COM1:, FILE:, etc...  Samba must also support the
-concept of ports associated with a printer.  By default, only one printer port,
-named "Samba Printer Port", exists on a system.  Samba does not really a port in
-order to print, rather it is a requirement of Windows clients.  
+The <parameter>[global]</parameter> section is one of 4 special
+sections (along with [<parameter>[homes]</parameter>,
+<parameter>[printers]</parameter> and
+<parameter>[print$]</parameter>...) It contains all parameters which
+apply to the server as a whole. It is the place for parameters which
+have only a "global" meaning (G). It may also contain service level
+parameters (S) which then define default settings for all other
+sections and shares. This way you can simplify the configuration and
+avoid setting the same value repeatedly. (Within each individual
+section or share you may however override these globally set "share
+level" settings and specify other values).
 </para>
 
+<variablelist>
+<varlistentry><term><parameter>printing = bsd</parameter></term>
+<listitem><para> this causes Samba to use default print commands
+applicable for the BSD (a.k.a. RFC 1179 style or LPR/LPD) printing
+system. In general, the "printing" parameter informs Samba about the
+print subsystem it should expect. Samba supports CUPS, LPD, LPRNG,
+SYSV, HPUX, AIX, QNX and PLP. Each of these systems defaults to a
+different <parameter>print command</parameter> (and other queue control
+commands).</para>
+<caution><para>The <parameter>printing</parameter> parameter is
+normally a service level parameter. Since it is included here in the
+<parameter>[global]</parameter> section, it will take effect for all
+printer shares that are not defined differently. Samba-3.0 no longer
+supports the SOFTQ printing system.</para></caution>
+</listitem></varlistentry>
+
+<varlistentry><term><parameter>load printers = yes</parameter></term>
+<listitem><para> this tells Samba to create automatically all
+available printer shares. "Available" printer shares are discovered by
+scanning the printcap file. All created printer shares are also loaded
+for browsing. If you use this parameter, you do not need to specify
+separate shares for each printer. Each automatically created printer
+share will clone the configuration options found in the
+<parameter>[printers]</parameter> section. (A <parameter>load printers
+= no</parameter> setting will allow you to specify each UNIX printer
+you want to share separately, leaving out some you don't want to be
+publicly visible and available).  </para></listitem></varlistentry>
+
+<varlistentry><term><parameter>show add printer wizard =
+yes</parameter></term> <listitem><para> this setting is normally
+enabled by default (even if the parameter is not written into the
+). It makes the <guiicon>Add Printer Wizard</guiicon> icon
+show up in the <guiicon>Printers</guiicon> folder of the Samba host's
+share listing (as shown in <guiicon>Network Neighbourhood</guiicon> or
+by the <command>net view</command> command). To disable it, you need to
+explicitly set it to <constant>no</constant> (commenting it out
+will not suffice!). The Add Printer Wizard lets you upload printer
+drivers to the <parameter>[print$]</parameter> share and associate it
+with a printer (if the respective queue exists there before the
+action), or exchange a printer's driver against any other previously
+uploaded driver.  </para></listitem></varlistentry>
+
+<varlistentry><term><parameter>total print jobs = 100</parameter></term>
+<listitem><para> this setting sets the upper limit to 100 print jobs
+being active on the Samba server at any one time. Should a client
+submit a job which exceeds this number, a <quote>no more space
+available on server</quote> type of error message will be returned by
+Samba to the client. A setting of "0" (the default) means there is
+<emphasis>no</emphasis> limit at all!
+</para></listitem></varlistentry>
+
+<varlistentry><term><parameter>printcap name = /etc/printcap</parameter></term>
+
+<listitem><para> this tells Samba where to look for a list of
+available printer names. (If you use CUPS, make sure that a printcap
+file is written: this is controlled by the "Printcap" directive of
+<filename>cupsd.conf</filename>).
+</para></listitem></varlistentry>
+
+<varlistentry><term><parameter>printer admin = @ntadmin</parameter></term>
+<listitem><para> members of the ntadmin group should be able to add
+drivers and set printer properties ("ntadmin" is only an example name,
+it needs to be a valid UNIX group name); root is implicitly always a
+<parameter>printer admin</parameter>. The "@" sign precedes group names in
+. A printer admin can do anything to
+printers via the remote administration interfaces offered by MS-RPC
+(see below).  Note that the <parameter>printer admin</parameter>
+parameter is normally a share level parameter, so you may associate
+different groups to different printer shares in larger installations,
+if you use the <parameter>printer admin</parameter> parameter on the
+share levels).
+</para></listitem></varlistentry>
+
+<varlistentry><term><parameter>lpq cache time = 20</parameter></term>
+<listitem><para> this controls the cache time for the results of the
+lpq command. It prevents the lpq command being called too often and
+reduces load on a heavily used print server.
+</para></listitem></varlistentry>
+
+<varlistentry><term><parameter>use client driver = no</parameter></term>
+<listitem><para> if set to <constant>yes</constant>, this setting only 
+takes effect for Win NT/2k/XP clients (and not for Win 95/98/ME). Its
+default value is <constant>No</constant> (or <constant>False</constant>).
+It must <emphasis>not</emphasis> be enabled on print shares 
+(with a <constant>yes</constant> or <constant>true</constant> setting) which
+have valid drivers installed on the Samba server! For more detailed
+explanations see the man page of &smb.conf;.
+</para></listitem></varlistentry>
+</variablelist>
+
+</sect2>
+
+<sect2>
+<title>The [printers] Section</title>
+
 <para>
-Note that Samba does not support the concept of "Printer Pooling" internally 
-either.  This is when a logical printer is assigned to multiple ports as 
-a form of load balancing or fail over.
+This is the second special section. If a section with this name
+appears in the &smb.conf;, users are able to
+connect to any printer specified in the Samba host's printcap file,
+because Samba on startup then creates a printer share for every
+printername it finds in the printcap file. You could regard this
+section as a general convenience shortcut to share all printers with
+minimal configuration. It is also a container for settings which
+should apply as default to all printers. (For more details see the
+&smb.conf; man page.) Settings inside this
+container must be share level parameters (S).
+</para>
+
+<variablelist>
+<varlistentry><term><parameter>comment = All printers</parameter></term>
+<listitem><para> the <parameter>comment</parameter> is shown next to
+the share if a client queries the server, either via <guiicon>Network
+Neighbourhood</guiicon> or with the <command>net view</command> command to list
+available shares.
+</para></listitem></varlistentry>
+
+<varlistentry><term><parameter>printable = yes</parameter></term>
+<listitem><para> please note well, that the
+<parameter>[printers]</parameter> service <emphasis>must</emphasis> be
+declared as printable. If you specify otherwise, smbd will refuse to
+load  at startup. This parameter allows
+connected clients to open, write to and submit spool files into the
+directory specified with the <parameter>path</parameter> parameter for
+this service. It is used by Samba to differentiate printer shares from
+file shares.  </para></listitem></varlistentry>
+
+<varlistentry><term><parameter>path = /var/spool/samba</parameter></term>
+<listitem><para>this must point to a directory used by Samba to spool
+incoming print files. <emphasis>It must not be the same as the spool
+directory specified in the configuration of your UNIX print
+subsystem!</emphasis> The path would typically point to a directory
+which is world writeable, with the "sticky" bit set to it.
+</para></listitem></varlistentry>
+
+<varlistentry><term><parameter>browseable = no</parameter></term>
+<listitem><para> this is always set to <constant>no</constant> if
+<parameter>printable = yes</parameter>. It makes the 
+<parameter>[printer]</parameter> share itself invisible in the
+list of available shares in a <command>net view</command> command or
+in the Explorer browse list. (Note that you will of course see the
+individual printers).
+</para></listitem></varlistentry>
+
+<varlistentry><term><parameter>guest ok = yes</parameter></term>
+
+<listitem><para>
+if set to <constant>yes</constant>, then no password is required to
+connect to the printers service. Access will be granted with the
+privileges of the <parameter>guest account</parameter>. On many systems the
+guest account will map to a user named "nobody". This user is in the UNIX
+passwd file with an empty password, but with no valid UNIX login.
+(Note: on some systems the guest account might not have the
+privilege to be able to print. Test this by logging in as your
+guest user using <command>su - guest</command> and run a system print
+command like
 </para>
 
+<para><userinput>lpr -P printername /etc/motd</userinput></para>
+
+</listitem></varlistentry>
+
+<varlistentry><term><parameter>public = yes</parameter></term>
+<listitem><para> this is a synonym for <parameter>guest ok =
+yes</parameter>. Since we have <parameter>guest ok = yes</parameter>,
+it really doesn't need to be here! (This leads to the interesting
+question: <quote>What, if I by accident have to contradictory settings
+for the same share?</quote> The answer is: the last one encountered by
+Samba wins. The "winner" is shown by testparm. Testparm doesn't
+complain about different settings of the same parameter for the same
+share! You can test this by setting up multiple lines for the "guest
+account" parameter with different usernames, and then run testparm to
+see which one is actually used by Samba.)
+</para></listitem></varlistentry>
+
+<varlistentry><term><parameter>read only = yes</parameter></term>
+<listitem><para>this normally (for other types of shares) prevents
+users creating or modifying files in the service's directory. However,
+in a "printable" service, it is <emphasis>always</emphasis> allowed to
+write to the directory (if user privileges allow the connection), but
+only via print spooling operations. "Normal" write operations are not
+allowed.  </para></listitem></varlistentry>
+
+<varlistentry><term><parameter>writeable = no</parameter></term>
+<listitem><para>
+synonym for <parameter>read only = yes</parameter>
+</para></listitem></varlistentry>
+</variablelist>
+</sect2>
+
+<sect2>
+<title>Any [my_printer_name] Section</title>
+
 <para>
-If you require that multiple ports be defined for some reason,
-<filename>smb.conf</filename> possesses a <ulink 
-url="smb.conf.5.html#ENUMPORTSCOMMAND"><parameter>enumports 
-command</parameter></ulink> which can be used to define an external program 
-that generates a listing of ports on a system.
+If a section appears in the , which is
+tagged as <parameter>printable = yes</parameter>, Samba presents it as
+a printer share to its clients. Note, that Win95/98/ME clients may
+have problems with connecting or loading printer drivers if the share
+name has more than 8 characters! Also be very careful if you give a
+printer the same name as an existing user or file share name: upon a
+client's connection request to a certain sharename, Samba always tries
+to find file shares with that name first; if it finds one, it will
+connect to this and will never ultimately connect to a printer with
+the same name!
 </para>
 
+<variablelist>
+<varlistentry><term><parameter>comment = Printer with Restricted Access</parameter></term>
+<listitem><para> the comment says it all.
+</para></listitem></varlistentry>
+
+<varlistentry><term><parameter>path = /var/spool/samba_my_printer</parameter></term>
+<listitem><para> here we set the spooling area for this printer to
+another directory than the default. It is not a requirement to set it
+differently, but the option is available.
+</para></listitem></varlistentry>
+
+<varlistentry><term><parameter>printer admin = kurt</parameter></term>
+<listitem><para> the printer admin definition is different for this
+explicitly defined printer share from the general
+<parameter>[printers]</parameter> share. It is not a requirement; we
+did it to show that it is possible if you want it.
+</para></listitem></varlistentry>
+
+<varlistentry><term><parameter>browseable = yes</parameter></term>
+<listitem><para> we also made this printer browseable (so that the
+clients may conveniently find it when browsing the <guiicon>Network
+Neighbourhood</guiicon>).
+</para></listitem></varlistentry>
+
+<varlistentry><term><parameter>printable = yes</parameter></term>
+<listitem><para>see explanation in last subsection.
+</para></listitem></varlistentry>
+
+<varlistentry><term><parameter>writeable = no</parameter></term>
+<listitem><para>see explanation in last subsection.
+</para></listitem></varlistentry>
+
+<varlistentry><term><parameter>hosts allow = 10.160.50.,10.160.51.</parameter></term>
+<listitem><para>here we exercise a certain degree of access control
+by using the <parameter>hosts allow</parameter> and <parameter>hosts deny</parameter> parameters. Note, that
+this is not by any means a safe bet. It is not a way to secure your
+printers. This line accepts all clients from a certain subnet in a
+first evaluation of access control
+</para></listitem></varlistentry>
+
+<varlistentry><term><parameter>hosts deny = turbo_xp,10.160.50.23,10.160.51.60
+</parameter></term>
+<listitem><para>all listed hosts are not allowed here (even if they
+belong to the "allowed subnets"). As you can see, you could name IP
+addresses as well as NetBIOS hostnames
+here.
+</para></listitem></varlistentry>
+
+<varlistentry><term><parameter>guest ok = no</parameter></term>
+<listitem><para>this printer is not open for the guest account!
+</para></listitem></varlistentry>
+
+</variablelist>
 </sect2>
 
-</sect1>
+<sect2>
+<title>Print Commands</title>
 
+<para>
+In each section defining a printer (or in the
+<parameter>[printers]</parameter> section), a <parameter>print
+command</parameter> parameter may be defined. It sets a command to
+process the files which have been placed into the Samba print spool
+directory for that printer. (That spool directory was, if you
+remember, set up with the <parameter>path</parameter>
+parameter). Typically, this command will submit the spool file to the
+Samba host's print subsystem, using the suitable system print
+command. But there is no requirement that this needs to be the
+case. For debugging purposes or some other reason you may want to do
+something completely different than "print" the file. An example is a
+command that just copies the print file to a temporary location for
+further investigation when you need to debug printing. If you craft
+your own print commands (or even develop print command shell scripts),
+make sure you pay attention to the need to remove the files from the
+Samba spool directory. Otherwise your hard disk may soon suffer from
+shortage of free space.
+</para>
+</sect2>
 
-<sect1>
-	<title>The Imprints Toolset</title>
-	
-	<para>The Imprints tool set provides a UNIX equivalent of the 
-	Windows NT Add Printer Wizard.  For complete information, please 
-	refer to the Imprints web site at <ulink url="http://imprints.sourceforge.net/">
-	http://imprints.sourceforge.net/</ulink> as well as the documentation 
-	included with the imprints source distribution.  This section will 
-	only provide a brief introduction to the features of Imprints.</para>
-	
-	
-	<sect2>
-		<title>What is Imprints?</title>
-
-		<para>Imprints is a collection of tools for supporting the goals 
-		of</para>
-		
-		<itemizedlist>
-			<listitem><para>Providing a central repository information 
-			regarding Windows NT and 95/98 printer driver packages</para>
-			</listitem>
-			
-			<listitem><para>Providing the tools necessary for creating 
-			the Imprints printer driver packages.</para></listitem>
-			
-			<listitem><para>Providing an installation client which 
-			will obtain and install printer drivers on remote Samba 
-			and Windows NT 4 print servers.</para></listitem>
-		</itemizedlist>
-		
-	</sect2>
-	
-	
-	<sect2>
-		<title>Creating Printer Driver Packages</title>
-		
-		<para>The process of creating printer driver packages is beyond
-		the scope of this document (refer to Imprints.txt also included
-		with the Samba distribution for more information).  In short,
-		an Imprints driver package is a gzipped tarball containing the
-		driver files, related INF files, and a control file needed by the
-		installation client.</para>
-	</sect2>
-	
-	
-	<sect2>
-		<title>The Imprints server</title>
-		
-		<para>The Imprints server is really a database server that 
-		may be queried via standard HTTP mechanisms.  Each printer 
-		entry in the database has an associated URL for the actual
-		downloading of the package.  Each package is digitally signed
-		via GnuPG which can be used to verify that package downloaded
-		is actually the one referred in the Imprints database.  It is 
-		<emphasis>not</emphasis> recommended that this security check 
-		be disabled.</para>
-	</sect2>
-	
-	<sect2>
-		<title>The Installation Client</title>
-
-		<para>More information regarding the Imprints installation client 
-		is available in the <filename>Imprints-Client-HOWTO.ps</filename> 
-		file included with the imprints source package.</para>
-
-		<para>The Imprints installation client comes in two forms.</para>
-
-		<itemizedlist>
-			<listitem><para>a set of command line Perl scripts</para>
-			</listitem>
-			
-			<listitem><para>a GTK+ based graphical interface to 
-			the command line perl scripts</para></listitem>
-		</itemizedlist>
-		
-		<para>The installation client (in both forms) provides a means
-		of querying the Imprints database server for a matching
-		list of known printer model names as well as a means to 
-		download and install the drivers on remote Samba and Windows
-		NT print servers.</para>
-
-		<para>The basic installation process is in four steps and 
-		perl code is wrapped around <command>smbclient</command> 
-		and <command>rpcclient</command>.</para>
-
-<para><programlisting>	
-foreach (supported architecture for a given driver)
-{
-     1.  rpcclient: Get the appropriate upload directory 
-         on the remote server
-     2.  smbclient: Upload the driver files
-     3.  rpcclient: Issues an AddPrinterDriver() MS-RPC
-}
-	
-4.  rpcclient: Issue an AddPrinterEx() MS-RPC to actually
-    create the printer
-</programlisting></para>
-		
-		<para>One of the problems encountered when implementing 
-		the Imprints tool set was the name space issues between 
-		various supported client architectures.  For example, Windows 
-		NT includes a driver named "Apple LaserWriter II NTX v51.8" 
-		and Windows 95 calls its version of this driver "Apple 
-		LaserWriter II NTX"</para>
-		
-		<para>The problem is how to know what client drivers have 
-		been uploaded for a printer.  As astute reader will remember 
-		that the Windows NT Printer Properties dialog only includes 
-		space for one printer driver name.  A quick look in the 
-		Windows NT 4.0 system registry at</para>
-	
-		<para><filename>HKLM\System\CurrentControlSet\Control\Print\Environment
-		</filename></para>
-		
-		<para>will reveal that Windows NT always uses the NT driver 
-		name.  This is ok as Windows NT always requires that at least 
-		the Windows NT version of the printer driver is present.  
-		However, Samba does not have the requirement internally.  
-		Therefore, how can you use the NT driver name if is has not 
-		already been installed?</para>
-		
-		<para>The way of sidestepping this limitation is to require 
-		that all Imprints printer driver packages include both the Intel 
-		Windows NT and 95/98 printer drivers and that NT driver is 
-		installed first.</para>
-	</sect2>
-	
-</sect1>
+<sect2>
+<title>Default Print Commands for various Unix Print Subsystems</title>
+
+<para>
+You learned earlier on, that Samba in most cases uses its built-in
+settings for many parameters if it can not find an explicitly stated
+one in its configuration file. The same is true for the
+<parameter>print command</parameter>. The default print command varies
+depending on the <parameter>printing =...</parameter> parameter
+setting. In the commands listed below, you will notice some parameters
+of the form <emphasis>%X</emphasis> where <emphasis>X</emphasis> is
+<emphasis>p, s, J</emphasis> etc. These letters stand for
+"printername", "spoolfile" and "job ID" respectively.  They are
+explained in more detail further below. Here is an overview (excluding
+the special case of CUPS, which is discussed in the next chapter):
+</para>
 
-<!--
-
-  This comment from rpc_server/srv_spoolss_nt.c:_spoolss_open_printer_ex()
-  needs to be added into a section probably.  This is to remind me it needs 
-  to be done.  -jerry
-
-                /*
-                 * If the openprinterex rpc call contains a devmode,
-                 * it's a per-user one. This per-user devmode is derivated
-                 * from the global devmode. Openprinterex() contains a per-user
-                 * devmode for when you do EMF printing and spooling.
-                 * In the EMF case, the NT workstation is only doing half the job
-                 * of rendering the page. The other half is done by running the printer
-                 * driver on the server.
-                 * The EMF file doesn't contain the page description (paper size, orientation, ...).
-                 * The EMF file only contains what is to be printed on the page.
-                 * So in order for the server to know how to print, the NT client sends
-                 * a devicemode attached to the openprinterex call.
-                 * But this devicemode is short lived, it's only valid for the current print job.
-                 *
-                 * If Samba would have supported EMF spooling, this devicemode would
-                 * have been attached to the handle, to sent it to the driver to correctly
-                 * rasterize the EMF file.
-                 *
-                 * As Samba only supports RAW spooling, we only receive a ready-to-print file,
-                 * we just act as a pass-thru between windows and the printer.
-                 *
-                 * In order to know that Samba supports only RAW spooling, NT has to call
-                 * getprinter() at level 2 (attribute field) or NT has to call startdoc()
-                 * and until NT sends a RAW job, we refuse it.
-                 *
-                 * But to call getprinter() or startdoc(), you first need a valid handle,
-                 * and to get an handle you have to call openprintex(). Hence why you have
-                 * a devicemode in the openprinterex() call.
-                 *
-                 *
-                 * Differences between NT4 and NT 2000.
-                 * NT4:
-                 * 
-                 * On NT4, you only have a global devicemode. This global devicemode can be changed
-                 * by the administrator (or by a user with enough privs). Every time a user
-                 * wants to print, the devicemode is reset to the default. In Word, every time
-                 * you print, the printer's characteristics are always reset to the global devicemode.
-                 *
-                 * NT 2000:
-                 * 
-                 * In W2K, there is the notion of per-user devicemode. The first time you use
-                 * a printer, a per-user devicemode is build from the global devicemode.
-                 * If you change your per-user devicemode, it is saved in the registry, under the
-                 * H_KEY_CURRENT_KEY sub_tree. So that every time you print, you have your default
-                 * printer preferences available.
-                 *
-                 * To change the per-user devicemode: it's the "Printing Preferences ..." button
-                 * on the General Tab of the printer properties windows.
-                 *
-                 * To change the global devicemode: it's the "Printing Defaults..." button
-                 * on the Advanced Tab of the printer properties window.
--->
+<informaltable frame='all'>
+<tgroup cols='2' align='left' colsep='1' rowsep='1'>
+<thead>
+<row>
+<entry>If this setting is active...</entry>
+<entry>...this is used in lieu of an explicit command:</entry>
+</row>
+</thead>
+<tbody>
+<row>
+<entry><parameter>printing = bsd|aix|lprng|plp</parameter></entry>
+<entry>print command is <command>lpr -r -P%p %s</command></entry>
+</row>
+<row>
+<entry><parameter>printing = sysv|hpux</parameter></entry>
+<entry>print command is <command>lp -c -P%p %s; rm %s</command></entry>
+</row>
+<row>
+<entry> <parameter>printing = qnx</parameter></entry>
+<entry>print command is <command>lp -r -P%p -s %s</command></entry>
+</row>
+<row>
+<entry><parameter>printing = bsd|aix|lprng|plp</parameter></entry>
+<entry>lpq command is <command>lpq -P%p</command></entry>
+</row>
+<row>
+<entry><parameter>printing = sysv|hpux</parameter></entry>
+<entry>lpq command is <command>lpstat -o%p</command></entry>
+</row>
+<row>
+<entry><parameter>printing = qnx</parameter></entry>
+<entry>lpq command is <command>lpq -P%p</command></entry>
+</row>
+<row>
+<entry><parameter>printing = bsd|aix|lprng|plp</parameter></entry>
+<entry>lprm command is <command>lprm -P%p %j</command></entry>
+</row>
+<row>
+<entry><parameter>printing = sysv|hpux</parameter></entry>
+<entry>lprm command is <command>cancel %p-%j</command></entry>
+</row>
+<row>
+<entry><parameter>printing = qnx</parameter></entry>
+<entry>lprm command is <command>cancel %p-%j</command></entry>
+</row>
+<row>
+<entry><parameter>printing = bsd|aix|lprng|plp</parameter></entry>
+<entry>lppause command is <command>lp -i %p-%j -H hold</command></entry>
+</row>
+<row>
+<entry><parameter>printing = sysv|hpux</parameter></entry>
+<entry>lppause command   (...is empty)</entry>
+</row>
+<row>
+<entry><parameter>printing = qnx</parameter></entry>
+<entry>lppause command   (...is empty)</entry>
+</row>
+<row>
+<entry><parameter>printing = bsd|aix|lprng|plp</parameter></entry>
+<entry>lpresume command is <command>lp -i %p-%j -H resume</command></entry>
+</row>
+<row>
+<entry><parameter>printing = sysv|hpux</parameter></entry>
+<entry>lpresume command   (...is empty)</entry>
+</row>
+<row>
+<entry><parameter>printing = qnx</parameter></entry>
+<entry>lpresume command   (...is empty)</entry>
+</row>
+</tbody>
+</tgroup>
+</informaltable>
 
-<sect1>
-<title>Diagnosis</title>
+<para>
+We excluded the special CUPS case here, because it is discussed in the
+next chapter. Just a short summary. For <parameter>printing =
+CUPS</parameter>: If SAMBA is compiled against libcups, it uses the
+CUPS API to submit jobs, etc. (It is a good idea also to set
+<parameter>printcap = cups</parameter> in case your
+<filename>cupsd.conf</filename> is set to write its autogenerated
+printcap file to an unusual place). Otherwise Samba maps to the System
+V printing commands with the -oraw option for printing, i.e. it uses
+<command>lp -c -d%p -oraw; rm %s</command> With <parameter>printing =
+cups</parameter> , and if SAMBA is compiled against libcups, any
+manually set print command will be ignored!
+</para>
+
+<!-- FIXME: This information is for 2.2 -->
+<para>
+Having listed the above mappings here, you should note that there used
+to be a <emphasis>bug</emphasis> in recent 2.2.x versions which
+prevented the mapping from taking effect. It lead to the
+"bsd|aix|lprng|plp" settings taking effect for all other systems, for
+the most important commands (the <command>print</command> command, the
+<command>lpq</command> command and the <command>lprm</command>
+command). The <command>lppause</command> command and the
+<command>lpresume</command> command remained empty. Of course, these
+commands worked on bsd|aix|lprng|plp but they didn't work on
+sysv|hpux|qnx systems. To work around this bug, you need to
+explicitly set the commands. Use <command>testparm -v</command> to
+check which command takes effect. Then check that this command is
+adequate and actually works for your installed print subsystem. It is
+always a good idea to explicitly set up your configuration files the
+way you want them to work and not rely on any built-in defaults.
+</para>
+</sect2>
 
 <sect2>
-<title>Introduction</title>
+<title>Setting up your own Print Commands</title>
 
 <para>
-This is a short description of how to debug printing problems with
-Samba. This describes how to debug problems with printing from a SMB
-client to a Samba server, not the other way around. For the reverse
-see the examples/printing directory.
+After a print job has finished spooling to a service, the
+<parameter>print command</parameter> will be used by Samba via a
+<emphasis>system()</emphasis> call to process the spool file.  Usually
+the command specified will submit the spool file to the host's
+printing subsystem. But there is no requirement at all that this must
+be the case. The print subsystem will probably not remove the spool
+file on its own. So whatever command you specify on your own you
+should ensure that the spool file is deleted after it has been
+processed.
 </para>
 
 <para>
-Ok, so you want to print to a Samba server from your PC. The first
-thing you need to understand is that Samba does not actually do any
-printing itself, it just acts as a middleman between your PC client
-and your Unix printing subsystem. Samba receives the file from the PC
-then passes the file to a external "print command". What print command
-you use is up to you.
+There is no difficulty with using your own customized print commands
+with the traditional printing systems. However, if you don't wish to
+"roll your own", you should be well informed about the default
+built-in commands that Samba uses for each printing subsystem (see the
+table above).  In all the commands listed in the last paragraphs you
+see parameters of the form <emphasis>%X</emphasis> These are
+<emphasis>macros</emphasis>, or shortcuts, used as place holders for
+the names of real objects. At the time of running a command with such
+a placeholder, Samba will insert the appropriate value
+automatically. Print commands can handle all Samba macro
+substitutions. In regard to printing, the following ones do have
+special relevance:
 </para>
 
+<itemizedlist>
+<listitem><para><parameter>%s, %f</parameter> - the path to the spool
+file name</para></listitem>
+
+<listitem><para><parameter>%p</parameter> - the appropriate printer
+name</para></listitem>
+
+<listitem><para><parameter>%J</parameter> - the job name as
+transmitted by the client.</para></listitem>
+
+<listitem><para><parameter>%c</parameter> - the number of printed
+pages of the spooled job (if known).</para></listitem>
+
+<listitem><para><parameter>%z</parameter> - the size of the spooled
+print job (in bytes)</para></listitem>
+
+</itemizedlist>
+
 <para>
-The whole things is controlled using options in smb.conf. The most
-relevant options (which you should look up in the smb.conf man page)
-are:
+The print command MUST contain at least one occurrence of
+<parameter>%s</parameter> or <parameter>%f</parameter>. -- The
+<parameter>%p</parameter> is optional. If no printer name is supplied,
+the <parameter>%p</parameter> will be silently removed from the print
+command. In this case the job is sent to the default printer.
 </para>
 
-<para><programlisting>
-      [global]
-        print command     - send a file to a spooler
-        lpq command       - get spool queue status
-        lprm command      - remove a job
-      [printers]
-        path = /var/spool/lpd/samba
-</programlisting></para>
+<para>
+If specified in the <parameter>[global]</parameter> section, the print
+command given will be used for any printable service that does not
+have its own print command specified. If there is neither a specified
+print command for a printable service nor a global print command,
+spool files will be created but not processed! And (most importantly):
+print files will not be removed, so they will start filling your Samba
+hard disk.
+</para>
 
 <para>
-The following are nice to know about:
+Note that printing may fail on some UNIXes from the "nobody"
+account. If this happens, create an alternative guest account and
+supply it with the privilege to print. Set up this guest account in
+the <parameter>[global]</parameter> section with the <parameter>guest
+account</parameter> parameter.
+</para>
+
+<para>
+You can form quite complex print commands. You need to realize that
+print commands are just passed to a UNIX shell. The shell is able to
+expand the included environment variables as usual. (The syntax to
+include a UNIX environment variable <parameter>$variable</parameter>
+in  or in the Samba print command is
+<parameter>%$variable</parameter>.) To give you a working
+<parameter>print command</parameter> example, the following will log a
+print job to <filename>/tmp/print.log</filename>, print the file, then
+remove it. Note that ';' is the usual separator for commands in shell
+scripts:
 </para>
 
 <para><programlisting>
-        queuepause command   - stop a printer or print queue
-        queueresume command  - start a printer or print queue
+<![CDATA[
+ print command = echo Printing %s >> /tmp/print.log; lpr -P %p %s; rm %s
+]]>
 </programlisting></para>
 
 <para>
-Example:
+You may have to vary your own command considerably from this example
+depending on how you normally print files on your system.  The default
+for the <parameter>print command</parameter> parameter varies depending on the setting of
+the <parameter>printing</parameter> parameter. Another example is:
 </para>
 
 <para><programlisting>
-        print command = /usr/bin/lpr -r -P%p %s
-        lpq command   = /usr/bin/lpq    -P%p %s
-        lprm command  = /usr/bin/lprm   -P%p %j
-        queuepause command = /usr/sbin/lpc -P%p stop
-        queuepause command = /usr/sbin/lpc -P%p start
+ print command = /usr/local/samba/bin/myprintscript %p %s
 </programlisting></para>
+</sect2>
+</sect1>
+
+<sect1>
+<title>Innovations in Samba Printing since 2.2</title>
 
 <para>
-Samba should set reasonable defaults for these depending on your
-system type, but it isn't clairvoyant. It is not uncommon that you
-have to tweak these for local conditions.  The commands should
-always have fully specified pathnames,  as the smdb may not have
-the correct PATH values.
+Before version 2.2.0, Samba's print server support for Windows clients
+was limited to the level of <emphasis>LanMan</emphasis> printing
+calls. This is the same protocol level as Windows 9x PCs offer when
+they share printers.  Beginning with the 2.2.0 release, Samba started
+to support the native Windows NT printing mechanisms. These are
+implemented via <emphasis>MS-RPC</emphasis> (RPC = <emphasis>Remote
+Procedure Calls</emphasis> ). MS-RPCs use the
+<emphasis>SPOOLSS</emphasis> named pipe for all printing.
 </para>
 
 <para>
-When you send a job to Samba to be printed,  it will make a temporary
-copy of it in the directory specified in the [printers] section.
-and it should be periodically cleaned out.  The lpr -r option
-requests that the temporary copy be removed after printing; If
-printing fails then you might find leftover files in this directory,
-and it should be periodically cleaned out.  Samba used the lpq
-command to determine the "job number" assigned to your print job
-by the spooler.
+The additional functionality provided by the new SPOOLSS support includes:
 </para>
 
+<itemizedlist>
+<listitem><para>Support for downloading printer driver files to Windows
+95/98/NT/2000 clients upon demand (<emphasis>Point'n'Print</emphasis>);
+</para></listitem>
+
+<listitem><para>Uploading of printer drivers via the Windows NT
+<emphasis>Add Printer Wizard</emphasis> (APW) or the
+<emphasis>Imprints</emphasis> tool set (refer to <ulink
+url="http://imprints.sourceforge.net/">http://imprints.sourceforge.net</ulink>);
+</para></listitem>
+
+<listitem><para>Support for the native MS-RPC printing calls such as
+StartDocPrinter, EnumJobs(), etc... (See the MSDN documentation
+at <ulink
+url="http://msdn.microsoft.com/">http://msdn.microsoft.com/</ulink>
+for more information on the Win32 printing API);</para></listitem>
+
+<listitem><para>Support for NT <emphasis>Access Control
+Lists</emphasis> (ACL) on printer objects;</para></listitem>
+
+<listitem><para>Improved support for printer queue manipulation
+through the use of internal databases for spooled job information
+(implemented by various <filename>*.tdb</filename>
+files).</para></listitem>
+
+</itemizedlist>
+
+<para>
+One other benefit of an update is this: Samba-3 is able to publish
+all its printers in Active Directory (or LDAP)!
+</para>
+
+<para>
+One slight difference is here: it is possible on a Windows NT print
+server to have printers listed in the Printers folder which are
+<emphasis>not</emphasis> shared. Samba does not make this
+distinction. By definition, the only printers of which Samba is aware
+are those which are specified as shares in
+. The reason is that Windows NT/200x/XP Professional
+clients do not normally need to use the standard SMB printer share;
+rather they can print directly to any printer on another Windows NT
+host using MS-RPC. This of course assumes that the printing client has
+the necessary privileges on the remote host serving the printer. The
+default permissions assigned by Windows NT to a printer gives the
+"Print" permissions to the well-known <emphasis>Everyone</emphasis>
+group. (The older clients of type Win9x can only print to "shared"
+printers).
+</para>
+
+<sect2>
+<title>Client Drivers on Samba Server for <emphasis>Point'n'Print</emphasis></title>
+
+<para>
+There is still confusion about what all this means: <emphasis>Is it or
+is it not a requirement for printer drivers to be installed on a Samba
+host in order to support printing from Windows clients?</emphasis> The
+answer to this is: No, it is not a
+<emphasis>requirement</emphasis>. Windows NT/2000 clients can, of
+course, also run their APW to install drivers
+<emphasis>locally</emphasis> (which then connect to a Samba served
+print queue). This is the same method as used by Windows 9x
+clients. (However, a <emphasis>bug</emphasis> existed in Samba 2.2.0
+which made Windows NT/2000 clients require that the Samba server
+possess a valid driver for the printer. This was fixed in Samba
+2.2.1).
+</para>
+
+<para>
+But it is a new <emphasis>option</emphasis> to install the printer
+drivers into the <parameter>[print$]</parameter> share of the Samba
+server, and a big convenience too. Then <emphasis>all</emphasis>
+clients (including 95/98/ME) get the driver installed when they first
+connect to this printer share. The <emphasis>uploading</emphasis> or
+<emphasis>depositing</emphasis> of the driver into this
+<parameter>[print$]</parameter> share, and the following binding of
+this driver to an existing Samba printer share can be achieved by
+different means:
+</para>
+
+<itemizedlist>
+<listitem><para>running the <emphasis>APW</emphasis> on an
+NT/200x/XP Professional client (this doesn't work from 95/98/ME
+clients);</para></listitem>
+
+<listitem><para>using the <emphasis>Imprints</emphasis>
+toolset;</para></listitem>
+
+<listitem><para>using the <emphasis>smbclient</emphasis> and
+<emphasis>rpcclient</emphasis> commandline tools;</para></listitem>
+
+<listitem><para>using <emphasis>cupsaddsmb</emphasis>(only works for
+the CUPS printing system, not for LPR/LPD, LPRng
+etc.).</para></listitem>
+
+</itemizedlist>
+
 <para>
-The %&gt;letter&lt; are "macros" that get dynamically replaced with appropriate
-values when they are used. The %s gets replaced with the name of the spool
-file that Samba creates and the %p gets replaced with the name of the
-printer. The %j gets replaced with the "job number" which comes from
-the lpq output.
+Please take additional note of the following fact: <emphasis>Samba
+does not use these uploaded drivers in any way to process spooled
+files</emphasis>. Drivers are utilized entirely by the clients, who
+download and install them via the "Point'n'Print" mechanism supported
+by Samba. The clients use these drivers to generate print files in the
+format the printer (or the Unix print system) requires. Print files
+received by Samba are handed over to the Unix printing system, which
+is responsible for all further processing, if needed.
 </para>
+</sect2>
+
+<sect2>
+<title>The [printer$] Section is removed from Samba-3</title>
+
+<formalpara><title>
+<parameter>[print$]</parameter> vs. <parameter>[printer$]</parameter>
+</title>
 
+<para>
+Versions of Samba prior to 2.2 made it possible to use a share
+named <emphasis>[printer$]</emphasis>. This name was taken from the
+same named service created by Windows 9x clients when a printer was
+shared by them. Windows 9x printer servers always have a
+<parameter>[printer$]</parameter> service which provides read-only
+access (with no password required) in order to support printer driver
+downloads.  However, Samba's initial implementation allowed for a
+parameter named <parameter>printer driver location</parameter> to be
+used on a per share basis.  This specified the location of the driver
+files associated with that printer. Another parameter named
+<parameter>printer driver</parameter> provided a means of defining the
+printer driver name to be sent to the client.  These parameters,
+including the <parameter>printer driver file</parameter> parameter,
+are now removed and can not be used in installations of Samba-3.0.
+Now the share name <parameter>[print$]</parameter> is used for the
+location of downloadable printer drivers. It is taken from the
+<parameter>[print$]</parameter> service created by Windows NT PCs when
+a printer is shared by them. Windows NT print servers always have a
+<parameter>[print$]</parameter> service which provides read-write
+access (in the context of its ACLs) in order to support printer driver
+down- and uploads.  Don't fear -- this does not mean Windows 9x
+clients are thrown aside now. They can use Samba's
+<parameter>[print$]</parameter> share support just fine.
+</para></formalpara>
 </sect2>
 
 <sect2>
-<title>Debugging printer problems</title>
+<title>Creating the [print$] Share</title>
 
 <para>
-One way to debug printing problems is to start by replacing these
-command with shell scripts that record the arguments and the contents
-of the print file. A simple example of this kind of things might
-be:
+In order to support the up- and downloading of printer driver files,
+you must first configure a file share named
+<parameter>[print$]</parameter>. The "public" name of this share is
+hard coded in Samba's internals (because it is hard coded in the MS
+Windows clients too). It cannot be renamed since Windows clients are
+programmed to search for a service of exactly this name if they want
+to retrieve printer driver files.
 </para>
 
-<para><programlisting>
-	print command = /tmp/saveprint %p %s
-
-    #!/bin/saveprint
-    # we make sure that we are the right user
-    /usr/bin/id -p >/tmp/tmp.print
-    # we run the command and save the error messages
-    # replace the command with the one appropriate for your system
-    /usr/bin/lpr -r -P$1 $2 2>>&amp;/tmp/tmp.print
-</programlisting></para>
+<para>
+You should modify the server's  file to
+add the global parameters and create the
+<parameter>[print$]</parameter> file share (of course, some of the
+parameter values, such as 'path' are arbitrary and should be replaced
+with appropriate values for your site):
+</para>
+
+<para><screen>
+ [global]
+      ; members of the ntadmin group should be able to add drivers and set
+      ; printer properties. root is implicitly always a 'printer admin'.
+      printer admin = @ntadmin
+      [....]
+
+ [printers]
+      [....]
+
+ [print$]
+      comment = Printer Driver Download Area
+      path = /etc/samba/drivers
+      browseable = yes
+      guest ok = yes
+      read only = yes
+      write list = @ntadmin, root
+</screen></para>
 
 <para>
-Then you print a file and try removing it.  You may find that the
-print queue needs to be stopped in order to see the queue status
-and remove the job:
+Of course, you also need to ensure that the directory named by the
+<parameter>path</parameter> parameter exists on the Unix file system.
 </para>
 
-<para><programlisting>
+</sect2>
 
-h4: {42} % echo hi >/tmp/hi
-h4: {43} % smbclient //localhost/lw4
-added interface ip=10.0.0.4 bcast=10.0.0.255 nmask=255.255.255.0
-Password: 
-Domain=[ASTART] OS=[Unix] Server=[Samba 2.0.7]
-smb: \> print /tmp/hi
-putting file /tmp/hi as hi-17534 (0.0 kb/s) (average 0.0 kb/s)
-smb: \> queue
-1049     3            hi-17534
-smb: \> cancel 1049
-Error cancelling job 1049 : code 0
-smb: \> cancel 1049
-Job 1049 cancelled
-smb: \> queue
-smb: \> exit
-</programlisting></para>
+<sect2>
+<title>Parameters in the [print$] Section</title>
 
 <para>
-The 'code 0' indicates that the job was removed.  The comment
-by the  smbclient is a bit misleading on this.
-You can observe the command output and then and look at the
-/tmp/tmp.print file to see what the results are.  You can quickly
-find out if the problem is with your printing system.  Often people
-have problems with their /etc/printcap file or permissions on
-various print queues.
+<parameter>[print$]</parameter> is a special section in
+. It contains settings relevant to
+potential printer driver download and local installation by clients.
 </para>
+
+<variablelist>
+<varlistentry><term><parameter>comment = Printer Driver
+Download Area</parameter></term>
+<listitem><para> the comment appears next to the share name if it is
+listed in a share list (usually Windows clients won't see it often but
+it will also appear up in a <command>smbclient -L sambaserver
+</command> output). </para></listitem></varlistentry>
+
+<varlistentry><term><parameter>path = /etc/samba/printers</parameter></term>
+<listitem><para> this is the path to the location of the Windows
+driver file deposit from the UNIX point of
+view.</para></listitem></varlistentry>
+
+<varlistentry><term><parameter>browseable = no</parameter></term>
+<listitem><para> this makes the <parameter>[print$]</parameter> share
+"invisible" in Network Neighbourhood to clients. However, you can
+still "mount" it from any client using the <command>net use
+g:\\sambaserver\print$</command> command in a "DOS box" or the
+"Connect network drive" menu from Windows
+Explorer.</para></listitem></varlistentry>
+
+<varlistentry><term><parameter>guest ok = yes</parameter></term>
+<listitem><para>this gives read only access to this share for all
+guest users. Access may be used to download and install printer
+drivers on clients. The requirement for <parameter>guest ok =
+yes</parameter> depends upon how your site is configured. If users
+will be guaranteed to have an account on the Samba host, then this is
+a non-issue.</para>
+
+<note><para> 
+The non-issue is this: if all your Windows NT users are guaranteed to
+be authenticated by the Samba server (for example if Samba
+authenticates via an NT domain server and the NT user has already been
+validated by the Domain Controller in order to logon to the Windows NT
+session), then guest access is not necessary. Of course, in a
+workgroup environment where you just want to be able to print without
+worrying about silly accounts and security, then configure the share
+for guest access. You'll probably want to add <parameter>map to guest
+= Bad User</parameter> in the <parameter>[global]</parameter> section
+as well. Make sure you understand what this parameter does before
+using it.
+</para></note> </listitem></varlistentry>
+
+<varlistentry><term><parameter>read only = yes</parameter></term>
+<listitem><para>as we don't want everybody to upload driver files (or
+even change driver settings) we tagged this share as not
+writeable.</para></listitem></varlistentry>
+
+<varlistentry><term><parameter>write list = @ntadmin,root</parameter></term>
+<listitem><para>since the <parameter>[print$]</parameter> was made
+read only by the previous setting, we need to create a "write list"
+also. UNIX groups (denoted with a leading "@" character) and users
+listed here are allowed write access (as an exception to the general
+public's "read-only" access), which they need to update files on the
+share.  Normally you will want to only name administrative level user
+accounts in this setting. Check the file system permissions to make
+sure these accounts can copy files to the share. If this is a non-root
+account, then the account should also be mentioned in the global
+<parameter>printer admin </parameter> parameter.  See the
+ man page for more information on
+configuring file shares.  </para></listitem></varlistentry>
+
+</variablelist>
+
 </sect2>
 
 <sect2>
-<title>What printers do I have?</title>
+<title>Subdirectory Structure in [print$]</title>
 
 <para>
-You can use the 'testprns' program to check to see if the printer
-name you are using is recognized by Samba.  For example,  you can
-use:
+In order for a Windows NT print server to support the downloading of
+driver files by multiple client architectures, you must create several
+subdirectories within the <parameter>[print$]</parameter> service
+(i.e. the Unix directory named by the <parameter>path</parameter>
+parameter). These correspond to each of the supported client
+architectures. Samba follows this model as well. Just like the name of
+the <parameter>[print$]</parameter> share itself, the subdirectories
+*must* be exactly the names listed below (you may leave out the
+subdirectories of architectures you don't want to support).
 </para>
 
+<para>
+Therefore, create a directory tree below the
+<parameter>[print$]</parameter> share for each architecture you wish
+to support.
+</para>
+
+<!-- FIXME: diagram-->
 <para><programlisting>
-    testprns printer /etc/printcap
+[print$]--+--
+          |--W32X86           # serves drivers to "Windows NT x86"
+          |--WIN40            # serves drivers to "Windows 95/98"
+          |--W32ALPHA         # serves drivers to "Windows NT Alpha_AXP"
+          |--W32MIPS          # serves drivers to "Windows NT R4000"
+          |--W32PPC           # serves drivers to "Windows NT PowerPC"
 </programlisting></para>
 
+<important><title>Required permissions</title>
+
 <para>
-Samba can get its printcap information from a file or from a program.
-You can try the following to see the format of the extracted
-information:
+In order to add a new driver to your Samba host, one of two conditions
+must hold true:
 </para>
 
-<para><programlisting>
-    testprns -a printer /etc/printcap
+<itemizedlist>
+<listitem><para>The account used to connect to the Samba host must
+have a UID of 0 (i.e. a root account)</para></listitem>
 
-    testprns -a printer '|/bin/cat printcap'
-</programlisting></para>
+<listitem><para>The account used to connect to the Samba host must be
+named in the <emphasis>printer admin</emphasis>list.</para></listitem>
+
+</itemizedlist>
+
+<para>
+Of course, the connected account must still possess access to add
+files to the subdirectories beneath
+<parameter>[print$]</parameter>. Remember that all file shares are set
+to 'read only' by default.
+</para>
+</important>
 
+<para>
+Once you have created the required <parameter>[print$]</parameter>
+service and associated subdirectories, go to a Windows NT 4.0/2k/XP
+client workstation. Open <guiicon>Network Neighbourhood</guiicon> or 
+<guiicon>My Network Places</guiicon> and browse for the Samba host.
+Once you have located the server, navigate to its <guiicon>Printers and
+Faxes</guiicon> folder.  You should see an initial listing of printers
+that matches the printer shares defined on your Samba host.
+</para>
 </sect2>
+</sect1>
+
+<sect1>
+<title>Installing Drivers into [print$]</title>
+
+<para>
+You have successfully created the <parameter>[print$]</parameter>
+share in ?  And Samba has re-read its
+configuration? Good. But you are not yet ready to take off. The
+<emphasis>driver files</emphasis> need to be present in this share,
+too! So far it is still an empty share. Unfortunately, it is not enough
+to just copy the driver files over. They need to be <emphasis>set
+up</emphasis> too.  And that is a bit tricky, to say the least. We
+will now discuss two alternative ways to install the drivers into
+<parameter>[print$]</parameter>:
+</para>
+
+<itemizedlist>
+
+<listitem><para>using the Samba commandline utility
+<command>rpcclient</command> with its various subcommands (here:
+<command>adddriver</command> and <command>setdriver</command>) from
+any UNIX workstation;</para></listitem>
+
+<listitem><para>running a GUI (<emphasis>Printer
+Properties</emphasis> and <emphasis>Add Printer Wizard</emphasis>)
+from any Windows NT/2k/XP client workstation.</para></listitem>
+
+</itemizedlist>
+
+<para>
+The latter option is probably the easier one (even if the only
+entrance to this realm seems a little bit weird at first).
+</para>
 
 <sect2>
-<title>Setting up printcap and print servers</title>
+<title>Setting Drivers for existing Printers with a Client GUI</title>
 
 <para>
-You may need to set up some printcaps for your Samba system to use.
-It is strongly recommended that you use the facilities provided by
-the print spooler to set up queues and printcap information.
+The initial listing of printers in the Samba host's
+<guiicon>Printers</guiicon> folder accessed from a client's Explorer
+will have no real printer driver assigned to them. By default, in
+Samba-3 (as in 2.2.1 and later) this driver name is set to a NULL
+string. This must be changed now. The local <emphasis>Add Printer
+Wizard</emphasis>, run from NT/2000/XP clients, will help us in this
+task.
 </para>
 
 <para>
-Samba requires either a printcap or program to deliver printcap
-information.  This printcap information has the format:
+However, the job to set a valid driver for the printer is not a
+straightforward one: You must attempt to view the printer properties
+for the printer to which you want the driver assigned. Open the
+Windows Explorer, open Network Neighbourhood, browse to the Samba
+host, open Samba's <guiicon>Printers</guiicon> folder, right-click the printer icon and
+select <guimenu>Properties...</guimenu>. You are now trying to view printer and driver
+properties for a queue which has this default <constant>NULL</constant> driver
+assigned. This will result in an error message (this is normal here):
 </para>
 
-<para><programlisting>
-  name|alias1|alias2...:option=value:...
-</programlisting></para>
+<para><errorname> Device settings cannot be displayed. The driver
+for the specified printer is not installed, only spooler properties
+will be displayed. Do you want to install the driver
+now?</errorname></para>
+
+<para>
+<emphasis>Important:</emphasis>Don't click <guibutton>Yes</guibutton>!  Instead,
+<emphasis>click <guibutton>No</guibutton></emphasis> in the error dialog.
+Only now you will be presented with the printer properties window. From here,
+the way to assign a driver to a printer is open to us. You have now the choice
+either:
+</para>
+
+<itemizedlist>
+<listitem><para>select a driver from the pop-up list of installed
+drivers.  <emphasis>Initially this list will be empty.</emphasis>
+Or</para></listitem>
+
+<listitem><para>use the <guibutton>New Driver...</guibutton> button to
+install a new printer driver (which will in fact start up the
+APW).</para></listitem>
+</itemizedlist>
 
 <para>
-For almost all printing systems, the printer 'name' must be composed
-only of alphanumeric or underscore '_' characters.  Some systems also
-allow hyphens ('-') as well.  An alias is an alternative name for the
-printer,  and an alias with a space in it is used as a 'comment'
-about the printer.  The printcap format optionally uses a \ at the end of lines
-to extend the printcap to multiple lines.
+Once the APW is started, the procedure is exactly the same as the one
+you are familiar with in Windows (we assume here that you are
+familiar with the printer driver installations procedure on Windows
+NT). Make sure your connection is in fact setup as a user with
+<parameter>printer admin</parameter> privileges (if in doubt, use
+<command>smbstatus</command> to check for this). If you wish to
+install printer drivers for client operating systems other than
+<application>Windows NT x86</application>, you will need to use the
+<guilabel>Sharing</guilabel> tab of the printer properties dialog.
 </para>
 
 <para>
-Here are some examples of printcap files:
+Assuming you have connected with an administrative (or root) account
+(as named by the <parameter>printer admin</parameter> parameter),
+you will also be able to modify other printer properties such as ACLs
+and default device settings using this dialog. For the default device
+settings, please consider the advice given further below.
 </para>
+</sect2>
+
+<sect2>
+<title>Setting Drivers for existing Printers with
+<command>rpcclient</command></title>
 
 <para>
+The second way to install printer drivers into
+<parameter>[print$]</parameter> and set them up in a valid way can be
+done from the UNIX command line.  This involves four distinct steps:
+</para>
+
 <orderedlist>
-<listitem><para>
-pr              just printer name
-</para></listitem>
-<listitem><para>
-pr|alias        printer name and alias
-</para></listitem>
-<listitem><para>
-pr|My Printer   printer name, alias used as comment
-</para></listitem>
-<listitem><para>
-pr:sh:\        Same as pr:sh:cm= testing
-  :cm= \ 
-  testing
-</para></listitem>
-<listitem><para>
-pr:sh           Same as pr:sh:cm= testing
-  :cm= testing
-</para></listitem>
+<listitem><para>gathering the info about the required driver files
+and collecting the files together;</para></listitem>
+
+<listitem><para>deposit the driver files into the
+<parameter>[print$]</parameter> share's correct subdirectories
+(possibly by using <command>smbclient</command>);</para></listitem>
+
+<listitem><para>running the <command>rpcclient</command>
+commandline utility once with the <command>adddriver</command>
+subcommand,</para></listitem>
+
+<listitem><para>running <command>rpcclient</command> a second
+time with the <command>setdriver</command>
+subcommand.</para></listitem>
 </orderedlist>
+
+<para>
+We will provide detailed hints for each of these steps in the next few
+paragraphs.
 </para>
 
+<sect3>
+<title>Identifying the Driver Files</title>
+
 <para>
-Samba reads the printcap information when first started.  If you make
-changes in the printcap information, then you must do the following:
+To find out about the driver files, you have two options: you could
+investigate the driver CD which comes with your printer.  Study the
+<filename>*.inf</filename> file on the CD, if it is contained. This
+may not be the possible, since the *.inf file might be
+missing. Unfortunately, many vendors have now started to use their own
+installation programs. These installations packages are often some
+sort of Windows platform archive format, plus, the files may get
+re-named during the installation process. This makes it extremely
+difficult to identify the driver files you need.
 </para>
 
-<orderedlist>
+<para>
+Then you only have the second option: install the driver first on a
+Windows client *locally* and investigate which file names and paths it
+uses after they are installed. (Note, that you need to repeat this
+procedure for every client platform you want to support. We are going
+to show it here for the <application>W32X86</application> platform only, a
+name used by Microsoft for all WinNT/2k/XP clients...)
+</para>
 
-<listitem><para>
-make sure that the print spooler is aware of these changes.
-The LPRng system uses the 'lpc reread' command to do this.
-</para></listitem>
+<para>
+A good method to recognize the driver files this is to print the test
+page from the driver's <guilabel>Properties</guilabel> Dialog
+(<guilabel>General</guilabel> tab). Then look at the list of driver
+files named on the printout. You'll need to recognize what Windows
+(and Samba) are calling the <guilabel>Driver File</guilabel> , the
+<guilabel>Data File</guilabel>, the <guilabel>Config File</guilabel>,
+the <guilabel>Help File</guilabel> and (optionally) the
+<guilabel>Dependent Driver Files</guilabel> (this may vary slightly
+for Windows NT).  You need to remember all names (or better take a
+note) for the next steps.
+</para>
 
-<listitem><para>
-make sure that the spool queues, etc., exist and have the
-correct permissions.  The LPRng system uses the 'checkpc -f'
-command to do this.
-</para></listitem>
+<para>
+Another method to quickly test the driver filenames and related paths
+is provided by the <command>rpcclient</command> utility. Run it with
+<command>enumdrivers</command> or with the
+<command>getdriver</command> subcommand, each in the
+<emphasis>3</emphasis> level. In the following example,
+<emphasis>TURBO_XP</emphasis> is the name of the Windows PC (in this
+case it was a Windows XP Professional laptop, BTW). I had installed
+the driver locally to TURBO_XP while <emphasis>kde-bitshop</emphasis> is
+the name of the Linux host from which I am working. We could run an
+<emphasis>interactive</emphasis> <command>rpcclient</command> session;
+then we'd get an <emphasis>rpcclient /></emphasis> prompt and would
+type the subcommands at this prompt. This is left as a good exercise
+to the reader. For now we use <command>rpcclient</command> with the
+<option>-c</option> parameter to execute a single subcommand
+line and exit again. This is the method you would use if you want to
+create scripts to automate the procedure for a large number of
+printers and drivers. Note the different quotes used to overcome the
+different spaces in between words:
+</para>
 
-<listitem><para>
-You now should send a SIGHUP signal to the smbd server to have
-it reread the printcap information.
+<para><screen>
+&rootprompt;<userinput>rpcclient -U'Danka%xxxx' -c 'getdriver "Heidelberg Digimaster 9110 (PS)" 3' TURBO_XP</userinput>
+  cmd = getdriver "Heidelberg Digimaster 9110 (PS)" 3
+
+  [Windows NT x86]
+  Printer Driver Info 3:
+          Version: [2]
+          Driver Name: [Heidelberg Digimaster 9110 (PS)]
+          Architecture: [Windows NT x86]
+          Driver Path: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\HDNIS01_de.DLL]
+          Datafile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.ppd]
+          Configfile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\HDNIS01U_de.DLL]
+          Helpfile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\HDNIS01U_de.HLP]
+  
+          Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.DLL]
+          Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.INI]
+          Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1KMMin.DLL]
+          Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.dat]
+          Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.cat]
+          Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.def]
+          Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.hre]
+          Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.vnd]
+          Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de.hlp]
+          Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\Hddm91c1_de_reg.HLP]
+          Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\HDNIS01Aux.dll]
+          Dependentfiles: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\HDNIS01_de.NTF]
+  
+          Monitorname: []
+          Defaultdatatype: []
+
+</screen></para>
+
+<para>
+You may notice, that this driver has quite a big number of
+<guilabel>Dependentfiles</guilabel> (I know worse cases however). Also,
+strangely, the <guilabel>Driver File</guilabel> is here tagged as
+<guilabel>Driver Path</guilabel>.... oh, well. Here we don't have yet
+support for the so-called <application>WIN40</application> architecture
+installed. This name is used by Microsoft for the Win95/98/ME platforms.
+If we want to support these, we need to install the Win95/98/ME driver
+files in addition to those for <application>W32X86</application>
+(i.e. the WinNT72000/XP clients) onto a Windows PC. This PC
+can also host the Win9x drivers, even if itself runs on Windows NT,
+2000 or XP.
+</para>
+
+<para>
+Since the <parameter>[print$]</parameter> share is usually accessible
+through the <guiicon>Network Neighbourhood</guiicon>, you can also use the UNC notation
+from Windows Explorer to poke at it. The Win9x driver files will end
+up in subdirectory "0" of the "WIN40" directory. The full path to
+access them will be
+<filename>\\WINDOWSHOST\print$\WIN40\0\</filename>.
+</para>
+
+<note><para> more recent drivers on Windows 2000 and Windows XP are
+installed into the "3" subdirectory instead of the "2". The version 2
+of drivers, as used in Windows NT, were running in Kernel Mode.
+Windows 2000 changed this. While it still can use the Kernel Mode
+drivers (if this is enabled by the Admin), its native mode for printer
+drivers is User Mode execution. This requires drivers designed for
+this. These type of drivers install into the "3" subdirectory.
+</para></note>
+</sect3>
+
+<sect3>
+<title>Collecting the Driver Files from a Windows Host's
+[print$] Share</title>
+
+<para>
+Now we need to collect all the driver files we identified. in our
+previous step. Where do we get them from? Well, why not retrieve them
+from the very PC and the same <parameter>[print$]</parameter> share
+which we investigated in our last step to identify the files? We can
+use <command>smbclient</command> to do this. We will use the paths and
+names which were leaked to us by <command>getdriver</command>. The
+listing is edited to include linebreaks for readability:
+</para>
+
+<para><screen>
+&rootprompt;<userinput>smbclient //TURBO_XP/print\$ -U'Danka%xxxx'	\ 
+	-c 'cd W32X86/2;mget HD*_de.*             \
+	hd*ppd Hd*_de.* Hddm*dll HDN*Aux.DLL'</userinput>
+  added interface ip=10.160.51.60 bcast=10.160.51.255 nmask=255.255.252.0
+  Got a positive name query response from 10.160.50.8 ( 10.160.50.8 )
+  Domain=[DEVELOPMENT] OS=[Windows 5.1] Server=[Windows 2000 LAN Manager]
+  <prompt>Get file Hddm91c1_de.ABD? </prompt><userinput>n</userinput>
+  <prompt>Get file Hddm91c1_de.def? </prompt><userinput>y</userinput>
+  getting file \W32X86\2\Hddm91c1_de.def of size 428 as Hddm91c1_de.def (22.0 kb/s) (average 22.0 kb/s)
+  <prompt>Get file Hddm91c1_de.DLL? </prompt><userinput>y</userinput>
+  getting file \W32X86\2\Hddm91c1_de.DLL of size 876544 as Hddm91c1_de.DLL (737.3 kb/s) (average 737.3 kb/s)
+  [...]
+
+</screen></para>
+
+<para>
+After this command is complete, the files are in our current local
+directory. You probably have noticed that this time we passed several
+commands to the <option>-c</option> parameter, separated by semi-colons.  This
+effects that all commands are executed in sequence on the remote
+Windows server before smbclient exits again.
+</para>
+
+<para>
+Don't forget to repeat the procedure for the <application>WIN40</application>
+architecture should you need to support Win95/98/XP clients.  Remember, the
+files for these architectures are in the WIN40/0/ subdir. Once we are
+complete, we can run <command>smbclient ...  put</command> to store
+the collected files on the Samba server's
+<parameter>[print$]</parameter> share.
+</para>
+</sect3>
+
+<sect3>
+<title>Depositing the Driver Files into [print$]</title>
+
+<para>
+So, now we are going to put the driver files into the
+<parameter>[print$]</parameter> share. Remember, the UNIX path to this
+share has been defined previously in your
+. You also have created subdirectories
+for the different Windows client types you want to support. Supposing
+your <parameter>[print$]</parameter> share maps to the UNIX path
+<filename>/etc/samba/drivers/</filename>, your driver files should now
+go here:
+</para>
+
+<itemizedlist>
+<listitem><para>for all Windows NT, 2000 and XP clients into
+<filename>/etc/samba/drivers/W32X86/</filename> <emphasis>but
+*not*(yet) into the "2" subdir</emphasis>!</para></listitem>
+
+<listitem><para>for all Windows 95, 98 and ME clients into
+<filename>/etc/samba/drivers/WIN40/</filename> -- <emphasis>but *not*
+(yet) into the "0" subdir</emphasis>!</para></listitem>
+</itemizedlist>
+
+<para>
+We again use smbclient to transfer the driver files across the
+network. We specify the same files and paths as were leaked to us by
+running <command>getdriver</command> against the original
+<emphasis>Windows</emphasis> install. However, now we are going to
+store the files into a <emphasis>Samba/UNIX</emphasis> print server's
+<parameter>[print$]</parameter> share...
+</para>
+
+<para><screen>
+&rootprompt;<userinput>smbclient //SAMBA-CUPS/print\$ -U'root%xxxx' -c 'cd W32X86; put HDNIS01_de.DLL; \
+  put Hddm91c1_de.ppd; put HDNIS01U_de.DLL;        \
+  put HDNIS01U_de.HLP; put Hddm91c1_de.DLL;        \
+  put Hddm91c1_de.INI; put Hddm91c1KMMin.DLL;      \
+  put Hddm91c1_de.dat; put Hddm91c1_de.dat;        \
+  put Hddm91c1_de.def; put Hddm91c1_de.hre;        \
+  put Hddm91c1_de.vnd; put Hddm91c1_de.hlp;        \
+  put Hddm91c1_de_reg.HLP; put HDNIS01Aux.dll;     \
+  put HDNIS01_de.NTF'</userinput>
+ added interface ip=10.160.51.60 bcast=10.160.51.255 nmask=255.255.252.0
+ Got a positive name query response from 10.160.51.162 ( 10.160.51.162 )
+ Domain=[CUPS-PRINT] OS=[Unix] Server=[Samba 2.2.7a]
+ putting file HDNIS01_de.DLL as \W32X86\HDNIS01_de.DLL (4465.5 kb/s) (average 4465.5 kb/s)
+ putting file Hddm91c1_de.ppd as \W32X86\Hddm91c1_de.ppd (12876.8 kb/s) (average 4638.9 kb/s)
+ putting file HDNIS01U_de.DLL as \W32X86\HDNIS01U_de.DLL (20249.8 kb/s) (average 5828.3 kb/s)
+ putting file HDNIS01U_de.HLP as \W32X86\HDNIS01U_de.HLP (9652.8 kb/s) (average 5899.8 kb/s)
+ putting file Hddm91c1_de.DLL as \W32X86\Hddm91c1_de.DLL (23777.7 kb/s) (average 10400.6 kb/s)
+ putting file Hddm91c1_de.INI as \W32X86\Hddm91c1_de.INI (98.6 kb/s) (average 10329.0 kb/s)
+ putting file Hddm91c1KMMin.DLL as \W32X86\Hddm91c1KMMin.DLL (22931.5 kb/s) (average 10501.7 kb/s)
+ putting file Hddm91c1_de.dat as \W32X86\Hddm91c1_de.dat (2462.8 kb/s) (average 10393.0 kb/s)
+ putting file Hddm91c1_de.dat as \W32X86\Hddm91c1_de.dat (4925.3 kb/s) (average 10356.3 kb/s)
+ putting file Hddm91c1_de.def as \W32X86\Hddm91c1_de.def (417.9 kb/s) (average 10290.1 kb/s)
+ putting file Hddm91c1_de.hre as \W32X86\Hddm91c1_de.hre (22571.3 kb/s) (average 11338.5 kb/s)
+ putting file Hddm91c1_de.vnd as \W32X86\Hddm91c1_de.vnd (3384.6 kb/s) (average 10754.3 kb/s)
+ putting file Hddm91c1_de.hlp as \W32X86\Hddm91c1_de.hlp (18406.8 kb/s) (average 10839.8 kb/s)
+ putting file Hddm91c1_de_reg.HLP as \W32X86\Hddm91c1_de_reg.HLP (20278.3 kb/s) (average 11386.3 kb/s)
+ putting file HDNIS01Aux.dll as \W32X86\HDNIS01Aux.dll (14994.6 kb/s) (average 11405.2 kb/s)
+ putting file HDNIS01_de.NTF as \W32X86\HDNIS01_de.NTF (23390.2 kb/s) (average 13170.8 kb/s)
+
+</screen></para>
+
+<para>
+Phewww -- that was a lot of typing! Most drivers are a lot smaller --
+many only having 3 generic PostScript driver files plus 1 PPD. Note,
+that while we did retrieve the files from the "2" subdirectory of the
+"W32X86" directory from the Windows box, we <emphasis>don't</emphasis>
+put them (for now) in this same subdirectory of the Samba box! This
+re-location will automatically be done by the
+<command>adddriver</command> command which we will run shortly (and
+don't forget to also put the files for the Win95/98/ME architecture
+into the <filename>WIN40/</filename> subdirectory should you need
+them).
+</para>
+</sect3>
+
+<sect3>
+<title>Check if the Driver Files are there (with smbclient)</title>
+
+<para>
+For now we verify that our files are there. This can be done with
+<command>smbclient</command> too (but of course you can log in via SSH
+also and do this through a standard UNIX shell access too):
+</para>
+
+<para><screen>
+&rootprompt;<userinput>smbclient //SAMBA-CUPS/print\$ -U 'root%xxxx' -c 'cd W32X86; pwd; dir; cd 2; pwd; dir'</userinput>
+ added interface ip=10.160.51.60 bcast=10.160.51.255 nmask=255.255.252.0
+ Got a positive name query response from 10.160.51.162 ( 10.160.51.162 )
+ Domain=[CUPS-PRINT] OS=[Unix] Server=[Samba 2.2.7a]
+
+  Current directory is \\SAMBA-CUPS\print$\W32X86\
+  .                                   D        0  Sun May  4 03:56:35 2003
+  ..                                  D        0  Thu Apr 10 23:47:40 2003
+  2                                   D        0  Sun May  4 03:56:18 2003
+  HDNIS01Aux.dll                      A    15356  Sun May  4 03:58:59 2003
+  Hddm91c1KMMin.DLL                   A    46966  Sun May  4 03:58:59 2003
+  HDNIS01_de.DLL                      A   434400  Sun May  4 03:58:59 2003
+  HDNIS01_de.NTF                      A   790404  Sun May  4 03:56:35 2003
+  Hddm91c1_de.DLL                     A   876544  Sun May  4 03:58:59 2003
+  Hddm91c1_de.INI                     A      101  Sun May  4 03:58:59 2003
+  Hddm91c1_de.dat                     A     5044  Sun May  4 03:58:59 2003
+  Hddm91c1_de.def                     A      428  Sun May  4 03:58:59 2003
+  Hddm91c1_de.hlp                     A    37699  Sun May  4 03:58:59 2003
+  Hddm91c1_de.hre                     A   323584  Sun May  4 03:58:59 2003
+  Hddm91c1_de.ppd                     A    26373  Sun May  4 03:58:59 2003
+  Hddm91c1_de.vnd                     A    45056  Sun May  4 03:58:59 2003
+  HDNIS01U_de.DLL                     A   165888  Sun May  4 03:58:59 2003
+  HDNIS01U_de.HLP                     A    19770  Sun May  4 03:58:59 2003
+  Hddm91c1_de_reg.HLP                 A   228417  Sun May  4 03:58:59 2003
+                40976 blocks of size 262144. 709 blocks available
+
+  Current directory is \\SAMBA-CUPS\print$\W32X86\2\
+  .                                   D        0  Sun May  4 03:56:18 2003
+  ..                                  D        0  Sun May  4 03:56:35 2003
+  ADOBEPS5.DLL                        A   434400  Sat May  3 23:18:45 2003
+  laserjet4.ppd                       A     9639  Thu Apr 24 01:05:32 2003
+  ADOBEPSU.DLL                        A   109568  Sat May  3 23:18:45 2003
+  ADOBEPSU.HLP                        A    18082  Sat May  3 23:18:45 2003
+  PDFcreator2.PPD                     A    15746  Sun Apr 20 22:24:07 2003
+                40976 blocks of size 262144. 709 blocks available
+
+</screen></para>
+
+<para>
+Notice that there are already driver files present in the
+<filename>2</filename> subdir (probably from a previous
+installation). Once the files for the new driver are there too, you
+are still a few steps away from being able to use them on the
+clients. The only thing you could do *now* is to retrieve them from a
+client just like you retrieve ordinary files from a file share, by
+opening print$ in Windows Explorer. But that wouldn't install them per
+Point'n'Print. The reason is: Samba doesn't know yet that these files
+are something special, namely <emphasis>printer driver
+files</emphasis> and it doesn't know yet to which print queue(s) these
+driver files belong.
+</para>
+</sect3>
+
+<sect3>
+<title>Running <command>rpcclient</command> with
+<command>adddriver</command></title>
+
+<para>
+So, next you must tell Samba about the special category of the files
+you just uploaded into the <parameter>[print$]</parameter> share. This
+is done by the <command>adddriver</command> command. It will
+prompt Samba to register the driver files into its internal TDB
+database files. The following command and its output has been edited,
+again, for readability:
+</para>
+
+<para><screen>
+&rootprompt;<userinput>rpcclient -Uroot%xxxx -c 'adddriver "Windows NT x86" "dm9110:HDNIS01_de.DLL: \
+  Hddm91c1_de.ppd:HDNIS01U_de.DLL:HDNIS01U_de.HLP:   \
+  NULL:RAW:Hddm91c1_de.DLL,Hddm91c1_de.INI,          \
+  Hddm91c1_de.dat,Hddm91c1_de.def,Hddm91c1_de.hre,   \
+  Hddm91c1_de.vnd,Hddm91c1_de.hlp,Hddm91c1KMMin.DLL, \
+  HDNIS01Aux.dll,HDNIS01_de.NTF,                     \
+  Hddm91c1_de_reg.HLP' SAMBA-CUPS</userinput>
+
+ cmd = adddriver "Windows NT x86" "dm9110:HDNIS01_de.DLL:Hddm91c1_de.ppd:HDNIS01U_de.DLL:    \
+  HDNIS01U_de.HLP:NULL:RAW:Hddm91c1_de.DLL,Hddm91c1_de.INI, \
+  Hddm91c1_de.dat,Hddm91c1_de.def,Hddm91c1_de.hre,          \
+  Hddm91c1_de.vnd,Hddm91c1_de.hlp,Hddm91c1KMMin.DLL,        \
+  HDNIS01Aux.dll,HDNIS01_de.NTF,Hddm91c1_de_reg.HLP"
+
+ Printer Driver dm9110 successfully installed.
+
+</screen></para>
+
+<para>
+After this step the driver should be recognized by Samba on the print
+server. You need to be very careful when typing the command. Don't
+exchange the order of the fields. Some changes would lead to a
+<computeroutput>NT_STATUS_UNSUCCESSFUL</computeroutput> error
+message. These become obvious. Other changes might install the driver
+files successfully, but render the driver unworkable. So take care!
+Hints about the syntax of the adddriver command are in the man
+page. The CUPS printing chapter of this HOWTO collection provides a
+more detailed description, if you should need it.
+</para>
+</sect3>
+
+<sect3>
+<title>Check how Driver Files have been moved after
+<command>adddriver</command> finished</title>
+
+<para>
+One indication for Samba's recognition of the files as driver files is
+the <computeroutput>successfully installed</computeroutput> message.
+Another one is the fact, that our files have been moved by the
+<command>adddriver</command> command into the <filename>2</filename>
+subdirectory. You can check this again with
+<command>smbclient</command>:
+</para>
+
+<para><screen>
+&rootprompt;<userinput>smbclient //SAMBA-CUPS/print\$ -Uroot%xxxx -c 'cd W32X86;dir;pwd;cd 2;dir;pwd'</userinput>
+ added interface ip=10.160.51.162 bcast=10.160.51.255 nmask=255.255.252.0
+ Domain=[CUPS-PRINT] OS=[Unix] Server=[Samba 2.2.7a]
+
+  Current directory is \\SAMBA-CUPS\print$\W32X86\
+  .                                   D        0  Sun May  4 04:32:48 2003
+  ..                                  D        0  Thu Apr 10 23:47:40 2003
+  2                                   D        0  Sun May  4 04:32:48 2003
+                40976 blocks of size 262144. 731 blocks available 
+
+  Current directory is \\SAMBA-CUPS\print$\W32X86\2\
+  .                                   D        0  Sun May  4 04:32:48 2003
+  ..                                  D        0  Sun May  4 04:32:48 2003
+  DigiMaster.PPD                      A   148336  Thu Apr 24 01:07:00 2003
+  ADOBEPS5.DLL                        A   434400  Sat May  3 23:18:45 2003
+  laserjet4.ppd                       A     9639  Thu Apr 24 01:05:32 2003
+  ADOBEPSU.DLL                        A   109568  Sat May  3 23:18:45 2003
+  ADOBEPSU.HLP                        A    18082  Sat May  3 23:18:45 2003
+  PDFcreator2.PPD                     A    15746  Sun Apr 20 22:24:07 2003
+  HDNIS01Aux.dll                      A    15356  Sun May  4 04:32:18 2003
+  Hddm91c1KMMin.DLL                   A    46966  Sun May  4 04:32:18 2003
+  HDNIS01_de.DLL                      A   434400  Sun May  4 04:32:18 2003
+  HDNIS01_de.NTF                      A   790404  Sun May  4 04:32:18 2003
+  Hddm91c1_de.DLL                     A   876544  Sun May  4 04:32:18 2003
+  Hddm91c1_de.INI                     A      101  Sun May  4 04:32:18 2003
+  Hddm91c1_de.dat                     A     5044  Sun May  4 04:32:18 2003
+  Hddm91c1_de.def                     A      428  Sun May  4 04:32:18 2003
+  Hddm91c1_de.hlp                     A    37699  Sun May  4 04:32:18 2003
+  Hddm91c1_de.hre                     A   323584  Sun May  4 04:32:18 2003
+  Hddm91c1_de.ppd                     A    26373  Sun May  4 04:32:18 2003
+  Hddm91c1_de.vnd                     A    45056  Sun May  4 04:32:18 2003
+  HDNIS01U_de.DLL                     A   165888  Sun May  4 04:32:18 2003
+  HDNIS01U_de.HLP                     A    19770  Sun May  4 04:32:18 2003
+  Hddm91c1_de_reg.HLP                 A   228417  Sun May  4 04:32:18 2003
+                40976 blocks of size 262144. 731 blocks available
+
+</screen></para>
+
+<para>
+Another verification is that the timestamp of the printing TDB files
+is now updated (and possibly their filesize has increased).
+</para>
+</sect3>
+
+<sect3>
+<title>Check if the Driver is recognized by Samba</title>
+
+<para>
+Now the driver should be registered with Samba. We can easily verify
+this, and will do so in a moment. However, this driver is
+<emphasis>not yet</emphasis> associated with a particular
+<emphasis>printer</emphasis>. We may check the driver status of the
+files by at least three methods:
+</para>
+
+<itemizedlist>
+<listitem><para>from any Windows client browse Network Neighbourhood,
+find the Samba host and open the Samba <guiicon>Printers and
+Faxes</guiicon> folder. Select any printer icon, right-click and
+select the printer <guimenuitem>Properties</guimenuitem>. Click on the
+<guilabel>Advanced</guilabel> tab. Here is a field indicating the
+driver for that printer. A drop down menu allows you to change that
+driver (be careful to not do this unwittingly.).  You can use this
+list to view all drivers know to Samba. Your new one should be amongst
+them. (Each type of client will only see his own architecture's
+list. If you don't have every driver installed for each platform, the
+list will differ if you look at it from Windows95/98/ME or
+WindowsNT/2000/XP.)</para></listitem>
+
+<listitem><para>from a Windows 2000 or XP client (not WinNT) browse
+<guiicon>Network Neighbourhood</guiicon>, search for the Samba
+server and open the server's <guiicon>Printers</guiicon> folder,
+right-click the white background (with no printer highlighted). Select
+<guimenuitem>Server Properties</guimenuitem>. On the
+<guilabel>Drivers</guilabel> tab you will see the new driver listed
+now. This view enables you to also inspect the list of files belonging
+to that driver<emphasis> (this doesn't work on Windows NT, but only on
+Windows 2000 and Windows XP. WinNT doesn't provide the "Drivers"
+tab).</emphasis>. An alternative, much quicker method for Windows
+2000/XP to start this dialog is by typing into a DOS box (you must of
+course adapt the name to your Samba server instead of <replaceable>SAMBA-CUPS</replaceable>):
+</para>
+
+<para><userinput> rundll32 printui.dll,PrintUIEntry /s /t2 /n\\<replaceable>SAMBA-CUPS</replaceable></userinput></para>
+</listitem>
+
+<listitem><para>from a UNIX prompt run this command (or a variant
+thereof), where <replaceable>SAMBA-CUPS</replaceable> is the name of the Samba
+host and "xxxx" represents the actual Samba password assigned to root:
+</para>
+
+<para><userinput>rpcclient -U'root%xxxx' -c 'enumdrivers' <replaceable>SAMBA-CUPS</replaceable></userinput></para>
+
+<para>
+You will see a listing of all drivers Samba knows about. Your new one
+should be amongst them. But it is only listed under the <parameter>[Windows NT
+x86]</parameter> heading, not under <parameter>[Windows 4.0]</parameter>,
+since we didn't install that part. Or did *you*? -- You will see a listing of
+all drivers Samba knows about. Your new one should be amongst them. In our
+example it is named <emphasis>dm9110</emphasis>.  Note that the 3rd column
+shows the other installed drivers twice, for each supported architecture one
+time. Our new driver only shows up for 
+<application>Windows NT 4.0 or 2000</application>. To
+have it present for <application>Windows 95, 98 and ME</application> you'll
+have to repeat the whole procedure with the WIN40 architecture and subdirectory.
 </para></listitem>
+</itemizedlist>
+</sect3>
+
+<sect3>
+<title>A side note: you are not bound to specific driver names</title>
+
+<para>
+You can name the driver as you like. If you repeat the
+<command>adddriver</command> step, with the same files as before, but
+with a different driver name, it will work the same:
+</para>
+
+<para><screen>
+&rootprompt;<userinput>rpcclient -Uroot%xxxx                                        \
+      -c 'adddriver "Windows NT x86"                     \
+      "myphantasydrivername:HDNIS01_de.DLL:              \
+      Hddm91c1_de.ppd:HDNIS01U_de.DLL:HDNIS01U_de.HLP:   \
+      NULL:RAW:Hddm91c1_de.DLL,Hddm91c1_de.INI,          \
+      Hddm91c1_de.dat,Hddm91c1_de.def,Hddm91c1_de.hre,   \
+      Hddm91c1_de.vnd,Hddm91c1_de.hlp,Hddm91c1KMMin.DLL, \
+      HDNIS01Aux.dll,HDNIS01_de.NTF,Hddm91c1_de_reg.HLP' SAMBA-CUPS
+  </userinput>
+
+ cmd = adddriver "Windows NT x86" 
+                 "myphantasydrivername:HDNIS01_de.DLL:Hddm91c1_de.ppd:HDNIS01U_de.DLL:\
+                  HDNIS01U_de.HLP:NULL:RAW:Hddm91c1_de.DLL,Hddm91c1_de.INI,           \
+                  Hddm91c1_de.dat,Hddm91c1_de.def,Hddm91c1_de.hre,                    \
+                  Hddm91c1_de.vnd,Hddm91c1_de.hlp,Hddm91c1KMMin.DLL,                  \
+                  HDNIS01Aux.dll,HDNIS01_de.NTF,Hddm91c1_de_reg.HLP"
+
+ Printer Driver myphantasydrivername successfully installed.
+
+</screen></para>
+
+<para>
+You will also be able to bind that driver to any print queue (however,
+you are responsible yourself that you associate drivers to queues
+which make sense to the target printer). Note, that you can't run the
+<command>rpcclient</command> <command>adddriver</command> command
+repeatedly. Each run "consumes" the files you had put into the
+<parameter>[print$]</parameter> share by moving them into the
+respective subdirectories. So you <emphasis>must</emphasis> precede an
+<command>smbclient ... put</command> command before each
+<command>rpcclient ...  adddriver</command>" command.
+</para>
+</sect3>
+
+<sect3>
+<title>La Grande Finale: Running <command>rpcclient</command> with
+<command>setdriver</command></title>
+
+<para>
+Samba still needs to know <emphasis>which</emphasis> printer's driver
+this is.  It needs to create a mapping of the driver to a printer, and
+store this info in its "memory", the TDB files. The <command>rpcclient
+setdriver</command> command achieves exactly this:
+</para>
+
+<para><screen>
+&rootprompt;<userinput>rpcclient -U'root%xxxx' -c 'setdriver dm9110 myphantasydrivername' <replaceable>SAMBA-CUPS</replaceable></userinput>
+ cmd = setdriver dm9110 myphantasydrivername
+ Successfully set dm9110 to driver myphantasydrivername.
+</screen></para>
+
+<para>
+Ahhhhh -- no, I didn't want to do that. Repeat, this time with the
+name I intended: 
+</para>
+
+<para><screen>
+&rootprompt;<userinput>rpcclient -U'root%xxxx' -c 'setdriver dm9110 dm9110' <replaceable>SAMBA-CUPS</replaceable></userinput>
+ cmd = setdriver dm9110 dm9110
+ Successfully set dm9110 to driver dm9110.
+</screen></para>
+
+<para>
+The syntax of the command is <userinput>rpcclient 
+-U'root%<replaceable>sambapassword</replaceable>' -c 'setdriver 
+"<replaceable>printername</replaceable>" 
+"<replaceable>drivername</replaceable>' 
+<replaceable>SAMBA-Hostname</replaceable></userinput> . --
+Now we have done *most* of the work. But not yet all....
+</para>
+
+<note><para>
+the <command>setdriver</command> command will only succeed if the printer is
+known to
+Samba already. A bug in 2.2.x prevented Samba from recognizing freshly
+installed printers. You had to restart Samba, or at least send a HUP
+signal to all running smbd processes to work around this:
+<userinput>kill -HUP `pidof smbd`</userinput>.  </para></note>
+</sect3>
+</sect2>
+</sect1>
+
+<sect1>
+<title>"The Proof of the Pudding lies in the Eating" (Client Driver Install
+Procedure)</title>
+
+<para>
+A famous philosopher said once: <quote>The Proof of the Pudding lies
+in the Eating</quote>. The proof for our setup lies in the printing.
+So let's install the printer driver onto the client PCs. This is not
+as straightforward as it may seem. Read on.
+</para>
+
+<sect2>
+<title>The first Client Driver Installation</title>
+
+<para>
+Especially important is the installation onto the first client PC (for
+each architectural platform separately). Once this is done correctly,
+all further clients are easy to setup and shouldn't need further
+attention. What follows is a description for the recommended first
+procedure. You work now from a client workstation. First you should
+guarantee that your connection is not unwittingly mapped to
+<parameter>bad user</parameter> "nobody". In a DOS box type:
+</para>
+
+<para><userinput>net use \\<replaceable>SAMBA-SERVER</replaceable>\print$ /user:root</userinput></para>
+
+<para>
+Replace root, if needed, by another valid 
+<replaceable>printer admin</replaceable> user as given in the  definition.
+Should you already be connected as a different user, you'll get an error
+message. There is no easy way to get rid of that connection, because
+Windows doesn't seem to know a concept of "logging off" from a share
+connection (don't confuse this with logging off from the local
+workstation; that is a different matter). You can try to close
+<emphasis>all</emphasis> Windows file explorer and Internet Explorer
+windows. As a last resort, you may have to reboot. Make sure there is
+no automatic re-connection set up. It may be easier to go to a
+different workstation and try from there. After you have made sure you
+are connected as a printer admin user (you can check this with the
+<command>smbstatus</command> command on Samba) do this from the
+Windows workstation:
+</para>
+
+<itemizedlist>
+<listitem><para>Open <guiicon>Network
+Neighbourhood</guiicon></para></listitem>
+
+<listitem><para>Browse to Samba server</para></listitem>
+
+<listitem><para>Open its <guiicon>Printers and
+Faxes</guiicon> folder</para></listitem>
+
+<listitem><para>Highlight and right-click the printer</para></listitem>
+
+<listitem><para>Select <guimenuitem>Connect...</guimenuitem> (for WinNT4/2K
+it is possibly <guimenuitem>Install...</guimenuitem>)</para></listitem>
+</itemizedlist>
+
+<para>
+A new printer (named <replaceable>printername</replaceable> on
+samba-server) should now have appeared in your
+<emphasis>local</emphasis> Printer folder (check <guimenu>Start</guimenu> --
+<guimenuitem>Settings</guimenuitem> -- <guimenuitem>Control Panel</guimenuitem>
+-- <guiicon>Printers and Faxes</guiicon>).
+</para>
+
+<para>
+Most likely you are now tempted to try and print a test page.  After
+all, you now can open the printer properties and on the "General" tab,
+there is a button offering to do just that. But chances are that you
+get an error message saying <errorname>Unable to print Test
+Page</errorname>. The reason might be that there is not yet a
+valid Device Mode set for the driver, or that the "Printer Driver
+Data" set is still incomplete.
+</para>
+
+<para>
+You must now make sure that a valid "Device Mode" is set for the
+driver. Don't fear -- we will explain now what that means.
+</para>
+</sect2>
+
+<sect2>
+<title>IMPORTANT! Setting Device Modes on new Printers</title>
+
+<para>
+In order for a printer to be truly usable by a Windows NT/2K/XP
+client, it must possess:
+</para>
+
+<itemizedlist>
+<listitem><para>a valid <emphasis>Device Mode</emphasis> generated by
+the driver for the printer (defining things like paper size,
+orientation and duplex settings), and</para></listitem>
+
+<listitem><para>a complete set of
+<emphasis>Printer Driver Data</emphasis> generated by the
+driver.</para></listitem>
+</itemizedlist>
+
+<para>
+If either one of these is incomplete, the clients can produce less
+than optimal output at best. In the worst cases, unreadable garbage or
+nothing at all comes from the printer or they produce a harvest of
+error messages when attempting to print. Samba stores the named values
+and all printing related info in its internal TDB database files
+<filename>(ntprinters.tdb</filename>,
+<filename>ntdrivers.tdb</filename>, <filename>printing.tdb</filename>
+and <filename>ntforms.tdb</filename>).
+</para>
+
+<para>
+What do these two words stand for? Basically, the Device Mode and the
+set of Printer Driver Data is a collection of settings for all print
+queue properties, initialized in a sensible way. Device Modes and
+Printer Driver Data should initially be set on the print server (that is
+here: the Samba host) to healthy values so that the clients can start
+to use them immediately. How do we set these initial healthy values?
+This can be achieved by accessing the drivers remotely from an NT (or
+2k/XP) client, as is discussed in the next paragraphs.
+</para>
+
+<para>
+Be aware, that a valid Device Mode can only be initiated by a
+<parameter>printer admin</parameter>, or root (the reason should be
+obvious). Device Modes can only correctly be set by executing the
+printer driver program itself. Since Samba can not execute this Win32
+platform driver code, it sets this field initially to NULL (which is
+not a valid setting for clients to use). Fortunately, most drivers
+generate themselves the Printer Driver Data that is needed, when they
+are uploaded to the <parameter>[print$]</parameter> share with the
+help of the APW or rpcclient.
+</para>
+
+<para>
+The generation and setting of a first valid Device Mode however
+requires some "tickling" from a client, to set it on the Samba
+server. The easiest means of doing so is to simply change the page
+orientation on the server's printer. This "executes" enough of the
+printer driver program on the client for the desired effect to happen,
+and feeds back the new Device Mode to our Samba server. You can use the
+native Windows NT/2K/XP printer properties page from a Window client
+for this:
+</para>
+
+<itemizedlist>
+	<listitem><para>Browse the <guiicon>Network Neighbourhood</guiicon></para></listitem>
+
+<listitem><para>Find the Samba server</para></listitem>
+
+<listitem><para>Open the Samba server's <guiicon>Printers and
+	Faxes</guiicon> folder</para></listitem>
+
+<listitem><para>Highlight the shared printer in question</para></listitem>
+
+<listitem><para>Right-click the printer (you may already be here, if you
+followed the last section's description)</para></listitem>
+
+<listitem><para>At the bottom of the context menu select
+<guimenu>Properties....</guimenu> (if the menu still offers the 
+<guimenuitem>Connect...</guimenuitem> entry
+further above, you need to click that one first to achieve the driver
+installation as shown in the last section)</para></listitem>
+
+<listitem><para>Go to the <guilabel>Advanced</guilabel> tab; click on 
+<guibutton>Printing Defaults...</guibutton></para></listitem>
+
+<listitem><para>Change the "Portrait" page setting to "Landscape" (and
+back)</para></listitem>
+
+<listitem><para>(Oh, and make sure to <emphasis>apply</emphasis>
+changes between swapping the page orientation to cause the change to
+actually take effect...).</para></listitem>
+
+<listitem><para>While you're at it, you may optionally also want to
+set the desired printing defaults here, which then apply to all future
+client driver installations on the remaining from now
+on.</para></listitem>
+</itemizedlist>
+
+<para>
+This procedure has executed the printer driver program on the client
+platform and fed back the correct Device Mode to Samba, which now
+stored it in its TDB files. Once the driver is installed on the
+client, you can follow the analogous steps by accessing the
+<emphasis>local</emphasis> <guiicon>Printers</guiicon> folder too if you are
+a Samba printer admin user. From now on printing should work as expected.
+</para>
+
+<para>
+Samba also includes a service level parameter name <parameter>default
+devmode</parameter> for generating a default Device Mode for a
+printer. Some drivers will function well with Samba's default set of
+properties. Others may crash the client's spooler service. So use this
+parameter with caution. It is always better to have the client
+generate a valid device mode for the printer and store it on the
+server for you.
+</para>
+</sect2>
+
+<sect2>
+<title>Further Client Driver Install Procedures</title>
+
+<para>
+Every further driver may be done by any user, along the lines
+described above: Browse network, open printers folder on Samba server,
+right-click printer and choose <guimenuitem>Connect...</guimenuitem>. Once
+this completes (should be not more than a few seconds, but could also take
+a minute, depending on network conditions), you should find the new printer in
+your client workstation local <guiicon>Printers and
+Faxes</guiicon> folder.
+</para>
+
+<para>
+You can also open your local <guiicon>Printers and Faxes</guiicon> folder by
+using this command on Windows 2000 and Windows XP Professional workstations:
+</para>
+
+<para><userinput>rundll32 shell32.dll,SHHelpShortcuts_RunDLL PrintersFolder
+</userinput></para>
+
+<para>
+or this command on Windows NT 4.0 workstations:
+</para>
+
+<para><userinput>
+rundll32 shell32.dll,Control_RunDLL MAIN.CPL @2
+</userinput></para>
+
+<para>
+You can enter the commands either inside a <guilabel>DOS box</guilabel> window 
+or in the <guimenuitem>Run command...</guimenuitem> field from the 
+<guimenu>Start</guimenu> menu.
+</para>
+</sect2>
+
+<sect2>
+<title>Always make first Client Connection as root or "printer admin"</title>
+
+<para>
+After you installed the driver on the Samba server (in its
+<parameter>[print$]</parameter> share, you should always make sure
+that your first client installation completes correctly. Make it a habit for
+yourself to build that the very first connection from a client as
+<parameter>printer admin</parameter>. This is to make sure that:
+</para>
+
+<itemizedlist>
+
+<listitem><para> a first valid <emphasis>Device Mode</emphasis> is
+really initialized (see above for more explanation details), and
+that</para></listitem>
+
+<listitem><para> the default print settings of your printer for all
+further client installations are as you want them</para></listitem>
+</itemizedlist>
+
+<para>
+Do this by changing the orientation to landscape, click
+<emphasis>Apply</emphasis>, and then change it back again. Then modify
+the other settings (for example, you don't want the default media size
+set to <emphasis>Letter</emphasis>, when you are all using
+<emphasis>A4</emphasis>, right? You may want to set the printer for
+<emphasis>duplex</emphasis> as the default; etc.).
+</para>
+
+<para>
+To connect as root to a Samba printer, try this command from a Windows
+2K/XP DOS box command prompt:
+</para>
+
+<para><userinput>runas /netonly /user:root "rundll32 printui.dll,PrintUIEntry /p /t3 /n \\<replaceable>SAMBA-SERVER</replaceable>\<replaceable>printername</replaceable>"</userinput>
+</para>
+
+<para>
+You will be prompted for root's Samba-password; type it, wait a few
+seconds, click on <guibutton>Printing Defaults...</guibutton> and
+proceed to set the job options as should be used as defaults by all
+clients. Alternatively, instead of root you can name one other member
+of the <parameter>printer admins</parameter> from the setting.
+</para>
+
+<para>
+Now all the other users downloading and installing the driver
+the same way (called <emphasis>Point'n'Print</emphasis>) will
+have the same defaults set for them. If you miss this step you'll
+get a lot of helpdesk calls from your users. But maybe you like to
+talk to people.... ;-)
+</para>
+</sect2>
+</sect1>
+
+<sect1>
+<title>Other Gotchas</title>
+
+<para>
+Your driver is installed. It is ready for
+<emphasis>Point'n'Print</emphasis> installation by the clients
+now. You <emphasis>may</emphasis> have tried to download and use it
+onto your first client machine now. But wait... let's make you
+acquainted first with a few tips and tricks you may find useful.  For
+example, suppose you didn't manage to "set the defaults" on the
+printer, as advised in the preceding paragraphs? And your users
+complain about various issues (such as <quote>We need to set the paper
+size for each job from Letter to A4 and it won't store it!</quote>)
+</para>
+
+<sect2>
+<title>Setting Default Print Options for the Client Drivers</title>
+
+<para>
+The last sentence might be viewed with mixed feelings by some users and
+admins. They have struggled for hours and hours and couldn't arrive at
+a point were their settings seemed to be saved.  It is not their
+fault. The confusing thing is this: in the multi-tabbed dialog that pops
+up when you right-click the printer name and select 
+<guimenuitem>Properties...</guimenuitem>, you can arrive at two identically
+looking dialogs, each claiming that they help you to set printer options,
+in three different ways. Here is the definite answer to the "Samba
+Default Driver Setting FAQ":
+</para>
+
+<formalpara><title><quote>I can't set and save default print options
+for all users on Win2K/XP! Why not?</quote></title>
+
+<para>
+How are you doing it? I bet the wrong way.... (it is not very
+easy to find out, though). There are 3 different ways to bring you to
+a dialog that <emphasis>seems</emphasis> to set everything. All three
+dialogs <emphasis>look</emphasis> the same. Only one of them
+<emphasis>does</emphasis> what you intend.
+<emphasis>Important:</emphasis> you need to be Administrator or Print
+Administrator to do this for all users. Here is how I reproduce it in
+on XP Professional:
+
+<orderedlist numeration="upperalpha">
+
+<listitem><para>The first "wrong" way:
+
+<orderedlist numeration="arabic">
+<listitem><para>Open the <guiicon>Printers</guiicon>
+folder.</para></listitem>
+
+<listitem><para>Right-click on the printer
+(<emphasis>remoteprinter on cupshost</emphasis>) and
+select in context menu <guimenu>Printing
+Preferences...</guimenu></para></listitem>
+
+<listitem><para>Look at this dialog closely and remember what it looks
+like.</para></listitem>
+</orderedlist>
+</para>
+</listitem>
+
+<listitem><para>The second "wrong" way:
+
+<orderedlist numeration="arabic">
+	<listitem><para>Open the <guimenu>Printers</guimenu>
+folder.</para></listitem>
+
+<listitem><para>Right-click on the printer (<emphasis>remoteprinter on
+cupshost</emphasis>) and select in the context menu
+<guimenuitem>Properties</guimenuitem></para></listitem>
+
+<listitem><para>Click on the <guilabel>General</guilabel>
+tab</para></listitem>
+
+<listitem><para>Click on the button <guibutton>Printing
+Preferences...</guibutton></para></listitem>
+
+<listitem><para>A new dialog opens. Keep this dialog open and go back
+to the parent dialog.</para></listitem>
+</orderedlist>
+</para>
+</listitem>
+
+<listitem><para>The third, the "correct" way: (should you do
+this from the beginning, just carry out steps 1. and 2. from second
+"way" above)
+
+<orderedlist numeration="arabic">
+<listitem><para>Click on the <guilabel>Advanced</guilabel>
+tab. (Hmmm... if everything is "Grayed Out", then you are not logged
+in as a user with enough privileges).</para></listitem>
+
+<listitem><para>Click on the <guibutton>Printing
+Defaults...</guibutton> button.</para></listitem>
+
+<listitem><para>On any of the two new tabs, click on the
+<guilabel>Advanced...</guilabel> button.</para></listitem>
+
+<listitem><para>A new dialog opens. Compare this one to the other,
+identical looking one from "B.5" or A.3".</para></listitem>
+</orderedlist>
+</para>
+</listitem>
 </orderedlist>
 
+Do you see any difference in the two settings dialogs? I don't
+either. However, only the last one, which you arrived at with steps
+C.1.-6. will permanently save any settings which will then become the
+defaults for new users. If you want all clients to have the same
+defaults, you need to conduct these steps as administrator
+(<parameter>printer admin</parameter> in )
+<emphasis>before</emphasis> a client downloads the driver (the clients
+can later set their own <emphasis>per-user defaults</emphasis> by
+following the procedures <emphasis>A.</emphasis>
+or <emphasis>B.</emphasis> above...). (This is new: Windows 2000 and
+Windows XP allow <emphasis>per-user</emphasis> default settings and
+the ones the administrator gives them, before they set up their own).
+The "parents" of the identically looking dialogs have a slight
+difference in their window names: one is called
+<computeroutput>Default Print Values for Printer Foo on Server
+Bar"</computeroutput> (which is the one you need) and the other is
+called "<computeroutput>Print Settings for Printer Foo on Server
+Bar</computeroutput>". The last one is the one you arrive at when you
+right-click on the printer and select <guimenuitem>Print
+Settings...</guimenuitem>. This is the one what you were
+taught to use back in the days of Windows NT! So it is only natural to
+try the same way with Win2k or WinXP. You wouldn't dream
+that there is now a different "clicking path" to arrive at an
+identically looking, but functionally different dialog to set defaults
+for all users!
+</para></formalpara>
+
+<tip><para>Try (on Win2000 and WinXP) to run this command (as a user
+with the right privileges):
+</para>
+
+<para><userinput>
+rundll32 printui.dll,PrintUIEntry /p /t3 /n\\<replaceable>SAMBA-SERVER</replaceable>\<replaceable>printersharename</replaceable>
+</userinput></para>
+
+<para>
+to see the tab with the <guilabel>Printing Defaults...</guilabel>
+button (the one you need). Also run this command:
+</para>
+
+<para><userinput>
+rundll32 printui.dll,PrintUIEntry /p /t0 /n\\<replaceable>SAMBA-SERVER</replaceable>\<replaceable>printersharename</replaceable>
+</userinput></para>
+
+<para>
+to see the tab with the <guilabel>Printing Preferences...</guilabel>
+button (the one which doesn't set system-wide defaults). You can
+start the commands from inside a DOS box" or from the <guimenu>Start</guimenu>
+-- <guimenuitem>Run...</guimenuitem> menu.
+</para>
+</tip>
+
 </sect2>
 
 <sect2>
-<title>Job sent, no output</title>
+<title>Supporting large Numbers of Printers</title>
 
 <para>
-This is the most frustrating part of printing.  You may have sent the
-job,  verified that the job was forwarded,  set up a wrapper around
-the command to send the file,  but there was no output from the printer.
+One issue that has arisen during the recent development phase of Samba
+is the need to support driver downloads for 100's of printers. Using
+Windows NT APW here is somewhat awkward (to say the least). If you
+don't want to acquire RSS pains from such the printer installation
+clicking orgy alone, you need to think about a non-interactive script.
 </para>
 
 <para>
-First,  check to make sure that the job REALLY is getting to the
-right print queue.  If you are using a BSD or LPRng print spooler,
-you can temporarily stop the printing of jobs.  Jobs can still be
-submitted, but they will not be printed.  Use:
+If more than one printer is using the same driver, the
+<command>rpcclient setdriver</command> command can be used to set the
+driver associated with an installed queue. If the driver is uploaded
+to <parameter>[print$]</parameter> once and registered with the
+printing TDBs, it can be used by multiple print queues. In this case
+you just need to repeat the <command>setprinter</command> subcommand
+of <command>rpcclient</command> for every queue (without the need to
+conduct the <command>adddriver</command> again and again). The
+following is an example of how this could be accomplished:
 </para>
 
-<para><programlisting>
-  lpc -Pprinter stop
-</programlisting></para>
+<para><screen>
+&rootprompt;<userinput>rpcclient <replaceable>SAMBA-CUPS</replaceable> -U root%<replaceable>secret</replaceable> -c 'enumdrivers'</userinput>
+ cmd = enumdrivers
+ 
+ [Windows NT x86]
+ Printer Driver Info 1:
+   Driver Name: [infotec  IS 2075 PCL 6]
+ 
+ Printer Driver Info 1:
+   Driver Name: [DANKA InfoStream]
+ 
+ Printer Driver Info 1:
+   Driver Name: [Heidelberg Digimaster 9110 (PS)]
+ 
+ Printer Driver Info 1:
+   Driver Name: [dm9110]
+
+ Printer Driver Info 1:
+   Driver Name: [myphantasydrivername]
+
+ [....]
+</screen>
+
+<screen>
+&rootprompt;<userinput>rpcclient <replaceable>SAMBA-CUPS</replaceable> -U root%<replaceable>secret</replaceable> -c 'enumprinters'</userinput>
+ cmd = enumprinters
+   flags:[0x800000]
+   name:[\\SAMBA-CUPS\dm9110]
+   description:[\\SAMBA-CUPS\dm9110,,110ppm HiVolume DANKA Stuttgart]
+   comment:[110 ppm HiVolume DANKA Stuttgart]
+ [....]
+</screen>
+
+<screen>
+&rootprompt;<userinput>rpcclient <replaceable>SAMBA-CUPS</replaceable> -U root%<replaceable>secret</replaceable> -c 'setdriver <replaceable>dm9110</replaceable> "<replaceable>Heidelberg Digimaster 9110 (PS)</replaceable>"'</userinput>
+ cmd = setdriver dm9110 Heidelberg Digimaster 9110 (PPD)
+ Successfully set dm9110 to driver Heidelberg Digimaster 9110 (PS).
+</screen>
+
+<screen>
+&rootprompt;<userinput>rpcclient <replaceable>SAMBA-CUPS</replaceable> -U root%<replaceable>secret</replaceable> -c 'enumprinters'</userinput>
+ cmd = enumprinters
+   flags:[0x800000]
+   name:[\\SAMBA-CUPS\dm9110]
+   description:[\\SAMBA-CUPS\dm9110,Heidelberg Digimaster 9110 (PS),110ppm HiVolume DANKA Stuttgart]
+   comment:[110ppm HiVolume DANKA Stuttgart]
+ [....]
+</screen>
+
+<screen>
+&rootprompt;<userinput>rpcclient <replaceable>SAMBA-CUPS</replaceable> -U root%<replaceable>secret</replaceable> -c 'setdriver <replaceable>dm9110</replaceable> <replaceable>myphantasydrivername</replaceable>'</userinput>
+ cmd = setdriver dm9110 myphantasydrivername
+ Successfully set dm9110 to myphantasydrivername.
+</screen>
+
+<screen>
+&rootprompt;<userinput>rpcclient <replaceable>SAMBA-CUPS</replaceable> -U root%<replaceable>secret</replaceable> -c 'enumprinters'</userinput>
+ cmd = enumprinters
+   flags:[0x800000]
+   name:[\\SAMBA-CUPS\dm9110]
+   description:[\\SAMBA-CUPS\dm9110,myphantasydrivername,110ppm HiVolume DANKA Stuttgart]
+   comment:[110ppm HiVolume DANKA Stuttgart]
+ [....]
+</screen></para>
 
 <para>
-Now submit a print job and then use 'lpq -Pprinter' to see if the
-job is in the print queue.  If it is not in the print queue then
-you will have to find out why it is not being accepted for printing.
+It may be not easy to recognize: but the first call to
+<command>enumprinters</command> showed the "dm9110" printer with an
+empty string where the driver should have been listed (between the 2
+commas in the "description" field). After the
+<command>setdriver</command> command succeeded, all is well.  (The
+CUPS Printing chapter has more info about the installation of printer
+drivers with the help of <command>rpcclient</command>).
 </para>
+</sect2>
+
+<sect2>
+<title>Adding new Printers with the Windows NT APW</title>
 
 <para>
-Next, you may want to check to see what the format of the job really
-was.  With the assistance of the system administrator you can view
-the submitted jobs files.  You may be surprised to find that these
-are not in what you would expect to call a printable format.
-You can use the UNIX 'file' utitily to determine what the job
-format actually is:
+By default, Samba exhibits all printer shares defined in
+&smb.conf; in the
+<guiicon>Printers...</guiicon> folder. Also located in this folder
+is the Windows NT Add Printer Wizard icon. The APW will be shown only
+if:
 </para>
 
-<para><programlisting>
-    cd /var/spool/lpd/printer   # spool directory of print jobs
-    ls                          # find job files
-    file dfA001myhost
-</programlisting></para>
+<itemizedlist>
+<listitem><para>...the connected user is able to successfully execute
+an <command>OpenPrinterEx(\\server)</command> with administrative
+privileges (i.e. root or <parameter>printer admin</parameter>).
+</para>
+
+<tip><para> Try this from a Windows 2K/XP DOS box command prompt:
+</para>
+
+<para><userinput>
+runas /netonly /user:root rundll32 printui.dll,PrintUIEntry /p /t0 /n \\<replaceable>SAMBA-SERVER</replaceable>\<replaceable>printersharename</replaceable>
+</userinput></para>
+
+<para>
+and click on <guibutton>Printing Preferences...</guibutton>
+</para></tip></listitem>
+
+<listitem><para>... contains the setting
+<parameter>show add printer wizard = yes</parameter> (the
+default).</para></listitem>
+</itemizedlist>
+
+<para>
+The APW can do various things:
+</para>
+
+<itemizedlist>
+<listitem><para>upload a new driver to the Samba
+<parameter>[print$]</parameter> share;</para></listitem>
+
+<listitem><para>associate an uploaded driver with an existing (but
+still "driverless") print queue;</para></listitem>
+
+<listitem><para>exchange the currently used driver for an existing
+print queue with one that has been uploaded before;</para></listitem>
+
+<listitem><para>add an entirely new printer to the Samba host (only in
+conjunction with a working <parameter>add printer command</parameter>;
+a corresponding <parameter>delete printer command</parameter> for
+removing entries from the <guiicon>Printers...</guiicon> folder
+may be provided too)</para></listitem>
+</itemizedlist>
 
 <para>
-You should make sure that your printer supports this format OR that
-your system administrator has installed a 'print filter' that will
-convert the file to a format appropriate for your printer.
+The last one (add a new printer) requires more effort than the
+previous ones. In order to use the APW to successfully add a printer
+to a Samba server, the <parameter>add printer command</parameter> must
+have a defined value. The program hook must successfully add the
+printer to the Unix print system (i.e. to
+<filename>/etc/printcap</filename>,
+<filename>/etc/cups/printers.conf</filename> or other appropriate
+files) and to  if necessary.
 </para>
 
+<para>
+When using the APW from a client, if the named printer share does not
+exist, smbd will execute the <parameter>add printer
+command</parameter> and reparse to the 
+to attempt to locate the new printer share. If the share is still not
+defined, an error of <errorname>Access Denied</errorname> is
+returned to the client.  Note that the <parameter>add printer
+command</parameter> is executed under the context of the connected
+user, not necessarily a root account. A <parameter>map to guest = bad
+user</parameter> may have connected you unwittingly under the wrong
+privilege; you should check it by using the
+<command>smbstatus</command> command.
+</para>
 </sect2>
 
 <sect2>
-<title>Job sent, strange output</title>
+<title>Weird Error Message <errorname>Cannot connect under a
+different Name</errorname></title>
 
 <para>
-Once you have the job printing, you can then start worrying about
-making it print nicely.
+Once you are connected with the wrong credentials, there is no means
+to reverse the situation other than to close all Explorer windows, and
+perhaps reboot.
 </para>
 
+<itemizedlist>
+<listitem><para>The <command>net use \\SAMBA-SERVER\sharename
+/user:root</command> gives you an error message: <computeroutput>Multiple
+connections to a server or a shared resource by the same user
+utilizing the several user names are not allowed. Disconnect all
+previous connections to the server, resp. the shared resource, and try
+again.</computeroutput></para></listitem>
+
+<listitem><para>Every attempt to "connect a network drive" to
+<filename>\\SAMBASERVER\\print$</filename> to z: is countered by the
+pertinacious message. <computeroutput>This network folder is currently
+connected under different credentials (username and password).
+Disconnect first any existing connection to this network share in
+order to connect again under a different username and
+password</computeroutput>.</para></listitem>
+</itemizedlist>
+
 <para>
-The most common problem is extra pages of output: banner pages
-OR blank pages at the end.
+So you close all connections. You try again. You get the same
+message. You check from the Samba side, using
+<command>smbstatus</command>. Yes, there are some more
+connections. You kill them all. The client still gives you the same
+error message. You watch the smbd.log file on a very high debug level
+and try re-connect. Same error message, but not a single line in the
+log. You start to wonder if there was a connection attempt at all. You
+run ethereal and tcpdump while you try to connect. Result: not a
+single byte goes on the wire. Windows still gives the error
+message. You close all Explorer Windows and start it again. You try to
+connect - and this times it works!  Windows seems to cache connection
+info somewhere and doesn't keep it up to date (if you are unlucky you
+might need to reboot to get rid of the error message).
 </para>
+</sect2>
+
+<sect2>
+<title>Be careful when assembling Driver Files</title>
 
 <para>
-If you are getting banner pages,  check and make sure that the
-printcap option or printer option is configured for no banners.
-If you have a printcap,  this is the :sh (suppress header or banner
-page) option.  You should have the following in your printer.
+You need to be very careful when you take notes about the files and
+belonging to a particular driver. Don't confuse the files for driver
+version "0" (for Win95/98/ME, going into
+<filename>[print$]/WIN/0/</filename>), driver version "2" (Kernel Mode
+driver for WinNT, going into <filename>[print$]/W32X86/2/</filename>
+<emphasis>may</emphasis> be used on Win2K/XP too), and driver version
+"3" (non-Kernel Mode driver going into
+<filename>[print$]/W32X86/3/</filename> <emphasis>can not</emphasis>
+be used on WinNT). Very often these different driver versions contain
+files carrying the same name; but still the files are very different!
+Also, if you look at them from the Windows Explorer (they reside in
+<filename>%WINDOWS%\system32\spool\drivers\W32X86\</filename>) you
+will probably see names in capital letters, while an "enumdrivers"
+command from Samba would show mixed or lower case letters. So it is
+easy to confuse them. If you install them manually using
+<command>rpcclient</command> and subcommands, you may even succeed
+without an error message. Only later, when you try install on a
+client, you will encounter error messages like <computeroutput>This
+server has no appropriate driver for the printer</computeroutput>.
 </para>
 
-<para><programlisting>
-   printer: ... :sh
-</programlisting></para>
+<para>
+Here is an example. You are invited to look very closely at the
+various files, compare their names and their spelling, and discover
+the differences in the composition of the version-2 and -3 sets
+Note: the version-0 set contained 40 (!)
+<parameter>Dependentfiles</parameter>, so I left it out for space
+reasons:
+</para>
+
+<para><screen>
+&rootprompt;<userinput>rpcclient -U 'Administrator%<replaceable>secret</replaceable>' -c 'enumdrivers 3' 10.160.50.8 </userinput>
+
+ Printer Driver Info 3:
+         Version: [3]
+         Driver Name: [Canon iR8500 PS3]
+         Architecture: [Windows NT x86]
+         Driver Path: [\\10.160.50.8\print$\W32X86\3\cns3g.dll]
+         Datafile: [\\10.160.50.8\print$\W32X86\3\iR8500sg.xpd]
+         Configfile: [\\10.160.50.8\print$\W32X86\3\cns3gui.dll]
+         Helpfile: [\\10.160.50.8\print$\W32X86\3\cns3g.hlp]
+ 
+         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\aucplmNT.dll]
+         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\ucs32p.dll]
+         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\tnl32.dll]
+         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\aussdrv.dll]
+         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cnspdc.dll]
+         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\aussapi.dat]
+         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cns3407.dll]
+         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\CnS3G.cnt]
+         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\NBAPI.DLL]
+         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\NBIPC.DLL]
+         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cpcview.exe]
+         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cpcdspl.exe]
+         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cpcedit.dll]
+         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cpcqm.exe]
+         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cpcspl.dll]
+         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cfine32.dll]
+         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cpcr407.dll]
+         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\Cpcqm407.hlp]
+         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cpcqm407.cnt]
+         Dependentfiles: [\\10.160.50.8\print$\W32X86\3\cns3ggr.dll]
+ 
+         Monitorname: []
+         Defaultdatatype: []
+
+ Printer Driver Info 3:
+         Version: [2]
+         Driver Name: [Canon iR5000-6000 PS3]
+         Architecture: [Windows NT x86]
+         Driver Path: [\\10.160.50.8\print$\W32X86\2\cns3g.dll]
+         Datafile: [\\10.160.50.8\print$\W32X86\2\IR5000sg.xpd]
+         Configfile: [\\10.160.50.8\print$\W32X86\2\cns3gui.dll]
+         Helpfile: [\\10.160.50.8\print$\W32X86\2\cns3g.hlp]
+ 
+         Dependentfiles: [\\10.160.50.8\print$\W32X86\2\AUCPLMNT.DLL]
+         Dependentfiles: [\\10.160.50.8\print$\W32X86\2\aussdrv.dll]
+         Dependentfiles: [\\10.160.50.8\print$\W32X86\2\cnspdc.dll]
+         Dependentfiles: [\\10.160.50.8\print$\W32X86\2\aussapi.dat]
+         Dependentfiles: [\\10.160.50.8\print$\W32X86\2\cns3407.dll]
+         Dependentfiles: [\\10.160.50.8\print$\W32X86\2\CnS3G.cnt]
+         Dependentfiles: [\\10.160.50.8\print$\W32X86\2\NBAPI.DLL]
+         Dependentfiles: [\\10.160.50.8\print$\W32X86\2\NBIPC.DLL]
+         Dependentfiles: [\\10.160.50.8\print$\W32X86\2\cns3gum.dll]
+ 
+         Monitorname: [CPCA Language Monitor2]
+         Defaultdatatype: []
+
+</screen></para>
 
 <para>
-If you have this option and are still getting banner pages,  there
-is a strong chance that your printer is generating them for you
-automatically.  You should make sure that banner printing is disabled
-for the printer.  This usually requires using the printer setup software
-or procedures supplied by the printer manufacturer.
+If we write the "version 2" files and the "version 3" files
+into different text files and compare the result, we see this
+picture:
 </para>
 
+<para><screen>
+&rootprompt;<userinput>sdiff 2-files 3-files</userinput>
+
+<![CDATA[
+ cns3g.dll                     cns3g.dll
+ iR8500sg.xpd                  iR8500sg.xpd
+ cns3gui.dll                   cns3gui.dll
+ cns3g.hlp                     cns3g.hlp
+ AUCPLMNT.DLL                | aucplmNT.dll
+                             > ucs32p.dll
+                             > tnl32.dll
+ aussdrv.dll                   aussdrv.dll
+ cnspdc.dll                    cnspdc.dll
+ aussapi.dat                   aussapi.dat
+ cns3407.dll                   cns3407.dll
+ CnS3G.cnt                     CnS3G.cnt
+ NBAPI.DLL                     NBAPI.DLL
+ NBIPC.DLL                     NBIPC.DLL
+ cns3gum.dll                 | cpcview.exe
+                             > cpcdspl.exe 
+                             > cpcqm.exe
+                             > cpcspl.dll
+                             > cfine32.dll
+                             > cpcr407.dll
+                             > Cpcqm407.hlp
+                             > cpcqm407.cnt
+                             > cns3ggr.dll
+]]>
+</screen></para>
+
 <para>
-If you get an extra page of output,  this could be due to problems
-with your job format,  or if you are generating PostScript jobs,
-incorrect setting on your printer driver on the MicroSoft client.
-For example, under Win95 there is a option:
+Don't be fooled though! Driver files for each version with identical
+names may be different in their content, as you can see from this size
+comparison:
 </para>
 
-<para><programlisting>
-  Printers|Printer Name|(Right Click)Properties|Postscript|Advanced|
-</programlisting></para>
+<para><screen>
+&rootprompt;<userinput>for i in cns3g.hlp cns3gui.dll cns3g.dll; do                  \
+           smbclient //10.160.50.8/print\$ -U 'Administrator%xxxx' \
+           -c "cd W32X86/3; dir $i; cd .. ; cd 2; dir $i";      \
+		   done</userinput>
+
+  CNS3G.HLP               A   122981  Thu May 30 02:31:00 2002
+  CNS3G.HLP               A    99948  Thu May 30 02:31:00 2002
+
+  CNS3GUI.DLL             A  1805824  Thu May 30 02:31:00 2002
+  CNS3GUI.DLL             A  1785344  Thu May 30 02:31:00 2002
+
+  CNS3G.DLL               A  1145088  Thu May 30 02:31:00 2002
+  CNS3G.DLL               A    15872  Thu May 30 02:31:00 2002
+
+</screen></para>
+
+<para>
+In my example were even more differences than shown here.  Conclusion:
+you must be very careful to select the correct driver files for each
+driver version. Don't rely on the names alone. Don't interchange files
+belonging to different driver versions.
+</para>
+</sect2>
+
+<sect2>
+<title>Samba and Printer Ports</title>
+
+<para>
+Windows NT/2000 print servers associate a port with each
+printer. These normally take the form of <filename>LPT1:</filename>,
+<filename>COM1:</filename>, <filename>FILE:</filename>, etc. Samba
+must also support the concept of ports associated with a printer. By
+default, only one printer port, named "Samba Printer Port", exists on
+a system. Samba does not really need such a "port" in order to print;
+it rather is a requirement of Windows clients.  They insist on being
+told about an available port when they request this info, otherwise
+they throw an error message at you. So Samba fakes the port
+information to keep the Windows clients happy.
+</para>
+
+<para>
+Note that Samba does not support the concept of "Printer Pooling"
+internally either. Printer Pooling assigns a logical printer to
+multiple ports as a form of load balancing or fail over.
+</para>
+
+<para>
+If you require that multiple ports be defined for some reason or
+another (<quote>My users and my Boss should not know that they are
+working with Samba</quote>),  possesses a
+<parameter>enumports command</parameter> which can be used to define
+an external program that generates a listing of ports on a system.
+</para>
+</sect2>
+
+<sect2>
+<title>Avoiding the most common Misconfigurations of the Client Driver</title>
+
+<para>
+So - printing works, but there are still problems. Most jobs print
+well, some don't print at all. Some jobs have problems with fonts,
+which don't look good at all. Some jobs print fast, and some are
+dead-slow. We can't cover it all; but we want to encourage you to read
+the little paragraph about "Avoiding the wrong PostScript Driver
+Settings" in the CUPS Printing part of this document.
+</para>
+</sect2>
+</sect1>
+
+<sect1>
+<title>The Imprints Toolset</title>
+
+<para>
+The Imprints tool set provides a UNIX equivalent of the
+Windows NT Add Printer Wizard. For complete information, please
+refer to the Imprints web site
+at<ulink url="http://imprints.sourceforge.net/">http://imprints.sourceforge.net/</ulink>
+as well as the documentation included with the imprints source
+distribution. This section will only provide a brief introduction
+to the features of Imprints.
+</para>
+
+<formalpara><title>Attention! Maintainer required</title>
+
+<para>
+Unfortunately, the Imprints toolset is no longer maintained. As of
+December, 2000, the project is in need of a new maintainer. The most
+important skill to have is decent perl coding and an interest in
+MS-RPC based printing using Samba. If you wish to volunteer, please
+coordinate your efforts on the samba-technical mailing list. The
+toolset is still in usable form; but only for a series of older
+printer models, where there are prepared packages to use. Packages for
+more up to date print devices are needed if Imprints should have a
+future.</para></formalpara>
+
+<sect2>
+<title>What is Imprints?</title>
 
 <para>
-that allows you to choose if a Ctrl-D is appended to all jobs.
-This is a very bad thing to do, as most spooling systems will
-automatically add a ^D to the end of the job if it is detected as
-PostScript.  The multiple ^D may cause an additional page of output.
+Imprints is a collection of tools for supporting these goals:
 </para>
 
+<itemizedlist>
+<listitem><para>Providing a central repository information regarding
+Windows NT and 95/98 printer driver packages</para></listitem>
+
+<listitem><para>Providing the tools necessary for creating the
+Imprints printer driver packages.</para></listitem>
+
+<listitem><para>Providing an installation client which will obtain
+printer drivers from a central internet (or intranet) Imprints Server
+repository and install them on remote Samba and Windows NT4 print
+servers.</para></listitem>
+</itemizedlist>
 </sect2>
 
 <sect2>
-<title>Raw PostScript printed</title>
+<title>Creating Printer Driver Packages</title>
 
 <para>
-This is a problem that is usually caused by either the print spooling
-system putting information at the start of the print job that makes
-the printer think the job is a text file, or your printer simply
-does not support PostScript.  You may need to enable 'Automatic
-Format Detection' on your printer.
+The process of creating printer driver packages is beyond the scope of
+this document (refer to Imprints.txt also included with the Samba
+distribution for more information). In short, an Imprints driver
+package is a gzipped tarball containing the driver files, related INF
+files, and a control file needed by the installation client.
 </para>
+</sect2>
+
+<sect2>
+<title>The Imprints Server</title>
 
+<para>
+The Imprints server is really a database server that may be queried
+via standard HTTP mechanisms. Each printer entry in the database has
+an associated URL for the actual downloading of the package. Each
+package is digitally signed via GnuPG which can be used to verify that
+package downloaded is actually the one referred in the Imprints
+database. It is strongly recommended that this security check
+<emphasis>not</emphasis> be disabled.
+</para>
 </sect2>
 
 <sect2>
-<title>Advanced Printing</title>
+<title>The Installation Client</title>
+
+<para>
+More information regarding the Imprints installation client is
+available in the <filename>Imprints-Client-HOWTO.ps</filename> file
+included with the imprints source package.
+</para>
+
+<para>
+The Imprints installation client comes in two forms.
+</para>
+<itemizedlist>
+<listitem><para>a set of command line Perl scripts</para></listitem>
+
+<listitem><para>a GTK+ based graphical interface to the command line Perl
+scripts</para></listitem>
+</itemizedlist>
+
+<para>
+The installation client (in both forms) provides a means of querying
+the Imprints database server for a matching list of known printer
+model names as well as a means to download and install the drivers on
+remote Samba and Windows NT print servers.
+</para>
+
+<para>
+The basic installation process is in four steps and perl code is
+wrapped around smbclient and rpcclient
+</para>
+
+<itemizedlist>
+	<listitem><para>
+	foreach (supported architecture for a given driver) 
+	<orderedlist>
+		<listitem><para>rpcclient: Get the appropriate upload directory on the remote server</para></listitem>
+		<listitem><para>smbclient: Upload the driver files</para></listitem>
+		<listitem><para>rpcclient: Issues an AddPrinterDriver() MS-RPC</para></listitem>
+	</orderedlist>
+	</para></listitem>
+
+	<listitem><para>rpcclient: Issue an AddPrinterEx() MS-RPC to actually create the printer</para></listitem>
+</itemizedlist>
+
+<para>
+One of the problems encountered when implementing the Imprints tool
+set was the name space issues between various supported client
+architectures. For example, Windows NT includes a driver named "Apple
+LaserWriter II NTX v51.8" and Windows 95 calls its version of this
+driver "Apple LaserWriter II NTX"
+</para>
+
+<para>
+The problem is how to know what client drivers have been uploaded for
+a printer. An astute reader will remember that the Windows NT Printer
+Properties dialog only includes space for one printer driver name. A
+quick look in the Windows NT 4.0 system registry at
+</para>
+
+<para><filename>
+ HKLM\System\CurrentControlSet\Control\Print\Environment
+</filename></para>
+
+<para>
+will reveal that Windows NT always uses the NT driver name.  This is
+ok as Windows NT always requires that at least the Windows NT version
+of the printer driver is present. However, Samba does not have the
+requirement internally. Therefore, how can you use the NT driver name
+if is has not already been installed?
+</para>
+
+<para>
+The way of sidestepping this limitation is to require that all
+Imprints printer driver packages include both the Intel Windows NT and
+95/98 printer drivers and that NT driver is installed first.
+</para>
+</sect2>
+</sect1>
+
+<sect1>
+<title>Add Network Printers at Logon without User Interaction</title>
+
+<para>
+The following MS Knowledge Base article may be of some help if you
+need to handle Windows 2000 clients: <emphasis>How to Add Printers
+with No User Interaction in Windows 2000.</emphasis> ( <ulink
+url="http://support.microsoft.com/default.aspx?scid=kb;en-us;189105">http://support.microsoft.com/default.aspx?scid=kb;en-us;189105</ulink>
+). It also applies to Windows XP Professional clients.
+</para>
+
+<para>
+The ideas sketched out below are inspired by this article. It
+describes a commandline method which can be applied to install
+network and local printers and their drivers. This is most useful
+if integrated in Logon Scripts. You can see what options are
+available by typing in a command prompt ("DOS box") this:
+</para>
+
+<para><userinput>rundll32 printui.dll,PrintUIEntry /?</userinput></para>
+
+<para>
+A window pops up which shows you all of the commandline switches
+available. An extensive list of examples is also provided.  This is
+only for Win 2k/XP. It doesn't work on WinNT. WinNT has probably some
+other tools in the respective Resource Kit. Here is a suggestion about
+what a client logon script might contain, with a short explanation of
+what the lines actually do (it works if 2k/XP Windows clients access
+printers via Samba, but works for Windows-based print servers too):
+</para>
+
+<para><screen>
+<userinput>rundll32 printui.dll,PrintUIEntry /dn /n "\\sambacupsserver\infotec2105-IPDS" /q</userinput>
+<userinput>rundll32 printui.dll,PrintUIEntry /in /n "\\sambacupsserver\infotec2105-PS"</userinput>
+<userinput>rundll32 printui.dll,PrintUIEntry /y /n "\\sambacupsserver\infotec2105-PS"</userinput>
+</screen></para>
+
+<para>
+Here is a list of the used commandline parameters: 
+</para>
+
+<variablelist>
+<varlistentry><term>/dn</term>
+<listitem><para>deletes a network printer</para></listitem>
+</varlistentry>
+<varlistentry><term>/q</term>
+<listitem><para>quiet modus</para></listitem>
+</varlistentry>
+<varlistentry><term>/n</term>
+<listitem><para>names a printer</para></listitem>
+</varlistentry>
+<varlistentry><term>/in</term>
+<listitem><para>adds a network printer connection</para></listitem>
+</varlistentry>
+<varlistentry><term>/y</term>
+<listitem><para>sets printer as default printer</para></listitem>
+</varlistentry>
+</variablelist>
+
+<para>
+I have tested this with a Samba 2.2.7a and a Samba-3alpha24
+installation and Windows XP Professional clients. Note that this
+specific command set works with network print queues (installing
+local print queues requires different parameters, but this is of no
+interest here).
+</para>
+
+<itemizedlist>
+<listitem><para>Line 1 deletes a possibly existing previous network
+printer <emphasis>infotec2105-IPDS</emphasis> (which had used native
+Windows drivers with LPRng that were removed from the server which was
+converted to CUPS). The <command>/q</command> at the end eliminates
+"Confirm" or error dialog boxes popping up. They should not be
+presented to the user logging on.</para></listitem>
+
+<listitem><para>Line 2 adds the new printer
+<emphasis>infotec2105-PS</emphasis> (which actually is same physical
+device but is now run by the new CUPS printing system and associated
+with the CUPS/Adobe PS drivers). The printer and its driver
+<emphasis>must</emphasis> have been added to Samba prior to the user
+logging in (e.g. by a procedure as discussed earlier in this chapter,
+or by running <command>cupsaddsmb</command>). The driver is now
+auto-downloaded to the client PC where the user is about to log
+in.</para></listitem>
+
+<listitem><para>Line 3 sets the default printer to this new network
+printer (there might be several other printers installed with this
+same method and some may be local as well -- so we decide for a
+default printer). The default printer selection may of course be
+different for different users.</para></listitem>
+</itemizedlist>
+
+<para>
+Note that the second line only works if the printer
+<emphasis>infotec2105-PS</emphasis> has an already working print queue
+on "sambacupsserver", and if the printer drivers have successfully been
+uploaded (via <command>APW</command> ,
+<command>smbclient/rpcclient</command> or
+<command>cupsaddsmb</command>) into the
+<parameter>[print$]</parameter> driver repository of Samba. Also, some
+Samba versions prior to version 3.0 required a re-start of smbd after
+the printer install and the driver upload, otherwise the script (or
+any other client driver download) would fail.
+</para>
 
 <para>
-Note that you can do some pretty magic things by using your
-imagination with the "print command" option and some shell scripts.
-Doing print accounting is easy by passing the %U option to a print
-command shell script. You could even make the print command detect
-the type of output and its size and send it to an appropriate
-printer.
+Since there no easy way to test for the existence of an installed
+network printer from the logon script, the suggestion is: don't bother
+checking and just allow the deinstallation/reinstallation to occur
+every time a user logs in; it's really quick anyway (1 to 2 seconds).
 </para>
 
+<para>
+The additional benefits for this are:
+</para>
+
+<itemizedlist>
+<listitem><para>It puts in place any printer default setup changes
+automatically at every user logon.</para></listitem>
+
+<listitem><para>It allows for "roaming" users' login into the domain from
+different workstations.</para></listitem>
+</itemizedlist>
+
+<para>
+Since network printers are installed per user this much simplifies the
+process of keeping the installation up-to-date. The extra few seconds
+at logon time will not really be noticeable. Printers can be centrally
+added, changed, and deleted at will on the server with no user
+intervention required on the clients (you just need to keep the logon
+scripts up to date).
+</para>
+</sect1>
+
+<sect1>
+<title>The <command>addprinter</command> command</title>
+
+<para>
+The <command>addprinter</command> command can be configured to be a
+shell script or program executed by Samba. It is triggered by running
+the APW from a client against the Samba print server. The APW asks the
+user to fill in several fields (such as printer name, driver to be
+used, comment, port monitor, etc.). These parameters are passed on to
+Samba by the APW. If the addprinter command is designed in a way that
+it can create a new printer (through writing correct printcap entries
+on legacy systems, or execute the <command>lpadmin</command> command
+on more modern systems) and create the associated share in
+, then the APW will in effect really
+create a new printer on Samba and the UNIX print subsystem!
+</para>
+</sect1>
+
+<sect1>
+<title>Migration of "Classical" printing to Samba-3</title>
+
+<para>
+The basic "NT-style" printer driver management has not changed
+considerably in 3.0 over the 2.2.x releases (apart from many small
+improvements). Here migration should be quite easy, especially if you
+followed previous advice to stop using deprecated parameters in your
+setup. For migrations from an existing 2.0.x setup, or if you
+continued "Win9x-style" printing in your Samba 2.2 installations, it
+is more of an effort. Please read the appropriate release notes and
+the HOWTO Collection for 2.2. You can follow several paths.  Here are
+possible scenarios for migration:
+</para>
+
+<itemizedlist>
+<listitem><para>You need to study and apply the new Windows NT printer
+and driver support. Previously used parameters "<parameter>printer
+driver file</parameter>", " <parameter>printer driver</parameter>" and
+"<parameter>printer driver location</parameter>" are no longer
+supported.</para></listitem>
+
+<listitem><para>If you want to take advantage of WinNT printer driver
+support you also need to migrate the Win9x/ME drivers to the new
+setup.</para></listitem>
+
+<listitem><para>An existing <filename>printers.def</filename> file
+(the one specified in the now removed parameter <parameter>printer
+driver file = ...</parameter>) will work no longer with Samba-3.0. In
+3.0, smbd attempts to locate a Win9x/ME driver files for the printer
+in <parameter>[print$]</parameter> and additional settings in the TDB
+and only there; if it fails it will <emphasis>not</emphasis> (as 2.2.x
+used to do) drop down to using a <filename>printers.def</filename>
+(and all associated parameters). The make_printerdef tool is removed
+and there is no backwards compatibility for this.</para></listitem>
+
+<listitem><para>You need to install a Windows 9x driver into the
+<parameter>[print$]</parameter> share for a printer on your Samba
+host. The driver files will be stored in the "WIN40/0" subdirectory of
+<parameter>[print$]</parameter>, and some other settings and info go
+into the printing-related TDBs.</para></listitem>
+
+<listitem><para>If you want to migrate an existing
+<filename>printers.def</filename> file into the new setup, the current
+only solution is to use the Windows NT APW to install the NT drivers
+and the 9x drivers. This can be scripted using smbclient and
+rpcclient. See the Imprints installation client at:
+</para>
+
+<para>
+<ulink url="http://imprints.sourceforge.net/"><emphasis>http://imprints.sourceforge.net/</emphasis></ulink>
+</para>
+
+<para>
+for an example. See also the discussion of rpcclient usage in the
+"CUPS Printing" section.</para></listitem>
+</itemizedlist>
+</sect1>
+
+<sect1>
+<title>Publishing Printer Information in Active Directory or LDAP</title>
+
+<para>
+We will publish an update to this section shortly.
+</para>
+</sect1>
+
+<sect1>
+<title>Common Errors and Problems</title>
+
+<para>
+Here are a few typical errors and problems people have
+encountered. You can avoid them. Read on.
+</para>
+
+<sect2>
+<title>I give my root password but I don't get access</title>
+
+<para>
+Don't confuse the root password which is valid for the Unix system
+(and in most cases stored in the form of a one-way hash in a file
+named <filename>/etc/shadow</filename>) with the password used to
+authenticate against Samba!. Samba doesn't know the UNIX password; for
+root to access Samba resources via Samba-type access, a Samba account
+for root must be created first. This is often done with the
+<command>smbpasswd</command> command.
+</para>
 </sect2>
 
 <sect2>
-<title>Real debugging</title>
+<title>My printjobs get spooled into the spooling directory, but then get lost</title>
 
 <para>
-If the above debug tips don't help, then maybe you need to bring in
-the bug guns, system tracing. See Tracing.txt in this directory.
+Don't use the existing Unix print system spool directory for the Samba
+spool directory. It may seem convenient and a saving of space, but it
+only leads to problems. The two <emphasis>must</emphasis> be separate.
 </para>
+
 </sect2>
 </sect1>