At some point during your Terminal Server system design you'll remember that your users will probably want to print something sooner or later. Printing is an important function to users within their Terminal Server sessions, yet it has traditionally been the biggest nightmare for administrators of server-based computing systems. Ideally, printing from applications via RDP sessions should be no different than printing from any other application. It should be relatively seamless to the users, allowing them to click the print button within their application, easily select a printer, and quickly receive their printouts.

All server-based computing environments pose unique challenges to printing. This is not due to any Microsoft design flaw, but rather with the way processing occurs in server-based architectures. Because all application processing occurs on the server, users' print jobs are also created on the server. However, users' printers are usually located near and configured at their client devices. The process of getting server-generated print jobs to a client-specified printer can be complicated.

On top of that, Windows Server 2003 uses the same printing subsystem that was designed way back in the Windows NT days. The original architects of NT built the Windows printing engine as a single process meant to run on a single device. This is fine for desktop printing but can lead to problems in server-based computing environments.

In this chapter, we'll look at how Windows printing works and the printing options that are available when using Terminal Server. We'll also look at what it takes to assign printers to users when you have dozens or even hundreds of users connecting to the same server. We'll close this chapter with an in-depth case study that examines the challenges faced by one company's multifaceted printing environment.

Before we explore the challenges of Terminal Server printing and the many solutions, you need to understand how Windows printing works. After all, the actual process by which a Terminal Server prints is no different than any other Windows computer.

When you look under the hood, there are a surprising number of steps that take place whenever a document is printed. We could write an entire book detailing the exact printing process that takes place, but to be able to successfully design Terminal Server environments, you just need to know the basics.

The printing process varies slightly depending on whether you're printing to a local printer or a network printer , but the same basic steps take place in each case. Behind the scenes, there are three phases that take place from the moment you hit the “print” button in your application to the moment the finished print job appears on the printer:

When a user requests a printout from a Windows application, the application is responsible for generating its own output in preparation for printing. This output includes items such as formatting the pages properly and adding page numbers. The application processes its printer output via a Windows subsystem called the Graphics Device Interface (GDI ). The GDI generates the application's output in the form of a metafile that contains data and instructions for the printer. (This metafile is usually referred to as “print data .”)

The preferred format of this print data is Microsoft's own enhanced metafile (EMF format). EMF print data is preferred over RAW format because EMF processing is less processor-intensive and it allows for background printing.

EMF files are not printer-specific. An application would generate the same EMF file for a printout no matter what kind of printer it was printing to. The file is the common middleman between the application and the printer driver. In order to understand this, let's consider how the following line of text would be printed:

All people seem to need data processing.

The EMF file for this line of text would contain instructions for the printout, including things like the color, font, characters, and the spacing. The EMF file is a vector-based document that is very small in size.

Once the GDI has written the EMF file to disk, the print data is passed into the Windows print subsystem.

The Windows print subsystem performs many printing-related functions. The easiest way to understand what it does is to break it up into logical steps. This subsystem is responsible for several tasks:

• Receiving the EMF file from the GDI .

• Determining whether the target printer is a local printer or a network printer .

• Using the print driver to translate the EMF file into the printer's raw format. (At this point the “print data ” becomes a “print job.”)

• Temporarily holding the print job if the printer is offline or otherwise unavailable.

• Ensuring that the print job is successfully transferred to the printer.

The exact process that takes place depends upon the type of printer that the print job is being sent to. A printing component called the “print router” sends print data down separate paths depending on whether the printer is a network or local printer.

For remote printing, the unprocessed EMF file that was received from the GDI is sent to the print server to be rendered with the proper print driver.

On the other hand, if the print job is destined for a local printer, the local print spooler uses the print drivers to translate the EMF file into the printer's raw data format. This time-consuming and processor-intensive process is called “rendering.” The rendered print job contains the raw data (print job) that is specific to the printer. Take another look at our example:

All people seem to need data processing.

In this case, the rendered print job would contain the printer-specific detailed instructions and formatting needed for printing in the printer's native language. This would include resolution, paper tray information, form feed data, and the rasterized image of the page. Rendered print jobs vary in size depending on the type of printer and how well the drivers are written. In most cases, however, the rendered print job files are much larger than the EMF print data files.

Once the print job is created, the print spooler ensures that the file is transferred to the printer.

In the final printing phase, the printer receives the rendered print job from the print spooler. The printer prints this file regardless of its format. This is why printers will print garbage if the wrong drivers are used. Using the wrong drivers creates print jobs that are not compatible with the printer. However, the printer doesn't know this and it tries to print whatever it receives.

Now that you understand how printing works in standard Windows environments, let's see how printing can be configured in Terminal Server environments. Before we get too far into the details of Terminal Server printing, we need to “redefine” some standard printing terms for the Terminal Server environment.

Even with the infinite number of printing scenarios available in the real world, there are only two major types of printing scenarios available with Terminal Server. All Terminal Server printing is a variation on one of the following two themes:

• Server Printers . Server printers in Terminal Server environments are printers in which the Terminal Server has direct access to the print queue. This can include standard network printers that are accessible via a \\servername\printerna me share. It can also include printers where the print queue is located locally on a Terminal Server itself, even including printers that are directly connected to the Terminal Server. Think of server printers as printers that are “installed” on the server .

• Client Printers . These are printers that are available to a user's client device before an RDP session is launched. This can include printers that are physically attached to a client device or printers that are logically mapped th rough the network. Think of these as printers that are “installed” on the RDP client.

Figure 8.2 The various types of Terminal Server printers

It's important that you understand the differences between server and client printers in Terminal Server environments. Each type has advantages and disadvantages and is used or configured differently. For these reasons, we'll look at server printers and client printers separately in this chapter, beginning now with server printers.

A “server printer ” is any printer that is installed on a Terminal Server. In technical terms, this means that the server has direct access to the print queue. This print queue can be Windows or NetWare, client or server based. Basically, any printer that can be accessed via a \\computername\printername share is a server printer.

A server printer can also be a printer that has a print queue directly on a Terminal Server. This could be a printer that is physically connected to a local LPT or USB port of a server or an IP printer that has a print queue locally on a Terminal Server.

In Terminal Server environments, server printers work just like “regular” printers in traditional environments. Figure 8.3 outlines this process.

1. The user prints from his application running on the Terminal Server.

2. The GDI creates the EMF file on the Terminal Server.

3. The GDI sends the EMF file to the printer subsystem.

4. The print router on the Terminal Server sends the EMF file to the network print server .

5. The network print server receives the EMF file and transfers it to its print spooler. The spooler renders the print job in preparation for printing.

6. The print job is transferred to a printer port where a print monitor service transfers it to the physical printer.

In most environments, users' network printers are already being mapped via logon scripts or they're configured as part of a user's roaming profile. In these cases, you don't really have to do anything special to make them available via Terminal Server sessions. Users can even set up their own network printers if they have the permissions to connect to them.

In general, you'll notice that if the print servers are on the same network as the Terminal Servers, then printing performance is excellent. In fact, printing in this type of environment is no different than printing in any network environment. This is most often seen when the users, Terminal Servers, and printers are all located in the same building.

Unfortunately, this server printer performance is not as good in remote environments where the users and printer are located on one side of a WAN and the Terminal Server is located in another. In such cases, (as shown in Figure 8.4) the voluminous print jobs have to reach the print server over the WAN link which is also shared with all the RDP session traffic.

Figure 8.4 Server printers are not efficient when the Terminal Servers are remote

In Terminal Server environments, any printer that's available on a user's client device is known as a “client printer.” Client printers can be printers that are physically attached to the client device (perhaps via a USB or LPT port) or they can be network printers that were mapped before the user's RDP session started. Either way, Terminal Server 2003 can automatically make client printers available on the server via a user's RDP session. This lets users print to printers that they are familiar with.

Both the RDP ActiveX control (web client) and the full RDC client support printing to client printers. Some third party RDP client software is available for other operating systems, but their printing capabilities are pretty varied. (These clients are discussed in full in Chapter 10.) For the sake of this chapter we will focus only on the RDP clients from Microsoft.

Before we can look at how client printers are configured, it's important to understand how client printers are used by Terminal Server.

When a user connects to a Terminal Server, his local RDP client software automatically makes the printers he has installed locally available to him from within his server session. It does this by dynamically creating printers that print to special printer ports (also dynamically created) that point back to the client device. These printers will have a name like “ Printer name (from Client name)in Session # .” (For example, “Lexmark Optra E312 (from LAPTOP42) in session 14.”) Furthermore, these printers are configured on special ports with names like “TS001” and “TS002” (as seen from the “Ports” tab of the printer's property page. Each printer is created with permissions that allow only that user to print to it.

