<

Go Premium for a chance to win a PS4. Enter to Win

x

Redirected Printing in a Remote Desktop Environment

Published on
43,993 Points
33,893 Views
6 Endorsements
Last Modified:
Awarded
The question has been asked on multiple occasions as to how best to do printing in a remote desktop or terminal services environment.  

It seems that this particular question has plagued several people and most especially as Terminal Services, as it was first known before it was changed to "Remote Desktop Protocol" came into its own right around the same time as the USB version of the personal laser printer.  I don't know if this was an unintentional mishap on the part of Microsoft at the time or just foul luck, but in either case, where USB printing is concerned, and even some other types of printers were concerned, printing in a remote desktop environment such as I have witnessed on many occasions can be problematic if you don't know what you're looking for, if it's set up incorrectly or a combination of both.

So the question is often asked, "why is my redirected printing not working?"  While I'd like to say that there is a one size fits all answer, unfortunately, that's not true.  

There are factors that are more prevalent than others, but even within the same environment, as I will demonstrate from a case I had to manage below, it could be a few different things that causes your printer redirection to not work as you'd hoped.  For many network administrators, the answer is simply to buy multiple network printers.  But in customer/service provider relationship as I have often found myself, you may not always have the option (and frequently you don't when you're simply a hired tech gun) to say, "just buy yourself a few network printers at several hundred dollars each".  And point of fact, there is an adage to remember...the customer is always right.  And to that point, I've found that lawyers offices can often be the MOST demanding of any customer.  

In one particular instance, I was a tech consultant for a law office and I was told exactly this..."This is how we've always done business and I don't care if it makes sense or not, just make it work".  My answer was to smile, nod my head and go back and think about how to make it work as seamlessly as possible.  So you are not always faced with an easy way out.  As a result, I've learned over the course of many years to think outside the box, try new things and become familiar with the ins and outs of various network strategies that I could leverage against such statements as are often presented to me like that above.

In general, as I've worked with Terminal Services (now known as Remote Desktop Protocol) as long as I have, one thing I've become incredibly familiar with are the ins and outs of how to make things work appropriately in the Terminal Services environment, particularly where printer redirection and application management are concerned.  One thing I've come to know is that there are five components that need to be addressed when working with printer redirection in particular, those being as follows:

1.  Printer drivers on the workstation
2.  Printer drivers on the server
3.  Registry patches that need to be applied to any NT variant operating system prior to Windows 7 (i.e., Windows 2000 Professional, Windows XP and Windows Vista)
4.  Making sure that within the Terminal Service client environmental settings locally that the user's client is set to do printer redirection
5.  Appropriate configuration of the user account in Active Directory Computers and Users

In one instance, I was faced with cleaning up printing issues as a result of another technical group's shortcomings.  Specifically, almost every desk had a small laser printer on it connected by USB that was not redirecting as it should.  And, as I mentioned, while one fix across all of them would have been nice, the 10 or so printers in question that were having issues had various problems relating to one or multiple components being missed and I will go into more specifics further on.  But as a rule, most any printer will work within Terminal Services, although from time to time you have to think a little outside of the box where Microsoft is concerned as I will detail later.  :)

Issue 1
Where the Laserjet P1006 printers are concerned, early documentation from HP had stated that they were unsupported in Terminal Services, although there was no particular explanation as to why.  Further investigation led me to information relating to the fact that the first generation drivers in order to work in a TS environment needed to have domain administrator privileges by the client in order to work, which is both impractical and uncalled for.  

However, with later releases of the driver, this stipulation went away, at least this is what such documentation as I could find suggested.  In investigating those systems that had Laserjet P1006 printers attached, in some cases, yes the registry fix had to be applied, but more to the point, most all of them had the 1.0.x series drivers - the first generation.  I downloaded and applied the latest set of printer drivers from HP, those being 8.0.X and between the registry fix and the new drivers, the printers, albeit slow, became operational.  I don't remember if the server itself had the drivers or not, although I know, in doing the research, that as Windows XP and Windows 2003 Server are so closely related, in Server 2003 x64, the drivers for Windows XP x64 can be used in a server environment and they install and work perfectly.

Issue 2
The Laserjet 1012 was a bit different issue.  Windows has the x64 drivers built in for the printer...HOWEVER...one small difference.  The problem is related to how the printer is identified.  In Windows XP i386 (32 bit), the printer is simply defined as a Laserjet 1012.  However, in Windows Server 2003 (both i386 and x64 editions) the printer is defined as a Laserjet 1012 HB.  That one single difference was enough that when an attaching XP system presented its printer for redirection, the server simply didn't see it within its driver database and didn't know what to do with it, even though the drivers for say Vista, which also reports the printer as being a Laserjet 1012 HB, are IDENTICAL to the XP drivers.  

The solution in this case was to download and manually install the Vista 32 bit drivers on the workstations in question that have Laserjet 1012 printers attached.  You have to remove the printer as it's reported, reattach the printer and manually install the drivers in order for it to apply them.  Once applied, the connecting XP system then reports the printer as a Laserjet 1012 HB, which matches the 2003 driver database and will be redirected (provided that the above mentioned general rules are in place).  Now the caveat to this is that the next time the system boots up, it will redetect the printer and will request the XP drivers.  

Simply have the XP drivers on hand and allow it to go through the installation process (again) with the XP drivers and a second instance of the local printer appears which identifies itself simply as a Laserjet 1012.  Make sure that the Laserjet 1012 HB is the default printer and the server will recognize and redirect the printer accordingly.
Issue 3
The HP Laserjet 1300 was a slightly different animal.  This printer, although it's a good printer, is actually a bit older than the rest.  There have been universal PCL5 drivers out forever.  However, it's been my experience that these drivers don't always act the way you'd like them to in a Terminal Services environment.  I did attempt to do it appropriately (install the universal drivers on the server and workstation), but as I had experienced in the past, the somewhat limited nature of the drivers was problematic as I'd come to know through experience in the past.  

However, as with most HP printers (as well as a lot of other makes of printers as well), many of the Laserjet family have one thing in common - they are built on the same platform as printers from more than a decade ago and they conform to the HP Laserjet 2/3/4 standard and most all of them will work with just plain standard Laserjet 4M drivers, the only difference being that if you have say a printer that is capable of duplexing, you lose the duplexing capability.  Obviously, this isn't the case with these printers so it's safe to use the Laserjet 4 drivers that are inherent in all versions of Windows.  So I used the Windows native HP Laserjet 4M drivers on this printer and it immediately worked with the server without any issue whatsoever.

Issue 4
This particular issue there were two computers that had an issue that I knew the technical support provider had been struggling with for some time and, when I left that afternoon, I'd also struggled with it some.  The issue manifested itself in such a way that, if the regular users of the computer logged in, although the registry patch was in place and the drivers were in place on the server, the printer was not redirected.  

However, if another user were to sit down at their same computer, the printer would be redirected without issue.  Now my old mind is somewhat feeble where long term storage is concerned, so I didn't immediately dredge up memories of me facing this particular issue a long time ago and what I might have done to correct it.  But being that I am of a mindset that I enjoy a puzzle, I did a little research at home.  It gave me an opportunity to peruse some of my old books anyway that my wife keeps asking me to throw out...guess what - they're staying now.  :)  

In any case, after blowing some dust off my MCSE books from eons back and also doing some Google searching, I finally came across the answer and I could have smacked myself in the head with my textbook for not remembering it once I saw it.  Within Active Directory Users and Computers, among all of the other tabs you see when you bring up the user account, there is one specific tab called "environment".  That tab is SPECIFIC to their Terminal Services environment and it completely overrides any client based settings, so no matter what you do on the client side in terms of setting up the client to do drive and printer redirection, this setting, if not applied, will not allow printer redirection or drive redirection to take place.  When you open that specific tab, there are three checkboxes.  Those checkboxes specifically address printer and drive redirection.  In order for printer and drive redirection to work, these MUST be turned on at the server side.  I found in both cases that these particular attributes within their Active Director profile were turned off for the two regular users.  Once I turned them on, as they had Laserjet P1006 printers, they worked without any issue whatsoever.

Summary
In all instances above, I used just the generic driver, not the whole printing platform from the vendor as I find the vendor software to often be resource intensive and an immense waste of time.  The "host based driver" as HP calls it (which is just the driver, no software) works just fine inasmuch as both the server and workstation are concerned and are all that is necessary.  

Now I will say that in previous experience, there are some companies (brother comes to mind) that don't ALLOW you to download just the driver for some of their models, although none of that is the case with this example.  But for future reference, here's a trick I learned a long time ago with such printers.  If you go in and have a full installable for a printing system such as Dell and Brother sometimes foist off on you, there is an easy way around it.  Ordinarily, these installation packages pause at some point before or during installation.  

The issue with these  kinds of programs is that, once the installation begins, almost without question it's going to try to go out and autodetect the printer and, when it finds that it is not there, it tells you, "you don't have the printer installed" and then rolls back everything and gets rid of the files.  This can be a major pain on the server side as you're not ATTACHING the printer to the server - you just want the drivers.  But it won't let you do a manual install to LPT1 just so you can get the drivers.  

The workaround that I've found is that, at that point in the installation process that it pauses, pay attention to your temp directories where it's extracting the files.  Usually the installation program will extract everything including the drivers and it gives you an opportunity to quickly copy the contents of the place where it was extracted to and capture the drivers.  Then put those captured drivers someplace else, complete the installation and let it fail and THEN go back and manually install the printer in question to LPT1, which won't require the installation program as you're not using the executable and printers on LPT1 aren't typically detectable anyway, and then, once you've manually installed it, you can remove the printer and the drivers will remain behind for use later.  

Again, this wasn't necessary in this case since all of the printers had simple drivers available that could be used.  But if you run into this particular issue with other such printers, I've used this method before and 99% of the time it works.

Again, as I mentioned above, just about any printer will work in Terminal Services with just the five pieces mentioned above in place.  On rare occasion you have to think a little outside of the box such as is the case with the Laserjet 1012.  But as a whole, I have yet to find a printer I can't make work reliably in Terminal Services.  :)

I hope this helps.  If you have any questions, please feel free to ask.
6
Comment
Author:bb_xpress
  • 3
  • 2
  • 2
  • +8
15 Comments
 

Expert Comment

by:chrisdodds
Wow.  I'm so glad I found this post!  

Scenario -

One of my clients is a small accounting firm and they keep QuickBooks company databases on there server for all of their clients.  They have a relatively new SBS 2K8 server installed last June/July.  We have set up 3 Windows XP
Pro machines to act as makeshift Terminal Servers (for now - as of two days ago another Server 2008 machine is on order and we're awaiting the arrival of the machine to install as a RDC Server.  Licensing for 5 concurrent connections has also been purchased.)  However with these 3 XP machines in place and QuickBooks installed on all of them, I can have up to 3 users logged into any 1 of the XP machines to access their company database files.  They connect over VPN to the corporate network and connect of MS RDC to access QB. All of this works correctly and without issue.  I have multiple different businesses logging in and working remotely to print from QB on the remote XP machines back to their local PC's without problem.  I have one specific user with 2 PC's only (a Mom-&-Pop Shop, P2P networking, no server) and while they can access the above referenced XP "Terminal Servers", their printers will not redirect.  

PC 1 is Win2K with an HP Color LaserJet 2480 and is installed on their local PC to an TCP/IP port of 192.168.1.106. and is set as their default printer.  Their network scheme is different from the remote network (192.168.1.X vs. 192.168.16.X) so there shouldn't be a conflict there either. The printer is shared on this PC.  I have applied the MS reg mod (even though the documentation states it is for Wix XP and up), I have rebooted after the reg mod was applied.  In the RDC connection on the local Win2K PC, the printers and clipboard are checked to allow for redirection upon connection to the remote PC.  I have downloaded from HP and installed on both the local and remote machine the full software (prior to reading your post) but all to no avail.  I have also logged into my corporate SBS 2K8 machine and checked in AD that under the "Environment" tab all client devices are enabled.  For some reason, I just can't get this printer to redirect...

PC 2 Is a Windows XP machine with an HP F4480 printer attached via USB rather than TCP/IP port.  It is shared out.  I have downloaded and installed the full software on my remote machine.  I have made sure that "Local Resources" boxes are checked in the RDC connection options.  I have applied the MS reg mod and rebooted.  All to no avail.  This is an All-in-One printer and the documentation I've researched suggests that these can be tricky to make work.  I'm at a loss now and don't know quite where to turn.  Hopefully you have some experience in redirecting print jobs from a remote machine back to a local network printer and may have an idea for me to try.  I apologize for the great length of this post, but you did say " If you have any questions, please feel free to ask."  So, I'm asking!  Thanks for your time and I look forward to hearing back from you soon.

- Chris in San Antonio

PS - I've posted over the last couple of days in hopes of some support.  You can reference my question here.  I'll gladly award the points to you if you can help me solve this conundrum.  I feel I'm close, but just can't quite seem to crack this one...

http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Windows/2000/Q_26736204.html
0
 

Expert Comment

by:chrisdodds
Okay, on my Windows 2000 PC I have not had a chance to complete the task at hand.  However on my second PC (Win XP) I was finally able to make my printing redirection work.  They have an HP DeskJet F4480 connected via USB.  The missing component in this scenario (which I did not know because I did not purchase or build these machines) is that my XP machines that the clientele are logging into are 64 bit versions of XP.  This was crucial (obviously) to my success in making this printer work in the remote session, but was still tricky to configure none the less.  I had to:

A. Add the additional drivers on my local PC (the PC with the printer actually attached to it) to be shared.

B. Download the drivers and add a printer locally using those drivers to have the drivers installed into Windows properly.  I installed it as a local printer and then once I logged off and reconnected, the printer was redirected and I was able to delete the instance of the bogus local printer I had to create on my remote machine.  

So, to add to your already fantastic list of items to look for, be sure you know what version of each OS you are working with.  This SHOULD go without saying but in my case obviously it needed saying.  
0
 
LVL 5

Author Comment

by:bb_xpress
Hi, Chris.  I should get back here and check these things more often, but I'm a touch scatterbrained.  :)

I hate to answer a question with a question, but in order to find out more about the situation, one thing I might not have mentioned in the article is that the event viewer, both on the server and workstation, are valuable tools in troubleshooting issues that you come across.

It sounds like you managed to get the XP system working and, yes, drivers need to be specific to each of the operating systems in order to work appropriately.  It bears repeating, though, that XP and Server 2003 are closely related.  So if the manufacturer lacks a driver for the 64 bit version of Server 2003, you may want to try the XP 64 bit driver instead.  The *safe* thing to do is try it in a non-production environment first because sometimes these drivers can create issues.  But 99% of the time the drivers coded for XP will usually work with the Server operating system as well.

Now as to the question, I was unclear as to the setup of the first printer.  It sounds like it's on a print server of some sort?  My article really was more relational to the DOT4 family of printers, however, most of the same things apply.  I am actually not sure, now that I think of it, whether TCP/IP printers automatically get redirected.  They *should* and if memory serves me they usually do.

In any case, the first thing you might want to check is to immediately look at the event logs on both the workstation and the server (the server most especially) as soon as the client logs into their remote desktop.  If the server has an issue with that printer, oftentimes it will manifest itself in the event viewer and give you an idea what the issue is.

Also check the drivers on the local machine.  Make sure that the drivers are the latest available.  I've more than once heard of issues relating to drivers where HP printers are concerned in a TS environment.

That's a good place to begin, at any rate.
0
Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

 

Expert Comment

by:cricure
You can use TSPrint for RDP printing.
Remote Desktop Printing
0
 
LVL 5

Author Comment

by:bb_xpress
Yes, you can.  But the point of the article was how to do it naively without the purchase and use of third party applications.  :)
0
 
LVL 6

Expert Comment

by:Sid_F
I am having a similar problem related to the 1300 laserjet you mention. You suggested the laserjet 4m, the 4m drivers does not appear to support 2003 ?
http://h20000.www2.hp.com/bizsupport/TechSupport/DriverDownload.jsp?lang=en&cc=us&prodNameId=15044&taskId=135&prodTypeId=18972&prodSeriesId=25487&lang=en&cc=us 
0
 
LVL 5

Author Comment

by:bb_xpress
Sid, the 4M printer is inherent in cache of Windows drivers already.  You simply need to select it from the list of printers that Windows already has and it will translate without issue on the Terminal Server as it also has its own set of drivers to match.
0
 
LVL 6

Expert Comment

by:Raneesh Chitootharayil
Dear BB XPRESS;
Excellent article; many tech guys around the world are struggling with terminal service printing problems; you did a fantastic job by posting this article.
0
 

Expert Comment

by:moeshakir
Dear BB XPRESS;

Can you please help me with my question? I posted it on the heading "Cant print Locally using Windows 2008 R2 Terminal Server"

I really appreciate it
0
 

Expert Comment

by:moeshakir
Dear BB XPRESS;

This is my situation.

I have a windows 2008 R2 server which runs Terminal services. I have 6 clients using this server and none of them cant print. I have a Brother MFC 8820DN Printer and everyone else have different printers most of them are 64bit OS.

When I remotely login I see all my printers on the Server and no error message at all. It says "redirected" in the brackets. When I try to print something nothing happens, basically the print job is not sent to the printer. I tried everything from my knowledge to make it work but no luck at all.

I also installed a local PCL5 generic driver for the server to see if that helps. Nothings working.

Can you please help me Sir?

Thanks
0
 

Expert Comment

by:finkeltron
I found it's better to spend the $100 for the TSPRINT software than spend countless hours trying to get this crap working natively. Maybe Microsoft should buy TSPRINT and use it? This whole experience is a complete joke waste of time.
0
 

Expert Comment

by:drinaldi
Agree with the last comment.  TSPrint is the way to go.  What a joke Microsoft.  How come TSprint can get it to work reliably consistently and easily and you can't.  Please buy them.
0
 

Expert Comment

by:sanymil
Wow, thank you, thank you for this article. It is like that you wrote it for me. I am having similar issue with one of my clients and you gave a lot of ideas to solve that problem. Thank you again
0
 
LVL 21
This article appears to be about older pre Windows Server 2008 R2 as a Terminal Server. I have not seen these issue since Windows Server 2008 R2 was released.

Windows Server 2008 R2 printer redirection is greatly improved. I have yet to have a Windows 7/8 client not be able to redirect their local printers.  I have never has to install any printer drivers on the Server side.  Even their PDF printers are redirect.   That mean a client PC with Acrobat PDF Printer, PrimoPDF, Nitro, etc installed can print from the Terminal Server to a PDF and save it to  their PCs local hard drive!

My clients have found the upgrading to Windows Server 2008 R2 or later and Windows 7 solved all their printer redirection issues. Along with the other enhancements  gained with the upgrade to current technology,  it is worth it.

FWIW:
For older Windows Servers like 2000 or2003 I installed the free PrimoPDF software on the server and client. I have yet to have it not redirect.
0
 
LVL 17

Expert Comment

by:Spike99
I am surprised you were able to get those host-based printers to work (the HP Laserjet P1006 & 1012).  I personally wouldn't have spent so much time & effort getting them to work: they are not supported in a terminal server/remote desktop environment.  The reason is because host-based print drivers require bi-directional communication between the "host" PC or server and the printer.  They usually doesn't work as redirected printers as a result.   Even if you can get them to print on a terminal server, host-based print drivers can cause issues in a multi-user environment.  Since all processing of the print job takes place on the "host" (and none on the printer), they can result in a severe hit to the TS performance, particularly when printing large jobs.  HP doesn't support them on a TS for a reason.

Even though the HP LaserJet 1300 has a host-based driver, it is compatible with the PCL 5 printer language, so you can use a PCL driver for it, like the HP LaserJet 1200. PCL drivers are much better for use in a Remote Desktop Environment.

Here is HP's document on printers supported in a Citrix XenApp or Remote Desktop environment:
http://h71028.www7.hp.com/ERC/downloads/4AA0-8465ENW.pdf

Interesting that HP does support the HP LaserJet 1012 driver on Server 2003 despite the fact that it's host-based, but they only support driver version 5.60.1604.0.  See page 7 of that PDF.
0

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Join & Write a Comment

this video summaries big data hadoop online training demo (http://onlineitguru.com/big-data-hadoop-online-training-placement.html) , and covers basics in big data hadoop .
Loops Section Overview

Keep in touch with Experts Exchange

Tech news and trends delivered to your inbox every month