Wenn die Cloud dich “löscht” – ein Fallbericht aus dem Microsoft-365-Alltag
IIch arbeite seit Jahren als IT-Dienstleister und Microsoft Partner. Microsoft 365 ist in diesem Kontext kein Experiment und kein Komfort-Tool, sondern zentrale Geschäftsgrundlage: E-Mail-Kommunikation, administrativer Zugriff auf Kundentenants, Partnerstatus sowie der Vertrieb und die Verlängerung von Lizenzen und Abonnements hängen unmittelbar daran.
Am 10. Januar 2026 hat diese Grundlage faktisch aufgehört zu existieren.
Nicht schleichend.
Nicht eingeschränkt.
Sondern technisch eindeutig und nachvollziehbar.
Meine geschäftliche E-Mail-Adresse wurde bzw. wird serverseitig als „nicht vorhanden“ behandelt. SMTP-seitig war bzw. ist das Konto aus Microsoft-Sicht “gelöscht” bzw. nicht existent. Damit ist nicht nur meine eigene Kommunikation unterbrochen, sondern auch der operative Betrieb als Partner massiv beeinträchtigt. Die Konsequenzen reichen dabei weit über mein eigenes Postfach hinaus: Was passiert mit den Kundentenants, deren Lizenzverlängerungen Ende Januar über mich hätten abgewickelt werden müssen? Was bedeutet ein solcher Identitäts- und Zugriffsverlust für laufende Abonnements, Support-Beziehungen und vertragliche Verpflichtungen gegenüber Kunden?
In einem Modell, das auf zentraler Cloud-Identität, Partnerrollen und automatisierten Verlängerungsprozessen basiert, ist der Ausfall einer solchen Kernidentität kein Randproblem – sondern ein systemisches Risiko mit direkter Auswirkung auf Dritte.
Der Anfang: Ein vermeintlicher Standard-Ausfall
Am Samstag meldeten sich mehrere Kunden telefonisch bei mir.
Tenor: „Mails kommen zurück, wir erreichen dich nicht.“
Meine erste Einschätzung war pragmatisch und rückblickend naheliegend: Wochenende, Microsoft, vermutlich ein temporärer Server- oder Backend-Ausfall. Solche Störungen kommen vor. Sie werden nicht immer aktiv kommuniziert und regeln sich üblicherweise innerhalb weniger Stunden oder spätestens am nächsten Werktag. Online hatte ich bereits Informationen gefunden die ein temporäres Versorgungsproblem bei Microsoft anzeigten.
Ich ging daher davon aus, dass sich das Problem von selbst erledigen würde und reagierte erstmal nur abwartend.
Erste Zweifel
Eigene Tests bestätigten die Nichtzustellbarkeit. E-Mails an ***@daniel-schuppelius.de kamen nicht an und wurden mit Zustellfehlern quittiert.
Als jedoch:
- keine Entstörungsmeldung erschien,
- sich auch am Montag keine Verbindung mehr zum System herstellen ließ,
- und der Zustand unverändert blieb,
wurde ich langsam unruhig.
Denn ab diesem Punkt war klar: Das ist kein kurzzeitiger Ausfall, sondern etwas Grundsätzlicheres.
Microsoft quittierte Zustellversuche mit:
550 5.1.10 RESOLVER.ADR.RecipientNotFound
Recipient ***@daniel-schuppelius.de not found by SMTP address lookup
Aus Sicht der Microsoft-Infrastruktur existierte meine Adresse schlicht nicht mehr.
Support in der Theorie – und in der Praxis
Spätestens jetzt wollte ich den Microsoft-Support einschalten. Und genau hier zeigte sich das nächste strukturelle Problem. Bei Microsoft ist es alles andere als trivial, einen Supportfall zu eröffnen, wenn man sich nicht mehr einloggen kann.
Die Supportlandschaft ist stark automatisiert:
- Telefonische Anfragen laufen zunächst über KI-gestützte Filtersysteme.
- Ziel dieser Systeme ist es erkennbar, möglichst viele Anfragen direkt
- auf Kurzlinks,
- auf Selbsthilfeartikel,
- oder auf automatisierte Prozesse
umzuleiten.
Das funktioniert, solange man:
- angemeldet ist
- oder ein Standardproblem hat.
In meinem Fall war genau das nicht möglich:
- keine Anmeldung
- kein Zugriff auf das Admin-Portal
- kein bestehendes Ticket
Hinzu kam:
Am Wochenende ist kein Geschäftskundensupport erreichbar.
Am Montag folgte eine Odyssee durch:
- KI-Hotlines
- falsche Supportbereiche (u. a. Consumer- und Surface-Support)
- Supportnummern, die mir erklärten, dass sie nicht zuständig sind
Erst nach mehreren Anrufen und diversen Fehlleitungen gelang es mir, mit einem Mitarbeiter des Geschäftskundensupports zu sprechen. Dabei entstand der Eindruck, dass weniger formale Zuständigkeit entscheidend war, sondern vielmehr, die richtigen Formulierungen zu verwenden, um die automatisierten Filtersysteme zu umgehen. Salopp gesagt: Erst nachdem ich den „Code“ herausgefunden hatte – ab wann und mit welchen Worten eine Weiterleitung zu einem Menschen erfolgt – konnte ich den Fall überhaupt schildern.
Ein zentrales Problem: Kein Login, kein Ticket
Das eigentliche Kernproblem wurde schnell deutlich:
Mein Hauptkonto ist zugleich:
- Benutzerkonto
- administratives Hauptkonto
- Partner-Identität
Dieses Konto war:
- nicht mehr anmeldbar
- nicht empfangsfähig
- serverseitig per SMTP nicht auflösbar
Ohne funktionierende Anmeldung war es mir nicht möglich:
- regulär Support-Tickets zu eröffnen
- Eskalationen im Portal nachzuvollziehen
- Statusinformationen einzusehen
Ich war vollständig auf telefonischen Support angewiesen –
werktags, zu Bürozeiten, ohne Historie, ohne Transparenz.
Teilweise Reparatur – das Hauptproblem bleibt
In den folgenden Tagen passierte Folgendes:
- Sekundäre Benutzerkonten wurden wiederhergestellt
- Diese konnten sich wieder anmelden
- Mailfunktionen für diese Konten funktionierten wieder
- Freigegebene Postfächer waren zeitweise erreichbar
Nicht wiederhergestellt wurde das zentrale Konto.
Bis heute:
- keine Anmeldung möglich
- kein Mail-Empfang
- SMTP-Ablehnung mit
550 5.1.10 RESOLVER.ADR.RecipientNotFound
Nach außen wirkte mein Unternehmen damit schlicht: nicht existent.
Geschäftliche Folgen
Das ist kein Komfortproblem. Die Folgen sind real:
- Kundenkommunikation nur noch per Telefon oder Ersatz-Mailadressen
- Keine Möglichkeit, neue Partnerverträge abzuschließen
- Keine saubere Abwicklung von Microsoft-Abonnements
- Eingeschränkte CSP-Anbindung (in meinem Fall über die Telekom)
- Laufender Betrieb nur noch im Notmodus
- Eingeschränkte Kommunikation über mein ERP-System
- Kundenkontakt
- Rechnungsversand bzw. -empfang
- Kein bzw. eingeschränkter Emailempfand für mein Ticketsystem
- Keine Statusmeldungen von Systemen die ich verwalte
- Loginmechanismen bei anderen Diensten und Einkaufsplattformen gestört
- Eingeschränkte Kommunikation über mein ERP-System
Und vor allem:
Keine belastbare Aussage von Microsoft, was eigentlich passiert ist oder wann Abhilfe erfolgt.
Warum ich mich an Heise gewandt habe
Nach mehreren Wochen ohne Lösung, ohne belastbare Statusinformation und ohne funktionierenden Wiederherstellungsmechanismus blieb mir faktisch nur noch der Notbetrieb.
Zu diesem Zeitpunkt war klar:
- Der reguläre Support kam nicht voran.
- Eskalationen verliefen im Sande.
- Ich hatte keinerlei Möglichkeit, selbst technisch einzugreifen.
In dieser Situation habe ich mich bewusst an Heise gewandt.
Nicht aus Ärger und nicht aus Prinzip, sondern aus reiner Verzweiflung und in der Hoffnung, dass eine journalistische Einordnung den notwendigen Impuls erzeugt, um Bewegung in den Fall zu bringen, habe ich mich an Heise gewandt.
Wenn selbst ein Microsoft Partner über Wochen hinweg keinen wirksamen Hebel mehr hat, bleibt häufig nur noch die Öffentlichkeit als Korrektiv.
Ob und in welcher Form sich Heise des Falls annimmt, liegt selbstverständlich bei der Redaktion. Bis dahin bleibt mir nichts anderes übrig, als dem Microsoft-Support weiterhin beharrlich „auf den Zahn zu fühlen“ – in der Hoffnung, dass sich doch noch eine technische oder organisatorische Lösung findet.
Einordnung: Kontrolle vs. Abhängigkeit
Dieser Vorfall hat meine Sicht auf Cloud-Dienste nachhaltig verändert.
Nicht, weil Cloud grundsätzlich schlecht wäre – sondern weil man sich darüber im Klaren sein muss, was man aufgibt, wenn man die Kontrolle vollständig aus der Hand gibt. In meinem Fall bestand das Problem nicht im fehlenden Know-how. Wäre die Infrastruktur in meinem Einflussbereich gewesen, hätte ich das Problem innerhalb von ein bis zwei Tagen analysiert und behoben.
In der Cloud ist das nicht möglich.
Man hat:
- keinen direkten Systemzugriff
- keine Möglichkeit, selbst einzugreifen
- keine Option, inkonsistente Zustände eigenständig zu korrigieren
Stattdessen ist man abhängig von:
- internen Prozessen des Anbieters
- dem jeweiligen Support-Mitarbeiter
- und letztlich vom Goodwill der Organisation
Das ist kein Vorwurf an Einzelpersonen.
Aber es ist ein strukturelles Risiko, das man bewusst akzeptieren muss.
Fazit
Ich habe mich bewusst für Cloud-Dienste entschieden:
- weniger Wartung
- mehr Zeit für Kunden
Was ich nicht einkalkuliert habe:
- wochenlange Handlungsunfähigkeit
- ohne eigenes Verschulden
- ohne funktionierenden Wiederherstellungsmechanismus
Cloud spart Arbeit, bis sie es nicht mehr tut.
Dieser Beitrag ist kein Aufruf gegen Cloud-Dienste.
Aber er ist ein Plädoyer für:
- mehrere unabhängige Admin-Identitäten
- ernsthaft gedachte Notfall-Szenarien
- realistische Annahmen über Support-Erreichbarkeit
Denn wenn die Cloud entscheidet, dass du nicht existierst, ist guter Rat plötzlich sehr lokal.
Und gerade in der heutigen Zeit sollte man zusätzlich bedenken, dass Abhängigkeitsentscheidungen nicht nur technischer Natur sind, sondern immer auch von politischen und geopolitischen Rahmenbedingungen beeinflusst werden können. Auch wenn Kunden scherzhaft fragen, ob ich „Donald Trump beleidigt habe“, ist das selbstverständlich nicht der reale Hintergrund dieses Falls. Solche Bemerkungen zeigen jedoch, dass ein Bewusstsein dafür existiert, wie machtvoll zentralisierte Plattformen geworden sind – und wie wenig Einfluss der einzelne Nutzer im Ernstfall hat.
Die Geschichte zeigt, dass es immer wieder Personengruppen, Branchen oder Organisationen gibt, die durch politische Entscheidungen, regulatorische Eingriffe oder wirtschaftliche Interessen plötzlich eingeschränkt oder ausgeschlossen werden.
Wer heute vollständig auf externe Cloud-Infrastrukturen setzt, sollte sich daher nicht nur fragen:
- ob der Anbieter technisch zuverlässig ist,
- sondern auch, unter welchen politischen und rechtlichen Bedingungen diese Abhängigkeit steht.
Cloud-Entscheidungen sind damit immer auch Vertrauensentscheidungen – und Vertrauen ist kein technischer Parameter, sondern ein strategischer.
4 Kommentare bisher
Daniel Jörg Schuppelius Eingestellt am 9.Feb. 2026 (23:03:58)
Heute hatte ich erneut ein Gespräch mit dem Datenschutzteam. Inzwischen kann ich kaum noch sagen, wie oft ich denselben Ablauf beschrieben und das Problem demonstriert habe. Es fühlt sich zunehmend so an, als müsste ich bei jedem neuen Ansprechpartner erneut nachweisen, dass tatsächlich ein Login-Problem vorliegt.
Auch heute wurde wieder die Vermutung geäußert, dass eine von mir erstellte Policy den Zugriff blockieren könnte. Es ist allerdings bereits längere Zeit her, dass ich Richtlinien in Azure bzw. Microsoft 365 erstellt oder geändert habe. Wenn diese Annahme zur Lösung beiträgt, akzeptiere ich sie zunächst als Arbeitshypothese – auch wenn ich mir aktuell nur schwer erklären kann, wie eine solche Richtlinie gleichzeitig meinen Login blockieren und dazu führen soll, dass der SMTP-Dienst mein Konto durchgehend als nicht existent behandelt.
Der Eindruck verstärkt sich zunehmend, dass sich die Bearbeitung bislang nahezu ausschließlich auf das Login-System konzentriert, während andere offensichtliche Symptome – insbesondere die serverseitige Behandlung des Kontos als „nicht existent“ – offenbar nicht im gleichen Umfang in die Analyse einbezogen werden. Meiner Einschätzung nach könnte das Problem im Zusammenhang mit einer Lizenzzuordnung dieses Kontos stehen. Wie gesagt, es handelt sich dabei lediglich um eine Vermutung, basierend auf meinem derzeitigen Eindruck des Fehlerbildes.
Die Mitarbeiterin kündigte an, dass das Problem voraussichtlich morgen behoben werden könne und dass hierfür meine MFA-Einstellungen sowie bestehende Policies zurückgesetzt werden sollen, um mir den Login wieder zu ermöglichen. Ich kann mir zwar derzeit nur schwer vorstellen, dass dies tatsächlich die Ursache ist, hoffe aber dennoch, dass sich diese Einschätzung bestätigt – zumal ich in zurückliegenden Supportgesprächen bereits mehrfach gehört habe, dass der Login zurückgesetzt werde. Selbst das Setzen eines neuen Passworts im virtuellen Beisein eines Technikers funktionierte nicht.
Es wird zunehmend schwierig, meinen Kunden die anhaltende Situation zu erklären. Viele warten inzwischen verständlicherweise auf eine belastbare Lösung beziehungsweise zumindest auf eine verlässliche Zeitangabe, wann mit den benötigten Lizenzen gerechnet werden kann.
Daniel Jörg Schuppelius Eingestellt am 6.Feb. 2026 (09:02:57)
Bewegung in den Vorgang kam bislang im Wesentlichen nur dadurch, dass ich wiederholt neue Support-Tickets eröffnet habe. Eine Mitarbeiterin von Microsoft bat mich allerdings darum, keine weiteren Tickets anzulegen, da parallel immer nur ein Ticket bearbeitet werden könne. Gleichzeitig teilte sie mir mit, dass sie sich am nächsten Tag melden werde (also Heute). Als mögliche Ursache nannte sie eine „Policy“, die mein Konto gesperrt habe und die sie entfernen wolle. Um welche Policy es sich konkret handelt, konnte sie mir jedoch nicht sagen – ich hoffe, hierzu noch eine Rückmeldung zu erhalten.
Persönlich bin ich derzeit skeptisch, ob dies tatsächlich die Ursache ist. Der Login-Vorgang bleibt weiterhin bei der Prüfung der Sicherheitsinformationen hängen, und auch ein Zurücksetzen des Passworts ist nicht möglich. Das System meldet unabhängig von Länge und Komplexität stets, dass die Passwortanforderungen nicht erfüllt seien.
Ein vorheriger Supportmitarbeiter zeigte sich über dieses Verhalten ebenfalls überrascht und konnte das Problem in dieser Form nicht erklären. Üblicherweise liegt bei solchen Fehlermeldungen der Verdacht zunächst beim Benutzer vor dem Bildschirm – in diesem Fall deutet jedoch vieles darauf hin, dass die Ursache tiefer im System liegt.
Daniel Jörg Schuppelius Eingestellt am 4.Feb. 2026 (14:58:04)
Der Fall wirft für mich mittlerweile eine grundsätzliche Frage auf:
Wie zuträglich ist die Nutzung stark zentralisierter Cloud-Dienste, wenn man sich an den Anforderungen der NIS2-Richtlinie orientieren muss?
NIS2 verlangt unter anderem belastbare Incident-Response-Prozesse, klare Wiederherstellungsmechanismen und die Fähigkeit, wesentliche Geschäftsprozesse auch bei Störungen aufrechtzuerhalten. In meinem Fall zeigt sich jedoch, wie begrenzt die eigenen Handlungsmöglichkeiten sind, wenn der Anbieter selbst zur Blackbox wird.
Technisch mag ein Dienst verfügbar sein – organisatorisch und wirtschaftlich kann er dennoch ausfallen, ohne dass man selbst eingreifen oder den Prozess beschleunigen kann. Diese Abhängigkeit lässt sich nur schwer mit dem Anspruch vereinbaren, Risiken aktiv zu beherrschen statt sie lediglich zu akzeptieren.
Der Vorfall ist für mich daher weniger eine Abrechnung mit Cloud-Diensten als vielmehr ein Anlass, die eigene Architektur und die getroffenen Abhängigkeitsentscheidungen kritisch zu hinterfragen – insbesondere vor dem Hintergrund regulatorischer Vorgaben wie NIS2.
Daniel Jörg Schuppelius Eingestellt am 4.Feb. 2026 (14:47:04)
Gestern, kurz nach der Veröffentlichung des Artikels, meldete sich erstmals das Datenschutzteam von Microsoft bei mir.
Die Mitarbeiterin war sich zunächst nicht sicher, ob sie für meinen Fall zuständig sei, da dieses Team nach eigener Aussage nur dann tätig wird, wenn kein Zugriff mehr auf Konten möglich ist. Ich habe ihr daraufhin erläutert, dass genau das hier der Fall ist und dass mir von mehreren Supportstellen der unteren Ebenen wiederholt mitgeteilt wurde, der Vorgang müsse an das Datenschutzteam eskaliert werden.
Die Mitarbeiterin kündigte an, sich noch am selben Tag erneut bei mir zu melden.
Wie man sich denken kann, ist das bislang nicht passiert.
Langsam frage ich mich, welche realistischen Optionen mir überhaupt noch bleiben.
Einen Rechtsstreit halte ich persönlich nicht für zielführend – nicht nur wegen des Aufwands, sondern auch, weil das Ergebnis kaum planbar ist. Wie man so sagt: Vor Gericht und auf hoher See ist man in Gottes Hand.
Ich werde mich daher wohl ernsthaft damit auseinandersetzen müssen, meine Infrastruktur wieder selbst zu betreiben.
Angesichts der Datenmenge bedeutet das voraussichtlich mehrere Tage Arbeit, die eigentlich für Kundenprojekte vorgesehen waren.