Change RDP Port in Windows Server Easily

Ever left your Remote Desktop connection on the default port and wondered if you’re basically inviting trouble? That’s a concern many Windows administrators face: stick with standard settings or take steps toward stronger security. Learning how to change RDP port in Windows Server adds a practical defense layer that’s worth the effort.

Why Change Your RDP Port from the Default 3389

Remote Desktop Protocol (RDP) stands among the most practical tools for Windows server management, enabling control from virtually anywhere. But convenience brings risk. RDP listens on TCP port 3389 by default—information every hacker, script kiddie, and automated scanner already knows.

Default RDP configurations attract automated attacks constantly. Security data shows typical internet-facing servers face dozens (sometimes hundreds) of RDP intrusion attempts daily. During the remote work surge, RDP attacks reportedly increased 768%, with most targeting port 3389.

Changing from port 3389 applies what security professionals term “security through obscurity.” Obscurity alone isn’t comprehensive protection, but it removes your server from targeting by unsophisticated automated attacks—which reportedly comprise roughly 70% of initial breach attempts.

Think of it like moving your house entrance from the obvious front door to an unmarked side entrance. Determined attackers targeting your property specifically will eventually locate it, but opportunistic criminals typically move to easier marks. Your server faces similar dynamics—targeted attacks remain feasible, but you immediately vanish from automated scanners hunting port 3389.

The security benefit comes with negligible operational impact. When servers face relentless daily attacks, any legitimate method reducing attack surface warrants attention.

Before You Start Making Changes

Proper preparation matters before modifying Remote Desktop port configurations. Groundwork prevents that awful realization you’ve locked yourself out.

Create a complete system backup or restore point at minimum. Registry changes occasionally produce unexpected results, and having fallback options ensures recovery without extended downtime. For production servers, schedule changes during maintenance windows when temporary inaccessibility won’t disrupt operations.

Document your current remote access setup thoroughly: existing firewall rules, port forwarding settings, VPN configurations referencing the default RDP port. This documentation serves dual purposes—providing references for updating related systems and offering recovery guidance when problems emerge.

Select your new port carefully. Pick numbers above 1024 (avoiding well-known service conflicts) but below 65535 (maximum TCP port value). Skip commonly used alternatives like 3390 or 3388, which attackers often check alongside defaults. Choose something less predictable—perhaps from an internal numbering scheme meaningful to your organization but not easily guessed externally.

Critical point: ensure alternative access methods exist. Console access, management networks, or remote management cards (iDRAC, iLO, etc.) provide backup access paths, preventing minor configuration hiccups from becoming major outages requiring physical intervention.

Method 1: Changing RDP Port Through Registry Editor

The most direct approach involves modifying the Windows Registry. While “registry editing” sounds daunting, this particular change requires straightforward modification of a well-documented key.

Connect to your server and launch Registry Editor by typing regedit in the Run dialog or Command Prompt. Exercise appropriate caution with registry work—incorrect changes affect system stability.

Navigate to: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

Within this key, locate “PortNumber.” By default, this shows decimal “3389” (or “0x00000D3D” in hexadecimal). Right-click this value, select “Modify,” enter your chosen port number. Verify your new port doesn’t conflict with existing services.

After changing this value, restart Remote Desktop Services or reboot for the configuration to take effect. Some administrators report success simply restarting the service (via Services.msc or using net stop termservice followed by net start termservice), though full system restart applies changes more reliably.

Quick tip: verify the change applied correctly before disconnecting your current session. Check active listening ports using netstat -an | find “LISTENING” and confirm your new port appears while the old one doesn’t.

Method 2: Using PowerShell to Change RDP Port

PowerShell offers scalable approaches for administrators preferring scripts or implementing changes across multiple servers. This proves valuable in enterprise environments requiring consistent configurations across server farms.

PowerShell involves the same underlying registry change but wrapped in an administrator-friendly package with better error handling and logging. Here’s a script template:

# Define the new RDP port

