Advanced Remote checks the port before you connect
Quick Connect probes RDP, VNC and SSH on the device and tells you which is actually listening before you click. Why that small chip removes a class of dead end.
Most failed remote sessions fail the same way, and it is not an interesting way. You pick a machine, you click connect, and then you wait. Fifteen seconds, twenty, however long the TCP timeout is on that path. Eventually something says the connection could not be established, and now you get to guess: wrong host, firewall, service not running, credentials, agent offline, or the thing is just slow today.
You will usually find the answer. It will usually be boring. Remote Desktop was never switched on, or nobody installed a VNC server, or sshd is not running on that box. Every one of those was knowable before you clicked, and nothing bothered to check.
Advanced Remote checks. The Quick Connect panel probes all three protocols against the selected device in the background, in parallel, while you are still reading the page.
What the chip actually knows
Each card carries the port it will dial (:3389, :5900, :22) and, once the probe answers, a chip saying Running or Not running. If it says Not running, a line underneath tells you which flavour of nothing it found: either “Nothing is listening on this port on the device. Start the service first,” or, when the traffic disappeared instead of being refused, “Nothing answered on this port. A firewall may be dropping the traffic.”
Those are genuinely different problems and they need different people. The first one is a service you can start. The second is a rule someone has to change.
The probe is advisory, and deliberately so. A card that came back Not running stays clickable. Someone might start the service in the thirty seconds between the probe and your click, an old agent might not answer the probe at all, and a stale “no” that locks you out of a machine you can actually reach would be a worse tool than the timeout we were trying to avoid. When the probe cannot reach a verdict, the card simply shows no chip rather than inventing one.
Same posture applies to the recommendation. The panel marks the protocol your platform usually ships (RDP on Windows, SSH on Linux, VNC on macOS) and will warn you that, say, Windows does not come with a VNC server, or that xrdp has to be installed for RDP on Linux. It never takes the option away. Plenty of real machines run the unusual combination, and a tool that assumes otherwise is just wrong more politely.
The banner above the cards answers the other pre-flight question, which is whether the agent on that device is even talking to us right now. If it is not, Quick Connect says so plainly instead of offering you three buttons that cannot work. Between that banner and the three chips, most of the guessing you would otherwise do after a failed connection has already been done for you.
The address is local to the machine you are dialling
The reason the probe means anything is where it runs.
Quick Connect always targets 127.0.0.1 on the selected device. Not your machine, not a bastion, not a hostname that has to resolve from wherever you happen to be sitting. The agent already running on that device forwards to its own local RDP, VNC or SSH service, and the probe is that same agent trying its own loopback address.
So when a card says nothing is listening on :5900, it means nothing is listening on that machine’s own loopback. That is a much stronger statement than “I could not get there from here,” which is what a probe from the outside would actually be telling you.
It is also why none of this requires a hole in anything. The service never has to be reachable from outside the box it runs on, let alone from the internet. We wrote up that model properly in how VPN-free remote access works, and there is no sense repeating it here.
”Not running” does not have to be the end of the conversation
On a Windows device where the probe proved RDP is closed, the panel offers to turn Remote Desktop on.
Read the qualifiers, because they are load-bearing. It only appears when the probe returned a definite no, never when the answer was inconclusive, because proposing a change to somebody’s server on a guess is not a feature. It only appears for operators holding the permission that governs protocol access, and that permission is enforced server-side rather than by hiding the button. And it asks first, spelling out that it will enable Remote Desktop and open the matching firewall rule, then queues that as an explicit command with its own audit entry.
Enabling remote access is a change to a machine. It should look like one, rather than happening quietly as part of a retry.
The toggle that stops you fighting Windows for a session
The RDP card has one extra control: a switch reading RDP: attach to the console session, with the condition it exists for spelled out beside it.
Underneath the row sits a note that experienced Windows admins will recognise immediately, and that everyone else learns the hard way: if you connect over RDP to a Windows device where the same user account is already signed in at the console, Windows will fight over the session. It authenticates, runs for a few seconds, then drops. The usual reaction is to blame the network and try again, which does exactly the same thing.
Use a different account, or use SSH or VNC instead, or attach to the console session rather than asking for a second one.
That note has lived in a support article at every company I have worked at. It belongs about four centimetres from the button that triggers it. Moving it there costs nothing and stops a ticket we would otherwise keep answering.
There is a related bit of anticipation in how credentials are handled. Windows authenticates before it draws anything, so an RDP attempt with no stored credentials cannot fall back to a login screen. It can only time out. Rather than dial and lose, Quick Connect asks for the username and password up front when the connection has none stored. VNC gets a password field with no username, because the protocol has no such concept and asking for one would produce a prompt nobody could satisfy.
A desktop in a tab, and a record that it happened
Once a session opens, the machine’s desktop renders in the browser tab. No client to install on the operator’s laptop, which matters most for the people you least want installing things: contractors, new starters, anyone on a machine you do not manage.
Quick Connect is one of five sections. Connections holds saved connections, Groups organises them once there are enough to need organising, Discovery finds devices on the network from the agent’s vantage point, and Activity Log records what was opened, by whom and when.
Discovery is worth a second look for anyone inheriting a site they did not build. The scan runs on the agent rather than from your laptop, looking for RDP, VNC and SSH services on the network that device is sitting on, and anything it finds can be turned into a saved connection without typing an address. What it sees is what that machine can see, which on a network where the documentation stopped being true two years ago is the more useful question.
The audit trail is the part that turns out to matter in the boring quarterly way. When somebody asks who was on that server on the 14th, the answer is a query rather than an archaeology project. If the broader question of whether any of this is safe is what brought you here, that argument is made properly in is browser-based SSH secure? rather than summarised badly at the end of a different post.
None of the above is glamorous. A chip that says a service is not running will never demo as well as a desktop appearing in a browser tab. It just happens to be the thing that gets you to the desktop on the first click instead of the third.
More on how this works in practice: the features overview, or email [email protected] with questions.
Related posts
When to use browser-based vs thick-client remote desktop
Browser remote desktop is not always the right call. The decision grid we use to pick between web and native clients is small, but it covers most of the real cases.
Secure remote desktop and SSH access for modern IT teams
IT teams need shell and desktop access without shipping another client. LynxTrac unifies both into one audited, browser-based surface that changes how access actually feels.
Lynx Desktop: many windows, one remote connection
Lynx Desktop puts the terminal, file explorer and remote desktop in one browser tab over a single connection to one device. What that changes about the work.