Installation for Admins
This page is for IT administrators who want to deploy Remote-Access permanently across a fleet, or set up a server for unattended access.
End user needing one-off support?
You don't need this page. → The Home page is all you need: click the download button, tell the agent your ID, done.
Which variant for what?
| Variant | Audience | Auth | Persistence |
|---|---|---|---|
| QuickSupport (portable) | End users, one-off support | per-session "Accept" dialog | none — close = gone |
| QuickSupport (MSI) | End users on managed Windows devices | per-session "Accept" dialog | stays installed, tray app |
| Unattended | Servers, always-on workstations, kiosks | password, no dialog | as Windows service |
The two variants share branding, key, and server config — they differ only in five behavior knobs (approve-mode, direction, installation, settings-access, tray-visibility). See branding/variants/*.env in the repo for the exact split.
Windows — MSI rollout
Interactive (manual)
Double-click the .msi → installer UI → default path C:\Program Files\Remote-Access\. After install, the client launches at logon as a tray app.
Silent (PowerShell / cmd)
msiexec /i "bg-quicksupport-x86_64.msi" /qn /norestart/qn— no UI, no dialogs/norestart— do not reboot even if pending- Exit codes: 0 = OK, 1641 = restart needed but suppressed, 3010 = restart scheduled
Microsoft Intune
Pack into
.intunewinusing the Microsoft Win32 Content Prep Tool:textIntuneWinAppUtil.exe -c <msi-folder> -s bg-quicksupport-x86_64.msi -o <output>Apps → Windows → Add → Win32 app in Intune:
- Install:
msiexec /i "bg-quicksupport-x86_64.msi" /qn /norestart - Uninstall:
msiexec /x "{ProductCode}" /qn - Detection rule: MSI product code (Intune auto-reads it from the
.intunewin)
- Install:
Assignment: Required → device or user group.
Group Policy (GPO)
For AD-managed domains without Intune:
- Place the MSI on an SMB share with read access for Domain Computers (
\\fileserver\software$\Remote-Access\bg-quicksupport-x86_64.msi). - Computer Configuration → Policies → Software Settings → Software installation → New Package — UNC path to the MSI, Assigned (not "Published" — that's for user GPOs).
gpupdate /forceon a test client. Installation happens at next reboot.
SCCM / MECM
Standard MSI application: msiexec /i install command, msiexec /x {ProductCode} uninstall, MSI detection method auto.
Unattended — set up permanent access
The Unattended variant installs as a Windows service and is password-authenticated. Incoming sessions skip the "Accept" click — the server accepts any connection that supplies the correct password.
Before rolling out
Set a strong, per-device password. A single shared password across the fleet = one leak opens every device. Distribute via a device-specific mechanism (Intune PowerShell script, Ansible, etc.).
Install
Roll out
bg-remoteaccess-x86_64.msi(same method as the QuickSupport MSI — see above).After install, the RustDesk service runs as
LocalSystem. Verify with:powershellGet-Service "*RustDesk*"Set the password — as admin, via the client binary:
powershell& "C:\Program Files\{{ appName }}\rustdesk.exe" --password "<strong-password>"
Admin-side connection
The connecting admin enters the device ID + password. No Accept dialog appears on the server — the session starts immediately.
Use cases
- Server / VM that normally has no one sitting at it
- Kiosk PC that can't be physically operated
- Service-desk workstations that must be reachable 24/7
Not suitable for end-user devices — the missing session confirmation conflicts with most privacy requirements.
macOS — deployment
Notarization status
The bundle is currently not notarized (no Apple Developer ID signature round-tripped through notarytool). Gatekeeper therefore shows on first launch:
"Remote-Access cannot be opened because Apple cannot check it for malicious software."
Manual override (single device)
- System Settings → Privacy & Security
- In the Security section: "Remote-Access was blocked" → "Open Anyway"
- One-time per device. App launches normally on subsequent runs.
MDM deployment (Jamf, Munki, Kandji, Mosyle)
- Wrap the bundle as a
.pkgand ship it with a PPPC profile policy that pre-grantsScreenCaptureandAccessibilityfor the app's bundle ID - That way the first launch skips both system prompts — user sees the ID immediately
- Extract bundle ID + code requirement with
codesign -dvvv Remote-Access.app
macOS permissions (manual)
On first launch macOS asks for:
- Screen Recording — so support can see your screen
- Accessibility — so support can move your mouse/keyboard
Both are required for a functioning session.
Android — sideload + MDM
Manual sideload (single device)
- Settings → Apps → Special app access → Install unknown apps → enable for the browser / file manager you're using
- Download the APK, tap it, Install
- On launch: allow Screen capture / cast
MDM (Intune for Android, Workspace ONE, Knox)
Standard APK distribution via Managed Google Play or directly as a line-of-business app:
- Intune: Apps → Android → Line-of-business app → upload APK → assignment "Required"
- Grant permissions ahead of time via Android App Configuration Policy — no user prompt on launch
Where is data stored?
| Platform | Local config path |
|---|---|
| Windows (MSI) | %APPDATA%\Remote-Access\ + service settings under C:\Windows\ServiceProfiles\LocalSystem\AppData\Roaming\Remote-Access\ |
| Windows (portable) | In memory only while running |
| macOS | ~/Library/Application Support/Remote-Access/ |
| Android | App-internal storage, no user-visible path |
Not stored: session screen content, keystrokes, mouse state, clipboard contents. That traffic is end-to-end encrypted between the participating devices and passes the Remote-Access servers only as opaque relay (when at all — direct P2P is preferred; see docs/networking.md in the repo).