Windows clients

The supported machine always runs the native Windows client — a web page cannot inject operating system mouse and keyboard input, so there is no browser-based client. What varies is whether that client is installed.

Portable executable — attended support

The user double-clicks it (or the join page hands them a launcher that passes the right relay, session and token). It runs inside that user's session, needs no administrator rights, and installs nothing. Closing it ends access. This is the lower-risk deployment and the right default for helpdesk work.

SecureDeskClient.exe --portable ^
  --relay wss://support.example.com ^
  --session my-code ^
  --token <session token>

The equivalent environment variables are RUBIX_RELAY, RUBIX_SESSION, RUBIX_TOKEN, plus RUBIX_FPS, RUBIX_QUALITY and RUBIX_NAME for tuning and labelling.

Elevating a portable session

A standard-user session cannot fix a service or a driver. The technician clicks Elevate…, enters an administrator account for that machine (DOMAIN\user, user@domain or a local account), and the client relaunches itself with those rights via a linked-token launch. It then reports the integrity level it actually obtained, so the console never claims an elevation that did not happen.

Installed service — unattended access

Installed from an elevated PowerShell prompt, the client runs as LocalSystem from boot. It survives logon, lock and fast-user-switch, and gives the technician access before anyone has signed in.

# elevated PowerShell
.\install-service.ps1 -Relay wss://support.example.com `
                      -Session my-code `
                      -Token <token>

.\install-service.ps1 -Uninstall

In normal use you do not hand-write session ids: the device enrolls with the portal and carries its own device token, appearing in the portal's per-customer device inventory. A technician with the devices.connect permission opens a session against it directly.

The Session 0 problem, and how it is handled

A Windows service runs in Session 0, isolated from the interactive desktop, so it cannot capture the screen or inject input from there. The service finds the active console session, duplicates that user's token, and spawns its capture worker inside the user's session on desktop winsta0\default — relaunching it across session changes.

Sign-in and lock screens

On the Windows sign-in desktop, GDI capture returns the composited login UI as solid black, while DXGI Desktop Duplication captures it correctly — but DXGI has to be created on a thread bound to the current input desktop, and it fails outright on some virtual display stacks. So the unattended worker runs both: GDI keeps frames flowing while DXGI is probed on the capture thread, and the moment DXGI yields a frame it switches to it permanently. If DXGI cannot initialize, you stay on GDI and the reason is recorded in diagnostics rather than showing up as an unexplained black screen.

Backstage — a SYSTEM shell with no desktop

The installed service also exposes a backstage session: cmd or PowerShell running as SYSTEM, with no interactive desktop. A technician can run privileged commands and move files without taking over or even disturbing the user's screen, and it works when nobody is logged in. The portable executable never starts one.

Backstage rides a derived session id. If the support code is S, desktop control uses S and backstage uses S-bs. The technician picks Desktop or Backstage in the console; the user only ever shares the one code.

What a session can do

The technician console

Two options, same capabilities including the backstage terminal: the browser console opened from the portal (or directly at /console), and a native Windows console for technicians who prefer an application. The native console links the client's protocol implementation directly, so the wire format cannot drift between the two.