msp onboarding process: first 14 days, day-by-day

Neuer Kunde, neue Geräte und ein laufendes SLA — die ersten zwei Wochen entscheiden, ob das Onboarding in eine stabile Managed‑Beziehung oder in einen wiederkehrenden Feuerwehreinsatz übergeht. Dieser Artikel liefert einen praxisorientierten, tageweisen MSP‑Onboarding‑Prozess für die ersten 14 Tage einer Kundenflotte: was auszurollen ist, was zu prüfen ist, was zu automatisieren ist und wann zu eskalieren.

Ziele, Umfang und Annahmen

Dieses Playbook geht von einer Flotte von 25–500 Endpunkten aus, gemischt Windows und macOS mit einigen Linux‑Servern, einer zentralen Ticket‑Queue (SLA: 4 Geschäftsstunden für P2) und einem von Ihnen gesteuerten RMM. Der Fokus liegt auf unbeaufsichtigtem Zugriff, Inventarisierung, sicherer Baseline, Überwachung und Audit‑Trails. Wenn der Kunde eine ausschließlich interne Infrastruktur verlangt (Datenresidenz, keine Drittanbieter‑Relays), behandeln Sie Self‑Hosting als Compliance‑Anforderung — andernfalls ist der verwaltete Relay‑Dienst die operative Standardeinstellung.

Tools, Architektur und empfohlene Standardwerte

• Remote‑Zugriff: native Tenvo‑Clients für Windows/macOS/Linux sowie der Browser‑Client (öffentliche Beta). Nutzen Sie den von Tenvo verwalteten Multi‑Region‑Relay‑Dienst als Standard: er reduziert Aufwand für Bereitschaftsdienste, Zertifikatsrotation und Cross‑Region‑Failover. Tenvo‑Pläne: Free $0, Lite $2.99/mo, Pro $7.99/mo — wählen Sie nach Funktionen und Sitzungs‑Limits.
• Ticketing/RMM: integrieren Sie Session‑Start/Stop‑Webhooks in Ihr Ticketing‑System und RMM. Wenn Sie eine Checkliste für den Startpunkt eines Help‑Desk‑Workflows benötigen, siehe Help‑Desk‑Fernsupport einrichten.
• Audit & recording: planen Sie Audit‑Logging von Tag eins an. Wenn Ihr Vertrag lange Aufbewahrungsfristen verlangt, planen Sie den Speicherplatz neben dem Ticketsystem; siehe Remote‑Desktop‑Audit‑Logging für Muster.
• Wann Self‑Hosting: nur bei schriftlichen Compliance‑Auflagen, isolierten Netzwerken oder strikten Datenresidenz‑Vorgaben. Self‑Hosting bringt Zertifikats‑Ops, On‑Call‑Relay‑Failover und Patch‑Aufwand mit sich — das kostet häufig mehr an Betriebsaufwand als ein verwalteter Relay‑Dienst. Siehe Self‑Hosted Remote Desktop: Warum, wie und welche Probleme auftreten für die Abwägungen.
• Tool‑Auswahl: dieses Playbook zielt standardmäßig auf den von Tenvo verwalteten Relay‑Dienst. Wenn Sie zuerst Alternativen vergleichen wollen, prüfen Sie MSP Remote‑Support‑Tools: Den richtigen Stack für 2026 wählen.

Tag für Tag: die ersten 14 Tage (praktische Checkliste)

