In this post I show you how you can enable Remote Desktop on Windows 10 via Group Policy, PowerShell, WMI, or psexec because even the geekiest CLI geek sometimes needs to RDP into a remote Windows machine.

You probably know you can enable Remote Desktop in the Windows 10 Control Panel's System app. That's quick to do if the computer is on your desk. However, if you want to access a remote machine and Remote Desktop is disabled for security reasons in your organization, you have to enable Remote Desktop access remotely.

Allow remote connections in the Windows 10 Control Panel

Allow remote connections in the Windows 10 Control Panel

Allow Remote Desktop via Group Policy ^

The easiest way certainly is to enable RDP access via Group Policy: Allow users to connect remotely using Remote Desktop Services

You can find the policy here:

Computer Configuration > Administrative Templates > Windows Components >Remote Desktop Services > Remote Desktop Session Host > Connections.

Allow users to connect remotely by using Remote Desktop Services

Allow users to connect remotely by using Remote Desktop Services

You will also have to allow RDP in the Windows Firewall on the remote Windows 10 computer:

Computer Configuration > Policies > Administrative Templates > Network > Network Connections > Windows Firewall > Domain Profile

Allow inbound Remote Desktop connections via Group Policy

Allow inbound Remote Desktop connections via Group Policy

The only problem is that Group Policy is sluggish, and if you want to log in quickly to a remote machine, it is often not an option. By contrast, on a PowerShell console, you can essentially get the job done with a single command.

Enable Remote Desktop via PowerShell ^

However, there is a catch—actually, two. Windows Firewall might get in your way, and if PowerShell remoting is not enabled on the machine, things can get a bit tricky. I know of two methods to enable Remote Desktop remotely via PowerShell. Which method you use mostly depends on your Windows Firewall configuration.

Let's assume first that PowerShell remoting is enabled on the remote machine. If so, you can simply enable Remote Desktop by modifying a registry key on the remote machine:

Invoke-Command -Computername <computer name> -ScriptBlock {Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server" -Name "fDenyTSConnections" –Value 0 }

We are using Invoke-Command to execute the Set-ItemProperty remotely, which changes the value fDenyTSConnections to 0.

Most likely, Windows Firewall blocks RDP on the remote machine. To open the Remote Desktop port, you can use this PowerShell command:

Invoke-Command -Computername <computer name> -ScriptBlock {Enable-NetFirewallRule -DisplayGroup "Remote Desktop"}

We are using PowerShell remoting again to execute Enable-NetFirewallRule remotely.

Enable Remote Desktop via WMI ^

If PowerShell remoting is not enabled on the remote machine, you can still use PowerShell via WMI for the task. This can be useful if you need to enable RDP on multiple machines or if this task is part of a larger automation problem and your organization's security guidelines don't allow PowerShell remoting. Sitaram wrote a PowerShell script that uses the Get-WmiObject cmdlet. This allows you to manage computers remotely without PowerShell remoting.

I removed the part of the script that first checks via Test-Connection if the computer is online because this would require an additional firewall setting to make the script work.

[cmdletbinding()]
param(
	[parameter(ValueFromPipeline=$true,ValueFromPipelineByPropertyName=$true)]
	[string[]]$ComputerName = $env:computername,
	[ValidateScript({Test-Path $_})]
	[string]$OutFolder = "c:\"
)

begin {
$SuccessComps = Join-Path $OutFolder "Successcomps.txt"
$FailedComps = Join-Path $OutFolder "FailedComps.txt"
}

process {
	foreach($Computer in $ComputerName) {

		try {
			$RDP = Get-WmiObject -Class Win32_TerminalServiceSetting `
								-Namespace root\CIMV2\TerminalServices `
								-Computer $Computer `
								-Authentication 6 `
								-ErrorAction Stop
								
		} catch {
			Write-Host "$Computer : WMIQueryFailed"
			"$Computer : WMIQueryFailed" | Out-File -FilePath $FailedComps -Append
			continue
		}
		
		if($RDP.AllowTSConnections -eq 1) {
			Write-Host "$Computer : RDP Already Enabled"
			"$Computer : RDP Already Enabled" | Out-File -FilePath $SuccessComps -Append
			continue
		} else {
			try {
				$result = $RDP.SetAllowTsConnections(1,1)
				if($result.ReturnValue -eq 0) {
					Write-Host "$Computer : Enabled RDP Successfully"
					"$Computer : RDP Enabled Successfully" | Out-File -FilePath $SuccessComps -Append
				} else {
					Write-Host "$Computer : Failed to enabled RDP"
					"$Computer : Failed to enable RDP" | Out-File -FilePath $FailedComps -Append

				}
			
			} catch {
				Write-Host "$computer : Failed to enabled RDP"
				"$Computer : Failed to enable RDP" | Out-File -FilePath $FailedComps -Append
			}
		}
	}

}

end {}

To understand how the script works, please read Sitaram's article. To use the script, you just have to save it to a file (Enable-RDPAccess.ps1) and then run this command:

.\Enable-RDPAccess.ps1 -ComputerName <computer name>
Enable RDP via WMI

Enable RDP via WMI

If you want to enable RDP on multiple Windows 10 computers, you can save the computer names in a text file and then use Get-Content to pipe the computer names to Enable-RDPAccess.ps1:

Get-Content <path to text file> | Enable-RDPAccess.ps1

Theoretically, you probably can also configure the Windows Firewall to allow the RDP connection with Get-WmiObject. However, I couldn't find the corresponding class. If you know more, please post a comment below.

Nevertheless, I know another way to configure the firewall via WMI, and that is with the wmic command:

wmic /node:<computer name> process call create "cmd.exe /c netsh firewall set service RemoteDesktop enable"

Of course, you can also enable Remote Desktop with wmic:

wmic /node:<computer name> process call create 'cmd.exe /c reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f'
Remotely enable RDP on Windows 10 with wmic

Remotely enable RDP on Windows 10 with wmic

Note that you have to configure the Windows Firewall of the remote machine to allow WMI access for the PowerShell script and for wmic to work. You could do this via Group Policy:

Computer Configuration > Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security.

Right-click Inbound Rules and then add the predefined rule Windows Management Instrumentation (WMI).

Enable WMI in Windows Firewall via Group Policy

Enable WMI in Windows Firewall via Group Policy

But now we are where we were in the beginning. We could then just use Group Policy to enable RDP right away. However, if WMI is already enabled in your firewall for other reasons, using Get-WmiObject is an option.

Also, if you often have to enable RDP remotely on Windows 10 machines, but your company policy doesn't allow you to work with PowerShell remoting, you could also consider opening WMI in your firewall permanently. I suppose it is less risky simply because WMI is more difficult to use than PowerShell remoting, and all the script kiddies who downloaded PowerShell scripts to hack into your systems will be in trouble.

Enable RDP via psexec ^

Yet another option is Microsoft's free tool psexec. It also doesn't require PowerShell remoting to be enabled. The only downside is that it is not as straightforward to use as Invoke-Command in PowerShell scripts. Psexec requires that Windows Firewall is open for File and Printer sharing, which is probably more common than open WMI ports or enabled PowerShell remoting:

Computer Configuration > Policies > Administrative Templates > Network > Network Connections > Windows Firewall > Domain Profile > Windows Firewall: Allow inbound file and printer sharing exception

Allow file and printer sharing in the Windows Firewall

Allow file and printer sharing in the Windows Firewall

To modify the registry to enable RDP with psexec, you have to run this command:

psexec.exe \\<computer name> reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f

This command also just sets the registry key that disables Terminal Server access to 0.

To allow RDP connections in the Windows Firewall, you can also use psexec:

Subscribe to 4sysops newsletter!

psexec.exe \\<computer name> netsh firewall set service RemoteDesktop enable
Enable Remote Desktop with psexec

Enable Remote Desktop with psexec

Conclusion ^

If you have to enable Remote Desktop remotely, you have a variety of options. Which one you use depends on how quickly you need access and the Windows Firewall configuration on the remote machine. If all the firewall ports discussed in this post are closed, Group Policy is your only option. If someone is close to the computer, the person can reboot the machine to apply the GPO. Yes, you can also remotely reboot the machine. But if you don't have a system management tool with this feature, you also have to open a couple of firewall ports for a remote reboot.

avataravatar
18 Comments
  1. RDPuser 5 years ago

    stupid update removed my open RDP port from the firewall settings

    now cannot access my machine

    • Author
      Michael Pietroforte 5 years ago

      Never heard that an update modified firewall settings. Are you sure that the update made the changes?

  2. Paolo Maffezzoli 5 years ago

    No issues or firewall changes found with latest Windows updates. RDP is still working as usual.

    avatar
  3. C P Champion 4 years ago

    FANTASTIC ARTICLE!!!!!

    I had lost remote connection, TeamViewer died and would not re-connect. I am domain admin on the network and thanks to your article I am now back on machine.

    Time to remove TV I think…

    Thank you so much 🙂

  4. Damon Dawson 4 years ago

    Great article. This one is going into my OneNote binder under “All Things Awesome”  Thanks so much for taking the time to write this up.  VERY VERY well done!

    avatar
    • Author
      Michael Pietroforte 4 years ago

      Damon, thanks! I think I will put your reply in my Notes for Mac folder “Awesome comments.” 😉

  5. DC 4 years ago

    Helped me fix a bunch of desktops.   Thanks for explaining all the options available.

    avatar
  6. Brandon 4 years ago

    PSEXEC saved me just when I thought all hope was lost.

    Thank you, thank you, THANK YOU for this post.

  7. Kozo 3 years ago

    THANK YOU! PSEXEC did it!!!! LOVE LOVE LOVE

  8. Ken 3 years ago

    Thank you very much, this was a great article.  Ken

  9. Tim 3 years ago

    Thanks for the great article.  It led me to use Services.msc on the DC to connect to the lost machine to enable Remote Registry as well as Remote Desktop Services.  Then I was able to use RegEdit to load that system's registry and set the fDenyTSConnections flag, and I'm in!

  10. Andrew 5 months ago

    1. Note, if your organisation has disabled RDP for security reasons, **do not** go about with processes like this to enable it, unless you have the specific blessing of that team.
    2. PsExec is a very handy tool, to be sure. But it is a huge security risk and will be flagged as a malicious executable by many AV systems. This is because it is literally just too powerful 🙂 So don’t run this on any corporate network without first talking to your security team.
    Group Policy should always be the preferred course of action which negates the need for any of these actions in the first place.
    But for home users, the write-up is ideal. :thumbsup:

    • Paolo Maffezzoli 4 months ago

      Agree on powerful features and related security concerns, however Psexec is included as a suggested tool in many Microsoft documents and in HowTo info configurations. Many AVs detect it but this tool is included as allowed.

      • Andrew 4 months ago

        Allowed by whom? Microsoft does not decide corporate security, which is just as well obviously. Like I said, is a great tool, but too powerful, and it is utterly irresponsible to advise users about this tool unless you also make clear that users in corporate settings must not operate such tools without the strict blessing of their IT/security teams.
        That goes for any “fix” or action really. You actually need to be putting at the beginning of any article, “don’t do this on your business device unless you have the blessing of the relevant IT body” etc. Because it’s tools like this and other things that people download after reading about it on a helpful website that allow hackers to run amok once they can acquire entry via a compromised device.

        Do not download any tool, Microsoft or otherwise, to your corporate device and attempt to “fix” things on your or other computers without the explicit approval of your IT team. Astounding that this even needs to be said.

        avatar
        • Paolo Maffezzoli 4 months ago

          Of course Microsoft does not decide corporate security, remote control in a corporate network is always performed by IT staff and follows the standards defined in business processes.

        • Paolo Maffezzoli 4 months ago

          Correct, this is the scope of this article.

          • Author
            Michael Pietroforte 4 months ago

            No need to become impolite! I’d say if your end users have admin rights in your organization, you have a much bigger problem than PsExec. Besides, PsExec is Microsoft tool that is used by countless admins around the globe for decades.

            avataravatar
            • Andrew 4 months ago

              Yes, and those corporations are playing with fire, but that doesn’t mean we shouldn’t take caution in advising potential actions. Obviously, no sysadmin should take any action unless it’s cleared with the security team – and if RDP is disabled for security reasons then they shouldn’t be using *any* of the processes listed here to seek to enable it unless they have the blessing of said Security team (*not* just sysadmin role benefits). I’m not objecting to the content of the article technically – it’s perfectly sound, and contains good (and reasonably thorough) information. I guess the core point is that I would expect to see a disclaimer along the lines of, ‘obviously work within the security boundaries of your corporate environment, and don’t action any of these activities unless you have explicit sanctioning to do so.’
              Just as many organisations are probably running laxer-than-suitable desktop security, probably many are also running with junior admins with domain-wide privileges and part of their education (since it’s presumably towards those admins that the piece is targeted) is precisely to appreciate the security context of an organisation and not *just* the technical capabilities.
              Anyway to your basic justification, if [said sysadmin] doesn’t have time to deploy a GPO but they have time to pull up an independent internet article to reference [with untrusted/unknown scripts!] the under-the-table actions then their priorities as an admin are already in the drink.
              And note as I mentioned earlier the issue with PSexec is not its direct usage, per se [although my earlier point about approval & process in that regard still stands] but mostly to do with the availability of the tool on a host for hackers to benefit from. The tool should always come with an explicit warning such as:
              “**Only** use this tool with explicit approval from your organisation’s security team *and* ensure it is removed from every machine after the operation is completed.”

Leave a reply

Your email address will not be published.

*

© 4sysops 2006 - 2022

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account