Websocket-Verbindungsprobleme – Debuggen einer vagen Microsoft Health-Benachrichtigung

Microsoft hat vor kurzem allgemeine Benachrichtigungen über den Zustand von Diensten für WebSocket-Verbindungsprobleme eingeführt, die Dienste wie Copilot betreffen. Einer unserer Kunden hat eine solche Benachrichtigung erhalten, die eine weitere Untersuchung ermöglichte. Auf den ersten Blick scheint die Meldung sehr allgemein zu sein und enthält keine spezifischen Details wie Standorte oder betroffene Neworks. Außerdem scheint die Vorfalls-/Beratungsnummer für alle Kunden eindeutig zu sein und nicht mit anderen zu korrelieren.

Beispiel für die Nachricht, die der Administrator sieht:

Wie bereits erwähnt, ist die Nachricht recht allgemein gehalten und enthält keine spezifischen Hinweise auf Standorte, Netzwerke oder Gruppen von betroffenen Personen. Für weitere Nachforschungen rät Microsoft, das Microsoft Admin Center aufzusuchen, um weitere Details zu erfahren.

Im Microsoft Admin Center können Sie auf die Seite Netzwerkkonnektivität zugreifen, um allgemeine Informationen zu Konnektivitätsthemen einschließlich ISP-Informationen und Netzwerkverkehr zu erhalten. (Referenz: https://techcommunity.microsoft.com/discussions/deploymentnetworking/optimizing-customer-network-connectivity-for-microsoft-365-copilot/4374772)

Eine neue Registerkarte namens Verbindungsblocker zeigt eine Zeitreihe von Verbindungs- und Websocket-Fehlerereignissen für die letzten 90 Tage in Ihrem Unternehmen an. Wenn Sie jedoch ein großes Unternehmen haben, in dem es nur an bestimmten Standorten Probleme mit der Konnektivität gibt, kann dieses Diagramm trügerisch sein. Denn wenn sich die Verbindungsprobleme auf bestimmte Standorte beschränken, kann die relativ geringe Anzahl von Benutzern an diesen Standorten im Vergleich zur gesamten Endbenutzerbasis zu klein sein, um einen signifikanten Einfluss auf dieses Diagramm zu haben, was zu einer fast flachen Linie im Diagramm führt, wie unten gezeigt. In diesem Fall kann ein Administrator beim Betrachten der Grafik natürlich keine Probleme feststellen.

Das bedeutet jedoch nicht, dass Sie die in der Warnung aufgeführten kritischen Websocket-Verbindungsfehler ignorieren können.

Auf der Registerkarte „Übersicht“ gibt es auch einen Abschnitt „Maßnahmen ergreifen“, der Insights auflistet, die Maßnahmen erfordern. Diese Funktion wurde vor kurzem eingeführt und „Websocket-Verbindung zu kritischen Microsoft 365 Domains schlägt fehl“ ist eine der Erkenntnisse, die hier aufgeführt werden können.

Wenn Sie auf den Einblick klicken, erhalten Sie einen Überblick über die betroffenen Bürostandorte:

Mit weiteren Drilldowns zu jedem Standort erhalten Sie eine Standortzusammenfassung (Registerkarte), zusätzliche Details, die Anzahl der Proben und eine Zeitleiste der fehlgeschlagenen Websocket-Verbindungen.

Bei Untersuchungen mit einem unserer Kunden stellten wir jedoch fest, dass der Kunde zwar die Benachrichtigungen über Fehler bei der Websocket-Konnektivität erhalten hatte, aber keine Einsicht in die Liste ‚Microsoft 365 Netzwerkkonnektivität‘ – Maßnahmen ergreifen sah.

Ohne dies können Sie nicht schnell feststellen, welcher Standort die von Microsoft festgelegten Schwellenwerte überschreitet, die die Benachrichtigung über den Zustand des Dienstes auslösen. Sie müssen also jeden einzelnen Standort durchgehen und überprüfen, um dies festzustellen.

Bei diesem Kunden wurde der Standort schließlich durch einfache Überprüfung einer langen Liste potenziell verdächtiger Standorte ermittelt. Wenn Sie den Standort, an dem die Probleme auftraten, aus der Dropdown-Liste auswählten, lieferte das Diagramm ein klareres Bild und zeigte einen hohen Prozentsatz von Websocket-Fehlern.

Bei diesem Kunden ist offensichtlich Anfang April etwas passiert.

Wenn Sie den Namen des betroffenen Standorts kennen, können Sie auf die Registerkarte Standorte klicken, den Standort auswählen und dann auf die Registerkarte Details klicken, um die Informationen zu sehen, die sonst auf dem Drilldown aus dem Einblick angezeigt worden wären, wenn es sie gegeben hätte:

Die Standortinformationen geben Aufschluss darüber, welche öffentlichen IPs und Eingangspunkte miteinander in Verbindung stehen, sowie über andere Verbindungen. Dies könnte ein Ansatzpunkt sein, um herauszufinden, ob es Einstellungen gibt, die beispielsweise die Websocket-Verbindungen zur Domäne *.cloud.microsoft blockieren.

Die Reise endet hier, denn es werden keine weiteren Einblicke gewährt. Es wäre nützlich gewesen, etwas mehr Informationen zu sehen, z.B. die betroffenen Benutzer oder vielleicht die Netzwerkinformationen, von denen aus sich die Benutzer verbinden. Es ist auch unklar, warum die Erkenntnis nicht auf der Microsoft 365 Liste „Netzwerkverbindung – Maßnahmen ergreifen“ für diesen Kunden und diese Instanz aufgeführt wurde. Das Fehlen dieser Information in der Liste „Maßnahmen ergreifen“ erschwert die Identifizierung des konkreten Standorts, auf den sich die Benachrichtigungen über den Zustand der Dienste beziehen.

Spekulationen über mögliche Gründe, warum kein Insight in der Liste der zu ergreifenden Maßnahmen aufgeführt war, könnten darin bestehen, dass die Anzahl der Websocket-Fehler den Schwellenwert für die Auflistung als Insight nicht mehr überstieg, als der Administrator sie nach Erhalt der Benachrichtigung über den Zustand des Dienstes betrachtete. Eine andere (spekulative) Möglichkeit wäre, dass die Schwellenwerte für das Senden einer Benachrichtigung über den Zustand des Dienstes und die tatsächliche Auflistung als Insight nicht übereinstimmen. So oder so würde dies bedeuten, dass es nahezu unmöglich ist, das in den Service Health Notifications erwähnte Problem im Nachhinein zu untersuchen, wenn es nicht sofort nach Erhalt der Benachrichtigung untersucht wird oder wenn der Schwellenwert für die Einstufung als Insight nicht erreicht wird.

Um auf das eigentliche Problem zurückzukommen, sind die folgenden Punkte einige allgemeine Richtlinien zur Lösung von Problemen mit der Websocket-Konnektivität.

Stellen Sie zunächst sicher, dass Ihr Netzwerk ausgehende Verbindungen zu *.cloud.microsoft, *.office.com, *static.microsoft und *.usercontent.microsoft zulässt. Diese sind in der offiziellen Dokumentation zu den IP-Adressbereichen/URLs von Microsoft aufgeführt.

Zweitens: Stellen Sie sicher, dass Ihre Firewall oder Ihr Proxy den Websocket-Verkehr nicht blockiert oder stört. Eine SSL/TLS-Inspektion könnte auch den Websocket-Handshake unterbrechen. Wenn Sie einen Proxy verwenden, überprüfen Sie die Konfiguration, um sicherzustellen, dass der Proxy keine Header verändert.

Derzeit bietet TrueDEM noch keine Websocket-Überwachung an. Aufgrund der wachsenden Nachfrage nach Echtzeitdiensten wie Copilot, Teams und anderen M365 Apps sowie der Erfahrung, dass es an Post-Mortem-Optionen mangelt, prüfen wir jedoch Möglichkeiten, unsere Kunden bei solchen Anforderungen zu unterstützen.