Remote-Support-Tools: Fernwartung im IT-Alltag

Was ist Remote-Support – und warum brauchst du das?

Jemand ruft an: “Mein Excel rechnet falsch, kannst du kurz schauen?” Du bist im Homeoffice, die Person sitzt im Aussenbüro, und physisch hinfahren dauert 45 Minuten. Genau hier kommen Remote-Support-Tools ins Spiel.

Mit Fernwartungs-Software verbindest du dich direkt auf den Bildschirm des anderen Rechners, siehst was der User sieht, übernimmst die Maus und kannst das Problem in Minuten lösen. Das spart Zeit, senkt Reisekosten und erhöht die Erstlösungsrate erheblich.

Im KMU-Alltag nutzt du Remote-Support für:

• Schnelle Fehlerdiagnose ohne Anfahrtsweg
• Software-Installationen auf entfernten Geräten
• Schulungen (“Ich zeig dir kurz, wie das geht”)
• Support für Homeoffice-Mitarbeitende
• Unterstützung von externen Dienstleistern auf firmeneigenen Geräten

Tool-Vergleich auf einen Blick

Windows Quick Assist – der Nullaufwand-Einstieg

Quick Assist ist in Windows 10 und 11 fest integriert. Kein Download, kein Konto, kein Abo. Für den gelegentlichen internen Support in kleinen Teams ist das oft genug.

Öffnen (Supporter und User):

Tastenkombination: Strg + Win + Q
oder: Start > "Schnellhilfe" suchen

Ablauf aus Sicht des Supporters:

1. Quick Assist öffnen → “Helfen” klicken
2. Microsoft-Konto anmelden (einmalig)
3. Den angezeigten 6-stelligen Code dem User mitteilen (z.B. per Telefon oder Teams)
4. User gibt den Code auf seinem Gerät ein und bestätigt die Verbindung
5. Du siehst den Bildschirm des Users – wahlweise nur beobachten oder volle Kontrolle übernehmen

Einschränkungen Quick Assist:

• Kein Unattended Access (User muss immer aktiv bestätigen)
• Nur Windows zu Windows
• Sitzung läuft nach 10 Minuten ohne Interaktion ab
• Keine Dateiübertragung über das Tool selbst
• Kein Session-Protokoll / Aufzeichnung

TeamViewer – der Standard im KMU

TeamViewer ist das am weitesten verbreitete Fernwartungs-Tool. Praktisch jeder IT-Allrounder kennt es, viele Hersteller-Support-Abteilungen setzen es ein. Das ist ein echter Vorteil: Wenn du einem User sagst “Lad bitte TeamViewer herunter und gib mir die ID”, weiss die Hälfte bereits was gemeint ist.

QuickSupport vs. vollständige Installation:

• TeamViewer QuickSupport: Kleines EXE, das der User ohne Installation starten kann. Einmaliger Support. Ideal für Enduser.
• TeamViewer (Vollinstallation): Für permanenten Unattended Access auf eigenen Geräten.

Verbindungsaufbau (Supporter-Seite):

# TeamViewer ID des Zielgeräts per Registry auslesen (für Inventar/Skripte)
Get-ItemProperty "HKLM:\SOFTWARE\WOW6432Node\TeamViewer" -Name ClientID
# Auf 64-Bit-System ohne WOW6432Node:
Get-ItemProperty "HKLM:\SOFTWARE\TeamViewer" -Name ClientID

Unattended Access per Mass-Deployment einrichten:

Wenn du TeamViewer auf vielen Geräten ausrollen willst (z.B. via GPO oder Intune), kannst du mit einem Customization-Paket aus dem TeamViewer Management Console arbeiten:

# Stilles Deployment mit vorbereiteter MSI (aus TeamViewer Management Console exportiert)
msiexec /i TeamViewer_Host.msi /quiet CUSTOMCONFIGID=<deine-config-id> APITOKEN=<dein-token>

# Gerät einem Konto zuweisen (nach Installation)
TeamViewer.exe --assignid <account-id> --grant-easy-access

AnyDesk – schnell und EU-konform

