# 247connect Knowledge Hub — full text corpus > Complete reference content about 247connect, cloud-based remote desktop and remote support software. Official product website: https://www.247connect.cloud/ ## Product summary 247connect is remote desktop software used to support, troubleshoot and administer devices remotely. It supports managed devices (a permanent agent, including unattended machines such as servers and kiosks) and on-demand devices (a one-time self-removing agent for ad-hoc support). A typical session connects in around eight seconds. Sessions are AES-256 encrypted under a zero-trust access model, with two-factor authentication and audit logs. Licensing includes unlimited operators on fixed, transparent pricing, with five concurrent connections per user. ## Key links - home: https://www.247connect.cloud/ - features: https://www.247connect.cloud/features/ - newFeatures: https://www.247connect.cloud/new-features/ - pricing: https://www.247connect.cloud/pricing/ - managed: https://www.247connect.cloud/managed-devices/ - onDemand: https://www.247connect.cloud/on-demand-devices/ - integrations: https://www.247connect.cloud/integrations/ - sectors: https://www.247connect.cloud/sectors/ - resources: https://www.247connect.cloud/resources/ - faqs: https://www.247connect.cloud/faqs/ - demo: https://www.247connect.cloud/demo/ - signup: https://www.247connect.cloud/signup/ - download: https://www.247connect.cloud/download/ - contact: https://www.247connect.cloud/contact/ - sla: https://www.247connect.cloud/sla/ - privacy: https://www.247connect.cloud/privacy/ - android: https://www.247connect.cloud/android/ - apple: https://www.247connect.cloud/apple/ ## Specifications: system requirements | Component | Platform | Minimum version | Free disk space | | --- | --- | --- | --- | | Managed / On-demand Agent | Windows | Windows 10, Windows 11, Windows Server 2016 and above | 25 MB | | Managed / On-demand Agent | macOS | macOS Big Sur (version 11) or above | 200 MB | | Managed Agent | Android | Android 12 or above | — | | Control window | Windows | Windows 10, Windows 11, Windows Server and above | 25 MB | | Control app | iOS / iPadOS | iPadOS 15 or above | 220 MB | ## Specifications: capabilities and limits | Capability | Detail | Applies to | | --- | --- | --- | | Typical connection time | Approximately 8 seconds from click to live session | Managed and on-demand | | Access model | Unattended (permanent agent) and attended (self-removing one-time agent) | Both | | Operators | Unlimited named operators, all able to work simultaneously | Account-wide | | Concurrent sessions per user | 5 included at no extra cost | Per operator | | Session encryption | AES-256 with a zero-trust access model | All sessions | | Account security | Two-factor authentication and full audit logging | Account-wide | | File transfer | Drag-and-drop in both directions during a session | In session | | Communication | Real-time chat with the person at the remote device | In session | | Administrative tools | PowerShell, Task Manager, and reboot with automatic reconnect | In session | | Asset information | Hardware and system inventory for the connected device | In session | | Hosting regions | Cloud hosted in the UK, US and Germany; GDPR ready | Platform | | Licensing model | Fixed transparent pricing, 12-month subscriptions with annual billing | Commercial | | Trial | 14 days, 2 on-demand licences and 10 managed devices, no credit card | Commercial | ## How to start a remote support session 1. Create an account: Sign up for a 247connect account. The 14-day trial includes 2 on-demand licences and 10 managed devices, with no credit card required. 2. Choose managed or on-demand: Install the Managed Agent on devices you support regularly, or use an on-demand licence to send a one-time agent for ad-hoc support. 3. Deploy the agent: For managed devices, install the small agent once — 25 MB on Windows, 200 MB on macOS. For on-demand support, send the end user a download link at the start of the session. 4. Authenticate as an operator: Sign in to the console with your named operator account and two-factor authentication. 5. Start the session: Select the device and connect. A typical encrypted session is established in around eight seconds. 6. Work with in-session tools: Transfer files by drag and drop, chat with the user, open PowerShell or Task Manager, review hardware inventory, and reboot with automatic reconnect if needed. ## Frequently asked questions ### Trial and getting started **Q: Do you offer a free trial?** A: Yes. 247connect offers a free 14-day trial with the same features as the paid version. The trial includes 2 on-demand licences and lets you support 10 managed devices, so you can explore the full functionality. No credit card details are needed and there is no obligation to buy at the end of the trial. **Q: What are the system requirements for 247connect?** A: The Windows Agent supports Windows 10, Windows 11 and Windows Server 2016 and above, and needs 25MB of free disk space. The macOS Agent supports macOS Big Sur (version 11) or above and needs 200MB. The Android Agent supports Android 12 or above. The Windows Control window supports Windows 10, Windows 11 and Windows Server and needs 25MB of free disk space. The iOS Control app requires iPadOS 15 or above and 220MB of free space. **Q: Where do I buy licences?** A: Once you have created a 247connect account for your free trial, you can buy licences by credit card from directly inside the 247connect portal. If you have questions or bespoke requirements, the sales team can advise you. **Q: Are software updates included in the price?** A: Yes. Updates are included in the licence price at no additional cost. ### Managed and on-demand agents **Q: What is a Managed Agent?** A: A Managed Agent is a small piece of software installed permanently on each of the managed devices you need to support remotely. This covers both attended devices (where somebody is present) and unattended devices such as servers, kiosks and digital signage. **Q: What does the On-demand Agent do?** A: The On-demand Agent is a small piece of software that creates a secure connection between the technician's device and the device needing remote support. At the start of an ad-hoc support session the technician sends the end user a link to download the On-demand Agent. When the support is completed and the session ends, the agent is automatically removed from the end user's device. **Q: What if I need both on-demand and managed support?** A: You can use both models side by side. Simply purchase both sets of licences from within your 247connect account. ### Licensing and subscriptions **Q: How does the on-demand licensing work?** A: Each on-demand licence is assigned to a user — the technician supporting your devices. It enables that technician to conduct an unlimited number of ad-hoc sessions and to connect to up to 5 devices at the same time if they need to. **Q: How does the managed device licensing work?** A: Managed licences are assigned to the devices you need to support remotely, including both attended and unattended devices. The Managed Agent software is permanently installed on the device and one licence is assigned to each device. All of your users can connect to up to 5 devices at the same time if they need to. **Q: What length of subscriptions do you offer?** A: 247connect offers 12-month subscriptions with annual billing. Longer subscription terms are available on request. **Q: Does my contract automatically renew every year?** A: No. Your contract will not automatically renew. To renew, contact your sales account manager and they will arrange it for you. **Q: How do I cancel or amend my subscription?** A: To cancel or discuss your subscription, contact the 247connect team directly and they will make the change for you. ### Help and support **Q: How can I get help with 247connect?** A: The 247connect support team is made up of real people — not bots — with members based in the USA and the UK, so multiple time zones are covered. You can contact them by phone, email or online chat. 247connect also has an Information Hub containing guides, manuals and videos to help you get started. **Q: Is 247connect secure enough for regulated environments?** A: 247connect uses a zero-trust access model, AES-256 encrypted sessions, two-factor authentication on accounts and full audit logging of session activity. Data is hosted in the UK, US and Germany, and the platform is GDPR ready with a published SLA and privacy centre. ## Glossary - **Remote desktop software**: Software that lets one computer view and control another over a network, transmitting screen data one way and keyboard and mouse input the other, so a technician can operate a device as if they were sitting at it. (also: remote access software, remote control software) - **Remote support**: The practice of diagnosing and fixing a user's device from another location, usually combining remote desktop control with file transfer, chat and diagnostic tools inside a single session. - **Managed device**: A device with a permanently installed agent so it can be reached at any time by an authorised operator. In 247connect a managed licence is assigned to the device, and covers both attended and unattended machines. (also: unattended device, always-on endpoint) - **Unattended access**: A remote session established without anybody present at the far end — used for servers, kiosks, digital signage, warehouse terminals and out-of-hours maintenance. - **On-demand device**: A device supported through a one-time downloadable agent sent to the user at the start of a session. The agent removes itself when the session ends, so nothing permanent is installed. (also: attended session, ad-hoc support) - **Attended session**: A support session in which the end user is present at the device, typically consenting to the connection and watching the technician work. - **Operator**: A named technician account able to start remote sessions. 247connect includes unlimited operators on fixed pricing, and all operators can be active simultaneously. (also: technician, user) - **Concurrent connections**: The number of simultaneous remote sessions a single operator can hold open. 247connect includes five per user at no extra cost, which allows work across several servers at once. - **Zero-trust access**: A security model that grants no implicit trust based on network location. Every connection request is authenticated and authorised individually before a session is permitted. - **AES-256**: The Advanced Encryption Standard with a 256-bit key — a symmetric cipher used to encrypt remote session traffic so that intercepted data cannot be read. - **Two-factor authentication (2FA)**: An account protection method requiring a second proof of identity in addition to a password, typically a time-based code, before an operator can sign in and start sessions. - **Audit log**: A tamper-evident record of who connected to which device, when, and for how long — used for compliance reporting and incident investigation. - **Agent**: The small application installed on the endpoint that accepts authorised remote sessions. 247connect ships Managed Agents (permanent) and On-demand Agents (self-removing). - **Control window**: The application the technician uses to view and drive the remote device, hosting the session view alongside in-session tools such as file transfer, chat and Task Manager. - **Reboot and reconnect**: A session feature that restarts the remote device and automatically re-establishes the connection when it comes back up, so a technician does not lose their place mid-task. - **RMM**: Remote monitoring and management — a broader class of platform bundling patching, scripting, alerting and asset management alongside remote access. Remote support tools such as 247connect focus on the access and support workflow itself. ## Video 247connect — An Introduction — https://www.youtube.com/watch?v=OYgoGNWwl_c A short walkthrough of 247connect: how operators add managed and on-demand devices, start an encrypted remote desktop session in around eight seconds, and use in-session tools such as file transfer, chat, PowerShell, Task Manager and remote reboot. - How the 247connect web console lists managed devices and their live status. - Starting a remote desktop session — a typical connection is established in around eight seconds. - On-demand support: sending a lightweight one-time agent to a device with no permanent install. - In-session tooling: drag-and-drop file transfer, real-time chat, PowerShell, Task Manager, and reboot-and-reconnect. - Security model: zero-trust access, AES-256 encrypted sessions, two-factor authentication and audit logs. - Licensing: unlimited named operators on fixed pricing, with five concurrent connections per user. ## Use cases by sector Representative deployment scenarios built from documented product capabilities (not named customer references). Source page: /use-cases ### Internal IT service desk — A hybrid workforce supported from one console A single IT team supports several hundred laptops split between head office, home offices and a handful of regional sites. Staff raise tickets by phone and chat, and expect help while they stay on the call. - Access model: Managed + on-demand - Time to session: ~8 seconds - Operator seats: Unlimited Challenge: - Tickets stall because the technician cannot see what the user sees - VPN-only tooling fails for staff working from home networks - Per-technician licensing discourages part-time and out-of-hours cover How it is set up: - Managed agents deployed to every company-owned laptop for unattended access - On-demand sessions used for contractors and personal devices, with the agent removing itself afterwards - Unlimited operators so first-line, second-line and out-of-hours staff all have their own login Outcome: - Sessions open in roughly eight seconds while the user is still on the call - Reboot and reconnect completes patching without a second appointment - No licence rationing, because operators are unlimited on fixed pricing ### Managed service provider — Many customers, one technician rota An MSP supports dozens of small business clients under a single contract model, with engineers moving between accounts throughout the day. - Concurrent sessions: 5 per operator - Pricing: Fixed, annual - Access control: Zero trust + 2FA Challenge: - Client estates are separated and must stay separated - Engineers work several sessions at once during busy periods - Heavyweight RMM suites cost more than the support work they enable How it is set up: - Managed devices grouped per client so access boundaries mirror the contract - Five concurrent connections per operator, included, for parallel work - Audit logs and two-factor authentication enabled account-wide Outcome: - Engineers keep multiple client sessions live without extra licences - Access reviews are answerable from audit logs rather than memory - Support tooling cost is fixed and predictable across a growing client base ### Education — Shared devices across several school sites A multi-site trust maintains classroom desktops, staff laptops and iPads used by teaching staff, with a small central technical team covering all sites. - Platforms: Windows, macOS, Android, iPadOS - Access model: Unattended (managed) - Site visits: Reserved for hardware faults Challenge: - Devices are in use during lessons and cannot be collected for repair - Site visits consume most of the team's week - Mixed estate spans Windows, macOS, Android and iPadOS How it is set up: - Managed agents installed on classroom and staff machines for out-of-hours work - iPadOS control app used by technicians who are away from a desk - Hardware inventory pulled during sessions to plan replacements Outcome: - Most faults are resolved between lessons, without travel - Overnight maintenance runs unattended, with reboot and reconnect - Fewer site visits mean the same team covers more sites ### Retail and hospitality — Distributed hardware with no local IT A retail estate runs tills, back-office PCs and kiosk machines across many branches. Nobody on site is technical, and downtime is measured in lost sales. - Endpoint types: Tills, back office, kiosk - Session type: Attended + unattended - Encryption: AES-256 Challenge: - Branch staff cannot describe a fault accurately over the phone - Fixes must happen during trading hours - No local technician to install anything on request How it is set up: - Managed agents pre-installed on till and back-office machines at build time - On-demand sessions for third-party hardware brought in by suppliers - In-session chat used to talk branch staff through anything physical Outcome: - Tills come back online without waiting for an engineer to travel - Suppliers get supervised, time-limited access instead of standing credentials - Faults are diagnosed from the actual screen rather than a description ### Public sector and healthcare — Support that has to satisfy an auditor A public sector organisation supports staff handling personal data, and every access route has to be justifiable to an information governance team. - Security model: Zero trust, AES-256, 2FA - Hosting regions: UK, US, Germany - Evidence: Session audit logs Challenge: - Standing remote access to sensitive endpoints is hard to defend - Data residency has to be documented - Every session needs an evidence trail How it is set up: - Zero-trust access model with two-factor authentication for all operators - Cloud hosting selected in the UK, US or Germany to match residency requirements - Audit logs retained as the record of who connected to what, and when Outcome: - Access reviews are evidenced rather than asserted - GDPR-relevant questions have a documented answer - Attended sessions leave nothing installed on the endpoint afterwards ### Small business — One part-time technician, twenty-odd machines A small company has no IT department. A part-time technician, or a director who happens to be technical, keeps around twenty machines running. - Trial: 14 days, no card - Trial allowance: 10 managed, 2 on-demand - Setup effort: Same-day Challenge: - Enterprise tooling is priced and shaped for larger teams - The person fixing things is rarely in the building - Nobody has time to learn a complex platform How it is set up: - Fourteen-day free trial used to prove the workflow before committing - Managed agents on the office machines, on-demand for everyone else - PowerShell and Task Manager used in-session instead of a separate toolset Outcome: - Problems are fixed from anywhere, including evenings and weekends - One fixed annual cost replaces ad-hoc callout fees - The setup takes an afternoon, not a project plan ## How-to guides (task based) ### How to set up unattended remote access to a computer URL: /how-to/set-up-unattended-remote-access Written for: IT staff setting up always-on access to servers, office desktops, kiosks or remote-site machines. 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. **Q: Do I need to install software on the remote computer for unattended access?** A: 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. **Q: Is unattended remote access safe?** A: 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. **Q: Can I set up unattended access on a laptop?** A: 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. **Q: How many devices can one operator manage?** A: 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. 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. ### How to remotely support someone without installing software URL: /how-to/remote-support-without-installing-software Written for: Helpdesk staff, MSPs and anyone supporting external users, contractors, customers or personally-owned machines. 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. **Q: Can you remotely access a computer without installing anything at all?** A: 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. **Q: Does the user have to accept the connection?** A: 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. **Q: What happens when the session finishes?** A: 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. **Q: Is on-demand support secure enough for sensitive work?** A: 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. 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. ### How to transfer files during a remote support session URL: /how-to/transfer-files-during-remote-session Written for: Support staff who need to deliver installers, drivers, patches or configuration files, or collect logs and evidence from a user's machine. Most remote support tools let you move files directly between your machine and the one you are supporting, usually by dragging them into the session window. It is faster than email, avoids putting company files through consumer cloud accounts, and keeps the transfer inside the same encrypted, logged session as the rest of your work. Key takeaways: - In-session transfer keeps files inside the encrypted support session rather than routing them through email or personal cloud storage. - Transfers run with the permissions of the account you are connected as, so a standard user session cannot write to protected folders. - Collecting logs is often more valuable than sending files: it lets you finish the diagnosis after the user has gone back to work. - Very large files are usually better staged from a network share than pushed down a live session. - Log what you moved. A support session that changed files without a record is hard to defend later. #### Why not just email it Email attachments get stripped, size-limited and quarantined, and consumer file-sharing links move company data through accounts nobody administers. Both approaches also break the thread: the file arrives separately from the support session, so nothing ties the change to the work that prompted it. Transferring inside the session avoids all of that. The file travels over the same encrypted channel, arrives on the machine you are already looking at, and appears in the same session record as everything else you did. #### How in-session transfer usually works The common implementation is drag-and-drop: you drag a file from your desktop into the remote session window and it lands on the remote machine, or you drag one out to pull it back. Some tools add an explicit file manager view with both file systems side by side, which is easier for multi-file work. Direction matters more than the mechanism. Pushing files is how you deliver a fix. Pulling files is how you gather evidence, and it is the direction most support teams underuse. - Push: installers, drivers, patches, configuration files, replacement documents - Pull: event logs, crash dumps, screenshots, corrupted files for offline inspection - Both directions should be encrypted in transit and recorded in the session log #### Permissions and the limits you will hit A transfer inherits the rights of the session. If you are connected in the context of a standard user, you cannot drop a file into a protected system directory, and no amount of dragging will change that. Stage the file somewhere writable, then elevate to move it into place. Antivirus is the other common obstacle. Security software on the remote machine inspects arriving files exactly as it would a download, and will quarantine anything it distrusts, including legitimate administrative tools. - Staged transfers into a temporary folder, then an elevated move, work where a direct write is blocked - Very large payloads are often better fetched from an internal share than pushed live - Expect on-access antivirus scanning to add delay on the far end - Some regulated environments disable transfer deliberately, and that is a policy setting rather than a fault #### Collecting evidence properly The most productive use of file transfer in support is not delivering fixes, it is taking evidence away. Pulling the event log, the application log and a crash dump at the moment the fault is reproducible means you can release the user and continue the diagnosis without needing them again. Name what you collect consistently, with the machine name and the date, and attach it to the ticket rather than leaving it on your desktop. The second occurrence of an intermittent fault is far easier to solve when you still have the first one on file. #### Transferring files cleanly 1. Tell the user what you are moving and why: Especially when pulling files off their machine. Silent collection of files from someone's computer is the kind of thing that ends up in a complaint. 2. Check you have somewhere writable: Confirm the destination folder is writable by the session account before you start, rather than discovering it at the end of a large transfer. 3. Drag the file into the session window: Or use the file manager view for multiple files. Watch the progress indicator rather than assuming completion. 4. Verify at the far end: Confirm the file exists, is the expected size, and opens. Interrupted transfers can leave a plausible-looking partial file. 5. Elevate only if you need to: Move the file into a protected location as a separate, deliberate step rather than running the whole session with more rights than the job requires. 6. Record it in the ticket: Note what was transferred, in which direction, and why. This is the record that protects both you and the user. 7. Clean up what you staged: Remove temporary installers and log bundles from the remote machine before you disconnect. Common mistakes: - Dropping a file into a protected directory and blaming the tool when the permission model was the real limit. - Pushing a multi-gigabyte image down a live session when a network share would have taken a fraction of the time. - Collecting logs from a user's machine without telling them. - Leaving installers and diagnostic bundles behind on the remote device. - No note in the ticket, so nobody can later establish what was changed or taken. **Q: Can I copy and paste files in a remote session?** A: Often yes, and clipboard transfer is convenient for small items. Drag-and-drop or a dedicated file transfer view is more reliable for anything large, because clipboard behaviour varies between operating systems and can fail silently. **Q: Is transferring files during a remote session secure?** A: It is as secure as the session, so encrypted in transit on any reputable tool. The additional control that matters is logging: the record should show which files moved, in which direction, and under which operator account. **Q: Why can't I transfer a file to the remote machine?** A: The usual causes are folder permissions in the session's account context, antivirus quarantining the arriving file, or a policy that disables transfer entirely. Check in that order. **Q: What size of file can I transfer?** A: There is rarely a hard cap, but practical throughput depends on the connection at the far end. Anything very large is usually faster staged from an internal share, with the session used to trigger the copy. In 247connect: In 247connect, drag-and-drop transfer works in both directions inside the same encrypted session as chat, PowerShell and Task Manager, so delivering a fix and collecting the logs do not need separate tools. ### How to reboot a computer remotely and reconnect automatically URL: /how-to/remote-reboot-and-reconnect Written for: Anyone applying updates, clearing faults or finishing installations on a machine they cannot physically touch. 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. 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. 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. 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. 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. 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. Wait out the threshold before escalating: Give updates time to finish. Interrupting an in-progress update is how a restart becomes a rebuild. 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. **Q: Will I lose my remote connection if I reboot the computer?** A: 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. **Q: How do I reboot a remote computer into safe mode?** A: 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. **Q: How long should I wait after a remote reboot?** A: 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. **Q: What if the machine does not come back?** A: 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. 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. ### How to work with multiple monitors in a remote session URL: /how-to/remote-support-multiple-monitors Written for: Support staff and administrators working on multi-display desktops, trading floors, design workstations and control rooms. When the machine you are supporting has more than one display, a remote session has to decide what to show you. The three usual options are all screens at once, one screen at a time, or one remote screen per local monitor. Which is best depends on whether you are watching for something or working on something. Key takeaways: - Spanning all displays into one window is good for orientation and bad for detailed work. - Single-screen view with quick switching is usually the fastest way to actually get something done. - Mismatched aspect ratios and scaling are what make multi-monitor sessions feel unusable, not bandwidth. - Ask the user which screen the problem is on before you start hunting through displays. - Dialog boxes routinely open on the screen you are not looking at, which explains a surprising number of apparently frozen applications. #### The three viewing modes Spanning shows every remote display side by side in one window. You see the whole desktop, but everything is shrunk, and on a triple-monitor target viewed from a single laptop screen it becomes unreadable. It is the right choice for the first ten seconds, when you want to understand the layout. Single-screen mode shows one display at full size with a control to switch. This is where most real work happens, because text is legible and the mouse behaves predictably. Multi-monitor mapping, where each remote display opens on one of your own, is the most comfortable option when your setup matches theirs. - Span all: orientation, spotting which screen has the problem - Single screen: legible detail work, the default for actual troubleshooting - One remote screen per local monitor: closest to sitting at the machine, needs matching hardware #### Why it looks wrong even when it works Two displays of different resolutions produce an irregular combined desktop, and remote tools letterbox the difference. Add per-monitor display scaling, common on high-resolution laptop panels, and the remote cursor can appear offset from where it actually is. Setting the session to a fixed scaling mode rather than automatic usually resolves the cursor offset. If text is unreadable, resist the urge to zoom the whole spanned view and switch to single-screen mode instead. #### The disappearing dialog box A large share of multi-monitor support calls are one problem: a modal dialog has opened on a display the user is not looking at, or on a screen that is currently disconnected. The application appears frozen because it is waiting for an answer nobody can see. Cycle through every display before you conclude an application has hung. If a screen was disconnected since the window was placed, the operating system's window-arrangement shortcuts will pull it back onto an active display. #### Working a multi-monitor session efficiently 1. Ask which screen the problem is on: Ten seconds of conversation saves several minutes of switching between displays looking for it. 2. Open in span mode to see the layout: Get your bearings on how many displays there are and how they are arranged, then move on. 3. Switch to single-screen for the work: Full-size, legible, and predictable. Learn the switch shortcut so moving between displays is instant. 4. Fix scaling before blaming the connection: Set a fixed scaling mode if the cursor is offset or text is blurred. This is usually a scaling artefact rather than a bandwidth problem. 5. Check every display for stray dialogs: Before diagnosing a hung application, confirm it is not simply waiting on a prompt you cannot see. 6. Leave the layout as you found it: If you moved windows between displays to work, put them back. Users notice, and it is a small courtesy that goes a long way. Common mistakes: - Working the whole session in spanned view and fighting unreadable text throughout. - Diagnosing a frozen application that is really a dialog on an off-screen display. - Ignoring per-monitor scaling and assuming the cursor offset is latency. - Rearranging the user's windows and leaving them scattered across the wrong screens. - Forgetting that a disconnected display can still hold windows, which stay invisible until they are recalled. **Q: Can I see all the remote monitors at once?** A: Yes, most remote desktop tools can span every remote display into a single window. It is useful for orientation, but on a target with three displays viewed from one laptop screen, everything becomes too small to work with comfortably. **Q: How do I switch between monitors in a remote session?** A: Tools provide a monitor selector in the session toolbar, usually with a keyboard shortcut. Learning the shortcut is worth the thirty seconds, because you will use it constantly on multi-display machines. **Q: Why does the remote cursor not line up with mine?** A: Almost always display scaling. When local and remote machines use different scaling factors, the coordinate mapping drifts. Setting a fixed scaling mode for the session normally corrects it. **Q: A window has vanished on the remote machine. Where is it?** A: It is likely positioned on a display that is currently disconnected or switched off. The operating system's window-snapping shortcuts will move the active window back onto a visible screen. In 247connect: 247connect sessions handle multi-monitor targets with per-display switching, so you can work at full size on the screen that matters rather than squinting at a spanned view of the whole desk. ### How to wake a powered-off computer for remote access URL: /how-to/wake-on-lan-remote-access Written for: IT teams supporting out-of-hours patching, home workers reaching office desktops, and anyone tired of asking users to leave machines on. Remote access needs the target machine to be running. Wake-on-LAN solves half of that problem by sending a specially formed network packet that powers a sleeping or soft-off machine back on. It works well on wired, same-subnet devices with the right firmware settings, and it is unreliable or impossible in several common situations worth knowing about in advance. Key takeaways: - Wake-on-LAN has to be enabled in two places: the machine firmware and the operating system's network adapter settings. - It is a broadcast, so it does not cross subnets or reach across the internet without a relay on the same network. - Wi-Fi wake is unreliable on most hardware. Treat wired as the supported path. - Fast startup on Windows can prevent wake from a soft-off state, and is a frequent cause of unexplained failure. - Where wake is not viable, scheduled power-on in firmware or a simple always-on policy for a defined set of machines is often the pragmatic answer. #### How wake-on-LAN works The network adapter stays partially powered when the machine is asleep or soft-off, listening for a specific broadcast frame addressed to its hardware address. Receiving it triggers a power-on. Nothing else on the machine is running, which is precisely why the feature has to be implemented in the adapter and the firmware rather than in software. That also explains the limitations. Because the packet is a broadcast on the local network segment, it does not route across subnets or the internet on its own, and anything that changes the machine's power state handling can break it. #### Getting it enabled There are two switches, and both must be on. In firmware, the setting is typically called wake-on-LAN, power on by PCIe, or resume by LAN, depending on the manufacturer. In the operating system, the network adapter's power management properties must allow the device to wake the computer, and specifically to do so only on a magic packet, so ordinary network chatter does not wake it constantly. On Windows, also check fast startup. It puts the machine into a hybrid state that many adapters will not wake from, and disabling it resolves a large share of cases where everything else looks correctly configured. - Firmware: enable wake-on-LAN, resume by LAN or power on by PCIe - Adapter properties: allow this device to wake the computer, magic packet only - Windows: disable fast startup if wake from soft-off fails - Record the machine's MAC address, because that is what the wake packet targets #### Crossing networks Sending a wake packet from outside the local segment needs help. The standard approach is to have a device that is already awake on the same subnet forward the packet on your behalf: another always-on machine, a management appliance, or a router that supports directed broadcast forwarding. Many organisations use a small always-on machine per site for exactly this purpose. It is unglamorous and it works, and it also gives you a reachable device to diagnose from when a site appears to be entirely offline. #### When to stop trying Wi-Fi wake support depends on the adapter, the driver and the access point all cooperating, and frequently one of them will not. Laptops in a bag, machines on hotel networks, and anything behind a captive portal are not going to answer regardless of configuration. In those cases, decide the policy instead of fighting the technology. A defined set of machines that stay powered on, or a firmware-scheduled power-on before the patch window, is more reliable than wake-on-LAN across an estate that was never wired for it. #### Enabling wake-on-LAN end to end 1. Confirm the machine is wired: Start with Ethernet. If wireless wake is a requirement, verify it on one device before assuming it works across the estate. 2. Enable it in firmware: Look for wake-on-LAN, resume by LAN or power on by PCIe. The wording varies by manufacturer, the effect is the same. 3. Configure the network adapter: Allow the device to wake the computer, and restrict waking to magic packets so stray traffic does not power it on repeatedly. 4. Disable fast startup on Windows: The hybrid shutdown state prevents wake on a lot of hardware. This is the most common single fix. 5. Record the MAC address: Store it against the device in your inventory. The wake packet is addressed to the hardware address, not the IP. 6. Provide a relay for remote sites: Nominate an always-on device on each subnet to forward wake packets, since broadcasts do not route by themselves. 7. Test from a cold state: Shut the machine down fully, wake it, and connect. Testing only from sleep hides the fast-startup problem entirely. Common mistakes: - Enabling wake in firmware but not in the operating system's adapter settings, so it never works and nobody can see why. - Leaving Windows fast startup on and concluding the hardware does not support wake. - Expecting a broadcast packet to cross subnets or reach a site over the internet unaided. - Relying on Wi-Fi wake across a mixed laptop estate. - Waking machines for a patch window with no matching plan to shut them down afterwards. **Q: Can I remotely access a computer that is turned off?** A: Not directly, because nothing is running to answer. Wake-on-LAN can power the machine on first, provided it is enabled in firmware and the network adapter, and the wake packet can reach the machine's network segment. **Q: Does wake-on-LAN work over the internet?** A: Not on its own. The wake frame is a local broadcast. You need something already awake on the same subnet to forward it, such as an always-on machine, a management appliance or a router that supports directed broadcasts. **Q: Why is wake-on-LAN not working?** A: In rough order of likelihood: fast startup is enabled on Windows, the adapter's power management setting is off, firmware support is disabled, the packet is not reaching the right subnet, or the machine is on Wi-Fi where support is unreliable. **Q: Is there an alternative to wake-on-LAN?** A: Firmware-scheduled power-on before a known maintenance window, or a policy that a defined set of machines stays powered on. Both are less elegant and considerably more predictable. In 247connect: Once a machine is awake, 247connect connects to it as a managed device in around eight seconds, so pairing a reliable wake method with fast connection times is what makes out-of-hours maintenance practical. ### How to make remote access work through firewalls without opening ports URL: /how-to/remote-access-firewall-ports Written for: Network and IT staff deploying remote access across sites with strict egress filtering or inspection proxies. Older remote access approaches expected you to forward an inbound port to each machine, which is both laborious and a standing invitation to attackers. Cloud-brokered tools invert it: the agent makes an outbound connection to a broker, and your session is relayed over that existing channel. Nothing inbound is exposed, and in most networks it works with no firewall change at all. Key takeaways: - Outbound-only architecture removes the need for inbound port forwarding, which is a significant security improvement over exposed RDP. - In most networks, standard outbound HTTPS on port 443 is all that is required. - Deep packet inspection and TLS interception are the usual causes of failure on locked-down networks, not blocked ports. - Allow-list by hostname where you can, because cloud service IP ranges change. - Exposing remote desktop protocols directly to the internet is a well-documented route to compromise. Do not do it. #### Outbound beats inbound The old model required each remote machine to be reachable from outside, which meant port forwarding at the router, static addressing, and a service listening for connections from anyone who found it. That last part is the problem: internet-exposed remote desktop endpoints are routinely scanned and attacked, and are a well-documented initial access route for ransomware. The modern model reverses direction. The agent on the remote machine opens an outbound connection to a broker service and holds it. When an operator wants a session, the broker matches the two sides over connections that were both initiated from inside their own networks. No inbound rule exists, so there is nothing on the perimeter to find and attack. #### What to allow Most deployments need outbound TCP on port 443 to the vendor's service endpoints, which the majority of corporate networks already permit for general web traffic. If your egress policy is default-allow, there is genuinely nothing to configure, and the deployment will simply work. On a default-deny network, allow-list the vendor's published hostnames rather than IP addresses. Cloud infrastructure changes addresses without notice, and an IP-based rule will fail at an unpredictable moment months later, usually during an incident. - Outbound TCP 443 to the vendor's documented endpoints - Hostname-based allow-listing in preference to IP ranges - An exclusion from TLS interception for those hostnames if you run an inspecting proxy - No inbound rules at all, which is the entire point of the design #### When it still does not connect On tightly controlled networks the failure is rarely a closed port. It is usually TLS interception: the inspection proxy substitutes its own certificate, the agent correctly refuses to trust it, and the connection is dropped. The fix is a bypass rule for the vendor's hostnames, not a change to the agent. Other recurring causes are proxy configuration that exists for the logged-in user but not for the system account the agent runs under, and captive portals that intercept everything until someone authenticates in a browser. - TLS inspection breaking certificate validation, the most common cause on enterprise networks - Proxy settings configured per-user but not for the system service account - Captive portals holding the machine before it can reach anything - Endpoint security software blocking the agent process rather than the network path #### Diagnosing it in the right order Work from the network outwards. Confirm the machine can resolve the vendor hostname, then that it can open a TLS connection to it, then look at the agent's own log. Each step tells you which team owns the next action, which is what actually gets these tickets closed in a large organisation. Test from the system account context where you can. A great deal of time is lost proving that a connection works in a browser, when the browser is using per-user proxy settings the agent has never seen. #### Getting remote access working through a firewall 1. Confirm the tool is outbound-only: If a product asks you to forward an inbound port to each machine, that is a meaningful mark against it on security grounds. 2. Check outbound 443 is permitted: On most networks this is already allowed and no change is needed at all. 3. Allow-list by hostname: Use the vendor's documented hostnames rather than IP addresses, so the rule survives infrastructure changes. 4. Bypass TLS inspection for those hosts: Interception breaks certificate validation and is the leading cause of failure on inspected networks. 5. Verify the system account's network path: The agent runs as a service. Per-user proxy settings do not apply to it, which explains connections that work in a browser but not for the agent. 6. Read the agent log before escalating: It will usually distinguish a name resolution failure from a certificate rejection, which points at the right team immediately. 7. Retire any exposed remote desktop ports: Once brokered access is working, close inbound remote desktop from the internet. Leaving it open alongside is the worst of both designs. Common mistakes: - Leaving inbound remote desktop exposed to the internet alongside a brokered tool. - Allow-listing IP addresses for a cloud service, which will break silently later. - Forgetting that TLS inspection will break certificate validation for the agent. - Testing only in a browser, under a user account with proxy settings the service account does not have. - Treating a captive portal as a firewall problem when it is an authentication problem. **Q: Do I need to open firewall ports for remote desktop software?** A: Not for cloud-brokered tools. The agent connects outbound over HTTPS and the session is relayed over that channel, so no inbound rules are required. Older direct-connection approaches did need port forwarding, which is part of why they were risky. **Q: Which ports does remote support software use?** A: Typically outbound TCP 443, the same port as ordinary secure web traffic, which most networks already permit. Check the specific vendor's documentation for the exact hostnames to allow on a default-deny network. **Q: Is it safe to expose RDP to the internet?** A: No. Internet-exposed remote desktop endpoints are continuously scanned and are a well-documented initial access route for ransomware. Use a brokered service or a controlled gateway instead. **Q: Why does the agent fail to connect when a browser works fine?** A: Usually because the agent runs as a system service and does not inherit the per-user proxy configuration the browser is using, or because TLS inspection is presenting a certificate the agent will not trust. In 247connect: 247connect agents connect outbound over HTTPS to the cloud service, so there are no inbound firewall rules to create and no ports exposed to the internet on the machines you support. ### How to remotely support someone working from home URL: /how-to/support-a-home-worker Written for: Helpdesk and IT teams supporting hybrid and fully remote staff on home broadband and mixed devices. Supporting a home worker is technically similar to supporting an office user and practically quite different. You have no control over the network, the device may be shared with a household, and you are working inside someone's home. The technical part is usually straightforward once you accept that connectivity, not the application, is the most likely cause. Key takeaways: - Assume connectivity first. Most home-working faults reported as application problems are network problems underneath. - You cannot administer a home router, so build diagnostics that work without it. - On a personal device, use attended access with visible consent, never a permanent agent. - Household context matters: shared bandwidth, other people's devices, and a lack of privacy on video calls are real causes of real tickets. - Peer-reviewed work on remote working consistently finds that effective IT support is a foundation of productive remote work, not a peripheral service. #### Start with the connection The single most useful question in home-worker support is whether the problem persists on a different network, such as a phone hotspot. It separates a genuine application fault from a connectivity fault in about a minute, and connectivity is the more common answer by a wide margin. Home broadband contends with everything else in the house. A call that breaks up every afternoon is often a household pattern rather than a fault, and the honest answer is sometimes about scheduling or a wired connection rather than a configuration change. - Test on a phone hotspot to isolate the home network - Ask about distance from the router and whether the device is wired - Check whether the fault correlates with times other household members are online - Distinguish VPN problems from internet problems before changing anything #### Corporate device or personal device This distinction determines what you may do, not just what you can do. On a corporate laptop, a managed agent and unattended access are reasonable and let you patch and fix outside working hours. On a personally-owned machine, permanent access is disproportionate and creates a privacy problem your organisation does not want. For personal devices, use attended sessions with explicit consent every time. National guidance on device security and personal devices at work makes a related point about data: keeping corporate information centrally held, rather than cached on the personal machine, limits what is exposed if that device is lost, sold or shared. #### Working in someone's home Remote support to a home is an unusually personal interaction. You may see personal files, family photographs, other people's names in a browser, and the state of a room on a video call. Treating that with obvious discretion is part of the job, and it strongly shapes whether people ask for help early or struggle silently. Say what you are doing before you do it. Announce when you take control, narrate as you work, and confirm clearly when the session has ended. It costs nothing and it is the difference between support that feels helpful and support that feels intrusive. #### Reducing the volume The same handful of issues generate most home-working tickets: wireless quality, VPN or sign-in failures, peripherals not connecting, and confusion about which applications should be used for what. Each of those is addressable with a short, plainly-written self-help page and a consistent answer from every technician. Track which problems recur per person as well as per category. A user who calls weekly about wireless drops usually has a house problem that no amount of software support will resolve, and a wired adapter is the actual fix. #### A repeatable home-support routine 1. Confirm the device type first: Corporate or personal. It changes what access is appropriate and what you are permitted to change. 2. Isolate the network: Ask them to try a phone hotspot. This one test resolves an ambiguity that would otherwise take twenty minutes. 3. Check the VPN separately from the internet: Users report both as the internet being down. Establish whether general browsing works before touching the VPN client. 4. Start an attended session with clear consent: Explain what will appear on screen, and confirm they can see the session is active and can end it. 5. Narrate as you work: Say what you are doing and why. It reduces anxiety and often prevents the next call on the same subject. 6. Fix the underlying pattern where you can: If someone calls weekly about wireless, send a wired adapter. Repeat tickets are usually an environment problem, not a user problem. 7. Close the session visibly and follow up in writing: Confirm access has ended, then send a short summary of what changed so the user has a record. Common mistakes: - Installing a permanent agent on a personally-owned machine, which is a privacy and governance problem regardless of intent. - Debugging an application for half an hour when the home wireless was the cause all along. - Taking control without announcing it, in someone's home, on a machine with personal content on it. - Assuming a home user can change router settings, or should be asked to. - Treating repeat callers as difficult users rather than as evidence of an unfixed environmental problem. **Q: How do I support a home worker's personal computer?** A: Use an attended, on-demand session that the user starts and can end, and avoid installing a permanent agent. Where possible, keep corporate data on centrally-managed systems rather than cached on the personal device. **Q: Can I fix a home worker's Wi-Fi remotely?** A: You can diagnose it, but you cannot administer their router and generally should not try. The practical remedies are moving the device closer, using a wired connection, or supplying a small adapter or extender. **Q: Should home workers' laptops have unattended remote access?** A: For corporate-owned laptops, yes, it allows patching and fixes outside working hours. The usual constraints apply: named operator accounts, multi-factor authentication, session logging and a visible policy so staff know it exists. **Q: What is the most common home-working IT problem?** A: Connectivity, by a considerable margin, followed by authentication and VPN access. Checking those first resolves the majority of tickets faster than starting with the application the user reported. In 247connect: 247connect covers both halves of this: managed devices for corporate laptops that need out-of-hours patching, and on-demand sessions for personal machines where a permanent agent would not be appropriate. ### How to run PowerShell on a remote machine during support URL: /how-to/run-powershell-remotely Written for: Windows administrators and second-line support staff who would rather query a machine than click through it. Many remote support tools give you a command line on the target machine alongside the screen. It is quicker than clicking through interfaces, it works without disturbing whoever is using the desktop, and it produces text output you can paste straight into a ticket. The discipline it requires is a record of what you ran and why. Key takeaways: - A command line is usually faster than the graphical interface for gathering facts, and far faster across several machines. - Background command execution lets you diagnose without taking over a screen someone is working on. - Read before you write. Gather state first, then make one change at a time. - Anything you run on someone else's machine should be reconstructable afterwards from the ticket. - Do not paste commands you have not read. Copying from a search result into a production machine is a genuine incident category. #### Why the command line wins for diagnosis Establishing which services are stopped, how much disk is free, what installed last week, or which process is holding a port is several clicks and several windows in a graphical session. As a command it is one line, and the output is text you can attach to the ticket rather than a screenshot someone will have to squint at. The advantage grows with scale. A question you can answer with a command can be answered across fifty machines with the same command. A question you answer by clicking can only ever be answered one machine at a time. - Service state, startup type and recent failures - Disk space, large directories and free space trends - Installed updates and their install dates - Network configuration, name resolution and connectivity tests - Event log entries filtered to the window when the fault occurred #### Working without interrupting the user The best remote support is invisible. If you can answer the question from a command line while the user carries on working, you have avoided taking their screen, avoided the awkward pause, and avoided the interruption cost entirely. This changes the shape of a support call. Gather everything you can in the background first, form a hypothesis, and only take the screen when you need to see something visual or demonstrate a change to the user. #### Doing it safely Two rules cover most of the risk. First, separate reading from writing: run the queries that establish the current state before you change anything, and change one thing at a time so you know what caused the outcome. Second, never run a command you have not read and understood, particularly one copied from a forum during a stressful incident. Elevation deserves the same discipline. Run with the lowest rights that will answer the question, and elevate deliberately for the specific action that needs it, rather than starting every session with full administrative rights out of habit. #### Keeping the record Commands run during a support session are changes to a production machine. The session log should show that a command line was used, and your ticket should record what was run and what it returned. Without both, a later question about who changed a setting has no answer. This is also how a support team gets better over time. Commands that keep appearing in tickets are candidates for a script, and scripts that keep being run manually are candidates for automation. #### Using a remote command line well 1. Gather state before changing anything: Run your read-only queries first and capture the output. You cannot tell what your change did without a baseline. 2. Work in the background where possible: Diagnose without taking the screen, so the user can keep working while you investigate. 3. Read every command before running it: Especially anything copied from elsewhere. Understand what it does on this machine before it does it. 4. Change one thing at a time: Batching three fixes together means you will never know which one worked, or which one broke something else. 5. Elevate only for the step that needs it: Least privilege applies to support sessions as much as to anything else. 6. Paste output into the ticket: Text output is searchable, comparable across incidents, and far more useful than a screenshot. 7. Promote repeated commands into scripts: Anything you type more than a few times a month should be a saved script with a known-good version. Common mistakes: - Running commands copied from a search result without reading them. - Making several changes at once and losing the ability to attribute the result. - Working with full administrative rights for the whole session out of habit. - No record of what was run, leaving a later configuration question unanswerable. - Using the command line to avoid talking to the user, when a thirty-second conversation would have identified the cause. **Q: Can I run PowerShell on a remote computer during a support session?** A: Yes. Many remote support tools include a command line against the target machine, often available without taking over the user's screen, which lets you gather diagnostics while they carry on working. **Q: Is it safe to run commands on a user's machine remotely?** A: It is as safe as your discipline. Read state before writing, change one thing at a time, run with the lowest rights that will do the job, and record what you ran in the ticket. **Q: Do I need administrator rights to run remote commands?** A: For most diagnostic queries, no. Service changes, registry edits and software installation do. Elevate for the specific step rather than for the whole session. **Q: How should command activity be audited?** A: The session record should show that a command line was used, by which operator and when, and the ticket should carry the commands and their output. Together those reconstruct what happened on the machine. In 247connect: 247connect includes PowerShell and Task Manager access alongside the remote screen on managed devices, so you can gather diagnostics in the background without interrupting whoever is using the machine. ### How to audit and review remote access sessions URL: /how-to/audit-remote-access-sessions Written for: IT managers, security leads and anyone answering audit or certification questions about privileged remote access. An audit trail for remote access answers one question: who connected to what, when, and what happened. Getting that right requires named accounts, complete session records, a retention period you have actually decided, and a review that someone genuinely performs. Most organisations have the logs and skip the review, which means problems are only ever found afterwards. Key takeaways: - Shared accounts make an audit trail worthless. You cannot attribute a session to a person who shares a login with four others. - A useful record covers operator, target device, start and end time, connection type, and what actions were taken. - Decide retention deliberately and write down the reason. An unbounded log is a liability and a two-week log is often too short to be useful. - The review is the control. Logs nobody reads detect nothing. - Offboarding is where most real exposure lives: former staff and ended supplier relationships with credentials still valid. #### What a session record should contain At minimum: the named operator, the target device, timestamps for start and end, and whether the session was attended or unattended. That is enough to answer the basic question of who was where and when. Beyond that, records of the significant actions within the session are what make the trail genuinely useful: files transferred in either direction, commands run, reboots triggered, and whether the user consented for attended sessions. The difference between a log that satisfies an auditor and one that does not is usually this layer of detail. - Named operator account, never a shared or generic login - Target device identity, ideally matching your asset register - Start time, end time and session duration - Attended or unattended, and consent where applicable - Files transferred, commands run, restarts triggered #### Retention that you can justify Retention should be a decision, not a default. Too short and you cannot investigate anything discovered later, which is when most things are discovered. Too long, or unbounded, and you are holding personal data about staff activity with no stated purpose, which is its own problem. Set a period, write down why you chose it, and align it with the retention you already apply to other security logs. Consistency with your existing policy is easier to defend than a number chosen for one system in isolation. #### The review nobody does Logging is the easy half. The control that actually detects misuse is a periodic review by someone competent to notice that a pattern is odd. Sessions outside working hours to machines the operator does not normally touch, a spike in connections to a single device, or activity from an account that should have been disabled are all visible to a reviewer and invisible to a log file. Keep the review small enough to be sustainable. A monthly sample plus a quarterly full review of accounts and devices is far more effective than an aspirational daily process that lapses after three weeks. #### Offboarding is the real risk The exposures that matter in practice are rarely exotic. They are a technician who left last year whose account still works, a managed service provider whose contract ended but whose access did not, and a device group that grew steadily and was never trimmed. Tie operator accounts to your existing joiners, movers and leavers process so removal is automatic rather than remembered. If the remote access tool is administered separately from your identity system, it will drift out of step, and that gap is where the risk accumulates. #### Establishing a defensible audit trail 1. Eliminate shared accounts: One named account per operator, with multi-factor authentication. Nothing else in this list works without it. 2. Confirm what your tool records: Check whether file transfers, commands and reboots appear in the record, not just connection times. Know the gaps before an auditor finds them. 3. Set and document a retention period: Align it with your other security logging and write down the justification. 4. Export logs somewhere independent: Forward to your SIEM or log store so the record does not live solely inside the system it describes. 5. Run a monthly sample review: A small number of sessions, checked properly, by someone who understands what normal looks like. 6. Review accounts and devices quarterly: Every operator account and every unattended device gets re-justified, or removed. 7. Wire removal into offboarding: Access should end when the person or contract does, automatically, not when somebody remembers. Common mistakes: - Shared operator logins, which make the entire audit trail unattributable. - Logs that record connection times but nothing about what happened in the session. - Keeping everything forever with no stated purpose, which creates its own data protection exposure. - A review process that exists in the policy document and nowhere else. - Remote access accounts administered outside the identity system, so leavers keep working credentials. **Q: What should a remote access audit log contain?** A: The named operator, the target device, start and end times, whether the session was attended or unattended, and the significant actions taken during it, such as file transfers, commands run and restarts triggered. **Q: How long should remote session logs be kept?** A: Long enough to investigate something discovered later, and no longer than you can justify. Align the period with your other security logging and document the reasoning rather than picking a number in isolation. **Q: How often should remote access be reviewed?** A: A monthly sample of sessions and a quarterly review of operator accounts and unattended devices is a sustainable baseline. A process that is realistic beats one that is thorough on paper and never performed. **Q: What do auditors usually ask about remote access?** A: Who can connect, how they authenticate, which devices are reachable without consent, what is recorded, how long records are kept, and how access is removed when someone leaves. Have an evidenced answer for each. In 247connect: 247connect records sessions against named operator accounts under a zero-trust model with two-factor authentication and AES-256 encryption, which covers the attribution and evidence side of the list above. ## Sector and role guides ### Remote IT support for schools, colleges and multi-academy trusts URL: /sectors/schools-and-education Written for: Network managers, IT coordinators and trust-wide IT leads in schools, colleges and multi-academy trusts. Education IT is defined by scale against budget: hundreds or thousands of shared devices, several sites, and a team that is often two or three people. Remote access is what makes that ratio work, provided it respects the two constraints that are specific to schools: safeguarding around pupil-facing devices, and a teaching day that cannot be interrupted. Key takeaways: - Site visits are the largest hidden cost in multi-site education IT, and remote access removes most of them. - Classroom devices need attended, consented sessions. Unattended access to a screen a pupil is using is a safeguarding question, not a convenience question. - Servers, suites and shared staff machines are the natural unattended set, and they cover most of the maintenance workload. - Holidays are the real maintenance window. Remote access is what makes it possible to use them without everyone being on site. - Fixed per-year costs matter more than per-technician pricing when your team size fluctuates with funding. #### The multi-site problem A trust with six schools and three technicians spends a large share of the working week in a car. Every journey is time not spent on the queue, and the queue at the site you just left carries on growing. Remote access changes the arithmetic directly: the majority of tickets stop requiring a journey at all, and the visits that remain are genuinely physical work. The gain is not only in the travel. Being able to reach every site from one place makes it practical to standardise, because you can actually see what is on each machine without arranging access to a locked room during a lesson. #### Safeguarding and consent In an education setting, remote access to a device a pupil is using needs to be visible and consented. That is not a technical preference. It shapes which devices belong in the unattended category and which do not, and it should be written into the acceptable use documentation that staff and parents see. The practical split is straightforward. Infrastructure, staff workstations and unoccupied suite machines can be unattended. Anything a pupil may be sitting at during a session should be attended, with a visible indicator and an obvious way for the teacher to end it. - Unattended: servers, network appliances, staff room machines, empty ICT suites, signage - Attended: pupil-facing devices, one-to-one laptops, classroom teacher machines during lessons - Document the split in the acceptable use policy, and make it readable by non-technical staff #### Making holidays productive Every education IT team plans its large work around holidays, and every holiday is shorter than the plan. Remote access to an empty building means image deployment, patching, software rollouts and clean-up can proceed with one person on site rather than the whole team, and can continue in the evenings without anyone in the building. The prerequisite is that machines are reachable when nobody is there. That means the agent starts with the operating system, machines are either left powered or reliably wakeable, and someone has verified the reboot path before term ends rather than discovering the gap on the first day back. #### Licensing that fits an education team School IT teams flex. A trust may run with two technicians, then take on an apprentice, then use a contractor over the summer. Licensing that charges per technician penalises exactly the flexibility the sector relies on, and creates the familiar bad habit of sharing a login, which destroys the audit trail. Fixed pricing with unlimited operators removes that pressure. Everyone gets a named account, the audit trail stays intact, and the budget line does not change when the team does. #### Rolling remote support out across a school estate 1. Inventory by site and by device role: Separate infrastructure, staff devices, suite machines and pupil devices. The categories determine access model, not the site. 2. Write the access policy before deploying: State plainly which devices can be reached unattended and which require consent, in language a teacher and a parent can follow. 3. Start with servers and suites: The unattended set delivers the biggest reduction in travel with the fewest questions to answer. 4. Give every technician a named account: Including apprentices and contractors. Shared logins in a safeguarding context are not defensible. 5. Test the holiday scenario in term time: Reboot a suite machine remotely and confirm it comes back on its own, while there is still someone on site if it does not. 6. Train teaching staff on the attended flow: A single short explanation of what they will see, and how to end a session, prevents most of the friction. 7. Review the device list each academic year: Estates change constantly in education. An unreviewed unattended list drifts within one year. #### Access model by device type | Device type | Recommended access model | | --- | --- | | Servers and network appliances | Unattended, restricted to senior technicians | | ICT suite workstations | Unattended outside lesson time, attended during lessons | | Staff laptops and office PCs | Unattended, with clear policy communication | | Pupil one-to-one devices | Attended only, with visible consent | | Signage, kiosks and hall systems | Unattended | Common mistakes: - Putting pupil-facing devices into the unattended group because it was simpler at deployment time. - Sharing one technician login across the team, which makes safeguarding questions impossible to answer. - Assuming suite machines will wake for holiday maintenance without ever having tested it. - Choosing per-technician licensing when your team size changes every year. - Never revisiting the device list, so decommissioned machines stay listed and new ones are missed. **Q: Is remote access to pupil devices allowed in schools?** A: It depends on how it is done. Attended sessions with visible consent, started by a member of staff, are normal practice. Silent unattended access to a device a pupil is using raises safeguarding concerns and should be avoided. **Q: How do multi-academy trusts support several sites with a small team?** A: By making remote access the default and site visits the exception. Once infrastructure and shared machines are reachable remotely, the technician count needed per site drops sharply and travel stops consuming the week. **Q: Can we patch and image machines during the holidays remotely?** A: Yes, provided the agent starts with the operating system and the machines are either left powered on or reliably wakeable. Test the reboot and reconnect path during term time rather than on the first day of the holiday. **Q: What licensing model suits school IT teams?** A: Fixed pricing with unlimited named operators, because education team sizes change with funding and staffing. Per-technician pricing tends to push teams towards shared logins, which is the opposite of what a safeguarding audit needs. In 247connect: 247connect fits this pattern with managed devices for infrastructure and suites, on-demand sessions for consented classroom support, and unlimited operators on fixed pricing so every technician and apprentice can have a named account. ### Remote IT support in healthcare and clinical settings URL: /sectors/healthcare Written for: IT teams in hospitals, GP practices, dental and veterinary groups, care providers and private clinics. Healthcare raises the stakes on every part of remote support. The machines carry patient data, they are in continuous use, and downtime has clinical consequences rather than commercial ones. The technology is the same as anywhere else; the governance around it, and the evidence you can produce afterwards, is what differs. Key takeaways: - Assume any clinical workstation may display patient data, and design consent and logging accordingly. - Shared clinical logins are common in practice, which makes remote session attribution on the IT side even more important. - Care is delivered around the clock, so the maintenance window is negotiated with clinical staff rather than assumed. - Connected medical devices and their controllers are frequently out of scope for normal patching, and need explicit handling. - Auditability is not optional. Assume every session will one day need to be explained. #### Patient data changes the consent model A remote session on a clinical workstation may reveal a patient record on screen. That makes attended, consented access the default for anything a clinician uses, with the clinician able to see the session is running and end it, and able to close a record before you take the screen. For unattended work on those machines, prefer approaches that do not require viewing the desktop at all. A command line, a service restart or a background diagnostic answers a great many questions without ever displaying patient information to an IT operator. #### Least privilege, applied properly Support staff should be able to fix the machine without being able to browse the clinical system. That means separating the operating system administration rights they need from the application access they do not, and resisting the convenience of a single all-powerful support account. Where an issue genuinely requires seeing the clinical application, do it as an attended session with the clinician present. It is slower, and it is the correct trade in this setting. - Distinct operator accounts with multi-factor authentication, never shared - Operating system rights separated from clinical application access - Attended sessions as the default on any device a clinician uses - Full session logging exported to a system the IT team does not solely control #### Working around clinical hours In an environment that never closes, there is no quiet period to assume. Maintenance windows are negotiated with clinical leads, they differ by department, and they are cancelled when the department is busy. Remote access helps mainly by shortening every task, which makes it possible to fit work into the short windows you actually get. It also removes the delay of getting an engineer to a site at three in the morning, which for many providers is the difference between a fault resolved in twenty minutes and one resolved at the start of the next shift. #### Medical devices and their controllers Imaging systems, analysers and monitoring equipment often run on controller machines that cannot be patched or altered without invalidating the supplier's support arrangement. They are still on the network and still generate faults, so they need a defined approach rather than being quietly excluded. Agree in advance with the supplier what IT may do, whether remote access to the controller is permitted, and who to call when it is not. Writing that down once prevents a stalled fault at the point where somebody is waiting for a scan. #### Setting up remote support in a clinical environment 1. Classify every device by data exposure: Which machines can display patient data, which cannot. That single classification drives the access model for each. 2. Set attended access as the clinical default: Consented sessions on anything a clinician uses, with the ability to close records before the screen is shared. 3. Separate system rights from clinical application rights: Support staff should be able to fix the machine without being able to read the record. 4. Agree maintenance windows department by department: There is no global quiet hour. Negotiate per area and expect windows to be cancelled at short notice. 5. Document the medical device position: Establish per supplier what remote access and patching are permitted, and who owns the fault when they are not. 6. Export session logs off the platform: Forward to central logging so the audit trail is independent of the tool being audited. 7. Rehearse the out-of-hours path: Confirm that on-call staff can actually connect at three in the morning, before the night it matters. Common mistakes: - One shared administrative account used by the whole support team. - Unattended access to clinical workstations with no consent step and no clear policy. - Assuming a night-time maintenance window exists in a service that runs continuously. - Leaving medical device controllers undefined, so faults stall while ownership is debated. - Session logs held only inside the remote access platform, with no independent copy. **Q: Is remote desktop access appropriate for clinical systems?** A: Yes, with controls. Attended consented sessions on clinician-facing machines, named operator accounts with multi-factor authentication, least privilege that separates system administration from clinical application access, and complete session logging. **Q: How do you protect patient data during remote support?** A: Let the clinician close records before the screen is shared, prefer background diagnostics over screen viewing where possible, restrict operator rights to what fixing the machine requires, and log every session against a named individual. **Q: Can medical device controllers be supported remotely?** A: Sometimes, and it depends entirely on the supplier agreement. Establish the position in writing per device type before a fault occurs, including who owns the resolution when IT is not permitted to intervene. **Q: What audit evidence should healthcare IT keep for remote sessions?** A: Named operator, target device, start and end times, whether consent was given, and the actions taken in the session, retained per your information governance policy and exported to independent central logging. In 247connect: 247connect supports this model with zero-trust access, AES-256 encryption, two-factor authentication and per-session audit logs, plus attended on-demand sessions for clinician-facing machines and background tools for the work that does not need the screen. ### Remote IT support for manufacturing, warehousing and logistics URL: /sectors/manufacturing-and-logistics Written for: IT teams supporting factories, warehouses, distribution centres and multi-site logistics operations. On a production line or in a distribution centre, an IT fault stops physical work. A scanner that will not connect halts a pick face; a terminal that will not log in stops a line. Remote support matters here because the response time is measured against throughput, and because the sites that need help are rarely the sites where IT staff are based. Key takeaways: - Downtime is measured in stopped output, so speed of first connection matters more here than almost anywhere else. - Line-side terminals, label printers and scanner base stations are the natural unattended set. - Shift patterns mean support demand does not follow office hours, and a maintenance window may be a changeover gap. - Operational technology and production control systems have their own rules, and are usually not yours to patch. - Site network quality varies enormously. Design for the worst warehouse, not the head office link. #### The cost of a stopped line In an office, a broken machine costs one person's productivity. On a line, it can idle a team, and in a distribution centre a failed scanner group can stall an entire pick wave. That difference is why response time dominates the requirements list for this sector, and why a tool that connects in seconds rather than minutes has an unusually direct value. It also changes triage. The right first question is not what is broken but what has stopped, because a low-severity technical fault on a critical terminal outranks a serious fault on a machine nobody is currently using. #### The device estate is not the usual one Alongside normal desktops there are ruggedised handhelds, vehicle-mounted terminals, label printers, scales, scanner base stations and touchscreen kiosks. Some are full operating systems that support an agent, some are appliances that do not, and knowing which is which before an incident saves a great deal of time during one. Environmental conditions matter too. Devices in cold stores, wash-down areas and dusty environments fail in physical ways that no remote session will fix, so the diagnosis often ends with dispatching a replacement rather than fixing the unit. - Line-side terminals and vehicle-mounted units: usually agent-capable, ideal unattended candidates - Handheld scanners: often managed through a separate mobile platform rather than a desktop agent - Label printers and scales: typically appliances, managed by configuration rather than remote desktop - Site servers and network gear: unattended, and the highest priority to keep reachable #### Shifts, not office hours A site running three shifts has no natural downtime. Maintenance happens in changeover gaps, planned stoppages and weekend windows, and those are agreed with operations rather than declared by IT. Remote access is what makes short windows usable, because the setup time that would be spent travelling is spent working. Out-of-hours cover also becomes far more sustainable. An on-call technician who can connect from home at two in the morning resolves faults that would otherwise wait for the day shift. #### Where IT stops and OT begins Programmable controllers, machine HMIs and production control systems usually sit outside the IT estate and under supplier or engineering ownership, often deliberately segregated from the corporate network. Attempting to bring them into a general remote access deployment causes problems rather than solving them. Draw the boundary explicitly, and make sure the service desk knows which side a device sits on. A clear handover to engineering is faster than an IT technician spending twenty minutes discovering they were never going to be able to help. #### Standing up remote support across industrial sites 1. Map devices by criticality to output: Rank by what stops when the device stops, not by device type. That ranking drives your priority model. 2. Mark the IT and OT boundary: Record which devices are production control systems under supplier ownership, so nobody wastes time on them. 3. Deploy agents to site servers and terminals first: These cover the highest-impact faults and are the most likely to be needed out of hours. 4. Validate over the worst site link: Test against your slowest, busiest warehouse connection rather than the head office network. 5. Agree windows with operations: Changeover gaps and planned stoppages, negotiated with the people who own throughput. 6. Set up on-call remote access properly: Confirm a technician can connect from home to a site terminal, end to end, before you rely on it. 7. Keep spare units at each site: Remote support diagnoses physical failure quickly. A local swap unit is what turns the diagnosis into a fix. Common mistakes: - Prioritising tickets by technical severity rather than by what has stopped producing. - Assuming warehouse wireless behaves like office wireless. - Trying to bring production control systems into a general IT remote access deployment. - No spare devices on site, so a correct remote diagnosis still leaves the line down. - Support cover aligned to office hours at a site running three shifts. **Q: Can warehouse scanners and handhelds be supported remotely?** A: Usually through a mobile device management platform rather than a desktop remote access agent. Base stations, terminals and site servers are the devices where conventional remote desktop support applies directly. **Q: How fast does remote support need to be in manufacturing?** A: Faster than in most sectors, because downtime is measured in stopped output rather than lost individual productivity. Connection time is a genuine requirement here, not a specification detail. **Q: Should production control systems be included in remote access?** A: Generally no. Operational technology is typically segregated and under engineering or supplier ownership. Define the boundary clearly so the service desk hands those faults over immediately rather than investigating them. **Q: How do you cover sites with no on-site IT?** A: Unattended access to site servers and terminals for the software faults, plus a stock of swap-out devices and a nominated local contact for the physical ones. Remote support handles the diagnosis; someone still has to swap a broken scanner. In 247connect: 247connect connects to managed devices in around eight seconds, which is the metric that matters when a terminal fault is holding up a pick wave, and unlimited operators means every technician across every shift has their own account. ### Remote IT support for law firms, accountants and professional services URL: /sectors/professional-services Written for: IT managers and outsourced IT providers supporting law firms, accountancy practices, consultancies and surveyors. In a professional services firm, the cost of an IT problem is billable time, and the sensitivity of the data is client confidentiality rather than personal data alone. Remote support is straightforward technically; what shapes it is confidentiality obligations, hard external deadlines, and a partner group that works from everywhere and expects to be unblocked immediately. Key takeaways: - Client confidentiality means the support model has to be explainable to a client, not only to an auditor. - Downtime converts directly into lost billable hours, which makes the business case unusually easy to make. - Deadline seasons concentrate demand, and capacity has to be planned around them rather than averaged. - Partners work from home, client sites, trains and hotels, so support cannot assume a corporate network. - Attended sessions with visible consent are the right default when a matter file may be open on screen. #### Confidentiality is the governing constraint A remote session on a fee earner's machine may expose privileged client material. That is a professional obligation as much as a data protection one, and it argues for attended sessions on user-facing machines, with the fee earner able to close what is open before the screen is shared. It also argues for a support model you could describe to a client without discomfort: named operators, multi-factor authentication, encrypted sessions, complete logs, and no standing invisible access to a machine where matter files live. #### The cost of downtime is easy to calculate Unlike most sectors, professional services can price an outage precisely. An hour lost by a fee earner has a known chargeable value, which makes the case for faster support tooling much simpler to write than it is elsewhere. The same arithmetic should shape triage. A fault affecting several fee earners during a deadline week is worth interrupting almost anything else for, and a support team that prioritises by ticket age rather than impact will consistently get this wrong. #### Deadline seasons Tax deadlines, filing dates, court timetables and year-end all concentrate demand into predictable peaks. Support volume rises at exactly the moment tolerance for delay is lowest, and the same peaks tend to be when everyone is working late from home. Plan for those weeks specifically: extended cover, pre-agreed escalation, and no scheduled changes anywhere near them. Remote access makes extended cover far cheaper to provide, because it does not require anyone to be in the building. - Map the firm's deadline calendar into the IT change calendar and freeze changes around it - Extend support hours for peak weeks rather than for the whole year - Pre-agree who can be called and about what, so nobody improvises during a filing deadline #### Supporting people who work everywhere Partners and consultants work from client premises, home, hotels and trains, on networks you do not control and sometimes on client guest wireless with restrictive filtering. Remote support has to function over ordinary internet connections without inbound firewall rules or a VPN being up first, because the VPN is frequently the thing that is broken. Cloud-brokered outbound access is what makes this workable. If the tool needs the corporate network to be reachable before it can help, it is unavailable in exactly the situations where it is most needed. #### A support model for a professional services firm 1. Write the confidentiality position down: Describe who can access what, under what consent, and how it is logged, in language you could send to a client. 2. Default to attended on fee earner machines: Let the user close matter files before the screen is shared. Reserve unattended access for infrastructure. 3. Make sure support works off-network: Verify you can help someone on hotel wireless with the VPN failing, because that is a routine scenario. 4. Import the deadline calendar: Freeze changes around filing and court dates, and staff those weeks deliberately. 5. Triage by impact, not by queue order: Several fee earners blocked during a deadline week outranks everything, and the calculation is easy to justify. 6. Give every technician a named account: Including any outsourced provider. Attribution is part of the confidentiality story. 7. Review third-party access quarterly: Outsourced providers and former suppliers with live credentials are the most common finding in a firm's own audit. Common mistakes: - Unattended access to fee earner machines holding privileged material, with no consent step. - A support tool that only works when the VPN is already connected. - Scheduling changes during a filing deadline because the change calendar and the firm calendar are separate. - Shared credentials with an outsourced IT provider, so sessions cannot be attributed to an individual. - Triaging strictly by ticket age when the impact difference between tickets is measured in chargeable hours. **Q: Is remote IT support appropriate for a law firm?** A: Yes, and it is standard practice. The controls that matter are attended consented sessions on machines holding matter files, named operator accounts with multi-factor authentication, encrypted sessions and complete audit logs you could show a client. **Q: How do you protect client confidentiality during remote support?** A: Use attended sessions so the fee earner can close privileged material first, restrict operator rights to what fixing the machine requires, log every session against a named person, and review third-party access regularly. **Q: How should IT handle deadline periods?** A: Freeze changes around known filing and court dates, extend cover for those specific weeks, and pre-agree escalation routes. The peaks are predictable, which means they can be planned for rather than absorbed. **Q: Can you support a partner working from a client site?** A: Yes, with a cloud-brokered tool that connects outbound over ordinary internet access. Anything that requires the corporate VPN first will be unavailable in precisely the situations where support is most needed. In 247connect: 247connect works over outbound connections without inbound firewall rules or a VPN, so a partner on hotel wireless is as supportable as someone at a desk, and every session is logged against a named operator. ### Remote IT support in financial services and regulated firms URL: /sectors/financial-services Written for: IT and operational risk teams in banks, brokers, insurers, wealth managers and other regulated financial firms. In a regulated financial firm the question is rarely whether remote support is secure, but whether you can evidence that it is. Regulators and auditors ask who can access what, how it is authorised, what is recorded and how access ends. A remote access deployment that cannot answer those questions with records is a finding waiting to happen. Key takeaways: - Remote access to production systems is privileged access, and should sit inside your privileged access controls rather than beside them. - Third-party and outsourced provider access is the area examiners probe hardest, and where most firms have gaps. - Market hours constrain change windows more tightly than most sectors realise, and remote access is what makes narrow windows usable. - Evidence beats assertion. Exportable logs, documented reviews and demonstrable offboarding are what stand up in an examination. - Operational resilience expectations mean you must show remote support still functions during a disruption, not only on a normal day. #### Treat it as privileged access Remote access into production systems gives an operator the ability to observe and change them, which places it squarely within privileged access management. The controls should therefore match the ones you already apply there: named accounts, multi-factor authentication, approval before elevated sessions, time limits, and full recording. Firms that manage remote support as a helpdesk tool rather than a privileged access channel tend to discover the mismatch during an examination, when the two sets of records fail to reconcile. - Named operator accounts integrated with the firm's identity platform - Multi-factor authentication enforced without exception - Approval and time limits for elevated or production access - Session records exported to independent, tamper-evident storage #### Third-party access is the hard part Outsourced IT providers, software vendors and specialist contractors all need access at some point, and vendor access is consistently one of the weakest areas in practice. The failure modes are familiar: a shared vendor account, access granted for a project and never withdrawn, and no record of which individual at the supplier connected. Insist on named individuals at the supplier, time-bound access tied to the engagement, and the same logging you apply internally. Make withdrawal part of contract closure rather than a task somebody remembers. #### Change control and market hours Trading and settlement timetables leave narrow windows for change, and the consequences of overrunning them are regulatory as well as operational. Remote access does not create a window, but it removes the setup and travel time that makes a narrow window unusable, and it lets a change be backed out quickly if it goes wrong. Support activity that changes configuration during a session is a change, whatever the ticket says. Make sure the support process feeds the change record rather than sitting outside it. #### Demonstrating resilience Operational resilience expectations focus on important business services continuing through disruption. Remote support is part of that story: if your technicians can only work from one office, a site-level disruption removes your ability to fix anything else. Test it rather than asserting it. A periodic exercise where support is delivered entirely from outside the office, including out-of-hours access to production, produces evidence and usually finds at least one dependency nobody had documented. #### Bringing remote access into a regulated control framework 1. Classify remote access as privileged access: Bring it under the existing framework rather than running a parallel set of controls that will not reconcile. 2. Integrate operator accounts with identity management: Provisioning and deprovisioning should follow the same joiners, movers and leavers process as everything else. 3. Name every third-party individual: No shared vendor accounts. Time-bound access tied to the engagement, withdrawn at contract closure. 4. Export session records independently: Logs held only in the tool being audited are weak evidence. Forward them to central, tamper-evident storage. 5. Connect support activity to change control: A configuration change made during a support session is still a change and needs the corresponding record. 6. Run a documented access review: Periodic re-justification of every operator and every reachable production system, with the outcome recorded. 7. Exercise off-site support: Prove support continues when the office does not, and document what the exercise found. Common mistakes: - Managing remote support outside the privileged access framework, so the two record sets never reconcile. - A shared account for an outsourced provider, which makes individual attribution impossible. - Project access to production that was never withdrawn when the project closed. - Configuration changes made in support sessions that never reach the change record. - Asserting resilience of the support function without ever exercising it. **Q: Is remote desktop access acceptable in a regulated financial firm?** A: Yes, and it is widespread. What matters is that it is governed as privileged access: named accounts, multi-factor authentication, approval for production access, complete exportable logs and evidenced periodic review. **Q: How should third-party remote access be controlled?** A: Named individuals at the supplier rather than a shared account, access scoped and time-bound to the engagement, the same session logging you apply internally, and withdrawal built into contract closure. **Q: What evidence do examiners look for?** A: Who holds access and why, how they authenticate, what each session recorded, how long records are kept, who reviewed access and when, and demonstrable removal of access for leavers and ended contracts. **Q: How does remote support relate to operational resilience?** A: It is part of how important business services keep running during disruption. If support can only be delivered from one location, that is a single point of failure, and it should be tested rather than assumed. In 247connect: 247connect provides the underlying controls this framework needs: zero-trust access, AES-256 encryption, two-factor authentication and per-session audit logging against named operator accounts. ### Remote support for managed service providers URL: /sectors/managed-service-providers Written for: Owners, service delivery managers and technical leads at managed service providers and IT support companies. For a managed service provider, remote access is not a supporting tool, it is the delivery mechanism. Margin depends on how many endpoints each technician can cover, growth depends on how quickly a new client can be onboarded, and reputation depends on never letting one client's access touch another's estate. Key takeaways: - Endpoints supported per technician is the number your margin runs on, and remote access is the main lever on it. - Tenant separation must be structural. Mixing clients in one flat device list is a breach waiting to happen. - Fast onboarding is a commercial advantage: a client productive on day one behaves very differently from one waiting a fortnight. - MSPs are a supply-chain target, and clients increasingly audit your access controls as part of theirs. - Per-technician pricing taxes growth. Fixed pricing with unlimited operators makes hiring a capacity decision rather than a cost decision. #### The economics An MSP's profitability is largely a function of how many endpoints one technician can look after. Every minute spent travelling, waiting for a client to be available, or navigating between tools is margin removed. Remote access attacks all three, which is why tooling decisions here have a direct commercial consequence rather than an operational one. Connection speed is worth more than it appears. A technician handling thirty sessions a day loses meaningful time to a tool that takes a minute to connect, and that time compounds across a team every working day of the year. #### Keeping clients separate Multi-tenancy is the requirement that distinguishes MSP tooling from internal IT tooling. Each client's devices should be grouped distinctly, technician access should be assignable per client, and no interface should ever present one client's machines alongside another's in a way that invites a mis-click. This is a client conversation as much as a technical one. Being able to describe how separation works, and how you would evidence that nobody outside the assigned team connected to their estate, is increasingly part of winning the account. - Device grouping per client, enforced rather than conventional - Technician assignment scoped per client, reviewed when people change teams - Audit logs filterable per client, so you can produce their records on request - Clear separation in the interface, to make a wrong-client connection difficult #### Onboarding speed as a differentiator The first two weeks of a new contract set the tone. A provider that can deploy agents on day one and begin resolving the backlog immediately looks entirely different from one still arranging site access a fortnight in. Build a repeatable onboarding package: a silent-install deployment key per client, a standard device grouping, a standard technician assignment, and a documented handover. What takes a week the first time should take an afternoon by the fifth client. #### You are part of your clients' supply chain Attacks on managed service providers as a route into their clients are well documented, and remote access tooling is the obvious target because it holds standing access to many estates at once. Clients know this, and their own security questionnaires increasingly ask about it directly. Treat your own controls as a sales asset. Named technician accounts with multi-factor authentication, per-client scoping, exportable logs, and a documented offboarding process are answers that shorten procurement as well as reduce risk. #### Building an MSP remote support operation 1. Standardise onboarding into a package: Deployment key, device grouping, technician assignment and handover documentation, repeatable per client. 2. Enforce tenant separation structurally: Grouping and scoped access, not a convention that relies on technicians reading device names carefully. 3. Give every technician a named account: Including junior and temporary staff. Shared accounts fail every client security questionnaire you will receive. 4. Make logs exportable per client: Being able to hand a client their own session records on request is both an audit control and a sales asset. 5. Measure endpoints per technician: Track it as a core operational metric. It tells you whether tooling changes are actually paying for themselves. 6. Automate the repetitive work: Anything a technician does the same way on every endpoint should be scripted, so remote sessions are spent on real problems. 7. Document offboarding for clients and staff: Agent removal when a contract ends, account removal when a technician leaves, both as process rather than memory. Common mistakes: - A single flat device list across all clients, making a wrong-client connection a matter of time. - Shared technician logins, which fail client security reviews and destroy attribution. - Per-technician licensing that makes every new hire a budget negotiation. - Agents left in place after a contract ends, leaving you with access you no longer have a basis for. - Onboarding reinvented for every client instead of packaged once. **Q: What should an MSP look for in remote support software?** A: Multi-tenant separation with per-client scoping, fast connection times, silent agent deployment, named technician accounts with multi-factor authentication, exportable per-client audit logs, and pricing that does not scale with headcount. **Q: How do MSPs keep client estates separate?** A: Structurally: device grouping per client, technician access assigned per client, and audit logs that can be filtered and produced per client. Separation that depends on technicians reading carefully is not separation. **Q: Why does per-technician pricing matter to an MSP?** A: Because it taxes growth. Every new hire becomes a licence negotiation, and the common workaround, sharing logins, breaks attribution and fails client security questionnaires. Fixed pricing with unlimited operators avoids both. **Q: How quickly can a new client be onboarded?** A: With a packaged deployment key and standard grouping, agents can be pushed on the first day and support can begin immediately. The limiting factor is usually the client's own deployment tooling, not the remote access setup. In 247connect: 247connect suits this model directly: unlimited operators on fixed pricing so hiring is not a licensing event, silent agent deployment for fast client onboarding, and per-session audit logs you can produce for a client on request. ### Remote access for IT managers: building the case and running it well URL: /sectors/for-it-managers Written for: IT managers and heads of IT responsible for support tooling, budget and governance. As an IT manager you are usually not the person running the sessions. Your job is to justify the spend, choose something the team will actually use, put governance around it that survives an audit, and prove afterwards that it improved something measurable. Each of those is a different piece of work. Key takeaways: - Build the case on avoided travel and reduced resolution time. Both are measurable before and after. - Licensing model matters as much as features, because it determines whether your team shares logins. - Governance has to exist before rollout. Retrofitting policy onto a deployed tool is much harder. - Track first-contact resolution and mean time to resolve, not session counts. Volume is not value. - Adoption fails on friction. If it is slower than the technician's current habit, they will keep the habit. #### Quantifying the case The strongest arguments are the concrete ones. Count the site visits your team made last quarter and estimate what proportion could have been handled remotely. Multiply by travel time and cost. Then look at mean time to resolve for tickets that required physical attendance versus those that did not. Those two numbers usually carry a business case on their own. Add the second-order effects but do not lead with them: less time travelling means more time on project work, out-of-hours cover becomes affordable, and recruitment widens because technicians no longer need to live near every site. - Site visits per quarter and the proportion avoidable - Travel time and cost per visit, including the productivity lost in transit - Mean time to resolve, split by whether attendance was required - Out-of-hours incidents currently deferred to the next working day #### Choosing, without being sold to Feature lists converge quickly, and most tools will demonstrate well. The differences that matter in daily use are connection speed, whether unattended and attended access are both properly supported, how agents deploy at scale, what the audit trail actually contains, and how licensing behaves when your team grows. Test with your own technicians on your own network, including the awkward sites. A tool that performs beautifully in a vendor demonstration and poorly over your worst branch link is the wrong tool, and you will only discover that in a real trial. #### Governance before rollout Decide the policy while you still have leverage: which device categories can be unattended, who may connect to what, how consent works on user-facing machines, what is logged and for how long, and how access is removed. Writing this after deployment means negotiating with established habits. Communicate it to staff too. People discovering by accident that IT can reach their machine produces a trust problem that is disproportionate to the actual capability, and entirely avoidable with one clear message up front. #### Measuring whether it worked Pick the metrics before you deploy so you have a baseline. First-contact resolution, mean time to resolve, and site visits per month are the three that reflect the change most directly. Session count is a vanity metric: it goes up because the tool is convenient, which tells you nothing about outcomes. Review at ninety days rather than a year. It is early enough to correct an adoption problem while the rollout is still recent, and it produces the evidence you will want at the next budget round. #### Running a remote access programme 1. Baseline before you change anything: Record site visits, resolution times and first-contact resolution now, or you will have no way to demonstrate improvement. 2. Write the governance position first: Device categories, consent, logging, retention and offboarding, agreed before a single agent is deployed. 3. Trial with your own team on your own network: Include the worst site link and the awkward device types. Vendor demonstrations never include those. 4. Check the licensing model against your growth plan: Per-technician pricing pushes teams towards shared logins. Confirm the model still works at the team size you expect in two years. 5. Tell staff before rollout, not after: One clear message about what IT can and cannot do prevents a trust problem that is hard to undo. 6. Deploy in waves and fix friction fast: Adoption is decided in the first fortnight. If it is slower than the old habit, technicians will revert. 7. Review at ninety days against the baseline: Report the change in resolution time and site visits. That is the evidence for the next budget conversation. Common mistakes: - No baseline, so improvement can be claimed but not shown. - Policy written after deployment, when habits are already established. - Choosing on feature lists rather than on connection speed and licensing behaviour. - Rolling out silently and letting staff discover the capability by accident. - Reporting session volume as if it were an outcome. **Q: How do I build a business case for remote support software?** A: Count avoidable site visits and their cost, and compare mean time to resolve for tickets needing attendance against those that do not. Those two figures usually carry the case. Treat freed project capacity and affordable out-of-hours cover as supporting benefits. **Q: What should I evaluate when comparing remote support tools?** A: Connection speed on your worst network, proper support for both unattended and attended access, silent agent deployment at scale, what the audit trail actually records, and how licensing behaves as the team grows. **Q: What governance does remote access need?** A: A documented device categorisation, named accounts with multi-factor authentication, a consent model for user-facing machines, defined logging and retention, periodic access review, and offboarding tied to your leavers process. **Q: Which metrics show remote support is working?** A: First-contact resolution, mean time to resolve and site visits per month, measured against a pre-deployment baseline. Session counts rise simply because the tool is convenient and prove nothing. In 247connect: 247connect is priced on fixed annual subscriptions with unlimited operators, which removes the licensing pressure that pushes teams towards shared logins, and a 14-day trial lets you run the baseline comparison on your own network before committing. ### Remote support for helpdesk and service desk teams URL: /sectors/for-helpdesk-teams Written for: Service desk analysts, team leaders and anyone designing helpdesk working practices. A service desk with good remote access resolves more at first contact, escalates less, and spends less time asking users to describe what they can see. Getting there is mostly about working practice: when to connect, when not to, how to hand a session between tiers, and how to behave on somebody else's machine. Key takeaways: - Connecting is not always the right first move. A question sometimes resolves in thirty seconds what a session takes ten minutes to reach. - Background diagnostics let you investigate without taking someone's screen, which is faster and less intrusive. - First-contact resolution is the metric remote access moves most, and the one worth designing around. - Warm handovers between tiers, with the session context passed on, prevent the user repeating themselves. - Etiquette is operational, not cosmetic. Users who trust the process report problems earlier and more accurately. #### Knowing when to connect The reflex to start a session immediately is often counterproductive. Plenty of tickets are answered by a question: what changed, what does the message say, does it happen on another machine. Establishing that first frequently resolves the call outright, and where it does not, it means you connect already knowing what to look at. Connect when you need to see state you cannot get a reliable description of, when the fix involves several steps you would otherwise dictate, or when the user is not confident enough to be talked through it. Those three cover most legitimate cases. #### Investigate without taking the screen Where the tooling supports background access, use it. Checking services, disk space, event logs and installed updates without interrupting the person working is faster for you and invisible to them, and it means that when you do take the screen you already know where you are going. This reframes the whole call. Diagnose quietly, form a hypothesis, then take control only for the part that needs the desktop. - Service state and recent failures - Free disk space and recently installed updates - Event log entries around the reported time - Network configuration and connectivity checks #### Handing over between tiers The most frustrating experience for a user is explaining the same problem three times. When escalating, pass what you have found, not just what was reported: the symptoms confirmed, the checks already run, the things ruled out, and the session record. Where the tool allows a second operator to join a live session, a warm handover is better still. The user stays in one conversation, the second-line technician arrives with context, and nobody starts again from the beginning. #### Session etiquette Announce yourself before taking control, describe what you are about to do, and narrate as you work. Avoid opening anything not related to the fault. If you must look at something personal, such as a document that is failing to open, say so first. End the session clearly and confirm out loud that access has stopped. Then send a short written summary of what changed. All of this takes under a minute in total, and it is the difference between a team users call early and a team they avoid until the problem is severe. #### A working pattern for remote support calls 1. Ask before connecting: What changed, what exactly does the message say, does it happen elsewhere. Sometimes that ends the call. 2. Run background checks first: Gather state without interrupting them, so you connect with a hypothesis rather than to start looking. 3. Announce before taking control: Say what you are going to do and confirm they are ready. Never simply start moving their mouse. 4. Narrate while you work: It reduces anxiety, and it teaches the user enough to sometimes prevent the next call. 5. Escalate with findings, not just symptoms: Pass the checks run and the things ruled out, so second line does not repeat your first ten minutes. 6. Close visibly and summarise in writing: Confirm access has ended, then send a short note of what changed for the user's records. 7. Feed recurring problems back: The same fault across many users is a problem record, not twenty incidents. Remote access makes the pattern visible early. Common mistakes: - Connecting immediately on every ticket, including the ones a question would have solved. - Taking control without warning, which is the fastest way to make a user uneasy. - Escalating a bare symptom description, so the user explains everything again. - Browsing around the machine beyond what the fault requires. - Ending a session without confirming it, leaving the user unsure whether you can still see their screen. **Q: How does remote access improve first-contact resolution?** A: It removes the dependency on the user accurately describing what they see, and it lets the analyst act rather than dictate. Both mean more tickets close on the first call instead of being escalated or scheduled. **Q: Should a helpdesk connect remotely on every ticket?** A: No. Some faults resolve faster with a question. Connect when you need to see state you cannot get described reliably, when the fix has several steps, or when the user is not confident being talked through it. **Q: What is good remote session etiquette?** A: Announce before taking control, explain what you are doing as you go, stay within what the fault requires, end the session visibly, and follow up in writing with what changed. **Q: How should sessions be handed between support tiers?** A: Pass findings rather than symptoms: what was confirmed, what was checked, what was ruled out, plus the session record. A live warm handover into the same session is better still where the tool supports it. In 247connect: 247connect gives service desks both halves of this pattern: background tools such as PowerShell and Task Manager for quiet diagnosis, and fast consented sessions when you do need the screen, with unlimited operators so the whole desk has named accounts. ## Guides ### Remote desktop software that just works: how 247connect connects in about 8 seconds URL: /remote-desktop-software Remote desktop software lets a support technician see and control another computer over the internet as if they were sitting in front of it. 247connect is a cloud-based remote desktop and remote support tool that establishes a session in roughly eight seconds, works on managed and on-demand devices, and includes unlimited operators on fixed, transparent pricing. - Typical connect time: ~8 seconds - Operators included: Unlimited - Concurrent sessions per user: 5 included - Free trial: 14 days, no credit card #### What remote desktop software actually does Remote desktop software creates an encrypted channel between two machines: the technician's device and the remote endpoint. Screen data travels one way, keyboard and mouse input travels the other, and a control layer carries extras such as file transfer, chat, and diagnostics. Everything a technician would do standing at the desk, they do from wherever they happen to be. The category splits into two working patterns. Unattended or managed access means an agent is installed on the endpoint so it can be reached at any time, including when nobody is logged in. On-demand or attended access means the end user runs a small one-time application when they need help, and access ends when the session does. 247connect supports both patterns from the same console. - Screen sharing and full remote control of the endpoint - Drag-and-drop file transfer in both directions - Real-time chat with the person at the other end - Built-in tools including PowerShell and Task Manager - Reboot and automatically reconnect without losing the session - Hardware and system inventory for the connected device #### Why connection speed is the metric that decides adoption Support teams rarely abandon a tool because of a missing feature. They abandon it because the first thirty seconds of every ticket are painful. If a session takes a minute to negotiate, times out, or drops on a weak connection, the technician calls the user back and the queue grows. 247connect is built around a fast handshake: a typical session comes up in around eight seconds, every time. Multiply that by the number of sessions a busy service desk opens in a day and the saving stops being cosmetic. Faster sessions mean shorter calls, calmer users, and more tickets closed before lunch. #### Who uses it 247connect is deliberately industry-agnostic. It is used by internal IT teams, managed service providers, education and public sector organisations, retail and hospitality estates with distributed hardware, and small businesses with a single part-time technician. The common thread is not a sector — it is people and devices in different places that need to be supported quickly. Because pricing is fixed and operators are unlimited, the software scales the same way for a two-person team as it does for a national estate. Nobody has to ration licences or plan around per-technician seat counts. #### How it compares with heavyweight RMM platforms Remote monitoring and management suites bundle patching, scripting, alerting, asset management, and remote access into one large product. That breadth suits some organisations and overwhelms many others: long onboarding, complex dashboards, and a licence model that grows unpredictably. 247connect takes the opposite position. It concentrates on doing remote support quickly and securely, with a short setup and an interface a new starter can use on day one. If you need remote access rather than an entire management platform, the simpler tool tends to win on both cost and adoption. **Q: What is remote desktop software used for?** A: It is used to view and control a computer from another location — most often for IT support, troubleshooting, software installation, configuration changes, and accessing work machines from elsewhere. **Q: How quickly does 247connect connect to a device?** A: A typical 247connect session is established in around eight seconds, on both managed and on-demand devices. **Q: Do I need to pay per technician?** A: No. 247connect includes unlimited operators on fixed, transparent pricing, and every user can run up to five concurrent connections at no extra cost. **Q: Can I try it before buying?** A: Yes. There is a 14-day free trial and no credit card is required to start it. ### Unattended remote access for managed devices: supporting machines nobody is sitting at URL: /unattended-remote-access Unattended remote access means an endpoint carries a permanently installed agent so a technician can connect at any time without anyone present. In 247connect these are called managed devices, and they are the right fit for servers, kiosks, digital signage, shared workstations, and any machine that needs maintenance out of hours. - Access model: Always-on agent - Best for: Servers, kiosks, fixed estates - Out-of-hours work: No user required - Session recovery: Reboot and reconnect #### What makes a device 'managed' A managed device has the 247connect agent deployed on it once, after which it appears in your device list and can be reached whenever it is powered on and online. There is no code to read out, no user to talk through a download, and no need for anyone to be at the keyboard. Deployment scales the way you would expect: technicians can install the agent by hand on a handful of machines, or roll it out across servers and workstations as part of a standard build. Once deployed, it stays available. - Servers and virtual machines that never have a user in front of them - Kiosks, signage, and point-of-sale hardware in public spaces - Shared workstations in labs, classrooms, and workshops - Home-worker laptops that need patching outside office hours - Remote sites with no on-premises IT presence #### Reboot, reconnect, and finish the job The classic failure mode of unattended access is the restart. A technician applies an update, the machine reboots, and the session dies — leaving a server that may or may not come back with someone hours away from it. 247connect handles the restart as part of the session: reboot the endpoint and the connection re-establishes automatically once it is back. Maintenance that used to need a site visit or an on-site pair of hands becomes an ordinary remote task. #### Knowing the machine before you connect Unattended access is more useful when it comes with context. 247connect surfaces hardware inventory for managed devices, so a technician can see details such as storage and memory before opening a session. That turns reactive support into something closer to preventative maintenance. A disk quietly filling up or a machine consistently short of memory is visible in the device list rather than discovered when it finally fails on a Monday morning. #### Choosing between managed and on-demand Use managed devices for hardware you own and expect to support repeatedly. Use on-demand access for one-off help with a person who is present, and for machines you do not control — a customer's laptop, a contractor, a member of the public. Most organisations run both. The important thing is that the two models live in the same tool, with the same interface and the same security controls, so the technician does not switch products halfway through a shift. **Q: What is unattended remote access?** A: It is remote access to a device through a permanently installed agent, so a technician can connect without anyone being present at the remote machine. **Q: Can I restart a managed device during a session?** A: Yes. 247connect supports reboot and reconnect, so the session re-establishes automatically once the device comes back online. **Q: Can I see device hardware details before connecting?** A: Yes. Managed devices expose a hardware inventory including details such as storage and memory, which helps identify small issues before they escalate. ### On-demand remote support: helping a user in minutes without installing anything permanent URL: /on-demand-remote-support On-demand remote support is attended access: the person at the remote machine starts a lightweight one-time session, the technician connects, fixes the problem, and access ends when the session closes. It is the fastest way to help someone whose device you do not manage. - Access model: One-time, attended - Install required: No permanent agent - Access after session: Ends immediately - In-session tools: Chat, file transfer, diagnostics #### The shape of an on-demand session The user runs a small application, the technician connects, and the two of them work through the problem together. Nothing stays behind on the machine afterwards, and the technician has no route back in once the session ends. For anyone worried about permanent access to a personal or customer-owned device, that boundary matters. The design goal is that a non-technical person can get to a working session on the first attempt while on a phone call. Fewer steps, fewer prompts, fewer opportunities for the call to stall before any support has happened. #### Working alongside the user, not around them Attended support has an advantage unattended access does not: the person who saw the problem is right there. Real-time chat keeps a written record of instructions, links, and credentials-free guidance, which is useful when the line is poor or the user does not share your first language. Drag-and-drop file transfer removes the awkward part of the call — getting a driver, log file, installer, or configuration export from one side to the other without email attachments or a cloud share the user cannot reach. - Walk a user through a fix while they watch, so they learn it - Collect logs and diagnostics without dictating file paths - Push an installer or patch straight to the desktop - Use PowerShell and Task Manager for deeper troubleshooting - Close the session and leave no standing access behind #### Where on-demand access earns its keep Service desks use it for staff on unmanaged or personal hardware. Managed service providers use it for prospective clients and for one-off jobs that never justify an agent rollout. Software vendors use it to troubleshoot a customer's environment during a support call. Charities, schools, and community services use it to help people who are not technical and are not in the building. In each case, the value is the same: no procurement, no deployment project, no waiting. Someone needs help now and you can be on their screen in under a minute. #### Keeping attended support accountable Short-lived access should still be governed access. Sessions run over encrypted connections, operator accounts are protected by two-factor authentication, and audit logs record what happened, so a quick fix is still a traceable event. That combination — low friction for the user, full accountability for the organisation — is what separates a proper support tool from ad-hoc screen sharing over a chat app. **Q: What is on-demand remote support?** A: It is an attended remote session started by the person at the remote device using a one-time application, with no permanently installed agent and no access after the session ends. **Q: Does the user need technical knowledge to start a session?** A: No. The flow is designed so a non-technical user can start a session while on the phone with a technician. **Q: Can I transfer files during an on-demand session?** A: Yes. Drag-and-drop file transfer works in both directions, alongside real-time chat and tools such as PowerShell and Task Manager. ### Secure remote access: zero-trust, AES-256 encryption, two-factor authentication and audit logs URL: /secure-remote-access Remote support software is, by definition, a route into every machine you support — so its security posture is the whole product. 247connect is built around zero-trust access with AES-256 encryption, two-factor authentication, and audit logs, so remote sessions are both protected in transit and accountable afterwards. - Access model: Zero-trust - Encryption: AES-256 - Account protection: Two-factor authentication - Accountability: Audit logs #### Why remote access is a security decision, not an IT convenience A remote support tool has, at some point, privileged access to servers, finance workstations, and the laptop of everyone in the organisation. If it is weak, it is the shortest path an attacker will ever find into the estate. Security teams are right to treat the choice as seriously as they treat the firewall. The practical questions are consistent: how is the session encrypted, how are operator accounts protected, who can reach which devices, and what record exists afterwards. Any vendor should answer all four without hedging. #### Zero-trust access in plain terms Zero-trust means no device or operator is trusted simply because of where it sits on the network. Every connection is authenticated and authorised on its own merits, rather than being waved through because it originated inside the perimeter. For a support team, the day-to-day effect is that access follows the operator's identity and permissions, not their location. Someone working from home, from a client site, or from an airport gets exactly the same access controls as someone at head office. #### Encryption, authentication, and audit working together AES-256 encryption protects session traffic so screen data, keystrokes, and transferred files cannot be read in transit. Two-factor authentication protects the operator account itself, which is the credential an attacker would most like to steal. Audit logs answer the question every incident review asks: who connected, to what, and when. Each control covers a gap the others leave open. Encryption without strong authentication protects the wire but not the account. Authentication without logging stops most attacks but leaves you unable to prove what happened. 247connect includes all three as standard rather than as security add-ons. - AES-256 encryption on remote sessions - Two-factor authentication on operator accounts - Audit logs recording session activity - Zero-trust access model for every connection - Attended sessions leave no standing access behind #### Questions worth asking any remote support vendor Use these when comparing tools, including this one. Is encryption applied to every session by default or only on higher tiers? Is two-factor authentication available to all users at no extra cost? Can you export an audit trail for a specific device or operator? Does unattended access require an explicit agent deployment you control? Are security features part of the base product or priced as extras? A vendor whose security depends on your pricing tier is telling you something about its priorities. Baseline protections should be baseline. **Q: Is 247connect encrypted?** A: Yes. 247connect uses AES-256 encryption for remote sessions, alongside two-factor authentication and audit logs. **Q: What does zero-trust access mean for remote support?** A: It means no connection is trusted based on network location. Every session is authenticated and authorised against the operator's identity and permissions. **Q: Can we prove who accessed a device?** A: Yes. Audit logs record session activity so access can be reviewed after the fact for compliance or incident investigation. ### Inside a remote session: file transfer, chat, PowerShell, Task Manager and hardware inventory URL: /remote-support-tools Screen control is only the beginning of a support session. The tools around it — file transfer, chat, a shell, a process view, a hardware inventory, and a reliable restart — are what decide whether a ticket closes in one session or three. - File transfer: Drag and drop, both ways - Communication: Real-time in-session chat - Command line: PowerShell - Diagnostics: Task Manager, hardware inventory #### Drag-and-drop file transfer Most tickets involve moving something: a driver, an installer, a configuration file, a log bundle for escalation. Doing that through email or a cloud share adds minutes, attachment limits, and a user who cannot find their downloads folder. In 247connect, files move by dragging them into the session in either direction. The technician pulls logs out and pushes fixes in without leaving the window they are already working in. #### Real-time chat that survives a bad phone line In-session chat is not a replacement for talking to people — it is what you use when the audio is poor, when you need to send an exact string, or when the user needs to keep a note of the steps after you have gone. It also keeps the conversation attached to the session rather than scattered across email threads and instant messages that nobody can find during a later review. #### PowerShell and Task Manager for real troubleshooting Clicking through a graphical interface at someone else's screen resolution is slow. A command line is faster and more precise, and PowerShell is available directly in the session for scripted checks, service restarts, and configuration changes. Task Manager covers the other half of the job: seeing what is actually consuming the machine, ending a stuck process, and confirming that a service came back after a change. - Run scripted diagnostics instead of clicking through dialogs - Restart services without disturbing the user's work - Identify runaway processes and memory pressure quickly - Confirm a fix held before you close the session #### Reboot, reconnect, and hardware inventory A restart is often the last step of a fix and historically the point where a remote session falls over. Reboot and reconnect means the session comes back on its own, so the technician can verify the result rather than hope for the best. Hardware inventory rounds it out by giving visibility into the device itself — storage, memory, and system details — which helps spot the small problems that turn into major ones if nobody is watching. **Q: Can I transfer files during a remote session?** A: Yes. 247connect supports drag-and-drop file transfer in both directions during a session. **Q: Does 247connect include command-line access?** A: Yes. PowerShell and Task Manager are available as built-in tools within a session. **Q: What happens if the remote machine restarts?** A: 247connect supports reboot and reconnect, so the session re-establishes automatically after the device comes back online. ### Remote support for IT teams and MSPs: unlimited operators, concurrent sessions and predictable cost URL: /remote-support-for-it-teams The licence model of a remote support tool quietly decides how your team works. Per-technician seats and paid concurrency create queues and rationing. 247connect includes unlimited operators, allows every user five concurrent connections, and prices predictably so capacity is not something you have to budget for mid-year. - Operators: Unlimited, no per-seat fee - Concurrency: 5 sessions per user included - Pricing: Fixed and transparent - Trial: 14 days, no credit card #### Per-technician licensing changes team behaviour When seats cost money, organisations buy fewer than they need. Apprentices share a login. The out-of-hours engineer borrows someone else's account. A second-line specialist who could resolve a ticket in two minutes is locked out because all the seats are in use. The cost never shows up on an invoice, but it shows up in resolution times and in an audit trail that no longer identifies who actually did the work. #### Unlimited operators and included concurrency 247connect includes unlimited operators, and all of them can be active at the same time. Each user can hold up to five concurrent connections, which matters for anyone running a change across several servers or comparing two machines side by side. In practice that means everyone who touches support gets their own account: first line, second line, the field engineer, the apprentice, the manager who occasionally covers a shift. Accountability improves as a side effect, because every session belongs to a real person. - Give every technician their own named account - Run changes across several servers in parallel - Cover out-of-hours shifts without borrowed logins - Onboard new starters without a procurement conversation #### Predictable cost at renewal Rising renewal costs are one of the most common reasons teams change remote access vendor. A price that grows with headcount, with concurrency, or simply because the renewal date arrived makes multi-year planning guesswork. Fixed, transparent pricing removes that variable. You know what remote support costs next year, and adding a technician does not change the answer. #### What to check before you switch Run the trial with your real workload rather than a demo scenario. Connect to your slowest site and your worst network, not the machine on the next desk. Time the handshake honestly across a working day. Check that unattended deployment fits your existing build process. Confirm that two-factor authentication and audit logs apply to every account rather than a premium tier. Then compare the total: licences, concurrency add-ons, support, and the renewal uplift you have been absorbing. The 14-day free trial needs no credit card, so the comparison costs nothing but attention. **Q: How many technicians can use 247connect?** A: Unlimited operators are included, and all users can be active at the same time. **Q: How many devices can one user connect to at once?** A: Each user can hold up to five concurrent connections, included at no extra cost. **Q: Is there a free trial?** A: Yes — a 14-day free trial with no credit card required. ## Citation This content may be quoted and cited by search engines and AI assistants. When referencing 247connect, link to the official website: https://www.247connect.cloud/