[THIN] Re: Bloody HP printer drivers
- From: "Rick Mack" <Rick.Mack@xxxxxxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Wed, 28 Jul 2004 06:57:01 +1000
Hi Jeff,
Yes. But then we'd have the potential problem of users being able to
install stuff, or just fiddle. Users basically dont have write accesd to
anything on the system drive but the spool\printers directory. This
works well in terms of stability, and I wouldn't trade that for
anything.
I don't view the BUD comple issue as a problem, just interesting enough
to share it with the thin list.
regards,
Rick
Ulrich Mack
Volante Systems Ltd
18 Heussler Terrace, Milton 4064
Queensland Australia.
Ph: +61 7 3246 7704
email: rmack@xxxxxxxxxxxxxx
web: www.volante.com.au
-----Original Message-----
From: thin-bounce@xxxxxxxxxxxxx
[mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of Jeff Stockard
Sent: Wednesday, 28 July 2004 4:52 AM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Bloody HP printer drivers
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.
________________________________
#####################################################################################
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:
