I am using a Windows Server 2008 Standard set up with Terminal Services.
Generally it has worked well, including when printing to locally attached printers / printer redirection.
Today at a particular site all 4 machines are unable to print to their local printers properly.
One printer is an HP Color LaserJet CP1215 set up on a Print Server (IOGear). When I print to this printer, I see a Windows Terminal Services Printing Service error. Click OK, and it actually usually WILL print.
I also receive the same error when using the XPS writer to the local machine – though it usually WILL print. That is my work-around – I write it to the desktop then print locally.
The main problem is:
The other printer is a HP LJ 1200. It is connected USB to an XP Pro machine and shared. The error happens on the directly attached machine as well as the remote machines. When printing from the TS session I get a invalid access code. I can not print at all to this printer – which is the one I really need to.
Any ideas? I have tried updating drivers, deleting and re-installing printers, logging in as administrative users on both the local machines and TS.
Best Answer
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.