[THIN] Re: Bloody HP printer drivers
- From: "Rick Mack" <Rick.Mack@xxxxxxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Tue, 27 Jul 2004 19:42:47 +1000
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 ^| find /i "print"') do con2prt /c
\\printserver\%i
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 /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:
