Die zum 31.8.2026 aufgetretene Microsoft 365-Störung scheint auch am 3. September 2026 noch nicht beseitigt zu sein. Microsoft kämpft weiterhin mit den Folgen und derzeit laufen wieder Nutzerberichte in Störungsportalen ein.
Rückblick auf den M365-Ausfall EX1464935
Bereits zum 31. August 2026 trat eine Störung beim M365-Dienst auf, die Microsoft unter EX1464935 bestätigt hatte. Kunden konnten mit Outlook keine Verbindung mehr zu Microsoft 365 Exchange Online aufbauen. Auch das Einloggen über Webmail (outlook.office.com) funktioniert nicht. Es gab die Fehlermeldung: "Something went wrong". Auch Teams, SharePoint und Defender XDR waren betroffen.
Ich hatte den Sachverhalt zeitnah im Blog-Beitrag EX1464935: M365-Ausfall wegen vergessener Zertifikatserneuerung (31.8.2026) aufgegriffen, und die Vermutung geäußert, dass es ein Problem mit Zertifikaten sei. Zum 1. September 2026 meldete sich erste Leser mit Kommentaren, und berichteten, dass die Probleme in ihrem Tenant behoben seien.
Andreas K. berichtete aber zum 1. September 2026 in diesem Kommentar, dass er Berichte über Probleme mit der Suche von Anwendern erhalte. Diese erhalten die Meldung:
"Da hat etwas nicht geklappt, und Ihre Suche konnte nicht abgeschlossen werden".
Ein weiterer Leser die Information von Microsoft ""We're observing residual impact to some downstream scenarios, including search….." in den Kommentaren gepostet.
Probleme auch noch am 3. Sept. 2026?
Auf der Webseite von Downdetector gehen seit dem 2. September 2026 (ca. Mittag europäischer Zeit) die Störungsmeldungen nach oben und halten auch am 3. September 2026 noch an.
Allerdings scheinen die Störungsmeldungen bei Outlook zurück zu gehen. Wir haben nun den 3. September 2026 und ich habe mal auf der öffentlichen Service Health M365-Statusseite von Microsoft nachgeschaut. Das sieht nicht so gut aus, Microsoft spricht am 3.9.2026 um 0:30 Uhr weiterhin von einer Diensteinschränkung (Service degradation" beim Microsoft 365 (Business oder Enterprise).
Bei der Nutzung mehrerer Microsoft 365-Dienste können noch Probleme auftreten. Die Auswirkungen betreffen unter anderem Exchange Online:
- Benutzer können E-Mail-Anhänge über keine der Verbindungsmethoden von Exchange Online herunterladen.
- Benutzer können sich möglicherweise nicht bei Outlook im Web anmelden.
Für Microsoft Graph gesteht Microsoft Probleme ein: Bei Szenarien, die auf den Zugriff auf Exchange Online-Daten angewiesen sind, sind möglicherweise Fehler aufgetreten. Dieses Problem soll aber inzwischen behoben sein.
Bei Exchange Online sollten ebenfalls die in den letzten Stunden behobenen Fehler behoben sein:
- Die Servicetelemetrie zeigt an, dass der Kern-E-Mail-Fluss und die Suchfunktionalität wiederhergestellt wurden.
- Die Servicetelemetrie zeigt an, dass der Großteil der zuvor betroffenen Authentifizierungs- und Protokollverbindungsszenarien wiederhergestellt wurde.
- Es kann vorkommen, dass Benutzer keine Verbindung zu Exchange Online herstellen konnten oder dort eingeschränkte Funktionalität feststellten, beispielsweise Fehler bei der Nutzung der Suchfunktion. Alle Verbindungsmethoden sind davon betroffen.
- Es kann vorkommen, dass Benutzer keine Verbindung zu Exchange Web Services (EWS) herstellen konnten.
- Es kann vorkommen, dass Benutzer die Raum-Suche in Outlook-Kalendern nicht nutzen konnten.
Der Status wird derzeit unter EX1464935 – Users may be unable to connect to, or experience degraded functionality with Exchange Online fortgeschrieben. Ist noch jemand von diesen Problemen betroffen?
MVP: 2013 – 2016
Shared Responsibility Model hin oder her. Nächste Woche sollte es wieder laufen. Sonst müsste man vielleicht doch an einen eigenen Stalwart oder Mailcow Server denken.
Ich will mir gar nicht vorstellen was los wäre wenn hier bei uns seit Montag keine Mails mehr gehen würden. Mir graut es schon vor unserem Umzug zu M365, der leider schon geplant ist. :(
Ihr werdet vermutlich eine Information für die Mitarbeitenden zur Migration bereitstellen, oder? Dort würde ich gleich das Shared Responsibility Model erwähnen und vor längeren Ausfällen vorwarnen. Wenn Mitarbeitende rechtzeitig eingebunden werden, ist das Verständnis meiner Erfahrung nach deutlich höher.
Das Interessiert Mitarbeiter die im Vertrieb arbeiten und nach Provision bezahlt werden nicht, die reden ab Minuten 1 von Umsatzverlust und persönlicher Existenzängste. Darüber hinaus gibt es nicht nur Mitarbeiterseite, sondern auch den Kunden. Wenn der Kunde Morgens eine Mail mit einem konkreten Anliegen schreibt, erwartet er auch eine Antwort, das die Mail nicht abgerufen werden kann ist nichts sein Problem, sondern das des Empfängers.
Die legale Nutzung von MS365 setzt einen gültigen EU-Angemessenheitsbeschluss voraus, sonst ist das ein DSGVo-Bruch.
Der aktuelle Angemessenheitsbeschluss geht aber grade den Bach runter (haben die meissten nur noch nicht mitbekommen):
https://www.heise.de/news/Kartenhaus-Wie-ein-US-Urteil-den-transatlantischen-Datenfluss-sprengen-koennte-11349599.html
Ich würde das mit der US-Cloud zumindest bis zur Klärung dieses Problems sein lassen, weil seit dem letzten Verlust des Angemessenheitsbeschlusses (Schrems II) sich ein wichtiges Detail geändert hat: Von einem DSGVo-Verstoß Betroffene können jetzt auch ohne konkreten Schaden Schadensersatz geltend machen:
https://www.anwalt.de/rechtstipps/bgh-urteil-dsgvo-verstoss-fuehrt-zu-schadensersatz-so-schuetzen-sich-unternehmen-240562.html
Vielleicht bringt ein Hinweis auf diese Haftungsrisiken den Entscheider ja noch zum Umdenken.
—-
GB: Musst nicht so weit weg suchen – die Information steckt zum 30. Juni 2026 im Blog-Beitrag Wurde das US-EU Transatlantic Datentransfer-Abkommen gerade pulverisiert?. Es wird imho aber erst etwas passieren, wenn der EuGH das stoppt, auch wenn das European Data Protection Board (EDPB) die EU-Kommission auffordert, den Angemessenheitsbeschluss zu prüfen (siehe Europäische Datenschützer fordern Prüfung des EU-US-Datentransferabkommens).
Diese Meldung ist jetzt schon 3 Monate alt, bisher noch nix passiert. Und so lange wird weiter gemacht wie bisher.
Ich betreue hier eine Zammad-Instanz, welche an ein Exchange365-Konto angebunden ist. Da laufen seit dieser Nacht auch ständig Fehler beim Abruf auf. Im Healthstatus steht dann als Fehler immer: SSL_connect returned=1 errno=0 peeraddr=40.99.155.242:993 state=error: wrong version number (OpenSSL::SSL::SSLError)
Moin Eiko,
ich kämpfe ebenfalls seit einigen Tagen mit wrong version number (OpenSSL::SSL::SSLError).
Hast du das Problem aktuell noch?
Viele Grüße
Sebastian
Wir sind bei M365!
Gestört ist das Verhalten der User / GF:
MAILS gehen nicht. SOFOROT !!111!!!!1! DRINGEND!1!!!
"Probleme liegt bei MS"
Ach so. Wann läuft das wieder?
"Wenn MS repariert hat"
Na Leute – dann haut rein. Dann sind die Profis ja dran!
Haha, ja, das kenne ich. ICH!! MUSS!! JETZT!! MAILEN!!!1elf – bei solchen Ausbrüchen steigt meine Motivation, dem Kunden zu helfen, sofort ins Unermessliche. Nicht. Erinnert mich an die MAD-Version von "Star Wars", in der Vader gesagt wird, dass man 16 Stunden am Tag am Todesstern arbeite und der entgegnet: "Dann verdoppeln Sie ihre Anstrengungen!" – "Sie meinen 32 Stunden am Tag?" – "Na und? Ich bin Sadist, kein Mathematiker!"
Verweist man hingegen auf Microsoft, gehen die meisten tatsächlich in den "kann man nichts machen"-Modus über. Was hilft ist sicherlich die breite Berichterstattung: Wird das Problem sogar in den TV-Nachrichten angesprochen (wie im aktuellen Fall geschehen), ist die Einsicht offenbar schneller möglich. Betrifft die Störung nur einen lokalen kleinen Provider, ist hingegen grundsätzlich die eigene IT Schuld.
Es sind meist die selben Leute, die z. B. ein Mobilfunk-Fallback fürs Internet (falls mal ein Bagger die Glasfaser mampft) mit "zu teuer/kommt doch eh nie vor" abbügeln. Ist manchmal schon toll, in der IT zu arbeiten.
Harmlos.
Kappe einem Onlinehändler bei einer Bank mal für wenige Minuten Telefon oder Internet. Am Besten unangekündigt. DA kommen dann Eskalationsstufen…
Das MAD-Beispiel setzt übrigens ein erdähnliches Planetending voraus, weil nicht jeder Tag hat 24 Stunden ;-)
Der 'kann-man-nix-machen'-Modus zeigt einem eigentlich nur eines: Die eigene Abhängigkeit/Ohnmacht. Einen Zustand, den man durch Vorsorge tunlichst vermeiden sollte. In diesem Fall: Sich nicht von einem Dienstleister abhängig machen.
Besser kann man eine Abhängigkeit doch nicht darstellen: Wir können da nix machen, ist MS-Sache.
Ok, jetzt dauert das mal 'länger', nix geht, die Firma steht, Lohnkosten fallen aber trotzdem an. Wer bezahlt das? Microsoft begrenzt Schadensersatz auf das, was man selbst an MS zahlt, da kommt also schon mal nix her…
Ich antworte dann immer mit:
*Wie bestellt so geliefert!* Wer nicht hören will muß lernen mit Schmerzen.
Wieder gruselig was in den Kommentaren so abgeht…
Gruselig ist das, was Microsoft wieder abliefert…
Gelesen habe ich von den Problemen, Auswirkungen haben wir keine, obwohl OneDrive und ExchangeOnline in Benutzung.
Allerdings nutzen wir die Desktopanwendungen und nicht die Webversionen.
Immer schön, wenn der Kelch an einem vorüber geht.
Bei uns scheint EXO die persönlichen Mailboxen durchzuklappern und lange erledigte Mails im Posteingang mit hoher Priorität / Wichtigkeit und Lesestatus-Anforderungen triggern zum Absender der Mail eine Lesebestätigung des Empfängers. Bisher etwa zwei Dutzend Fälle gemeldet bekommen. Ob es da einen Zusammenhang gibt?
Amazon-Buch von Benjamin Bergspitz: DAU: Der dümmste anzunehmende User
In der Kürze liegt die Würze, @Balduin .-)
Referrer & Query-Strings werden für Tracking verwendet, weshalb man diese aus der URL entfernen sollte. Bei Amazon-Verlinkungen also besser so
http_s://www.amazon.de/DAU-d%C3%BCmmste-anzunehmende-Benjamin-Bergspitz/dp/B0HDV6PK4H oder noch kürzer
http_s://www.amazon.de/dp/B0HDV6PK4H.
Bin noch unschlüssig ob das zusammen hängt, aber anscheinend wurde im Zuge der ganzen Aktion auch das Zertifikat des Office 365 CDN oder zumindest für das Microsoft 365 Apps readiness file ausgetauscht. Scheint bei normalen Endbenutzern keinen negativen Effekt zu haben (zumindest kann ich mein Word noch aktualisieren). Jedoch klappt seit dem die Synchronisierung über MECM (Configuration Manager) nicht mehr und der SMS_SERVICE_CONNECTOR wirft einen Fehler aus. Im dafür zuständigen OfficeCDNWorker.log sieht man, dass zuletzt am 31.8.2026 synchronisiert wurde, danach kommt immer ein Fehler:
—————————————————
[Critical][OfficeCDNWorker][1][System.Security.Authentication.AuthenticationException][0x80131501]
The remote certificate is invalid according to the validation procedure. at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception exception)
at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest, Boolean renegotiation)
at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)
at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)
at System.Net.PooledStream.Write(Byte[] buffer, Int32 offset, Int32 size)
at System.Net.ConnectStream.WriteHeaders(Boolean async) SMS_SERVICE_CONNECTOR_OfficeCDNWorker
—————————————————
Die fehlgeschlagene Zertifikatsprüfung hat mich dann dazu gebracht, mir das Quell-Zertifikat anzuschauen. MECM greift auf die URL https://go.microsoft.com/fwlink/?linkid=2094253 zu, welche nach https://omex.cdn.office.net/mirrored/sccmreadiness/SOT_SCCM_AddinReadiness.CAB umleitet. Die https Seite liefert das Microsoft TLS G2 ECC CA OCSP 02 Zertifikat, welches seit dem 31.8.2026 gültig ist!
Zertifikatskette ist i.O., die CRLs der Zertifikate (auch Intermediate und Root) sind gültig, also keine Ahnung was dem Modul von MECM da nicht gefällt.
Wer MECM betreibt und Office 365 damit verwaltet/patcht möge doch bitte mal einen Blick in das OfficeCDNWorker.log am Site Server (\\Program Files\\Microsoft Configuration Manager\\Logs) werfen.
Unklar ist auch noch wofür die Datei gebraucht wird. Wenns wirklich nur für das Microsoft 365 Apps Upgrade Readiness dashboard in Microsoft Endpoint Configuration Manager nötig ist, kann man wahrscheinlich überleben ;-)