[THIN] Re: Bloody HP printer drivers
- From: "Jeff Stockard" <jstockard@xxxxxxxxxxxxxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Tue, 27 Jul 2004 14:51:47 -0400
Could this issue be resolved by giving the everyone group Read / Write
permissions on the Spool\drivers\w32x86 directory? I know in earlier
versions, we added the everyone permissions to the spool\printers
folder.
Thank you, for the heads up!
Jeff
Jesus loves you
-----Original Message-----
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On
Behalf Of Rick Mack
Sent: Tuesday, July 27, 2004 5:43 AM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Bloody HP printer drivers
Hi People,
Been having a really good run with 2003 printer-wise, until a couple of
weeks ago.
Customer started getting users complaining that they couldn't print to
some printer queues on some servers. If an admin logged on to the server
and tried printing, it worked fine, and also fixed things for other
users on that server using that printer.
Trouble is, the print failures kept cropping up on other servers and
other queues.
Tracked it down to .BUD files in the spool\drivers\w32x86\3 directory.
Before this makes sense I'll have to tell you a bit about printer driver
design in win2k/win2k3 (and XP of course).
Microsoft decided that they had to do something to make printer driver
development etc both easier and more stable.
The way they achieved this was to borrow what they'd done on NT 4.0 with
postscript printers. With the exception of some maverick drivers (Xerox,
Adobe), most postscript drivers used the native postscript engine, and
PPD (postscript printer definition) files. So the only part of the
driver that was printer specific was a text description file that was
compiled into a binary format (.BPD) when the printer was used the first
time on a system.
In win2k etc, "most" enterprise drivers also use a text printer
definition file .GPD which describes the escape sequences etc needed to
make the printer change fonts, paper trays etc etc, plus one or more
resource DLLs which have printer graphics and fancy features added by
overachieving printer driver developers. The printer engine, unidrv.dll
(Universal Driver engine), uses the GPD file compiled into a binary
printer description file (BUD file) for faster execution.
So the first time I use a particular printer driver, the spooler will
compile its GPD file into a BUD file in spool\drivers\w32x86\3 and life
is sweet.
Unfortunately if I'm a non-admin user and the drivers\w32x86\3 directory
is super locked down, we have a problem. But all it needs is an admin
using the printer or just connecting to a network shared printer using
that driver and the BUD file is created and things work.
So why were we suddenly having BUD file issues?
The more complex drivers (HP) use external include files with their GPD
file. So in addition to the printer driver GPD file, the driver also
uses a bunch of shared *.GPD files that are basically common code macro
files. Normally the spooler will only try to recompile an existing
printer driver's GPD file if the GPD file changes (create date changes).
But it will also insist on recompiling the GPD file if any of the
include GPD files change!!!!
So if my customer added a new printer driver from HP that updated ANY of
the include macros, this started a snowball effect that meant every
other HP driver using that macro will have to have its GPD file
recompiled to a BUD file before users can use that driver. The end
result is controlled chaos as users on multiple servers can't print to
multiple network printers.
The fix?
A quick hack that mounts all posssible network printers on one of the
farm's TS servers, and then propagates the drivers directory changes to
other servers on the farm, eg
for /f %i in ('net view \\printserver <file:///\\printserver> ^| find
/i "print"') do con2prt /c \\printserver\%i <file:///\\printserver\%25i>
and of course:
for /f %i in ('qfarm /load ^| find /i "common part of server name"') do
robocopy %systemroot%\system32\spool\drivers\w32x86\3
\\%i\admin$\system32\spool\drivers\w32x86\3
<file:///\\%25i\admin$\system32\spool\drivers\w32x86\3> /s /e /w:0 /r:0
I guess the moral of the story is what idiot wants super locked down
printer drivers anyway! :-(
regards,
Rick
Ulrich Mack
rmack@xxxxxxxxxxxxxx
Volante Solutions
18 Heussler Terrace, Milton 4064
Queensland Australia.
tel +61 7 3246 7777
_____
This e-mail, including all attachments, may be confidential or
privileged. Confidentiality or privilege is not waived or lost because
this email has been sent to you in error. If you are not the intended
recipient any use, disclosure or copying of this email is prohibited.
If you have received it in error please notify the sender immediately by
reply email and destroy all copies of this email and any attachments.
All liability for direct and indirect loss arising from this email and
any attachments is hereby disclaimed to the extent permitted by law.
_____
Other related posts:
