Installation für Admins

Diese Seite richtet sich an IT-Administratoren, die BAUER GROUP Remote-Access dauerhaft auf einer Geräteflotte ausrollen oder einen Server für unbeaufsichtigten Zugriff einrichten wollen.

Pakete herunterladen

Lade verfügbare Installer …

Firewall — Ports die ausgehend erlaubt sein müssen

Jeder Client muss diese Ports ausgehend zur Server-Adresse erreichen können. In Corporate-Netzwerken mit strikter Egress-Policy musst du diese Liste an die IT/Network-Security weitergeben. Den genauen Server-Hostname findest du unter Manuelle Konfiguration.

Port	Protokoll	Zweck	Pflicht?
21116	UDP	Rendezvous-Registrierung (RegisterPk) — der Client meldet sich an, kriegt eine ID	Ja, kritisch
21115	TCP	NAT-Type-Detection beim Verbindungsaufbau	Empfohlen
21116	TCP	Rendezvous-Fallback wenn UDP geblockt ist (Sessions, nicht Registration)	Empfohlen
21117	TCP	Relay-Server für Sessions ohne P2P	Empfohlen
21118	TCP	WebSocket-Rendezvous (Session-Setup über 443 nicht möglich)	Optional
21119	TCP	WebSocket-Relay	Optional
443	TCP	HTTPS — Download-Portal und WSS-Fallback (/ws/id, /ws/relay)	Pflicht (Download) + Fallback
80	TCP	HTTP → wird automatisch auf 443 umgeleitet	Empfohlen

UDP 21116 ist NICHT optional

Der RustDesk-OSS-Server (rustdesk-server) implementiert die initiale Client-Registrierung (RegisterPk-Message) ausschließlich über UDP. Verifiziert per Source-Read in hbbs/src/rendezvous_server.rs:556-564 — der TCP/WebSocket-Handler gibt für RegisterPk hardcoded NOT_SUPPORT zurück.

Wenn UDP 21116 in der Corporate-Firewall blockiert ist, hängt der Client für immer auf „Verbinden mit dem Netzwerk …", bekommt keine ID und keine Peer kann ihn finden. Sessions selbst können dann via TCP-Fallback laufen, aber die Registrierung muss durch.

(Bei RustDesk-Pro wäre das anders — dort hat handle_tcp einen eigenen RegisterPk-Pfad. Für unseren OSS-Stack: UDP 21116 ist Pflicht.)

Mindest-Setup für 443-only-Netze

Wenn die IT absolut nichts außer Port 443 öffnen will (z.B. Konzern-WAN mit Web-Proxy), kann der User im Client manuell die Option „WebSocket verwenden" (Einstellungen → Netzwerk) aktivieren. Sessions laufen dann via WSS über 443. ABER: die initiale Registrierung über UDP 21116 funktioniert weiterhin nicht — der User braucht für die erste Verbindung kurz UDP 21116 frei, danach kann er hinter den Strict-Egress-Setting.

Realistisch: bitte UDP 21116 freischalten lassen. Ist nur 1 Port, kein Risiko (RustDesk-Protokoll, kein generischer UDP-Verkehr).

Endkunde mit einmaligem Supportbedarf?

Du brauchst diese Seite nicht. → Startseite ist alles, was du brauchst: Download-Button drücken, ID dem Support nennen, fertig.

MSI + Unattended sind vor-konfiguriert

Server-Hostname, Public-Key und alle Branding-Einstellungen sind bereits in jede MSI eingebacken — die rdgen-Pipeline tut das beim Build des Custom-Clients. Es ist keine First-Run-Konfiguration nötig: nach der Installation verbindet sich der Client automatisch mit eurem Server. Niemand muss in den Client-Settings Hostnames oder Schlüssel eintragen.

Wer den Stock-RustDesk-Client (von rustdesk.com / Play Store / App Store) manuell konfigurieren will, findet die nötigen Werte unter Manuelle Konfiguration.

Welche Variante wofür?

