Windows Server 2025 / How to Enable Remote Desktop and Check Firewall Access

Remote Desktop access to Windows Server 2025 requires server permission, user rights, a working network path, and matching firewall rules. For this administration lab, use a trusted internal network and keep Network Level Authentication (NLA) enabled.

Separate Remote Desktop from other management tools

Remote Desktop opens an interactive server session. Server Manager, Windows Admin Center, and PowerShell remoting use their own communication and authentication paths. Enabling one does not enable all the others.

This exercise is administrative access, not a multiuser Remote Desktop Services (RDS) application deployment. Do not install the full RDS role simply to administer a server. A Core session also remains a Core management environment rather than acquiring the standard desktop. Connect FS1 and CLIENT1 to the same isolated network.

Enable server access while retaining NLA

1. At the FS1 console, open Server Manager → Local Server → Remote Desktop.
2. Allow remote connections while retaining the NLA requirement. On Core, use the Remote Desktop setting in SConfig.
3. Choose the permitted account and required privilege. Add an ordinary user to the allowed users when appropriate, without unnecessary Administrators membership.
4. Save and inspect the active network profile and Remote Desktop inbound rules.

NLA authenticates a user before establishing the full session. Microsoft’s Remote Desktop guidance recommends it for supported clients. Do not begin troubleshooting by disabling NLA or the entire firewall.

Check profiles and allowed address ranges

Open wf.msc and inspect Remote Desktop inbound rules. Names can be localized, so also check protocol, local port, and profile. TCP 3389 is the default Remote Desktop Protocol (RDP) port; use the actual port if it has been changed.

1. Identify whether the active network profile is Domain, Private, or Public.
2. Check that the intended rule applies to that profile instead of allowing every profile indiscriminately.
3. Consider restricting remote addresses to the management PC or management subnet.
4. Look for other rules allowing the same port more broadly. A new narrow rule does not remove an existing broad allow rule.

Do not relabel an untrusted network as Private or hide a domain authentication problem merely to make a rule apply. Check the real network context and domain DNS connectivity.

Connect from the client

On CLIENT1, test the default TCP path, then open the connection tool. TcpTestSucceeded being True does not prove that credentials or logon rights are valid.

Test-NetConnection -ComputerName 172.24.50.20 -Port 3389
mstsc

1. Enter FS1’s IP address or resolvable name in Remote Desktop Connection.
2. Before domain joining, distinguish a local account with FS1\username. After joining, select the intended domain identity.
3. For an unfamiliar certificate warning, verify the destination and certificate rather than blindly accepting an unknown server.
4. After connection, run hostname and whoami to confirm both server and account.

Closing a window may disconnect rather than sign out. Save work and sign out when finished, and do not save credentials on a shared computer.

Use the error to choose the next check

If access is no longer required, disable it from the console and reverse the lab-specific user and rule changes. For external administration, design a controlled VPN or management gateway rather than exposing router port 3389 directly to the internet.