RDP First-Session Setup on Windows Server: Service, Firewall Scoping, and Lockout Avoidance

The very first thing you do on a fresh Windows VPS is usually the thing you never revisit: signing in over Remote Desktop for the first time. That first session determines whether the server is manageable for the next two years or a source of recurring friction. This is the practical setup sequence — enabling, connecting, rightsizing the experience, and confirming you will not lock yourself out.

For how the underlying machine is provisioned, see windows-vps.org. Below is the operator’s checklist.

Before the first connection: what the provider gives you

Most Windows VPS providers hand you an IP address, an administrator password, and little else. Two things matter immediately: the password is usually generated and should be rotated on first login, and RDP may not be reachable until you confirm the network is not blocking 3389. Test reachability from your own machine before blaming the server:

Test-NetConnection 203.0.113.10 -Port 3389
# or from Linux/macOS:
# nc -vz 203.0.113.10 3389

If the port is closed but you have console access through the provider’s web panel, log in there — that out-of-band console is your safety net for the rest of this article.

Confirm the RDP service and listener state

Once you have any form of access, verify the service and the registry keys that control it rather than toggling a checkbox blindly:

Get-Service TermService | Select-Object Name, Status, StartType

# fDenyTSConnections = 0 means RDP is allowed
Get-ItemProperty 'HKLM:\System\CurrentControlSet\Control\Terminal Server' |
    Select-Object fDenyTSConnections

netstat -ano | findstr :3389

If fDenyTSConnections is 1, set it to 0 and restart the service. The netstat line should show a listener on 0.0.0.0:3389 or the specific IP you bind to.

Firewall rules: scope, do not just open

Opening 3389 to Any is the default mistake. Scope the rule to your own source addresses, and scope it at the Windows Firewall layer so that a mistake in an upstream cloud firewall is not the only thing protecting you.

New-NetFirewallRule -DisplayName "RDP-Scoped" -Direction Inbound `
    -Protocol TCP -LocalPort 3389 -Action Allow `
    -RemoteAddress 198.51.100.0/24,203.0.113.7

Keep a second rule or an upstream allow for a backup network path (a phone hotspot, a VPN exit) so a mistake in IP scoping never becomes a full lockout.

First-session configuration that prevents pain later

• Create a second administrator account and test it in a new RDP session. Never rely on a single account.
• Rotate the generated password and store it in a password manager, not a text file on the desktop.
• Set the machine timezone to your operating timezone so logs and Task Scheduler triggers line up with your expectations.
• Install the RDP client properly — the Microsoft Store “Remote Desktop” app (mstsc successor) handles multimonitor and scaling better than the legacy client.
• Save a working .rdp file with display settings before you change server-side policy.

Changing the RDP port: tempting, rarely worth it

Moving RDP to a non-standard port is the most common first instinct, and it is mostly security theatre. Automated scanners sweep every port, not just 3389, so the change slows a determined scanner by minutes while adding real operational cost: firewall rules to maintain, .rdp files to hand-edit, and the constant risk of forgetting which port a given server uses. If you do it, do it deliberately:

$port = 33890
Set-ItemProperty 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
    -Name PortNumber -Value $port
New-NetFirewallRule -DisplayName "RDP-$port" -Direction Inbound `
    -Protocol TCP -LocalPort $port -Action Allow -RemoteAddress 198.51.100.0/24
Restart-Service TermService -Force

Note the -Force on the service restart: it drops every active session, including yours, so only run it while you have the provider’s out-of-band console open.

Session experience: fix the defaults that annoy you

Two settings cause most first-week complaints. Display scaling on high-DPI laptops makes the remote desktop tiny or blurry — set it client-side in the .rdp file, not server-side. And idle disconnects annoy remote workers; check Remote Desktop Services session timeouts before assuming the network dropped.

Symptom	Likely cause	Where to fix
Tiny/blurry text	DPI mismatch	Client .rdp display settings
Disconnects after minutes idle	Idle session limit	GPO / RDS session timeouts
Second user cannot log in	Single-session limit	Server SKU session cap
Connection refused	Firewall or service	Rule scope / TermService

Network-level hardening worth adding

Firewall scoping stops most noise, but two server-side settings go further. Enable Network Level Authentication so the server demands authentication before allocating a session — this blocks the unauthenticated pre-login attacks that account lockout policies cannot touch. Then check the lockout threshold: a policy of three bad attempts in ten minutes, with a fifteen-minute lockout, is aggressive enough to stop brute force without locking out real users who mistype once.

# Confirm NLA is required
Get-ItemProperty 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' |
    Select-Object UserAuthentication

# Account lockout policy
net accounts

A UserAuthentication value of 1 means NLA is enforced. If it is 0, enable it before opening the port to any network wider than your own.

The lockout-avoidance rule

Before you disable NLA, change the port, or enable a restrictive policy, keep an existing session open and test the new configuration from a second session. If the second session fails, you still have the first one to revert. This single habit prevents almost every “I locked myself out of my own server” incident.

Do these steps in order and your VPS is manageable, recoverable, and pleasant to work in from day one — which is exactly what the first session should establish.