Remote Desktop Disconnections

Modified on Wed, 14 Oct at 3:11 PM

What affects your connection and how we can help.


Dear Customer,

Thank you for letting us know about the disconnections on your Remote Desktop sessions. We understand how disruptive they are, especially when someone is working in Paradigm or another business application.

A Remote Desktop (RDP) session is a live, continuous connection between your computer and your virtual server in the Huawei Cloud South African region. Every keystroke, mouse movement and screen update travels across several pieces of equipment and networks. If any one of them drops or delays traffic, even for a few seconds, the session can freeze or disconnect. Below is an overview of each point along that path, so we can work together to find the cause.

 

1. The user's computer

  • Network card and drivers. Outdated drivers, or Windows power-saving settings that switch off the network adapter, can drop the connection briefly.
  • Sleep and power settings. A laptop that sleeps, hibernates or has its lid closed ends the session.
  • Resource load. A computer that is short on memory or CPU, or busy with updates, antivirus scans or backups, can struggle to keep the session responsive.
  • Remote Desktop client. An old version of the Remote Desktop client increases bandwidth demand. So do demanding display settings, such as several high-resolution monitors.
  • Local software. Personal VPNs, third-party firewalls or "internet security" suites sometimes interfere with RDP traffic.

2. The local network: cable or Wi-Fi

  • Network cables and wall points. Damaged or poor-quality cables and loose connectors cause intermittent drops that are easy to miss.
  • Wi-Fi signal.Several things cause packet loss on Wi-Fi:
    • distance from the access point
    • walls between the user and the access point
    • interference from neighbouring networks, microwaves and other devices
    • many users sharing one access point
  • Wi-Fi roaming. A laptop may switch between access points, or between the 2.4 GHz and 5 GHz bands. The short handover can break the session.

3. Office network equipment: switches and routers

  • Switches. Faulty ports, overheating, or low-cost unmanaged switches under heavy load can drop traffic.
  • Router or firewall. Routers that are overloaded or running old firmware may drop RDP connections. So may routers configured with short idle timeouts, which close connections they consider inactive. Some routers also mishandle the UDP traffic that RDP uses for smoother performance.
  • Internal bandwidth use. Large downloads, cloud backups, video calls or streaming on the same connection compete with RDP traffic. Without quality-of-service (QoS) prioritisation, RDP can suffer.
  • Power interruptions. During load shedding or power dips, routers, switches and access points restart unless they are on a UPS or backup battery. When they restart, every session drops.

4. The internet connection: fibre, LTE/5G, wireless or ADSL

  • Line stability. Brief line drops, even ones that recover on their own, disconnect RDP sessions. Your provider's router logs or line statistics usually show these.
  • Line capacity and contention. If the connection is fully used by other traffic, or the provider's network is congested at peak times, latency and packet loss increase.
  • Connection type. LTE, 5G and fixed-wireless connections are more affected than fibre by signal strength, weather and tower congestion. Towers and network nodes can also go down during extended load shedding.
  • IP address changes. Some connections change their public IP address periodically. This can break active sessions and, depending on your security settings, may affect access to your server.

5. Your Internet Service Provider (ISP) and the path to our data centre

  • ISP network and routing. Traffic passes through several "hops" before it reaches the Huawei Cloud data centre. These are routers belonging to your ISP and to upstream carriers. Congestion, maintenance or faults at any hop can cause latency spikes, packet loss or dropped connections.
  • Peering between networks. The quality of the route depends on how well your ISP connects to the networks serving the cloud region. Two users on different ISPs can have very different experiences connecting to the same server.
  • Traffic routed through other countries. A VPN, a proxy or your ISP's routing may send traffic via an overseas location. This increases latency, and our geofencing security controls may block access from that location.

6. The cloud platform and your virtual server (our side)

  • Server resources. If CPU, memory or disk is under sustained pressure, sessions become sluggish or unresponsive. We monitor these continuously with our RMM tools.
  • Session policies. Idle-session and disconnected-session time limits on the server can end sessions that are left inactive. We can review these settings with you.
  • Maintenance. Scheduled Windows updates, restarts or platform maintenance will interrupt sessions. We schedule these outside business hours and communicate them in advance.
  • Security controls. Our firewall access lists, geofencing and logon policies protect your server. By design, they may block connections from unexpected locations or IP addresses.

Why does the server disconnect a session?

An RDP session is a continuous two-way conversation between your computer and the server. The server constantly sends screen updates, and your computer sends back acknowledgements and keep-alive signals. If those signals stop arriving because packets are lost or delayed along the path, the server retries for a short period. If it still cannot reach your computer, it concludes the connection is gone and places the session in a "disconnected" state.

A disconnect is not a logoff. Your session, open programs and unsaved work stay running on the server, and when you reconnect you return to exactly where you were. The server protects your session this way because it assumes the break was caused by the network rather than by you.

Why the server does not disconnect sessions on its own

The server has no reason to end a healthy connection. As long as it can communicate with your computer, the session stays connected, whether it lasts one hour or ten. A server-side disconnect only happens for a few specific, identifiable reasons:

  • A configured time limit is reached, such as an idle-session limit. The user sees a message that clearly says a time limit was reached.
  • The same user logs on from another computer, which takes over the existing session.
  • An administrator disconnects the session, or the server restarts for maintenance. We schedule and communicate these in advance.

Each of these leaves a clear record in the server's logs and shows a specific message on screen. Users may instead see messages such as "The connection has been lost" or "Attempting to reconnect". Those messages mean the server has stopped hearing from the user's computer. That points to an interruption somewhere between the user's device and the data centre, not to the server itself.

How you can help us resolve this quickly

When a disconnection happens, please send us the following:

  1. The date and exact time of the disconnection.
  2. The username or usernames affected.
  3. Whether it affected one user or several at the same time.
  4. Whether those users were on cable, Wi-Fi or mobile data, and at which site or location.
  5. The exact error message, if one appeared. A screenshot is ideal.
  6. Whether anything else happened at the same time, such as a power interruption, a router restart or other internet issues.

Who is affected is a useful clue:

  • If everyone at one site disconnects at the same moment, the cause is almost always the local network or internet connection at that site.
  • If only one user is affected, the cause is usually their computer, cable or Wi-Fi.
  • If users at different sites and on different ISPs drop at the same time, the cause is more likely on our side, and we will investigate immediately.

With this information we can match the events against our server logs and monitoring data and tell you where the problem most likely lies. If it is outside our infrastructure, we will give you the evidence to take to your IT provider or ISP.

Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article