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.
Und in der folgenden Mitteilung von Microsoft zu MSExchangeSe habe ich doch im ersten Moment das wichtigste überlesen, Microsoft spoilert den Termin für das Update an…. August 2026 das ist ja nun nicht mehr so weit weg.
https://techcommunity.microsoft.com/blog/exchange/upcoming-retirement-of-owa-light-in-exchange-server/4534943
Im Rest der Mitteilung geht es um ein die OWA Light Oberfläche, und ehrlicherweise muss ich gestehen, dass ich diese seit mindestens 10 Jahren nicht mehr im Einsatz gesehen habe und daher bereits im großen und ganzen vergessen war.
Ich finde es gut, dass Microsoft diese “Altlasten” konsequent aus den Systemen ausbaut.