How-to guides · 7 min read
How to set up unattended remote access to a computer
Written for: IT staff setting up always-on access to servers, office desktops, kiosks or remote-site machines.
In short
Unattended remote access lets an authorised operator connect to a computer when nobody is sitting at it. You install a small agent on the target machine, register it against your account, and connect on demand. The work that matters is not the install: it is deciding which machines qualify, tying every connection to a named person, and confirming the device reconnects on its own after a reboot.
Key takeaways
- Unattended access needs an agent installed once on the target machine; after that the device is reachable without anyone present.
- Decide the scope before you deploy. A device list you cannot justify becomes a device list nobody reviews.
- Every operator should connect from a named account with multi-factor authentication, never a shared login.
- Test the reboot path deliberately. An agent that does not restart with the machine is worse than no remote access, because you will assume the device is reachable.
- Record sessions from day one. Retrofitting an audit trail after an incident is not possible.
What unattended access actually gives you
In an attended session, someone at the far end accepts the connection. That is right for helping a colleague, but useless for a server at 2am or a signage PC in an empty building. Unattended access removes the human from the far end: the machine advertises itself as available, and an authorised operator connects whenever the work needs doing.
The practical effect is that maintenance stops being scheduled around people. Patching, restarts, log collection and configuration fixes move into the quiet hours, and a device in a locked room stops being a site visit.
- Servers and virtual machines that nobody logs into locally
- Office desktops that staff need to reach from home
- Kiosks, signage, EPOS terminals and lab machines
- Devices at branch sites with no on-site IT presence
Deciding which machines qualify
This is the step most teams skip, and the one that causes trouble later. An unattended device is permanently reachable by anyone who holds operator credentials, so the list should be defensible. Write down the categories that qualify and the categories that do not, and get that agreed before you push an agent anywhere.
A useful rule of thumb: unattended access suits machines the organisation owns and controls. Personally-owned devices, and machines where a user would reasonably expect privacy at the keyboard, belong in the attended category where consent is explicit and visible.
Deployment methods
For a handful of machines, running the installer manually is fine. Beyond about twenty, do it centrally: push the agent through group policy, an MDM profile, or your existing software deployment tool, using a deployment key so devices register against the right account automatically.
Silent installation matters here. If the agent prompts during install, an unattended rollout stalls halfway and you end up walking the estate anyway. Check the vendor's silent-install switches before you build the package.
- Group Policy software installation or a startup script for domain-joined Windows estates
- Intune, Jamf or another MDM for mobile and modern-managed devices
- An existing RMM or deployment tool if you already run one
- A deployment key so each device lands in the right group without manual sorting
Proving it works before you depend on it
A machine you cannot reach at the moment you need it is the failure mode that hurts. Test the full cycle on a representative device: connect, reboot the machine, confirm the agent comes back on its own, connect again, and check the session appears in the audit log with the correct operator name against it.
Do this once per device type, not once overall. A server, a laptop that sleeps, and a kiosk behind a captive-portal network fail in different ways.
Setting up unattended access, step by step
1. Agree the device scope
List the categories of machine that may be reachable unattended and the categories that may not. Get sign-off from whoever owns the risk, and keep the list somewhere it will be reviewed.
2. Create named operator accounts
One account per person, with multi-factor authentication enforced. Shared logins make the audit trail worthless because you can never prove who was on the machine.
3. Package the agent for silent install
Build the installer with your deployment key and silent switches, so devices register into the correct group without a prompt at the far end.
4. Pilot on ten devices
Cover each device type you support. Confirm registration, connection, and behaviour after a restart before you go wider.
5. Deploy in waves
Roll out by site or department rather than all at once, so a packaging mistake affects ten machines rather than a thousand.
6. Verify the reboot and reconnect path
Restart a device from within a session and confirm it returns on its own. This is the single most common gap in an otherwise working deployment.
7. Turn on session logging and set a review date
Enable audit logging immediately, and diarise a quarterly review of both the device list and the operator list. Access that is never reviewed only ever grows.
Common mistakes
- Installing the agent under a personal account, so the estate becomes unreachable when that person leaves.
- Skipping multi-factor authentication on operator accounts because it slows down the first week.
- Assuming a laptop that sleeps behaves like a desktop that does not. Sleeping devices need wake-on-LAN or they simply will not answer.
- Deploying to personally-owned machines under the unattended policy, which is a governance problem rather than a technical one.
- No documented offboarding step, so a departed contractor keeps working credentials.
Frequently asked questions
- Do I need to install software on the remote computer for unattended access?
- Yes. Unattended access requires a small agent installed on the target machine, because something has to answer the connection when no person is present. Attended support is the alternative when you cannot or should not install anything.
- Is unattended remote access safe?
- It is safe when access is tied to named accounts with multi-factor authentication, sessions are encrypted, every connection is logged, and both the device list and operator list are reviewed regularly. It is unsafe when it is deployed broadly with shared credentials and never audited.
- Can I set up unattended access on a laptop?
- Yes, but sleep and network state matter. A laptop that is asleep, hibernating or off a trusted network will not answer. Wake-on-LAN helps on wired connections; otherwise plan around the device being reachable only when awake and online.
- How many devices can one operator manage?
- That depends on the tooling rather than any hard limit. The practical constraint is usually concurrent sessions per operator and how much routine work is automated rather than performed by hand.
How this works in 247connect
If you are choosing a tool for this, 247connect handles unattended machines as managed devices: the agent installs silently with a deployment key, devices reconnect automatically after a reboot, operators are unlimited and named, and every session is logged.
More how-to guides
Support a user with no install
How on-demand, attended remote support works when you cannot install anything permanently: one-time session applications, consent, what the user sees, and when this approach is the right choice.
Transfer files in a session
Moving files to and from a machine you are supporting: drag-and-drop transfer, when to use it instead of email or cloud storage, size and permission limits, and keeping a record of what moved.
Reboot and reconnect remotely
Restarting a machine from a remote session without losing access: safe mode considerations, what has to be true for the device to come back, and how to avoid stranding a computer you cannot reach.