Remote control

Take control of any customer device in seconds, with no VPN and without asking anything of the person on the other end.

Access is unattended: the technician connects when they need to, and nobody has to accept anything on the remote machine. That is what lets you fix a server at three in the morning when there is nobody sitting at it. For exactly that reason, who can reach which machine is controlled from the console, and every attempt is recorded.

Where it lives

You have three places to click Connect:

• Devices, on each machine's row in the list.
• The device record, in the header.
• The Screen Wall, on each screen's tile.

On a phone, the list button does not appear. You have to open the device record.

What you need first

• The Remote control permission. Without it the button is not shown.
• The KairosLink viewer installed on your PC. You install it once per machine of yours, not per customer device.
• The device has to be online and have its credential. If either is missing, the button is greyed out.
• A Windows or macOS machine. There is no remote desktop on Linux.

If the device is a Mac

macOS requires the user of the Mac to grant three system permissions before the screen can be seen:

They are granted in System Settings, Privacy & Security. There is no way to grant them remotely: macOS reserves that decision for whoever is sitting at the machine. The session agent asks the user for them on the Mac.

Without them the device is still managed, but the screen cannot be seen. It is covered in detail in the Install the macOS agent guide.

Connecting for the first time

1. Go to Devices.
2. If you have never installed the viewer on this PC, use the Install viewer link at the top and run the installer.
3. On the device row, click Connect.
4. The button changes to Generating and then to Opening viewer.
5. The viewer opens on its own and the session starts.

If the viewer was not installed, after two seconds you get the The viewer is not installed notice with a download button.

One detail that saves frustration: that notice has a link saying "I installed it, retry the connection". Do not use it. The connection permit lives for 60 seconds and an installer takes longer than that, so the retry goes out with an expired permit. After installing the viewer, close the notice and click Connect again.

How the connection travels

The viewer tries three paths, in this order, and keeps the first one that works:

There is nothing to configure: the choice is automatic. The viewer shows you in its bar which of the three the session ended up on, so you can check it yourself rather than take our word for it.

Falling back to the relay is normal and frequent on residential networks across Latin America, where the provider blocks direct connections. A session going through the relay is not a failure.

Who can reach what

By default, any technician in your organization can reach any device in your organization. That is permissive mode and it is how every new account starts.

If you need to narrow it, the control is under Settings, Security section, Device access card.

The four capabilities

What you control is not "in or out", but what each technician can do on each machine. They are grouped by risk:

The two modes

Permissive. With no rules, the technician can do everything. Deny rules cut things back.

Restrictive. With no rules, the technician can do nothing. Allow rules open things up.

Before you switch to restrictive, the screen tells you how many technicians would lose access immediately. Read it: the change is instant for everyone.

How rules are resolved

When several rules apply to the same device, they win in this order:

1. The Owner always passes. Rules do not apply to them.
2. Deny beats allow when both have the same priority.
3. The most specific wins: device, then AD group, then organizational unit, then customer, then all devices.
4. Among rules of the same scope, the lowest priority number wins.
5. If the device's AD group or organizational unit cannot be determined, that rule does not apply. The system does not guess.

An Administrator is not exempt. Unlike the Owner, rules do apply to an Admin. The screen says so, but it is worth keeping in mind when designing your scheme.

Restricting a technician to certain devices

With the organization in permissive mode:

1. Settings, Security section, Device access.
2. In the technicians table, three-dot menu, View rules.
3. Add a Deny rule scoped to All devices, ticking the capabilities you want to close.
4. Add an Allow rule for each device they should reach.

The most specific wins, so the allow rules override the general deny.

Every mode change and every rule added or removed is written to the security audit, with who did it and when.

A technician cannot see a device they should see

First, something important: a device the technician has no capability over does not appear in their list at all. Not crossed out, not disabled: absent. And the automatic refresh applies the same filter, so it cannot be spotted through the browser console either.

Check this in order, which is the order the system decides in:

1. Are they the Owner? Then there is nothing to investigate, they always pass.
2. Do they have the Remote control permission? Without it there is no connection, even if the rules allow it.
3. What mode is the organization in? In restrictive mode with no rules, the technician sees nothing. That is expected.
4. What rules do they have? Open their rules and read them with the criteria above.
5. Are there AD group or organizational unit rules? If the device is not matched to Active Directory, those rules are skipped and the outcome changes.
6. Check the audit filtered by that technician and the Denied state. Every blocked attempt leaves a row.

If the device is visible but the Connect button is greyed out, this is not a permissions problem: it is the device. It is offline or missing its credential.

Reviewing who connected to what

Side menu, Security, Remote sessions. Requires the Manage devices permission.

The screen gives you who, which device, which customer and when, with filters by date range, technician, customer, device and state. Export CSV downloads the whole filter, not just the page you are looking at.

Each device record also shows its recent sessions, with a link to the audit already filtered to that machine.

The states

Error and Denied are kept separate on purpose and are coloured differently: Denied is red. An administrator seeing "denied" has to understand immediately that someone tried to reach somewhere they should not, and not confuse it with a badly enrolled device.

About duration

The duration column says Not confirmed, and that is accurate.

The console records the start of the session, not the close. It knows the start with certainty because the viewer asks the console for permission to begin. That is why you will not see a number, and not a dash either: a dash would read as zero.

We do not estimate duration from the permit expiry or by any other means. In an audit, an invented number is worse than a missing one.

For the same reason, a row in Started does not mean "connection live right now": it means it began. The console does not know whether it is still open.

Common errors

The Connect button is greyed out. The device is offline or missing its credential. This is not a permissions problem.

"The viewer is not installed" but it is installed. The detection is a two-second heuristic and sometimes gets it wrong. Close the notice and click Connect again.

I click Connect and nothing happens. The connection permit lives 60 seconds. If the viewer was slow to open, click Connect again to request a fresh one.

I click the button on the Screen Wall and nothing happens. The Screen Wall does not report blocked access. If you suspect that is the cause, try from the Devices list, where the button greys out and the reason is visible.

A technician says a device "disappeared". It did not disappear: they stopped having capabilities over it. Check their access rules.

I connect to a Mac and the screen does not show, or the keyboard and mouse do not respond. System permissions are missing on the device. Check the three of them in System Settings, Privacy & Security. The user of the Mac grants them, not you.

Frequently asked questions

Which systems can I take remote control of? Windows and macOS. There is no remote desktop on Linux.

Does the person using the device have to accept anything? No. Access is unattended. That is why the console controls who can reach what, and why every attempt is audited. On a Mac there is a one-time exception: the three system permissions are granted by the user of the device before the first connection, not on every session.

How long does the connection permit live? 60 seconds. It is single use.

Can I cut a session from the console? No. The console has no way to close a live session.

Can I see whether a session is open right now? No. The console knows when it started, not whether it is still alive.

How long did a session last? Duration is not recorded. See the explanation above.

Which path did a session take, LAN, peer to peer or relay? The connection path is visible in the viewer, not in the audit: the viewer shows it in its bar while you are connected.

I revoke a technician's access while they are connected. Does it cut off? No. Rules are evaluated when the connection permit is requested. Whoever is already in stays in until they close the window.

Can I connect from a phone? Not from the list: the button is not in the mobile view. Open the device record.

Can an audit row be deleted? No. It is evidence, and by design it is not deleted.

How many rows does the CSV export? Twenty thousand. If you need more, split the date range.