AnyDesk punktet mit niedrigerer Latenz dank des proprietären DeskRT-Codecs und hatte lange einen günstigeren Einstiegspreis als TeamViewer. Die EU-Server-Option macht DSGVO-Compliance einfacher. Seit den Lizenzänderungen Oktober 2025 lohnt sich ein genauer Preisvergleich.

AnyDesk-ID per PowerShell auslesen:

# AnyDesk-ID aus dem Konfigurationsordner lesen
$configPath = "$env:APPDATA\AnyDesk\system.conf"
if (Test-Path $configPath) {
    Get-Content $configPath | Select-String "ad.anynet.id"
}

# Alternativ aus dem AnyDesk-Prozess
(Get-Process AnyDesk -ErrorAction SilentlyContinue).MainWindowTitle

Unattended Access konfigurieren:

In den AnyDesk-Einstellungen unter “Sicherheit” → “Unbeaufsichtigter Zugriff” setzt du ein Passwort. Dieses Passwort verwaltest du am besten zentral in deinem Passwort-Manager.

RustDesk – Open Source mit Self-Hosting

RustDesk ist die einzige komplett quelloffene Lösung in dieser Liste. Du kannst deinen eigenen Relay-Server betreiben – dann läuft kein Traffic über Server Dritter. Für Organisationen mit hohen Datenschutzanforderungen oder ohne Budget für kommerzielle Tools eine echte Alternative.

Architektur verstehen:

RustDesk braucht zwei Server-Komponenten:

• hbbs (ID/Rendezvous-Server): Vermittelt Verbindungen, speichert IDs
• hbbr (Relay-Server): Leitet Traffic weiter wenn Direkt-Verbindung (NAT) nicht klappt

Self-hosted RustDesk-Server mit Docker:

# docker-compose.yml für RustDesk-Server
version: "3"
services:
  hbbs:
    image: rustdesk/rustdesk-server:latest
    command: hbbs
    volumes:
      - ./data:/root
    ports:
      - "21115:21115"
      - "21116:21116"
      - "21116:21116/udp"
      - "21118:21118"
    restart: unless-stopped

  hbbr:
    image: rustdesk/rustdesk-server:latest
    command: hbbr
    volumes:
      - ./data:/root
    ports:
      - "21117:21117"
      - "21119:21119"
    restart: unless-stopped

# Starten
docker compose up -d

# Public Key auslesen (für Client-Konfiguration nötig)
cat data/id_ed25519.pub

RustDesk-Clients auf den eigenen Server zeigen:

In der RustDesk-Anwendung unter Einstellungen → Netzwerk:

• ID-Server: deine-server-ip-oder-domain
• Relay-Server: deine-server-ip-oder-domain
• API-Server: leer lassen
• Key: <public-key aus id_ed25519.pub>

Microsoft Remote Help – für Intune-Umgebungen

Wenn deine Organisation Microsoft Intune einsetzt (Bestandteil von M365 Business Premium), ist Microsoft Remote Help die integrierte Alternative. Es ist direkt im Intune Admin Center verankert, jede Session wird protokolliert und du kannst Geräte auch dann supporten, wenn der User nicht angemeldet ist (Elevated Privileges).

Voraussetzungen:

• M365 Business Premium oder Remote Help Add-on-Lizenz
• Gerät in Intune enrollt
• Remote Help App auf beiden Seiten installiert

Session starten:

# Remote Help App installieren (z.B. via Intune oder manuell)
winget install Microsoft.RemoteHelp

Der Supporter sucht das Gerät im Intune Portal unter “Devices” → “Remote actions” → “New Remote Assistance Session”. Alternativ direkt per Remote Help App über den Entra ID-Account des Users verbinden.

Mobile Device Remote Support: Intune Remote Actions

Bei Smartphones und Tablets kannst du nicht einfach eine Fernwartungs-Software installieren wie auf einem Windows-PC – iOS und Android schränken Bildschirmzugriff aus Sicherheitsgründen stark ein. Für Intune-verwaltete Mobilgeräte gibt es deshalb zwei unterschiedliche Werkzeugkategorien: einfache Remote Actions direkt im Intune Admin Center und echte Remote-View/Remote-Control-Sessions über eine Connector-Integration.

Remote Actions ohne Bildschirmzugriff (immer verfügbar, alle Plattformen):

