HP LaserJet -vs- Terminal Server

[Stoic Joker]

Two things I'd like to start with:

1. I work for an HP Authorized Service Center.

2. nmX.Memnoch is right, HP drivers are a nightmare.

The 2nd one is "fix-able" if you do two things; Use the add printer wizard to grab the .inf and install just the driver (with out the garbage...), and avoid PCL6 like a plague. PCL5 works perfectly fine and doesn't contain all the extra crap that tends to make people swear when trying to print .pdf files

Any of the cheap (USB) laser printers are not (really designed) for a work/business environment. They're for home offices that don't really do much...

While you could do with a bunch of the Laserjet 1020/1022s you will most likely end up right back where you're at now by the time the warranty runs out. Note: these modles are not "repairable", if the thing dies, HP will make you send it back and then ship you a referb. e.g. Don't do that.

Your best bet would be to group your users on a much smaller number of (truly business class) network printers like the Laserjet 4250n, TCO is much lower that way because the machine is designed to take a beating, and the number of supplies you need to stock is much lower. Yes the toner cartridges are a bit more money, but you get alot more prints out of them and they don't tend to waste toner like the smaller (loss-leader) machines.

One of our clients is an accounting firm that (generates tons of paperwork) has several hundred of the 4250s in their offices spread across the country. Those machines adverage around 25,000 pages a month each while the users beat them unmercifully, and seldom ever fail even though they've been in service (at that rate) for several (2-4) years.

@nmX.Memnoch

Try using the Universal Print Driver on a Terminal Server

Yes, what sort of troubles are you having?

[nmX.Memnoch]

@nmX.Memnoch

Try using the Universal Print Driver on a Terminal Server

Yes, what sort of troubles are you having?

HPBPRO.EXE and HPBOID.EXE. Every time a new user logs into a terminal server another instance of each is started...and they aren't stopped with the user logs out. You also can't terminate the processes in Task Manager. Get enough users logging in and out all day and the server will eventually run out of virtual memory, the CPU goes to 100% and eventually stop responding to connection attempts. Disabling the services doesn't work because HP seems to have coded the driver to just reset the service back to Automatic and start them anyway.

Using the Add Printer Wizard isn't the correct way to load additional drivers on a Terminal Server. Technically it works, but it's not the proper way. You're supposed to load them on the Drivers tab of the Print Server Properties.

I have a customer on a side job that has a Terminal Server for some of their external users to connect to a custom application. After a single day of use there were 50+ instances of each started in Task Manager. And the only way to clear them is to reboot the server.

There are a couple of solutions listed here, but none of them are 100%. The thing I find really odd is that thread is almost 4 years old now and HP still hasn't fixed it. Those files aren't even required for printing. We even tried loading just the drivers without using the UPD and one of the printer drivers (4000 or 4100 I believe) has them anyway.

Edited October 4, 2007 by nmX.Memnoch

[Stoic Joker]

Crap ... I hadn't intended to Hi-Jack the poor guy's thread... Sorry!

@nmX.Memnoch

Try using the Universal Print Driver on a Terminal Server

Yes, what sort of troubles are you having?

HPBPRO.EXE and HPBOID.EXE. Every time a new user logs into a terminal server another instance of each is started...and they aren't stopped with the user logs out. You also can't terminate the processes in Task Manager. Get enough users logging in and out all day and the server will eventually run out of virtual memory, the CPU goes to 100% and eventually stop responding to connection attempts. Disabling the services doesn't work because HP seems to have coded the driver to just reset the service back to Automatic and start them anyway.

Ah yes HP's inane habbit of orphaning things and letting them run amok, their house keeping skills suck.

Using the Add Printer Wizard isn't the correct way to load additional drivers on a Terminal Server. Technically it works, but it's not the proper way. You're supposed to load them on the Drivers tab of the Print Server Properties.

Um...Nut sure where this part is coming from, so forgive me if I get my thinking & dunce caps backwards...

My reference to using APW/.INFs above was in regard to installing a locally attached printer only. It's just a quick-N-dirty was of stripping all the "helper App" garbage out of the driver and just getting the thing to print, instead of having it trying to become your new best friend.

