How-to guides · 6 min read
How to remotely support someone without installing software
Written for: Helpdesk staff, MSPs and anyone supporting external users, contractors, customers or personally-owned machines.
In short
When you need to help someone once, or the machine is not yours to change, you use an on-demand session instead of a permanent agent. The user runs a small one-time application, reads out a session code, and grants consent. You get control for the duration of the call, and nothing is left behind afterwards.
Key takeaways
- On-demand support suits one-off help, external users, and any device you do not own or manage.
- The user stays in control: they start the session, they can see it is active, and they can end it.
- Nothing persists after the session, which is what makes this approach acceptable on personal machines.
- Consent is the whole point. It is what separates support from surveillance in the eyes of the person you are helping.
- If you find yourself running on-demand sessions to the same machine every week, that machine should probably be a managed device instead.
How an on-demand session works
The pattern is consistent across tools. You generate a session, the user downloads and runs a small application, and a short code links the two of you together. The application asks the user to allow the connection, and only then does the screen appear on your side. When you close the session, the application stops and typically removes itself.
Because there is no permanent install, there is no fleet to manage, no agent to patch, and no lingering access. That is exactly the trade you are making: less convenience for you, far less standing exposure for them.
When to use it instead of unattended access
Use on-demand support when the relationship is temporary or the machine is not under your control. That covers customers, suppliers, contractors, home users, and staff on personally-owned devices. It also covers first contact with a new client before anything is deployed.
Use unattended access instead when you support the same machine repeatedly, when the work happens outside office hours, or when nobody will be present to accept the connection.
- One-off support calls to people outside your organisation
- Personally-owned laptops and home machines
- New customer onboarding before agents are deployed
- Any situation where a permanent agent would be disproportionate
Getting the user through it smoothly
Most failed support sessions fail at the download, not at the connection. The person you are helping is often stressed, unfamiliar with their own browser, and being talked through it over a phone line. Keep the instructions short, use the same wording every time, and know exactly what the download prompt looks like in the common browsers.
Prepare for the two predictable obstacles: a browser blocking the download, and a standard user account being unable to run it. Knowing your answer to both in advance turns a ten-minute struggle into a thirty-second step.
- Send the link by email or chat rather than dictating a URL over the phone
- Tell the user in advance that they will see a security prompt, so it does not alarm them
- Have a fallback for locked-down machines where downloads are blocked
- Confirm out loud when the session ends, so the user knows access has stopped
Consent, and why it is worth protecting
Visible consent is what makes remote support socially acceptable inside an organisation. The user should be able to see that a session is running and end it themselves at any point. Tools that can connect invisibly to a staffed machine create a trust problem that no policy document will fix.
This matters legally as well as culturally. Where remote support touches personal devices or personal data, being able to show that the user initiated and could terminate the session is a meaningful part of your position.
Running an on-demand support session
1. Confirm the user is at the machine
Attended support only works with someone present. If nobody is there, you need unattended access instead.
2. Send the session link
Email or message it rather than reading it aloud. Fewer typos, faster start, and you have a record of when you sent it.
3. Talk them through the download and run
Name the exact prompts they will see. Warn them about the security warning before it appears rather than after.
4. Take the session code
Have them read the code back to you, and confirm it matches before you connect. This also verifies you are joining the right machine.
5. Ask before you take control
Explain what you are about to do. Users tolerate a lot when they know what is happening and almost nothing when they do not.
6. Do the work, narrating as you go
Commentary while you work reduces anxiety and often teaches the user enough to avoid the next call.
7. End the session explicitly
Close it in front of them and confirm the application has gone. Leave the machine as you found it.
Common mistakes
- Assuming the user can install anything. On a locked-down corporate machine, they often cannot.
- Taking control without saying so first, which is the fastest way to lose a user's trust.
- Reading long URLs over the phone instead of sending them.
- Using on-demand sessions as a permanent arrangement for machines you support weekly, where a managed agent would be cheaper and faster.
- Failing to confirm the session has ended, leaving the user unsure whether you can still see their screen.
Frequently asked questions
- Can you remotely access a computer without installing anything at all?
- Not entirely. Something has to run on the remote machine to share the screen. On-demand tools get as close as practical by using a small one-time application that runs for the session and removes itself afterwards, rather than a permanent installed agent.
- Does the user have to accept the connection?
- In attended support, yes. The user starts the session and grants consent, and should be able to end it at any point. That visible consent is the defining characteristic of attended support.
- What happens when the session finishes?
- The one-time application stops running and typically removes itself, so no standing access remains. You cannot reconnect later without the user starting a new session.
- Is on-demand support secure enough for sensitive work?
- The session itself should be encrypted and logged like any other. The bigger control is that access is temporary and consented, which limits exposure compared with permanent access to the same machine.
How this works in 247connect
247connect calls these on-demand devices: the user runs a one-time application, no permanent agent is left behind, and the session is AES-256 encrypted and logged like any managed connection. The 14-day trial includes on-demand licences if you want to test the flow with a real user.
More how-to guides
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.
Support multi-monitor setups
Handling multi-monitor remote sessions without squinting: switching between displays, spanning versus single-screen view, scaling, and what to do when the remote layout does not match yours.