Ich arbeite seit Jahren als IT-Dienstleister und Microsoft Partner. Microsoft 365 ist dabei kein „Spielzeug“, sondern geschäftliche Grundlage: E-Mail-Kommunikation, Partnerstatus sowie Lizenz- und Abonnementvertrieb.

Am 10. Januar 2026 hat genau diese Grundlage aufgehört zu existieren.

Nicht schleichend. Nicht teilweise.
Sondern technisch eindeutig: Meine Geschäftsadresse wurde serverseitig als „nicht vorhanden“ behandelt.

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.

Erste Zweifel

Eigene Tests bestätigten die Nichtzustellbarkeit. E-Mails an ***@daniel-schuppelius.de kamen nicht an, Rückmeldungen blieben aus.

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 inzwischen 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

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.