![](\"https:\/\/borncity.com\/blog\/wp-content\/uploads\/2019\/07\/Azure.jpg\")
Microsoft wurde letzte Woche ja bei seinen Diensten Azure\/Office365.com durch Anmeldeprobleme geplagt. Jetzt gibt es Informationen, was schief gelaufen ist \u2013 es waren gleich drei Fehler, die zuschlugen. Und die ber\u00fchmte Telemetrie, die alles wei\u00df, suggerierte den Microsoft-Operatoren, dass alles in bester Ordnung w\u00e4re. Gl\u00fccklicherweise gab es Medien wie Twitter und Blogs, so dass die Microsoftler irgendwann mit bekamen, dass was nicht stimmt. <\/p>\n
<\/p>\n
Die St\u00f6rung dauerte 14 Stunden an. Einige Tage zuvor hatte ich im Beitrag Office365.com\/Outlook.com mit Problemen<\/a> \u00fcber die letzte St\u00f6rung berichtet. Das zeigt, wie wackelig das Ganz Cloud-Gesch\u00e4ft im Grunde ist. Alle R\u00e4der stehen still, wenn Microsoft (oder Mc Murphy) das will \u2026<\/p>\n Inzwischen hat Microsoft einen Dreifachfehler in Form von Bugs f\u00fcr diesen Ausfall und vor allem f\u00fcr die Zeit, bis die Ursache bekannt war, verantwortlich gemacht. Die Information findet sich im Statusbereich<\/a> (11\/19):<\/p>\n There were three independent root causes discovered. In addition, gaps in telemetry and monitoring for the MFA services delayed the identification and understanding of these root causes which caused an extended mitigation time. <\/p>\n<\/blockquote>\n Hier hat McMurphy zugeschlagen \u2013 denn durch diese Kombination konnte Microsoft die Telemetrie-Daten nicht richtig auswerten und so die Ursache der Bugs nicht feststellen. Die ersten zwei Fehler traten beim Multifactor-Authentification Frontend-Server auf. <\/p>\n Die ersten beiden Hauptursachen wurden als Probleme auf dem MFA-Frontend-Server identifiziert, die beide einem Roll-out eines (Code-) Updates unterzogen wurden. Das Rollout begann in einigen Rechenzentren (DCs) am Dienstag, den 13. November 2018 und das Ganze wurde in allen Domain-Controllern (DCs) am Freitag, den 16. November 2018, abgeschlossen.<\/p>\n Die Probleme traten aber erst sp\u00e4ter auf, sobald eine bestimmte Verkehrsschwelle \u00fcberschritten wurde. Diese Schwelle wurde erstmals Anfang Montag (UTC) in den DCs von Azure West Europe (EU) erreicht. Der morgendlichen Spitzenverkehr in den Domain Controllern der westlichen EU waren die ersten, die die Schwelle \u00fcberschritten haben. Der Fehler wurde damit getriggert. <\/p>\n Die dritte Ursache f\u00fcr den Ausfall hatte nichts mit dem Rollout des Updates zu tun, wurde aber im Rahmen der Untersuchung dieses Ereignisses gefunden. Der Fehler f\u00fchrte dazu, dass keine Ressourcen im Back-End mehr bereitstanden, um Anfragen zu beantworten. Hier die Beschreibung der Ursachen durch Microsoft:<\/p>\n 1. The first root cause manifested as latency issue in the MFA frontend's communication to its cache services. This issue began under high load once a certain traffic threshold was reached. Once the MFA services experienced this first issue, they became more likely to trigger second root cause.<\/p>\n 2. The second root cause is a race condition in processing responses from the MFA backend server that led to recycles of the MFA frontend server processes which can trigger additional latency and the third root cause (below) on the MFA backend.<\/p>\n 3. The third identified root cause, was previously undetected issue in the backend MFA server that was triggered by the second root cause. This issue causes accumulation of processes on the MFA backend leading to resource exhaustion on the backend at which point it was unable to process any further requests from the MFA frontend while otherwise appearing healthy in our monitoring.<\/p>\n<\/blockquote>\n Interessierte Blog-Leser\/innen seien an dieser Stelle auf den Microsoft Statusbericht<\/a> verwiesen, wo noch weitere Details beschrieben werden. Letztendlich f\u00fchrte das dazu, dass die Benutzer sich nicht mehr per Zweifaktor-Authentifizierung anmelden konnten. Gleichzeitig wurde den Administratoren dieser Azure-Server angezeigt, dass alles in Ordnung gewesen sei. Die Serie von Fehlern wirkte sich zuerst in Europa und Asien (EMEA) und dann bei APAC-Kunden (Asien, Pazifik) aus. Im Laufe des Tages traf es dann auch die US-Abonnenten. Microsoft konnte das Problem schlie\u00dflich l\u00f6sen, indem die Mannschaft die Server nach der Anwendung eines Fixes aus- und wieder einschaltete (die alte, bew\u00e4hrte Methode halt). <\/p>\n Microsoft versichert, dass man nat\u00fcrlich alles tue, damit so etwas nicht mehr vorkomme. Microsoft will dazu pr\u00fcfen, wie man mit Updates und Tests umgeht, sowie ihre internen \u00dcberwachungsdienste \u00fcberpr\u00fcfen. Und fairerweise muss man zugestehen, dass das Zeugs reichlich komplex ist. Aber ich gestehe, mir zuckte so ganz kurz 'fresst eure eigene Suppe, damit ihr wisst, wie es manchen Administratoren nach einer Update-Installation geht' durch den Kopf. (via<\/a>)<\/p>\n","protected":false},"excerpt":{"rendered":" Microsoft wurde letzte Woche ja bei seinen Diensten Azure\/Office365.com durch Anmeldeprobleme geplagt. Jetzt gibt es Informationen, was schief gelaufen ist \u2013 es waren gleich drei Fehler, die zuschlugen. Und die ber\u00fchmte Telemetrie, die alles wei\u00df, suggerierte den Microsoft-Operatoren, dass alles … Weiterlesen Ich hatte am 19. November 2018 im Beitrag Anmeldeprobleme bei Azure\/Office365.com<\/a> \u00fcber Anmeldeprobleme bei Microsoft Azure und Office365.com berichtet. Das betraf Nutzer in Europa und Asien, die von der Zweifaktor-Authentifizierung komplett ausgesperrt waren. Die Statusseite von Office 365 zeigt diese Meldung mit dem Hinweis, dass eine Anmeldung gest\u00f6rt sei:<\/p>\n
![\"Office](\"https:\/\/i.imgur.com\/1eJbzlW.jpg\"\/ "\\"Office")
<\/p>\nUrsachenanalyse: Dreifachfehler, dumm gelaufen<\/h2>\n
\n
Ein Update geht in die Hose<\/h3>\n
Dritter Bug bei Ursachenanalyse gefunden<\/h3>\n
\n