Blog: HP

We began to see the autocreation of printers (or redirected printers) starting to fail for users when logging in to a customer's Terminal Servers lately.  On the same server we also start seeing the printers that were autocreated not being deleted (orphaned session printers) when users logged off a Terminal Server.  The cause turned out to be two outdated DLLs installed on the Terminal Servers:

Hpmini.dll - This issue occurs with HP model driver versions 60.x.x.x and 4.x.x.x. containing hpbmini.dll version 1.0.0.18 or older. Version 1.0.0.19 and newer has the fix. The memory leaks and memory corruption possible with the 1.0.0.18 (or older) dll will not cause a spooler crash, but can degrade performance of the server.  Version 4.x.x.x print drivers have an issue unloading hpbmini.dll which will likely cause a spooler crash when the server has a heavy load of connected users.

hpcdmc32.dll - This issue occurs with 60.x.x.x and 4.x.x.x HP print drivers containing hpcdmc32.dll version 1.0.2.30 or older. Version 1.0.2.31 and newer has the fix. The most recent version of hpcdmc32.dll is 1.0.2.35. The memory leaks possible with the 1.0.2.30 (or older) dll will not cause a spooler crash but may cause performance degradation.

Here is what turned out to be the solution for us: [more]

1. Upgrade to latest driver available for printer model(s) causing issue – verify that the two DLLs above are updated during this process. If the files are in use while the driver is updated, they will not be replaced.
2. Manually replace the two DLLs above with updated versions.
3. Install and use HP Universal print driver

I’ve been researching some slow installs on one of our terminal servers for a while now. An install, which normally takes a couple of minutes, had been taking close to an hour; giving me time to complete other installs and come back to it. It seemed like a registry issue for the longest time, but I wasn’t completely sure where to begin. I found a posting on an HP forum about an older version of the Universal Print Driver leaving a ton of garbage in the registry when it was installed. Checking the tree (HKEY_CURRENT_USER\Software\Hewlett-Packard, HKEY_USERS\.DEFAULT\Software\Hewlett-Packard) and there were quite a few keys with GUIDs (100a6cf5-1f38-4593-558c-306404c054e2) running down the list. [more]

Following recommendations from http://www.rb303.net/2010/01/terminal-server-2003-msiexec-high-cpu.html, I deleted all the HP printers, deleted all the HP drivers from the local print server properties, and then backed up and deleted the trees listed above as well as the HP Universal Print Monitor key (HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Print\Monitors\HP Universal Print Monitor). I then reinstalled the necessary HP printers, one of which installed the Universal Print driver again, and checked the registry. Much cleaner.

After running a test install, it appears that removing those entries really cleaned up the registry quite a bit and is speeding up the installs. To give you an idea of the sheer size of the exported entries, in the default .reg format, the export took nearly 40MB. In plain-text (.txt) export, the size doubled. That's a lot of HP garbage.

Here's a helpful hint that will save you some time trying to figure out why your additional paper tray won't work after moving your HP printer.  I recently encountered this problem after moving an HP printer to a different spot in the same office.  After I plugged it back in the add on paper tray wouldn't work.  Turns out, the paper tray had to have power before the printer was turned on, or the printer would not recognize it.  Power applied simultaneously did not work.

I have been working on a proof of concept install of VMware View v4 at a customer location. One of the challenges that we ran up against was trying to get the USB redirection to work with HP USB printers. Technically, all that is necessary is to have the printer plugged in USB and have a driver loaded on the virtual machine that you are connecting to using the VMware View client. However, in practice what we found...

HP printers are usually installed using a DOT4 USB port driver. DOT4 port types have been around a while and basically provide a bi-direction information flow between multiple devices on a single physical channel. Its most commonly seen for devices that support multiple functionality like scanning and printing, but can be used for any USB connected printer. There is an option to NOT use the DOT4 port types and in our situation it was essential because….well, the VMware View USB redirection just simply didn’t work with the DOT4 ports. The problem is that once the printer was installed it was IMPOSSIBLE to change the port type from DOT4 to USB…the printer would stop working. After about 2 days of struggling with this and not being able to remove the DOT4 port type, I finally found that the port type could be altered after the printer was installed. Heres how: [more]

1. Open device manager on the PC and change the view to by connection and show hidden devices
   
2. Search through the USB host controllers and USB Root Hubs until you find the hub with the printer installed…It will look like the following:
   
