Skip to content

Core Tools

How Remote Desktop works

Connecting to a simulated workstation, the desktop environment inside it, and how windows behave.

Remote Desktop is how you reach a requester's simulated machine. It is authorized per ticket — SysDesks checks whether the incident you have open actually concerns an endpoint before it lets a remote session open, the same way real remote-access tooling is scoped to an authorized purpose rather than open to any machine at any time. A directory-only or shipping-only ticket, for instance, will not authorize a remote session, because there is nothing on an endpoint for it to fix.

Once a session opens, you get a full simulated Windows desktop rendered inside the browser: a Start menu, a taskbar with pinned and running apps, a desktop with icons, and a working window manager. This is not a static screenshot or a scripted sequence — it is a real desktop shell with its own state, and the applications inside it read and write the same simulated device state your ticket is scored against.

What is on the simulated desktop

  • Command Prompt — ipconfig, ping, nslookup, net start/stop, tasklist, and the other commands a Tier 1 technician actually uses.
  • Services — view and start or stop Windows services, and see their startup type.
  • Device Manager — inspect and fix driver and hardware-enumeration problems.
  • Event Viewer — Application and Security logs, including the errors a user never saw on screen.
  • Task Manager — running processes, CPU and memory usage, and startup impact.
  • NorthMail — the company email client (see the NorthMail article for the full detail).
  • Settings, Control Panel, Programs and Features, File Explorer, and the Company Software Portal.

Windows inside a remote session behave like real desktop windows: they can be dragged by the title bar, minimized, maximized, and resized from any edge or corner, with a sensible minimum and maximum size so a window can never be dragged into an unusable sliver or off the screen entirely. If you resize a window and then minimize it, restoring it from the taskbar brings back the exact size you left it at — that memory is scoped to your current session on that specific device, which matters for the next point.

Window state does not follow you between devices. When you disconnect from one remote session and connect to another, every open window, every resized dimension, and anything else about how you left the desktop resets to a clean baseline. This is deliberate: it mirrors how a real technician's remote session to one machine has nothing to do with the next machine they connect to, and it means you never have to worry about a previous ticket's window layout bleeding into a new one.

The Start menu and the taskbar's Search are two separate surfaces and only one is ever open at a time — opening one closes the other automatically, the same way Windows itself behaves. The Start menu is a plain scrollable list of the apps available on that desktop; searching for a specific app or setting by name is what the Search button is for.

Some devices run a simulated front panel or a browser-based Remote UI instead of a full desktop — this applies to network-attached hardware like the Canyon Printer, which you work through its own physical-style front panel for jam and consumable issues, or through its Remote UI (reached the same way you'd browse to a printer's IP address on a real network) for network, queue, and firmware issues.

The remote session bar along the top of the screen carries a few controls worth knowing about: a fullscreen toggle for working without browser chrome around the desktop, zoom presets (75, 100, 125, and 150 percent) for scaling the whole session to fit your own screen, and a clipboard sync toggle that mirrors how a real remote-access tool lets you carry text between your machine and the one you've connected into. None of these affect ticket scoring — they're purely about making the session comfortable to actually work in.

Because everything a remote session touches is real simulated state, actions you take there are exactly what a ticket's resolution conditions check against later. Starting a service in Services, disabling a device in Device Manager, or changing a setting in Control Panel are not cosmetic — they persist, they're visible if you reconnect, and they're what determines whether the ticket you're working actually resolves when you click Resolve.

Read next