SaaS Performance Troubleshooting: M365 & Co. richtig messen

SaaS Performance Troubleshooting ist eine der anspruchsvollsten Aufgaben im modernen IT-Betrieb, weil sich der eigentliche Dienst (z. B. Microsoft 365, Salesforce, ServiceNow oder Zoom) außerhalb Ihrer direkten Kontrolle befindet. Gleichzeitig erwarten Nutzer eine „LAN-ähnliche“ Reaktionszeit – auch im Homeoffice, über VPN, im Gastnetz oder auf Reisen. Wenn M365 & Co. als „langsam“ wahrgenommen werden, ist die Ursache selten „zu wenig Bandbreite“. Viel häufiger sind es Latenzspitzen, Jitter, Paketverlust, ungünstige Proxy-/VPN-Pfade, falsche DNS-Auflösung oder eine suboptimale Anbindung an das Cloud-Edge-Netzwerk des Providers. Hinzu kommt ein Messproblem: Klassische Speedtests messen oft nur große Downloads zu beliebigen Servern – nicht aber den relevanten Pfad zu den SaaS-Frontdoors, nicht die TLS-Handshake-Zeit, nicht die Stabilität unter Last und nicht die Unterschiede zwischen Standorten, ISPs und Egress-Punkten. In diesem Artikel lernen Sie, wie Sie SaaS-Performance professionell und belastbar messen: Welche Kennzahlen wirklich zählen, wie Sie M365-Netzwerktests und Assessments nutzen, wie Sie Pfade und Egress-Strategien bewerten und wie Sie aus Messdaten konkrete Maßnahmen ableiten, die die Nutzererfahrung nachweislich verbessern.

Was „SaaS ist langsam“ in Messwerte übersetzt

Bevor Sie Tools starten, übersetzen Sie die Nutzerwahrnehmung in messbare Größen. SaaS-Performance wird typischerweise durch vier Faktoren geprägt:

• Latenz (RTT): Zeit für Hin- und Rückweg. Kritisch für interaktive Apps (Outlook, Teams-Chat, SharePoint-UI, VDI/RDP).
• Jitter: Schwankung der Latenz. Kritisch für Meetings/VoIP, Screen Sharing und Echtzeit-Streams.
• Paketverlust: Führt zu Retransmissions, stockendem UI-Load und schlechter Medienqualität.
• Pfad/Policy: Proxy, TLS-Inspection, VPN-Hairpinning und falsche Egress-Punkte machen selbst bei „guter“ Bandbreite alles zäh.

Wichtig: Bandbreite ist nur dann Engpass, wenn sie wirklich dauerhaft ausgereizt ist. In vielen Fällen ist Bandbreite ausreichend, aber Queueing (Bufferbloat), Inspection oder ungünstige Pfade erzeugen Latenzspitzen – und damit gefühlte Langsamkeit.

Der entscheidende Unterschied: „Internet-Speed“ vs. „SaaS-Pfadqualität“

Ein Speedtest misst häufig zu einem nahegelegenen CDN- oder ISP-Server und optimiert für Durchsatz. SaaS-User-Experience hängt jedoch an anderen Teilstrecken:

• DNS & Anycast/Frontdoor-Auswahl: Welcher SaaS-Edge wird überhaupt genutzt?
• TLS-Handshake & TCP-Verhalten: Retransmissions, MTU, Proxy-Interception, SNI/ALPN.
• App-spezifische Protokolle: WebSockets, UDP (z. B. Medien), HTTP/2/HTTP/3, große Objektlisten (SharePoint).
• Egress-Design: Lokaler Internet-Breakout vs. zentraler Proxy in der Zentrale vs. Cloud-SWG.

Für Microsoft 365 ist es besonders relevant, ob Sie „optimal“ in Microsofts globales Netzwerk gelangen und ob der genutzte Frontdoor-Standort zu Ihrer Location passt. Microsoft beschreibt dafür Prinzipien zur Netzwerk-Konnektivität und Optimierung. Siehe die Microsoft 365 network connectivity principles.

Messstrategie: So messen Sie SaaS korrekt und vergleichbar

Professionelles Troubleshooting besteht aus reproduzierbaren Messungen, die Sie vor und nach Änderungen vergleichen können. Bewährt hat sich eine Kombination aus drei Ebenen:

• Endnutzer-Messung (Real User): Was erlebt der Nutzer wirklich (Office Location, WLAN/ISP, Gerätetyp)?
• Synthetische Messung: Regelmäßige Tests von definierten Standorten zu definierten SaaS-Endpunkten.
• Netzwerk-Telemetrie: Flow/Proxy/Firewall-Metriken, Drops, Queueing, Egress-Pfade, Bypass-Regeln.

Ein Minimum an Kennzahlen, das fast immer reicht

• RTT zum SaaS-Edge (nicht nur zu 8.8.8.8)
• Paketverlust (in beide Richtungen, wenn möglich)
• DNS-Antwortzeit und Resolver-Pfad
• TLS-Handshake-Zeit (ClientHello → Finished) als Indikator für Inspection/Path-Issues
• HTTP Time To First Byte (TTFB) für Web-Apps

M365 & Co. richtig messen: Microsoft-spezifische Tools, die wirklich helfen

Bei Microsoft 365 sollten Sie nicht „irgendeinen“ Ping verwenden, sondern die von Microsoft vorgesehenen Messpunkte und Auswertungen, die auf die M365-Frontdoors und -Protokolle abgestimmt sind.

Microsoft 365 Network Connectivity Test

Ein zentraler Einstieg ist der Microsoft 365 Network Connectivity Test unter connectivity.office.com. Der Test prüft unter anderem TCP-Latenz zur Microsoft-Frontdoor und kann einen Bericht erzeugen, der sich mit dem Tenant teilen lässt. Das zugehörige Tool und die Szenarien sind in der Dokumentation beschrieben: Microsoft 365 network connectivity test tool.

• Wann nutzen? Wenn Nutzerstandorte auffällig sind, wenn Copilot/Teams/M365 „hängt“ oder wenn Sie vermuten, dass Protokolle wie WebSockets blockiert werden.
• Was bringt es? Es zeigt, ob Ihr „in-use front door“ optimal ist und ob die Anbindung an Microsofts Netzwerk erwartbar gut ist.

Microsoft 365 Network Assessment im Admin Center

Für eine Standort- und Tenant-Sicht gibt es Network Assessments, die die Netzwerkqualität und den Einfluss Ihres Designs auf M365 bewerten. Überblick: Microsoft 365 network assessment.

• Mehrwert: Trend und Vergleich zwischen Standorten, schneller Drilldown auf Problem-Locations.
• Praxis: Nutzen Sie es als „Radar“, um zu priorisieren, wo detaillierte Analysen nötig sind.

Microsoft Remote Connectivity Analyzer

Wenn es eher um Protokoll- oder Konfigurationsprobleme geht (Exchange/Outlook, Autodiscover, Teams), kann der Microsoft Remote Connectivity Analyzer helfen, typische Fehler in Verbindung und Konfiguration sichtbar zu machen.

Egress-Design: Der häufigste Performance-Hebel bei SaaS

Bei SaaS ist der Egress-Punkt entscheidend: Wo verlässt Ihr Traffic das Unternehmensnetz Richtung Internet/Cloud? Drei typische Modelle:

• Zentraler Egress (HQ Proxy/Firewall): Einfach zu kontrollieren, aber riskant für Latenz und Bottlenecks (Hairpinning).
• Lokaler Breakout pro Standort: Oft beste Performance, erfordert aber klare Security- und Policy-Standards.
• Cloud-SWG/Proxy: Gute Balance aus Security und Performance, wenn PoPs gut verteilt sind.

Für Microsoft 365 gibt es zudem klare Kategorien von Endpunkten (Optimize/Allow/Default), die unterschiedliche Anforderungen an Performance und Behandlung (z. B. Proxy-Bypass) haben. Die aktuelle Liste und Kategorisierung finden Sie in Microsoft 365 URLs and IP address ranges.

