CoNetrix

Blog: drivers

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”.

Networking, SBS 2008, drivers, SBS, HP, printing,
 

You know the situation… you’re keeping lots of plates spinning, multi-tasking, generally having a productive day when you look down and realize that you have 87 windows open on your task bar…the Windows Weeds. In my particular situation I was about to install a Proliant Support Pack (a conglomeration of driver updates approved by HP for a particular server model). The order of events was as follows: [more]

  • Downloaded compressed PSP from HP website to a network location
  • Extracted PSP to a child folder on the network
  • Was planning to copy the extracted files from the network to a Temp directory on the terminal server I was working on to perform a local installation of the PSP
  • Received a support call for a different problem and turned my attention to that task for a while
  • Came back to the PSP task. On the terminal server to be updated, I saw that there was already a d:\cnx\temp folder that had what appeared to be my extracted PSP files in it. With so many windows and directories opened I thought I had already copied the extracted files over to the local directory before I got called away to the other task.
  • Upon installing the extracted PSP files from the local directory, several core networking components crashed rendering the teamed NICs on this server useless. Re-running the PSP as a whole as well as just installing the updated networking driver portion of the PSP did not help at all.

As it turns out, the directory and PSP files that were in d:\cnx\temp were created by another engineer during maintenance procedures several months ago. It was just coincidence that the same type of installation files (just an earlier version) were in the exact network location I was going to create…what are the odds?!? When extracted, PSP files from different versions look the same, so there was nothing to tip me off that I was actually installing an old (and also corrupted) PSP.

Lessons learned:

  1. Keep a tidy task bar
  2. Clean up old temp files when finished with them
  3. Question your presuppositions if things aren’t adding up (i.e. “I KNOW these are my PSP files”)
  4. The unlikely is still a possibility (ie. same files –just diff versions- in the same directory). 
Networking, drivers, HP, Proliant,
 

There are two SCSI driver standards that are available for most SCSI HBA’s. The older standard (SCSIport) has been replaced by a newer technology (STORport). STORport allows faster I/O, duplexing and other advantages. You should use the STORport drivers for all HBA’s when available. This is especially revelant for FC cards. The details are: [more]

Classic SCSI (SCSIPort):

  • commands were queued on an adapter/LUN basis
  • Maximum number of I/O's per adapter is 256, with 16 LUN's per adapater
  • Queue limit on LUN level, with a maximum of 20 outstanding I/O's
  • If one LUN reaches it's limits all other LUN's will be blocked as well
  • Will remain for direct attached storage

Storport:

  • No limitation on adapter queues
  • Each LUN has a queue limit of 256 outstanding I/O's
  • Designed for Fibre Channel attached storage
  • Exchange and SQL will probably not be using Storport directly
  • Except for SQL RAW disk functionality which will bypass volume management (for higher performance)

More details: http://download.microsoft.com/download/5/6...eb/Storport.doc

Networking, drivers, SCSI,