# Dienstzustand und Message Center: zwei Kanäle, zwei Fragen > Meldungen dem richtigen Kanal zuordnen und aus Einstufung, Status und Herkunft eine belegbare Auskunft ableiten — statt aus einer geschätzten Dauer. Track: [Microsoft 365 Collaboration Administration](https://physar.tech/learn/m365-collaboration) Kanonische Fassung: https://physar.tech/learn/m365-collaboration/service-change-management Stand: 2026-09-12 Interaktiver Teil: 9 Checks (nur im Browser) ## Dienstzustand und Message Center: zwei Kanäle, zwei Fragen ### 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. > **Lernziel:** Du 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 geht:** Beide 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 bedeutet:** `Investigation 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? - [x] 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. > 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 Funktion:** Fü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 Aktualisierungen:** Die 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 anderen:** Wer 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 Weg:** Wer 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 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 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. ## Quellen - learn.microsoft.com/en-us/microsoft-365/admin/manage/message-center — https://learn.microsoft.com/en-us/microsoft-365/admin/manage/message-center - learn.microsoft.com/en-us/microsoft-365/enterp…/view-service-health — https://learn.microsoft.com/en-us/microsoft-365/enterprise/view-service-health - learn.microsoft.com/en-us/microsoft-365/admin/…rs/about-admin-roles — https://learn.microsoft.com/en-us/microsoft-365/admin/add-users/about-admin-roles