Loading additional drivers via Print Server properties (on any server) is shared printer support of down level OSs. Once any one print driver is installed on the TS (to get the spooler started), it will happily connect back to whatever printers are installed locally on the client machine and use them.

I have a customer on a side job that has a Terminal Server for some of their external users to connect to a custom application. After a single day of use there were 50+ instances of each started in Task Manager. And the only way to clear them is to reboot the server.

There are a couple of solutions listed here, but none of them are 100%. The thing I find really odd is that thread is almost 4 years old now and HP still hasn't fixed it. Those files aren't even required for printing. We even tried loading just the drivers without using the UPD and one of the printer drivers (4000 or 4100 I believe) has them anyway.

I usually don't like to assume too much especially when working (blind) on the Internet/remotely ... so I'm mainly trying to make sure we're on the same page. That being said...

I really don't see why you're using the UPD, it's for letting an OS print to any HP printer, not to let any OS print to a given printer. What OS(s)are the client machines running? Both the LJ4000 and the LJ4100 will run fine on the (PCL5e) LJ4000 driver, which doesn't have any Helper-Poo in it.

The service/utilities (HPBPRO.EXE and HPBOID.EXE) discussed in the HP thread you posted may be orphaned from a previous driver install and just need to be ripped out by the roots (as mentioned in the thread). Generally in any TS/Citrix deployment the silver bullet fix for any printer that uses PLC is to just install the HP laserjet III driver ... It's ugly and has no options to speak of, but it'll get the thing to print with out breaking the server.

If you give me more detail about what you're up against I can try to simulate it in the lab and come up with a better answer.

Stoic Joker

[nmX.Memnoch]

Using the Add Printer Wizard isn't the correct way to load additional drivers on a Terminal Server. Technically it works, but it's not the proper way. You're supposed to load them on the Drivers tab of the Print Server Properties.

Um...Nut sure where this part is coming from, so forgive me if I get my thinking & dunce caps backwards...

My reference to using APW/.INFs above was in regard to installing a locally attached printer only. It's just a quick-N-dirty was of stripping all the "helper App" garbage out of the driver and just getting the thing to print, instead of having it trying to become your new best friend.

They're not backwards. I guess I was just clarifying that it's not supposed to be done that way on Terminal Servers (I've seen people do it and it's a pain to "fix").

Loading additional drivers via Print Server properties (on any server) is shared printer support of down level OSs.

Not necessarily. On a Terminal Server you would use the same method to install printer drivers (not the printer itself) so that the Terminal Server can successfully connect the client's printer. You do this because the printers aren't actually installed on the Terminal Server, you're just making the driver available so user can print from within their TS session.

Once any one print driver is installed on the TS (to get the spooler started), it will happily connect back to whatever printers are installed locally on the client machine and use them.

Right, but you have to make the driver available for that initial connection. I think we're both trying to say the same thing, just in different ways.

I really don't see why you're using the UPD, it's for letting an OS print to any HP printer, not to let any OS print to a given printer. What OS(s)are the client machines running? Both the LJ4000 and the LJ4100 will run fine on the (PCL5e) LJ4000 driver, which doesn't have any Helper-Poo in it.

That's the thing...we're NOT using the UPD anymore. When I started the job back in April the server had Windows 2000 Server on it and it was basically being used as a "one stop shop"...Domain Controller (and associated DNS, WINS, DHCP services), File Server, Print Server, Database Server, and Terminal Server. They were having problems with some HP LaserJet 1320 printers (those suck BTW). Against my recommendation, and because the network printers at the main location (where the server sits) are hung off of the server, they loaded the UPD on the server trying to fix the problems with those printers.

Anyway, they got a new server and everything but Terminal Services was moved to the new box. Once we were sure everything was running smooth on the new server, we reinstalled the old server with Windows Server 2003 and loaded the individual printer drivers for the remote users (using the Drivers tab in Print Server Properties). Everything was fine until we loaded the LJ4000 drivers. I'm pretty sure that we did use PCL6 though. I'm not sure that backing down PCL5 will work because I believe the driver has to match what the client has installed (since it technically maps it back to the clients local printer) and he has the PCL6 drivers loaded on all of those printers.

