How-to guides · 6 min read

How to reboot a computer remotely and reconnect automatically

Written for: Anyone applying updates, clearing faults or finishing installations on a machine they cannot physically touch.

In short

A remote reboot restarts the machine you are connected to and, if the tooling is set up correctly, re-establishes the session automatically once it is back. The restart itself is trivial. What matters is knowing, before you press it, that the device will return: the agent must start with the operating system, the machine must reach the network without a human, and any disk encryption must not stop at a password prompt.

Key takeaways

  • Automatic reconnect depends on the agent starting as a service with the operating system, not after a user logs in.
  • Full-disk encryption with a pre-boot password will strand a remote machine unless network unlock is configured.
  • Warn the user first. An unannounced restart destroys unsaved work and trust in equal measure.
  • Know how long the device normally takes to return, so you can tell a slow boot from a real failure.
  • Always have a fallback for a machine that does not come back, before you need one.

What has to be true for the machine to come back

Three conditions decide whether a remote reboot is safe. The remote access agent must run as a system service that starts at boot rather than at login. The machine must obtain network access without human intervention, which rules out anything that depends on a user signing into a captive portal or a per-user VPN. And the boot sequence must complete without stopping at a prompt.

If any of those is uncertain on a given device, treat the reboot as a site visit waiting to happen and check first. The cost of verifying is a minute. The cost of being wrong is a journey.

  • Agent installed as a system service, set to start automatically
  • Wired or automatically-joining network connection, with machine-level rather than user-level authentication
  • No pre-boot password prompt, or network unlock configured for encrypted volumes
  • No pending prompt from a previous update waiting to block the boot

The disk encryption trap

This is the single most common way to strand a machine. Full-disk encryption that requires a password before the operating system loads will hold the device at that prompt indefinitely, and no remote tool can reach it, because nothing is running yet. The device is not broken, but it is now a physical job.

Where encryption is in place, either configure network-based unlock so trusted machines release the key automatically on a known network, or accept that remote reboots on those devices require somebody on site.

Restarting into safe mode

Some tools can trigger a restart into safe mode with networking, which is genuinely useful for driver problems and malware cleanup. Confirm the networking variant, because plain safe mode disables the network stack and takes the machine offline until someone restarts it locally.

Treat safe mode reboots as a higher-risk action generally. Do them on machines you can reach physically if it goes wrong, or during hours when someone is on site.

Telling a slow boot from a dead machine

The uncomfortable few minutes after a remote restart are much easier when you know the baseline. A machine with pending cumulative updates can take considerably longer than usual, and interrupting an update that is mid-install creates a far worse problem than waiting.

Establish a normal return time for each device class and write it in the runbook. Then set a threshold beyond which you stop waiting and escalate to someone on site, rather than refreshing hopefully for half an hour.

Rebooting a remote machine safely

  1. 1. Check the agent runs as a system service

    Confirm it starts at boot rather than at user login. This is what makes the difference between reconnecting automatically and not reconnecting at all.

  2. 2. Check for pre-boot encryption prompts

    If the device asks for a password before the operating system loads, and network unlock is not configured, do not reboot it remotely.

  3. 3. Warn the user and save their work

    If anyone is using the machine, tell them, give them time to save, and confirm before you proceed.

  4. 4. Note the time and the expected return

    Record when you triggered the restart and what a normal return time looks like for that device class.

  5. 5. Trigger the restart from the session

    Use the tool's reboot-and-reconnect action rather than typing a shutdown command, so the session is queued to re-establish automatically.

  6. 6. Wait out the threshold before escalating

    Give updates time to finish. Interrupting an in-progress update is how a restart becomes a rebuild.

  7. 7. Verify the state after reconnecting

    Confirm services started, the original fault is resolved, and nothing new is failing before you close the ticket.

Common mistakes

  • Rebooting a machine with pre-boot disk encryption and no network unlock, which strands it at the password prompt.
  • Assuming safe mode includes networking when it does not.
  • Restarting a machine mid-update because it seemed to be taking too long.
  • Rebooting a device that authenticates to Wi-Fi with user credentials, so it never rejoins the network without a login.
  • No agreed escalation threshold, so nobody knows when to send someone on site.

Frequently asked questions

Will I lose my remote connection if I reboot the computer?
The session drops during the restart, but tools with a reboot-and-reconnect function re-establish it automatically once the agent comes back online. That requires the agent to run as a system service that starts at boot.
How do I reboot a remote computer into safe mode?
Many remote support tools offer a restart into safe mode with networking. Make sure it is the networking variant, otherwise the machine comes up with no network and becomes unreachable until someone restarts it locally.
How long should I wait after a remote reboot?
Base it on that device class rather than a general rule. A machine installing cumulative updates can legitimately take far longer than a normal restart, and interrupting it makes things worse.
What if the machine does not come back?
Check whether it responds to a ping or appears in your management console at all, which distinguishes a network problem from a boot failure. Beyond that it usually needs physical access, which is why the pre-reboot checks matter.

How this works in 247connect

247connect includes reboot with automatic reconnect on managed devices, so the session re-establishes itself once the machine is back rather than leaving you to keep retrying.

More how-to guides