[THIN] Re: Printer Hell
- From: "Bob Coffman Jr - Info From Data " <bcoffman@xxxxxxxxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Mon, 5 Feb 2007 14:16:34 -0500
My understanding is that certain "odd" printers won't work with UPD... And
you need to be on version 9.x of the ICA Client.
-----Original Message-----
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of Schneider, Chad M
Sent: Monday, February 05, 2007 1:20 PM
To: 'thin@xxxxxxxxxxxxx'
Subject: [THIN] Re: Printer Hell
Set to auto-create and use UPD only.
_____
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of Joe Shonk
Sent: Monday, February 05, 2007 11:45 AM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Printer Hell
Are these users using older ICA clients?
Joe
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of Schneider, Chad M
Sent: Monday, February 05, 2007 10:40 AM
To: 'thin@xxxxxxxxxxxxx'
Subject: [THIN] Re: Printer Hell
Has anyone noted that even using the UPD (should keep me from needing native
drivers), I sometimes have to install the true printer driver, or the UPD
created printer will either not work, or simply not create?
_____
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of Mike MacDonald
Sent: Monday, February 05, 2007 10:53 AM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Printer Hell
For those interested....The vbscript that Rick posted will only work on
Windows 2003 (and Longhorn) servers because the WIN32_PRINTERDRIVER class
isn't present on Windows 2000 (
<http://msdn2.microsoft.com/en-us/library/aa394366.aspx>
http://msdn2.microsoft.com/en-us/library/aa394366.aspx). You can however use
the WIN32_PRINTER class. Here is code that will work on W2K and W2K3:
------ start listdriversw2k.vbs -------
'listdriversw2k.vbs - Lists all installed printer drivers on the local
server
strComputer = "."
Set objWMIService = GetObject( _
"winmgmts:" & "{impersonationLevel=impersonate}!\\" _
& strComputer & "\root\cimv2")
Set colInstalledPrinters = objWMIService.ExecQuery _
("Select * from Win32_Printer")
For Each objPrinter in colInstalledPrinters
wscript.Echo objPrinter.DriverName
Next
------ end listdriversw2k.vbs -------
Thanks again to Rick for the help.
-Mike
On 2/2/07, Rick Mack <ulrich.mack@xxxxxxxxx> wrote:
Hi Mike,
The main attraction of third party printing solutions is that they sharrply
restrict the number of printer drivers you've got on your systems. Aside
from that, they aren't any better or worse than what Citrix already have for
you.
Now that Citrix have got most of the bugs out of their UPD solution, the one
real weakness left is the support for session network printers and the need
to support the odd application that does it own thing with regard to
printing and just passes a raw spool job to the spooler subsystem.
I can turn a "good" scenario into a bad one just by ticking a single box in
the CMC, the one that controls if the client printer is a network printer
and I know about it, create a network printer in the session instead of
printing via the ICA client (and UPD). And it doesn't matter if I've got a
trusted printer driver source or anything else because the trusted source
probably has bad drivers.
Supporting network printers means installing drivers, and with HP at the top
of the list, there are some really, really bad printer drivers out there
(see below). They work okay in a single user environment, but just don't
handle a multi-user environment terribly well and will hang or crash the
spooler subsystem and the Citrix print manager service.
Symptoms are handle leaks in the cpsvc, login hangs running cmstart, all
sorts of printer creation and assignment problems, a crashed spooler, failed
RPC service, toasted servers. Great stuff.
And do third party solution solve this problem? They sure do.
Toss out all the bad drivers, don't use network printers, only use a UPD and
printing is stable and reliable. Move the whole overhead for printing on to
a print server (eg Thinprint VC gateway) and life is wonderful.
But that doesn't mean you have to go for third party printing solutions.
Believe it or not, but you can actually make your Citrix printing reliable
as well. Even when things have gone to hell.
One of the things I do to "tune" our sites is to apply an unmanaged group
policy that does something really simple, it stops RDP printer autocreation
when admins log on to servers. Because if you don't do that, and you haven't
disabled printer remapping in the RDP client configuration, then RDP printer
autocreation can suck the printer drivers off your workstation, laptop or
home computer and install them on your servers. Every time you attach to a
network print queue because you want to print something while logged on as
an admin, you suck drivers across on to your servers.
Create a Citrix policy as well for admins only that prevents printer
autocreation. Because admins are the most likely source of rogue drivers.
Most of the default printer driver restrictions apply to non-admins so if
things go bad, guess who's responsible? Probably you or me, the admins. Not
Citrix.
Anyway, I hope I've made the point about who is most often guilty when
things go bad. But stay tuned 'cause printer hell isn't all our fault.
As an aside, the other thing you HAVE to do if you're supporting network
printers, is to give users write access to the
%systemroot%\system32\spool\drivers\w32x86\3 folder. If you don't,
introducung new (mostly HP) printer drivers to your farm is going to cause
all sorts of interesting problems with other drivers, even when they're
"good" drivers. It'd take too long to explain but you really need to do
this.
Of course if you set things up to just use the UPD (we're talking PS4 UPD
here), you've just avoided a whole stack of problems, even if it isn't the
most efficient way to go.
Anyway, I'd better finish this up.
Since Citrix released AddPrinter, we've been cleaning up printing problems
on all our customer sites. All AddPrinter does is create a bunch of printer
queues using the driver being tested. It simulates a worst case scenario
where you have a few users creating a printer at the same time. No rocket
science but it's a real life saver becauae it'll show you what's causing
your printer hell.
Most of the time it's HP.
I had a lot of issues with HP printer drivers a few years ago, (remember the
Stop 0x1E and stop 0x50 bluescreens?) and got to know the guys at HP pretty
well. They really cleaned up their act and I guess I just assumed, stupidly,
that if it was HP it was terminal server friendly. I used to bag Xerox
because they were using so many kernel mode drivers, but it's not Xerox on
my hit list these days because it's been a real eye opener to see just how
bad some of the HP drivers are.
If you try testing the HP LaserJet 8150 driver with AddPrinter, as an
example, it'll crash the spooler almost instantly. And that's not the worst
one because that's a clean death and only effects the spooler. If you set
the spooler to auto restart, you hardly notice. Of course there are a lot of
instances of HPBOID.exe running on the server but at least it's not really
broken. It's the HP drivers that cause memory leaks and memory corruption
that really hurt because they'll eventually toast your server.
Check out CTX111947 (Intermittent Client Printer Autocreation Failures) for
what I now consider to be a partial list of the bad drivers:
. HP Color LaserJet 4600
. HP LaserJet 4200
. HP LaserJet 4300
. HP Color LaserJet 4550
. HP Color LaserJet 5500
. HP Color LaserJet 8550
. HP LaserJet 4100
. HP LaserJet 5100
. HP LaserJet 8150
. HP LaserJet 9000
. HP Color LaserJet 2500
. HP LaserJet 2300
. HP Color LaserJet 5550
. HP Color LaserJet 9500
. HP Color LaserJet 9500 MFP
. HP LaserJet 2410/2420/2430
. HP LaserJet 4250
. HP LaserJet 4345 mfp
. HP LaserJet 4350
. HP LaserJet 9050
. HP LaserJet 9050/9040 MFP
. HP LaserJet 9055 MFP
. HP LaserJet 9065 MFP
. HP Color LaserJet 2800 Series
. HP Color LaserJet 3000
. HP Color LaserJet 3600
. HP Color LaserJet 4700
. HP Color LaserJet 4730 mfp
. HP ColorLaserJet 3800
. HP LaserJet 5200/5200L
. HP Color LaserJet 3700
. HP Color LaserJet 4650
. HP Color LaserJet 3550
There are more.
We've gone to the trouble of cleaning up all the bad drivers in a farm, and
something marvellous has happened. Printing just works reliably.
Testing all your printer drivers is easy. But a word of warning, don't try
using AddPrinter on a production server with users logged on. The experience
won't win you any friends.
All you need is some way of listing all the printer drivers on a server. The
following VB script is a pretty simple way to do it.
------ start listdrivers.vbs -------
' listdrivers.vbs - list all installed printer drivers
DIM DrvArray
strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel = impersonate}!\\" & strComputer & "\root\cimv2")
Set colInstalledPrinters = objWMIService.ExecQuery _
("Select * from Win32_PrinterDriver")
For each objPrinter in colInstalledPrinters
DrvArray = split(objPrinter.Name,",")
Wscript.Echo DrvArray(0)
Next
----- end listdrivers.vbs -------
Run "vbscript //nologo listdrivers.vbs > drivers.txt" and you've got a list
of drivers.
A single command will now do your testing:
for /f "delims=:" %i in (drivers.lst) do @echo %i >> addprinters.log &
addprinter - name test -driver "%i" -conc 5 -iter 10 - port lpt1: -delay 500
| find /v "%%" >> addprinters.log 2>&1
Note: If you cut and paste this, the quotes ["] may not come across properly
and the script will generate an addprinter error. Replace the quotes and it
will work.
Things aren't completely straightforward because some of the drivers will
crash the spooler, so you'll have to shepherd the testing and restart the
spooler (or the server) and edit drivers.txt to restart the testing past the
bad driver. It'll take some time as well.
When you look at the log, thread wait errors mean the driver is probably
okay (but why risk it) and hard errors mean get rid of that driver. RPC
server errors mean the previous driver crashed the spooler and you'll have
to restart with that driver removed from drivers.txt. At the end of the
execise you'll have a list of bad, suspect and passed (I almost said good,
but that's be lying) drivers.
On average we've had to replace about 10-15% of the drivers being used in a
farm. You have to start with upgrading/modifying the printer driver on the
file server(s) and then propagate the updated driver to your terminal
servers. Once you've finished cleaning up the printer drivers, your problems
are nearly over.
You've still got the occasional orphaned print job (print job queued to
autocreated client printer on client no longer conected) that will cause
problems, but you've just gotten rid of the bulk of your printing problems.
regards,
Rick
--
Ulrich Mack
Commander Australia
Other related posts:
