Microsoft shipped Windows Server 2019 with Remote Desktop disabled by design. That decision wasn’t an accident — it was a response to years of ransomware gangs, brute-force bots, and accidental exposures that turned port 3389 into a global attack surface. Last week’s fresh guidance from Windows Report and hardening how-tos across administration sites don’t announce any new vulnerability. They serve as a collective reminder that enabling RDP remains one of the riskiest things you can do to a server, and it’s also one of the most common.

The how-to from Windows Report, which appeared on March 15, 2025, boils the process down to three methods: PowerShell, Server Manager, and the System Properties dialog. But the real story isn’t how to check a box. It’s how to do it without turning a production machine into low-hanging fruit for opportunistic attackers. This guide walks through exactly what happens under the hood, which method fits which scenario, and the non-negotiable hardening steps that should be completed before any remote session connects.

What Actually Changes When You Enable Remote Desktop

Flipping the Remote Desktop switch isn’t magic. It’s a tidy chain of configuration changes that can be traced and audited. At the center is a single registry value buried under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server called fDenyTSConnections. Microsoft’s own documentation confirms that this is the master on/off switch for incoming RDP connections.

  • fDenyTSConnections = 1 (default): Denies all remote connections.
  • fDenyTSConnections = 0: Allows remote connections.

Changing that value alone is not enough. The operating system also must create or enable specific Windows Defender Firewall rules that permit RDP traffic on TCP and UDP port 3389. These rules belong to the predefined display group “Remote Desktop.” Finally, the service that actually listens for connections — TermService — needs to be running. If any one of these pieces is missing, the server won’t accept remote sessions, even though Windows might report that Remote Desktop is enabled.

Network Level Authentication adds another layer. It’s governed by UserAuthentication in the registry path HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp. Set to 1, it requires that the client authenticate before a full RDP session is established, which dramatically reduces exposure to credential-stuffing attacks and certain older exploits. Microsoft has been urging administrators to keep this enabled since Windows Vista/Server 2008.

Three Paths to Enable RDP — and When to Use Each

All three methods manipulate the same registry key, firewall rules, and service, so there’s no “secret sauce” in any one of them. The difference is speed, repeatability, and suitability for automated deployments.

PowerShell: The Automation Favorite

If you manage more than one server, PowerShell is the only sensible starting point. The sequence that gets RDP up and running with NLA enforced looks like this:

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

This snippet is idempotent — safe to run multiple times — and can be dropped into a provisioning script or a Group Policy startup script. The Windows Report article and several community guides confirm that it matches what the GUI toggle does behind the scenes.

When to pick PowerShell:
- Deploying dozens of servers via template or automation
- You need a log of exactly what changed
- You’re working on Server Core installations with no GUI

Server Manager: The GUI-Admin’s Button

Server Manager is the built-in GUI that most Windows admins are familiar with. After logging in with administrative rights, you go to Local Server, click the Remote Desktop status link, and arrive at the familiar System Properties > Remote tab. Checking Allow remote connections to this computer and keeping the NLA checkbox ticked is all you need.

But veteran admins know two quirks: the status tile sometimes says “Disabled” even after the change, requiring a manual refresh (F5), and the firewall rules aren’t always enabled reliably if the server has been moved between network profiles. Always verify with Get-NetFirewallRule -DisplayGroup "Remote Desktop" before walking away.

When to pick Server Manager:
- Single-server, interactive setup
- You prefer a visual overview of local server settings
- You’re already in the Server Manager workflow for role installation

System Properties Dialog: The Direct Shortcut

This is the same dialog, reached faster. Press Windows + R, type SystemPropertiesRemote, and press Enter. Tick the same checkbox, confirm NLA, and click OK. Under the hood, it triggers the same registry and firewall writes. It’s the quickest manual method and doesn’t require Server Manager to be open.

When to pick the dialog:
- You’re at the console and want to avoid hunting through Server Manager
- You’re following a phone-step with a junior admin who just needs to click one thing

Verification: Don’t Trust the Checkbox

A green icon or a “Remote Desktop is enabled” message is not a guarantee. System admins who’ve been burned by this know to run a quick battery of checks before relying on the connection:

  • Registry: Get-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections — must return 0.
  • Firewall: Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Where-Object Enabled -eq True — should show at least two rules (inbound TCP and UDP).
  • Service: Get-Service TermService — status Running.
  • Listening port: Get-NetTCPConnection -LocalPort 3389 or netstat -an | findstr 3389 — should show a listening entry.
  • Local test: From a machine on the same LAN, fire up mstsc.exe and connect using the server’s IP. If you changed the default port, append :port (e.g., 10.0.0.10:3390).

