Linux – Sharing a USB printer with IPP (internet printing protocol)

Windows and Active Directory do not natively provide any good way to handle auditing/reporting of print queues. Administration, however, is pretty easy, and it's completely built-in.

Some agencies use central print queue servers, but it's discouraged by many sysadmins. I personally prefer to have one or two print queue servers per building. Publishing printers in active directory is a great way to make installing printers on clients a breeze. Users can select "Add Printer", "Find Now", and it will automatically list all of the printers in the directory or all of the printers in their current site, depending on how you have group policy, sites and services, and the print queues configured.

I've also found that it's far easier to manage print queues when there are no network printers directly installed (using TCP/IP). We've instituted a policy that our network printers are to always have a queue created on a server, and then clients connect to that queue.

While I do prefer to use Linux for some things, print queue hosting isn't one of them. If you're using Windows clients to print, use a Windows server or client to host the queue.

I've run into soooo many problems with printers & Terminal Services (now known as Remote Desktop Services) that I can probably write a book on what to do & not to do...

All that aside... 51% of the problem is that Windows XP doesn't play nice with XPS printing system... and Microsoft has no desire to fix it. XP is dead/dying. There are several incompatibilities between the Windows XP printing system and the XPS Printing Framework that the Microsoft TS Easy-Print is based on.

With that in-mind, there is a small glimmer of hope. If you can manage to get the same driver for both machines installed, and let the RDS use the native HP driver instead of relying on the TS Easy Print driver... most of your problems will go away.

If you're not using the TS Easy-print driver... then the problems you're running into are based on the fact that the drivers you are using are "host-based" drivers. What this means is that the drivers are poorly written (Yes, HP has done this several times) and rely on being able to talk DIRECTLY to the printer instead of going through the windows printing system or use some some hard-coded port names or whatever else they could come up with. If this is the case, you'll also find that you will have similar problems if you try to print via UNC path on a networked machine. i.e. \computer1\printer What you can do in this situation is a bit of hit & miss. HP makes a "Universal Print Driver" which is supposed to use some sort of generic print language that most printers understand (i.e. PCL3 or PCL5 or postscript etc...) You will typically lose some functionality on the printer (if you can get it to work) but it will function much better in a RDS environment.