Remote Desktop is a Windows feature that allows you to connect to your computer remotely by using the RDP protocol, but it can sometimes be difficult to establish a Remote Desktop session. Learn troubleshooting techniques and workarounds for Remote Desktop connectivity, authentication and encryption issues in this tip from WindowsNetworking.com.
Ever since the release of Windows XP, one of my favorite features has always been Remote Desktop. In case you're not familiar with Remote Desktop, it is a built-in Windows feature that allows you to connect to your computer remotely by using the RDP protocol. For example, if you are at home and you need to access something from your computer at the office, you could use a Remote Desktop session to remotely control your office PC from home. Remote Desktop is built on the same technology and uses the same protocol as Windows Terminal Services.
As handy as Remote Desktop is, it can sometimes be problematic. While the sessions are usually solid, there are a number of things that can go wrong during the connection and authentication process. In this article, I will explore troubleshooting techniques you can use when things go wrong with Remote Desktop.
The remote computer cannot be found
Probably the most common Remote Desktop problem is that Remote Desktop has trouble locating the remote PC. There are a number of things that can cause this problem. Probably the simplest cause is misspelling the name of the remote computer. Therefore, if you're having trouble connecting to remote computer, just take a second and make sure you've spelled the remote machine's name correctly.
If the remote computer's name is spelled correctly, the problem may be DNS related. Remote Desktop uses the RDP protocol, which piggybacks on top of the TCP/IP protocol. As you probably know, TCP/IP does not use computer names as a mechanism for identifying the systems. The only reason that it is possible to specify a computer name is because a DNS server resolves the computer name to an IP address.
If you find yourself having name resolution problems, there are a couple of different things you can try. One option is to try using the remote system's fully qualified domain name as opposed to its NetBIOS name. This won't always help you to establish a connection, but in certain situations it will help.
Another option is to specify the remote machine's IP address rather than its name. Generally speaking, using an IP address tends to be much less problematic than using a host name when connecting. Even IP addresses can be problematic, though.
The biggest factor that tends to make connecting with IP addresses problematic is the use of dynamic IP addresses. If you are using Remote Desktop to connect to a server, this probably won't be an issue, because most servers use static IP addresses. Workstations, on the other hand, almost always use dynamic IP addresses. Therefore, the IP address your workstation is using today will probably be assigned to a different workstation tomorrow. If the machine that you are connecting to does use dynamic IP addresses, then you will practically have no choice but to specify a host name when connecting rather than specifying the machine's IP address.
Another factor that can make it difficult to connect to a host machine using remote desktop is firewalls. The Remote Desktop Protocol is designed to work across TCP port 3389. If you are attempting to connect to a remote machine that sits behind a firewall, then the firewall must allow traffic to flow through TCP port 3389. Of course, blindly opening this port on your firewall can pose a huge security risk. You might choose instead to enable port forwarding so that inbound RDP traffic is forwarded to a specific IP address, rather than someone on the outside being able to attempt an RDP connection to any machine on your network.
On many networks, you won't have a choice but to use port forwarding for RDP traffic. The majority of networks use private IP addresses on their networks, where only the router uses a public IP address. The router uses Network Address Translation (NAT) to proxy traffic between the Internet and hosts on the private network. If you are trying to establish an RDP connection from across the Internet with a host that sits behind a NAT firewall, then you will have to configure the firewall to forward RDP traffic to the target host.
This assumes that you are attempting to establish a connection directly from outside the perimeter network. If you are connecting to the private network using a VPN or a dial-up connection, then you will have to worry about reconfiguring a NAT firewall, because your VPN or dial-up connection provides you with a connection to the private network. The remote access server that is used for establishing VPN or dial-up connections almost always sits behind a firewall, and you'll have to insure that this firewall allows RDP traffic to flow to the private network.
While I am on the subject of firewalls, I want to point out that Windows XP SP2 and Windows Vista both contain a built-in firewall. If you are attempting to establish a connection to a machine running one of these operating systems, you'll have to insure that the Windows firewall is configured to allow RDP traffic.
Authentication problems
Establishing the initial connection is by far the most problematic aspect of Remote Desktop, but there are other problems that you may encounter. Many users are surprised to see that they can attach to a remote PC, and enter their credentials, but are stopped by the following error message:
The local policy of the system does not permit you to log on interactively.
Windows displays this error message if the user lacks the necessary permissions to log in using the Remote Desktop Protocol. You can correct the problem by adding the user account to the Remote Desktop Users group or to the local Administrators group.
Data encryption
One of the most cryptic problems with Remote Desktop involves receiving the following error message:
Because of an error in data encryption, this session will end. Please try connecting to the remote computer again.
This error message is almost always related to using an outdated remote desktop (or terminal service) client. When Microsoft released Windows 2000, they created an add-on called the Administration Tool Pack. The Administration Tool Pack included a client component that could be used to establish a remote session. Although this client initially appears to be compatible with Windows XP, it isn't. Using the Windows 2000 version of the Administration Tool Pack to establish a Remote Desktop session with Windows XP will usually trigger the error message that I mentioned above.
Windows XP comes with its own Remote Desktop client that you can use to establish a connection with other machines that are running Windows XP. If you prefer using the Administration Tool Pack though, then you can always upgrade to the Windows Server 2003 version, which you can download at Microsoft's support section.
About the author:
Brien Posey is an award-winning author who has written more than 3,000 articles and written or contributed to 27 books. You can visit Brien's personal Web site at www.brienposey.com.
WindowsNetworking.com contains a wealth of networking information for administrators: Featuring information on how to setup and troubleshoot various networks of any size. Also includes a comprehensive archive of hundreds of reviewed networking software and hardware solutions. Frequently updated with articles and tips by a team of leading authors, it remains a favorite within the networking community.
