Read about the changes in Windows Server 2003 that greatly improve access to terminal services for remote users.
I have been telling IT professionals for quite some time that I believe the best way to provide applications to users is through a terminal server. The terminal services make it possible to run applications on machines that never would have otherwise supported them. For instance, I frequently administer my servers by remotely controlling them from a PDA that’s running Windows CE. Normally, Windows CE would be incapable of running User Manager for Domains or any of the other administrative tools. However, because the applications are actually running on the server itself, my PDA makes an excellent administration tool.
Nonetheless, for all their good points the terminal services don't do well in one area of IT administration. Until recently it has traditionally been a very poor solution for supporting remote users. Let's look at reasons why the terminal services do not make the best remote admin tool and a way to overcome these limitations.
Limitations of the terminal services for remote users
The terminal services work by sending screen images to the user and by sending a user’s keystrokes and mouse motions back to the server. These transmissions have traditionally consumed much more bandwidth than a remote connection would support. I have personally witnessed users remotely accessing a terminal server over a modem, and the entire session could be best described as painfully slow.
Another reason why the terminal services have been traditionally bad for remote users is because of the way that the user has been forced to access the terminal services. Normally, if a user will be accessing the terminal services they will dial into a RAS server, authenticate into the network, and then begin a terminal session. Again, the concept of dialing in just isn’t conducive to a well-performing terminal session.
Everything changes with Windows Server 2003
Recently there have been two changes that make the terminal services better suited to remote operations. These include the widespread deployment of broadband connections, and the implementation of Windows Server 2003. Windows Server 2003’s version of the terminal services relies on the Remote Desktop Protocol (RDP). This is the same protocol used by Windows XP’s Remote Assistance feature. RDP is designed to be much faster than its predecessor. It also allows for greater color depth than was previously available and supports the transmission of sound.
Since broadband Internet access and the RDP make terminal service access more feasible for remote users, it might be tempting to give all of your remote users terminal server access. However, one big challenge that must be overcome is most companies have a limited supply of IP addresses.
Normally, when a company gets Internet access, the ISP will provide them with one IP address. Since each PC must have its own IP address, it has become common to assign each PC a bogus IP address. The one real IP address is assigned to the router or firewall that is physically connected to the Internet. This machine uses what’s known as a Network Address Translation (NAT) firewall. NAT allows you to create an entire network of bogus IP addresses. When someone needs to access the Internet, the request is sent to the NAT firewall and it makes the request to the Web site on behalf of the person. In doing so, the request appears to have come from the network’s one legitimate IP address. When the Web site replies to the request, the reply is sent to the NAT firewall. The NAT firewall receives the request and then forwards it to the appropriate bogus IP address on the private network.
When it comes to accessing the Terminal Services, NAT presents a couple of problems. One problem is that the terminal server does not have a legitimate IP address. Therefore, the server is not accessible to the outside world. Only PCs on the private, internal network are usually able to access such servers. The second challenge is NAT is configured to block all unauthorized traffic types. This includes terminal server traffic.
Just because there are challenges involved in accessing the terminal services across a NAT firewall doesn’t mean doing so is impossible. You can access a terminal server externally by using something called port forwarding. The basic idea of port forwarding is that someone from the outside world would configure her terminal server client to connect to the terminal server. However, the connection must be made by entering your network’s one legitimate IP address. Remember that this IP address is assigned to your firewall / router rather than to the terminal server. The trick is to know that the terminal services use port number 3389. Therefore, when connecting, enter the network’s one legitimate IP address followed by a colon and the number 3389 (for example, 184.108.40.206:3389).
In addition, the NAT firewall must be configured to support port forwarding by telling NAT that any traffic coming in on port 3389 must be redirected to your terminal server. For this step you can enter the server’s private IP address. The actual port forwarding mapping procedure varies from firewall to firewall, but in general it simply involves entering the port number (3389) and the private IP address of the terminal server.
Simple registry tweak
The down side to using port forwarding is that you can only access one terminal server from the outside world. The reason is that you can only map a port number to one private IP address. Therefore, if port 3389 is mapped to one terminal server, then it can’t be mapped to a second terminal server. However, there is no reason why you can’t map port number 3390 to your second terminal server. The only trick is that you must configure the second server’s terminal services to listen on port number 3390 rather than 3389.
This step involves a simple registry edit. Remember that editing the registry is dangerous. An incorrect registry modification can destroy Windows and / or your applications. Therefore, I recommend backing up your server before attempting this modification.
To accomplish this step go to your second terminal server, open the Registry Editor, and navigate to:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ TerminalServer\WinStations\RDP-Tcp
Now, locate the PortNumber key and change its value to that of the new port number you want to use.
A final word about security
Accessing the Terminal Services directly through port forwarding will work, but by default, it might not be the most secure method of access. Keep in mind that unless you specify that terminal server traffic is encrypted, it will be unencrypted by default. It is just as secure, if not more so, to access the terminal services through a VPN connection. Nonetheless, I would expect the end user would see much better performance if accessing the terminal server through a NAT.