Technically, power users and administrators can print to any printer, so they'll see all the printers from all users on the server. Regular users, however, will only see their own printers. When a user needs to print a document from within a Terminal Server application, he invokes the print job as usual. From within his session, he'll see his client device's printers listed within the application's printing interface. To the user, these printers look like regular printers. The user has no idea that these printers are actually mapped back to his local printers through the RDP protocol.

When the user prints to one of his client printers, the process outlined in Figure 8.5 (next page) takes place.

1. The user prints from his application running on the Terminal Server.

2. The GDI creates the EMF file on the Terminal Server.

3. The EMF file is sent to the print spooler (via the print router) on the Terminal Server.

4. If the print drivers for the client printer are load on the Terminal Server, the Terminal Server's print spooler renders the print job. If the p roper drivers are not loaded on the Terminal Server, the user's print job cannot be completed.

5. The print job is sent from the Terminal Server to the client device via a printing virtual channel as part of the RDP protoco l.

6. The client device receives the print job. Because the server had the print drivers loaded for the client's printer, the print job is rendered specifically for the client's printer, and the client device's local printer subsystem can immediately process the job and send it to the printer.

Upon looking at the client printing process in Figure 8.5, you can probably see that there is the potential for a severe performance problem. The raw print job is usually quite large, and it can take a long time to transmit to the client's printer, especially if the user is connected via a dial-up line. Additionally, the performance of the RDP session can be degraded because bandwidth is being consumed by the print job that is being sent to the client.