1. Tag 1 — Vertrags‑ und Zugriffs‑Kickoff (Tag 0, wenn Sie bevorzugen): Bestätigen Sie Umfang, SLAs, Übergabe privilegierter Konten und Wartungsfenster. Sammeln Sie Admin‑Zugangsdaten, VPN‑Infos und eine Liste der Verantwortlichen je Geschäftseinheit. Fügen Sie einen Notfallkontakt für Domain-/Controller‑Admins hinzu.
2. Tag 2 — Inventarisierung und Baseline‑Snapshot: Verteilen Sie den Agenten an eine Pilotgruppe (10–20 Geräte). Erfassen Sie Hardware/OS‑Details, installierte AV, Platten­nutzung und Basis‑Performance. Verwenden Sie Agent‑Tags für OS, Abteilung und Umgebung (prod/test).
3. Tag 3 — Unbeaufsichtigte Zugriffskonfiguration (Pilot): Aktivieren Sie auf Pilotgeräten unbeaufsichtigten Zugriff. Konfigurieren Sie rollenbasierten Zugriff für Techniker und fordern Sie starke Passwörter oder SSO, wo unterstützt. Verifizieren Sie, dass Session‑Start‑Ereignisse im Ticketing protokolliert werden.
4. Tag 4 — Zertifikats‑ und Netzwerkprüfung: Überprüfen Sie die Zertifikatsregistrierung und Konnektivität jedes Geräts. Prüfen Sie NAT‑Traversal: bestätigen Sie, welche Geräte P2P‑ vs. Relay‑Verbindungen nutzen. Hinweis: Wenn der Verkehr den Relay verwendet, terminiert TLS am Relay, sodass der Relay‑Betreiber Sitzungsdaten einsehen kann. Dokumentieren Sie, welche Subnetze Firewall‑Anpassungen benötigen.
5. Tag 5 — Firewall‑ und Gateway‑Regeln: Rollen Sie erforderliche FQDN/IP‑Allow‑Regeln und HTTP/S‑TLS‑Inspektions‑Ausnahmen aus, wenn Ihr Kunde Traffic inspiziert. Testen Sie einen Wechsel von blockiert zu erlaubt und einen erzwungenen Relay‑Pfad, um zu bestätigen, dass Sitzungen weiterhin aufbauen.
6. Tag 6 — Credential‑ und Vault‑Integration: Integrieren Sie Session‑Credential‑Injection oder ein Secrets‑Vault (Vault, Bitwarden, CyberArk) für privilegierte Sitzungen. Lagern Sie gemeinsame Admin‑Passwörter nicht weiter in Tabellen; legen Sie eine Rotations‑Kadenz (30–90 Tage) fest und dokumentieren Sie den Rotationsprozess im Runbook.
7. Tag 7 — Monitoring‑ und Alert‑Baseline: Fügen Sie Remote‑Access‑Healthchecks in die Überwachung ein (Agent‑Online‑%, Verbindungszeit‑Perzentile, Anzahl fehlgeschlagener Authentifizierungen). Setzen Sie Alert‑Schwellen: z. B. >3 fehlgeschlagene Sitzungen in 15 Min., Agent offline >30 Min.
8. Tag 8 — Skalierung des Rollouts: Erweitern Sie das Agent‑Rollout auf 50–75 % der Geräte. Nutzen Sie MSI/GPO oder Ihr RMM zur Automatisierung von Installationen. Planen Sie pro Abteilung ein Rollout‑Fenster, um Störungen zu begrenzen und bei Installationsproblemen schnell zurückzurollen.
9. Tag 9 — Sitzungsrichtlinien & Berechtigungen: Erzwingen Sie Least‑Privilege: Techniker erhalten nur die Gruppen, die sie benötigen. Erstellen Sie ein separates Break‑glass‑Verfahren für Notfallzugriffe mit Genehmigungen und aktivierter Audit‑Aufzeichnung.
10. Tag 10 — Integration mit Ticketing und SSO: Koppeln Sie Session‑APIs, um Session‑IDs und Logs automatisch an Tickets anzuhängen. Aktivieren Sie SAML/SSO (Okta, Azure AD) für Techniker‑Logins und testen Sie Provisioning-/Deprovisioning‑Flows.
11. Tag 11 — Aufzeichnungen und Aufbewahrungsrichtlinie: Wenn Sie Support‑Sitzungen aufzeichnen, setzen Sie die Aufbewahrung gemäß Vertrag und Datenschutzvorgaben. Speichern Sie Metadaten (Benutzer, Techniker, Ticket‑ID) zusammen mit den Aufzeichnungen zur Auditierbarkeit. Testen Sie Wiedergabe‑ und Redaktions‑Workflows, wo nötig.
12. Tag 12 — Performance‑ und UX‑Tuning: Messen Sie Sitzungs‑Latenz, Bildrate und Bandbreite. Optimieren Sie Codec‑Einstellungen, Zwischenablage‑Sync und Peripherie‑Redirection‑Richtlinien für stark genutzte Gruppen (Designer, Videoeditoren) und sperren Sie Funktionen, die für den regulären Support nicht benötigt werden.
13. Tag 13 — Backup‑ & Failover‑Test: Simulieren Sie einen Relay‑Ausfall und verifizieren Sie das Failover zu alternativen Regionen oder lokalen VPN‑Pfade. Wenn der Kunde externe Relays verbietet, prüfen Sie Ihr Self‑Hosted‑Relay‑Cluster auf Failover, Zertifikats‑Erneuerung und Monitoring.
14. Tag 14 — Review, SLA‑Abnahme und Runbook‑Handover: Führen Sie eine 60–90‑minütige Review mit dem Kunden durch: Inventarabdeckung, Incident‑Response‑Schritte, On‑Call‑Eskalation und einen rollierenden 30/60/90‑Tage‑Plan. Veröffentlichen Sie Runbooks und ein "what we watch"‑Dashboard. Schließen Sie die ticketbezogenen Onboarding‑Punkte und wandeln Sie wiederkehrende Onboarding‑Aufgaben in Automatisierungsaufgaben um.

Operative Checkliste nach Tag 14

• Tägliche/wöchentliche KPIs zum Nachverfolgen: Agent‑Abdeckung %, mittlere Verbindungszeit, First‑Call‑Resolution‑Rate, Anzahl der Break‑glass‑Ereignisse.
• Monatlich: Credential‑Rotation, Zertifikats‑Ablaufprüfungen und eine simulierte Incident‑Response‑Übung (Gerät aus Backup wiederherstellen und innerhalb des SLA verbinden).
• Runbooks: Pflegen Sie ein kurzes Runbook pro häufigem Ausfall (fehlgeschlagene Agent‑Installation, Zertifikats‑Mismatch, Relay‑Erreichbarkeit). Bewahren Sie Remediation‑Skripte im Source‑Control mit Änderungsverlauf auf.
• Audit & Compliance: Stellen Sie sicher, dass Session‑Logs vertraglich vorgeschrieben aufbewahrt werden; erwägen Sie längere Aufbewahrung für regulierte Kunden. Siehe Remote‑Desktop‑Audit‑Logging für Implementierungs‑Muster.
• Help‑Desk‑Wiring: Sorgen Sie dafür, dass Techniker das minimale Toolset für Sicherheit und Geschwindigkeit haben. Für Workflow‑Playbooks und ticketgetriebene Sessions siehe Help‑Desk‑Fernsupport einrichten.

Wann Managed Relay vs. Self‑Host wählen

Standard: Verwenden Sie den von Tenvo verwalteten Relay‑Dienst. Er nimmt die Last für Region‑Failover, Zertifikatsverteilung und 24/7‑Relay‑Betrieb ab. Verwaltete Relays reduzieren die mittlere Reparaturzeit, weil Sie die Relay‑Infrastruktur nicht betreiben, Zertifikate über Regionen hinweg erneuern oder Schlüsselverwahrung managen müssen.

Self‑Host nur, wenn der Kundenvertrag Drittrelays ausdrücklich verbietet oder das Netzwerk isoliert ist. Self‑Hosting erfordert den Betrieb eines HA‑Relay‑Clusters, automatisierte Zertifikats‑Erneuerung, Monitoring und Patch‑Management — berücksichtigen Sie dabei den fortlaufenden Betriebs‑Personalbedarf und das SLA‑Risiko. Für eine technische Durcharbeitung der Self‑Host‑Abwägungen sehen Sie Self‑Hosted Remote Desktop: Warum, wie und welche Probleme auftreten. Wenn Sie Anbieter vergleichen, hilft dieser Artikel bei der Größenabschätzung der operativen Unterschiede: MSP Remote‑Support‑Tools: Den richtigen Stack für 2026 wählen.

