Enable Remote Desktop on Windows Server 2019: 3 Safe Methods & Hardening

Windows Server 2019 ships with Remote Desktop (RDP) capability turned off by default for safety; enabling it is simple but needs care. This feature piece walks through three reliable methods to enable Remote Desktop on Windows Server 2019 — PowerShell, Server Manager GUI, and the System Properties dialog — then validates the exact registry keys, firewall rules, and ports involved, highlights security hardening you must apply, and gives step‑by‑step verification and troubleshooting guidance so you don’t accidentally expose an enterprise server to the Internet. The short how‑to from Windows Report provides the same three approaches as a starting point, but this article expands each step, cross‑checks key commands against Microsoft documentation, and explains the risks and mitigations you should apply before allowing remote access.

---

Background / Overview​

Remote Desktop Protocol (RDP) is Microsoft’s built‑in mechanism for interactive remote control of Windows hosts. On Windows Server editions — including Windows Server 2019 — RDP can act in two general roles:

• As a basic single‑session remote control for administrators (the built‑in host functionality), and
• As a platform for Remote Desktop Services (RDS) multi‑session deployments (sessions hosting many users using RDS roles).

For the common administrative scenario (enable the host to accept remote admin connections), Windows Server 2019 requires you to explicitly enable the service because the default configuration denies incoming RDP sessions. That default is controlled by a registry flag named fDenyTSConnections. Microsoft documents that setting and its valid values; the default is true (deny), and setting it to false enables RDP.
This article shows three supported ways to flip that switch, then drills into related items you must configure: the firewall rule that permits RDP traffic, Network Level Authentication (NLA), the RDP listening port (default 3389), service health checks, and operational hardening (VPN/RD Gateway, MFA, logging). Where possible, claims and exact commands are verified against Microsoft documentation plus independent community guides to ensure accuracy across environments.

---

Why you must treat enabling RDP as a policy decision​

Enabling Remote Desktop on a server is functionally trivial, but it increases your attack surface. RDP ports (TCP and UDP) are frequently targeted by automated scanners and brute‑force attacks when exposed to the open Internet. Microsoft’s own troubleshooting and ports documentation shows RDP uses TCP and UDP port 3389 by default; while you can change the listening port, doing so is an obfuscation step and not a substitute for proper access controls. Always pair RDP enablement with network controls and strong authentication.
Key security principles to apply immediately after enabling RDP:

• Never expose TCP/UDP 3389 directly to the public Internet without additional controls.
• Use VPN or Remote Desktop Gateway (RD Gateway) for remote access from untrusted networks.
• Require Network Level Authentication (NLA) and, ideally, multi‑factor authentication (MFA) for RDP accounts.
• Limit allowed RDP users to the smallest feasible set and use strong passwords plus account lockout policies.
• Monitor logs and alert on repeated failed logons; retain session logs for forensic readiness.

Microsoft and multiple administration guides emphasize these same protections; they are not optional for production servers.

---

1) Enable Remote Desktop with PowerShell (fast, scriptable)​

PowerShell is the fastest way to enable RDP on a server and is ideal when configuring multiple servers or automating builds.
Why this method: it’s scriptable, repeatable, and suitable for automation or image preparation. Community and Microsoft guidance both use the registry key approach to programmatically enable Remote Desktop by changing fDenyTSConnections and then enabling the firewall rule group for Remote Desktop.

Steps (copy/paste friendly)​

• Open PowerShell as Administrator.
• Run this command to enable Remote Desktop in the registry:
  Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -Name 'fDenyTSConnections' -Value 0
• This sets fDenyTSConnections = 0 which allows RDP connections. Microsoft documents this element explicitly.
• Configure the Windows Firewall to allow Remote Desktop connections:
  Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
• This toggles the firewall rules belonging to the pre‑defined "Remote Desktop" group so the OS accepts incoming RDP traffic. Confirm those rules with Get‑NetFirewallRule if needed.
• Optionally, ensure Network Level Authentication (NLA) is enforced for RDP sessions:
  Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name "UserAuthentication" -Value 1
• Setting UserAuthentication = 1 enforces NLA (CredSSP/Credential security). Use this unless a client compatibility reason forces relaxation. Community guidance and Microsoft troubleshooting threads show this as an important step when addressing authentication failures.

Verify​

• Registry: Get-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -Name 'fDenyTSConnections' should show 0.
• Firewall: Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Format-Table Name, Enabled, Direction.
• Service: Get-Service -Name TermService should show Status = Running (start TermService if needed).

If you prefer a one‑liner, many admins combine the steps into a short script; just validate each step’s success and log outputs for automation reliability.

---

2) Use Server Manager GUI (recommended for admins who prefer UI)​

