Tips for Troubleshooting Remote Desktop Connection Problems

As a systems administrator, you've probably experienced a problem connecting to a system via the Remote Desktop Protocol (RDP). Error messages such as Remote Desktop Disconnected and This client could not establish a connection to the remote computer represent recurring problems that we see in Microsoft Product Support. Unfortunately, such error messages don't always point to a specific root cause.

Based on our experience and trends we've seen, we've put together a cheat sheet of the most common causes of these problems:

·         Misunderstood terminologies and settings

·         Incorrect permissions andor user rights

·         Port assignment conflict

·         Misconfigured Group Policy or RDP-TCP settings in Remote Desktop Services configuration

Note that this isn't a comprehensive list of all the various types of problems you might be experiencing while attempting to connect to a remote computer; they're merely the most common problems we've seen. The goal is to help you identify these problems before calling the Microsoft support team or hitting the search engine.

Misunderstandings

One common misconception surrounding RDP is that you need to install a Remote Desktop Licensing Server (aka Terminal Services Licensing) andor Remote Desktop Session Host (aka Terminal Server) to allow remote connections on a server. Out of the box, Remote Desktop supports two concurrent connections to remotely administer a computer. You don't need a licensing server for these connections.

Note that Remote Desktop Licensing (RD Licensing)—formerly Terminal Services Licensing (TS Licensing)—is a role service in the Remote Desktop Services server role included with Windows Server 2008 R2. RD Licensing manages the Remote Desktop Services client access licenses (RDS CALs) that are required for each device or user to connect to a Remote Desktop Session Host (RD Session Host) server. You use Remote Desktop Licensing Manager (RD Licensing Manager) to install, issue, and track the availability of RDS CALs on a Remote Desktop license server.

Suppose you have three administrators in your IT team. You build a brand-new Windows Server system to serve as your new application server. To help with the initial settings, you have two admins remotely connected to this server (no licenses installed). When you have a change of shift, while one of the admins leaves work, the third admin tries to remotely connect to the same box. Figure 1 shows the message he sees. There are already two admins connected to the box, and if necessary he can disconnect one of them.

Figure 1: Selecting a user to disconnect

Also, remember that to allow remote connections for administrative purposes only, you don't have to install Remote Desktop Session Host (aka Terminal Server). Instead, ensure that the Remote Desktop setting is enabled, as Figure 2 shows.

Figure 2: Enabling a Remote Desktop Connection

Another common misunderstanding involves knowing what permissions are necessary to allow a user to log on to a remote computer. As you see in Figure 3, members of the Administrators group don't need any special permissions and can remotely connect even if they aren't explicitly listed in the Remote Desktop Users group. The Remote Desktop Users group on an RD Session Host server is used to give users and groups permission to remotely connect to an RD Session Host server.

Figure 3: Administrators don't need special permissions

You can add users and groups to the Remote Desktop Users group by using the Microsoft Management Console (MMC) Local Users and Groups snap-in, by using the Active Directory Users and Computers snap-in (if the RD Session Host server is installed on a domain controller—DC), or by accessing the Remote tab in the System Properties dialog box on an RD Session Host server (as you see in Figure 2) Adding a user to the Remote Desktop Users group using one of these methods will provide the appropriate permissions for remotely accessing a box. Otherwise, the connection will be denied.

Permissions and User Rights

So, what happens behind the scenes? How does adding a user to the Remote Desktop Users group magically give them the appropriate user rights to remotely connect to a computer? User Rights, as their name suggests, control who is authorized to log on to a computer and how they can log on. In this case, the Allow log on through Remote Desktop Services user right controls remote access to a server.

If you pull up the local security policy on a server (StartRunsecpol.msc), you'll notice that, by default, the Remote Desktop Users is already added to the Allow log on through Remote Desktop Services user right, as you see in Figure 4. Adding users to the Remote Desktop Users group also gives them this right.

Figure 4: Logon through Remote Desktop Services (click to enlarge)

