Issue to RDP on server 2025

Question

Issue to RDP on server 2025

Scott Huang 3,451

HI,

It is enabled below to RDP on Local server but I cannot access it using RDP. Any reasons?

User's image

0 comments

2 answers

Your answer

Answer 1

Jason Nguyen Tran 17,025 Independent Advisor

Hi Scott Huang,

There are a few common reasons this can happen. First, please check that the Windows Defender Firewall is allowing inbound RDP traffic (TCP port 3389). Even if Remote Desktop is enabled, the firewall may still block external connections. Second, confirm that the server’s network settings are correct, if the IP address is assigned via DHCP, it may have changed, so make sure you’re connecting to the right address. Third, ensure that your user account has permission to log in via Remote Desktop; only members of the Remote Desktop Users group or administrators can connect.

It’s also worth verifying that no group policy or security configuration is restricting RDP access. In some environments, enhanced security settings or network-level authentication requirements can prevent successful connections. Lastly, if you’re attempting to connect from outside the local subnet, check that routing and NAT rules are properly configured.

I hope these suggestions help you narrow down the issue and get RDP working as expected. If this answer is helpful, please don’t forget to hit “Accept Answer”.

Jason.

Scott Huang 3,451 Reputation points

2026-05-06T06:44:56.49+00:00

Firewall is enabled that on the port 3389. I see that DHCP is enabled. And I'm not sure about the reason of this. Any help?
Jason Nguyen Tran 17,025 Reputation points Independent Advisor

2026-05-06T07:13:21.25+00:00

One possibility is that DHCP may be assigning a new IP address to the server, which can cause confusion if you’re trying to connect using an old or cached address. I recommend verifying the current IP address of the server and ensuring that’s the one you’re using for the RDP client. Another common issue is that while port 3389 is open, the firewall profile (Public, Private, or Domain) may not be aligned with your network type, so double-check that the inbound rule applies to the correct profile.

It’s also important to confirm that your user account has Remote Desktop permissions. Only administrators or members of the Remote Desktop Users group can log in remotely. If you’re connecting from outside the local subnet, routing or NAT rules may need to be configured to allow the traffic through.

Lastly, please make sure that Network Level Authentication (NLA) is either supported by your client or temporarily disabled for testing, as mismatches here can block connections.

I hope these steps help you pinpoint the root cause and get RDP working smoothly. If this answer is helpful, please don’t forget to hit “Accept Answer”.
Scott Huang 3,451 Reputation points

2026-05-06T07:25:51.15+00:00

the firewall profile (Public, Private, or Domain) may not be aligned with your network type, so double-check that the inbound rule applies to the correct profile.

Which rule to check?

I'm using administrator account for this.
Jason Nguyen Tran 17,025 Reputation points Independent Advisor

2026-05-06T07:35:34.8066667+00:00

Since you’re using an administrator account, you already have the right level of access to review and adjust these settings. The key is to make sure that the inbound rule for Remote Desktop (TCP port 3389) is applied to the correct firewall profile, Public, Private, or Domain, depending on how your server’s network is classified.

For example, if your server is joined to a domain, the Domain profile will apply, and the rule must be enabled there. If it’s on a private LAN without domain membership, the Private profile is the one to check. And if the server is treating the network as untrusted, the Public profile will be active. You can confirm which profile is currently in use by opening the Windows Defender Firewall with Advanced Security console and looking at the active profile in the overview section.

Once you know the active profile, verify that the “Remote Desktop (TCP-In)” rule is enabled for that profile. If it’s not, you can edit the rule’s properties and check the boxes for the appropriate profiles. This ensures that the firewall is actually allowing RDP traffic under the conditions your server is operating in.
Scott Huang 3,451 Reputation points

2026-05-06T08:16:35.42+00:00

3389 rule is enabled like

Answer 2

Even though Remote Desktop shows as Enabled on the local server, several other conditions must be correct before RDP connections succeed. Use the following checks in order:

Confirm RDP is actually enabled in the registry

On the server, open Registry Editor and go to:
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server
Verify the fDenyTSConnections value:
- 0 = RDP enabled
- 1 = RDP disabled
If it is 1, change it to 0.

Verify the RDP services are running On the server, open Services and confirm these services are Running:

Remote Desktop Services (TermService)
Remote Desktop Services UserMode Port Redirector (UmRdpService) Start them if they are stopped.

Check that the RDP listener and port are correct

In Registry Editor, go to:
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
Confirm PortNumber is 0x00000d3d (3389).
If a different port is configured, connect using servername:port.

Test local RDP and listener behavior

On the server console, run mstsc and connect to localhost.
- If this fails, the problem is on the server (RDP listener/configuration).
- If this works, the problem is likely network/firewall.

Verify firewall rules for RDP On the server, open wf.msc and check Inbound Rules:

Ensure Remote Desktop - User Mode (TCP-In) and Remote Desktop - User Mode (UDP-In) are Enabled for all profiles.

Or in elevated PowerShell:

  Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Set-NetFirewallRule -Enabled True

If still failing, temporarily disable the firewall to test:

Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False

(Enable it again after testing.)

Test network connectivity to port 3389 from another machine From a machine in the same network, run in elevated PowerShell:

Test-NetConnection -ComputerName <server-name-or-ip> -Port 3389 -InformationLevel Detailed

If TcpTestSucceeded = False, there is a network or firewall/NSG issue between client and server.
If True, focus on server configuration (steps 1–4 and 7–8).

Check for another process using port 3389 On the server, run:

tasklist /svc | findstr TermService
netstat -anob | findstr 3389

Confirm the PID for TermService matches the process listening on port 3389.
If another process is using 3389, stop that process and restart Remote Desktop Services.

Validate RDP certificate and roles

In MMC → Certificates (Computer account) → Remote Desktop, delete the RDP self-signed certificate and restart Remote Desktop Services so it is recreated.
In Server Manager → Manage → Remove Roles and Features, check Remote Desktop Services roles. Remove unnecessary RDS roles (for example, Connection Broker) if this is not an RDS deployment, then restart the server.

If all these checks pass and RDP still fails, collect logs and contact Microsoft Support as indicated in the documentation.

References:

Share via

Issue to RDP on server 2025

2 answers

Your answer