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.