Remote access
/admin/remote to configure, and a button on each device
page. No module gate: this is available on every plan.
Plugboard does not ship a remote control product and is not going to. What it does is put your existing one (ScreenConnect, TeamViewer, AnyDesk, Splashtop, NinjaOne, an RMM web console, plain Remote Desktop) on the device page with the right machine already selected, and write down who started a session and on whose device.
What Plugboard does and does not hold
Section titled “What Plugboard does and does not hold”It assembles a link and records the intent. That is all.
It never carries the session, never proxies a screen, and never holds a credential that could control a machine. Your own tool still signs the technician in and still decides what they may do. If your remote tool is switched off, nothing here reaches anybody’s device.
Configuring a target
Section titled “Configuring a target”Admin, Remote access. A target is a link with the device’s details substituted in.
| Field | |
|---|---|
| Label | What the button says: Remote in, ScreenConnect |
| URL template | The link, with placeholders |
| Scheme | Web console opens in a tab; App hands the URI to an installed application |
| Device type | Optional. Show this target only for laptops, or only for iPads |
| Campus | Optional. Show this target only at one campus |
| Notify the person using the device | On by default. See below |
| Enabled, rank | Whether it appears, and in what order |
Worked examples:
https://your-console.example.com/devices?search={serial}teamviewer10://control?device={mdmId}anydesk:{assetTag}rdp://full%20address={hostname}The placeholders
Section titled “The placeholders”A closed list, on purpose. An open substitution, “any field of the device record”, would eventually let a template name a column that should not leave the database, and the URL it built would carry it into a third party’s access log.
| Placeholder | |
|---|---|
{serial} |
The serial number |
{assetTag} |
Your asset tag |
{model} |
The model |
{hostname} |
The hostname |
{mdmId} |
The MDM’s own id for the device |
A template must contain at least one. A link that is the same for every device is a bookmark, not a device action.
Every substituted value is percent-encoded. A serial is boring; an asset tag is
whatever somebody typed into your MDM ten years ago, and one containing & or
# would otherwise silently rewrite the rest of the URL.
A template naming a field this device has no value for produces no button, and the device page says which field is missing. That is a better answer than a link that opens your console’s “machine not found” page.
The schemes
Section titled “The schemes”Also a closed list.
https: for a web console, and then the URI schemes browsers hand to an
installed application: rdp:, vnc:, teamviewer:, teamviewer10:,
anydesk:, screenconnect:, splashtop:, dameware:, ms-rd:.
There is deliberately no http:. A remote support console reached over plain
HTTP is a credential and a screen share crossing a school network in clear, and
every product in this category has offered TLS for a decade.
The obvious exclusions are javascript: and data:, but the reason the list is
closed rather than a pattern is file:. A template is written by an
administrator and rendered into a link a technician clicks, and the gap between
those two people is exactly where a surprising scheme would be useful to
somebody.
Templates are checked when you save them, not when somebody clicks. An administrator typing one gets told what is wrong with it; validating at click time means the first person to find out is the one who can do least about it.
Telling the person
Section titled “Telling the person”Notify the person using the device is on by default, because these are mostly students’ devices.
Plugboard returns the flag rather than sending the notice itself: on a school’s estate the surface that can actually reach somebody mid-lesson is the MDM or the remote tool, not an email nobody reads. Wire it into whichever of those you use.
Turning it off for a target is a decision a school has made about children’s screens, and it is recorded on the target and again on every session started with it.
Permissions
Section titled “Permissions”| Permission | Allows |
|---|---|
remote.start |
See what can be started on a device, and start it |
remote.manage |
Create, edit and remove targets |
Neither is folded into device.manage. That permission is held by whoever
corrects a room number or a warranty date; this one watches a screen that mostly
belongs to a child. A school with three technicians should still be able to grant
one without the other.
What is audited
Section titled “What is audited”Every one of these lands in the audit log:
remote.start |
Who started it, on which device, which target, which placeholders were filled, the serial, who the device is assigned to, and whether the notice was on |
remote.targetCreate |
The label, the template, and whether it notifies |
remote.targetUpdate |
The same, with what changed |
remote.targetDelete |
Which target went |
The remote.start row is written before the link is handed over, not after.
A session started by a process that then died would otherwise leave no trace at
all, and an unexplained remote session is a phone call from a parent that nobody
can answer.
There is no second row on success. Nothing here is irreversible and nothing can fail on our side: the link either was handed over, or the request errored before that point.
If your tool has a connector
Section titled “If your tool has a connector”Plugboard has a remote access connector category for the two things a link genuinely cannot do: saying whether the machine is online before somebody clicks, and minting a session that expires. Nothing ships in it yet, and the device page works without one.
That is the point of doing this as a link. A school running a tool we have never heard of should not have to wait for somebody to write its integration, and connectors here amplify rather than gate. If you want one for your tool, see getting one built.