Now consider what happens when printing to a client network printer . (Remember that a client network printer is a network printer that was mapped from the user's client workstation before their session with the Terminal Server was started.)

Conceptually, this process is similar to printing to a locally-attached client printer. However, since this is a network printer , the client must take the additional step of sending the print job to the network print server once it's received from the Terminal Server. Figure 8.6 outlines this process.

1. The user prints from his application running on the Terminal Server.

2. The GDI creates the EMF file on the Terminal Server.

3. Since the printer is a client-mapped printer, the print job is rendered on the Terminal Server.

4. The Terminal Server sends the print job to the mapped port through the printing virtual channel of the RDP protocol.

5. The client device receives the print job and forwards it to the network print server.

6. The print server receives the print job and sends it to the printer.

At first glance you might wonder why Terminal Server is not smart enough to print directly to the network print server. It would seem that doing so would alleviate the need for the EMF file to travel down from the server to the client and back. Unfortunately, in reality, this is not feasible. For example, there can be situations where the print server from Figure 8.6 is only available to the client device and not to the Terminal Server., or maybe there's a firewall on the network that only allows RDP traffic on port 3389 through.

Regardless of the specifics of a situation, the folks at Microsoft who designed Windows knew that they couldn't guarantee that Terminal Server had access to the print server. Therefore, they had to take the lowest common denominator and send the print jobs down to the client, even if that meant that in some cases the client turned around and sent the print jobs right back up to the server.

Of course an easy way to combat this potential inefficiency would be to simply map the network printer from within the user's Terminal Server session, thereby allowing the server to send the print job directly to the network print server. Sound familiar? It should, because this would be the exact description of a server printer as outlined back in Figure 8.3.

Another way to combat this inefficiency would be to use a third-party printing product, as discussed later in this chapter.

In addition to the performance issues, there's one more potential downside to using client printers. As you saw in Figures 8.5 and 8.6, a user's print job is initiated on the Terminal Server when client printer mappings are used. Because of this, the server needs to have the necessary drivers installed for the client's printer so that it can create the print job. After all, it's the server that will be creating print jobs from user sessions, not the client device.

If you're lucking enough to have an environment in which your users have only a few different types of printers, then this might not be a problem. However, if you have hundreds of users with hundreds of different printers, installing and configuring printer drivers on your Terminal Servers can be a nightmare. We'll study the use and management of printer drivers on Terminal Servers a bit later in this chapter.

Another downside to using client printers in Terminal Server environments is that in order for a user to be able to use a printer, it must (by definition) be installed and configured locally on their client device. If your users have a lot of printers already configured on their workstations, then this might be okay. However, this could also be the exact opposite of what you're trying to do by using Terminal Server. Most likely, you want to move away from having to configure things on individual users' workstations. If a user installs, deletes, or otherwise modifies their local workstation printers (not your problem), it will affect how they print from their Terminal Server session (definitely your problem).

Advantages of Printing with Mapped Client Printers

• Seamless connection of printers.

• Users see printers that they are familiar with.

• All supported local printers are available.

• Quick setup for e xisting client printers.

Disadvantages of Printing with Mapped Client Printers

• Poor print performance.

• Bandwidth intensive.

• Print jobs must be rendered on the server, which is processor-intensive.

By definition, client printers are already set up and configured on the client devices, so there is nothing else that you need to do there. All client printer mapping configuration is done on your Terminal Servers. From a high level, allowing users to print to their client printers involves two steps:

1. Install the printer drivers on your Terminal Servers.

2. Configure your servers to use client printers.

Step 1. Install Printer Drivers

Since client printers will only work when the printer drivers are installed on the Terminal Server, the first thing you need to do when using client printers is make sure that the proper drivers are installed on your server. In the real world, there are many issues associated with the installation and management of printer drivers on Terminal Servers. We'll look at the specific details in the “Managing Printer Drivers” section of this chapter.

Step 2. Configure the Terminal Server to Connect Client Printers

After the printer drivers are installed, you need to configure your Terminal Server to connect clients' printers when their RDP sessions are started. To do this, you'll have to configure Terminal Server permissions, the RDP connection listener, and the user's domain account properties.

Step 2A: Verify Terminal Server Permissions for Printing

In order for users to be able to print on a Terminal Server, users will need Read, Write, Execute, and List Folder Contents access to the print spooler's directory, %SystemRoot%\System32\Spool . Even though these are not the default settings for Windows Server 2003 “out of the box,” these settings have been a Terminal Services best practice since the beginning of Terminal Services.

Step 2B: Verify RDP Listener Configuration for Client Printer Use

With the Terminal Services Configuration tool, you can configure the client printer options for all users that use a particular connection. In the “client settings” tab section of the connection properties, make sure that the “Windows printer mapping” and “ LPT port mapping” boxes are not checked in the “Disable the following” section. Obviously, checking either one of these boxes will prevent client printers from being mapped.

Also, if the “Use connection settings from user settings” option is checked, then you will need to verify that the user's account is properly configured for client printer mapping.

Instead of configuring these options as an RDP connection property on each server, you can apply them via a GPO . (See Chapter 6 for more information about GPOs.) These client printer mapping properties can be found within a GPO via the following path:

The settings configured here will then apply to any Windows 2003 Terminal Server that is in an OU where this GPO has been applied.

Step 2C: Configure User Account Settings

You can also configure client printer connection settings on a user-by-user basis. In Active Directory environments, the client printer mapping properties are part of the user's AD object (Active Directory Users and Computers | User Object | Environment Tab).

Selecting “Connect Client Printers at Logon” will cause the user's client printer to automatically be created when they log onto a Terminal Server. When the user logs off and all his print jobs have printed, the printer is automatically deleted. If you do not set the “Connect Client Printers at Logon” option, a user will still be able to manually map to his client printer, it just will not be created for him automatically.

Remember that your Terminal Server must have the proper printer drivers installed for users to be able to print to their client printers since the print jobs are rendered and spooled on the server.

At first glance, this doesn't seem like it would be too much of a problem. However, there can be complications. For example, how does a Terminal Server know if it has the proper driver installed for a user's client printers?

When a user with client printer mapping enabled starts a Terminal Server session, the server checks the driver names of the printers install on the user's client device. It then looks at all the names of the drivers that are installed on the server. If the two names are the same, the server knows that it has the appropriate drivers installed to support that printer and the printer is automatically mapped for that user's session. However, if there's not an exact match, then that printer is skipped and the Terminal Server moves on to the next client printer.

For example, if the Terminal server has a driver installed called “HP OfficeJet 40xi” and the RDP client has a printer installed that uses a driver called “HP OfficeJet 40xi,” the server will know that there's a match. However, if the client has a printer that uses a driver called “HP DeskJet 500,” then obviously the server knows that there is not a match.

This works fine in when Windows 2000 and Windows XP clients connect to Windows 2000/2003 Terminal Servers. Since all these platforms use the same printer drivers , the names of the drivers are guaranteed to match. However, this leads to an interesting situation if your client devices are running anything prior to Windows 2000, including ME, 98, 95, or NT. The problem arises from the fact that the same printer driver written for two different versions of Windows doesn't necessarily use the exact same printer driver names. For example, the Windows 95/98 version of the driver for a LaserJet 5P printer is named “Hewlett Packard LaserJet 5P,” while that printer's Windows 2000/XP/2003 driver is named “HP LaserJet 5P.” To humans, these two names are the same, but to Terminal Server, the fact that the client's printer uses a driver that starts with “Hewlett Packard” and the server's driver starts with “HP” means that the server thinks these two names are different. To a Terminal Server, these two names are no more similar than the names “HP LaserJet 5P” and “Tandy LP-1000.”

In the situation of a client connecting from Windows 98 with an HP LaserJet 5P printer attached, the server would not map that printer—even if it had the proper drivers installed—since the print drivers ' names didn't match.

To address this, it's possible for you to correlate the names of printer drivers on your server with the names of printer drivers on your users' clients. For example, you can tell the server that the client print driver “Hewlett Packard LaserJet 5P” is the same as the server print driver “HP LaserJet 5P.” Keep in mind that you only need to do this if (1) you are using client printer mappings and (2) your clients are not running Windows 2000 or Windows XP.

In order to enable printer driver mapping, you need to place a file on your Terminal Server that contains the pairs of client and server driver names. In previous versions of Terminal Server, this was done via a mapping file called “ wtsuprn.inf ” located in the %systemroot%\system32\ folder. However, this file does not exist by default in Windows Server 2003, and Windows does not look for it.

To create a mapping file in Windows 2003, you must add two registry values:

Key: HKLM\SYSTEM\CurrentControlSet\
Control\Terminal Server\Wds\rdpwd

Type: REG_SZ

Value: PrinterMappingINFName

Data: Name of the .INF file that contains printer driver name mappings. (For example, c:\winnt\inf\printsubs.inf)

Key: HKLM\SYSTEM\CurrentControlSet\
Control\Terminal Server\Wds\rdpwd

Type: REG_SZ

Value: PrinterMappingINFSection

Data: Name of the section in the .INF file that contains the actual mappings. (For example: Printers)

Once you've finished adding your registry entries you should restart the spooler service or reboot the Terminal Server to allow these changes to take effect. After you add the new registry values, you'll need to create an .INF file that includes the driver names you want to use for client-side to server-side mappings. You file will look something like this:

You can create this file with Notepad and save it within an .INF filename extension in the %SystemRoot%\System32\ directory. Using this example, you would specify the printsubs.inf file name that you just created in the PrinterMappingINFName registry value and "Printers" in the PrinterMappingINFSection registry value.

The printer driver names you place in this file are case sensitive and space sensitive. Basically, everything between the quotation marks must match the printer name exactly . As with many .INF files, the leading semicolon (;) indicates that the line is a comment and should be ignored. When you use this file, be aware that you can have more than one client printer mapped to a single server print driver.

Creating a printer driver mapping file is more of an art than a science. Fortunately, the some very kind people run a website called www.printingsupport.com . This site has downloadable printer mapping files that you can use in your environment.

Once you get your mapping file created, you'll need to make sure that it exists on every Terminal Server where you want these printer driver mappings to be applied. Keep in mind that this mapping file merely tells the server which of its already installed drivers correlate to client printer drivers . You'll also need to install the actual printer drivers on your Terminal Server when you use this file.

If your .INF mapping file contains any syntax errors (other than a misspelled driver name inside the quotes), you may receive the following messages in the event log:

Event 1110: "Error processing ntprint.inf. If the file on the system is corrupt, you can restore it from the installation media.

This message is misleading since it refers to “ntprint.inf ” and not your custom filename. This error usually means that the custom .INF file that the system is processing has errors in it. The most common error is that you will create a custom mapping file with no entries in it. You new .INF file must have at least one mapping in its printer name mapping section and the lines containing your mappings must not start with a semicolon. If the custom .INF file has a blank name-mapping section, you'll receive the Event 1110 errors in the event log.

Finding the Exact Printer Driver Names

In order to be able to map printer drivers between your Terminal Server and clients, you need to know the exact printer driver name for both the server and the client. You can get this information from the printer properties dialog box (Right-click Printer | Properties). On Windows 9x computers, the driver is listed in the “Print using the following driver” box. On Windows 2003 servers the driver box is on the “Advanced” tab. Because the name of the printer driver can vary on the workstation depending on the platform, make sure you have the right driver name for the each client platform that is being used. For example, if you see “HP LaserJet 4000 Series PCL 5/5e,” be sure to note all the punctuation, spaces, and case sensitivity.

If you already have the driver installed on your Terminal Server, but you do not have a printer installed where you can check the properties, you can always view the driver name from the list of drivers installed on the server. Just open the Printers applet in control panel and use the “Drivers” tab from the File | Server Proprieties applet. This will show you a complete list of drivers installed on your Terminal Server.

Once the driver names have been added to your mapping file, your users will be able to print to their client printers from Terminal Server sessions. You do not have to reboot your server after you change the mapping file. Simply log the user off and then back on.

Sequencing of Client Printer Driver M apping

When a user with client printers logs on to a Terminal Server, the server goes through several steps to try to find an appropriate printer driver to use:

1. The list of the client's local printers is enumerated from the registry.

2. The server queries the printer driver string names on the client.

3. The server looks for the client printer driver name in the printer driver mapping .INF file.

4. If no match is found, the server looks for a driver name match in the [Previous Names] section of built-in “ ntprint.in f ” file.

5. If the server still cannot find any mapping information, it checks to see if the driver is already installed. To do this, it looks at HKLM\System\CurrentControSet\Control\Print\Environments\Windows NT x86\Drivers\ in the registry.

6. If it can't fi nd the printer driver information in the registry, that means that the printer driver is not installed. As a last resort, the server will check to see if the client's printer is one of the hundreds of standard printers that are available with Windows. To do this, it goes back to the built-in ntprint.inf file and looks in the [Manufacturer] section. If a match is found, the server automatically installs the driver by extracting in from the built-in Driver.cab file located in the %systemroot%\Driver Cache\i38 6 folder on the server.

7. Once any of these steps is successful, the server creates a dynamic printer port that maps back to the real printer on the user's client device. This port is mapped through an RDP virtual channel . Then, the server creates a printer object with the appropriate permissions (and using the appropriate drivers) for the user.

8. If the server is not able to find an appropriate driver using any of the previous methods, then the client's printer is not mapped for the session and an event that states that the printer could not be redirected is written to the event log.

9. The server starts this entire process over again for the next printer on the client's list.

In general, Terminal Server 2003's printer driver installation process works fairly well. There used to be problems with incompatible drivers getting installed and crashing the server, but that hasn't really been a problem since the NT 4 days. (Back then, a lot of regular drivers would blue screen the server if multiple users tried to print at the same time. Ouch!)

One of the big concerns that many administrators have is the number of printer drivers that are installed on their servers. Since users with all types of printers cause drivers to be installed on the Terminal Server, the server will need to manage a lot of drivers. This can be a problem whenever client printers are used, regardless of the client operating system. (Remember that the mapping file is helpful when using older clients, but even new Windows XP clients still cause printer drivers to get installed on your Terminal Servers.)

In order to prevent too many drivers from getting installed on your server, there are two options that you can implement:

• Map multiple client printer drivers to a single server driver.

• Use a third-party “driverless” printing solution (discussed later).

Let's look at how we can use the printer driver mapping .INF file to control the number of drivers that are installed on a Terminal Server. Thinking back to the previous description of this file, you'll remember that it can contain multiple client driver entries for a single server driver. This means that you can use a single printer driver on your server to support dozens (or even hundreds) of different client printer models. For example, it's widely known that many LaserJet drivers will work with other LaserJet printers. You might decide that you want all client printers called HP LaserJet 4, HP LaserJet 4M, HP LaserJet 4 Plus, HP LaserJet 4M Plus, HP LaserJet 4L, and HP LaserJet 4ML to use the same “HP LaserJet 4” driver. This will let you provide a single server driver for six different printer models. To do this, you could configure your .INF mapping file to look like this:

In fact, HP has a completely “generic” LaserJet driver (called “HP LaserJet”) that you could use for every single LaserJet printer, and a generic DeskJet driver (called “HP DeskJet”) that you could use for every single DeskJet printer. Adding all these entries to your .INF file would allow you to support hundreds of different types of printers with only two different drivers.

You can also use these “alternate printer mappings” to map a driver from one vendor to support a printer from another vendor. In addition to having fewer drivers to support on your servers, this can also lead to a potential performance gain. This can happen because the spooled print file, which is transmitted down the RDP stream to the RDP client, is created with the printer driver. All printer drivers are not created equal. Some printer drivers are very efficient and create very efficient spool files. This is usually the case with name-brand printers. However, the whole reason that we need to use client printer mapping in the first place is because we, as administrators, do not have control over the printers that our users have connected locally to their clients. They probably didn't buy the name brand printer that we recommended. Instead, they bought the cheapest $25 printer that they could find at Walmart. These printers tend to have very inefficient drivers, which means that they can easily create spooled print files that are several megabytes per page. (To be fair, the people who created these drivers probably never imagined that anyone would actually want to transmit the spooled print files across a slow network.)

To combat this, you can usually find alternate drivers that work for some printers that are much more efficient than the printer's native drivers. You can also use alternate black-and-white drivers for color printers. By definition, black-and-white drivers will produce smaller spool files since they're monochrome instead of full color. Of course, your users will not be able to print in color, but monochrome printing is better than nothing.

All this alternate printer driver mapping leads to one question: Which drivers can successfully be substituted for which printers?

Of course you can find out by trial and error on your own, but most likely you have better ways to spend your time. Fortunately, the Internet is full of free resources like www.printingsupport.com whose sole purpose is to provide printer driver mapping information for Terminal Server administrators.

The only real drawback to using alternate printer driver mapping is that some of the functionality of the original printer driver on the Terminal Server may not work on the printer. These functions are usually minor, like multiple paper tray settings, stapling, or duplexing options.

As discussed previously, the architecture behind the use of client printers is fundamentally inefficient since large spooled print jobs must be sent via the RDP stream to the client to be printed. Even though some of the other printing methods (such as server printers) are much more efficient than using client printers, the convenience of client printers is a compelling reason to use them. Because of this, there are some aspects of their performance that can be addressed, including:

• Reducing the DPI of the printers.

• Implementing a third party printing solution.

Reducing the Printer DPI Settings

Because the entire spooled print job must be sent to the client when client printer mapping is enabled, users with slow connections may see degraded session performance. This amount of degradation is generally proportional to the size of the print job being sent. Therefore, reducing the size of the print job reduces the impact printing has on the client session. By reducing the DPI of the printer from 600 DPI to 300 DPI, you essentially reduce the print job size by 75%.

Of course an additional benefit of this is that print jobs finish faster since the amount of data being transmitted is smaller. The drawback to this is that jobs that require a high resolution will look “grainy” and this will not be acceptable to some users. For normal text, however, 300 DPI is just fine.

Whether you use client-mapped printers or server printers, you'll need to have printer drivers installed on each of your Terminal Servers. Consequently, you will need to spend some time thinking about how to manage those printer drivers. Before we address this issue, however, let's look at what printer drivers really are, how they work, and how they're stored on Windows servers.

Fundamentally, Windows printer drivers translate print jobs from an enhanced metafile format, which is printer-independent, into the native language that can be understood by a printer. This is why a printer prints garbage when you use the wrong driver. Printer drivers need to be installed and registered on a computer before they can be used.

Two things happen when you install a printer driver onto a Terminal Server or Windows 2000 server. First, the necessary printer driver files are copied from the source location to the server. The server stores printer driver files in the %systemroot%\system32\spool\drivers\w32x86\3\ folder. In this path, the “ w32x86 ” signifies an Intel Windows 32-bit platform, and the “ 3 ” signifies the version of the printer driver (3 = Windows 2000/XP/2003).

Second, the driver's details are written to the registry in this path: HKLM\System\CurrentControlSet\Control\Print\ Environments\Windows NT x8 6\Drivers\Version-3\. Similar to the file path, a Version-3 key means that the driver is a Windows 2000/XP/2003 driver.

User's individual printer settings, such as print, duplexing, and paper tray options, are stored in the HKCU\Printers registry key. These settings are user-specific and stored in their profile, just like any other customized Windows settings.

Installing print drivers onto a Terminal Server is no different than installing printer drivers onto any Windows computer.

The easiest way to install a driver without actually installing a printer is via the “Printers and Faxes” applet. (Start | Printers and Faxes | File Menu | Server Properties | “Drivers” tab | “Add” button) On a Terminal Server, it's only necessary to add the Windows 2000/XP/2003 version of the driver, since you're only installing the driver so you can print from server sessions.

If you have a lot of drivers to install, you can script the process using rundll32.exe to call the printui.dll (the Printer Properties User Interface).

If you're only using printers whose drivers are built-in to Windows 2003 (via the “ driver.cab ” file discussed previously) then you don't really have to worry about driver installation since the process is automatic when the printer is installed. However, if you have a number of drivers that are not part of the Windows 2003 install, you can script the following command to install a large number of printer drivers at once:

To use this command, replace Driver Name with the driver's name as it appears in the .INF file, replace Version of Driver with the platform for which it was written, (generally Windows 2000 or XP) and replace the \\Source\print.inf with the path and .INF filename for the printer driver. For more information on using rundll32.exe for installing and removing printers and drivers, run “ rundll32 prinui.dll,PrintUIEntry /?” from a command prompt. When using this command, note that there is a comma with is no space between the word prinui.dll and PrintUIEntry .

When you delete a printer from the “Printers” folder on one of your Terminal Servers, the drivers are not uninstalled from the server. This can be a problem if you've identified that a certain printer driver causes problems, since you need to be able to remove that driver from the server to prevent clients from using it.

Fortunately, the Printers and Faxes applet in Windows 2003 (and 2000) can also be used to remove drivers from your Terminal Server. (Start | Printers and Faxes | File Menu | Server Properties | “Drivers” tab | “Remove” button) Of course this will only remove the driver if no printers are currently using it.

Alternately, you can also use the “rundll32” command we used previously to remove the print driver. All that is required is the modification of a couple of switches. The cool thing about using the rundll32 method is that it can even be done from remote machines. Here are some examples of how to use the command line to remove a local driver and a driver from a remote server.

6. Delete the referenced driver files from the %systemroot%\ system32\ spool\drivers\w32x86\x folder. If you have multiple pri nters installed, you may want to copy the driver files to a temp orary location before you delete them outright, because many similar types of printers use the same driver files.

7. If you're not able to delete the files, you will need to disable the spooler, reboot, and delete the files again. After you do this, reset the spooler to “automatic” startup.

8. After the print drivers have been removed, you should reboot the server.

Occasionally you will need to figure out which drivers a printer uses that you haven't installed yet. This is especially handy if you allow your Terminal Server to automatically install any needed printer drivers .

Every Windows 2000 and Windows 2003 server has a “master list” of default printers that it supports and the drivers that each printer needs. That master list is stored in the %systemroot%\inf\ntprint.inf file. You can open this file in a text editor to see which drivers each printer will request. Ntprint.inf is organized by manufacturer, with individual printers and their drivers listed under the manufacturer's section, as shown below.

One of the printing-related challenges that you'll face as an administrator of a multiple server environment is that each Terminal Server maintains its own list of configured printers and locally installed print drivers . Each Terminal Server is completely unaware of the printer configuration and installed drivers of the other Terminal Servers.

Further complicating this is that as an administrator, you'll have no idea whether a printer driver has been updated or installed unless you view each server and driver individually.

In addition to this, server printers and their configurations are stored locally on each server and must be added, removed, or modified on every server to maintain a consistent environment. This leads to a management nightmare in environments with hundreds different client printers.

In a load-balanced or clustered server environment, each server must be configured identically. This means that drivers, printers, and printer configurations should match on all servers in the cluster. Doing this manually in a server cluster of 5 servers with 100 printers would be extremely time consuming. Now imagine those same printers in a 20- or 30-server cluster, and you'll quickly realize that you need a better way to manage drivers.

There are really only a couple of ways to get both the Windows print drivers and the server printers you have created on a Terminal Server to other servers:

• Replication using Print Migrator.

• Manual replication.

• Use a third-party printer management tool (discussed later in this chapter).

Print Migrator is a tool from Microsoft that can be used to replicate printer drivers between servers. (Since Microsoft is always changing things on their website, the easiest way to find this tool is to do a search on Microsoft.com for “Print Migrator.” The version discussed here is 3.1.)

Printer Migrator allows you to back up printers, print queues, ports, printer drivers , and printer shares to a .cab file. You can then restore the settings of that .cab file to another server. You can even use this tool to migrate printers between different versions of Terminal Server.

Now that you've completed the work needed to ensure that various printers will be available to the users on your Terminal Servers, you need to provide a method for users to access their printers. This is easy if you're using client mapped printers because the printers are automatically created for the users.

However, client printers aren't always an option in the real world, so server printers must be used. When using server printers, you need to think about how your users will access these printers. Will you assign certain printers to certain users? If so, how will you do this? Maybe you want to allow all users to be able to use all printers? If this is the case, how will users know which printers they should use? We'll look at two strategies to answer these questions:

Once you decide that you would like to control which printers your users are able to print to, you need to determine how to provide that access. Setting permissions on printers is important, but permissions alone won't configure a printer for a user. For example, if you want the user “brian” to print to the \\printerserver\fastlaser printer, you can edit the properties of that print queue and grant “brian” print permissions. However, how will Brian know how to access that printer? Is he smart enough to be able to browse the network to the \\printserver computer, and then select the fastlaser printer? Most likely, if you decide that Brian should use the \\printserver\fastlaser printer, you need a way to assign that printer to him so that when he selects “print” from a Terminal Server application, the \\printserver\fastlaser printer shows up in his printer list.

There are three methods that you can use to assign server-based printers to users:

• Map printers in users' logon scripts.

• Map printers as part of a user's profile and policy settings.

• Install the printer locally on the server and configure its permissions.

One of the most tried-and-true methods of making printers available to users is to map them via a logon script. (Logon scripts were covered in detail back in Chapter 6.) When it comes to printing, there are a few different ways that you can use logon scripts to map users' printers.

One of the cool things about using logon scripts to map printers is that you can incorporate conditional branching into the scripts based on a user's group membership. That way, you can give a user access to a printer simply by adding them to the appropriate Windows group. You can even set the permissions of a printer based on the same user group.

Command-Line Printer Mapping

You can use the same “rundll32” from the printer drivers section of this chapter to map user connections to network printers. (This method replaces the older, less-flexible “ con2prt.exe ” utility.) To do this, add the following line to a logon script:

rundll32 printui.dll,PrintUIEntry /in \\ printserver \ printer

Again, make sure that you have a comma with no space between the words “ printui.dll ” and “ PrintUIEntry .” You can add this command multiple times in a script if you need to map multiple printers.

Mapping Printers with Kixtart

If you've chosen to use Kixtart as the language for your logon scripts, you can use its own native capabilities to connect to network printers. For example, the following Kixtart code checks to see whether the user is in the “ PrinterGroupName ” Windows group. If he is, it adds the \\printserver\fastlaser printer connection and sets it to be the default printer for the user.

if ingroup(“PrinterGroupName”)

addprinterconnection (“\\printserver\fastlaser”)

setdefaultprinter (“\\printserver\fastlaser”)

endif

Many Terminal Server administrators use code like this, adding this code segment for each printer in the environment. This can allow them to create an all-encompassing logon script that maps the proper printers based on users' group memberships.

Another option for ensuring that users can easily access their printers is to use roaming profiles. By doing so, your users will only have to connect to a printer once. After that, the printer connection will become part of their profile and will automatically be restored whenever they logon. See Chapter 6 for full information about using roaming profiles.

The last method of assigning printers is not exactly a “best practice,” but it can work well in smaller LAN environments that don't have too many printers. To use this method, you install the printer “locally” onto a Terminal Server. This does not mean that the printer must be physically attached to the Terminal Server. It just means that you add the printer to the Terminal Server as a local printer instead of a network printer . To do this:

1. Logon to the Terminal Server as an administrator.

2. Start the “Add Printer” wizard.

3. Select “Local printer attached to this computer.”

4. Make sure that the “Automatically detect and install my Plug and Play printer” box is unchecked.

5. When asked, cr eate a new port instead of using an existing port.

6. Select Standard TCP/IP port.

7. Type in the IP address of the printer or print server.

8. Configure the options for type of port detected on the IP address you specified.

Following this procedure creates a shared print queue on the Terminal Server. Even though this queue is for a remote printer, the server treats it as a locally installed printer. By default, all users that run sessions on a Terminal Server are able to print to local printers on a server, meaning that all users will “automatically” have access to this printer.

You can modify the permissions of one of these newly-installed local printers so that only certain users or groups can print to it. What's cool about this is that users won't see a printer that they don't have rights to print to, so you don't have to worry about any additional configuration.

The major downside to this method is that since the print queue is local to the Terminal Server, the server's printing subsystem will spool the file locally and send it across the network in its raw data format instead of as an EMF file. (In some cases, such as when some types of JetDirect cards are used, this is always the case anyway.)

Instead of assigning printers to your users, you may have an environment in which users need to be able to choose their own printers. This makes your job much easier. If security is important, you can still set the printing permissions on the printers that you don't want everyone to be able to print to.

If you simply give a user permissions to print to a network printer , that printer will not be automatically set up for the user. However, the user will be able to browse the network and connect to the printer if he needs to print to it.

If your users are able to configure their own printers via Windows Explorer or the “Printers” folder in the Start Menu when using a desktop session this may be fine. However, in the real world, many people choose not to allow users to connect to the Windows desktop or Windows Explorer and instead only use single application connections, and thus users are not able connect to network printers since they have no interface to do so.

With that problem in mind, many administrators will give the users a connection to the server that launches the Printers folder. Of course this is an extra step for the end user but it allows them access to a resource without giving them a full server desktop.

Connecting to the Printers folder is very easy to do. The Printers folder does not have its own executable; it's actually built into the Windows shell (explorer.exe). These types of Explorer shell components are called “shell extensions.” Each shell extension has its own GUID, which is like a serial number that differentiates it from all other shell extensions. Information about different shell extensions are contained in the following registry location: HKEY_CLASSES_ROOT\CLSID\.

In this case, the Printer folder's unique GUID is {2227A280-3AEA-1069-A2DE-08002B30309D}.

Any Windows program can access a shell extension by calling explorer.exe and requesting the GUID of the extension it wants. You can even create an initial application that points to the Printers shell extension. Here's a neat trick to show how that shell extension will work:

1. Create a new folder on your Windows desktop.

2. Name the folder “Printers.{2227A280-3AEA-1069-A2DE-08002B3030 9D}” with no spaces anywhere in the name.

As soon as you press Enter, the icon for the folder will change into the Printers folder icon. When you open that folder it will look just like the Printers folder from the start menu. To make the Printers folder available as a stand-alone application, you need to create a command line that launches a folder like this. Here are the steps to take:

1. Create a folder called “Printers.{2227A280-3AEA-1069-A2DE-08002B30309D}.” Make sure that there are no spaces anywhere in the nam e .

2. Put that folder somewhere it can be launched. For example, use the c:\print\ directory, so that the full path of your folder is c:\ print\Printers.{2227A280-3AEA-1069-A2DE-08002B30309D}\.

3. Now, all you need to do is launch that folder with certain command-line switches . However, you need to first make a copy of explorer.exe. Your copy can be called anything except explorer.exe. This will force your command to open a new instance of explorer.exe, since yours will have a different name than the backgr ound copy that is already running.

4. Put the new copy of explorer.exe (Let's call it printexplorer.exe) into the m:\print\ folder.

That command line begins by launching printexplorer.exe with several command-line options. The /n option tells explorer to open a single-paned window. The /root option tells explorer to open this window as the root, preventing users from being able to click the “Up” folder to browse back up through the directory structure. The command ends with the full path to your custom folder, telling explorer which folder should be used as the root.

By this point we've examined all aspects of printing in Terminal Server environments related to out-of-the-box tools and techniques. However, even considering everything we've seen so far, troubling issues can still arise, including:

• Printer drivers must be installed and managed on every Terminal Server for each client printer in use in your environment.

• Client printing performance is poor, both in terms of the amount of data that must be sent across the network and the server resources required to render the print jobs.

• There are no good out-of-the-box solutions for situations in which RDP clients and print servers are on one side of the WAN while the Terminal Servers are on the other (as outlined back in Figure 8.4).

Fortunately, several third-party software printing solutions are available to address these issues. The four most popular vendors now, in alphabetical order are:

• Emergent Online (EOL) : a fairly large consulting and training company that also creates various software packages to help administrators with many thin-client situations. They offer several printing products that can help with many different aspects of printing. Their website is www.go-eol.com .

• ThinPrint : a German company with a large US presence. As their name implies, they focus entirely on printing in mobile and low bandwidth environments. You can find them at www.thinprint.com .

• triCerat Software: offers several products that can help you simplify the management of server-based computing environments, including several printing products. More information is available at www.tricerat.com .

Because there are drawbacks to Terminal Server's out-of-the-box printing solutions, and because third-party tools are so popular, it's worth considering them. As for recommendations, we'll study the printing challenges and how third-party tools are used to address them from a technical standpoint. We will not analyze each vendors' products and provide reviews. (Product review information is available online at www.brianmadden.com .)

After reading this section, you'll have a true understanding of why these products are needed and how they can help, enabling you to explore the different printing vendors and accurately assess their offerings. All four vendors named here offer 30-day trial versions of their products. You can find a complete list of links with more information in the Appendix.

The technical design information provided here together with the online information about these four vendors should provide you with enough information to decide how to support the printing challenges that arise in your environment.

The universal print driver products from EOL, Qnetix , and Citrix allow you to install a single “universal” print driver on your Terminal Server that is then used for every printer. (This driver does not, however, work with specialty printers such as vector plotters, label printers, and barcode printers.)

When a user prints, the Terminal Server's print subsystem uses the universal driver to render the print job into either a PDF file or PCL file (depending on the product). Then, the print job is transmitted to the client device where the local printing subsystem forwards it to the appropriate print queue. This entire process is laid out in Figure 8.7.

• Universal print driver products allow printing to any printer without having to install different drivers on your Terminal Servers.

• You don't have to worry about what kind of client printer is used. It can be replaced without having to notify the server administrator.

• PDF / PCL files are smaller than raw print jobs, thereby increasing the speed of the printout and lowering the impact on the network. (Furthermore, some of the products compress the PDF/PCL print data .)

ThinPrint and triCerat 's products fall into the second group of third-party printing products known as “EMF -based” printing products. TriCerat has a product called “ScrewDrivers ,” and ThinPrint's product is called “ThinPrint.”

EMF -based printing products are technically superior to UPD -based printing products, but they are also more expensive.

Both triCerat ScrewDrivers and ThinPrint install a simulated print driver on the server that receives print data from the GDI . This approach is similar to that of UPD -based products. However, unlike those products, these EMF -based products do not render the print job on the server. Instead, they send the device-independent EMF file to the client device. From there, triCerat or ThinPrint client software forwards the EMF print data to the client's print subsystem. The client device renders the print job and sends it to the appropriate printer. Figure 8.8 illustrates this process.

4. The third-party software compresses and transmits the EMF file to the RDP client. It is usually transmitted through a virtual channel of the RDP protocol, although ThinPrint has the additional option to transmit it directly to the client via TCP/IP outside of the RDP protocol.

5. A third-party software component on the client receives the EMF file.

6. The third party software transfers the EMF file to the local print spooler on the client device.

7. The client device's local print spooler spools and renders the print job.

8. The print job is transmitted to the client's printer, just like any print job in a non-Terminal Server environment.

Often, Terminal Server environments are designed so that the users are at one location and the Terminal Servers are at another location. This design is preferred in many cases because it's desirable to place the Terminal Servers close to the data sources, usually located at corporate offices. One problem with this architecture is printing. Typically, the location that houses the users has its own print server, as is often the case with remote offices or factory floors, shown in Figure 8.9.

The problem with this design is that the WAN is not used efficiently. If client printers are used (see again Figure 8.5), the Terminal Server will spool the entire print job before it's sent across the WAN. Alternately, the printer could be configured as a server printer (see again Figure 8.3). However, with this configuration, the print job would still be spooled on the Terminal Server. Either way, inefficient print traffic is sent across the WAN.

The third-party tools outlined previously offer some relief in this scenario as well. The UPD -based tools send the PDF or PCL data to the client, and the client then invokes its local print subsystem and prints the document as normal.

The EMF -based solutions send the compressed EMF data to the client, where (again) the client invokes its local print subsystem and prints the document as normal.

On the surface, it doesn't appear that there are any problems with the third-party tools as outlined. But what happens if your client device is connected via a low-bandwidth connection? Or if your client device is running on a platform not supported by the products listed previously?

Fortunately, there is a solution here as well. Some third-party vendors offer products by which the print information is sent directly to the print server, completely bypassing the client device. (In effect, the print server becomes the third-party software client.)

The exact implementation of this process depends on the vendor. UPD -based vendors such as EOL and Qnetix have solutions by which they can send PDF files directly to print servers, and ThinPrint can send EMF print data directly to the print server.

The “standard” advantages and disadvantages of UPD -based and EMF -based solutions apply in this scenario also. The EMF-based solution offers better performance and quality at a higher price than the UPD-based solutions.

Dina's Gourmet has decided to implement Windows 2003 Terminal Servers to provide several core applications for their users. They have 13 office locations and about 950 users. At this point, the project team has taken an inventory of their locations and users. Based on inventory findings, they were able to put together the basic design of their Terminal Server environment. Now all they need to do is figure out how to print. The project team decided that it would be easiest to create a solution based on the type of printing scenario. In looking at their Terminal Server system design, they realized that there were basically four different printing scenarios:

• Main Office . There is 1 main office with 550 users and 14 Terminal Servers. All printing is handled by local print servers.

• Regional Offices . There are 2 regional offices, each with 150 users and 5 Terminal Servers. All printing is handled by local print servers. However, these users will also need to print from sessions running on Terminal Servers at the main office.

• Small Offices . There are 10 small offices, each with 5 to 15 users. These offices do not have local Terminal Servers—all their users run applications off of Terminal Servers at the main office. Each of these small offices has a local file server that doubles as a print server, with a laser printer and a color ink jet printer.

• Home Users. There are fifty users that work from their homes. Each has a local printer connected to his laptop computer. The IT department had issued a “Home Office Supported Equipment” list to the departments that listed four different printer models that would be supported.

In addition to identifying the different printing scenarios, the project team also created a list of business goals for their Terminal Server printing environment. These goals included the following:

• Users should be able to log in anywhere and be able to print.

• The printing process cannot be too confusing for the users.

• The printing process must work at a reasonable speed.

Keeping these three printing goals in mind, the project team decided to address each printing scenario separately, beginning with the main office.

At the main office, users' printers are automatically mapped via their logon scripts. Because the project team wanted the users to have the same environment when they logged onto a Terminal Server as when they logged onto their local workstation, the users will run their standard logon scripts (except for the virus update section which does not run if it detects that the user is logging on from a Terminal Server). Because the printers are configured via logon scripts, there will be no issues configuring printers for different users.

Some project team members commented that printing performance would actually be faster when printing from Terminal Server than when printing from workstations since the Terminal Servers are in the data center two racks down from the print servers. Print jobs generated by users on Terminal Servers don't even have to leave the data center.

There was only one issue with the network printers at the main office that the project team had to address. That issue dealt with printer drivers and the drivers that need to be installed onto the Terminal Servers. Some project team members wanted to install all of the drivers for all of the printers; other team members thought that only basic, generic drivers should be installed. To fully understand the difference of opinion, let's probe deeper into this issue.

Dina Gourmet has eight different types of network printers in their main office. Three-quarters of these are HP LaserJets. The rest are more specialized, such as color printers and dot-matrix printers for multipart forms. Some project team members felt that all of the LaserJet printers should use the same driver, most likely a LaserJet 4 driver. While they might lose some functionality of the more advanced printers, they would not have to support very many drivers.

Other team members felt that they could easily support eight different printer drivers . They pointed out that because these were all network printers, there was no chance that non-supported printers would ever be used. There was no risk that they would ultimately have to support hundreds of printer drivers.

In the end, this driver issue was escalated all the way up to the CTO. His vision was pretty compelling. He said, “We have already spent a lot of money on fancy printers that can duplex, collate, staple and bind. With our vision of moving everything to a server-based computing model, it seems that Terminal Server will be a key part of our infrastructure for the next few years. For that reason, we should do everything we can to ensure that we are able to realize the full benefits of our printers in the Terminal Server environment.”

With that, the project team decided to install all of the native printer drivers on their Windows 2003 Terminal Servers.

Dina Gourmet has two regional offices, each with about 150 users. Most applications that users need to access will be served from local Terminal Servers. However, a few users will need to access some database applications from Terminal Servers located at the main office. In either case, all printers at these regional offices are network printers. The print servers, which are all Windows 2000, are located locally at the regional offices.

For the most part, printing in the regional offices mirror the main office, with users receiving their printer mappings via logon scripts. The users running RDP sessions on local Terminal Servers will have extremely fast and reliable access to the printers.

The only issue here relates to those users who need to print from applications running on the Terminal Servers located back in the main office. In order to figure out how printing should be configured for them, the project team conducted an interview in order to create a “printer user's profile.” Their questionnaire addressed all printing information that the project team would require to determine the type of printer support needed.

The following questions were asked of users to create the printer user's profile:

• How many different printers do you use? Why?

• Do you use any advanced printer features, such as duplexing, collating, copying, or hole-punching?

• Do you print in color? How often?

• Do you ever use different paper types or sizes?

• Do you have any other special printing needs?

• Do you print forms, Word documents, images, or presentations?

• Who views your printouts?

• How many times per day do you print?

• What type of client device do you have? What operating system does it run?

• How many pages are usually printed at once?

In addition to surveying individual users, the project team also chose to look at the printers that they used and to collect the following information about them:

• What is the printer's rated speed, in pages per minute?

• How often is the printer used throughout the day?

• How is the printer connected to the network? Can it be accessed via an IP address, or must it be accessed via a print server?

• What special features does the printer support that might be lost by using alternate generic drivers? How many people use these special features?

Remember, as far as the project team was concerned, they were only collecting printer information to evaluate printing options for users at the two regional offices (with local print servers) that had to print from applications running on Terminal Servers located at the main office.

The evaluations revealed that only about twenty people from each regional office needed to print from Terminal Servers at the main office. Most of these were using Windows XP workstations, although a few in the Customer Service Department were using HP Evo thin client terminals. Some users needed to print in color, and they did print quite often from their central applications. The printers they used were HP LaserJet 8000N's, and they often printed on both sides of the page.

Based on this analysis, and the information that the project team received from their interviews, they built this list of requirements:

• Client platforms of Windows XP and Windows CE.

• Monochrome and color printing.

• High speed.

• The printer must support duplexing.

The project team determined that a third-party printing software solution was their best choice to meet these requirements. As outlined in Figure xxx, their users would be able to print to any printer without administrator intervention.

A third party utility would provide the best overall solution for the regional office users that needed to print from applications running on the main office Terminal Servers. The only real disadvantage to that approach was the fact that the third party tool had to be purchased in addition to their Microsoft software. However, the team figured that increased performance and decreased configuration effort would allow the new software to pay for itself very quickly.

All of Dina's ten small offices have local print servers, but all Terminal Server application execution takes place at the main office. Again, because the print server is not located near the Terminal Server, the spooled printer files must be sent from the Terminal Server across the WAN to the print server, which can be time consuming.

In this case, the project team was able to quickly make a decision without any disagreement. They decided to use the same third-party printing utility that they will use for the regional offices, allowing the users at those facilities to make full use of their color and laser printers without the need to install any client software on users' workstations.

Finally the project team addressed the printing needs of the home users. The home users all run Terminal Server sessions off the servers at the main office. Almost all of the fifty home users have local printers installed. The printers are connected to their laptop computers via USB or the parallel port. As the project team discussed earlier, the big challenge concerning these users was that no one can be sure of what kind of printers they have. Some team members estimated that there may be as many as thirty different types of printers out there.

Fortunately, the printing technology decision for the home users was also easy to make. The project team knew that they were working with these requirements:

• Any client computer make and model.

• Any operating system.

• Any printer make and model.

• Extremely slow network connections (dial-up).

• No user intervention.

All of these requirements naturally lead the team to one solution: third party printer management software. The server component of this software would be installed on each of the Terminal Servers. A client component would be installed on every RDC client device. Once this client software is installed, the Terminal Servers send small, unrendered metafile print jobs to the client. The third party software installed on the client computer renders the print jobs locally, allowing any printer to be used, as shown back in Figure 7.8.

By carefully analyzing all of the unique requirements of each printing scenario, the Dina Gourmet Food Service project team was able to successfully design a Windows 2003 Terminal Server printing solution that allows users to print documents with the speed and flexibility they need.Brian Madden - Terminal Server Printing.pdf

This message was originally posted by an anonymous visitor on May 24, 2004 I've been working with Terminal Server for the past couple of years and want to thank you for the abundant of useful information your site brings. Terminal Services seems to be the wave of the future for server computing power and your articles makes it easy to recommend, set-up and properly distribute terminal services in the enterprise. Thanks!

This message was originally posted by an anonymous visitor on July 30, 2004 best article that i've read on printing on windows (in general)

Guest
wrote
I couldnt have stated the problem and solution better myself...

on
Sun, Dec 12 2004 1:31 PM

This message was originally posted by Ajay Prashar on August 16, 2004 Largely because I don't understand all this stuff as well as you do. Thanks for the very well written article. Im placing it in my favorites now...

This message was originally posted by Louis on September 16, 2004 This is a well written article. I will make this a required reading for all of my techs. If we could find articles like this on more subjects our life would be so much easier. Thanks for your time.

This message was originally posted by an anonymous visitor on September 26, 2004 Very good article ! It helped me to solve my printer and sound redirection problems when even Microsoft knowledge base failed to. Clear and understandable. Thanks !

This message was originally posted by an anonymous visitor on November 11, 2004 we have TS 2000 running, and cannot make it work with remote client printers that have USB (as opposed to parallel) connections. we're thinking of upgrading to TS2003. This article seems to indicate that UBS printers at client sites are supported by TS 2003.

Your EXCELLENT article says, "Technically, power users and administrators can print to any printer, so they'll see all the printers from all users on the server. Regular users, however, will only see their own printers." My users all see everyone's local client-side printers on all sessions. Obviously I would like to stop that, so they see only their own session's printers and the TS Server's printer. My environment: Windows Server 2003, no Citrix, no add-ons at all, no service packs. One server, no domain, no active directory. All users are "local users". Each user allowed to come in on RDP is in a TS group I made myself. That group is, in Local Security Policy, "User Rights Assignment" listed under these two "rights": "Access this computer from the network", and "Allow Logon through Terminal Services". The built in groups "Remote Desktop Users" and "Print Operators" both have zero members. So, why to all TS users see the other TS users' printers, and how can I stop that? Thank you! Chris Jamison

Though it may have it's downsides, what I miss here is the solution where the Terminal Server spools the (relative compact) EMF data over the WAN to the Shared Printer on the Client PC, which renders it to RAW!? BTW: Great great article!!!

Can you completely hide a printer from a terminal server user within a session. Example 6 printers installed on term sever: Remote user1 can only SEE and USE printer1 in the session. Remote user2 can only SEE and USE printer2 in the session. etc......

Users can only see the printers they have access to. If your users are seeing other printers, they are probably admins or power users on the box or the application itself is not playing nice and making nonstandard calls to the OS for the printers.

This was an outstanding and very informative paper with regards to helping me understand what happens with TS printing! I just have one question that I think that I need clarification on. The problem that I'm having is that when I log into my TS and try to print from one of the redirected printers it gives me an error and unfortunately no error log. however, when I print to one of the printers that is installed directly on the TS it prints just fine. Because of your paper I think that this has something to do with RDC. Does this sound accurate?

I use CUP as mentioned in CTX106812 - How to Create the Citrix Universal Printer" and when an user logs on on a MFP 4.0 from a web client 9.150 the CUP (the unique printer in the citrix session) is not set as a default printer. So some applications like Excel 2003 can not print. Any help is welcome and thanks a lot for the article.

Excellent work guys! Comprehensive, concise and clear. For those wanting to print to map local printers connected via all sorts of odd ports like DOT4, read MS's KB302361. Shows how to map *any* local printer port in TS. As at this comment, it can be found here:

This message was originally posted by an anonymous visitor on November 11, 2004 we have TS 2000 running, and cannot make it work with remote client printers that have USB (as opposed to parallel) connections. we're thinking of upgrading to TS2003. This article seems to indicate that UBS printers at client sites are supported by TS 2003.

Has anyone been able to come up with a solution to this problem as I am having exactly the same issue. I would like to be able to print using USB and TS 2000?

USB Printers are supported on 2000 and 2003, so long as you're using an up to date Remote Desktop Client, i.e. 5.2.3790 (that ships with 2003, but is free to download), or the XP SP2 RDP Client. You can download them here:

http://www.sessioncomputing.com/downloads.htm

If the printer uses a DOT4 printer port, you'd have to enable a registry setting:

I have an application that auto connects to the printer name, however when RDP to the same server, the printer changes from session #1 to session #2 for example, and since the name of the printer is changed from 1 to 2 it doesn't connect to the printer. is there a way i can control how the server names the printer when it auto creates it?

Our sysadmin was out for the day and I absolutely had to figure out how to print something locally from the terminal server -- but no matter what I did, my printer wouldn't show up. Then I read in your paper that the drivers had to match EXACTLY. One word difference! Now everything is great! Thanks!!!

Guest
wrote
Outstanding article got me printing in hours after trying for many days.

on
Tue, May 30 2006 7:28 AM

Great job, well written.

I was confused by one paragraph that said:

"At first glance you might wonder why Terminal Server is not smart enough to print directly to the network print server. It would seem that doing so would alleviate the need for the EMF file to travel down from the server to the client and back....."

I thought the EMF file normally didn't go to the client, but was rendered on the server, and the resulting file was then sent down. Am I missing something here?

That said, It was a wonderful article, and I greatly apprecaiate it. Many Thanks, John Gaudio, http://abetterblogsite.com.

Jeff Pitsch
wrote
RE: Outstanding article got me printing in hours after trying for many days.

on
Tue, May 30 2006 9:11 AM

If the print job is going through an autocreated printer, then the job goes back to the client first. If the printer is mapped through login script or some other method, then the print job goes directly to the print server.

Guest
wrote
Printers That Use Ports That Do Not Begin With COM, LPT, or USB Are Not Redirected TS or RDP

on
Fri, Jun 23 2006 9:59 AM

All, please refer to this article for those of you who wish to have non-standard printers redirect in an RDP or TS session. Hopefully it will save you hours of frustration like it did me!

This article was fantastic! Clear, easy to read and it gave me the info I really need. Thanks a lot.

May be some one can help me with a problem I have.

My Administrators can see all the printers on all the servers without any problem. But my help desk and support team do not see the printers on remote servers, only on the server they are logged on to. They have regular user rights on the servers and have full control rights to all printers.

What do I have to do to have them see and manage printers on all the servers without having to locally log on to each server? I do not want to grant them power user or administrator rights. But I do want to open the rights to the printers for them.

What is the relationship between figure 8.4 and 8.8? They look the same. 8.4 is Microsoft TS sending the EMF and data over the network to a remote print server. 8.8 seems to be the same thing, it just uses the third party sofware. I assume the third party software can compress the data...?

How can one setup a default printer for just 1 thin client (not affecting the other thin clients) for any user on that thin client (and not affecting those users who go log on to their own "real" computers on the same network). Example: I have a group of nurses that need to print to a shared printer (using a linksys PSUS4 print server) when at a particular thin client - but later on may log on to their own computer and then, may even use a terminal session from their own computer - which should be printing to a different printer. So, I don't want to set a printer based on user. And, my active directory in server 2003 R2 wasn't set up with computers, only users.

Actually, I find that most terminal services printing articles are not helpful at all beyond their educational purpose. Lets take a look at the cause of most common causes of autocreation:

-driver name not matching,or driver not installed on server -the obvious - it is not enabled for the users, or user -security in system32. ie spool, printer.inf -Print Manager Service for citrix is not running -user settings in active directory and server is set to use user defined settings

Beyond this, which are the obvious causes of failed autocreation, there is not much help out there to look for the least obvious.

Your article is superb. The technical knowledge is precisely focused on the problem and the writing is clear and easily understandable.

My thanks and appreciation of your abilities.

Kind regards, Peter

Guest
wrote
Remote client printer at LPT port works, same printer connected to USB does not work!

on
Thu, May 24 2007 4:17 AM

I have the following problem:

Remote client printer at LPT port works, same printer connected to USB does not work.

In the teminal session, the printer appears at both scenarios (connected via LPT or USB). If a print job is started to the Printer connected to LPT it works fine. If a print job is started to the Printer connected to USB it does not work. The print-job appears for just a second in the printing queue window at the tserver but never appears at the client pc. There are also no error messages at the client or at the tserver. tserver v. 2003, client windows xp.

I was wondering how I can stop all but the default printers from using a TS session? Some clients have 8 printers installed for printing locally on their network. How can I stop ALL of those from being installed and only using their DEFAULT printer in a remote session? I cannot rely on the client deleting his excess printers.

terminal USB redirecting through RDP session from windows 2000 server is there not a solution for the redirecting through the RDP session in the windows 2000 server if in case if there is any of the solution could u plz mail me at naren_s1@rediffmail.com

Even though the last comment to this article is a 9 months old I wanted to update some information. Microsoft released the printer redirection tool which will make the registry entries and setup the inf file for you. http://www.microsoft.com/downloads/details.aspx?familyid=9AD27BE9-40DB-484F-862E-38A094EEEAF7&displaylang=en#Overview

Guest
wrote
Re: Remote client printer at LPT port works, same printer connected to USB does not work!

on
Wed, Sep 5 2007 9:33 AM

Chech and see if your USB printers are using the DOT4 virtual port or the actual USB mapping.

There are several KB articals around on this. I have seen our TS's work off and on with this problem, sometimes it prints, sometimes it does not. So I simply those USB printers with network printers or print servers for the few that I had to maintain.

It was a simple solution for me for only a few hundred dollars opposed to many hours of trouble shooting an intermittent issue.

I have maping but driver seting are down to default! (font setings) altough installed setings at both sides (client and terminal) are correct. And driver versions are same (but not MS sertifed Drivers)

Lemme know if u dont Fixit send me the complete issue along with the network diagram and i will be able to do it...My email id is ankurbk2000@gmail.com

Guest
wrote
Re: Re: Remote client printer at LPT port works, same printer connected to USB does not work!

on
Wed, Sep 19 2007 5:59 PM

Upgrade your MSTSC client version to 6.0, it will resolve the issue.

Guest
wrote
Two site connect to the same ts but they both can see all printers

on
Fri, Sep 21 2007 11:17 PM

I m in the need for this unsolve issue:

I have site A & site B both log on to the same ts server. But they both can see all of our internal printers and themself... is there a way to eliminate site A and site B only see they own printers, and not see other printers. Please help....thanks

We have recently switched to a TS, and all is fine except that for 57 TS users, they see ALL the printers of the other users (100+), and are confused on which to choose (machine names are not always correct for/familiar to the user). Is there not an easy way, if allowing the printers local resource, to "filter" the printers seen to just those of the users (connection's) machine name?????? I think that the printer folder redirection in this article might work, but I wanted to make sure I am not missing something easy...... Thank you, Kelly :)

I have been working in a Terminal server world for the past 6 years and printing has always been a pain in the kazoo!You did a real service by writing this article and you have helped me tremendously.So thank you and keep up the good work!M hewitt

Please help... I've seen a number of posts referencing my issues, however the fixes aren't working for me. To be exact we have a number of HP laserjets which are solely USB based. They work great on the local workstation, however they are non-functional when we remote out to a terminal server (2003) via RDP. We've tried different versions of the RDP client and haven't found one that works. We have a mix of W2K and WXP workstations and that makes no difference. Is there a particular version of the RDP client that works better? Is there some fix where I can get the USB printers to work? The LPT (pararel) and network printers work fine. This seems ridiculous to me since you can't purchase pararel printers anymore, only USB. Please Help....

Hi...First I want to say that this forum is gold. My problem is this: In a terminal server connection with Nortel Networks VPN, one of my local USB printers (Brother Ql-500) dont print and it always send two pages to the spooler. Another Local USB HP printer dont have no problem to print. If I try with another client terminal server connection without no VPN but with the some Operation System (2003 Server), the Brother print fine and the spooler just receive one page to print. There are any place in a Windows 2003 Server that configure that or probably the problem is the connection!!!???Thanks

My Users have been complaining of not being able to choose the page range when printing. So rather than printing 50 pages they would choose the particular page(s) they requried. This option is available to them on the local computer desktop but not when through terminal Services?

If I log in I can choose the page range as I have admin rights over the network so it is quite possibly something to do with permissions or Group policy? Any thoughts? John

Brian What can I say, but a sincere congratulations on presenting one of the best all time explanations of TS printing - in fact printing in general. This document was a pleasure to read and as such I have passed it to our whole Infrastructure team for review. We are about to make company wide decisions regarding whether to use third party solutions for our Citrix environment or not and although this isn't strictly Citrix focus as TS is the underlying infrastructure itso makes this article particularly relevant (and independent). Again, many. many thanks for your hard work spent on generating this superb review.Lea

I wanted to know if there was a way to know when the users printers are mapped.

We have a Terminal server printing at our office. The problem we were facing was our NYC users were experiencing slowness since they were mapped to a NYC print server for a LA TS. Our solution was to map the la servers on there machine and when they log on to the ts, a logon script would change their default printer to the la print server. The problem is the logon script runs before the printers are mapped. Do you think this is a good direction or how to know when the printers are mapped

"The most common issue is when the client and the server have mismatched driver versions. When this occurs, the client and the print processor on the server may not be able to reconcile some features when using EMF Printing."

contradicts the extract from this page. Furthermore, this is confirmed by the text at:

which includes, in the context of citing client-side rendering advantages:

"Elimination of driver mismatches. Because the computer that spooled the print job also rendered the EMF-format data, there are no inconsistencies that may be caused by client / server print driver mismatches."

Therefore, the text on this page is incorrect at worst or unqualified at best.

One thing that wasn’t mentioned is 3rd-party print processors. My suspicion is that the 3rd part print proc is initiated in Phase 2 between the conversions of Metafile data to RAW data - however, I am a bit sketchy on this. Care to comment?

Hi, Great job done. I am having a query on TS port assignment. When a user logon RDC the printers and devices redirected using TS ports. But, here we should assign static Ports like TS075 or TS425 for that printers and devices on TS. Need of your best.

(Note: You must be logged in to post a comment.)

If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.