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. :)
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.
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.
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.
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.
this video explains a free download that you can incorporate into your Access databases, or use stand-alone for contact management.
Contacts -- Names, Addresses, Phone Numbers, eMail Addresses, Websites, Lists, Projects, Notes, Attachments…