Univention Bugzilla – Bug 33505
Windows clients rename printer during Point'n Print driver upload to server
Last modified: 2014-12-01 12:28:55 CET
Windows clients rename the printer share while uploading Point'n Print drivers to a Samba server. This is pretty confusing for the Administrator as the usual testpage printing doesn't work in this case and the admin faces the windows error code 0x0000007a instead. Samba might offer a solution for this, as described in manpage for smb.conf: ============================================================================== When assigning a new driver to a printer on a remote Windows compatible print server such as Samba, the Windows client will rename the printer to match the driver name just uploaded. This can result in confusion for users when multiple printers are bound to the same driver. To prevent Samba from allowing the printer´s printername to differ from the sharename defined in smb.conf, set force printername = yes. ==============================================================================
Current status: This issue was raised again recently upstream https://bugzilla.samba.org/show_bug.cgi?id=10482 I tested driver upload with "force printername = yes" from a windows7 client but that consistently triggered this error message already at the point of driver upload. The advantage is that the server side printer share UNC doesn't get renamed. This is a big plus, because it avoids ending up with a broken printer share after the driver was uploaded. The drawback is this (and possibly another) ugly "false" error message getting raised to the administrator.
After some testing and research on the net it looks like the error message 0x0000007a is unrelated to the renaming of the printer. The source of this error message is unidentified yet but it's also reported in native windows domains and technet forums suggest a) an error during upload of the printer driver to the "print$" share b) a problem with the print spooler (local or remote?) c) driver files blocked via C:\Windows\inf\printupg.inf or printupg.pnf It's true that I could reproduce the problems (yet not always) with the HP Universal PS driver which contains a file "pscript5.dll" which is listed in the printupg.inf file on my Windows 7 client. The problem didn't show (yet) with the Universal PCL6 driver. I would dare to bet that this is not a Samba problem. Specifically the error code 0x0000007a does *not* seem to correlate to any of the protocol inherent WERR_INSUFFICIENT_BUFFER messages in the log.smbd. From the Microsoft provided protocol specification these seem to be regular messages occurring during response buffersize negotiations between client and server. Finally note that only the "printername" is changed by the client-sent spoolss_SetPrinter command, but the "sharename" and "uncpath" are unmodified: Before: printername: //master40/printer9 sharename: printer9 After the client assigned "Driver XYZ": printername: //master40/Driver XYZ sharename: printer9
I recommend adjusting the cups-printers.py listener module to set force printername = yes on all (added or modified) printer shares. The default for this should be configurable via UCR.
Fixed, Advisory: 2014-09-08-univention-printserver.yaml
OK - 3.2-3 OK - 4.0-0 OK - YAML
I guess it's better to make the default configurable. Now there is a UCR variable samba/force_printername , which may be set to no/false in case the new default doesn't work for somebody. Advisory adjusted to mention new UCR variable.
OK
http://errata.univention.de/ucs/3.2/202.html