Oh, and I guess is should clarify that the remote workstations are using a variety of HP printers. They're not all LJ4000/4100's. Even at the main location they have five or six different types of HP printers.

The service/utilities (HPBPRO.EXE and HPBOID.EXE) discussed in the HP thread you posted may be orphaned from a previous driver install and just need to be ripped out by the roots (as mentioned in the thread). Generally in any TS/Citrix deployment the silver bullet fix for any printer that uses PLC is to just install the HP laserjet III driver ... It's ugly and has no options to speak of, but it'll get the thing to print with out breaking the server.

Again, no previous driver installs. This happened on a completely fresh server install and without using the UPD. I even made sure to use the latest versions of the individual printer drivers direct from HP's site.

[Stoic Joker]

Sorry about butchering the post, the board said I(/we) ended up with too many quote tags.

They're not backwards. I guess I was just clarifying that it's not supposed to be done that way on Terminal Servers (I've seen people do it and it's a pain to "fix").

Hm... I've never run across this issue, but I have an Idea what may be causing it.

Not necessarily. On a Terminal Server you would use the same method to install printer drivers (not the printer itself) so that the Terminal Server can successfully connect the client's printer. You do this because the printers aren't actually installed on the Terminal Server, you're just making the driver available so user can print from (ithin their TS session.

(Tyeing in the comment above)

[i'll try to make a scenario out of this for clarity] If I start with a TS(no printers) and one client with a LJ4000 locally attached, enable connect back to local devices->printers, and then connect to the TS, the printer will install itself during the connection...but printing will fail (because the spooler isn't "ready").