Server Manager provides a built‑in, supported way to toggle Remote Desktop for the local server. It is often used in GUI‑first environments and when manually provisioning a single server.

Steps​

• Log on to the server with an administrative account.
• Open Server Manager from the Start menu.
• Select Local Server on the left pane.
• Click the value labeled Disabled (or Enabled) beside Remote Desktop to open the System Properties > Remote tab.
• Tick Allow remote connections to this computer. For security, ensure Allow connections only from computers running Remote Desktop with Network Level Authentication (recommended) is selected unless you have a compatibility need.
• Optionally use Select Users to add non‑administrator accounts that need remote access.
• Click OK. If Server Manager still shows “Disabled,” press Refresh or F5 — the view sometimes lags until refreshed.

Notes and verification​

• Server Manager automatically attempts to enable the matching firewall rules, but confirm by checking Windows Defender Firewall or running Get‑NetFirewallRule -DisplayGroup "Remote Desktop".
• If you need to manage many servers centrally, Server Manager supports remote server pools, but remote management specifics and prerequisites vary by Windows Server version. Refer to Server Manager configuration documentation before scaling this approach.

---

3) Use the System Properties dialog (via Command Prompt or Run)​

This is the same UI as the Server Manager path but reached directly.

Steps​

• Press Windows + R, type:
  SystemPropertiesRemote
  and press Enter.
• In the Remote tab of System Properties, tick Allow remote connections to this computer and configure NLA as recommended.
• Use Select Users to add non‑admin accounts if needed. Click OK to apply.

This is a quick method when you’re at the console and prefer a direct dialog rather than navigating Server Manager. The underlying changes are identical to the Server Manager path; the registry and firewall are updated by the system when you apply the change. The WindowsReport guide lists this as the third simple option.

---

Confirming the details: registry keys, firewall groups, and ports​

This section verifies the exact artifacts you’ve changed so you can audit and document the change.

• Registry toggle: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\fDenyTSConnections — 0 = allowed, 1 = denied. Microsoft documents this setting as the definitive control element to enable RDP.
• Firewall group: Enabling the Remote Desktop display group via Enable‑NetFirewallRule manipulates predefined firewall rules that allow the RDP ports to pass. Confirm which rules are enabled using Get‑NetFirewallRule and inspect their associated ports with Get‑NetFirewallPortFilter (or examine Windows Defender Firewall advanced rules). Community guides echo this pattern for a reliable firewall change.
• Default ports: RDP uses TCP and UDP 3389 by default. Microsoft’s RDS/ports documentation lists TCP/UDP 3389 as the standard client/server port and explains how to change it when required. If you change the port, you must update inbound firewall rules and document the new port to avoid lockouts.

---

Essential verification and quick troubleshooting checklist​

After enabling RDP, follow this checklist before you rely on the connection for production tasks.

• Verify registry:
  Get-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections — value 0.
• Verify TermService status:
  Get-Service -Name TermService — Status should be Running. If not, start it: Start-Service -Name TermService.
• Confirm firewall rules:
  Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Where-Object {$_.Enabled -eq 'True'}.
• Check listening port(s):
  netstat -an | findstr 3389
  or use PowerShell: Get-NetTCPConnection -LocalPort 3389
• Test a local connection first:
  From another machine on the same LAN, run mstsc.exe (Remote Desktop Connection) and connect to the server by IP or hostname. If the server uses a non‑standard port, append ort in the connection target (for example, 10.0.0.10:3390).
• If you can’t connect:
• Confirm NLA compatibility (older clients may need updates).
• Verify firewall profiles — the rule may be limited to Domain/Private profiles, and your server might be classified as Public. Adjust profile scope or move server to the correct network profile.
• Check for group policy that blocks remote desktop. Domain policies can override local settings.
• Look for certificate warnings; replace self‑signed RDP certificates with CA‑issued certs in production.

---

Hardening and production best practices​

Enabling RDP without hardening is risky. The following is a prioritized checklist for production servers:

• Use VPN (site‑to‑site or client VPN) or RD Gateway to avoid exposing RDP ports to the Internet. RD Gateway tunnels RDP over HTTPS and provides a hardened entry point; Microsoft recommends RD Gateway for remote user access rather than port forwarding.
• Enforce Network Level Authentication (NLA). It prevents unauthenticated session establishment and reduces exposure to some classes of exploits. Set the registry UserAuthentication = 1 for hosts to require NLA.
• Implement multi‑factor authentication (MFA) for remote access. RD Gateway and many VPN solutions can be integrated with MFA providers. MFA dramatically reduces the chance of credential compromise.
• Limit access with firewall IP whitelisting. Only allow remote access from known office IPs or your VPN gateway addresses.
• Rotate privileged account credentials and avoid using shared admin accounts. Use role‑based access control and Just‑In‑Time (JIT) privileged access where possible.
• Patch RDP stacks promptly. Subscribe to vulnerability advisories for Windows and RDP components; RDP‑related vulnerabilities are regularly patched in Microsoft security updates.
• Centralize logging and alert on repeated failed logon attempts or abnormal session start times. Keep logs for incident response and compliance.

