supporting printing on a headless device

  • Thread starter Thread starter Greg Brown
  • Start date Start date
G

Greg Brown

Has anyone had any experience supporting printing on a headless device? The
problem is that I can not guarantee what printer my customers will be using,
since we are not in the business of selling peripheral devices. I suppose
we could 'recommend' a printer that has the drivers included in my build,
but with new printers showing up at your local electronics store on a daily
basis, this doesn't seem like a long term solution.

Any direction would be appreciated.

Greg
 
I haven't tried this approach yet, but perhaps some of the remote tools can
help you along the way (i.e. use remote desktop to view device manager).
Another possibility is to use DUA to install printer drivers remotely.
 
Greg:

This will be a challenge especially for USB printers. Some printers, once
componentized, work flawlessly. Others, like the HP Deskjet 5550, cause
issues with ntprint.inf with the file sRGB.icm. The HP printer installation
file, requests the SRGB color profile file from the ntprint.inf file. The
ntprint.inf file (in \Windows\inf) tells the installer to copy the file from
the installation CD, regardless of whether or not it is already installed.
You can modify the ntprint.inf to force the file to be ignored (assume it's
installed).

As for the USB issue, the issue is that physically different printers of the
same make/model cause the H/W Detection wizard to run and install the
device. I'm not an expert on this so maybe someone else has a solution for
this. This is probably because some/all(?) USB printers have a unique
serial # and this causes each printer to be unique to the OS? Maybe do some
googling on this as there might be a way to stop this from happening. Also,
plugging the same printer (or USB keyboard or USB mouse for that matter)
into a different USB port also causes the h/w re-detection.

HTH... Doug
 
I too, will have to cross this bridge soon.
The ideas that I have at this point, (before starting any work are)

1) 'Qualify' a number of printers that are allowed with the system, and
install drivers for those. (Hopefully if I pick a common HP driver, I can
use HP printers for a while...)

2) Our system will be using the 'Different Shells For Different Users'
approach (search MSDN for that title), so users should be able to log on as
an admin and install whatever printer they want...

Additional concerns include:
Because our system will usually operate headless, with it's own non-vga
display, we are concerned the user plugging in a device, and not seeing VGA
screen messages like 'device found'... and think the device is hung. (To say
nothing of 'paper out' and 'printer error' messages!).

I am planning on investigating the approaches found in the MSDN Articles:
'Enable Default Reply (Windows XP Embedde)
and
'Message Box Interception (Windows XP Embedded)

But I am not sure how difficult this will be...

Steve Schilz
 
Back
Top