Introduction
As you might know RDS stands for Remote Desktop Services, previously known as Terminal Services and designed to have multiple user sessions hosted on a single server. Now it is called Session Virtualization. These sessions have grown out to becoming complete local desktop replacements. What activity is one of the most frequent user actions on a desktop? Exactly, printing!
Therefore, whether to allow printing from a session is not the question. The question is how to configure it in the most convenient way from the end-users perspective and easy to maintain from the administrators perspective. In this article, we’ll discuss printing in Microsoft RDS environments, what printing from a remote session was like in the past and how it evolved in today’s technology.
History
Windows NT, Terminal Server Edition
After Citrix’s MultiWin, Microsoft’s first attempt in creating a multiuser environment was Windows NT, Terminal Server Edition. This edition was very much a starting point. The operating system was a separate edition of Windows NT Server, very basic and therefore many instances were running Citrix MetaFrame on top of it. Redirecting local printers was not even an option.
Windows 2000 Server
A big step forward was made with the release of Windows 2000 Server. Terminal Services became a role within the operating system and the Terminal Server Protocol was upgraded. It now contained the first version of printer redirection. This meant that end-users would now be able to map their local printer to their remote session. Although as an administrator, you had to install and maintain printers’ drivers for all printers to be redirected. That is, if you could even find an appropriate driver that was compatible with Window 2000 Server. Aside from printer redirection, installing network printers on the Terminal Server box itself (i.e. by using a Print Server) was also an option.
Windows Server 2003 (SP1)
Another big improvement came with Windows Server 2003. The operating system became more and more multiple sessions aware and you had the ability to maintain the servers collectively. Meaning the introduction of Group Policy Objects (GPO) to manage and maintain Terminal Server Settings over multiple Terminal Servers. Amongst, the group policy settings there were settings to manage printer redirection. You could for example enable or disable printer redirection, or allow the default printer to be set. In those days, you would typically see mixed printer environments were users would have a set of network printers assigned to them and the option to redirect their local printers. But still administrators would have to install and update printer drivers for every type of printer that needed to be redirected. With SP1 for Windows Server 2003, a new feature was introduced “Terminal Server fallback printer driver behavior”. If this setting was enabled using a GPO, the Terminal Server’s default behavior would be to locate a suitable printer driver. If it did not find any suitable drivers, you could configure the Terminal Server to fall back to a default driver. The following options were available:
- Do nothing if one is not found. This is the default setting. Basically, this would mean that the fallback printer driver functionality was disabled.
- Default to PCL if one is not found. If no suitable printer driver could be found, the Terminal Server would use Hewlett-Packard compatible Printer Control Language (PCL) as a fallback printer driver.
- Default to PS if one is not found. If no suitable printer driver could be found, the Terminal Server would use Adobe PostScript (PS) as a fallback printer driver.
- Show both PCL and PS if one is not found. If no suitable printer driver could be found, the Terminal Server would show both PS-based and PCL-based fallback printers.
This was just the first step in attempting to minimize the number of printer drivers needed to be installed on the Terminal Servers. As you might understand, having a fall back driver for a printer would work for emergency scenarios but it wasn’t the ideal situation. Because of the fall back driver users would be missing specific printer properties that they were used getting on their local machines. Therefore, with Windows Server 2003 you would still be stuck with managing printer drivers. In those days, 3rd party vendors responded to this by creating tools that would be able to use the driver of the local client. I remember using Screwdrivers from Tricerat to be able to redirect all local printers without having to install drivers on all Terminal Servers. I must say it worked pretty well, and I believe that’s where the idea of Microsoft’s Easy Print started off.
Windows Server 2008
The release of Windows Server 2008 was a big relief for administrators of Terminal Servers. Microsoft introduced Terminal Services Easy Print. Using this technology, it became possible to have local printers redirected without having to install printer drivers and unlike Fall Back Printing, users would see all the printer-specific properties. We could spend a whole article on how TS Easy Print works (and maybe we will in the future :)) but for now, TS Easy Print is based on the Microsoft’s XPS format. The print jobs are now spooled from the server-side via XPS over RDP to the client-side where they are being printed by making use of the local print queue. Another advantage of this technology is that the XPS format uses much less bandwidth then regular printer redirection. Of course, there are some pre-requisites to make TS Easy Print work.
- Clients must use a RDP Client version 6.1 or higher
- Clients must have installed .NET framework 3.0 SP1
The first requirement is almost everywhere in place since SP3 of Windows XP (mostly used in those days) already contained RDP 6.1. The second requirement was a bit harder to explain to customers and end-users, since this version of .NET framework was not inside SP3 for Windows XP and had to be installed separately. Nevertheless, the Easy Print functionality that users would be getting in return definitely made it worth installing. The GPO settings for TS Easy Print are as follows:
- Use Terminal Services Easy Print printer driver first. With this setting enabled, Terminal Server would try to use the TS Easy Print driver first. If that doesn’t succeed, the corresponding printer driver on the Terminal Server itself will then try to be used. If no suitable driver is found, the printer in question won’t be redirected. You will be notified in the Event log about this.
- Redirect only the default client printer. This setting, as the name suggests, makes it possible to be able to force only having the printer redirected that is marked as default on the client. This way you can minimize the amount of printers that are redirected.
Windows Server 2008 R2 SP1
SP1 for Windows Server 2008 R2 canceled the need to have .NET framework installed on the client to be able to use Easy Print, which is now called RD Easy Print due to the name change from TS to RD. This made it even easier to implement printer redirection for Remote Desktop Services.
Printing from RDS environments today
Typically, what you would see configured today related to printing from a RDS environment will be a mix of network printers and redirected printers. Most companies would want to have office network printers to be available for RDS sessions. However, in almost every case there would be the need to have specific local printers that users tend to have on their desk. Therefore combining both network printers and redirected printers will probably be the most used and suitable printing solution.
We have already covered the GPO settings that can be used to configure RD Easy Print. But what about those network printers? Typically, you would want to assign only a specific set of printers to a user at logon, for example based on his role or his current location and having a set of printers enforced each time the user logs on. So, how would we assign network printers? Before Windows Server 2008 you would mostly see implementations based on a logon script (i.e. kix, batchfiles, vb-script etc.) that would assign printers to the user at logon and based on group membership. With Windows Server 2008 Group Policy Preferences were introduced. Using GPO preferences you have, among many other settings, the ability to assign a preferred set of printers to a user based on a specific condition (an item level target).
You can find these preferences inside the GPO at two different levels:
- User Configuration / Preferences / Control Panel Settings / Printers
- Computer Configuration / Preferences / Control Panel Settings / Printers
In this example we create a printer using the path \\printerserver01\Printer1 and set it as the default printer. We then open up the Common tab and select Item level Targeting.
Figure 1: GPO Printer Preference
Figure 2: GPO preference Common tab
When we click the Targeting button, we are presented with a dialog box in which we can configure the ILT, meaning we can configure the condition on which the GPO preference will be applied. This will make printers assignment very flexible.
In the example below, we only assign the printer if the user is a member of group in Active Directory (GG_Default_Printers).
Figure 3: Item Level Target Example
Ideally, you would want to dynamically assign printers based on the location from where the user connects. For example, only assign printers that are available in the building where the user is connecting from. It seems like the option to do this based on the membership of the client that the user connects from is through the option “Computer in Group”. However, since this GPO is applied on the Remote Desktop Server, the “Computer in Group” setting will check the group membership of the RDS server and not the client. An additional GPO Preferences group of setting which was introduced is called Terminal Session.
Figure 4: Item Level Targeting Terminal Session
Using this ILT you can base the preference on the client IP address or the client name. For example, what you could do here is assign a printer only when a user’s client IP address is in the range 192.168.20.1 to 192.168.20.255. Alternatively, you could assign a printer when a user’s client hostname start with a set of characters that refers to the client location. The options here are very diverse and the best ILT depends on the customer needs of course. Nevertheless, being able to assign printers using preferences and therefore not having to rely on logon scripts is a big improvement when it comes to flexibility, central management and maintenance of assigned printers.
Conclusion
We’ve seen how printing in session virtualization has evolved in what it is today in Windows Server 2008 R2 (SP1). Although we see paperless offices more and more, I think we can all agree that having users be able to print to their desired printers (whether their locally redirected or network printers) in an easy way is crucial in having a successful RDS environment. With Windows Server 2008 R2 SP1 Microsoft offers a complete, stable, flexible and easy to maintain printer solution for Session Virtualization out of the box.
Additional information:
