← Microsoft 365 Collaboration Administration

Dienstzustand und Message Center: zwei Kanäle, zwei Fragen

Eine Funktion, die gestern noch da war, fehlt heute. Der Dienstzustand zeigt alles grün, und der naheliegende Schluss — es liegt an uns — ist in etwa der Hälfte dieser Fälle falsch: Geplante Wartung und angekündigte Änderungen erscheinen im Dienstzustand grundsätzlich nicht, sondern nur im Message Center. In diesem Modul lernst du, welche Frage welcher Kanal beantwortet, was der Unterschied zwischen einem Hinweis und einer Störung tatsächlich aussagt und welche der neun Statuswerte eine Dauerprognose erlauben und welche nicht. Du lernst, warum ausgerechnet Investigation suspended Arbeit für die eigene Organisation bedeutet, warum die selten gefüllte Spalte Act by das stärkste Dringlichkeitssignal ist, warum mehrere gewichtige Administratorrollen das Message Center gar nicht sehen — und warum Archivieren dort nur die eigene Ansicht betrifft.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-12

Grün, und trotzdem geht etwas nicht

Der Servicedesk meldet: Seit heute früh können Nutzer eine Funktion in Teams nicht mehr verwenden, die gestern noch da war. Der Blick auf den Dienstzustand zeigt alles grün. Die naheliegende Schlussfolgerung — es liegt an uns — ist in etwa der Hälfte dieser Fälle falsch.

Denn eine geplante Änderung erscheint nicht im Dienstzustand. Die Dokumentation sagt es ausdrücklich: Geplante Wartungsereignisse werden dort nicht angezeigt; sie stehen im Message Center unter der Kategorie Plan for change. Wer nur einen der beiden Kanäle kennt, sucht in der Hälfte der Fälle an der falschen Stelle — und findet dort zuverlässig nichts.

LernzielDu kannst eine Meldung dem richtigen Kanal zuordnen, du kannst aus Meldungstyp und Status ablesen, welche Erwartung angemessen ist, und du erkennst die wenigen Signale, die eine Handlung bis zu einem Termin verlangen — im Unterschied zu denen, die nur Kenntnisnahme verlangen.

Message Center — Der Kanal für angekündigte Änderungen an Microsoft 365 — neue Funktionen, Umstellungen, Abkündigungen und Hinweise, die vorbereitendes Handeln verlangen. Erreichbar im Microsoft 365 Admin Center unter Health. Er beantwortet nicht, ob gerade etwas gestört ist.

Zwei Kanäle, zwei Fragen

Die Trennung ist sauber, sobald man sie einmal in Fragen übersetzt hat. Beide Kanäle liegen im Admin Center nebeneinander unter Health und beantworten Verschiedenes.

Dienstzustand: Beantwortet: Liegt es gerade am Dienst? Zeigt laufende Störungen und Hinweise sowie die Historie der letzten 30 Tage. Enthält keine geplante Wartung.
Message Center: Beantwortet: Kommt etwas auf uns zu, und müssen wir handeln? Enthält angekündigte Änderungen, Abkündigungen und geplante Wartung.

Die Dokumentation macht die Abgrenzung an einer Stelle besonders deutlich: Meldungen der Message-Center-Kategorie Prevent or fix issues unterscheiden sich von Dienstzustandsmeldungen dadurch, dass sie zu proaktivem Handeln auffordern, um Störungen zu vermeiden. Der Dienstzustand beschreibt, was schon passiert; das Message Center, was passieren wird.

Wenn die Anmeldung selbst nicht gehtBeide Kanäle liegen hinter der Anmeldung am Admin Center. Wer sich gar nicht anmelden kann, findet bekannte Probleme auf der öffentlichen Statusseite unter status.cloud.microsoft. Das ist der einzige Weg, der ohne funktionierenden Tenant auskommt — und er gehört in jedes Notfallblatt.

Störung oder Hinweis

Ist im Dienstzustand etwas zu sehen, trägt es eine von zwei Einstufungen. Der Unterschied ist keine Schwereskala im Ermessen, sondern ein Aussagensatz über Verfügbarkeit.

Hinweis (Advisory): Ein Problem betrifft einige Nutzer, der Dienst ist aber weiterhin verfügbar. Häufig gibt es einen Umgehungsweg; das Problem ist oft zeitweise oder in Umfang und Auswirkung begrenzt.
Störung (Incident): Ein kritisches Problem: Der Dienst oder eine wesentliche Funktion ist nicht verfügbar. Die Auswirkung auf Nutzer ist spürbar; während einer Störung gibt es laufend Aktualisierungen zu Untersuchung, Eindämmung und Bestätigung der Behebung.

Für die eigene Kommunikation ist das der wichtigste Unterschied. Bei einem Hinweis lohnt die Suche nach dem Umgehungsweg und die gezielte Ansprache der Betroffenen. Bei einer Störung ist die Umgehung meist nicht das Thema, sondern die Frage, wie lange es dauert — und dafür liefert der Statuswert mehr als die Einstufung.

Der Statuswert sagt, was zu erwarten ist

Neun Statuswerte beschreiben, wo ein Vorgang steht. Sie sind keine Fortschrittsbalken, sondern Aussagen darüber, was gerade bekannt ist — und genau daraus lässt sich ableiten, was man den eigenen Nutzern sagen kann.

Investigating: Ein mögliches Problem ist bekannt, Informationen und Umfang werden noch gesammelt. Eine Dauerprognose ist hier nicht möglich.
Service degradation: Bestätigt: Es gibt ein Problem, das die Nutzung beeinträchtigen kann — langsamer als üblich, zeitweise Unterbrechungen oder eine nicht funktionierende Funktion.
Service interruption: Der Zugriff auf den Dienst ist betroffen; das Problem ist erheblich und reproduzierbar.
Restoring service: Die Ursache ist identifiziert, die Gegenmaßnahme bekannt, die Wiederherstellung läuft.
Extended recovery: Die Gegenmaßnahme läuft, braucht aber Zeit bis zu allen betroffenen Systemen — oder es wirkt eine vorläufige Abhilfe, bis die dauerhafte greift.
Investigation suspended: Für die weitere Untersuchung werden zusätzliche Angaben von Kunden benötigt. Hier ist die eigene Organisation gefragt.

Drei weitere Werte beschreiben den Ausgang: Service restored bestätigt die Behebung; False positive hält fest, dass der Dienst nach eingehender Prüfung gesund war und keine Auswirkung beobachtet wurde oder die Ursache außerhalb des Dienstes lag; Post-incident report published weist auf einen veröffentlichten Bericht mit Ursache und Folgemaßnahmen hin.

Der Wert, der Arbeit für einen selbst bedeutetInvestigation suspended ist der einzige Statuswert, bei dem der Vorgang auf die eigene Organisation wartet. Wer ihn als „wird untersucht“ liest, blockiert die Bearbeitung, ohne es zu merken. Und False positive bleibt laut Dokumentation in der Historie sichtbar, bis er abläuft — ein gelöster Fall ist es damit nicht, sondern ein zurückgezogener.

Zwischenstand

Kurzcheck

Eine Funktion, die gestern noch da war, ist heute verschwunden. Der Dienstzustand zeigt keinerlei Eintrag. Wo suchst du als Nächstes?

Im Message Center — geplante Änderungen und Wartung erscheinen nicht im Dienstzustand.
In der Historie des Dienstzustands — dort stehen abgeschlossene Vorgänge der letzten 30 Tage.
In den eigenen Änderungsprotokollen — ohne Eintrag im Dienstzustand liegt es an der eigenen Konfiguration.

Treffer. Richtig. Die Dokumentation hält fest, dass geplante Wartungsereignisse nicht im Dienstzustand erscheinen und über das Message Center verfolgt werden, gefiltert auf die Kategorie Plan for change.

Das Message Center und seine drei Kategorien

Jeder Beitrag im Message Center trägt eine von drei Kategorien. Sie sagen, welche Art von Aufmerksamkeit angemessen ist — und sie sind die erste Filterebene für jede Routine.

Prevent or fix issues: Bekannte Probleme, die die eigene Organisation betreffen und möglicherweise Handeln verlangen, um Störungen zu vermeiden. Der proaktive Gegenpart zum Dienstzustand.
Plan for change: Änderungen, die Handeln verlangen können, damit der Dienst normal weiterläuft — etwa geänderte Systemanforderungen oder entfernte Funktionen. Für Änderungen, die ein Handeln der Administration erfordern, werden mindestens 30 Tage Vorlauf angestrebt.
Stay informed: Neue oder aktualisierte Funktionen, die eingeschaltet werden. Zuerst angekündigt über den öffentlichen Roadmap-Kanal. Enthält außerdem geplante Wartung, die zu Ausfallzeiten führen kann.

Die dritte Zeile ist die, die am häufigsten unterschätzt wird: Unter Stay informed steht auch die geplante Wartung, bei der Nutzer zeitweise nicht auf Microsoft 365, eine bestimmte Funktion oder einen Dienst zugreifen können. Eine Kategorie, deren Name nach Lesestoff klingt, enthält damit die einzige Ankündigung geplanter Nichtverfügbarkeit, die es gibt.

Die Signale, die wirklich Handlung verlangen

Ein Message Center mit dreistelligen Beitragszahlen je Monat ist nur brauchbar, wenn man weiß, welche Felder Dringlichkeit tragen. Vier davon lohnen die Aufmerksamkeit.

Act by: Ein Datum steht hier laut Dokumentation nur, wenn eine Änderung ein Handeln bis zu einer Frist verlangt. Die Spalte wird selten verwendet — und genau deshalb ist ein Eintrag darin ein starkes Signal.
Major update: Änderungen, die bei erforderlichem Handeln mindestens 30 Tage im Voraus angekündigt werden. Dazu zählen unter anderem Änderungen an Posteingang, Besprechungen, Delegierungen, Freigabe und Zugriff, Änderungen an sichtbaren Kapazitäten und neue Dienste, die mit eingeschalteten Voreinstellungen ausgerollt werden.
Tags: Retirement, Admin impact, User impact, Data privacy, Feature update, New feature — die schnellste Vorsortierung nach Art der Betroffenheit.
Relevance: Eine Einschätzung in High, Medium und Low, die aus App- und Dienstnutzung sowie der Art der Änderung errechnet wird. Bei neuen Beiträgen kann sie kurzzeitig auf Processing stehen.

Dazu kommt eine Angabe, die für die Priorisierung oft mehr wert ist als jede Einstufung: Beim Öffnen eines Beitrags wird die Zahl der Nutzer angezeigt, die die betroffene Anwendung oder den Dienst in den letzten 28 Tagen tatsächlich genutzt haben. Eine Änderung an einem Dienst mit drei aktiven Nutzern ist eine andere Aufgabe als dieselbe Änderung an einem mit dreitausend.

Der Freigabestand je FunktionFür einen Teil der Ankündigungen zeigt das Feld Status for your org den Freigabestand im eigenen Tenant: Scheduled, Rolling out oder Launched. Verfügbar ist das laut Dokumentation nur für Funktionen, die auch über den öffentlichen Roadmap-Kanal angekündigt sind und allgemeine Verfügbarkeit erreicht haben. Fehlt das Feld, heißt das nicht, dass nichts kommt — nur, dass es dafür keinen Stand gibt.

Selbst melden und benachrichtigt werden

Der Dienstzustand ist kein reiner Lesekanal. Tritt ein Problem auf, das dort nicht steht, lässt es sich über Report an issue melden. Die Meldung wird laut Dokumentation mit Daten und Meldungen anderer Organisationen abgeglichen, um festzustellen, wie verbreitet das Problem ist und ob es aus dem Dienst stammt — trifft das zu, entsteht daraus ein neuer Vorgang, dessen Bearbeitung sich verfolgen lässt. Die eigenen Meldungen samt Status stehen unter Reported issues.

Das ist der Weg, der aus einer lokalen Beobachtung einen überprüfbaren Vorgang macht. Er lohnt auch dann, wenn man nicht sicher ist: Die Auswertung erfolgt gegen den Bestand anderer Tenants, und genau diese Perspektive fehlt der eigenen Organisation.

Benachrichtigungen je Dienst: Bis zu zwei Adressen, wahlweise für Störungen oder Hinweise, und begrenzt auf ausgewählte Dienste.
Benachrichtigungen je Vorgang: Über Manage notifications for this issue lässt sich ein einzelner laufender Vorgang abonnieren, statt alle Ereignisse eines Dienstes zu erhalten.
Mobil: Beide Kanäle sind über die Admin-App auf dem Mobilgerät samt Push-Benachrichtigungen erreichbar.

Zwei Tiefen von AktualisierungenDie Beiträge zu einem Vorgang gibt es in zwei Ausführungen: Quick Update sind kurze, häufige Zwischenstände für breit wirkende Störungen und stehen allen Kunden zur Verfügung; Additional Details liefern reichere technische Angaben und tiefere Einblicke in die Bearbeitung, sind aber an dieselben Voraussetzungen gebunden wie die erweiterte Exchange-Online-Überwachung. Wer detailliertere Angaben vermisst, vermisst unter Umständen kein Detail, sondern eine Voraussetzung.

Wer die Meldungen überhaupt sieht

Beide Kanäle liegen hinter Rollen, und die Zuordnung ist nicht so, wie man sie vermuten würde. Für den Dienstzustand nennt die Dokumentation ausdrücklich die Rollen Service Support Administrator und Helpdesk Administrator — beides Rollen ohne weitreichende Rechte, was für eine Servicedesk-Besetzung günstig ist.

Beim Message Center ist die interessante Liste die der Ausnahmen. Die meisten Administratorrollen können Beiträge lesen, einige aber nicht — darunter Compliance administrator, Conditional access administrator, Device administrators, Directory readers, Intune service administrator, Privileged role administrator und Reports reader.

Dass ausgerechnet Privileged role administrator und Compliance administrator außen vor sind, überrascht regelmäßig — es sind Rollen mit erheblichem Gewicht und ohne Zugang zu den Ankündigungen.
Für Personen, die nur lesen und weitergeben sollen, gibt es die eigene Rolle Message center reader — ohne weitere administrative Rechte.
Beiträge mit dem Tag Data privacy sind auf globale Administratoren und die Rolle Message center Privacy reader beschränkt.

Der Verteilweg für alle anderenWer keinen Zugang hat, kann Beiträge trotzdem bekommen: Ein Beitrag lässt sich per E-Mail an beliebige Personen teilen, und ein kopierter Link funktioniert nur für Empfänger, die selbst Zugang haben. Der Unterschied zwischen beiden Wegen entscheidet darüber, ob eine Weitergabe ankommt.

Was die Kanäle nicht leisten

Vier Eigenschaften begrenzen, was sich auf diese Kanäle stützen lässt. Keine davon ist ein Mangel — aber jede führt zu falschen Erwartungen, wenn man sie nicht kennt.

Archivierung ist persönlich: Die Ansicht im Message Center gilt je Benutzerkonto. Wer einen Beitrag archiviert, entfernt ihn nur aus der eigenen Ansicht; für andere Administratoren bleibt er stehen.
Historie ist kurz: Der Dienstzustand zeigt die Vorgänge der letzten 30 Tage. Für ältere Fragen gibt es dort keine Antwort mehr.
E-Mails sind englisch: Die Anzeige lässt sich maschinell übersetzen. Der wöchentliche Auszug und per Mail versandte Beiträge kommen laut Dokumentation ausschließlich auf Englisch.
Zwei Adressen je Administrator: Für Benachrichtigungen lassen sich bis zu zwei Adressen hinterlegen — und zwar je Administratorkonto, nicht je Organisation.

Die erste Zeile ist die betrieblich folgenreichste. Weil Archivieren nur die eigene Sicht betrifft, gibt es keinen gemeinsamen Bearbeitungsstand: Zwei Administratoren können denselben Beitrag unabhängig voneinander bearbeiten oder beide auf den anderen warten. Für eine Zuständigkeitsverteilung braucht es deshalb ein Werkzeug außerhalb des Message Center — die Dokumentation nennt dafür die Übernahme der Aufgaben nach Planner.

Der programmatische WegWer die Auswertung automatisieren will, ist nicht auf die Oberfläche angewiesen: Dienstzustand und Message-Center-Meldungen sind über die Service Communications API in Microsoft Graph abrufbar. Das ist der Weg, auf dem sich eine eigene Vorsortierung nach Relevanz, Tag und Nutzerzahl bauen lässt.

Durchgerechnet: eine Meldung sauber bearbeiten

Von der Nutzermeldung zur begründeten Antwort

Szenario

Der Servicedesk meldet, dass eine Teams-Funktion seit heute früh bei mehreren Nutzern fehlt. Es gibt keine eigene Änderung in diesem Zeitraum. Die Fachabteilung fragt, wann es wieder geht.

Anforderungen

Feststellen, ob es an einem Dienst, an einer Änderung oder an der eigenen Umgebung liegt
Eine Aussage zur Dauer treffen, die belegbar ist
Die Betroffenen so informieren, dass die Auskunft in zwei Tagen noch stimmt

Schritte

Beide Kanäle prüfen, nicht einen. Der Dienstzustand beantwortet die Störungsfrage, das Message Center die Änderungsfrage — ein leerer Dienstzustand beantwortet die zweite nicht.
Im Dienstzustand zuerst den Abschnitt Issues for your organization to act on ansehen: Steht dort etwas, liegt Arbeit bei der eigenen Organisation, nicht beim Anbieter.
Steht ein Vorgang unter Active issues Microsoft is working on, Einstufung und Status lesen. Ein Hinweis erlaubt die Suche nach einem Umgehungsweg; eine Störung nicht.
Das Feld Issue origin prüfen — es sagt, ob das Problem bei Microsoft oder in der eigenen Umgebung gefunden wurde. Diese eine Zeile entscheidet, wer weiterarbeitet.
Bei leerem Dienstzustand ins Message Center wechseln und auf Plan for change sowie Stay informed filtern: Eine angekündigte Änderung oder geplante Wartung erscheint ausschließlich dort.
Für die Dauerfrage den Statuswert übersetzen: Bei Investigating ist keine Prognose möglich; bei Restoring service läuft die Behebung; bei Extended recovery dauert es auch nach der Korrektur noch.
Steht Investigation suspended, liegt der Vorgang bei der eigenen Organisation — dann sind angeforderte Daten oder Protokolle zu liefern, bevor irgendetwas weitergeht.
Die Auskunft an die Fachabteilung auf Einstufung, Status und Herkunft stützen, nicht auf eine geschätzte Dauer — und den Beitrag per E-Mail teilen, statt einen Link zu schicken, den die Empfänger nicht öffnen können.

Merksatz: Vier Felder — Einstufung, Status, Herkunft und Kategorie — beantworten die Frage vollständig und belegbar. Die Dauer beantwortet keines davon, und das ist die ehrlichste Auskunft, die man geben kann.

Der Preis und die Route

Diese Kanäle sind die einzige Quelle, aus der eine Organisation erfährt, dass sich ihre Plattform ändert — und sie kosten laufende Aufmerksamkeit. Ein Message Center, das niemand liest, produziert Änderungen, die als Störungen im Servicedesk ankommen. Ein Message Center, das jemand vollständig liest, kostet mehrere Stunden im Monat für Beiträge, von denen die meisten nichts mit der eigenen Umgebung zu tun haben.

Der Ausweg ist Vorsortierung statt Vollständigkeit: nach Relevanz, nach Tag, nach tatsächlicher Nutzerzahl — und eine Routine, die nur die wenigen Beiträge mit Act by und Major update wirklich durcharbeitet. Der Preis davon ist ebenso ehrlich zu benennen: Man verzichtet bewusst darauf, alles gelesen zu haben, und verlässt sich auf eine Einstufung, die von außen kommt.

Frage bestimmen: Störung oder Änderung?→Dienstzustand: erst die eigene Handlungsliste, dann die des Anbieters→Einstufung, Status und Herkunft lesen — in dieser Reihenfolge→Message Center nach Kategorie, Tag und Nutzerzahl vorsortieren→Beiträge mit Frist außerhalb des Message Center nachverfolgen

Zwei Kanäle, zwei Fragen

Das nächste Modul geht von der Ankündigung zur Untersuchung: Was zu tun ist, wenn etwas offensteht, das nicht offenstehen sollte — und wie man dabei den Bestand sichert, statt ihn zu zerstören.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität3 Primärquellen · zuletzt geprüft: 2026-09-12