The first task after any Windows VPS is provisioned is getting a remote desktop session to open. The mechanics are standard across providers — you receive an IP address, an administrator username, and a password from the control panel or welcome email, then connect with Microsoft’s built-in Remote Desktop client. What differs is the troubleshooting: most “I can’t connect” tickets come down to five or six specific causes, and knowing them turns a frustrating afternoon into a two-minute fix.
This guide walks through gathering credentials, opening mstsc, saving a reusable connection file, and diagnosing the failure modes you are most likely to hit on a fresh Windows server instance.
Gathering the Right Credentials
After provisioning, your provider sends a welcome message or shows a panel with four values: the public IP address, the administrator username (usually Administrator or a custom admin name), the password, and sometimes a non-standard RDP port. Copy them verbatim — a single trailing space in the username causes a login failure with no useful error.
Change the default password on first login and store it in a password manager. If the panel offers two-factor authentication for the control console, enable it: the console can reset RDP access, so it is the more valuable target of the two.
Opening the Remote Desktop Client (mstsc)
On Windows, press Win+R, type mstsc, and hit Enter. Enter the server’s public IP in the Computer field. If the provider uses a non-default RDP port, append it with a colon — for example 203.0.113.10:3390. Click Connect; when prompted, enter the username and password from your welcome email.
If you connect from macOS, install Microsoft Remote Desktop from the App Store and add a PC with the same IP and credentials. From Linux, Remmina or FreeRDP handles the protocol identically. The server does not care which client you use as long as it speaks RDP.
Saving a Connection for Repeated Use
Typing the IP every time is unnecessary. In mstsc, click “Show Options” then “Save As” to write an .rdp file you can double-click. For teams, store the file in a shared location and set the username field so colleagues only need the password. Avoid saving the password inside the .rdp file unless the machine is your own and encrypted.
Tune the Experience tab for the connection quality: on a fast link, enable “Persistent bitmap caching” and LAN-quality settings; over a slow link, drop to low-bandwidth mode so the desktop remains responsive. These settings are covered in more depth in our Windows RDP optimization material.
Common Connection Failures and Fixes
“Remote Desktop can’t connect to the remote computer.” Usually a firewall rule that does not allow the port, or the server’s RDP service is stopped. Confirm you are using the correct port and that your own IP is permitted.
Credentials rejected repeatedly. Check for hidden spaces, verify Caps Lock, and ensure the account is not locked by a previous failed attempt. Providers sometimes deliver the password with a similar-looking character (0 vs O, l vs 1) — copy rather than retype.
Connection opens then immediately drops. Often an NLA mismatch or certificate issue. If you control the server, ensure Network Level Authentication is enabled and the machine’s clock is correct; a wrong system time breaks RDP’s TLS handshake.
Hardening the Session After First Login
An internet-facing RDP port is attacked within minutes of going live. Restrict inbound 3389 to your own IP range at the firewall, enable Network Level Authentication, set an account lockout policy, and consider moving RDP to a non-standard port as a minor deterrent. For an always-on server, a licensed Windows VPS with these controls applied is far safer than any default configuration.
Finally, verify your server’s health after connecting: check that Windows Update is configured, the disk has free space, and a backup or snapshot exists. The connection is the first step, not the last.
A Quick Troubleshooting Order
When a connection fails, work through it in order: ping the IP, confirm the port is open, check the credentials character by character, verify the RDP service and firewall on the server side, then examine NLA and system time. In nearly every case the fault is one of those five, and a methodical check finds it faster than re-provisioning the server.
Get the session open, then spend your time on configuration and backups rather than connection problems. The setup above works the same on any provider, which means the skills transfer the moment you move to a different host.
Verifying the Server Is Ready After You Connect
A successful login is not the finish line. Open Server Manager and confirm Windows Update is configured with sensible active hours, check that the system drive has adequate free space, and verify the server’s time zone and clock. An incorrect clock breaks Kerberos, TLS and RDP authentication, and it is one of the easiest things to overlook on a freshly provisioned machine.
Next, confirm your snapshot or backup schedule. Many providers offer image snapshots in the control panel; enable them before you install anything, so you always have a known-good state to roll back to. Finally, create a second administrative account with a strong password. If your primary credentials are ever locked out, the secondary account is what gets you back in.
Working Comfortably Once Connected
Adjust a few session settings to make daily work pleasant: copy-paste support between local and remote, mapped local drives for quick file transfer, and local printer redirection if you print from the server. In mstsc’s Local Resources tab, “Clipboard” and “Drives” are the two most useful toggles. They eliminate the need for FTP just to move a file onto the server.
For long sessions, enable reconnection so a brief network drop resumes the same desktop instead of starting a new logon. These defaults are set in the client, not the server, so each machine you connect from should be configured once and the .rdp file saved.



