I need help turning on Remote Desktop from another computer because I can’t access the PC in person right now. It was working fine before, but after a restart, remote access is no longer enabled and I need to connect urgently for work files. Looking for the safest and easiest way to remotely enable Remote Desktop on Windows.
I ran into this on a few office machines after a policy change shut off RDP. Annoying one, because the box is up, the network is fine, and you still get locked out of the easy path.
If you’re trying to turn Remote Desktop back on from another machine, I had the best results with PowerShell remoting, PsExec, or Group Policy. Which one works depends on what access is still alive on the target PC.
A decent write-up is here:
how to remotely enable remote desktop
My short version looked like this.
- Flip the RDP setting in the remote registry
reg add ‘\PCNAME\HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server’ /v fDenyTSConnections /t REG_DWORD /d 0 /f
- Turn on the firewall rule for Remote Desktop
Enable-NetFirewallRule -DisplayGroup ‘Remote Desktop’
- Check the services people usually miss
- Remote Registry
- Remote Desktop Services
- Windows Management Instrumentation, WMI
If WinRM was already on, I used PowerShell remoting first. It felt cleaner and gave me fewer weird edge-case errors. On older Windows setups, PsExec still got the job done when newer management stuff was half-broken or never set up right.
The part I saw people miss most often was the firewall. They enable RDP, try again, and still fail because inbound 3389 is blocked. So if your registry change worked but the connection still times out, look there first.
6 Likes
I’d check one thing first before doing what @mikeappsreviewer listed. A restart often flips the network profile to Public. When that happens, RDP looks dead even if the service is fine.
From another PC, if you still have admin access through Computer Management, WMI, or a domain tool, set the target network back to Private or Domain. Then verify these:
System PropertiesRemote.exe /s on the target. The Remote tab should show RDP enabled.
TermService startup type should be Automatic.
Local Group Policy, Computer Configuration, Administrative Templates, Windows Components, Remote Desktop Services, Remote Desktop Session Host, Connections, Allow users to connect remotely using Remote Desktop, set it to Enabled.
If it’s domain joined, I’d push it with GPO over doing one-off registry edits. Less messy. More reliable after the next reboot too.
Also check NLA. I disagree a bit with the “turn it on first, sort details later” approach. If NLA stayed enabled and your account lost rights after policy refresh, you’ll still get blocked. Make sure your user is still in Remote Desktop Users or local Administrators.
Fast test list:
ping target
Test-NetConnection target -Port 3389
sc \target query TermService
If 3389 is closed but host responds, it’s config. If host is missing from network, you’ve got a diff rent problem.
I’d actually start one layer lower than what @mikeappsreviewer and @byteguru suggested. Not because they’re wrong, just because after a reboot the problem is pretty often not “RDP got disabled”, it’s “the machine stopped accepting the kind of remote management you need.”
If you still have admin creds, try using MMC from another PC:
- Computer Management
- Action > Connect to another computer
- Check Services and Applications > Services
- Make sure:
- Remote Desktop Services is running
- Remote Procedure Call is running
- Windows Firewall is not doing something dumb
- Remote Registry is running only if you need it
Also open Event Viewer remotely if possible and look at:
- Windows Logs > System
- Applications and Services Logs > Microsoft > Windows > TerminalServices
That can tell you if TermService failed on startup, if policy killed it, or if the NIC/profile changed after boot. Saves time vs randomly flipping settings and hopng it works.
One thing I sorta disagree with is going straight to registry edits first. Yeah, they work, but if the box has a broken service dependency or policy refresh pending, you just end up enabling a setting that still won’t listen.
If the machine is domain-joined, I’d force a gpupdate remotely through your management tools or use RSOP to see what got applied after restart. If it’s not domain joined, remote Scheduled Tasks can be a lifesaver. Create a task on the target to run as SYSTEM with a one-time trigger and execute:
cmd /c netsh advfirewall firewall set rule group='remote desktop' new enable=Yes
and if needed:
cmd /c sc config TermService start= auto & sc start TermService
That route is ugly, but it works suprisingly often when PowerShell remoting is unavailable. If none of that connects, you may be dealing with a machine that came back on a different network, different profile, or with VPN not reconnected after reboot. That part gets missed a lot.
I’d add one angle the others only touched lightly: BIOS or sleep-state fallout after the reboot. If the box restarted into Modern Standby weirdness, hybrid shutdown, or NIC power saving, RDP can look “disabled” when the machine just is not reachable enough to finish the handshake.
What I’d check remotely, if you still have any admin path:
- Confirm it is not asleep:
powercfg /aand disable Fast Startup later - Verify the NIC did not lose its static IP or switch networks
- Check DNS actually resolves to the current address, not a stale record
- Query Event IDs around boot for network stack delays and TermService startup ordering
I slightly disagree with jumping straight into firewall and registry toggles first. @byteguru, @boswandelaar, and @mikeappsreviewer are all covering the common fixes, but if name resolution or the post-reboot network state is wrong, those changes won’t matter.
If you have remote CMD access, test by IP, not hostname. If IP works and name does not, fix DNS and you’re done.
Pros for ‘’: can centralize remote support workflow.
Cons for ‘’: no value if you currently have zero management path into the PC.