Univention Bugzilla – Bug 37148
some printer drivers do not work in S4 printserver environments
Last modified: 2015-08-06 18:08:04 CEST
Reported at 2014120121000384. Current Triumph-Adler drivers <http://www.triumph-adler.de/C125712200447418/vwLookupDownloads/KxDriver_cCD_cLP_20141029.zip/$FILE/KxDriver_cCD_cLP_20141029.zip> seem not to wokr with printservers in S4 environments. After successfully uploading and installing these driers without any issue, you cannot print with these printers - at windows 7 you'll receive "Fehler 0x00000006" - W2k12 mentions "invalid handle". In a native AD printserver environment this works.
Created attachment 6491 [details] log.smbd - debug level 12 See debug level 12 logs from a testpage print attatched - printernam is "drucker".
Created attachment 6495 [details] debug information for the S4 environment This tarball contains the following: debugging/log.samba debugging/log.nmbd debugging/log.smbd debugging/samba_printer.pcapng debugging/samba_printer.tcpdump Debuglevel: 12 pcapng is client side trace, tcpdump is server side trace. It contains the following steps: 1. Uploading driver 2. Installing driver 3. Testprint with resulting failure 0000x6
direct customer info: "Wenn man bei den gewissen Triumph Adler Drucker Treibern in den Eigenschaften -> Geräteeinstellungen die Druckersprache mal auf was anderes als "PCL XL" stellt, dann geht das Drucken. Kömischerweise habe ich es dann wieder zurück gestellt und es geht immer noch"
Google search for 0x00000006 shows that this is a common issue with Windows printer drivers and nothing Samba specific. I can reproduce the problem and the workaround described here but I cannot see any relevant server side changes comparing "not working" with "working" printer shares. There is a workround, and it's documented here, I guess that's all we can do now.
(In reply to Arvid Requate from comment #4) > Google search for 0x00000006 shows that this is a common issue with Windows > printer drivers and nothing Samba specific. I can reproduce the problem and > the workaround described here but I cannot see any relevant server side > changes comparing "not working" with "working" printer shares. There is a > workround, and it's documented here, I guess that's all we can do now. If I know it correctly, the workaround doesn't work with the current Samba version. Does it also happen with a Microsoft based AD server?
It works with 2:4.2.0~rc2-1. I'll check again against Windows and 4.2.2.
* On a Windows 2003 driver installation fails completely * Printing from Windows 7 to a Windows 2008 R2 printer worked (intially I had a different error popup, but that vanished after configuring a real printer as backend instead of a file). * Checked again with UCS 4.0-2 (Samba 2:4.2.0~rc2-1.729.201503191909) but without server side printer driver storage: Created a printer share on UCS, installed the driver directly on the Windows client, print Testpage -> Error 0x00000006. So this has nothing to do with server side printer driver distribution. * Checked locally on the Windows 7 client which registry keys get added when trying to print the intial Testpage: ============================================================================= 1. Key: HKLM\SOFTWARE\Kyocera Mita\Shared Files -> "Install Path" Value: \\CSR|master50\{$SOME_UUID} ## This UUID gets modified 2. Key: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering\Servers\master50\Monitors\Client Side Port\{$SOME_UUID} -> "PrinterPath" Value: \Users\S-1-5-21-<domain part>-500\Printers\^\^\master50^\drucker0 3. Key: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering\Servers\master50\Printers\{$SOME_UUID} [and subkeys] ( The last two structures are also present below HKLM\SOFTWARE\Wow6432Node ) ============================================================================= Switching the printer protocol from PCL XL to PCL 5e and back again removes the UUID-specific structures and writes a new one to the Kyocera Mita\Shared Files -> "Install Path". The workarounds found in the internet also deal with removing these registry keys, but that alone (and restarting the spooler service) didn't fix the issue for me. Not that this is again an issue of a Kyocera driver, we had issues with other Kyocera drivers earlier (Bug 32771).
Created attachment 7011 [details] PrinterDriverData.reg This registry key on the Samba server makes all the difference: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers\drucker1\PrinterDriverData It contains three values ("KcFontSubW", "Setup", "Setup_Copy") of type REG_BINARY. So: When I create the printer and assign the driver (client side) I have the error. When I then add these registry values on the samba server via remote regedit, printing the testpage works. When I remove them again I have the error again. Now we have some foundation to work on. I'll check the Samba logs for a) initial driver assignment and b) performing the workaround above (or wherever these registry keys get created).
Created attachment 7012 [details] PrinterDriverData.txt Actually it's the value of "Setup" which seems to be essential. The attached file is the corresponding registry data (utf-16le). I also see that the proposed workaround causes the Windows Client to write this value (and the other two) via three individual spoolss_SetPrinterData RPC calls. After removing "KcFontSubW" and "Setup_Copy" it still works, the Windows Client recreates them later somehow. The bad news is: I checked with a printer driver which is not affected by these issues (HP Universal PCL6 Printer Driver) and he doesn't have these registry values. Transplanting it's set of values to the Triumph-Adler printer didn't help, so it seems the value of "Setup" is essential.
Created attachment 7013 [details] ZeroPrinterDriverData.reg While messing around with the binary data of the "Setup" value I discovered, that the Windows client somehow fixed the data when asked to print a testpage. That brought up the idea to simply initialize this value with a reasonable number of zero bytes (see attached crafted registry file, it's for "drucker3" in this case). And <tada> the Windows client is happy, prints a test page and fixes the value. Note: Unfortunately the tools in the registry-tools package currently don't seem to be capable to set registry values, so I always had to do this remotely from the Windows Client via regedit. Now, a) how do we know when to do this hack? b) which part of the samba code can be adjusted to do this? This can be really ugly, e.g. detecting the printer driver vendor when a printer driver gets assigned via spoolss_SetPrinter rpc call and silently injecting this vendor-specific registry value.
Ok, I was able to reproduce the 0x00000006 popup with a Windows 2008R2 Server (just the server, no client required). After assigning a driver to a printer share on the native Windows print server the "PrinterDriverData" Key is properly initialized with the "Setup" value. When I manually remove this I get the error popup when trying to print a test page. The thing is, creating a printer share on a native Windows server always requires installation of a printer driver and during that installation the drivers native routines for that are executed properly. The situation is simply different on Samba, as described here: http://www.openprinting.org/download/kpfeifle/SambaPrintHOWTO/Samba-HOWTO-Collection-3.0-PrintingChapter-11th-draft.html#AEN851 Quote: ============================================================================= 6.8.2. IMPORTANT! Setting Device Modes on new Printers In order for a printer to be truly usable by a Windows NT/2K/XP client, it must possess: * a valid Device Mode generated by the driver for the printer (defining things like paper size, orientation and duplex settings), and * a complete set of PrinterDriverData generated by the driver. 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 only harvest error messages when attempting to print. Samba stores the named values and all printing related info in its internal TDB database files (ntprinters.tdb, ntdrivers.tdb, printing.tdb and ntforms.tdb). 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 PrinterDriverData 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. Be aware, that a valid Device Mode can only be initiated by a "printer admin", 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 PrinterDriverData that is needed, when they are uploaded to the [print$] share with the help of the APW or rpcclient. 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 DeviceMode to our Sanba server. You can use the native Windows NT/2K/XP printer properties page from a Window client for this: [...] ============================================================================= So, as described in that document, the "Default Devmode" is another registry value, that needs to be created by the client driver. The document describes how to "tickle" Windows printer drivers to write this value by adjusting a device setting on the "Advanced" tab of the printer settings. Likewise, the values below the "PrinterDriverData" key get written when opening the "Device Settings" tab (name may be driver specific, like "Settings" or "Configuration") and simply clicking "Ok" (no change required) and closing the whole Printer settings dialog. After that a test page can be printed. And that's what the "PCL XL"/"PCL 5e" toggling workaround essentially does. I guess we should improve documentation on this. given that experts in this field recommend this procedure for new printers.
SDB? Manual?
(In reply to Arvid Requate from comment #12) > SDB? Manual? As discussed, I would prefer the SDB.
Since I was doing QA for Bug 38136 and Bug 33000 I simply added it directly to the manual, please check, I guess it's much simpler this way. svn r62168
(In reply to Arvid Requate from comment #14) > Since I was doing QA for Bug 38136 and Bug 33000 I simply added it directly > to the manual, please check, I guess it's much simpler this way. > > svn r62168 OK, looks good. Small adjustments: r62224
r62405 | Bug #37148 doc: print service translation English translation Spelling fixes Waiting for Bug #38846 to get verified...