$NewRDPPort = 7389  # Replace with your chosen port

# Create a registry backup before making changes

$BackupPath = “C:\RDPPortBackup.reg”

reg export “HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp” $BackupPath

# Change the port in registry

Set-ItemProperty -Path “HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp” -Name “PortNumber” -Value $NewRDPPort

# Update the firewall rule

$FirewallRuleName = “Remote Desktop”

$ExistingRule = Get-NetFirewallRule -DisplayName $FirewallRuleName -ErrorAction SilentlyContinue

if ($ExistingRule) {

    # Update existing rule

    Set-NetFirewallRule -DisplayName $FirewallRuleName -LocalPort $NewRDPPort

} else {

    # Create new rule

    New-NetFirewallRule -DisplayName $FirewallRuleName -Direction Inbound -Protocol TCP -LocalPort $NewRDPPort -Action Allow

}

# Output confirmation and reminder

Write-Host “RDP port has been changed to $NewRDPPort. Please restart the server to apply changes.”

Write-Host “Remember to connect using the new port: mstsc /v:servername:$NewRDPPort”

This script exceeds simple port modification—it creates registry backups and updates associated firewall rules, both critical steps sometimes overlooked during manual changes.

For multi-server deployments, extend this with remote execution:

$Servers = “Server1”, “Server2”, “Server3”

$NewRDPPort = 7389

foreach ($Server in $Servers) {

    Invoke-Command -ComputerName $Server -ScriptBlock {

        param($Port)

        # Insert the script above here, using $Port instead of $NewRDPPort

    } -ArgumentList $NewRDPPort

}

This ensures consistent configuration across environments with centralized execution and error reporting—significant advantages over manual methods with multiple servers.

Updating Windows Firewall for the New RDP Port

After changing RDP configuration, updating Windows Firewall ranks as the next critical step. Your server might have correct listening ports, but without proper firewall rules, connection attempts never reach the RDP service.

The straightforward approach uses Windows Firewall with Advanced Security, accessible through Administrative Tools or typing wf.msc at the command prompt. Navigate to Inbound Rules and locate “Remote Desktop” rules—typically multiple entries covering different profiles (domain, private, public).

Creating a new rule often provides cleaner results than modifying existing ones. Click “New Rule” in the Actions pane, select “Port” as rule type, specify “TCP” and enter your new port number. Continue through the wizard, selecting appropriate profiles and naming the rule descriptively like “RDP – Custom Port 7389.”

PowerShell handles firewall updates with:

New-NetFirewallRule -DisplayName “RDP Custom Port” -Direction Inbound -Protocol TCP -LocalPort 7389 -Action Allow

After creating the new rule, verify it appears in active inbound rules with correct configuration. Common mistakes include creating rules applying to incorrect network profiles—if your server uses “Domain” profile but your rule only applies to “Private,” connections fail despite seemingly correct configuration.

For optimal security, disable or remove original RDP rules for port 3389 after confirming your new configuration works. This ensures you’re not accidentally leaving the default port accessible alongside your new configuration.

Network and Router Configuration Considerations

Changing your server’s RDP port affects not just Windows Server but potentially several network components between remote users and your server. These network layers require careful updates to maintain accessibility while preserving security improvements.

Servers behind NAT routers or firewall appliances need updated port forwarding rules matching your new configuration. Access your router’s administration interface and locate port forwarding (sometimes called “virtual servers” or “service forwarding”). Update or create rules forwarding your chosen external port to the same internal port on your server’s IP address.

VPN solutions for remote access face additional considerations. If your VPN includes split tunneling where only certain traffic passes through VPN connections, you might need updating VPN client configurations to recognize the new RDP port as tunneled traffic.

Multi-tiered network architectures involving jump servers or Remote Desktop Gateways require configuration changes extending beyond just destination servers. Each component in the connection chain needs appropriate updates maintaining end-to-end connectivity. Document each required change before implementation ensuring nothing gets overlooked.

Important consideration often missed: DNS records or connection brokers might hardcode port information. If you’ve created convenient DNS CNAME records like “rdp.company.com” pointing to your server, check whether these include SRV information specifying ports. Similarly, connection brokers or remote desktop management tools often store port information requiring updates.

Testing Your New RDP Port Configuration

After implementing changes, thorough testing ensures your new configuration functions as expected. Proper validation prevents uncomfortable situations where remote users suddenly report connection failures.

Basic testing uses standard Remote Desktop client with explicit port specification:

mstsc /v:servername:7389

Where “7389” represents your newly configured port. Test from multiple network locations when possible, not just your current location. Common testing omissions:

• Testing from outside corporate networks
• Verifying connections through VPN services
• Confirming access from different client operating systems
• Validating connections through any proxy servers in your environment

Beyond connectivity tests, verify the default port actually closed. Use port scanning tools like Nmap from external networks confirming port 3389 no longer responds while your new port correctly accepts connections. This validation ensures you’ve achieved security benefits, not just added alternative access methods.

For production servers, monitor connection logs for 24-48 hours after implementation. Unexpected connection failures might indicate overlooked configurations in intermediate network devices or client settings requiring additional updates.

Quick troubleshooting tip: if connections fail despite seemingly correct configuration, temporarily disable Windows Firewall determining whether issues lie with RDP configuration itself or firewall rules. This diagnostic step often reveals true sources of connectivity problems.

Additional Security Measures Beyond Port Changes

Changing from port 3389 represents a positive security step but shouldn’t stand alone in defense strategies. Think of custom RDP port configuration as one layer in comprehensive security approaches—important but insufficient by itself.

Network Level Authentication (NLA) provides significant security enhancement with minimal configuration effort. This feature requires users to authenticate before establishing full RDP sessions, preventing certain attacks targeting the RDP service itself. Enable NLA through Remote Desktop Session Host Configuration or Group Policy at Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services.

Remote Desktop Gateway services offer powerful protection layers, particularly for organizations with multiple RDP-accessible servers. This approach tunnels all remote desktop connections through single, heavily secured gateway servers, applying consistent authentication, authorization, and encryption policies across environments. Gateways can implement additional protections like multi-factor authentication, device compliance checking, and comprehensive connection logging.

Account lockout policies play crucial roles defending against brute force attacks. Configure reasonable lockout thresholds (typically 5-10 failed attempts) with appropriate reset periods balancing security against legitimate users occasionally mistyping credentials. For sensitive environments, implement progressively longer lockout periods for repeated failures—dramatically increasing time required for successful brute force attacks.

IP restriction represents another effective complementary measure. Configure Windows Firewall rules accepting RDP connections only from specific IP addresses or ranges associated with legitimate users. For organizations with predictable connection sources (like branch offices with static IPs), this significantly reduces exposure without affecting legitimate access.

Multi-factor authentication provides perhaps the strongest additional protection for RDP connections. Solutions range from Microsoft’s built-in options (for domain environments) to third-party products integrating with RDP authentication. Implementation complexity varies, but security benefits prove substantial—even if attackers somehow discover your custom port and obtain valid credentials, MFA prevents unauthorized access without the second factor.

Regular security audits of RDP configuration matter as much as technical measures. Use penetration testing tools (with proper authorization) scanning servers for RDP vulnerabilities, verifying default ports remain closed, and confirming chosen security measures function as expected. Regular testing identifies configuration drift or security gaps before attackers discover them.

Implementing these complementary security measures alongside your custom RDP port creates defense-in-depth strategies significantly raising barriers for potential attackers. Each layer may seem incomplete alone, but together they form formidable barriers against unauthorized access—transforming servers from easy targets to hardened systems encouraging attackers to look elsewhere.

Understanding how to change RDP port in Windows Server and implementing supporting security measures demonstrates proactive security management distinguishing truly secure environments from those merely hoping to avoid becoming targets. That difference might ultimately determine whether servers remain secure in increasingly hostile digital landscapes.