Warum Proxy-Inspection oft „SaaS langsam“ auslöst

TLS-Inspection und tiefe HTTP-Analyse erhöhen Latenz und können Protokolle stören (WebSockets, HTTP/2, bestimmte Zertifikatspfade). Bei M365 empfiehlt Microsoft für bestimmte Endpoint-Kategorien eine optimierte Behandlung (häufig: Bypass oder reduzierte Inspection), um Performance und Kompatibilität sicherzustellen. Die Endpoint-Kategorien sind deshalb nicht nur „Listen“, sondern Teil eines Performance-Designs.

DNS als Performance-Faktor: falsche Auflösung = falscher Pfad

DNS beeinflusst, welche SaaS-Edges und welche Dienst-Frontdoors genutzt werden. Fehler zeigen sich oft nicht als „DNS down“, sondern als suboptimaler Pfad oder als Zugriff auf falsche IPs:

• Falscher Resolver: Homeoffice/Hotel-DNS liefert andere Anycast-Edges als Unternehmensresolver.
• Split DNS inkonsistent: Interne Namen lösen auf private IPs, aber Split Tunnel routet nicht dorthin.
• DoH/Browser-DNS: Umgeht Unternehmens-DNS, wodurch Policies und Split-Horizon nicht greifen.

Praxis: Messen Sie DNS nicht nur mit „geht/geht nicht“, sondern mit Antwortzeit, Resolver-Pfad und Vergleich „intern vs. extern“. DNS-Basics: RFC 1035.

Performance-Fehlerbilder und wie Sie sie sauber unterscheiden

Hohe RTT, aber kaum Paketverlust

• Wahrscheinlich: ungünstiger Egress (Hairpin), geografisch falscher Proxy/PoP, Peering-Umwege.
• Messung: RTT zu SaaS-Frontdoor vs. RTT zu ISP-Nearest. Vergleich zwischen Standorten.
• Maßnahme: Egress näher an Nutzer (Local Breakout/Cloud PoP), Routing/Peering optimieren.

Jitter-Spikes, Meetings ruckeln

• Wahrscheinlich: Bufferbloat (besonders Upload), WLAN/Heimnetz, ISP-Last, VPN überlastet.
• Messung: RTT im Idle vs. unter Last, Paketverlust während Meetings, ggf. UDP-Policy prüfen.
• Maßnahme: SQM/QoS am Edge, Priorisierung für Echtzeit, lokale Breakouts für Medien, VPN entlasten.

Paketverlust und Retransmissions

• Wahrscheinlich: Congestion, fehlerhafte Links, WLAN-Interferenzen, Policer/Drops, MTU-Probleme.
• Messung: TCP Retransmissions im Capture, Interface Drops/Discards, Flow-Daten zu Spitzenzeiten.
• Maßnahme: Engpass finden (Top Talkers), Shaping, Linkqualität, WLAN-Optimierung, MTU/MSS prüfen.

„Nur bestimmte SaaS-Features“ funktionieren nicht

• Wahrscheinlich: Proxy/Firewall blockt spezifische Endpoints oder Protokolle (WebSockets, UDP/443), DNS zeigt auf falsche Region, Conditional Access/Policy.
• Messung: M365 Connectivity Test, Proxy-Logs, Firewall-Hits, Vergleich Client vs. Standort.
• Maßnahme: Endpoint-Kategorien korrekt behandeln, Protokolle gezielt erlauben, Policies dokumentieren.

Der praxiserprobte Ablauf: SaaS Performance Troubleshooting als Runbook

Dieses Runbook ist so aufgebaut, dass Sie schnell zwischen „lokalem Problem“, „WAN/ISP“, „Egress/Proxy“ und „Provider“ unterscheiden können.

Schritt: Standort und Pfad festhalten

• Wo sitzt der Nutzer (Office Location, Homeoffice, WLAN/LAN)?
• Welcher Egress wird genutzt (lokal, HQ, Cloud Proxy)?
• Ist VPN aktiv (Full/Split)?

Schritt: Basis-Metriken messen