Praktische Skripte, Installationsbeispiele und Verifikationsbefehle

REM Windows MSI silent install (example)
msiexec /i "tenvo-agent.msi" /qn /norestart /l*v "C:\Windows\Temp\tenvo-install.log"

# PowerShell: verify agent is installed and running
Get-Service -Name TenvoAgent | Select-Object Name, Status

# Powershell: check certificate thumbprint and expiry (local store)
Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object { $_.Subject -like "CN=tenvo-*" } | Select-Object Subject, Thumbprint, NotAfter

# macOS: pkg install and verify
sudo installer -pkg tenvo-agent.pkg -target /
launchctl list | grep com.tenvo.agent

# Test connectivity: verify P2P vs relay (example agent tool)
tenvo-agent --diag --show-connection
# Expect output: P2P:true or Relay:us-east.tenvo.net

Sicherheitshinweise und Realitätscheck

Seien Sie gegenüber Kunden explizit bezüglich des Bedrohungsmodells: Eine direkte Peer‑to‑Peer‑Sitzung ist Ende‑zu‑Ende zwischen den beiden Geräten. Wenn die Verbindung auf einen Relay ausweicht, terminiert TLS am Relay, sodass der Relay‑Betreiber Sitzungsdaten beobachten kann. Tenvo's verwalteter Relay‑Dienst nutzt standardmäßig per‑Device‑Zertifikate und Multi‑Region‑Relays; das reduziert das operationelle Risiko, eliminiert aber nicht die Notwendigkeit, Relays als Infrastruktur mit Zugriffsbefugnissen zu behandeln. Wenn der Kunde keine Dritt‑Relay‑Betreiber tolerieren kann, planen Sie Self‑Hosting ein und budgetieren Sie den fortlaufenden Betriebsaufwand.

Häufige Fallen und wie man sie vermeidet

• Flächendeckendes Rollout auf alle Geräte gleichzeitig: führt zu Help‑Desk‑Überlastung. Staffelung nach Abteilung und Monitoring der Ticket‑Queue während des Rollouts.
• Auslassen von Zertifikatsprüfungen: planen Sie automatisierte Ablaufprüfungen und einen Alert für Zertifikate mit <30 Tagen Restlaufzeit.
• Kein Break‑glass‑Audit‑Trail: Jeder Notfallzugriff muss ein Audit‑Ticket und eine Aufzeichnung erfordern, um Missbrauch zu vermeiden.
• Annahme, Self‑Host sei günstiger: Berücksichtigen Sie On‑Call, Patching, Backups und Failover‑Tests in Kostenmodellen. Für einen realistischen TCO‑Vergleich siehe die MSP‑Tool‑Analyse in MSP Remote‑Support‑Tools: Den richtigen Stack für 2026 wählen.

Das Onboarding einer neuen Kundenflotte ist überwiegend Koordination und Automatisierung: Erfassen Sie die Inventarisierung korrekt, sperren Sie Zugänge und Credentials, machen Sie Monitoring handlungsfähig und automatisieren Sie wiederkehrende Fixes innerhalb der ersten 14 Tage, damit Sie das Feuerlöschen beenden und stabilen Betrieb liefern. Wenn Sie einen client‑bereiten Agenten und einen verwalteten Relay‑Dienst möchten, um Relay‑Ops zu vermeiden, beginnen Sie mit dem Herunterladen der Clients und testen Sie heute eine Pilotinstallation.

Tenvo herunterladen, um eine Pilot‑Bereitstellung zu starten und dieses 14‑tägige Playbook zu befolgen. Wenn Sie tiefere Konfigurationsbeispiele oder eine Migrations‑Checkliste benötigen, bieten unsere Dokumentation und die verlinkten Artikel Schritt‑für‑Schritt‑Anleitungen.