Leveraging Local Resources

With Microsoft 2003 Terminal Services Microsoft now provides a much more impressive list of redirected local resources to a terminal session. With 2003 Terminal Services and an RDP client version 5.1 or later, you now have the ability to provide the user not only access to local and network drives and printers, but also COM ports and audio redirection. Users can now again enjoy something as simple as a new mail notification sound all the way up to viewing a multimedia presentation all via a terminal server session.

Although audio redirection is nice and another step closer to making a terminal server session experience rival running the application locally a perhaps more useful addition to 2003 Terminal Services is COM port redirection. The most requested use of this is being able to synch a Palm Pilot to applications running via Terminal Services. Prior to 2003 Terminal Services an administrator was usually unable to deploy Outlook to a fair number of users because the users had to be able to sync to their Palm Pilot. This is no longer the case. Although audio and COM port redirection are nice, Windows 2003 Terminal Services have been really improved in the area of local and network drive and printer access. Windows 2003 Terminal Services can now automatically map all of a user's local and network drives and printers. The user now has full access to all their local and network drives and printers without you having to do anything in the background to set it up.

Optimizing Local Printing

Ask any terminal server administrator the number one problem she has encountered while deploying Terminal Services and 9 out of 10 times you will hear about printing problems. By default when a client connects to the terminal server the terminal server will attempt to create all the printers that the client device is attached to into the terminal server session. Depending on the type and model of printer this might or might not work. The terminal server is only able to create printers for which it has drivers. By default the only printers that Terminal Services will be able to install are those listed in the ntprint.inf file and whose drivers are contained in the i386 directory. So, if a client device has a printer attached that uses a driver not listed in the .inf file that printer will not get created and the user will not be able to print to it.

To ensure the client device can print you have a few options. One option is to install the printer driver for the device onto the terminal server. Even though the printer is not really attached to the server you just go through the steps of installing the printer to lpt1 and then when complete you can now delete the newly installed printer and choose to leave the drivers behind. Now when the client connects the printer drivers are already installed onto the terminal server and the client will be able to print.

There are major drawbacks to using this method. A majority of manufacturer print drivers are not certified for use on terminal server and as such can cause various undesirable effects ranging from print spooler crashes to the infamous blue screen of death. Also in a large environment imagine trying to identify every single printer that will need to have a driver loaded onto every single terminal server; a daunting, potentially neverending task. A small modification to the previously mentioned method will result in a much more stable terminal server printing environment.

As previously mentioned, by default Terminal Services will be able to install all printers listed in the ntprint.inf file. What you can do is modify the ntprint.inf file to support the client printers. The basic steps are as follows . First identify the name of the printer driver from the client computer. Then the ntprint.inf must be modified by adding an entry to the Previous Names section that exactly matches the name of the client-side driver and then maps to a known stable printer driver that will print to the device. As you can see managing printers can potentially be a very big task for you and is probably the number one reason that people turn to the third-party manufacturers like Citrix, Newmoon, Jetro systems, and so on for their printing solutions. All of these manufactures provide what they call a unidriver. This is a single print driver that will allow printing to most any printer on the market. Although this is excellent for the stability of the terminal server, these unidrivers do lack in functionality and as such at times it will still be a requirement to install vendor drivers for the user to print properly.

Leveraging Local and Network Drives

If enabled Windows 2003 Terminal Services now maps both local and network drives defined on the client into the terminal session. Now it becomes very simple for a user to be able to run applications on the terminal server yet still access files from their local machine. This feature can of course be disabled for security reasons. It is not always desirable to give the end user the capability to upload and download files to and from the terminal server. In fact in most cases one can argue strongly that it is counterintuitive to what is trying to be accomplished by using centralized computing. That being said there will be many instances where Terminal Services is just being used either for remote access or a specialized application in a traditional decentralized computing environment and access to local resources will be a necessity.

Greater Performance Over Low Bandwidth Connections

Greater performance over low bandwidth connections will be achieved by not enabling client drive redirection. When at all possible keep user data on the local network and map drives via login scripts instead of redirecting the resources from the client.