Microsoft and numerous administration guides explicitly recommend these controls; they are standards in hardened server operations.

---

Alternatives to native RDP (when you shouldn’t enable RDP)​

In situations where enabling built‑in RDP is not desirable (e.g., Windows Home targets, unattended support across firewalls, or temporary support sessions), consider these alternatives — but evaluate each for security, licensing, and audit needs:

• RD Gateway / Azure Virtual Desktop / Windows 365 — Managed Microsoft options that add security, logging, and centralized control. RD Gateway tunnels RDP over HTTPS and avoids exposing port 3389.
• Third‑party remote‑support tools — Chrome Remote Desktop, AnyDesk, TeamViewer, Splashtop, RustDesk, Mikogo (mentioned in the WindowsReport guide). These tools can simplify cross‑network access but involve third‑party trust and different licensing models; evaluate vendor security and privacy policies carefully. The WindowsReport article suggests Mikogo as an option but this is a third‑party recommendation and should be vetted against your organization’s security policy and procurement requirements.

Note: Replacing RDP with a third‑party tool shifts trust from Microsoft to that vendor. For production servers, prefer Microsoft’s managed solutions (RD Gateway, AVD) or strictly controlled VPN access.

---

Real‑world pitfalls and how to avoid them​

• Mistake: Changing the RDP port without updating firewall rules and documented client settings. Result: Lockout. Fix: Always maintain a local console session while testing port modifications and keep documentation of the new port. Microsoft’s guidance includes explicit steps to change PortNumber in the registry and adjust firewall rules.
• Mistake: Enabling RDP and relying on obscure ports as a security control. Result: False sense of security. Fix: Use proper access controls (VPN/RD Gateway, IP whitelisting, MFA, and logging).
• Mistake: Forgetting to enable the firewall rule group after toggling the registry key. Result: RDP appears enabled but connections fail. Fix: Run Enable‑NetFirewallRule -DisplayGroup "Remote Desktop" or verify via Windows Firewall advanced settings.
• Mistake: Domain Group Policy overriding local settings. Fix: Check applied GPOs (gpresult /h report.html or RSOP.msc) before assuming local changes take effect.
• Mistake: Using shared administrative credentials. Fix: Use unique accounts, enable MFA, and adopt least privilege.

---

Example: Safe, repeatable PowerShell snippet for automation​

(Use only after vetting for your environment and testing in a non‑production window.)

• Run PowerShell as Administrator.
• Execute:
• Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -Name 'fDenyTSConnections' -Value 0
• Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
• Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'UserAuthentication' -Value 1
• Start-Service -Name TermService
• Validate outputs and log success/failure for each step.

This exact sequence is reflected across community how‑tos and Microsoft guidance for enabling RDP and the required supporting rules. Always test in a lab before running against production servers.

---

Final checklist before calling it done​

• Registry fDenyTSConnections is 0.
• TermService is running.
• Firewall rules for "Remote Desktop" are enabled and scoped to the appropriate network profiles.
• NLA is enforced where client compatibility permits.
• Remote access is tunneled through VPN or RD Gateway for external access.
• MFA is in place for privileged accounts.
• Logging and alerts are configured for failed logon attempts.
• Documentation updated: who can connect, from where, and the exact steps to disable RDP if necessary.

These are the same reliable checks used by admins and documented in Microsoft guidance and community tutorials; perform them as part of server hardening SOPs.

---

Conclusion​

Enabling Remote Desktop on Windows Server 2019 can be done quickly through PowerShell, Server Manager, or the System Properties dialog — each method ends up setting the same underlying registry key and firewall configuration. For automation and scale, PowerShell is preferable; for single‑server or GUI‑centric workflows, Server Manager or SystemPropertiesRemote is fine. However, the technical act of turning RDP on is only the beginning: secure deployment requires firewall scoping, NLA, MFA, VPN/RD Gateway, and monitoring. Verified Microsoft documentation confirms the registry key (fDenyTSConnections), the firewall rule group, and the default RDP ports (TCP/UDP 3389), and community guides align with these steps — but those same resources also emphasize the security imperative: do not expose RDP unfiltered to the Internet.
If you follow the validated steps above and apply the hardening checklist, your Windows Server 2019 hosts will be accessible for remote administration without needlessly increasing risk.

---

Source: Windows Report 3 Ways to Enable Remote Desktop on Windows Server 2019