Variante	Zielgruppe	Authentifizierung	Persistenz
QuickSupport (Portable)	Endkunden, einmaliger Support	„Annehmen"-Dialog pro Sitzung	keine — schließen = weg
QuickSupport (MSI)	Endkunden auf verwalteten Windows-Geräten	„Annehmen"-Dialog pro Sitzung	bleibt installiert, Tray-App
Unattended	Server, immer-an Workstations, Kiosks	Passwort, kein Dialog	als Windows-Dienst

Die zwei Varianten teilen sich Branding, Schlüssel und Server-Konfiguration — sie unterscheiden sich nur in fünf Verhaltens-Knöpfen (Approve-Mode, Direction, Installation, Settings-Access, Tray-Sichtbarkeit). Siehe branding/variants/*.env im Repo für die genaue Aufstellung.

Windows — MSI ausrollen

Dateinamen in den Beispielen

Die rdgen-Pipeline backt Version + Architektur in den Dateinamen ein, z.B. bg-quicksupport-1.4.7-x86_64.msi. In den Code-Beispielen unten verwende ich das Platzhalter-Muster bg-quicksupport-<version>-x86_64.msi — den genauen Namen pro Build siehst du auf der Download-Seite deiner Instanz oder im Manifest /downloads/manifest.json.

64-bit (x86_64) ist der Default; falls du CLIENT_BUILD_PLATFORMS um windows-x86 erweiterst, gibt's parallel auch 32-bit-MSI-Pakete im selben Schema (bg-quicksupport-<version>-i686.msi).

Interaktiv (manuell)

Doppelklick auf die .msi → Installer-UI → Standard-Pfad C:\Program Files\BAUER GROUP Remote-Access\. Nach Installation startet der Client automatisch bei Anmeldung als Tray-Anwendung.

Silent (PowerShell / cmd)

msiexec /i "bg-quicksupport-<version>-x86_64.msi" /qn /norestart

• /qn — kein UI, keine Dialoge
• /norestart — auch bei pending-Reboot nicht durchstarten
• Exit-Code 0 = OK, 1641 = Restart nötig aber unterdrückt, 3010 = Restart eingeplant

Bei Fehlern: vollständiges Verbose-Log einschalten — Standard-Debugging-Werkzeug für MSI-Installationen, die silent fehlschlagen:

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

/l*v = log all + verbose. Das geschriebene Log enthält Custom-Action-Aufrufe, ACL-Setzungen, jeden Setup-Schritt — alles, was Microsoft Installer intern macht. Bei Intune erscheint dieses Log nicht automatisch im Reporting; daher bei Rollout-Tests immer manuell auf einem Pilot-Gerät mit /l*v durchlaufen lassen, bevor du auf die ganze Flotte rollst.

Microsoft Intune

1. .intunewin packen mit dem Microsoft Win32 Content Prep Tool:

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

2. Apps → Windows → Hinzufügen → Win32-App in Intune:

   • Installation: msiexec /i "bg-quicksupport-<version>-x86_64.msi" /qn /norestart
   • Deinstallation: msiexec /x "{ProductCode}" /qn
   • Erkennungsregel: MSI-Produktcode auto-erkennen (Intune liest ihn aus dem .intunewin)

3. Zuweisung: Required → Geräte- oder Benutzergruppe.

Gruppenrichtlinie (GPO)

Für AD-verwaltete Domänen ohne Intune:

1. MSI auf eine SMB-Freigabe legen, die für Domain Computers Lesezugriff hat (\\fileserver\software$\BAUER GROUP Remote-Access\bg-quicksupport-<version>-x86_64.msi).
2. Computer-Konfiguration → Richtlinien → Softwareeinstellungen → Softwareinstallation → Neues Paket — UNC-Pfad zur MSI, Zugewiesen wählen (nicht „Veröffentlicht", das ist für User-GPOs).
3. gpupdate /force auf einem Test-Client. Installation passiert beim nächsten Reboot.

SCCM / MECM

Standard-MSI-Application: msiexec /i als Install-Command, msiexec /x {ProductCode} als Uninstall, MSI-Erkennungsmethode auto.

Deinstallation

Sauberer Silent-Uninstall braucht den MSI-Produktcode des installierten Builds. Den Code generiert WiX bei jedem rdgen-Build neu — er ist also nicht stack-konstant.

Produktcode finden (auf einem System mit installiertem Client):

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

PSChildName ist der Produktcode in {GUID}-Form, z.B. {12345678-90AB-CDEF-1234-567890ABCDEF}. Diesen Wert dann in den Uninstall-Command einsetzen:

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

Für Intune: beim Anlegen der Win32-App liest Intune den ProductCode automatisch aus dem .intunewin-Paket. Du musst nur msiexec /x "{ProductCode}" /qn im Uninstall-Command-Feld stehen lassen — Intune ersetzt den Platzhalter beim Deploy.

Bei der Unattended-Variante: erst den Dienst stoppen, dann uninstallieren — sonst bleibt der Service-Prozess hängen. Siehe Unattended → Deinstallation weiter unten.

Unattended — Dauerzugriff einrichten

Die Unattended-Variante installiert sich als Windows-Dienst und ist Passwort-authentifiziert. Eingehende Sitzungen brauchen keinen „Annehmen"-Klick — der Server akzeptiert jede Verbindung, die das richtige Passwort liefert.

Vor dem Rollout

Setze ein starkes, individuelles Passwort pro Gerät. Ein einheitliches Passwort über die ganze Flotte = ein Leak = jedes Gerät offen. Verteile per Geräte-spezifischen Mechanismus (Intune-PowerShell-Script, Ansible, etc.).

Installation

1. bg-remoteaccess-<version>-x86_64.msi ausrollen (gleiche Methode wie QuickSupport-MSI — siehe oben: Silent, Intune, GPO oder SCCM).

2. Nach Installation läuft der RustDesk-Dienst als LocalSystem. Prüfen mit:

   Get-Service "*RustDesk*"

3. Passwort setzen — als Admin via Client-Binary:

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

   Der Befehl schreibt das Passwort (als bcrypt-Hash) in die Service-Konfiguration unter C:\Windows\ServiceProfiles\LocalSystem\AppData\Roaming\BAUER GROUP Remote-Access\RustDesk.toml. Klartext-Passwort verlässt diesen Prozess nicht — danach gibt es keinen Weg, es wieder auszulesen (siehe Passwort ändern oder zurücksetzen).

Bulk-Rollout (per-device Passwörter)

Pro Gerät ein individuelles Passwort — nicht ein flotten-weites. Pattern für ein Intune-PowerShell-Script (oder Ansible-Task), das das Passwort aus einer per-Gerät-Quelle bezieht:

# Beispiel: Passwort aus Azure Key Vault, indiziert per Hostname
$hostname = $env:COMPUTERNAME
$password = (Get-AzKeyVaultSecret -VaultName "rustdesk-passwords" `
                                   -Name "host-$hostname" `
                                   -AsPlainText)

if (-not $password) {
    # Fallback: kryptografisch zufälliges 24-Zeichen-Passwort generieren
    # und sofort in den Vault speichern, damit es reproduzierbar ist
    $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 Quellen je nach Infrastruktur: HashiCorp Vault (vault kv get -field=password secret/rustdesk/$hostname), AWS Secrets Manager (aws secretsmanager get-secret-value), oder simpler CSV-Lookup für Air-Gapped-Umgebungen. Nicht über ein einheitliches Passwort in der GPO/Intune-Script-Definition — das ist ein einzelner Geheimleck = jedes Gerät offen.

Verbindung von Admin-Seite

Der verbindende Admin gibt die Geräte-ID + Passwort ein. Es erscheint kein Accept-Dialog auf dem Server — Sitzung startet sofort.

Anwendungsfälle

• Server / VM, an dem normalerweise niemand sitzt
• Kiosk-PC, der nicht physisch bedient werden kann
• Service-Desk-Workstations, die 24/7 erreichbar sein müssen

Nicht geeignet für Endkundengeräte — dort widerspricht die fehlende Sitzungs-Bestätigung den meisten Datenschutz-Anforderungen.

Passwort ändern oder zurücksetzen

Das gleiche --password-Kommando überschreibt das gespeicherte Passwort. Es gibt keine Möglichkeit, das aktuelle Passwort auszulesen — es wird gehasht gespeichert. Wenn du es vergessen hast:

# Neues Passwort setzen (überschreibt das alte)
& "C:\Program Files\{{ appName }}\rustdesk.exe" --password "<neues-starkes-passwort>"

# Optional: Dienst neu starten damit die Änderung sofort greift,
# anstatt erst beim nächsten Connect-Versuch
Restart-Service -Name "RustDesk*"

Bei Rotation über die ganze Flotte: dasselbe Pattern wie der Bulk-Rollout oben verwenden. Wichtig: die Verbindungs-Seite (Admin-Workstation) muss das neue Passwort kennen, bevor der Service rotiert wird — sonst sperrt man sich selbst aus. Empfohlene Reihenfolge: neuen Wert in den Vault schreiben → Script auf dem Zielgerät rollen → erste Verbindung zum Verifizieren öffnen.

Dienst-Kontrolle

Standard-Windows-Service-Kommandos für Troubleshooting:

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

# Stoppen / Starten / Neustart
Stop-Service    -Name "RustDesk*"
Start-Service   -Name "RustDesk*"
Restart-Service -Name "RustDesk*"

# Service-Logs (alle Einträge der letzten 24 Stunden, neueste zuerst)
Get-EventLog -LogName Application -Source "RustDesk*" `
             -After (Get-Date).AddHours(-24) |
    Format-Table TimeGenerated, EntryType, Message -AutoSize

Häufige Symptome ↔ Ursachen:

Symptom	Vermutete Ursache
Get-Service zeigt Stopped, lässt sich nicht starten	Crash beim Start — Application-Event-Log prüfen, dann ggf. neu installieren
Admin-Verbindung schlägt mit „Wrong Password" fehl	Passwort nicht oder mit falschem Account gesetzt; mit Get-EventLog checken ob --password überhaupt durchlief
Verbindung baut auf, schlägt aber nach Sekunden ab	Firewall lokal blockiert ausgehende UDP/TCP — siehe Hilfe & Troubleshooting
Dienst läuft, aber Service-Account hat keine Berechtigung Bildschirminhalt zu lesen	Windows-Lock-Screen sperrt LocalSystem aus — RustDesk Pro hat einen Workaround dafür; OSS-Variante kann gesperrte Sessions nicht durchgreifen

Deinstallation

Wegen des laufenden Dienstes braucht der Unattended-Uninstall eine spezifische Reihenfolge — ein direktes msiexec /x ohne vorheriges Stoppen lässt den Service-Prozess hängen, und beim nächsten Install-Versuch beklagt sich der Installer über „bereits laufende Datei".

# 1. Dienst stoppen + auf "Disabled" setzen, damit er nicht
#    zwischenzeitlich respawnt:
Stop-Service -Name "RustDesk*"
Set-Service  -Name "RustDesk*" -StartupType Disabled

# 2. ProductCode finden (siehe Abschnitt "Deinstallation" oben unter Windows-MSI):
$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. Aufräumen — gestopfter Konfig + Schlüssel:
Remove-Item -Path "C:\Windows\ServiceProfiles\LocalSystem\AppData\Roaming\{{ appName }}" `
            -Recurse -Force -ErrorAction SilentlyContinue

Achtung Schritt 4: löscht den LocalSystem-AppData-Pfad, in dem auch das gehashte Passwort liegt — bei einem späteren Re-Install muss das Passwort komplett neu gesetzt werden (kein Carry-Over). Falls Re-Install mit gleichem Passwort gewünscht ist, Schritt 4 weglassen — msiexec /x behält die Konfigdatei standardmäßig nicht, aber andere RustDesk-State-Files können relevant sein.

macOS — Deployment

Notarisierungs-Status

Das Bundle ist aktuell nicht notarisiert (kein Apple-Developer-ID-Signatur-Round-Trip durch notarytool), und das rdgen-Customizing bäckt die Server-Config nachträglich in die Binary — das bricht die Original-Signatur. Auf dem Mac äußert sich das je nach Chip unterschiedlich:

Mac	Symptom beim ersten Start
Apple Silicon (M1/M2/M3/M4)	„… ist beschädigt und kann nicht geöffnet werden" — oder die App startet kommentarlos gar nicht (der Kernel killt ungültig signierte arm64-Binaries ohne Dialog)
Intel	„… kann nicht geöffnet werden, da Apple sie nicht auf Schadsoftware überprüfen kann"

Quarantäne entfernen allein reicht auf Apple Silicon NICHT

Apple Silicon verlangt für jede arm64-App eine gültige Code-Signatur. Weil das rdgen-Customizing die Signatur bricht, killt der Kernel die App beim Start — auch nachdem das Quarantäne-Flag entfernt wurde (typisches Symptom: „keine Reaktion"). Nötig sind zwei Schritte: Quarantäne entfernen und das Bundle ad-hoc neu signieren.

Lösung Apple Silicon — Quarantäne entfernen + ad-hoc neu signieren

App zuerst nach Programme ziehen, dann beides einmalig im Terminal ausführen:

# 1. Quarantäne + alle erweiterten Attribute rekursiv entfernen
sudo xattr -cr "/Applications/<Name>.app"

# 2. Bundle ad-hoc neu signieren — stellt eine gültige Signatur her
sudo codesign --force --deep --sign - "/Applications/<Name>.app"

<Name> ist der exakte Name der App, wie er in Programme steht. Für die Pakete dieser Instanz:

Variante	App-Name in „Programme"
QuickSupport (Standard-Download)	BAUER GROUP QuickSupport
Unattended	BAUER GROUP Remote-Access

Danach startet die App normal und fragt nur noch nach Bildschirmaufnahme + Bedienungshilfen.

Warum das nicht im Build behoben wird

codesign ist ein macOS-only-Tool. Unsere Build-Pipeline läuft in einem Linux-Container und kann das Bundle technisch nicht gültig signieren. Die einzige vollständige Alternative wäre eine echte Notarisierung mit Apple-Developer-ID auf einem macOS-CI-Runner — bis dahin ist der Zwei-Schritt oben der zuverlässige Weg.

Manueller Override Intel (Einzelgerät)

Für die mildere Intel-Meldung genügt der UI-Weg:

1. Systemeinstellungen → Datenschutz & Sicherheit
2. Im Abschnitt Sicherheit: „BAUER GROUP Remote-Access wurde blockiert" → „Trotzdem öffnen"
3. Einmalig pro Gerät. App startet danach normal.

MDM-Deployment (Jamf, Munki, Kandji, Mosyle)

• Bundle als .pkg in eine PPPC-Profil-Policy einbinden, die ScreenCapture und Accessibility für die App-Bundle-ID vorgewährt
• Damit überspringt der erste Start beide System-Prompts — Nutzer sieht direkt die ID
• Bundle-ID + Code-Requirement aus codesign -dvvv "<Name>.app" extrahieren (z. B. "BAUER GROUP QuickSupport.app")

macOS-Berechtigungen (manuell)

Beim ersten Start fragt macOS nach:

• Bildschirmaufnahme — damit Support den Bildschirm sieht
• Bedienungshilfen — damit Support Maus/Tastatur steuern kann

Beide erforderlich für eine funktionierende Sitzung.

Android — Sideload + MDM

Manueller Sideload (Einzelgerät)

1. Einstellungen → Apps → Spezieller App-Zugriff → Unbekannte Apps installieren → für den verwendeten Browser/Datei-Manager aktivieren
2. APK herunterladen, antippen, Installieren
3. Beim Start: Bildschirmaufnahme / Casting erlauben

MDM (Intune for Android, Workspace ONE, Knox)

Standard-APK-Distribution über Managed Google Play oder direkt als Line-of-Business-App:

• Intune: Apps → Android → Line-of-business App → APK hochladen → Zuweisung „Required"
• Berechtigungen vorab per Android App Configuration Policy gewähren, dann kein User-Prompt beim Start

Bestehenden RustDesk-Client mit dem Server verbinden

Die Anleitungen oben rollen unseren vorkonfigurierten Custom-Client aus — Server-Hostname, Public-Key und Branding sind bereits eingebacken. Es gibt aber Szenarien, in denen ein bereits installierter Stock-RustDesk-Client (von rustdesk.com, Play Store oder App Store) auf eure Server zeigen soll:

• iOS — der App-Store-Build ist der einzige offizielle Weg; eigene IPA-Pakete bauen wir nicht
• Linux-Workstations — wir produzieren aktuell keine .deb/.rpm/.AppImage-Pakete
• Mobile Geräte ohne MDM — Privat-Smartphones, BYOD-Setups
• Notfall-Setup — während ein frischer Custom-Client-Build noch läuft (typisch beim ersten Deploy oder nach Server-Wechsel)
• Bestehende Installation umkonfigurieren — Geräte, auf denen der Stock-Client bereits läuft und auf andere Server (z.B. die öffentlichen RustDesk-Server) zeigt

Die Server-Verbindungsdaten (ID-Server, Relay-Server, Public-Key) plus eine Schritt-für-Schritt-Anleitung für Desktop und Mobile sind auf einer eigenen Seite hinterlegt — inklusive Copy-to-Clipboard für jeden Wert und mode-spezifischen Hinweisen (z.B. „Allow WebSocket" im WSS-Mode):

→ Manuelle Konfiguration öffnen

Warum eine separate Seite und nicht hier inline?

Die Seite ist absichtlich nicht in der Top-Navigation und nicht in Suchmaschinen indexiert — damit das Server-Setup nicht passiv über Google/Bing crawlbar wird. Die Werte selbst sind technisch nicht geheim (der Public-Key ist designgemäß die öffentliche Hälfte eines Schlüsselpaars), Hostnames müssen Clients eh kennen. Wir vermeiden trotzdem die passive Indexierung. Schick den Link einfach an die betroffenen Nutzer.

Wo werden Daten gespeichert?

Plattform	Lokaler Konfigurationspfad
Windows (MSI)	%APPDATA%\BAUER GROUP Remote-Access\ + Dienst-Settings unter C:\Windows\ServiceProfiles\LocalSystem\AppData\Roaming\BAUER GROUP Remote-Access\
Windows (Portable)	Nur im Speicher während des Betriebs
macOS	~/Library/Application Support/BAUER GROUP Remote-Access/
Android	App-interner Speicher, kein nutzerlesbarer Pfad

Nicht gespeichert: Sitzungs-Bildschirminhalte, Tastatureingaben, Mauszustand, Clipboard-Inhalte. Dieser Traffic läuft Ende-zu-Ende-verschlüsselt zwischen den beteiligten Geräten und passiert die BAUER GROUP Remote-Access-Server nur als opaque relay (wenn überhaupt — direkte P2P-Verbindung wird bevorzugt, siehe docs/networking.md im Repo).

Weitere Konfiguration

• Manuelle Konfiguration — Server-Verbindungsdaten + Schritt-für-Schritt-Anleitung für den Stock-RustDesk-Client (siehe Abschnitt oben „Bestehenden RustDesk-Client mit dem Server verbinden")
• Hilfe & Troubleshooting — End-User-orientierte FAQ für SmartScreen-Warnungen, Verbindungsabbrüche, Schlüsselkonflikte usw.