Restarting a computer remotely without losing access to it
Rebooting a machine you cannot physically reach is the moment remote access either proves itself or strands you for a week. The outcome is decided by four settings, all of which you can verify beforehand.
What a restart actually breaks
The session ends — expected, and not the problem. The problem is everything that has to happen unattended before the machine is reachable again:
- The machine has to complete boot without stopping at a prompt.
- The remote host software has to start without anyone logging in.
- The network has to come up and the host has to register itself.
- You have to know how to address it — the code or identifier may have changed.
Any one of those failing produces the same outcome, which is a machine that is on and unreachable.
Boot-time versus login-time — the crucial distinction
A remote tool installed as a normal user application starts when someone logs in. After an unattended restart, nobody logs in, so the tool never starts, and the machine sits at the login screen indefinitely.
A tool installed as a service starts at boot, before and independently of any login. This is the single most important property for unattended access, and it is also what lets a tool show the login screen at all.
Test it properly rather than reading the documentation: restart the machine, do not log in, walk away for five minutes, and try to connect. That one test is worth more than every setting page.
The four blockers
| Blocker | What you see | Fix |
|---|---|---|
| Disk encryption PIN | Machine never reaches the login screen | Use TPM-only unlock, or accept that it needs hands |
| Host app starts at login | Machine is up, nothing answers | Install as a service, or enable auto-login (with the trade-off below) |
| Pending update installs on boot | Unreachable for 10–40 minutes | Wait it out; schedule updates deliberately |
| BIOS stops on an error | Machine on, no network, indefinitely | Usually a "halt on error" setting — check before you travel |
The disk encryption row is the one that catches people. If BitLocker or an equivalent is set to require a PIN or a USB key at boot, an unattended restart cannot complete — by design. That is exactly the protection you asked for. If a machine must reboot unattended, it has to be configured for TPM-only unlock, and that is a real security trade-off to make consciously rather than discover.
Before you press restart
- Save and close things on the host. Your local machine will not warn you about unsaved work on the remote one.
- Check for pending updates. A restart with 40 minutes of updates queued is a very different outage from a 90-second one, and you cannot tell from the outside which you are in.
- Note the reconnect details somewhere else. If the code is shown on the host screen, you cannot read it after the restart. Have the identifier written down somewhere you control.
- Make sure someone can reach the machine physically if it is important, or accept the risk explicitly. "There is nobody there until Monday" is a decision, not a detail.
- Prefer a restart to a shutdown. A shut-down machine needs a power button, and Wake-on-LAN over the internet mostly does not work — see can you turn on a computer that is off.
After the restart
Give it longer than feels reasonable. Boot, network, host registration and any update work stack up, and two minutes of nothing is normal. If it is still silent after ten, the questions are in order: is it on the network at all, did the host service start, did it stop for a prompt.
One detail worth building in as a habit: after any remote restart, verify that you can connect from the login screen before you log in. If you log in first and only then test, you have verified the easy case and learned nothing about the one that will strand you.
More guides
Never put RDP straight on the internet — and what to do instead
Port 3389 is scanned continuously, credential stuffing against it is automated, and it is the most common entry point for ransomware. Four safer ways to reach the same machine.
Why a remote connection will not establish, and how to tell which layer failed
NAT, CGNAT, symmetric NAT and corporate firewalls each break the connection in a different place. A diagnosis order that identifies the layer in a few minutes.
Why the remote cursor lags, and which of the six causes is yours
Network round-trip, upstream bandwidth, encoder delay, frame rate, resolution and relay hops each add lag in a different way. How to tell them apart and what actually helps.
Try RemoteFrames
Install the host on the computer you want to reach, then enter its 6-digit code in any browser. No account — two free 10-minute sessions a day.
Try RemoteFrames