Microsoft Windows Server 2003 Terminal Services

Hassle-free printing is a central requirement in a corporate environment and requires an appropriate infrastructure. Using print servers and connecting local printers to clients are two ways for providing printers concurrently to multiple users. However, planning, configuring, and maintaining this type of remote printer environment requires significantly more know-how of the basic mechanisms than using a direct printer connection to the terminal server.

Print Clients and Printer Drivers

Printing a document seems trivial at first glance: the computer transfers all graphical elements of the document to a device that outputs the graphics on paper. Unfortunately, there is a lot more to the process than is apparent. The ludicrous array of document formats, graphical elements, and printer types generates problems.

The source of a print job is referred to as the print client . If a user enters the command to print a document or a document area, an image of the document to be printed is generated in an enhanced metafile format . Because this format is independent of the target printer, it needs to be adapted to the correct format for that printer. To achieve this, the corresponding printer driver must be installed and registered on the print client. The printer driver generates the specific data stream from the enhanced metafile format to contact the target printer.

Spooling is the administration and processing of print jobs for all connected printers. This task is performed by a special service that is referred to as a spooler . It accesses printer drivers for processing print jobs. When this service is terminated , you can no longer print on the local computer, regardless of the printer drivers installed.

When a printer driver is installed, the applicable files are saved in the %Systemroot% \system32 \spool \drivers \w32x86 \3 folder. The 3 at the end of the path defines the printer driver s version, which corresponds to Windows 2000 and Windows Server 2003. A 2 , however, indicates a printer driver that was developed for Windows NT.

The concept of automatically installed printer drivers was developed for Windows operating systems to simplify network printing. A central instance transfers the printer drivers to a computer with the proper OS and permissions to use this printer. Oftentimes, installation is initiated automatically by the first user who requests the corresponding printer on the network. However, this behavior might be problematic for terminal servers. An administrator is no longer able to control which drivers are currently on the terminal server. You can regulate behavior more strictly only through modifying the registry database. (See also Chapter 6.)

So how does the system decide which printer driver to use for which printer? The %Systemroot% \inf folder contains a file named Ntprint.inf. Among its other tasks , this file enables exact allocation of the known printer types to the existing printer drivers. The file s syntax is relatively simple:

[HP] HP LaserJet 5MP = HPLJ5MP.GPD

Print Servers

If network printers are used in corporate environments, it is not very efficient if each computer handles its own local print jobs and sends them to the target printer. A dedicated server should perform this task, and in so doing becomes a print server. All computers on the network send their print jobs to the print server. In case of frequent changes to the printer constellation, this procedure ensures a minimum of necessary changes to the client system. Spooling is again key here, that is, receiving, processing, caching, sequencing, and distributing print jobs.

It is possible to divide the processes during a print job on the network into several individual steps. A terminal server assumes the same role in this example as a normal client.

1. A user prints a document from a terminal server. The GDI/GDI+ graphical interface generates an output data stream using the selected printer driver. The driver is transferred to a spooler, the source of the following network communication. Often, the data stream is transferred directly to the print server that then assumes the task of spooling. In third-party systems, the process is similar but excludes the use of the GDI interface.

2. The terminal server sends the print job to the print server. The generated data stream is sent through a remote procedure call to the server s router. The print server receives the print job and processes the data received. With Windows operating systems, the print job is handled by the Redirector, where the server service transfers the data to the print server. If the client is a UNIX computer, the print server s LPD service is needed to accept the print job.

3. The router or print-server services forward the print job to the server s local print support. The spooler on the server processes and carries out the print process. It saves that data on the hard drive until the data can be further processed in the print process.

4. The print job is forwarded to a separator page processor and the print monitor. Either the printer or another print server receives the print job via the physical interface and converts it to individual pages.

The printer drivers play a key role in the preceding process. They allow a generic communication between an application and the different printers, regardless of device type or language that was used to write the page.

Figure 4-33: The basic architecture of a print server environment. The Windows print client runs on the terminal server.

Network Printers