# Remote Actions per Microsoft Graph (Beispiel: Gerät sperren)
Connect-MgGraph -Scopes "DeviceManagementManagedDevices.PrivilegedOperations.All"
Invoke-MgLockManagedDevice -ManagedDeviceId "<geraete-id>"

Echter Bildschirmzugriff auf Mobilgeräte:

Seit April 2026 hat Microsoft die TeamViewer-Remote-Assistance-Integration in Intune komplett überarbeitet: einfacheres Setup, SSO, Gerätegruppen-Synchronisation und feingranulare Rollenrechte. Die neue Integration unterstützt echten Bildschirmzugriff und -steuerung für Windows, macOS, iOS und Android, benötigt aber TeamViewer Tensor (oder ein vergleichbares Enterprise-Lizenzmodell) mit Microsoft-Add-on – reine Intune-Lizenzierung reicht nicht.

Sicherheit: Die wichtigsten Regeln

Remote-Support-Tools sind mächtig – und genau deshalb ein beliebtes Angriffsziel. Social-Engineering-Angriffe missbrauchen gezielt den “Microsoft-Support ruft an und braucht Fernzugriff”-Trick.

Checkliste für sicheren Remote-Support-Betrieb:

• Unattended Access nur für eigene Firmengeräte – niemals auf Privat-PCs einrichten
• Whitelist nutzen: TeamViewer und AnyDesk erlauben, Verbindungen auf bekannte Account-IDs zu beschränken
• Zwei-Faktor-Authentifizierung auf dem Management-Konto aktivieren
• Session-Aufzeichnung aktivieren (je nach Tool und Compliance-Anforderung)
• Datenschutz-AVV abschliessen mit TeamViewer / AnyDesk wenn du auf Geräten mit Personendaten arbeitest (DSGVO-Pflicht)
• Tool-Version aktuell halten – Remote-Support-Clients sind ein häufiges Angriffsziel

Unattended-Access-Passwörter sicher verwalten:

# TeamViewer ID aller verwalteten Geräte exportieren (aus Registry via Skript)
$computers = Get-ADComputer -Filter * | Select-Object -ExpandProperty Name
foreach ($pc in $computers) {
    $id = Invoke-Command -ComputerName $pc -ScriptBlock {
        (Get-ItemProperty "HKLM:\SOFTWARE\WOW6432Node\TeamViewer" -ErrorAction SilentlyContinue).ClientID
    } -ErrorAction SilentlyContinue
    if ($id) {
        [PSCustomObject]@{ Computer = $pc; TeamViewerID = $id }
    }
}

Privileged Access Workstation (PAW) und Jump-Host: Admin-Fernzugriff richtig absichern

Alles bisher Beschriebene gilt für den Support von Enduser-Geräten. Sobald du dich als Administrator auf Domain Controller, Hypervisoren oder andere Tier-0/Tier-1-Systeme verbindest, reicht “TeamViewer draufmachen” nicht mehr – hier brauchst du ein sauberes Zugriffskonzept. Der Grund: Dein normaler Arbeitsplatz-PC, auf dem du auch Mails liest und im Web surfst, ist ein Angriffsziel. Wenn du von genau diesem Gerät aus Domain-Admin-Rechte nutzt, reicht ein einziger erfolgreicher Phishing-Klick, um die gesamte Domäne zu kompromittieren.

Genau das adressiert das Clean-Source-Prinzip: Die Quelle eines privilegierten Zugriffs muss mindestens so vertrauenswürdig sein wie das Ziel, das sie verwaltet. Microsoft übersetzt das in zwei ergänzende Bausteine:

• Privileged Access Workstation (PAW): Ein dediziertes, stark gehärtetes Gerät ausschliesslich für administrative Tätigkeiten. Kein Internet-Browsing, keine Mails, keine Produktivitäts-Apps – nur die Werkzeuge, die für die Verwaltung nötig sind (RSAT, PowerShell, Admin-Konsolen). Idealerweise mit eigenem, separat verwalteten Admin-Konto angemeldet, das nirgendwo sonst verwendet wird.
• Jump-Host (Jump-Server): Ein zentraler Sprungserver – häufig ein RDS-/Terminalserver –, über den alle administrativen RDP-Verbindungen zu Servern laufen. Direkter RDP-Zugriff von Admin-Arbeitsplätzen auf Produktivserver wird per Firewall-Regel unterbunden.

In einer ausgereiften Architektur greifst du von der PAW aus per RDP auf den Jump-Host zu, und erst von dort aus auf den eigentlichen Zielserver. Das ergibt zwei unabhängige Kontroll- und Protokollierungsebenen: Die PAW schützt den Ursprung der Session (dein Gerät ist sauber), der Jump-Host bietet einen kontrollierten, zentral auditierbaren Pfad zum Ziel.

# Beispiel: Firewall-Regel auf einem Tier-0-Server, die RDP nur vom Jump-Host-Subnetz erlaubt
New-NetFirewallRule -DisplayName "RDP nur von Jump-Host" `
  -Direction Inbound -Protocol TCP -LocalPort 3389 `
  -RemoteAddress 10.10.50.0/24 -Action Allow
New-NetFirewallRule -DisplayName "RDP von allen anderen blockieren" `
  -Direction Inbound -Protocol TCP -LocalPort 3389 `
  -RemoteAddress Any -Action Block

Für kleinere KMU ist eine vollwertige, physisch getrennte PAW oft überdimensioniert. Ein praxistauglicher Mittelweg: eine gehärtete virtuelle Maschine ausschliesslich für Admin-Tätigkeiten, die auf dem Alltagsgerät läuft, aber keinen Internetzugang hat und nur über den Jump-Host administrative Verbindungen aufbauen darf.

Out-of-Band-Management: Zugriff via iLO, iDRAC und IPMI, wenn nichts mehr geht

Alle bisherigen Tools setzen voraus, dass das Betriebssystem läuft und eine Netzwerkverbindung besteht. Genau dann versagen sie, wenn du sie am dringendsten brauchst: Server hängt beim Boot, BIOS-Einstellung muss geändert werden, Betriebssystem ist abgestürzt, oder das Netzwerkinterface selbst ist defekt konfiguriert. Für diese Fälle hat praktisch jeder Server-Hersteller einen unabhängigen Management-Chip verbaut, der komplett getrennt vom Hauptsystem läuft – Out-of-Band-Management (OOB).

Der grosse Vorteil: Diese Management-Controller haben eine eigene Netzwerkschnittstelle, ein eigenes Betriebssystem und laufen weiter, solange der Server am Strom hängt – selbst wenn das Hauptsystem komplett ausgeschaltet oder abgestürzt ist. Du bekommst virtuelle Tastatur/Maus/Bildschirm (iKVM), kannst ISO-Images virtuell einlegen, den Server hart aus- und wieder einschalten und BIOS/UEFI-Einstellungen ändern – alles ohne physisch vor Ort zu sein. Mehr zur Server-Hardware selbst findest du unter Server-Hardware-Grundlagen.

Beispiel Dell iDRAC per racadm (SSH oder Remote-RACADM):

# Systeminformationen abfragen
racadm getsysinfo

# Server hart neu starten
racadm serveraction powercycle

# Aktuellen Stromstatus abfragen
racadm serveraction powerstatus

Beispiel HPE iLO per ilorest:

# Verbindung zum iLO aufbauen und Power-Status abfragen
ilorest login <ilo-ip> -u administrator -p <passwort>
ilorest power
ilorest power on
ilorest power reset

Beispiel generisches IPMI per ipmitool (Linux-Management-Station):

# Stromstatus des Zielservers abfragen
ipmitool -I lanplus -H <bmc-ip> -U admin -P <passwort> power status

# Server per Power-Cycle neu starten
ipmitool -I lanplus -H <bmc-ip> -U admin -P <passwort> power cycle

# Serial-over-LAN-Konsole aktivieren (z.B. für Linux-Boot-Menü ohne GUI)
ipmitool -I lanplus -H <bmc-ip> -U admin -P <passwort> sol activate

Reverse-Tunnel-Konzepte für fremde Firewall- und NAT-Umgebungen

Kommerzielle Remote-Support-Tools wie TeamViewer oder AnyDesk lösen das NAT-Problem für dich automatisch: Beide Seiten bauen ausgehend eine Verbindung zu den Herstellerservern auf, die den Traffic dann vermitteln – deshalb funktionieren sie meist ohne Portfreigaben. Wenn du aber eigene Dienste (SSH, RDP, eine Web-Oberfläche) auf einem Gerät erreichen willst, das hinter einer fremden Firewall oder einem Router mit NAT sitzt, auf den du keinen administrativen Zugriff hast – zum Beispiel bei einem Kunden vor Ort, in einer Fabrikhalle mit restriktivem Netzwerk oder bei einem IoT-Gerät im Feld – hilft ein Reverse-Tunnel.

Das Prinzip: Statt dass du dich von aussen nach innen verbindest (was durch NAT/Firewall blockiert wird), baut das Gerät selbst eine ausgehende Verbindung zu einem Server auf, den du kontrollierst. Über diese bereits bestehende Verbindung tunnelst du dann Traffic in die Gegenrichtung.

# Auf dem Zielgerät (hinter NAT) ausführen: baut eine ausgehende SSH-Verbindung
# zu deinem öffentlich erreichbaren Server auf und öffnet dort Port 5000,
# der auf den lokalen SSH-Port 22 des Zielgeräts zeigt
ssh -fN -R 5000:localhost:22 supportuser@dein-oeffentlicher-server.de

# Von deinem Support-Rechner aus verbindest du dich über den öffentlichen Server
# auf den getunnelten Port – und landest auf dem Zielgerät
ssh -J supportuser@dein-oeffentlicher-server.de localhost -p 5000

Für dauerhafte Tunnel eignet sich autossh, das die Verbindung bei Abbruch automatisch neu aufbaut:

autossh -M 0 -f -N -R 5000:localhost:22 supportuser@dein-oeffentlicher-server.de \
  -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3"

VPN + RDP vs. Screen-Sharing-Tools: Wann ist was sicherer?

Eine Frage, die in jedem Security-Review auftaucht: Sollen Admins per VPN und anschliessendem RDP auf Server zugreifen, oder ist ein Screen-Sharing-Tool wie TeamViewer/AnyDesk die bessere Wahl? Die ehrliche Antwort: Es kommt auf den Einsatzzweck an – beide Modelle haben unterschiedliche Angriffsflächen.

Faustregel aus der Praxis:

• Server- und Infrastruktur-Administration: VPN + RDP (oder besser: PAW + Jump-Host, siehe oben) ist die robustere Wahl. Du bekommst volle Kontrolle, Protokollierung im eigenen Active Directory und musst niemandem vertrauen ausser deiner eigenen Infrastruktur.
• Ad-hoc-Support für Enduser: Screen-Sharing-Tools sind unschlagbar praktisch, weil sie ohne Netzwerkkonfiguration funktionieren und der User aktiv mitverfolgen kann, was passiert.
• Hybrid-Ansatz: Viele Organisationen nutzen VPN+RDP für alles, was mit Servern zu tun hat, und Screen-Sharing ausschliesslich für Client-Support. Für höchste Sicherheitsanforderungen ergänzt eine Zero-Trust-Architektur beide Modelle um kontinuierliche Verifizierung statt einmaliger Anmeldung.

Session-Recording und Audit-Trail für regulierte Umgebungen

In Branchen mit Compliance-Anforderungen (Finanzdienstleister, Gesundheitswesen, Betreiber kritischer Infrastrukturen) reicht “wir haben TeamViewer benutzt” als Nachweis nicht aus. Prüfer wollen sehen: Wer hat sich wann auf welches System verbunden, was genau wurde dort gemacht, und ist die Aufzeichnung unveränderbar gespeichert.

Was ein belastbarer Audit-Trail für Remote-Support typischerweise umfasst:

• Verbindungsprotokoll: Zeitstempel, Quelle, Ziel, verwendetes Konto, Dauer der Session
• Bildschirmaufzeichnung (Session Recording): Video- oder Frame-basierte Aufzeichnung der gesamten Sitzung, oft inklusive Tastatureingaben-Log
• Command-Logging: Bei Terminal-/CLI-Sessions eine textbasierte Aufzeichnung aller eingegebenen Befehle
• Unveränderlichkeit: Aufzeichnungen werden in ein separates, mit eigenen Rechten geschütztes Storage geschrieben – der Administrator, der die Session durchführt, darf sie nicht selbst löschen können
• Vier-Augen-Freigabe: Bei hochkritischen Systemen muss eine zweite Person die Session live freigeben oder mitverfolgen (Session-Genehmigung statt reiner Aufzeichnung)

Wo das in der Praxis herkommt:

# PowerShell-Transcription auf einem Jump-Host per GPO-Registry-Pfad aktivieren
# (idealerweise zentral über Gruppenrichtlinie ausgerollt, hier zur Veranschaulichung lokal)
$path = "HKLM:\Software\Policies\Microsoft\Windows\PowerShell\Transcription"
New-Item -Path $path -Force | Out-Null
Set-ItemProperty -Path $path -Name "EnableTranscripting" -Value 1
Set-ItemProperty -Path $path -Name "OutputDirectory" -Value "\\log-server\pshistory\$env:COMPUTERNAME"
Set-ItemProperty -Path $path -Name "EnableInvocationHeader" -Value 1

Für kleinere KMU ohne PAM-Budget ist ein pragmatischer Einstieg: Aktiviere die eingebauten Aufzeichnungsfunktionen von TeamViewer/AnyDesk (sofern lizenziert), erzwinge PowerShell-Transcription auf allen Servern per GPO, und definiere klar, wie lange diese Protokolle aufbewahrt werden.

Troubleshooting: Häufige Probleme

Verbindung schlägt fehl / Timeout:

1. Prüfe ob das Remote-Support-Tool auf dem Zielgerät läuft (tasklist | findstr TeamViewer)
2. Prüfe ob der Dienst gestartet ist:

   Get-Service -Name TeamViewer -ErrorAction SilentlyContinue
   Get-Service -Name AnyDesk -ErrorAction SilentlyContinue

3. Firewall-Ausnahmen prüfen (meist automatisch durch Installer gesetzt)
4. Prüfe ob ein Proxy die Verbindung blockiert – Remote-Tools brauchen ausgehend HTTPS (Port 443) und in manchen Fällen weitere Ports

Quick Assist zeigt “Verbindung nicht möglich”:

• Stelle sicher dass beide Seiten Windows 10 Version 1903 oder neuer verwenden
• Quick Assist benötigt einen Microsoft-Account auf Supporter-Seite
• In Unternehmensumgebungen kann Windows Defender Credential Guard Quick Assist blockieren – im Ereignis-Viewer nach Fehlern suchen (Ereignisanzeige)

User sieht “Fernzugriff verweigert” bei RustDesk:

# RustDesk-Server-Logs prüfen (Docker)
docker logs rustdesk-hbbs-1 --tail 50
docker logs rustdesk-hbbr-1 --tail 50

Häufigste Ursache: Der Public Key auf dem Client stimmt nicht mit dem Server überein. Key neu aus data/id_ed25519.pub kopieren und im Client eintragen.

AnyDesk startet nicht / hängt beim Verbinden:

# AnyDesk-Dienst neu starten
Restart-Service -Name AnyDesk -ErrorAction SilentlyContinue

# AnyDesk-Logs prüfen
Get-Content "$env:APPDATA\AnyDesk\ad.trace" -Tail 50

Wann welches Tool?

Weiterlernen

• Microsoft: Quick Assist verwenden (offizielle Doku, DE)
• RustDesk Self-Hosting Dokumentation (EN)
• TeamViewer: Erste Schritte mit TeamViewer Remote (EN)
• AnyDesk DSGVO-Compliance (EN)
• MSXFaq: Quick Assist / RemoteHilfe (DE)
• RDP-Grundlagen – wenn du eine eigene Session statt Bildschirmübertragung brauchst
• Microsoft: Privileged Access Devices – offizielle Doku (EN)
• Microsoft: Remotely administer devices in Intune (EN)
• Dell: RACADM Command Line Reference Guide (EN)
• ipmitool Cheat Sheet – Thomas-Krenn (DE)

Verwandte Themen: RDP-Grundlagen · VPN-Grundlagen · AD-Security-Hardening und Tier-Modell · Entra PIM Governance · Server-Hardware-Grundlagen · SSH-Grundlagen · Intune-Grundlagen · Troubleshooting-Methodik · Ticketsystem-Grundlagen

Videos

YouTube