Installation for Admins

This page is for IT administrators who want to deploy BAUER GROUP Remote-Access permanently across a fleet, or set up a server for unattended access.

Download packages

Loading available installers …

Firewall — Outbound ports that must be allowed

Every client must be able to reach these ports outbound to the server address. On corporate networks with strict egress policies, share this list with your IT/network-security team. The exact server hostname is on the Manual Configuration page.

Port	Protocol	Purpose	Required?
21116	UDP	Rendezvous registration (RegisterPk) — the client announces itself and gets an ID	Yes, critical
21115	TCP	NAT-type detection during connection setup	Recommended
21116	TCP	Rendezvous fallback when UDP is blocked (sessions only, NOT registration)	Recommended
21117	TCP	Relay server for sessions where P2P isn't possible	Recommended
21118	TCP	WebSocket rendezvous (session setup over 443 isn't possible)	Optional
21119	TCP	WebSocket relay	Optional
443	TCP	HTTPS — download portal and WSS fallback (/ws/id, /ws/relay)	Required (download) + fallback
80	TCP	HTTP → automatically redirected to 443	Recommended

UDP 21116 is NOT optional

The RustDesk-OSS server (rustdesk-server) implements initial client registration (the RegisterPk message) only over UDP. Verified by source-reading at hbbs/src/rendezvous_server.rs:556-564 — the TCP/WebSocket handler hardcodes NOT_SUPPORT for RegisterPk.

If UDP 21116 is blocked by the corporate firewall, the client hangs on "Connecting to network…" forever, never gets an ID assigned, and no peer can find it. Sessions themselves can fall back to TCP, but the registration has to come through UDP.

(RustDesk-Pro has a different handle_tcp that supports RegisterPk over TCP/WS. For our OSS stack, UDP 21116 is mandatory.)

Minimum setup for 443-only networks

If IT will absolutely only open port 443 (e.g. corporate WAN with web-proxy), the user can manually enable "Use WebSocket" in the client (Settings → Network). Sessions then run via WSS over 443. BUT: initial registration over UDP 21116 still won't work — the user needs UDP 21116 open for the first connection, after which strict-egress can apply.

Realistic ask: please get UDP 21116 unblocked. It's a single port, no security risk (it carries RustDesk protocol, not generic UDP traffic).

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.

MSI + Unattended are pre-configured

Server hostname, public key, and all branding settings are already baked into every MSI — rdgen does this at custom-client build time. No first-run configuration needed: once installed, the client immediately connects to your server. Nobody has to type hostnames or keys into the client settings.

If you want to configure the stock RustDesk client (from rustdesk.com / Play Store / App Store) manually instead, the values are at Manual Configuration.

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

Filenames in the examples

The rdgen pipeline bakes version + architecture into the filename, e.g. bg-quicksupport-1.4.7-x86_64.msi. In the code samples below I use the placeholder pattern bg-quicksupport-<version>-x86_64.msi — find the exact name per build on your instance's Download page or in the manifest at /downloads/manifest.json.

64-bit (x86_64) is the default; if you extend CLIENT_BUILD_PLATFORMS to include windows-x86, the 32-bit MSI variants ship alongside under the same naming convention (bg-quicksupport-<version>-i686.msi).

Interactive (manual)

Double-click the .msi → installer UI → default path C:\Program Files\BAUER GROUP Remote-Access\. After install, the client launches at logon as a tray app.

Silent (PowerShell / cmd)

msiexec /i "bg-quicksupport-<version>-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

When things fail: turn on verbose logging — the standard debugging tool for MSI installs that fail silently:

msiexec /i "bg-quicksupport-<version>-x86_64.msi" /qn /norestart /l*v "$env:TEMP\rustdesk-install.log"

/l*v = log all + verbose. The resulting log contains custom-action invocations, ACL grants, every setup step — basically everything Microsoft Installer does internally. Intune doesn't surface this log in its reporting; always pilot a silent rollout with /l*v on one test device before deploying fleet-wide.

Microsoft Intune

1. Pack into .intunewin using the Microsoft Win32 Content Prep Tool:

   IntuneWinAppUtil.exe -c <msi-folder> -s bg-quicksupport-<version>-x86_64.msi -o <output>

2. Apps → Windows → Add → Win32 app in Intune:

   • Install: msiexec /i "bg-quicksupport-<version>-x86_64.msi" /qn /norestart
   • Uninstall: msiexec /x "{ProductCode}" /qn
   • Detection rule: MSI product code (Intune auto-reads it from the .intunewin)

3. Assignment: Required → device or user group.

Group Policy (GPO)

For AD-managed domains without Intune:

1. Place the MSI on an SMB share with read access for Domain Computers (\\fileserver\software$\BAUER GROUP Remote-Access\bg-quicksupport-<version>-x86_64.msi).
2. Computer Configuration → Policies → Software Settings → Software installation → New Package — UNC path to the MSI, Assigned (not "Published" — that's for user GPOs).
3. gpupdate /force on 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.

Uninstall

Clean silent uninstall requires the MSI product code of the installed build. WiX regenerates it on every rdgen build, so it's not stack-constant.

Find the product code (on a system with the client installed):

# Via Registry (fast, no WMI polling):
Get-ChildItem 'HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall' |
    Get-ItemProperty |
    Where-Object DisplayName -like "*{{ appName }}*" |
    Select-Object DisplayName, DisplayVersion, PSChildName

PSChildName is the product code in {GUID} form, e.g. {12345678-90AB-CDEF-1234-567890ABCDEF}. Plug that into the uninstall command:

msiexec /x "{12345678-90AB-CDEF-1234-567890ABCDEF}" /qn /norestart

For Intune: when you create the Win32 app, Intune reads the product code automatically from the .intunewin. Just leave msiexec /x "{ProductCode}" /qn in the uninstall command field — Intune fills the placeholder at deploy time.

For the Unattended variant: stop the service first, then uninstall — otherwise the service process hangs. See Unattended → Uninstall further down.

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

1. Roll out bg-remoteaccess-<version>-x86_64.msi (same method as the QuickSupport MSI — see above: Silent, Intune, GPO, or SCCM).

2. After install, the RustDesk service runs as LocalSystem. Verify with:

   Get-Service "*RustDesk*"

3. Set the password — as admin, via the client binary:

   & "C:\Program Files\{{ appName }}\rustdesk.exe" --password "<strong-password>"

   The command writes the password (as a bcrypt hash) into the service config at C:\Windows\ServiceProfiles\LocalSystem\AppData\Roaming\BAUER GROUP Remote-Access\RustDesk.toml. The plain-text password never leaves this command's process — there is no way to read it back afterwards (see Rotate or reset the password).

Bulk rollout (per-device passwords)

One distinct password per device — never a fleet-wide shared one. Pattern for an Intune PowerShell script (or Ansible task) that pulls the password from a per-device source:

# Example: pull from Azure Key Vault, indexed by hostname
$hostname = $env:COMPUTERNAME
$password = (Get-AzKeyVaultSecret -VaultName "rustdesk-passwords" `
                                   -Name "host-$hostname" `
                                   -AsPlainText)

if (-not $password) {
    # Fallback: generate a cryptographically random 24-char password
    # and immediately persist it to the vault for reproducibility
    $bytes = [System.Security.Cryptography.RandomNumberGenerator]::GetBytes(18)
    $password = [Convert]::ToBase64String($bytes)
    Set-AzKeyVaultSecret -VaultName "rustdesk-passwords" `
                          -Name "host-$hostname" `
                          -SecretValue (ConvertTo-SecureString $password -AsPlainText -Force)
}

& "C:\Program Files\{{ appName }}\rustdesk.exe" --password $password

Alternative sources depending on infrastructure: HashiCorp Vault (vault kv get -field=password secret/rustdesk/$hostname), AWS Secrets Manager (aws secretsmanager get-secret-value), or a simple CSV lookup for air-gapped environments. Don't hardcode a single password in the GPO / Intune script definition — one leak opens every device on the fleet.

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.

Rotate or reset the password

The same --password command overwrites the stored password. There is no way to read the current one back — it's hashed at rest. If you forget it:

# Set a new password (overwrites the old one)
& "C:\Program Files\{{ appName }}\rustdesk.exe" --password "<new-strong-password>"

# Optionally restart the service to apply immediately,
# instead of waiting for the next connection attempt
Restart-Service -Name "RustDesk*"

For fleet-wide rotation: same pattern as the bulk rollout above. Critical sequencing: the admin workstation initiating the connection must learn the new password BEFORE rotating it on the target device — otherwise you lock yourself out. Recommended order: write new value to the vault → roll the script to the target → open a verification connection.

Service control

Standard Windows service commands for troubleshooting:

# Status check (Stopped / Running / Paused, Start-Type Automatic / Manual)
Get-Service "*RustDesk*" | Format-List Name, Status, StartType

# Stop / Start / Restart
Stop-Service    -Name "RustDesk*"
Start-Service   -Name "RustDesk*"
Restart-Service -Name "RustDesk*"

# Service logs (last 24 hours of Application-log entries, newest first)
Get-EventLog -LogName Application -Source "RustDesk*" `
             -After (Get-Date).AddHours(-24) |
    Format-Table TimeGenerated, EntryType, Message -AutoSize

Common symptom ↔ probable cause:

Symptom	Probable cause
Get-Service shows Stopped, won't start	Crash on start — check Application event log, then reinstall if needed
Admin connection fails with "Wrong Password"	Password not set, or set in wrong account context; verify the --password call ran by reviewing Application event log
Connection establishes but drops after seconds	Local firewall blocking outbound UDP/TCP — see Help & Troubleshooting
Service runs but lacks permission to read screen content	Windows lock screen blocks LocalSystem — RustDesk Pro has a workaround for this; OSS can't reach into locked sessions

Uninstall

Because of the running service, unattended uninstall needs a specific order — a direct msiexec /x without first stopping the service leaves the service process hanging, and the next install attempt will complain about "file in use".

# 1. Stop the service + disable startup so it doesn't respawn
#    while we're uninstalling:
Stop-Service -Name "RustDesk*"
Set-Service  -Name "RustDesk*" -StartupType Disabled

# 2. Find the product code (same as the Windows-MSI Uninstall section above):
$productCode = Get-ChildItem 'HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall' |
    Get-ItemProperty |
    Where-Object DisplayName -like "*{{ appName }}*" |
    Select-Object -ExpandProperty PSChildName

# 3. Silent uninstall:
msiexec /x "$productCode" /qn /norestart /l*v "$env:TEMP\rustdesk-uninstall.log"

# 4. Clean up leftover config + key:
Remove-Item -Path "C:\Windows\ServiceProfiles\LocalSystem\AppData\Roaming\{{ appName }}" `
            -Recurse -Force -ErrorAction SilentlyContinue

Watch out at step 4: this removes the LocalSystem AppData folder which holds the hashed password — a later reinstall will require setting the password from scratch (no carry-over). If you want re-install with the same password, skip step 4 — msiexec /x doesn't remove the config file by default, but other RustDesk state files may matter.

macOS — deployment

Notarization status

The bundle is currently not notarized (no Apple Developer ID signature round-tripped through notarytool), and the rdgen customization bakes the server config into the binary after the fact — which breaks the original signature. How that surfaces on the Mac depends on the chip:

Mac	Symptom on first launch
Apple Silicon (M1/M2/M3/M4)	"… is damaged and can't be opened" — or the app simply does nothing on launch (the kernel kills an invalidly-signed arm64 binary with no dialog)
Intel	"… cannot be opened because Apple cannot check it for malicious software"

Removing quarantine alone is NOT enough on Apple Silicon

Apple Silicon requires a valid code signature for every arm64 app. Because the rdgen customization breaks the signature, the kernel kills the app on launch — even after the quarantine flag is gone (classic symptom: "nothing happens"). You need two steps: remove quarantine and re-sign the bundle ad-hoc.

Fix for Apple Silicon — strip quarantine + re-sign ad-hoc

Drag the app to /Applications first, then run both once in Terminal:

# 1. Remove quarantine + all extended attributes recursively
sudo xattr -cr "/Applications/<Name>.app"

# 2. Re-sign the bundle ad-hoc — restores a valid signature
sudo codesign --force --deep --sign - "/Applications/<Name>.app"

<Name> is the exact name of the app as shown in /Applications. For this instance's packages:

Variant	App name in /Applications
QuickSupport (default download)	BAUER GROUP QuickSupport
Unattended	BAUER GROUP Remote-Access

The app then launches normally and only asks for Screen Recording + Accessibility.

Why this isn't fixed in the build

codesign is a macOS-only tool. Our build pipeline runs in a Linux container and technically cannot produce a valid signature. The only complete alternative would be real notarization with an Apple Developer ID on a macOS CI runner — until then, the two-step above is the reliable path.

Manual override on Intel (single device)

For the milder Intel message the UI path is enough:

1. System Settings → Privacy & Security
2. In the Security section: "BAUER GROUP Remote-Access was blocked" → "Open Anyway"
3. One-time per device. App launches normally on subsequent runs.

MDM deployment (Jamf, Munki, Kandji, Mosyle)

• Wrap the bundle as a .pkg and ship it with a PPPC profile policy that pre-grants ScreenCapture and Accessibility for 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 "<Name>.app" (e.g. "BAUER GROUP QuickSupport.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)

1. Settings → Apps → Special app access → Install unknown apps → enable for the browser / file manager you're using
2. Download the APK, tap it, Install
3. 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

Connecting an existing RustDesk client to the server

The guides above roll out our preconfigured custom client — server hostname, public key and branding are already baked in. There are scenarios, though, where an already-installed stock RustDesk client (from rustdesk.com, the Play Store, or the App Store) needs to be pointed at your servers:

• iOS — the App Store build is the only official path; we don't produce custom IPA packages
• Linux workstations — we don't currently produce .deb/.rpm/.AppImage packages
• Mobile devices without MDM — personal smartphones, BYOD setups
• Emergency setup — while a fresh custom-client build is still running (typical on first deploy or after a server move)
• Reconfiguring an existing install — devices where a stock client is already running and pointing at other servers (e.g. the public RustDesk servers)

The server connection details (ID server, relay server, public key) plus a step-by-step guide for desktop and mobile live on a separate page — including copy-to-clipboard for every value and mode-specific notes (e.g. "Allow WebSocket" in WSS mode):

→ Open Manual Configuration

Why a separate page rather than inlining here?

That page is intentionally not in the top navigation and not indexed by search engines — so the server setup isn't passively crawlable via Google/Bing. The values themselves aren't technically secret (the public key is by design the public half of a key pair, and hostnames have to be known by every client anyway). We just avoid passive indexing. Send the link to affected users directly.

Where is data stored?

Platform	Local config path
Windows (MSI)	%APPDATA%\BAUER GROUP Remote-Access\ + service settings under C:\Windows\ServiceProfiles\LocalSystem\AppData\Roaming\BAUER GROUP Remote-Access\
Windows (portable)	In memory only while running
macOS	~/Library/Application Support/BAUER GROUP 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 BAUER GROUP Remote-Access servers only as opaque relay (when at all — direct P2P is preferred; see docs/networking.md in the repo).

Further configuration

• Manual Configuration — server connection details + step-by-step guide for the stock RustDesk client (see the "Connecting an existing RustDesk client to the server" section above)
• Help & Troubleshooting — end-user-facing FAQ for SmartScreen warnings, connection drops, key mismatches, and similar.