If it fails, the top culprits are: firewall rules limited to the Domain profile while the server is on a Public profile, a Group Policy that overwrites the local setting, or NLA incompatibility with an ancient client (Windows XP or some thin clients).

The Hardening You Can’t Skip

Enabling RDP and calling it a day is a recipe for a security incident. Microsoft’s own best practices, echoed by every competent guide, say that port 3389 should never face the open internet without a tunnel. Here’s the checklist that separates a functional remote desktop setup from a hardenend one:

  • Never expose RDP directly to the internet. Use a VPN (site-to-site or client VPN) or a Remote Desktop Gateway (RD Gateway) that encapsulates RDP inside HTTPS.
  • Enforce NLA. The UserAuthentication=1 registry value must be set on all hosts.
  • Add MFA. RD Gateway and major VPNs can integrate with Azure AD MFA or third-party providers. This is the single most effective step against credential theft.
  • Lock down source IPs. Even inside the enterprise, limit inbound RDP to known admin subnets or jump hosts via firewall scope.
  • Regularly audit the allowed users list. By default, local administrators can connect. But if you’ve added extra accounts via the “Select Users” dialog, review them quarterly.
  • Patch the RDP stack promptly. KB articles and Patch Tuesday updates frequently address RDP-related vulnerabilities. A delay of even a few days can expose you.
  • Turn on logging and alerting. Monitor Security event logs for repeated Event ID 4625 (failed logon). Forward them to a SIEM and trigger alerts for spikes.

Windows Report’s original piece includes a mention of third-party alternatives like Mikogo, AnyDesk, and TeamViewer. Those tools can be useful for ad-hoc support, but they shift your trust to an external vendor. For production servers, Microsoft’s own managed solutions — RD Gateway, Azure Virtual Desktop, or Windows 365 — are the safer bet because they maintain the same security boundary you already manage.

Common Pitfalls That Lead to Lockouts

Even experienced admins fall into these traps. Here’s what to watch for:

  • Changing the listening port but forgetting to update firewall rules. The registry key PortNumber under HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp controls the port, but you must manually adjust inbound firewall rules to match. Always keep a local console session alive while testing a port change.
  • Relying on port obfuscation for security. Automated scanners sweep all 65,535 ports in minutes. Obscurity is not a control; proper authentication and network segmentation are.
  • Forgetting that Group Policy overrides local settings. If your domain enforces a GPO that sets “Deny remote desktop connections,” your local registry change will be stomped on during the next policy refresh. Run gpresult /h gpresult.html to review which policies apply.
  • Using the same admin account for everything. If that account gets compromised, the attacker isn’t just in — they’re everywhere. Use separate, named privileged accounts and implement Just-in-Time (JIT) access where feasible.

The Bigger Picture: Why This Still Matters in 2025

Remote Desktop isn’t going away. Even as organizations adopt cloud-hosted desktops and serverless architectures, the need to poke a head into an on-premises Windows Server to restart a service or check a log file persists. RDP remains the most direct way to do that, which is why it remains the most attacked.

Microsoft’s 2024 Digital Defense Report noted a 178% year-over-year increase in ransomware-as-a-service incidents, many of which started with exposed RDP. That’s why the community refreshes guides like the one Windows Report published — not because something is new, but because the consequences of doing half the job haven’t changed.

Looking ahead, expect further tightening of default RDP settings in Windows Server 2025 and future releases. Microsoft may eventually push towards deprecating the standalone RDP listener in favor of HTTPS-tunneled connections through RD Gateway or Azure Arc-based remote management. Until then, the steps above remain the gold standard for safe remote administration.

What to Do Right Now

  1. Audit every server in your environment. For each one, answer: Is RDP enabled? Is fDenyTSConnections 0? Is NLA enforced? Is port 3389 reachable from the internet?
  2. Close what you don’t need. If a server doesn’t require remote desktop access, disable it.
  3. For servers that need it, apply the full hardening checklist above today — not after the next risk assessment.
  4. Bookmark the verification script from this guide and make it part of your server build documentation.
  5. Subscribe to Microsoft’s security update RSS feed and watch for RDP-related CVEs. Patch within 24 hours of release for critical vulnerabilities.