Remote Desktop Protocol is the standard way to reach a Windows server running in a data centre. The client ships with every Pro and Enterprise edition of Windows, so most of the work is choosing the right connection settings and understanding why a login sometimes fails before it reaches the desktop.
This walkthrough covers the mstsc client from the first connection to the settings that make day-to-day sessions faster, plus the error messages you are most likely to meet. If you are still deciding which server image to run, our Windows VPS comparison table lays out the RDP-ready templates and the resource tiers that suit different workloads.
Confirm the server is reachable
Before touching the RDP client, prove that the host is up and that port 3389 is open. From a command prompt on your workstation:
Test-NetConnection 203.0.113.10 -Port 3389
A TcpTestSucceeded : True result means the network path and the listener are both fine, so any failure after that point is authentication, certificate, or session configuration. If the test fails, check that the provider firewall allows your source IP and that the guest firewall has an inbound rule for Remote Desktop. A silent timeout usually means a network-level block; an immediate refusal usually means nothing is listening on the port at all.
One nuance worth knowing: some providers expose RDP on a non-standard port to reduce noise from automated scanners. If your control panel issued a port other than 3389, use that value in the address field as host:port and in the test above.
Open the client and set the essentials
Launch mstsc.exe, enter the public address or hostname of your server in the Computer field, then open Show Options to fill in the details that matter:
- User name — use
SERVERNAME\Administratoror.\Administratorif the account is local. A bare username can be resolved against the wrong domain. - Allow me to save credentials — convenient on a trusted personal machine, but skip it on shared hardware.
- Experience tab — pick LAN (10 Mbps or higher) for a data-centre link, or Modem when you are tethered.
- Display tab — choose a resolution and colour depth your link can carry; 32-bit colour over a congested link causes noticeable lag.
Save the connection as a .rdp file when you are finished. It keeps every setting, including gateway and certificate preferences, so you can launch the same configuration from a shortcut or hand it to a colleague without retyping credentials.
Why the first login sometimes fails
The identity of the remote computer cannot be verified
This warning appears because the server presents a self-signed certificate that the client cannot trace to a trusted authority. Inside a data centre the host is one you provisioned, so choosing Don’t ask me again for connections to this computer and continuing is normal. A certificate warning on a host you do not recognise is a genuine reason to stop, because it can indicate a man-in-the-middle proxy.
An authentication error has occurred (Code: 0x80004005 or 0x80090302)
These codes point at a CredSSP or Network Level Authentication mismatch, often after patching changed the CredSSP encryption oracle setting on one side of the link. Server and client must agree on the required encryption level, and a mismatch surfaces as an authentication failure before the login screen ever renders. The same symptom appears if the server requires NLA but the connecting account is blocked by a lockout policy.
# Check the auth level and RDP listener state
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' | Select-Object UserAuthentication, SecurityLayer
Get-Service TermService
(Get-NetTCPConnection -LocalPort 3389 -State Listen).OwningProcess
The number of connections is limited
An administrative session limit or an expired RDS CAL produces a message about the connection limit being reached. Sign out stale sessions from the server console or with qwinsta and rwinsta, and check licensing if the limit returns every day.
Dial in the settings that change how it feels
Two things dominate perceived performance once the connection works. First, disable desktop composition, menu animations, and font smoothing on the client’s Experience tab — they add round trips for little benefit on a remote session. Second, keep your session resolution close to your local monitor; upscaling a large desktop over a thin link forces the client to re-render more pixels than it needs.
For users on high-latency links, the Persistent bitmap caching option meaningfully reduces redraw traffic, at the cost of disk space in the local cache folder. Enable it for regular connections and disable it on shared machines.
Reconnect, gateway, and multi-monitor notes
If you reach the server through a Remote Desktop Gateway, the gateway address belongs on the Advanced tab, not in the Computer field. When a session drops, the default behaviour is to reconnect automatically; the Reconnect if the connection is lost checkbox controls that, and it works best when the server keeps disconnected sessions alive rather than logging them off immediately.
Multi-monitor setups need the display setting matched to the monitors actually available. A saved .rdp file that requests four monitors will open a single maximised window on a laptop unless Use all my monitors for the remote session is set, which is a common source of “it looks wrong” reports.
A short pre-flight checklist
- Network path verified on the correct RDP port from your source address.
- Credentials entered as
SERVERNAME\userand stored only where safe. - Experience and Display tabs tuned for your link speed.
- Connection saved as a reusable .rdp file.
- Port restricted to known IP addresses rather than the whole internet.
- Gateway configured on the Advanced tab when one is in use.
Work through that list once and the connect-and-login step stops being the part of server administration that consumes your time. When you are ready to move from testing to a permanent environment, see the full specs and pricing so you can match vCPU, RAM, and disk to the number of concurrent RDP users you expect.


