[THIN] Re: Printer Hell
- From: "Rick Mack" <ulrich.mack@xxxxxxxxx>
- To: thin@xxxxxxxxxxxxx
- Date: Sat, 3 Feb 2007 13:09:45 +1000
Hi Mike,
I wasn't game to add anything extra to that too long post.
The reason for the write access to
%systemroot%\system32\spool\drivers\w32x86\3 is actually not that hard.
The Microsoft unidriver mechanism uses a graphics driver definition file,
*.gpf for graphics printers and postscript definition files, *.pdf for
Postscript printers. These are text files that basically define the printer
capabilities and escape sequences etc that the printer uses to change fonts,
font sizes and just about everything else.
Before you can use a unidriver printer driver the spooler has to "compile"
the .gpd file into a .bud file ( and .pdf to .bpd). The .bud file also
includes either time/date stamps or checksums of all the driver components.
HP unidriver-based printer drivers use a master.gpd file, and also a bunch
of "include" .gpd files for common HP printer driver components. All of
these .gpd files are compiled into the .bud file.
We had a lovely time with a customer that had about 170 print queues (all
HP) and about 20 Citrix servers. Things were stable and working well until
one day they got a new HP printer. Since we'd drummed into them to test all
printer drivers before rolling them into production, they did.
The printer driver was fine, but what happened afterwards wasn't.
Multiple printers didn't work anymore, but when a user called up to say they
couldn't print, an admin would log on to the same server, try and print,
successfully, and then users could print to that printer. The next day the
user would log on to another server and couldn't print again. So an admin
would log on to test the server and things worked after that. That went on
for 3 days, 800 users, about 40 affected printer queues and more helpdesk
calls than I prefer to think about 'tli we figured out what was happening.
The new driver installation updated most of the include .gpd files and it
turns out that when any of a driver's components are updated the .bud file
has to recompiled before you can use the driver. But when a non-admin user
tried to use a printer driver that needed recompilation, they didn't have
write access to %systemroot%\system32\spool\drivers\w32x86\3 so the compile
didn't happen. When an admin tried to do the same thing the compile worked,
the .bud file was created and printing worked, for that server.
When we gave users write access to
%systemroot%\system32\spool\drivers\w32x86\3 the compiles all worked and the
problems went away and I've never seen that issue since.
So that's why I give users write access to
%systemroot%\system32\spool\drivers\w32x86\3.
regards,
Rick
---
Ulrich Mack
Commander Australia
On 2/3/07, Mike MacDonald <mike5287@xxxxxxxxx> wrote:
Rick
Mega-humongous-thanks for the informative post - I greatly appreciate
it! First off, with about 90% thin clients in the office, we are stuck with
network printing. I had looked several years ago at 3rd party and didn't go
with them because of that. While it would help in some situations, our
primary concern is network printing. And I see about 8 drivers at quick
glance that exist on your bad list and on our servers :(
I am going to have to read up on the "why" behind the write permissions in
%systemroot%\system32\spool\drivers\w32x86\3 permissions, but I just checked
and users currently have read-only access. Something I will remedy on
Monday. You are right about the trusted driver source because the client
support folks who setup the printers are able to install drivers on the
print servers that are trusted sources - too many people doing too many
things unchecked has made for a collosal mess.
The part that is most confusing to me is that for about a year everything
was fine. Then something changed where all of a sudden client print drivers
were getting installed. In CMC the policy was (and is) there and set to not
automatically install drivers - yet they do get installed - even by
non-admins. I cleaned up drivers on one server Monday and double checked the
policy was set correctly, and by Weds 27 new drivers got installed - none of
them by admins. I can only assume a Microsoft update or client change
occurred to cause this to start happening. Even now the only way I have been
able to stop new drivers, even after checking policies, was to rename the
ntprint.inf. I am going through everything related to this again to make
sure nothing got changed but thus far have found nothing.
Again - thanks for the time to post your reply. I have a test server and I
will be going through every driver we have with the addprinter utility as
well as using it to test all new drivers. I will also be doing the policy to
stop RDP printer autocreation when admins login to servers. Unfortunately
the hardest part is changing the drivers around which in our environment is
going to cause problems. "This app only prints correctly with PCL drivers,
and this app only with PS" type stuff. But it just needs to be done so we
can get through this ugliness and hopefully out of Printer Hell(TM)
Seriously - a big thanks to Rick, Mark Malcom, Brian and everyone for all
the help!
-Mike MacDonald
Other related posts:
