So, for those that aren’t aware, or haven’t been around long enough to remember. Before BYOD administrators still had to deal with hell from users and their devices. Evil devices I spent a section of my career specializing in!
Printers! Or more specifically; cheap nasty home printers.
So before windows 2008 setting up a Terminal Server was simple
- Build a Box
- Make it a member server
- Install updates
- Install Terminal Services role
- Change user mode and install apps
- Install printer drivers (or pick them up from your group policy)
Now, that last item becomes a real PITA when you have management users with a printer at home. Typically if you’re looking at this blog you’re not working for a company that sends their staff home with an approved printer. Which means you are stuck with whatever rubbish inkjet multifunction that the salesman at your local electronics or office store could sap them for. I’m sure it does print great photos with those $50 ink cartridges and $10 paper!
Why is this a problem? Well, On Windows 2003 and earlier if the RDP client attempts to redirect the printer, the server looks at its internal driver store for the matching printer driver, fails and throws an error in the system event log of all places, now this isn’t so bad as users don’t need to know the internal workings of the Terminal Server. At the end of the day they just want to get some work done and that means a little more work on your part.
Oh hey guys, learn to ignore me while auditing servers! Haha!
Great. So your boss comes in and tells you that his new multifunction he bought last night won’t work on your trusted TS box and they absolutely need to print from the TS server, so a quick jump into the event log and you have the printer make and model all ready for a trip down consumer print driver lane.
This wasn’t really an issue with some vendors as they have proper drivers or at least just the drivers.. But some others (I’m looking at you HP!) are full of bloat for optimising images and scanning things and just general crap that isn’t in their business grade devices (100 MB for a printer driver?)
So after you remove all the bloat ware and toolbars it installs for you, then you would run into compatibility issues between the driver the user has on their pc installed fresh from the CD and the driver on the server. Forcing you to update the drivers on the user’s home pc (and forever be blamed for anything that ever happens to it again EVER) not to mention the fact these drivers are poorly written and could be the cause of issues on the TS box later on including frustrating print spooler crashes.
This method is utter madness. Certainly there must be something better.
Windows Server 2008 saw the advent of TS easy print which later got renamed to Remote Desktop Easy Print along with Terminal Services in the Server 2008r2 era. Microsoft has a great write up about it here, but I’ll quickly summize
http://blogs.msdn.com/b/rds/archive/2007/04/26/introducing-terminal-services-easy-print-part-1.aspx
Upon connecting to the TS/RDS server the RDP client sends its list of printers to the server
It spins up a virtual printer on the server similar to client redirection
It uses the TS Easy Print driver to connect the users printer
When a document is printed, it is converted into XPS format via Easy print, sent down the RDP stream where the client connects to the local print spooler and lets the local driver handle it
That’s the theory anyway. A couple of things are required for this to work
First off, the client needs to have .NET framework 3.5 installed. Secondly they need to be running RDP 7 or newer and this can be a pain to get on end users PC but manageable. I recommend ninite for getting .NET and things setup
(RDP 7 http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=20609 )
(.NET http://ninite.com/.net/ )
So this is fine you think, finally a solution that doesn’t involve fuffing about with drivers and I can leave my virgin Remote Desktop server they way I intended.
ERRRRR WRONG.
Wait, you just spent 700 odd words telling me how bad the old method was, certainly TS/RDP Easy Print is better? Well yes, kind of.
Easy print is all fine and dandy until it’s not. It’s an absolute nightmare to troubleshoot when it does go wrong. I’ve had on a fair few occasions now had printers spew forth documents written completely in Windings with a company logo in the corner because the remote user was using WinXP and didn’t have whatever font the document was originally written in, during the conversion to XPS something weird happens and it all just goes down the toilet.
To add insult to injury there is no obvious way to install the printer driver and use that instead. (Solution below)
Worse is troubleshooting the issues when they do occur. TechNet is flooded with posts of admins looking for solutions to weird and wonderful Easy Print issues, some of which have HotFixes for Win2k8 but still seem to be present in 2012.
There is now also the possibility of vendors no longer providing the clean server drivers as Easy Print “solves all your problems”.
Don’t let me dishearten you, Easy Print is a good thing if deployed right.
My advice to you is to configure Easy Print in a hybrid mode. This allows for control and driver hell when it’s needed and Easy Print for when it’s not.
Kick off your group policy manager for the domain and spin up a new policy.
Drill down to
Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Printer Redirection
Find the policy item “Use Remote Desktop Easy Print driver first” and set it to Disabled.
This should have no impact on your existing users using Easy Print but gives you the advantage of being able to manually install the print driver for said printers spewing forth Swahili instead of the latest TPS reports.
This fix doesn’t solve everything, you still have all the Pre-2008 woes to contend with, bad drivers and all. But at least now you only need to do it for the few staff that Easy Print just seems to go haywire for.
/Rant