Thin client computing was originally designed as a way of giving end users a consistent and centralized experience that was mostly independent of the capabilities of the user's desktop computer. Consequently, providing access to local resources has never really been one of Windows Terminal Services' strong points. Although keeping everything centralized is good in theory, the reality is that many times in the real world, users need access to local hardware devices. Gaining access to local hardware was a challenge in a Windows Server 2003 terminal services environment but has been greatly improved in Windows Server 2008. In this article, I will discuss some of these improvements.
Before I get started, I need to explain that although the improvements I will be mentioning are specific to Windows Server 2008, they are also dependant on the client component. Users must be running a compatible Terminal Services client (typically the one that comes with Vista) to take advantage of the improvements.
1. Plug and play redirection
In my opinion, the biggest resource-related improvement to Terminal Services has to do with the way external plug-and-play devices are supported. In the previous version of Windows Terminal Services, if a user plugged in an external plug-and-play device, the device would be available through the local computer, but not through the terminal server session.
External plug-and-play devices are supported for use in Windows 2008 Terminal Services sessions, but there are some limitations. In order to use an external plug-and-play device with a Terminal Services session, the device must support the Media Transfer Protocol (MTP) or the Picture Transfer Protocol (PTP).
If a plug-and-play device that supports one of these two protocols is attached to the user's workstation at the time they establish a terminal server session, the device will be automatically available through the session. If, on the other hand, the user wants to connect the plug and device later on, he can still use the device through the session, but only if he selects the Devices that I Plug in Later option in the Remote Desktop Client prior to establishing the session. You can see what this option looks like in Figure A.
Figure A
The Remote Desktop Client contains an option that allows you to attach plug-and-play devices later on.
2. .NET device redirection
As I alluded to in the previous section, one of the downsides to using the Windows Terminal Services in the past is that if users required access to local hardware, they were limited to using only the basics. Microsoft has improved the support for non-standard local hardware by integrating .NET device redirection.
The idea behind this is that Terminal Services is ideally suited to Point of Sale (POS) environments, but many organizations use devices such as barcode scanners and magnetic strip readers in conjunction with their point-of-sale software. Previously these types of devices were inaccessible through a Terminal Services session. If, however, the devices use Microsoft Point of Service for version 1.11 of the .NET Framework, then those devices can be redirected.
3. Access for local drives
Looking at Figure A, you can see that the Remote Desktop Client allows users to choose the local drives they want to access through a Terminal Services session. Local drive access works well if a user is browsing the machine through Windows Explorer, but local drive access has always been a bit of a problem from the command prompt because of the way local drives are referenced during a Terminal Services session.
The Windows 2008 version of the Terminal Services application makes it possible to map a drive letter to a local drive so that local drives can be accessed the same way as server drives. The mapping process is a little bit tricky. To map the local C: drive, you would enter this command:
Net Use * \\tsclient\c
This command will map drive Z: to the local C: drive. Any additional drive mappings will use available drive letters starting at the end of the alphabet and working backwards (Y:, X:, W:, etc.).
4. Printing
In Windows Server 2003, printing to a local printer was a real pain. When users wanted to print to a local printer, they either had to use a printer driver that was local to Windows Server 2003, or the print driver had to be manually installed on the client's computer prior to establishing the session. Windows Server 2008 makes the printing process easier through an aptly named component called Easy Print.
Easy Print acts as a proxy between the printing process and the local printer. Its design allows it to function as a universal printer driver that works with old and new printers alike.
In conclusion, local resource redirection has improved considerably in the Windows Server 2008 version of Terminal Services. Just keep in mind that the new redirection features can only be used if the Remote Desktop Client supports them.
About the author: Brien M. Posey, MCSE, has received Microsoft's Most Valuable Professional Award five times for his work with Windows Server, IIS and Exchange Server. He has served as CIO for a nationwide chain of hospitals and healthcare facilities, and was once a network administrator for Fort Knox.
