Microsoft 365 aus der Praxis – Roadmap, Security & Compliance
Noch eine Webseite, die sich hauptsächlich um Microsoft 365 drehen wird, als ob es noch nicht genug davon gibt … Und ja, das gleiche habe ich auch gedacht, …
Worum es hier geht
Aber ich brauche wieder einen Ort, an dem ich Gedanken rund um die Dinge, die mich beschäftigen runterschreiben kann, im Nachgang etwas nachlesen kann und es wiederfinde, also wieso nicht wieder ein Blog schreiben.
Was euch hier erwartet
Nur ein Blog, in dem ich meine Gedanken zu Microsoft 365 festhalten werde, dieses kann von einem einfach oh so geht das auch, bis zu einem komplexen Artikel alles werden.
Ich habe mich bewusst für ein sehr minimalistisches Design entschieden, denn ich persönlich bevorzuge es, Texte schnell und einfach lesen und zusammenfassen zu können und nicht von vielen anderen Dingen abgelenkt zu werden.
Technisch könnte Exchange Mails aus dem Internet direkt annehmen. In der Praxis tun das die wenigsten Umgebungen, und meine Demo auch nicht. Vor den Exchange-Servern stehen zwei Mailgateways in einer eigenen DMZ. Sie sind die einzigen Systeme, die Mails von außen überhaupt sehen.
Warum ein Gateway davor?
Die Idee ist einfach: Alles, was aus dem Internet kommt, wird geprüft, bevor es das interne Netz erreicht. Spam, Viren und offensichtlich gefälschte Absender bleiben draußen. Exchange bekommt nur noch, was den Filter passiert hat.
Dazu kommt die Entkopplung. Die Gateways stehen in einem Netz, aus dem nur genau definierte Verbindungen nach innen erlaubt sind: Mails an Exchange zustellen, Namensauflösung und Uhrzeit von den Domain Controllern holen, sonst nichts. Wird ein Gateway kompromittiert, steht der Angreifer nicht automatisch im internen Netz.
Zwei statt einem
Ich setze das Open-Source-Produkt Proxmox Mail Gateway ein, als Verbund aus zwei Knoten. Konfiguriert wird nur auf einem, der andere übernimmt die Einstellungen automatisch. Beide stehen mit gleicher Priorität als Mailempfänger der Domäne im DNS.
Das sorgt für eine angenehme Eigenschaft von E-Mail: Fällt ein Gateway aus, versuchen sendende Server es einfach beim anderen. Dafür braucht es keinen Load Balancer und keine Zusatztechnik. In der Demo schalte ich ein Gateway ab und schicke dieselbe Testmail noch einmal. Sie kommt an.
Wer zwei Exchange-Server betreibt, braucht etwas davor, das die Zugriffe verteilt. Clients sollen eine einzige Adresse kennen, nicht zwei Server. Und fällt ein Server aus, soll niemand das merken. Diese Aufgabe übernimmt in meiner Demo ein Load Balancer von Kemp in der kostenlosen Variante.
Spannend ist weniger, dass es ihn gibt, sondern wie er arbeitet. Zwei Entscheidungen haben die ganze Architektur geprägt.
Entscheidung 1: Die Verschlüsselung bleibt zu
Viele Load Balancer entschlüsseln den Datenverkehr, schauen hinein und verschlüsseln ihn dann neu. Das nennt man SSL-Offloading, und es erlaubt clevere Dinge, etwa eine Prüfung jedes einzelnen Exchange-Dienstes.
Bei Exchange SE geht das so nicht mehr. Der Schutzmechanismus Extended Protection, den ich in Teil 3 erwähnt habe, bindet die Anmeldung an die verschlüsselte Verbindung zwischen Client und Server. Bricht ein Gerät dazwischen diese Verbindung auf und verschlüsselt sie mit einem eigenen Zertifikat neu, scheitert die Anmeldung. Microsoft hat das so gewollt: Es ist genau der Trick, mit dem Angreifer Anmeldungen abfangen und weiterreichen.
Neu verschlüsseln mit genau demselben Zertifikat wäre erlaubt, lässt sich bei meinem Load Balancer aber nicht mit dem transparenten Modus kombinieren, um den es gleich geht. Er reicht die verschlüsselte Verbindung deshalb unverändert durch. Er braucht kein Zertifikat und sieht keine Inhalte. Der Preis: Er kann nicht prüfen, ob Outlook im Web oder die mobile Synchronisation einzeln funktionieren. Er prüft jeden Server als Ganzes über eine Statusseite, die Exchange dafür bereitstellt.
Der eindrucksvollste Moment jeder Exchange-Demo dauert nur wenige Sekunden. Ich schalte vor den Augen der Teilnehmer einen Exchange-Server hart aus, so als würde jemand den Stecker ziehen. Und Outlook arbeitet nach einer kurzen Unterbrechung einfach weiter.
Möglich macht das eine Database Availability Group, kurz DAG. Das Konzept ist alt und bewährt, aber es lässt sich erstaunlich schwer erklären, solange man es nur auf Folien zeigt.
Das Prinzip in drei Sätzen
In der Demo gibt es zwei Postfachdatenbanken und zwei Exchange-Server. Jede Datenbank ist auf einem Server aktiv und wird laufend auf den anderen kopiert, wo sie passiv mitläuft. Fällt ein Server aus, schaltet Exchange die passive Kopie auf dem verbleibenden Server automatisch aktiv.
Damit nicht beide Server gleichzeitig glauben, sie seien allein übrig, gibt es einen Zeugen. In meiner Demo ist das der Verwaltungsserver. Er hat keine Postfächer, aber eine Stimme: Bei zwei Servern entscheidet er, welche Seite die Mehrheit hat und weiterarbeiten darf.
Drei Vorführungen, drei Botschaften
Der geplante Wechsel zeigt den Alltag: Ich verschiebe eine Datenbank per Befehl auf den anderen Server, etwa vor einem Update. Outlook bleibt verbunden, der Anwender merkt nichts. Die Botschaft an IT-Leiter: Wartung ist kein Ausfall mehr.
Wer zum ersten Mal Exchange Server Subscription Edition installiert, sucht vergeblich nach dem großen Neuanfang. Das ist keine Kritik, sondern Absicht. Die erste Version von Exchange SE ist funktional dasselbe wie Exchange 2019 mit dem letzten Cumulative Update 15. Neue Funktionen sollen erst mit dem nächsten Update, CU1, kommen.
Warum das eine gute Nachricht ist
Für Kunden, die von Exchange 2019 kommen, ist der Umstieg damit vor allem ein Wechsel von Version und Lizenzmodell, kein Technologiewechsel. Administratoren finden dieselben Verwaltungswerkzeuge, dieselben Konzepte und dieselben Fallstricke. Wer Exchange 2019 betrieben hat, kann Exchange SE betreiben.
Genau das zeige ich in der Demo auch: Die Oberfläche, die Outlook-Anbindung und die Hochverfügbarkeit sehen aus wie gewohnt. Der Unterschied steckt im Kleingedruckten.
Was sich im Kleingedruckten ändert
Der Name verrät es: Exchange SE wird im Abonnement lizenziert. Für die erste Version akzeptiert Exchange laut Microsoft noch einen vorhandenen Exchange-2019-Schlüssel. Ein eigener SE-Schlüssel wird erst mit einem künftigen Update Pflicht. Ohne Schlüssel läuft Exchange 180 Tage als Testversion. Danach weist die Verwaltungsoberfläche darauf hin, die Funktion bleibt aber erhalten. Für eine Demo ist das bequem, für eine Produktivumgebung kein Zustand: Die Lizenzierung gehört vor den Start geklärt, nicht danach.
Die einfachste Exchange-Demo wäre ein einzelner Server mit einem Client daneben. Sie wäre schnell gebaut und würde trotzdem nichts beweisen. Kunden betreiben Exchange nicht im luftleeren Raum, sondern zwischen Firewalls, Load Balancern und Mailfiltern. Genau dieses Zusammenspiel wollte ich zeigen können.
Herausgekommen sind zehn virtuelle Maschinen in fünf getrennten Netzen.
Wer wo steht
DC-Netz: zwei Domain Controller für Active Directory, DNS und die interne Zertifizierungsstelle. Servernetz: zwei Exchange-Server und ein Verwaltungsserver, von dem aus administriert wird. Clientnetz: ein Windows-11-Rechner mit Outlook, der den Anwender spielt. LB-Netz: der Load Balancer mit der Adresse, über die alle Clients Exchange erreichen. DMZ: zwei Mailgateways, die Mails aus dem Internet annehmen und prüfen. In der Mitte sitzt eine Firewall, die alle fünf Netze verbindet und festlegt, wer mit wem sprechen darf. Sie ist auch der Weg ins Internet.
Warum so viele Netze?
Der naheliegende Einwand: Für eine Demo wäre ein gemeinsames Netz doch einfacher. Das stimmt, aber es hätte drei Dinge unmöglich gemacht.
Erstens den Load Balancer im sogenannten transparenten Modus. In diesem Modus sehen die Exchange-Server die echte Adresse des Anwenders statt der des Load Balancers. Das funktioniert nur, wenn Clients und Server in verschiedenen Netzen liegen. Warum mir das wichtig ist, erkläre ich in Teil 5.
Seit dem 14. Oktober 2025 bekommen Exchange 2016 und Exchange 2019 keinen Support mehr. Viele Unternehmen, mit denen ich spreche, haben ihre Entscheidung trotzdem noch vor sich: komplett in die Cloud, oder E-Mail weiter im eigenen Rechenzentrum betreiben? Für alle, die vor Ort bleiben wollen oder müssen, heißt der Nachfolger Exchange Server Subscription Edition, kurz Exchange SE.
In solchen Gesprächen habe ich eines gelernt: Folien überzeugen niemanden. Ein Architekturbild mit zwei Servern und einem Pfeil erklärt Hochverfügbarkeit, aber es zeigt sie nicht. Was Kunden wirklich wissen wollen, ist konkreter. Was passiert mit Outlook, wenn ein Server ausfällt? Wie lange dauert ein geplanter Wechsel? Wie kommt eine Mail von außen sicher ins Postfach?
Deshalb habe ich eine eigene Demo-Umgebung für Exchange SE aufgebaut. Sie soll realistisch sein, aber völlig isoliert von allem Produktiven.
Was die Demo zeigt
Im Kern stehen zwei Exchange-Server, die ihre Datenbanken gegenseitig spiegeln. Fällt einer aus, übernimmt der andere. Davor sitzt ein Load Balancer, der die Zugriffe verteilt, und eine Firewall, die alle Netze voneinander trennt. Mails aus dem Internet laufen über zwei Mailgateways, die Spam und Viren aussortieren. Ein Windows-11-Client mit Outlook spielt den Anwender.
Es gibt Roadmap-Einträge, die man beobachtet, weil sie etwas Neues bringen. Und es gibt solche, die man beobachtet, weil man auf ihnen eine Planung aufgebaut hat. 429876 – „Microsoft Purview compliance portal: Information Protection – MIP auto-labeling for Azure SQL & Storage" gehörte in die zweite Kategorie. Am 24. September 2026 hat Microsoft den Eintrag auf Cancelled gesetzt.
Die Begründung ist ein Einzeiler:
„We have decided not to move forward with this change at this time and will communicate via a new Roadmap item when we choose to proceed."
Kein technischer Grund, keine Alternative im selben Atemzug, kein neues Zieldatum. Für alle, die Datenklassifizierung jenseits von Microsoft 365 planen, ist das trotzdem eine der relevanteren Nachrichten dieses Monats.
Die Fakten zum Roadmap-Eintrag Feld Wert Roadmap-ID 429876 Titel Microsoft Purview compliance portal: Information Protection – MIP auto-labeling for Azure SQL & Storage Status Cancelled (24.09.2026) Release-Phase (ursprünglich) Preview Preview (geplant) Juli 2024 General Availability (zuletzt geplant) April 2026 Zugehörige Message-Center-Meldung MC933531 Der ursprüngliche Umfang laut Eintrag: „Extend your sensitivity labels to specific or all subscriptions within Azure Storage and Azure SQL Server via auto-labeling policy." Das Versprechen war also ausdrücklich subscription-scoped – man hätte eine Richtlinie definiert und sie auf ausgewählte oder alle Subscriptions angewendet, ohne dabei die bestehende M365-Konfiguration anzufassen. Genau dieses Modell existiert jetzt nicht mehr.
Auf der Microsoft 365 Roadmap steht ein Eintrag, der in keinem Community-Roundup auftaucht und in zwei Zeilen abgehandelt ist: „Microsoft Teams: Add alternate text to images shared from OneDrive and SharePoint" (ID 571687). Die Beschreibung bleibt nüchtern – Nutzende sollen die Zugänglichkeit verbessern können, indem sie Bildern einen Alternativtext geben.
Kleine Funktion, große Vorgeschichte. Denn Teams konnte das schon einmal, und im neuen Client ist es an entscheidenden Stellen verloren gegangen.
Die Fakten zum Roadmap-Eintrag Feld Wert Roadmap-ID 571687 Titel Microsoft Teams: Add alternate text to images shared from OneDrive and SharePoint Produkt Microsoft Teams Status In development Release-Phase General Availability Verfügbarkeit (Public Disclosure) November CY2026 Public Preview noch nicht terminiert Plattformen Desktop Zweck laut Microsoft „improve accessibility by adding alternate text to images" Zwei Einschränkungen fallen sofort auf. Erstens ist als Plattform ausschließlich Desktop genannt – Web und Mobile sind im Eintrag nicht adressiert. Zweitens gibt es keinen weiterführenden Link und keinen Preview-Termin; technische Details bleiben offen.
Und drittens, für die Einordnung am wichtigsten: Der Eintrag taucht in den einschlägigen Roadmap-Roundups (SharePoint Stuff, Planet Technologies, Level Up M365) bislang nicht auf. Wer eine Bewertung sucht, muss sie sich aus dem Bestand bauen – aus der Funktionshistorie in Teams und aus dem regulatorischen Umfeld.
Am 21. September 2026 ist auf der Microsoft 365 Roadmap ein Eintrag aufgetaucht, der in der Kurzfassung leicht untergeht, in der Praxis aber eine seit Jahren offene Lücke schließt: „Microsoft Teams: Granular Conditional Access for Teams meetings" (ID 571879).
Die Beschreibung ist knapp gehalten: Organisationen erhalten mehr Kontrolle über den Zugang zu sensiblen Besprechungen. Administratoren sollen Conditional-Access-Richtlinien auf ausgewählte Meetings anwenden können, sodass Teilnehmende die Sicherheitsanforderungen der Organisation erfüllen müssen, bevor sie beitreten.
Die Fakten zum Roadmap-Eintrag Feld Wert Roadmap-ID 571879 Titel Microsoft Teams: Granular Conditional Access for Teams meetings Status In development Release-Phasen General Availability, Targeted Release Verfügbarkeit (Public Disclosure) November CY2026 Public Preview noch nicht terminiert Plattformen Desktop, Web Cloud-Instanz Worldwide (Standard Multi-Tenant) Angelegt / geändert 21.09.2026 Zwei Punkte sind bemerkenswert. Erstens: Es gibt keinen moreInfoLink und keinen Termin für eine Public Preview – technische Details bleiben damit offen. Zweitens: Der Eintrag ist zum Zeitpunkt dieses Beitrags erst wenige Stunden alt. In den einschlägigen Community-Roundups (etwa SharePoint Stuff, Level Up M365, Planet Technologies) ist er noch nicht aufgeschlagen. Wer die Einordnung sucht, muss sie sich aus dem bestehenden Wissen über Conditional Access, Authentication Contexts und Meeting-Schutz selbst bauen. Genau das leistet dieser Beitrag.
Neue Teams-Funktion: Benachrichtigungen temporär pausieren Die Microsoft 365 Roadmap führt unter der ID 569205 eine neue Funktion für Microsoft Teams: Nutzer können ihre Benachrichtigungen künftig für einen selbst gewählten Zeitraum vollständig pausieren, ohne die bestehenden Benachrichtigungseinstellungen dauerhaft zu verändern.
„Users can now temporarily pause all notifications to minimize interruptions and stay focused on important work, meetings, or other priorities, without changing their existing notification settings."
— Microsoft 365 Roadmap (RM569205)1
Vorteile im Überblick Weniger Unterbrechungen, mehr Fokus: Die Funktion reduziert Benachrichtigungsüberlastung und ermöglicht konzentriertes Arbeiten bei wichtigen Aufgaben oder Meetings.2 Keine dauerhafte Umkonfiguration nötig: Die individuellen Benachrichtigungseinstellungen bleiben erhalten. Nach Ablauf der gewählten Pause werden sie automatisch wieder aktiviert.2 Plattformübergreifend verfügbar: Die Funktion steht auf Desktop, Web, Mac, iOS und Android zur Verfügung.2 Kein Admin-Aufwand: Es ist keine Aktion durch IT-Administratoren erforderlich – die Aktivierung erfolgt automatisch clientseitig.2 So wird die Funktion aktiviert Teams-App öffnen (Desktop, Web oder Mobile). Auf das Profilmenü oben rechts in der Anwendung klicken. Gewünschte Pausendauer für Benachrichtigungen auswählen. Nach Ablauf der Zeit greifen automatisch wieder die vorherigen Einstellungen. Eine gesonderte Konfiguration durch Administratoren ist laut Microsoft nicht erforderlich.2