Now if I install any printer driver locally on the TS, (let's say an Epsom Inject) then the spooler will completely initialize on the TS, and if I connect the client to the TS, it will again install/create a "Session Printer" (which is deleted when I log off) that uses/displays the LJ4000 name (or what ever silly name I gave it locally), and printing will succeed! (Now please don't ask me which Tech Note I found that little jewel in as I was in the middle of an "all nighter", **** glad I could finally go home, and didn't save it.)

]Now the weird part...[ Thing that will break the above - XP Home, this trick will not work if the client is XP Home (which uses Simple File Sharing only). XP Pro, while much better, if Simple File Sharing is enabled I have seen that make all of the connect back to local device X function either badly, or not at all. I believe this method is dependent on the IPC$ "Doorstep" that is only available when "normal" file sharing is used.

At any rate, being that these printers are strictly session based, every trace of them is eradicated when the session is closed (which is a good thing in this case).

I have used the above method with both 2k & XP clients while connecting to both 2k & 2k3 servers, and using a 16bit application over a VPN/WAN that required a port capture to use a network printer... and it worked every time.

Right, but you have to make the driver available for that initial connection. I think we're both trying to say the same thing, just in different ways.

No, depending how the client is configured, the server can/will pull what it needs driver wise from the client (or use its native driver as/if needed).

That's the thing...we're NOT using the UPD anymore. When I started the job back in April the server had Windows 2000 Server on it and it was basically being used as a "one stop shop"...Domain Controller (and associated DNS, WINS, DHCP services), File Server, Print Server, Database Server, and Terminal Server. They were having problems with some HP LaserJet 1320 printers (those suck BTW). Against my recommendation, and because the network printers at the main location (where the server sits) are hung off of the server, they loaded the UPD on the server trying to fix the problems with those printers.

Oh, the horror... and you're 100% correct the 1320 is a bit ... "Grenade Prone".

Anyway, they got a new server and everything but Terminal Services was moved to the new box. Once we were sure everything was running smooth on the new server, we reinstalled the old server with Windows Server 2003 and loaded the individual printer drivers for the remote users (using the Drivers tab in Print Server Properties). Everything was fine until we loaded the LJ4000 drivers. I'm pretty sure that we did use PCL6 though. I'm not sure that backing down PCL5 will work because I believe the driver has to match what the client has installed (since it technically maps it back to the clients local printer) and he has the PCL6 drivers loaded on all of those printers.

Yes they will conflict if they don't match, but there is always the option of switching the clients to PCL5, to save on headaches. I've yet to see anything useful that was added in PCL6... e.g. What the Heck does the printer need to know the documents filename and path for...? ...Is it really going to go back and look it up later?!?

Oh, and I guess is should clarify that the remote workstations are using a variety of HP printers. They're not all LJ4000/4100's. Even at the main location they have five or six different types of HP printers.

The service/utilities (HPBPRO.EXE and HPBOID.EXE) discussed in the HP thread you posted may be orphaned from a previous driver install and just need to be ripped out by the roots (as mentioned in the thread). Generally in any TS/Citrix deployment the silver bullet fix for any printer that uses PLC is to just install the HP LaserJet III driver ... It's ugly and has no options to speak of, but it'll get the thing to print with out breaking the server.

Again, no previous driver installs. This happened on a completely fresh server install and without using the UPD. I even made sure to use the latest versions of the individual printer drivers direct from HP's site.

I've got a 4100 connected the my WS at the office, and I use RDC from there to manage the servers, so I'll try to see if I can get one of those files to show up on the server and see where is comes from.

I actually rather hate printers, so to have one crash one of my servers would make me livid beyond words. So... I'll do what ever I can to try to find an answer/solution for you on this

Stoic Joker

[PMooter]

I am having the same issue as the one you are talking about here. I have a Citrix Farm with numerous Windows 2003 TS / Cirtix servers and ~ 400 clients. We have four servers that handle one published app and we have encountered the problem with HPBOID and HPBPRO.EXE eating up all our resources. Has anyone found a "Document" that either Citrix, Microsoft or HP has put out addressing this issue and how to go about fixing it? When I called HP it was a joke. "We don't support using our print drives in the way you using them"... BS.

I basically just want to rip out the HP Port Resolver service and any print driver that installed that service.

Any help is greatly appreciated.

paul.mooter@avistacorp.com

[cluberti]

Well, first thing to do is to remove all drivers in spoolsv.exe on the term services server via Printers and Faxes > File > Server Properties > Drivers tab. Second, make sure you uninstall from add/remove programs any crap the driver installed that isn't removed by uninstalling the driver from the server properties in printers and faxes. Next, download and run cleanspl.exe (windows 2003 reskit) on the terminal server, making sure not to delete any inbox print monitors (like standard tcp/ip print monitor, local port, lpr, usb port, etc), but deleting any other non-inbox print monitors. You will have to reboot once this is finished.

Next, reinstall ONLY the driver files (if the driver for your model didn't ship with the Windows CD, and you can't use a driver that's "compatible" or similar from the list on the Windows CD, you will have to download the driver package from the vendor and extract it to disk to do this) via Printers and Faxes > File > Server Properties > Drivers tab. Just point the installer to the driver you need (either from the Windows list or the folder on disk).

Now, the TS is "clean", or as clean as you'll get it if you install OEM print drivers. One more thing is to make sure administrators don't have print redirection functionality on the server - admins who connect and use a driver not already on the TS will INSTALL A NEW DRIVER, so watch out. Admin access should never be for everyday usage anyway, only patching/config changes/etc, and as such admins do not need to be redirecting printers.

Lastly, make sure you enable and use the TS print fallback driver functionality if you allow redirection of printers, so that if a user has a queue that doesn't have a driver already installed, that he/she will be forced to use the "fallback" driver for the queue rather than the driver on their machine - this should keep you as clean as possible. If you are so inclined, doing the exact same thing on your print servers and clients is another great way to "clean up" your print environment overall.

Oh, and yes - PCL drivers are evil. PS drivers are the most stable (although perhaps least functionality comparatively), PCL5, then PCL6. 6 may be most functional, but they create HUGE spool files and are just not as stable or supportable as PS drivers. If your users can use postscript, use ALL postscript drivers - once you start mixing and matching, you cause the spooler service to be compromised stability-wise, which you've all already found out, it seems, the hard way .