Note that installing the RD Session Host role service on an AD DC isn't recommended. Allowing users to run programs on a DC could create security risks and performance problems. If the RD Session Host role service is installed on a DC, the security settings of the DC will need to be adjusted to allow users to have remote access to the server. This remote access is controlled by the Allow log on through Remote Desktop Services user rights assignment, which can be configured by using the Group Policy Management Console (GPMC).

On a DC, by default, only the Administrators group is granted the Allow log on through Remote Desktop Services user right. To allow remote access to the RD Session Host server for users who aren't members of the Administrators group, you should grant the Remote Desktop Users group the Allow log on through Remote Desktop Services user right.

Next time you see the error message that Figure 5 shows, be sure to check the Group Policy settings on the remote box. It’s highly recommended that you don't add the user explicitly to the user right but instead follow the best practice of adding him or her to the Remote Desktop Users group and ensuring that the group isn't missing from the specific user right.

Figure 5: Missing membership to the Remote Desktop Users group

Port Assignments

Another common scenario we come across is port blocking and/or port assignment conflict. To diagnose this problem, you not only want to check whether the default RDP port (3389) is blocked; you also want to make sure that it's being used by the appropriate service (TermService, in this case).

Here's a quick test that uses the Netstat and Tasklist commands, which you run on the server that you're trying to connect to remotely:

C:UsersAdministrator.CONTOSOONE>netstat -a -oActive Connections            Proto    Local Address   Foreign Address           State    PID            TCP      :3389        :0          LISTENING        2252

The results show that the server is listening on port 3389. If port 3389 isn't listed, the server isn't listening on that port (possibly due to a host-based firewall or another ACL mechanism on the host machine that prevents the usage of that port).

But confirming that the port is open is only half of the battle. You still need to make sure that the right service is using that port. So, you grab the Process ID (PID) number from the results and run Tasklist while grep’ing for PID 2252.

C:UsersAdministrator.CONTOSOONE>tasklist /svc | findstr "2252"Image Name      PID       Servicessvchost.exe      2252     TermService

These results tell you that the port is being used by the right service (Termservice, in this case). If you don't see the appropriate service listed, you can conclude that port 3389 is open (i.e., the server is listening on port 3389) but that another application is using it. (The aforementioned command should tell you which application or service is using the port).

There could be legitimate reasons for reassigning the default RDP port to a different application, but then you need to determine which port is assigned to RDP. It's important to note that Microsoft does not recommend changing the port assigned to RDP.

Misconfigured Settings

Another common scenario is where you're limited in the number of users who can connect simultaneously to a Remote Desktop session or Remote Desktop Services session. This scenario might not be obvious at first because it might come in as a "failure to connect" Help desk call. Only after poking around a bit do you realize that although x users are able to connect, the x + 1 user fails with the error that Figure 6 shows. Note that these settings might also affect administrators who are trying to remotely administer a computer in the Remote Administration mode.

Figure 6: Reaching the simultaneous connection limit

Two settings limit the number of Remote Desktop Services sessions that can be active on a server:

Figure 7: Limit Number of Connections setting (click to enlarge)

Figure 8: RDP-TCP Properties setting

Both of these settings help configure the number of simultaneous connections allowed for a connection. Restricting the number of simultaneous remote connections can improve performance because fewer sessions are demanding system resources. We often see admins enabling either of these settings to help improve performance today but not remembering it when they encounter a problem wherein only a few users are able to connect.

Resources

I hope I've assembled a helpful checklist to help you identify some of these problems. For more information, check out "Troubleshooting RDP Client Connection problems." You should also refer to the following articles based on your Remote Desktop Session host server OS:

·         Windows Server 2003

·         Windows Server 2008

·         Windows Server 2008 R2

The article "Troubleshooting General Remote Desktop Error Messages" at documents even more symptoms. Microsoft will regularly update these articles to reflect the latest trends and steps on how to fix them.

Related Reading: