How to Change RDP Port in Windows Server Easily (2016 to 2025)

Bots knock on the RDP port of every Windows Server, 3389, all day. Move Remote Desktop to another port, and most of them walk past. To change the RDP port in Windows Server you edit one registry value, PortNumber. Then you open the new port in Windows Firewall and restart.

The procedure hasn’t changed in years. People lock themselves out all the time, though. So we’d read the safety steps first.

Why move off 3389

Every mass scanner on the internet probes 3389 first. Move the service, and the automated login attempts in your Security log mostly stop. Less noise to sift through.

It’s security through obscurity. Useful as one layer, never enough alone. A full port scan still finds the new port.

Remote Desktop Protocol is the everyday tool for Windows Server management. That convenience has a cost. Port 3389 is common knowledge, and bots hammer any exposed server with password guesses around the clock.

That’s the typical picture on internet-facing servers. With RDP on a high port, the stream of failed logons drops from a constant trickle to almost nothing within a day. Those are the events with ID 4625. Your numbers will differ. The pattern doesn’t.

Think of it like moving a shop’s entrance from the main street to a side door. A burglar who targets that shop will still find it. The passer-by who rattles every handle on the street walks on.

When it’s worth doing

For a server reachable from the internet, yes. As long as you also apply the measures near the end of this page.

For a server reachable only inside a VPN or a management network, the gain is small. A non-standard port can also confuse colleagues and monitoring tools.

Before you touch the registry

Three things. A second way into the server, a backup of the RDP-Tcp key, and a chosen port that nothing else uses. With those in place, a typo costs you a minute. Without them we’d expect a trip to the data center, or a ticket with the host.

1. Out-of-band access. Console access through Hyper-V Manager, VMware, the Azure serial console, or a management card such as iDRAC or iLO. With a physical server in another city, we’d never skip it.
2. A backup. At minimum, export the registry key. On production servers, schedule the change in a maintenance window. Take a full backup or a VM checkpoint first.
3. A list of everything that knows the old port. Router port forwards, cloud network security groups, saved .rdp files, monitoring checks, jump hosts and documentation.
4. A free port. Pick a number from 1025 to 65535 that no other service on the server uses. On internet-facing hosts, skip obvious neighbours such as 3388 or 3390. Scanners check those too.

Check that the port is free. Replace 50123 with your choice:

netstat -ano | findstr :50123

No output? Then nothing is listening on it.

Leave your current RDP session open while you work. An existing session keeps running after you change the value. So you can still fix a mistake, right up to the restart.

Picking the new RDP port for Windows Server

Anything from 1025 to 65535 that’s free on the server. A few practical thoughts on top.

• High, random-looking numbers draw less attention than tidy ones. 50123 beats 4000.
• Stay away from ports other services are known for. 8080, 8443 and 5985 belong to someone else.
• Use the same number on every server you manage, or write each one down. Guessing at 2 a.m. isn’t fun.
• Put the number in your documentation the same day.

One number for the whole fleet is easier to remember. Different numbers per server are harder to guess. We’d pick by how many people need to connect.

How to change the RDP port in Windows Server with Registry Editor

The edit itself takes under two minutes. It works the same on every current server release.

1. Select Start, type regedit and open Registry Editor as an administrator.
2. Go to the RDP-Tcp key. You can paste the path below into the address bar at the top.
3. Double-click PortNumber.
4. Select Decimal first. Then type your new port, 50123 for example, and select OK.
5. Close Registry Editor. Don’t restart yet.
6. Open the firewall for the new port. The next sections show how.
7. Restart the server.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

The default shows as 0x00000d3d in hexadecimal. That’s 3389 in decimal.

Typing the number while Hexadecimal is still selected is the most common mistake of all. 3390 in hex becomes port 13200.

About the restart. Microsoft’s instructions ask for a full one. Restarting the Remote Desktop Services service also applies the new port in practice. It drops every active session, though, yours included.

After the restart, confirm that the listener moved:

netstat -ano | findstr LISTENING | findstr :50123

You should see the new port in the list, and no line for 3389.

The same change with PowerShell

PowerShell changes the same registry value, and it can create the firewall rules in the same session. We’d use it on Server Core, in remote sessions, and whenever more than one server is involved. Run everything below in an elevated Windows PowerShell window.

First, read the current port. These commands follow Microsoft’s own documentation:

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -name 'PortNumber'

Next, back up the key, then set the new value:

reg export "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" C:\RDP-Tcp-backup.reg
$portValue = 50123
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -name 'PortNumber' -Value $portValue

Then add inbound rules for TCP and UDP, and restart:

New-NetFirewallRule -DisplayName 'RDPPORTLatest-TCP-In' -Profile Domain,Private,Public -Direction Inbound -Action Allow -Protocol TCP -LocalPort $portValue
New-NetFirewallRule -DisplayName 'RDPPORTLatest-UDP-In' -Profile Domain,Private,Public -Direction Inbound -Action Allow -Protocol UDP -LocalPort $portValue
Restart-Computer

Microsoft’s example scopes the rules to the Public profile. We add Domain and Private as well, because a domain-joined server uses the Domain profile.

Something went wrong? Go to the console and import the backup. Then restart, and you’re back on 3389:

reg import C:\RDP-Tcp-backup.reg

Double-clicking the exported file does the same.

Several servers at once

For a group of servers, wrap the same commands in Invoke-Command. PowerShell remoting runs on WinRM, on port 5985 or 5986, and not on RDP. So the session survives the port change.

$servers = 'SRV01', 'SRV02', 'SRV03'
Invoke-Command -ComputerName $servers -ArgumentList 50123 -ScriptBlock {
    param($port)
    $key = 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'
    Set-ItemProperty -Path $key -Name 'PortNumber' -Value $port
    New-NetFirewallRule -DisplayName "RDP-TCP-$port" -Profile Domain,Private,Public -Direction Inbound -Action Allow -Protocol TCP -LocalPort $port
    New-NetFirewallRule -DisplayName "RDP-UDP-$port" -Profile Domain,Private,Public -Direction Inbound -Action Allow -Protocol UDP -LocalPort $port
    Restart-Computer -Force
}

Test on one server before you run it against the whole list.

In a domain, Group Policy Preferences can push the registry value too. A firewall rule can come from the same policy, in its Windows Defender Firewall section. New servers then stay consistent without anyone remembering the step.

Opening the new port in Windows Firewall

Windows Firewall only opens 3389 for Remote Desktop. After the change you need a new inbound rule for the new port. TCP and UDP, in every network profile the server uses.

Without that rule the service listens correctly, and every connection attempt times out. That looks exactly like a broken server.

The console route, if you prefer it over PowerShell:

1. Run wf.msc to open Windows Defender Firewall with Advanced Security.
2. Select Inbound Rules, then New Rule in the Actions pane.
3. Choose Port, select TCP and enter the new port under Specific local ports.
4. On the Action page, keep the default action that permits the connection.
5. Tick the profiles the server uses. Domain, Private, Public.
6. Give the rule a clear name, such as RDP custom port 50123 TCP, and finish.
7. Repeat for UDP on the same port.

The built-in rules in the Remote Desktop group are tied to the service. They don’t follow the new port. Leave them alone until the new port works.

Once you’ve connected through the new port, disable the old rules. That closes 3389 for good:

Disable-NetFirewallRule -DisplayGroup 'Remote Desktop'

The profile mismatch is the classic failure. A rule created only for Private does nothing on a domain-joined server, which sits in the Domain profile. Check the active profile with Get-NetConnectionProfile.

Routers, firewalls and cloud rules

Every device between client and server that filters or forwards traffic has to learn the new port. Windows can be perfect, and it still fails at one stubborn layer.

RD Gateway works differently. Clients reach the gateway on HTTPS, port 443. The gateway connects on to the session host, on its RDP port.

So the internal port change matters mostly for the gateway’s resource authorization policy, and for direct internal connections.

Azure VMs

Add an inbound rule for the new port to the network security group first. Only then change the port inside the VM. The other way round, the VM becomes unreachable over RDP. We’d consider Azure Bastion or just-in-time access before opening any port.

Connecting to Windows Server on the custom RDP port

Add a colon and the port number after the server name or IP address. It works in any Remote Desktop client.

srv01.contoso.com:50123
mstsc /v:srv01.contoso.com:50123
[2001:db8::10]:50123

The Windows App on Windows, macOS, iOS and Android accepts the same format.

A few habits save support calls.

• Save the connection as an .rdp file. It stores the port in its full address line, so colleagues don’t have to remember it.
• Tell the team before the change, not after.
• Mac users connect the same way. Our guide to accessing Windows Server from a Mac covers the client side.

Testing the RDP port change on Windows Server

Test from outside the server. A test on the server itself proves nothing about the firewall, the router or the cloud rules in between.

Test-NetConnection -ComputerName srv01.contoso.com -Port 50123
Test-NetConnection -ComputerName srv01.contoso.com -Port 3389

You want TcpTestSucceeded to read True on the new port, and False on 3389.

Then work through the places people forget.

• A connection from outside the company network. Over mobile data, for example.
• A connection over the VPN.
• A client on another operating system, such as macOS.
• Any proxy or jump host your team uses.

From an external host, a port scanner such as Nmap confirms the same thing from the attacker’s side. Run it only against servers you’re allowed to test.

For the first day or two, watch the TerminalServices-RemoteConnectionManager log and the Security log. A burst of failures from internal IPs? We’d look for a saved connection or a script still on 3389.

When the connection fails after the change

Three causes cover most cases. The firewall rule is missing or bound to the wrong profile. The value was typed in hexadecimal. Or an upstream device still forwards 3389.

Check them in that order from the console session.

1. Read the value again with the Get-ItemProperty command above. Is the decimal number the one you expect?
2. List the listeners and look for the port. No listener, and the service didn’t restart or the value is wrong.
3. List which ports your rules open.
4. Check the router, the NSG or the security group.
5. Import the backup if you need RDP back on 3389 quickly.

netstat -ano | findstr LISTENING
Get-NetFirewallRule -DisplayName 'RDPPORT*' | Get-NetFirewallPortFilter

Don’t switch the firewall off to test. That’s risky on a public server. Add a temporary inbound rule limited to your own IP address. It answers the same question without exposing the machine.

What else secures RDP

A custom port only hides Remote Desktop from lazy scanners. Real protection comes from the list below. Combine several, and the port number becomes a minor detail.

• Network Level Authentication. Users authenticate before a full session starts. It’s on by default in current versions. Check it under System Properties, on the Remote tab.
• Account lockout policy. A lockout threshold stops brute-force guessing. Between 5 and 10 attempts balances safety and typos in most environments. We walk through the settings in our guide to password and lockout policies in Windows Server.
• Source IP restriction. Edit the scope of the new firewall rule, so it accepts only office or VPN addresses. With static office IPs, we’d call this the biggest single win.
• RD Gateway or VPN. RD Gateway publishes RDP over HTTPS and can enforce MFA. A VPN keeps RDP entirely private. Azure Bastion does a similar job for Azure VMs.
• Multi-factor authentication. A stolen password and a known port aren’t enough then. Without the second factor the attacker stays out.
• Patching and audits. Install the monthly updates. Review who’s in the Remote Desktop Users group.

The Group Policy location for Network Level Authentication, level by level:

• Computer Configuration.
• Administrative Templates.
• Windows Components.
• Remote Desktop Services.
• Remote Desktop Session Host.
• Security.

Still setting up remote access? Start with our guide on how to enable RDP on Windows Server. Then come back here to move the port.

Typical problems after an RDP port change

The hex typo

An admin types 3390 and clicks OK. Hexadecimal was still selected. The server now listens on 13200, and nobody knows. The console session and one look at the value sort it out.

The rule in the wrong profile

Everything in the registry is right. The rule exists. Connections still time out. The rule was made for Private only, and the server sits in the Domain profile. One more tick box, and it works.

The cloud VM that went silent

Inside the VM, the port gets changed first. The security group still permits only 3389. RDP is gone. The serial console brings the old value back. The group gets its new rule. Then the change is done again, in the right order.

Windows Server versions this guide covers

The registry value, the PowerShell commands and the firewall steps apply unchanged to every current Windows Server release. Desktop Experience and Server Core alike.

You’ll find the same PortNumber value on Windows 10 and Windows 11 Pro, where the Remote Desktop host is available.

Microsoft documents the procedure in its article on changing the Remote Desktop listening port.

Need a server license? We sell a genuine Windows Server 2025 Standard key. Delivery is instant to email.

The RDP port change in short

1. Change one decimal value.
2. Open the new port on TCP and UDP.
3. Update every device in between.
4. Restart.
5. Test from outside.

Done in that order, it’s a ten-minute job with no drama. And the server stops showing up in the logs of every scanner that only knocks on the default door.

Related guides

• Setting Up and Managing FTP Servers in Windows 11