• RTT und Loss zum VPN-Gateway oder Proxy-PoP
• RTT und Loss zum SaaS-Frontdoor (M365 Connectivity Test)
• DNS-Antwortzeit und Resolver

Schritt: App-nahe Messung durchführen

• TLS-Handshake-Zeit und HTTP TTFB (Browser DevTools oder synthetisch)
• Für M365: Connectivity Test Report und Network Assessment (Standortvergleich)

Schritt: Hypothese bilden und mit Gegenprobe verifizieren

• Gegenprobe „ohne VPN“ vs. „mit VPN“ (nur wenn policy-konform)
• Gegenprobe „anderer Egress“ (z. B. anderer Standort/ISP/PoP)
• Gegenprobe „per IP“ vs. „per Name“ (DNS-Pfad prüfen)

Schritt: Maßnahmen ableiten und kontrolliert umsetzen

• Egress-Optimierung: Local Breakout oder Cloud-SWG-PoP anpassen
• Proxy/Inspection: Endpoints nach Kategorie behandeln, unnötige Inspection reduzieren
• DNS: Resolver-Strategie, Split DNS und DoH-Policy konsistent machen
• WAN: Shaping, Kapazität, Peering/ISP-Optionen, QoS für Echtzeit

Dokumentation und Kommunikation: So machen Sie SaaS-Messungen „ticketfähig“

Damit interne Teams und Provider- oder Microsoft-Support schnell helfen können, brauchen Sie strukturierte Daten. Sammeln Sie pro Incident:

• Zeitfenster, Standort, ISP, Egress-Punkt
• Messwerte (RTT/Loss/Jitter), ideal im Idle und unter Last
• M365 Connectivity Test Report (wenn betroffen) und ggf. Admin-Center Assessment-Sicht
• Proxy/Firewall-Logs (Allow/Deny, TLS-Inspection, WebSocket/UDP-Blocks)
• DNS-Resolver, Antwortzeit, abweichende Antworten (intern/extern)

Outbound-Links zur Vertiefung

• Microsoft 365 Network Connectivity Test: SaaS-Pfad zu Microsoft-Frontdoors messen
• Dokumentation zum Microsoft 365 network connectivity test tool
• Microsoft 365 Network Assessment: Standort- und Tenant-Sicht auf Netzwerkqualität
• Microsoft 365 URLs und IP-Ranges inklusive Optimize/Allow/Default-Kategorien
• Microsoft Remote Connectivity Analyzer für Exchange/Outlook/M365-Connectivity

Checkliste: M365 & Co. richtig messen und SaaS-Performance sauber troubleshoot’en

• Symptom präzisieren: Latenz, Jitter, Paketverlust, DNS, Pfad/Policy – nicht nur „langsam“.
• Scope festlegen: betroffene App, Standort, ISP, Egress, VPN-Modus (Full/Split), Zeitfenster.
• Basis messen: RTT/Loss zum Gateway/Proxy, RTT/Loss zum SaaS-Frontdoor, DNS-Antwortzeit und Resolver.
• M365-spezifisch messen: connectivity.office.com nutzen und Ergebnisse mit Tenant/Standort-Assessment abgleichen.
• Egress prüfen: Hairpinning über HQ? Proxy-PoP geografisch passend? Lokaler Breakout möglich/erlaubt?
• Proxy/Inspection prüfen: Endpoint-Kategorien (Optimize/Allow/Default) korrekt behandelt? WebSockets/UDP/443 blockiert?
• DNS prüfen: Split-Horizon konsistent? DoH umgeht Policy? AAAA/IPv6-Pfad vorhanden oder verursacht Timeouts?
• Unter Last testen: Idle vs. Last (Bufferbloat) messen, besonders im Homeoffice und bei Videocalls.
• Hypothese verifizieren: Vergleich ohne/mit VPN (policy-konform), Vergleich anderer Egress/Standort, Vergleich IP vs. Name.
• Änderung kontrolliert umsetzen: Egress-Optimierung, Proxy-Bypass/Reduktion, DNS-Strategie, QoS/Shaping – dann Vorher/Nachher messen und dokumentieren.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.