3. Next, right-click on the USB Printing Support and select properties.
4. Select the drivers tab and select upgrade driver
5. Choose to “Install from a specific location” and then choose “Don’t search. I will choose the driver”
6. Then you will be give the option to choose the driver used for the USB printer support. Choose USB Printer support.
7. Click Next and it will install new drivers and change the port type of the printer from DOT4 to USB

It is yet to be tested if this USB printer support method works with multifunction printers, but the change worked on every LaserJet USB printer that we set up. Obviously, if you have a choice, just set up all the printers as network printers and avoid the problem altogether.

I had been troubleshooting a DL380 server and replaced bad memory.  I had the server powered off and connected to it using iLO.  I used iLO to send power signal to the server so that I could watch it boot up.  For some reason right after I powered on the server, I lost connectivity to iLO and the blue UID light on the server remained on.

Once Windows came up, I checked the HP System Management software, and it did not list an iLO management processor like the other servers did.  I figured that iLO was hung, so I shutdown the server.  Still no response from iLO, so I checked BIOS with a physical monitor and keyboard.  Upon boot, it did not show the message to press a function key to configure iLO.[more]

In order to reset iLO, I had to completely unplug both power supplies from the back of the server.  After powering the system on again, I then saw the option to configure iLO.  I saw that it had an IP address but I still could not connect.  The blue UID light was off though.  After the system came back up, I had to reset the iLO interface through the HP System Management software before it would work again correctly.

A client recently had a problem where printing to an HP P2035 printer from the network. When the printer was pointed to installed driver, the print spooler on the print server would crash.

The cause of the problem was that the only model specific driver to date (10/21/09) for the P2035 model was a Host-based driver – also known as: Graphic Display Interface (GDI). The driver must NOT be a Host-based printer (AKA GDI or Windows-only Printer) - Host-based Printers, will not function in a Terminal Services Environment (without 3rd party printing software). The only other available driver was the HP universal driver. [more]

In the documentation I found out that the printer does support PCL5 language. However, there is not a model specific driver in this language provided by HP. The P2015 model does have a PCL 5e driver available. I downloaded that model and installed it to the printer server and test servers. I then tested printing and things seemed to function.  However, further testing revealed failure to print images from Adobe and bank specific applications while using the P2015 driver with this printer. Images would come out as black squares. Several modifications were made to the printer settings, but nothing seemed to fix this issue. The problem was not documented on HP’s support site, probably due to the fact that this is a new model of printer.

When flashing the NVRAM or the Hard Disk on any of the HP printers make sure that you remove any added on devices that can store data on them such as the Bar DIMM USB devices used to print barcode fonts. If they remain in place when flashing the NVRAM or HD it will erase the data on the addon device as well.

I am doing an SBS 2008 install at a customer and have run into the whole x86 / x64 print driver problem. The SBS box is x64 and that is where I wanted to install the network printers. The terminal server is x86. I did some research on the driver compatibility and universal printer drivers and decided for simplicity sake to use the HP universal print driver. I got everything installed, but during testing a couple of the printers (specifically the HP 4050 series LaserJet), I had a very weird problem come up. Every time I printed something, the printer would display “waiting on manual feed tray” as if the job was specifically targeting that tray. Even when I statically set the default tray in the driver config, it would try to pull from the manual feed tray….ahh the joy of printers. Well, after about an hour of troubleshooting, I tried changing what seemed like a very unrelated setting. [more]

Notice the Paper type is unspecified. By default that is set to "HP Tough Paper" on this model of printer. If that setting is not changed, it defaults back to the manual feed tray NO MATTER WHAT. Does the gremlin in the printer know what type of paper is loaded…well, apparently so. Do yourself an favor and set it to “Unspecified”.

I was installing a 64bit VM in ESX Server 3.0.2.  When attempting to load the ISO file to install the OS, I got a cryptic ‘Host CPU’ error in VI client.  Searching a number of forum posts, I decided to check the BIOS setting on that DL380-G5 for the CPU Virtualization Technology.  Sure enough, it was disabled and enabling let me get past the ‘host CPU’ error and load the OS.  I noticed in the posts that many people were saying older Proliants had this setting enabled, while newer models had the setting disabled.  This setting should be enabled for systems acting as VM hosts (ESX, ESXi, Hyper-V, etc), so be sure to check that setting, regardless of how new the server is, before installing your VM guests.

Also, a quick note that these CPU BIOS settings (VT, No-Execute memory protection, etc) should be consistent across any systems being used for V-Motion.