Terminal servers, print servers, Terminal Services clients, and network printers frequently do not run on the same network segment. Which setups exist in a comprehensive network with terminal servers and Terminal Services clients on different segments?

• The Terminal Services client and a network printer are on one network segment, and terminal servers and printer server are on another. This is a typical setup for home offices and small remote offices connected to the company headquarters network via an ISDN router. The user works on a terminal server and starts some applications. A print job is generated in the computing center on the terminal server and sent to the print server on the logical, short path. Subsequently, the print data is sent to the printer on the other network segment via routers. This scenario is problematic if, in addition to Terminal Services client, local applications are used on the client computer. These local applications generate a print job on the client, send it the long way to the print server, and again from there the long way to the printer. Due to this redundant data transfer per print job, the line between the network segments is frequently heavily loaded. It is therefore recommended that a local print concept be used for local applications, although it does make the environment s configuration a bit more complicated and requires user expertise. A fast connection between the two network segments makes this configuration an excellent option.

• Terminal Services client, a print server, and a printer are on the same network segment, the terminal server on another. This is a rather unusual combination if there is only one, very powerful print server. Both server types are not on the same, central segment, which is not very practical. Only if the concept is supported by small, decentralized print servers is the scenario slightly more realistic. This arrangement does have an advantage, though: the print-data stream needs to be transferred only once between the network segments for both terminal server sessions and local applications.

• The Terminal Services client is on one network segment, and terminal servers, print server, and printer on another. This is a network arrangement that meets increased transfer and security requirements. A print job from a terminal server session does not traverse any segment borders, that is, the environment can achieve an optimum print-data transmission rate. Furthermore, this combination allows company data to be printed to just one single network segment. If the network segment with the Terminal Services client is external and the network segment and other components are inside a monitored company building, it is relatively safe to print sensitive data. The data never leaves the internal network segments; only transient monitor images get out. These statements do not apply to local applications on the client, where such a solution is unsuitable.

We could, of course, look at some other arrangements based on more than two network segments. However, they are mere extensions of the above examples and would not yield any new features.

Redirected Client Printers

The RDP protocol from version 5.0 supports printers that are physically connected to the client. Interfaces and print queues are redirected to the terminal server and thus become visible within a user session. You can even set the user session s default printer to the client printer. In this way, all print jobs from a user session on a terminal server are automatically sent to the client printer.

The user generally expects to use the redirected client printer even though the applications are physically running on the remote server. The technical implementation of this behavior is supported by applications that do not communicate directly with the printer but via the GDI interface and spooler.

On a terminal server, the client printer has one more instance for handling print jobs. This instance is named RDP Port Redirector (RDPPR). It creates an administrative unit for virtual printers that are each associated with the physical client printers. The number of virtual printers depends on the currently active user sessions. A virtual printer s properties correspond to those of a real printer that is connected to the terminal server either directly or through a print server. Therefore, applications or their GDI requests cannot discern any differences between the two printer types.

When a user logs on, the RDPPR automatically establishes all existing serial, parallel, and USB ports as well as the printer queues of the corresponding client. This process dynamically generates virtual printers and interfaces on the terminal server through Plug and Play API, which are then integrated into the user session. Possible changes to the print queues are also conveyed to the terminal server this way, which enables runtime adjustment. The user session on the terminal server also handles default printer settings (for example, double-sided printing).

The print queue terminates when the user session ends. All incomplete or suspended print jobs are lost. The settings of the corresponding client printer are saved on the client and reloaded for later sessions.

An event is created in the Event Viewer if a necessary printer driver is not available on the terminal server. If you still want to use the printer, you need to install the driver manually. However, you need administrator rights on the terminal server to do this. After you install the printer manually, you can delete the printer object connected to the serial, the parallel, or the USB port. Upon user logon, the integrated user session printer is mapped to the redirected client interface. Thus, local USB printers are supported, too.

Figure 4-34: List of redirected and automatically generated print queues on a terminal server.

If a data stream is sent from a user session to a virtual printer, the RDPPR forwards the print job to the corresponding client. The client communicates with the physical printer. All data used for connecting a client printer is transferred using a separate, virtual RDP channel.