No-Good Very Bad Print Server Issues: Print Server Troubleshooting Suggestions?

Question

We just replaced a fifty-year-old print server and are attempting to use HP Universal Print Driver (per their engineers' suggestion) for all of our printers (the PCL 5 4.7 version). We thought this would solve some printing problems.

However, this is not working out. We have tens of users complaining that they can't print, and they're reporting multiple issues:

• Printers that are supposed to be supported are reporting "not a supported HP device."
• Multiple people have received the "application error" dialog with an 0x error code and a debug button. (I'm trying to dig up more info on this.)
• People report a "Printer error: ENUM printer failed" dialog.

We are finding that restarting the spooler service and/or reinstalling the printer objects on these machines will resolve the problem temporarily, but they soon die again.

We have experimented with loosening permissions on the printer objects on the server but that seems to have no effect.

I tried to add a printer NOT using the Universal driver, and I'm getting this error on the server side:

And this when trying to get properties on a specific printer.

I'm starting to think there's something more going on here than a bad driver - corruption in the server install?

TL;DR:

Anyone have:

• Experience using the HP "Universal" driver in an enterprise with ~100 printers
• Suggestions for print server troubleshooting that have worked for you?

Answer 1

The desktop folk here don't like the HP Universal Driver. I believe they got burned by it several years ago shortly after it came out. They like to use per-device drivers whenever possible. So our experience with it hasn't been great. We're a university with general computing labs, so driver quality is something we really care about as we have over 1400 lab workstations and 60 printers that print between 3 to 4 million pages an academic quarter.

---

Update after experience:

Two months after I posted the above I went through the process of deploying Microsoft Print service across our entire campus of 20K students. This introduced a bunch of problems that we hadn't run into before when we were using the Novell printing solution. Our single largest problem was HP driver quality.

And it was the per-device drivers that gave us the most crap, by a large extent.

Case in point: The HP LaserJet 9050 printer.

The per-device driver for this printer was released in May, 2008. It has no explicit Server 2008 R2 support.

The HP Universal Driver was last updated within the last six months.

In our case, an interaction between some Office 2010 applications and the 2008 PCL drivers for that printer caused the printer to think a 5 page document actually printed anywhere from 700 to 2100 pages. This caused our print-auditing solution no end of grief. When we switched to the Universal driver, this problem went away. HP has never updated the device-specific driver for the 9050, so the bug remains to this day.

Second issue: Our large volume of printing meant that we were ending up with print spooler crashes once or twice a day. Recovery of the crashes required purging the entire print-queue, which can mean several hundred jobs get lost every time we did that. Crashdump analysis pointed to the HP device-specific driver. Once we moved over to the Universal Driver, this problem became a once-a-quarter phenomena.

Take-away:

HP really wants you to use the Universal Driver if you're doing centralized print-deployment with the big printers designed for that kind of thing. It's designed for stability in a way that device-specific drivers aren't. Yes, some features can be harder configure from that driver, but you gain a lot in overall stability.

For "prosumer" printers, the per-device drivers may be a better bet as those devices are not designed for centralized-printing scenarios.

Answer 2

Yes, it does look like there's more going on than just the drivers. Anything else in the logs? Any signs of pressure/bottlenecks? Do you have another server that can be temporarily pressed into service to test a few print queues using the universal print driver?

Previous:

It sounds like you need to scrap that universal driver. The steps you're taking having nothing to do with security. They basically have to do with stopping and restarting the drivers on each workstation.

Here's what I would try to see if the driver is a problem:

1. Create a new printer queue using the driver for that printer (not the universal) while keeping a separate printer queue using the universal for the normal users.
2. Select a subset of solid test users to add that printer queue for.
3. Monitor to see if they have issues.

If that test group doesn't have issues but the normal group continues to, then you know it's the universal print driver.