Tutorials How to resolve common problems with Windows Remote Desktop

How to resolve common problems with Windows Remote Desktop

If you are having problems using Remote Desktop (RDP) with your Windows server, there are a couple of things that could be at fault. This troubleshooting guide aims to help in ruling out some of the most common causes for poor functionality.

Problems connecting

Even while you might have trouble connecting using Remote Desktop, you should always be able to log in to the web console at your UpCloud control panel, or by VNC connection, which settings can also be found at your server details.

Once you’ve connected to your server, through either of the methods mentioned above, you should be greeted by Windows lock screen. Sign into your server with an account that has administrator privileges to continue troubleshooting.

If the connection shows something other than the lock screen, try if the server seems responsive, should it not react to commands you might have to restart your server.

Remote Desktop settings

When you are logged in and the server seems to be working, but RDP still cannot connect, make sure a remote connection is allowed. The easiest way to get to the option is to open sysdm.cpl by searching for it on the start menu, and moving to the Remote tab.

The Remote Desktop needs to allow connections from other computers for the feature to work. If your server was set to allow remote control with Network Level Authentication, make sure your own computer supports this or select to allow any connection. You can find more information about Network Level Authentication at Microsoft’s TechNet.

While still at the RDP settings, check the allowed users by clicking the Select Users or by pressing S. All users with administrator access are automatically permitted to connect, but all normal users must be added to this list. If you were trying to connect with user credentials that do not have admin rights, add the username you wish to connect with to the list of allowed users.


The Windows Firewall might be a little restrictive at times, for example, inbound ICMP protocol that ping connections use are disabled by default. Open the Windows Firewall with Advanced Security by searching for “firewall” in the start menu. Move to the Inbound Rules list and scroll down to Remote Desktop rules by pressing R.

Windows Server 2008 should show two rules: Remote Desktop (TCP-In) and Remote Desktop - RemoteFX (TCP-In). Both of these would in most cases be enabled as long as the server is still using the standard 3389 TCP port for RDP connections.

With 2012 Windows Servers the rules are split between Domain and Private, or Public profiles as well as TCP and UDP protocols, which translates to 4 separate Remote Desktop - User Mode rules, all of which would usually be enabled.

Optionally while at the firewall settings, you may wish to enable ICMP for ping. You can find the rules, called File and Printer Sharing (Echo Request - ICMPv4 - In) and v6 for both IP versions, by pressing F.

When you are certain that the Windows Firewall is allowing RDP connections, also check the server specific firewall settings at your UpCloud control panel. If you have set the default incoming rule to reject, remember to add a rule to permit traffic to the port Remoter Desktop server is listening to, 3389 by default. You can find out more about the UpCloud firewall at the tutorials.

Network connection

Test the internet connection on your server to make sure all your network resources work as they should. Start by pinging out from your server. Open the Command Prompt by typing cmd in the start menu search and press enter then use the command below.


If you enabled the echo requests from Windows Firewall, you can also attempt to ping your server from your own computer. You can find the server’s public IP address on your UpCloud Control Panel under Network and Public Network.

In case the internet connection does not seem to work, check your IP configuration on Command Prompt with the following command.


The output will list all of your servers network connections, you should see 3 Ethernet adapters: the private network, public IPv4 and public IPv6. Check that these match with the network information in your server details under Network tab at your UpCloud control panel.

If you see differences in the ipconfig output and your server network details page, check that all network interfaces are set to obtain the IP addresses automatically. To do this, search for Network Connections in the start menu and press enter to open it. Open the Properties for one of the Ethernet adapters, select Internet Protocol Version 6 or 4 and click on Properties button underneath. Make sure both radial buttons are set to automatic and press OK to save. Check through all of the network adapters on the server the same way.

Slow connection

If your Remote Desktop connection works, but feels slow or disconnects at times, you should try updating the network drivers. Download the latest Virtio drivers for Windows.

After downloading the ISO file on your server, with Windows Server 2008 you will need to have a program like 7zip to unpack it, on Server 2012 you can simply mount the file as a disk.

With the files available, open the Device Manager simply by searching for it by name in the start menu and pressing enter. Browse down to Network adapters, select each adapter one by one and run the Update Driver Software. In the update wizard, select Browse my computer for driver software, enter the driver location to the search field and press next. Note to keep the Include subfolders selected.

If you were connected through Remote Desktop while updating the network drivers, you’ll probably get disconnected for a moment, but the client should be able to restore the connection automatically after the drivers have been installed successfully.

Port conflict

In some cases, it is possible to have another application unintentionally using the same port as Remote Desktop, which can cause connection issues or prevent RDP from connecting.

Check the ports used by programs by entering the command below on Command Prompt.

netstat -a -o

Netstat will print out a list of IP addresses and port numbers they use. Look for rows with your RDP port number (3389 by default) and check the program ID (PID) at the end of these lines. One PID will belong to the RDP service, but if you see another PID using the same port these will conflict with one another.

To find out which programs the PIDs belongs to, use the following on Command Prompt.

tasklist /svc

Remote Desktop will be listed as svchost.exe TermService, any other PID using the same port number is causing issues.

Change RDP port number

Should you find a port conflict, you can resolve it by changing the port used by one of the applications. Microsoft recommends to ideally change the port used by any other applications, but if this is not possible, the port number Remote Desktop listen to can be changed with a couple of steps.

Changing the port number can also help to reduce intrusion attempts through obfuscation, but this should not be your only method of security.

To change the port number, you’ll first need to choose a free port not used by anything else on your server. Check the ports currently in use with netstat -a -o as described previously. The new port number can be anything from 1024 through 49151.

Add the port number you’ve selected to the Windows Firewall Inbound rules by creating a new rule. In the New Inbound Rule Wizard, select the following

  • Rule Type: Port
  • Protocol and Ports: TCP, Specific local ports, <port number>
  • Action: Allow the connection
  • Profile: all options ticked
  • Name: Remote Desktop – TCP <port number>

In the steps above the <port number> is the new port you wish RDP to listen to. Make sure your new firewall rule is set up correctly, as once you change the RDP port you’ll need it to work to be able to connect again.

The port number for RDP was not designed to be changed, and the only way to do so is through editing registry. We highly recommend that you make a backup of your server before making any changes.

Open the editor by searching for regedit in the start menu and pressing enter.

Locate the following key in the registry file system.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal SErver\WinStations\RDP-Tcp\PortNumber

Open the PortNumber registry key for edit, change the display to Decimal, enter your new port number and click OK to save the changes.

For the changes to get applied, you will need to restart the RDP service. Open Services again by searching for it in the start menu and pressing enter to run the program.

In the Services (Local) list, scroll down to find Remote Desktop Service, and restart it. A confirmation popup will ask to restart other related services as well, click Yes to continue.

You will get disconnected if you were using RDP to make these changes. Afterwards just reconnect to your new port by defining it in the Computer field on RDP connection.


With the new port, you should get uninterrupted reliable remote access.

Getting help

If you ran into deeper trouble or need help with something else, don’t hesitate to ask. When contacting UpCloud Support, try to explain the problem to the best of your ability, and include any steps you’ve already taken together with their results while troubleshooting the issue. It will help our support team in solving your problem.

6 thoughts on “How to resolve common problems with Windows Remote Desktop

  1. Hello,

    I am using Microsoft Windows 2008 R2 Server, where Microsoft Dynamics Great Plains 2013 is hosted. Everything has been working so smooth until 2 days back, when client computers cannot connect to the server through remote desktop connection. When you ping the server from client you get reply and vice-versa. I have checked if remote desktop connection is enabled, i have ran out of ideas. please help.

    1. Hi Bolokang, if you have access to the server through other means, I’d suggest checking that RDC is listening by using netstat -ano | findstr 3389 in the CMD. Assuming you are still using the default port. If there are no ports open and listening, check that the service called Remote Procedure Call (RPC) and its dependencies are running and restart them if not.

  2. Hi, How can I avoid RDP Session Ids greater than a certain number or keep RDP Session Ids within a range? I want customers to fall directly into a website logged-in area , and that is supported via cookies loaded after a username/password is entered. Problem with RDP is that the cookie remain at the RDP Session Id where it has been entered, and is not seen by other Session IDs. Eve if I limit the number of connections to ” 5″ at Group Policy Editor and access the server 5 times via RDP , enter in Username/password in all those sessions, and then disconnect them all at once, and try a new re-connection, I might get a new Session Id “6” that will not have been given the Username/Password in a a previous access, and as a result, when I access the server I am NOT logged in the internal area of the website. I have been trying man GPEDIT configurations but there’s always a chance a new connection will get a Session Id which has not been logged before. I think I can use brute force and log n to all Session Ids that come up in the horizon while I am using 5 ports, but It will be a nightmare later on, with 50 ports.
    A real solution would be sharing cookies across RDP Session Ids…. Is that anyway that can be achieved? I have looked around hard yesterday and still no clue how to achieve that …. Thanks Much

  3. Hi Janne,

    While connecting 2012 server RDP it is closing within a seconds for the particular user under domain and for other users its working fine. Please suggest me to fix the same.

    1. Hi Mohammed, it sounds like the issue might be with the user’s client or internet stability if everyone else is able to maintain RDP connection. Any error messages should help in troubleshooting the problem further.

Leave a Reply

Your email address will not be published. Required fields are marked *


Helsinki (HQ)

In the capital city of Finland, you will find our headquarters, and our first data centre. This is where we handle most of our development and innovation.


London was our second office to open, and a important step in introducing UpCloud to the world. Here our amazing staff can help you with both sales and support, in addition to host tons of interesting meetups.


Seattle is our 4th and latest office to be opened, and our way to reach out across the pond to our many users in the Americas.


Singapore was our 3rd office to be opened, and enjoys one of most engaged and fastest growing user bases we have ever seen.