Establishing a Windows remote desktop session is normally a simple and reliable process, but IT professionals need to be ready for remote desktop issues to pop up.
For example, administrators may find that the remote machine refuses the Remote Desktop Protocol (RDP) connection. Fortunately, troubleshooting the problem is usually a straightforward process.
When everything is working properly, establishing a remote desktop session is a simple process. Admins only need to open the Remote Desktop client -- also known as the RDP Client or the Remote Desktop Connection (RDC) app -- and enter the name or IP address of the endpoint that will host the connection. Then, it's as simple as clicking the Connect button to establish the session. If the RDP client has saved credentials on hand from a previous session, then the new session automatically uses them. Otherwise, the client prompts you to enter a username and password.
If these steps don't yield a successful RDC connection, then IT administrators should take troubleshooting steps to determine and address the root cause of the issue.
1. Make sure the credentials are correct
The first step in troubleshooting the problem should always be to make sure that the correct credentials are in place. This includes making sure that the credentials are entered in the correct format and have the correct capitalization, as well as any other considerations. One of the more common mistakes is to accidentally omit the domain name from the credential set.
Consider an IT professional logging in with an administrator account for the example domain PoseyLab. If the IT pro types Administrator instead of PoseyLab\Administrator, then the client would attempt to log in using the endpoint's local administrator account rather than the domain administrator account. Odds are that the local administrator account lacks the permissions to log on to the machine remotely. Even if the required permissions do exist, the local administrator account probably does not have the same password as the domain administrator account, so the logon won't be successful.
2. Update the saved credentials
One of the more common problems that can leave remote desktop credentials not working is a set of cached credentials that are no longer valid. This can happen if someone changes a domain account password, but the RDP client is still authenticating with the old password.
Normally, when this happens, the RDP client attempts to log on using the old password, and when the authentication attempt fails, the client prompts for a new password. Occasionally, however, admins may find that the prompt does not display. In those situations, the admin has to manually update the saved credentials.
The easiest way to do this is to open the RDP client, choose the computer to connect to and then click on the Show Options link. This expands the interface to reveal the Logon settings section. The Logon settings section contains an edit link (Figure 1). Clicking this hyperlink opens a prompt that enables an admin to enter and save a new password.
3. Make sure that the account is not locked out
If an admin has completed the first two steps and the remote desktop connection credentials are still not working, the next step is to make sure the administrator account has not been locked out. Most organizations configure their Active Directory environments to automatically lock accounts after too many invalid login attempts as an RDP security measure.
Even if the account was not initially locked out, failed attempts at establishing an RDP session with the remote machine count as logon attempts and may lead to a lockout. It's a good idea to check whether the account is locked and manually override the lockout if it is in place.
4. See if the account has remote access permissions
Another item to check when remote desktop credentials aren't working is whether or not the account that you are using has permission to log on to the remote machine through an RDP session. Even with a successful RDP connection in place from a prior session, it's always possible that the permission was somehow removed accidentally. Unfortunately, checking the remote access permissions means that someone has to log on to the machine locally.
The exact steps of this process can vary considerably depending on the version of Windows that the remote machine runs on. With most modern versions of Windows, right-click on the Start button, and then choose the System command from the shortcut menu. Then, select the Remote Desktop tab, and make sure that the Enable Remote Desktop setting is turned on. Next, click on the Select users that can remotely access this PC link found at the bottom of the screen (Figure 2).
Then, verify and, if necessary, add accounts that can establish remote desktop sessions with the machine in question.
5. Check the firewall
Next, administrators should check if RDP traffic is able to flow between the remote machine and the local machine. The protocol that nearly all RDP clients use is TCP port number 3389. Make sure that Windows Firewall on the remote machine is not blocking access to this port. The same also holds true for any other firewalls that exist between the two machines.
6. Verify that the connection is targeting the correct machine
One more step that IT administrators can take if they are having trouble connecting to the remote machine is to verify they are connecting to the correct machine. Begin the process on the remote machine by right-clicking the Start button and choosing the System command from the shortcut menu. From the About tab within the Settings window, click on the System Info link. This yields some basic information for the remote machine. Verify both the machine name and the name of the domain that the machine is connected to (Figure 3).
With the computer and domain names confirmed, the admin should verify the computer's IP address. The easiest way to do this is to open a Command Prompt window and enter the following command:
This lists the remote machine's IP address, as well as the address of the domain name server that it is using. Finally, look at the domain name server to ensure that the DNS record for the machine lists the correct computer name and IP address.