Enable Remote Desktop PowerShell: Setting Firewall Rules Too

Enabling Remote Desktop and Opening the Firewall Port with PowerShell

Turning on Remote Desktop from the GUI is fine for a one-off machine, but if you’re setting up a server (especially Server Core, where there’s no GUI to click through) doing it via PowerShell is quicker and scriptable across multiple machines. First, enable Remote Desktop itself by flipping the fDenyTSConnections registry value:

Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -Name "fDenyTSConnections" -Value 0

Then make sure the Windows Firewall rule group for Remote Desktop is enabled so the traffic is actually allowed through:

Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

Run both from an elevated PowerShell session. Once complete, you should be able to connect over RDP immediately — no reboot required for either change. If you also want to require Network Level Authentication (recommended for anything internet-facing), that’s a separate property:

Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name "UserAuthentication" -Value 1

Doing This Remotely Across Multiple Machines

All three commands above work equally well wrapped in Invoke-Command against a remote machine (or a list of machines) rather than run locally on each one — useful if you’re bringing up several Server Core instances at once and don’t want to RDP into each individually just to enable RDP itself, which is obviously not possible for the very first connection:

Invoke-Command -ComputerName Server01 -ScriptBlock {
    Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -Name "fDenyTSConnections" -Value 0
    Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
}

This obviously requires PowerShell Remoting (WinRM) to already be enabled and reachable on the target — which it typically is by default on Windows Server, but worth confirming with a quick Test-WSMan against the target first if this doesn’t connect straight away. If you’re managing RDP-enabled servers at any real scale, it’s also worth considering whether direct internet-facing RDP is the right approach at all today — an RD Gateway, a VPN, or Windows Admin Center’s browser-based remote management are all commonly used to avoid exposing port 3389 directly, since it remains one of the most consistently targeted ports for brute-force and credential-stuffing attacks against Windows servers.

Resources

• Server Core