Microsoft Exchange Server

Was ist Microsoft Exchange Server?

Das Kollaborationsprodukt Microsoft Exchange Server ist die E-Mail-, Kalender-, Kontakt-, Terminplanungs- und Kooperationsplattform von Microsoft und steht auf Windows-Server-Betriebssystem (OS) für die geschäftliche Nutzung bereit. Der Zugriff ist von mobilen Geräten, Desktops und webbasierten Systemen aus auf die Messaging-Plattformen möglich und auch Sprachnachrichten werden unterstützt.

Exchange-Benutzer arbeiten durch die gemeinsame Nutzung von Kalendern und Dokumenten zusammen. Mit den Storage- und Sicherheitsfunktionen der Plattform können Unternehmen Inhalte archivieren, Suchen durchführen und Compliance-Aufgaben erfüllen. Exchange Server hat sich im Laufe der Zeit weiterentwickelt und ist nun eine grundlegende Komponente von Microsoft 365 als Software-as-a-Service-Angebot (SaaS) in der Microsoft-Cloud, wobei Microsoft als Dienstanbieter fungiert.

Was ist die Aufgabe von Exchange Server?

Exchange Server ist ein Kollaborationsprodukt der Unternehmensklasse, das sich auf das Senden, Empfangen und Speichern von E-Mail-Nachrichten konzentriert. Neben der Verwaltung des Nachrichtenverkehrs bietet Exchange Server verschiedene andere Funktionen für die Zusammenarbeit, zum Beispiel Kalenderfunktionen und eine enge Integration mit anderen Microsoft-Office-Anwendungen.

Exchange Server ist bekannt für seine High-Availability-Funktionen (HA). Sie gewährleisten die Aufrechterhaltung des Dienstes in verschiedenen Ausfallszenarien, einschließlich des Ausfalls eines einzelnen Servers und des Ausfalls des Rechenzentrums.

Wie funktioniert Exchange Server?

Exchange Server stützt sich auf einen zentralen Server, der die Konten der Benutzer konfiguriert. Unternehmen haben die Wahl, ihren eigenen Exchange-Server zu verwalten oder ihn von Microsoft über ein Cloud-basiertes Microsoft-365-Konto verwalten zu lassen.

Exchange Server nutzt Exchange ActiveSync für die Synchronisierung von E-Mails, Kalendern und anderen Outlook-Daten zwischen Endbenutzer-Clients und dem zentralen Server, eine de wichtigsten Funktionen. Unternehmen können ihre E-Mails jedoch auch über das Internet Message Access Protocol (IMAP) verwalten, das wie ActiveSync E-Mails zwischen Clients und Server synchronisiert, oder über das Post Office Protocol 3, das E-Mails vom Server herunterlädt, ohne die Synchronisierung zwischen Geräten aufrechtzuerhalten.

Ist Microsoft Exchange dasselbe wie Outlook?

Exchange-Benutzer greifen über einen E-Mail-Client auf Nachrichten zu und interagieren mit ihnen. Microsoft Outlook ist der am häufigsten verwendete Client. Exchange Server 2019 unterstützt auch Folgendes:

• Outlook 2024
• Outlook 2019
• Outlook 2016
• Outlook 2013
• Outlook 2010 Service Pack 2
• Outlook für Mac für Office 365
• Outlook für Mac 2011

Outlook ist auch als webbasierte Anwendung verfügbar, genannt Outlook im Web. Es ermöglicht Benutzern den Zugriff auf und die Interaktion mit Nachrichten von verschiedenen Webbrowsern von Dokumenten, die in OneDrive for Business auf einem lokalen SharePoint-Server gespeichert sind. Das schafft eine einfachere und direktere Möglichkeit für Endbenutzer, Dateien zu speichern und an E-Mails anzuhängen.

Wo findet man Microsoft-Exchange-Details in Outlook?

Benutzer können ihre Kontoeinstellungen in Outlook überprüfen, um festzustellen, ob ihr Konto mit Microsoft Exchange verbunden ist. Zunächst sollten die Benutzer im Menü Datei die Option Kontoeinstellungen wählen. Nach der Auswahl werden in einer Übersicht die konfigurierten und die mit Exchange verbundenen Outlook-Konten angezeigt.

Neben der desktopbasierten Anwendung verwenden einige Unternehmen auch Outlook im Web. Es bietet ein ähnliches Erlebnis wie die Outlook-Desktop-Anwendung und ermöglicht es den Lesern, E-Mails zu schreiben, ihren Kalender und andere Aufgaben über ihren Browser zu verwalten und Exchange-Details im gleichen Dropdown-Menü Kontoseinstellungen anzuzeigen.

Funktionen von Exchange Server 2019

Die Version 2019 bietet ein deutlich schnelleres und zuverlässigeres Failover zwischen Servern. Sie wurde entwickelt, um die Gesamtleistung zu verbessern und die Vorteile der neuesten Storage-Hardware zu nutzen, einschließlich größerer Festplatten und Solid-State-Laufwerke.

Zu den weiteren neuen Funktionen in Exchange Server 2019 gehören die folgenden:

• bietet Unterstützung für bis zu 256 GByte Memory und 48 Central Processing Unit Cores
• ermöglicht Installationen auf Windows Server Core
• ermöglicht es, den externen Zugriff auf das Exchange Admin Center und die Exchange Management Shell nativ zu blockieren
• dynamische Memory-Cache-Zuweisung zur Optimierung der Memory-Nutzung für aktive Datenbanken
• ermöglicht es, Teilnehmer an der Weiterleitung von Besprechungseinladungen zu hindern
• bietet Endbenutzern zusätzliche Optionen für die Abwesenheit vom Arbeitsplatz
• ermöglicht es Administratoren, Meetings zu stornieren, die von einem Benutzer organisiert wurden, der das Unternehmen verlassen hat.
• ermöglicht Administratoren die Zuweisung von Delegationsberechtigungen
• ermöglicht es, E-Mail-Adressen, die nicht-englische Zeichen enthalten, nativ weiterzuleiten und zuzustellen

Zusammen mit diesen zusätzlichen Funktionen in Exchange Server 2019 wurden Unified Messaging und alle damit verbundenen Funktionen aus Exchange Server 2019 entfernt.

Am 14. Oktober 2025 ist das End of Life (EOL) von Microsoft Exchange Server 2019 und Exchange Server 2016. Mit einer neuen Edition von Exchange Server Subscription Edition ist wohl im dritten Quartal von 2025 zu rechnen. Auch ein Wechsel zu Microsoft Exchange Online als Teil von Microsoft 365 ist möglich.

Anforderungen für Exchange Server 2019

Die folgenden Anforderungen müssen erfüllt sein, um Exchange Server 2019 zu installieren:

• Exchange Server 2019 kann im Active Directory Forest – der höchsten Ebene der AD-Organisation – mit vorhandenen Exchange 2016- und 2013-Servern installiert werden. Es können keine früheren Versionen des Exchange-E-Mail-Servers in demselben AD Forest wie Exchange 2019 installiert werden.
• Alle Domänencontroller in einem AD Forest müssen Windows Server 2022 Standort oder Datacenter, Windows Server 2019 Standard oder Datacenter, Windows Server 2016 Standard oder Datacenter oder Windows Server 2012 R2 Standard oder Datacenter ausführen.
• Die Funktionsstufe des AD Forests muss Windows Server 2012 R2 oder höher sein.
• Der Server, der Exchange Server 2019 hostet, muss einen 64-Bit-Prozessor verwenden.
• Der Server sollte zwischen 128 GByte und 256 GByte RAM haben.
• Das New Technology File System ist auf allen Festplattenpartitionen erforderlich, die die Systempartition, Exchange-Binärdateien, Diagnoseprotokolle und Transportdatenbankdateien enthalten. Resilient File System kann auf Partitionen verwendet werden, die Mailbox-Datenbanken und Transaktionsprotokolle enthalten.

Exchange Preferred Architecture

Die Exchange Preferred Architecture (PA) ist die ideale Exchange-Bereitstellung, wie sie vom Exchange-Team bei Microsoft angestrebt wird. PA wurde mit Blick auf die Gesamtbetriebskosten, HA, Ausfallsicherheit, Redundanz und Wiederherstellung entwickelt- Sie ist nicht als Reifegradmodell gedacht, sondern soll vielmehr als Inspiration dienen.

Hochverfügbarkeit von Exchange Server

Exchange Server verfügt über mehrere wichtige Funktionen zur Aufrechterhaltung von Ausfallsicherheit und Hochverfügbarkeit. Die Komponenten des Exchange-Postfachservers stützen sich auf Datenbankverfügbarkeitsgruppen (Database Availability Groups, DAGs). Die Komponenten des Client-Zugriffsservers stützen sich auf den Lastausgleich.

Datenbankverfügbarkeitsgruppen

Die DAG ist das grundlegende Exchange-Subsystem zur Gewährleistung von HA. Die DAG wurde erstmals in Exchange 2010 eingeführt und entwickelte sich schnell zu einem der wichtigsten Subsysteme innerhalb von Exchange.

Die DAG ist eine Gruppe von bis zu 16 Exchange-Servern, die automatisch Datenbanken zwischen den Mitgliedern kopiert, um im Falle eines Ausfalls auf Datenbank- oder Serverebene Redundanz zu gewährleisten. Jeder Server in einer DAG kann eine Kopie einer Datenbank von einem beliebigen anderen Server in der DAG hosten. Sobald eine Kopie einer Datenbank zu einem anderen Server hinzugefügt wird, wird diese Kopie automatisch auf dem neuesten Stand gehalten und kann jederzeit aktiviert werden.

Die DAG basiert auf Windows Clustering und nicht auf einer Technologie, die für das Exchange Team selbst spezifisch ist. Das kann bedeuten, dass Funktionen und Fehler in Windows Server manchmal einen erheblichen Einfluss auf die Funktionsweise von Exchange haben können.

Active Manager

Active Manager (AM) ist die Exchange-Komponente, die für die Verwaltung von Failover-Ereignissen in einer Exchange-Umgebung verantwortlich ist. AM wird im Microsoft Exchange Replication Service auf allen Exchange-2016-Servern ausgeführt. Wenn ein Exchange-Server mit einer DAG verbunden wird, werden zwei AM-Rollen auf diesem Server ausgeführt: Primary AM (PAM) und Standby AM (SAM).

Der DAG-Mitgliedsserver, der die Cluster-Quorum-Ressource besitzt, hat die PAM-Rolle inne. Wenn der DAG-Knoten, der die Quorum-Ressource besitzt, ausfällt, wechselt die PAM-Rolle zu dem Server, der die Quorum-Ressource übernimmt.

SAM ist dafür verantwortlich, den anderen Exchange-Komponenten, auf denen AM-Clients ausgeführt werden, Informationen darüber bereitzustellen, welche Datenbankkopie gerade aktiv ist. SAM erkennt, wenn eine Datenbank ausfällt, und fordert PAM auf, das Failover-Ereignis zu initiieren. SAM ist nicht für die Auswahl der Datenbankkopie verantwortlich, die nach einem Ausfall aktiviert wird. Dieser Vorgang wird als Best Copy and Server Selection (BCSS) bezeichnet.

Auswahl der besten Kopie (Best Copy Selection)

Wenn ein Datenbankausfall festgestellt wird, unternimmt AM Schritte, um den Ausfall zu beheben, indem es die beste Kopie der betroffenen Datenbank zur Aktivierung auswählt. Der BCSS-Prozess läuft folgendermaßen ab:

1. Ein Ausfall wird von AM oder Managed Availability erkannt. Dieser Prozess kann auch von einem Administrator gestartet werden, der eine ziellose Umschaltung einleitet.

2. PAM startet den internen BCSS-Algorithmus.

3. Der Unterprozess attempt copy last logs (ACLL) versucht, alle fehlenden Protokolldateien von dem Server zu kopieren, auf dem sich zuletzt die aktive Kopie der Datenbank befand.

4. Nach dem Abschluss des ACLL-Prozesses wird ein AutoDatabaseMountDial-Wert für Server, die Kopien der Datenbank zu beherbergen, überprüft und mit der Länge der Kopierwarteschlange der zu aktivierenden Datenbank verglichen. Wenn die Anzahl der fehlenden Protokolldateien kleiner oder gleich dem Wert von AutoDatabaseMountDial ist, fährt AM mit Schritt fünf fort. Ist das nicht der Fall, beginnt AM den Vorgang wieder bei Schritt zwei.

5. PAM sendet eine Mount-Anforderung an den Informationsspeicher. Wenn die Datenbank nicht gemountet werden kann, kehrt AM zu Schritt zwei zurück.

Es gibt eine zusätzliche Logik in diesem Prozess, wenn das Failover-Ereignis durch ein Protokollüberwachungsereignis ausgelöst wird. Die zusätzliche Logik stellt sicher, dass der Server, der die aktive Datenbank übernimmt, in einem besseren Zustand ist als der Server, von dem er kam.

DAG-Quorum-Modi

Ein DAT ist eine spezielle Implementierung eines Windows Server Failover Clusters (WSFC). Die Exchange-Komponenten von DAGs sind auf die zugrunde liegende WSFC-Technologie angewiesen, um zu funktionieren. Das Konzept des Quorums ist für das Verständnis der Implementierung und Verwaltung von DAGs unerlässlich.

Quorum bedeutet, dass es für den Fall, dass einige DAG-Mitglieder ausfallen, Regeln gibt, die festlegen, welche Ressourcen die verbleibenden Mitglieder bereitstellen können. Diese Quorum-Regelsätze sorgen für einen konsistenten Betrieb einer DAG und dienen als Entscheidungshilfe in Situationen, in denen DAG-Knoten die Kommunikation untereinander verlieren.

Wenn eine DAG eine gerade Anzahl von Knoten hat, wird der Quorum-Modus Node & File Share Majority verwendet. In diesem Modus fungiert ein externer Zeugenserver als Tiebreaker. Jedes DAG-Knotenmitglied erhält eine einzelne Stimme, aber der Zeugenserver gibt einem der DAG-Knoten eine zusätzliche Stimme. Die Quorum-Daten des Clusters werden auf der lokalen Systemfestplatte jedes Mitglieds gespeichert, aber der Zeugenserver verfügt über eine separate Datei, die auf ein DAG-Mitglied als die aktuellste Kopie der Quorum-Daten des DAG-Clusters verweist.

Hat eine DAG aber eine ungerade Anzahl von Mitgliedern hat, verwendet sie den Quorum-Modus Node Majority. In diesem Modus erhält jedes DAG-Mitglied eine Stimme, und die lokale Systemfestplatte jedes Mitglieds wird zum Speichern der Cluster-Quorum-Daten verwendet.

Es ist möglich, bestimmten DAG-Mitgliedern manuell gewichtete Quorum-Stimmen zuzuweisen. Das ist in den meisten Fällen nicht empfehlenswert und sollte nur nach direkter Rücksprache mit dem Microsoft-Support erfolgen.

Datacenter Activation Coordination Mode

Der Modus Datacenter Activation Coordination (DAC) ist eine Funktion von DAGs, die verhindern soll, dass ein Ausfall dazu führt, dass zwei Kopien einer Datenbank auf zwei verschiedenen Servern aktiv sind. Der DAC-Modus erfordert ein manuelles Eingreifen, wenn der Server, der die Datenbank hostet, die Mehrheit der DAG-Mitgliedsserver nicht erreichen kann.

Die Best Practices von Microsoft sehen vor, dass der DAC-Modus für jede DAG mit zwei oder mehr Mitgliedern und kontinuierlicher Replikation aktiviert wird. Die einzigen Fälle, in denen der DAC-Modus für eine DAG nicht empfohlen wird, wären, wenn der Administrator ein Replikations-Tool eines Drittanbieters verwendet.

Wenn ein DAC aktiv ist, findet beim Starten eine zusätzliche Kommunikation zwischen den DAG-Knoten statt, die das DAC Protocol (DACP) verwenden. DACP wird beim Starten auf 0 gesetzt. Wenn das DACP-Bit auf 0 bleibt, versucht AM nicht, irgendwelche Datenbanken auf diesem Knoten zu starten. Das DACP-Bit kann auch auf 1 gesetzt werden, wenn das DACP-Bit eines anderen DAG-Mitglieds auf 1 gesetzt ist oder wenn ein DAG-Knoten alle Server in seiner DAG-Mitgliederliste kontaktieren kann.

Der DAC-Modus ist nützlich, wenn ein primäres Rechenzentrum vollständig ausfällt und ein Backup-Rechenzentrum aktiviert wird. Wenn die Stromversorgung wiederhergestellt ist und die Server hochgefahren werden, bevor die Wide-Area-Network-Verbindung wieder online ist, verhindert der DAC-Modus, dass unterschiedliche Kopien derselben Datenbanken in beiden Rechenzentren aktiv werden.

Bei einer DAG mit zwei Knoten vergleicht der DAC-Modus die Startzeit des alternativen Zeugenservers mit der Zeit, zu der das DACP-Bit auf 1 gesetzt wurde, um festzustellen, ob er Datenbanken einhängen kann. Wenn das DACP-Bit früher als die Boot-Zeit des alternativen Zeugenservers auf 1 gesetzt wurde, geht das System davon aus, dass die beiden Server zur gleichen Zeit neu gestartet wurden – möglicherweise aufgrund eines Stromausfalls im primären Rechenzentrum – und das DAG-Mitglied darf keine Datenbanken bereitstellen. Wenn das DACP-Bit nach dem Startzeitpunkt des alternativen Zeugenservers auf 1 gesetzt wurde, geht das System davon aus, dass es sicher ist, Datenbanken bereitzustellen.

DatabaseAvailabilityGroup-Cmdlets und Split-Brain-Bedingungen

Split Brain ist eine Situation, in der zwei verschiedene Kopien derselben Datenbank gleichzeitig in verschiedenen Rechenzentren aktiv werden. In diesem Fall laufen die beiden unterschiedlichen Kopien der Datenbank auseinander, was zum Verlust von Benutzerdaten führen kann, wenn die beiden unterschiedlichen Kopien versuchen, sich abzugleichen.

Der DAC-Modus verhindert nicht nur Split-Brain-Bedingungen, sondern ermöglicht auch das Starten, Stoppen und Wiederherstellen von DatabaseAvailabilityGroup-Cmdlets. Diese Cmdlets werden verwendet, um manuelle Umschaltungen des Rechenzentrums durchzuführen. Wenn der DAC-Modus nicht aktiv ist, ist der Prozess eines manuellen Rechenzentrums komplex und umfasst sowohl Exchange-Tools als auch einen Cluster-Manager.

Stellen Sie sich eine Situation vor, in der eine Exchange-Umgebung aus vier Servern besteht, von denen jeder eine Kopie der gleichen Datenbank besitzt. Zwei dieser Server befinden sich in Rechenzentrum A und zwei in Rechenzentrum B. In der Verbindung zwischen den beiden Rechenzentren kommt es zu einem Netzwerkausfall. Ohne den DAC-Modus wäre es möglich, dass die Server in jedem Rechenzentrum denken, sie müssten eine Kopie der Datenbank aktivieren.

Der DAC-Modus verhindert dieses Split-Brain-Szenario, indem er eine Knotenmehrheit verlangt, bevor eine Datenbank aktiviert werden kann. Knotenmehrheit bedeutet, dass die meisten Knoten des Clusters – oder in diesem Fall der DAG – online und erreichbar sein müssen, damit ein DAG-Knoten eine Datenbankkopie aktivieren kann. Bei einer geraden Anzahl von Knoten in der DAG fungiert der Dateifreigabe-Witness auch als stimmberechtigtes Mitglied, um die Knotenmehrheit zu bestimmen.

In dem oben beschriebenen Fall mit einem Vier-Knoten-Cluster und zwei Knoten in jedem Rechenzentrum könnten nur die Exchange-Server in dem Rechenzentrum mit dem Dateifreigabe-Witness Datenbank aktivieren. Die DAG-Knoten im anderen Rechenzentrum würden daran gehindert, Datenbanken zu aktivieren, bis sie in der Lage sind, alle als Mitglieder der DAG aufgeführten Server zu kontaktieren.

Third Site Witness

Eine Funktion, die Exchange in der 2013-Version hinzugefügt wurde, war die Unterstützung für einen Third Site Witness, der die Möglichkeit hat, alle Ressourcen ohne Eingreifen des Administrators online zu bringen. Wenn jeder Standort über einen unabhängigen Netzwerkpfad zum Third Site Witness verfügt, können die Knoten an einem Standort das Quorum mithilfe des Witness-Servers aufrechterhalten. Der Nachteil bei der Verwendung eines Third Site Witness ist, dass Exchange-Administratoren sich Zeit nehmen müssen, um ihr Netzwerkverhalten genau zu verstehen.

Load Balancing

Das Load Balancing ist eine Möglichkeit für Administratoren, den Netzwerkverkehr zu verwalten, der an die einzelnen Exchange-Server innerhalb eines Netzwerks geleitet wird. Normalerweise ist es aus zwei Gründen wünschenswert, die Verteilung eingehender Client-Verbindungen auf Exchange Server 2016 zu verwalten:

1. Verteilung der Arbeitslast: Wenn sich jemand die Mühe macht, mehrere Exchange-Server einzurichten und zu warten, ist es eine gute Idee, alle diese Exchange-Server regelmäßig etwas arbeiten zu lassen.

2. Verringerung der Ausfallauswirkungen: Wenn etwas schief geht, ist es gut, ein redundantes System zu haben, das die Arbeitslast des ausgefallenen Systems übernimmt.

Load Balancing ist eine Ergänzung zu DAGs. Die Aufgabe einer DAG besteht darin, dafür zu sorgen, dass mehrere Kopien jede Postfachs zur Aktivierung bereitstehen und Client-Anfragen angenommen werden, falls die aktive Kopie nicht mehr verfügbar ist. Load Balancing funktioniert ähnlich: Es soll sicherstellen, dass es andere Orte gibt, an die der Client-Datenverkehr gesendet werden kann, falls ein Ort nicht mehr verfügbar ist.

Load Balancing kann zwischen zwei oder mehreren Exchange-Servern an einem einzigen Standort oder über mehrere Standorte hinweg erfolgen. Eine Exchange-Bereitstellung nach der bevorzugten Architektur (Preferred Architecture, PA) würde vier Exchange-Server umfassen, die auf zwei separate AD-Standorte verteilt sind. Die aktuellen Versionen von Exchange unterstützen Load Balancing auf Layer 4, Layer 7 und im Domänennamensystem (Round Robin).

Microsoft Exchange Online

Microsoft bietet Exchange als SaaS-Angebot namens Exchange Online an. Es ist als eigenständiger Dienst und als Teil der Microsoft-365-Suite verfügbar. Endbenutzer stellen über den Outlook-Client oder Outlook im Web eine Verbindung zu Exchange Online her. Administratoren mit Microsoft-365-Verwaltungsberechtigungen konfigurieren und verwalten den Dienst. Microsoft bietet Exchange als gehosteten Dienst an, um den mit der Bereitstellung von Exchange-Servern vor Ort verbundenen Verwaltungsaufwand zu verringern.

Exchange On-Premises, Exchange Online und Gmail im Vergleich

Unternehmen, die sich für eine Messaging-Anwendung entscheiden müssen, stehen meist vor der Wahl zwischen Exchange und Google Mail und, wenn sie sich für Exchange entscheiden, zwischen Exchange vor Ort und Exchange Online. Die folgenden Tabellen geben einen Überblick über die Vor- und Nachteile aller drei Varianten.

Preise und Lizenzierung von Exchange Server

Die Preise für Exchange Server können variieren, je nachdem, wie die Software erworben wird und welche Version von Exchange gekauft wird.

Exchange On-Premises wird auf Serverbasis verkauft. Außerdem ist für jeden Benutzer, der auf Exchange zugreift, eine Windows Server Client Access License (CAL) erforderlich. Exchange Server muss auf einem Server installiert werden, auf dem das Windows-Server-Betriebssystem läuft, das ebenfalls mit einem Pro-Server mit CAL-Modell lizenziert werden muss. Der Server muss in einer AD-Gesamtstruktur mit mindestens einem Domänencontroller installiert sein.

Exchange Server verfügt über zwei Lizenzierungspläne für seinen Server: Standard und Enterprise. Der Standard-Plan umfasst Messaging und Kalender, während der Enterprise-Plan zusätzliche Funktionen wie integrierte Archivierung, Data Loss Prevention (DLP) und höhere Speichergrenzen für Nachrichten bietet.

Exchange-CALs gibt es ebenfalls in Standard und Enterprise. Jeder Nutzer muss über eine Windows Server Standard CAL verfügen und kann eine Enterprise CAL für zusätzliche Funktionen haben. Sowohl die Standard- als auch die Enterprise-CALs können mit beiden Server-Editionen verwendet werden.

Exchange Online wird auf einer monatlichen Basis pro Benutzer entweder als eigenständiges Angebot oder als Teil eines Microsoft-365-Pläne. Es gibt zwei eigenständige Pläne. Exchange Online Plan 1 bietet einen sicheren und verfügbaren geschäftlichen E-Mail-Dienst mit einem 50-GByte-Postfach pro Benutzer. Exchange Online Plan 2 baut auf Plan 1 auf und bietet eine gehostete Voicemail und DLP-Funktionen. Ein Plan für Microsoft 365 Business Standard ist ebenfalls verfügbar. Er umfasst eine Desktop-Suite von Microsoft-365-Anwendungen, ein 50-GByte-Postfach und maximal 300 Benutzer.

Die Geschichte von Exchange Server

Exchange Server wurde erstmals 1993 veröffentlicht. Zu den wichtigsten Ereignissen in seinem Lebenszyklus gehören die folgenden:

• 1993: Exchange Server wird in einer privaten Vorschau veröffentlicht.
• 1996: Die erste öffentlich verfügbare Version, Exchange 4.0, wird veröffentlicht.
• 1997: Exchange 5.0 wird veröffentlicht, mit Simple Mail Transfer Protocol und der Einführung von Office Web Access.
• 1998: Exchange 5.5 wird mit Standard- und Enterprise-Editionen, Wiederherstellung gelöschter Elemente und Unterstützung für IMAP4- und Lightweight Directory Access Protocol v3-Clients veröffentlicht.
• 2000: Exchange Server 2000 wird mit Instant Messaging und Integration mit AD veröffentlicht.
• 2003: Exchange Server 2003 wird mit Frontend-Server-Unterstützung und verbesserten Migrationsfunktionen veröffentlicht.
• 2007: Exchange Server 2007 wird mit PowerShell-Integration, separaten Exchange-Server-Rollen, Unified Messaging und mehreren Datenbank-HA-Optionen veröffentlicht.
• 2009: Exchange Server 2010 war eine kleinere Version, die die Einführung von DAGs und verbesserte Load-Balancing-Optionen beinhaltete. Office 365 wurde ebenfalls im Jahr 2010 angekündigt.
• 2012: Exchange Server 2013 wurde mit einer engeren Integration zwischen den Office-Dienstprodukten, der Einführung von Standortpostfächern und modernen öffentlichen Ordnern veröffentlicht.
• 2015: Exchange Server 2016 wurde veröffentlicht. Die Möglichkeit, separate Exchange-Server-Rollen zu installieren, wurde mit Ausnahme der Edge-Transport-Rolle entfernt.
• 2018: Exchange Server 2019 wird veröffentlicht, ermöglicht die Installation auf Windows Server Core und entfernt die Unified-Messaging-Funktionen.

Bekannte Exchange-Server-Hacks und -Verletzungen

Exchange wurde im Laufe der Jahre Opfer mehrerer regionaler und globaler Cybersicherheitsangriffe. Im Juli 2023 griff eine Gruppe chinesischer Hacker, bekannt als Volt Typhoon, kritische US-Infrastrukturen an und war in der Lage, US-Regierungsbehörden auszuspionieren.

Im Jahr 2021 kam es zu einem globalen Angriff durch Hafnium, eine Cyberspionage-Gruppe mit angeblichen Verbindungen zu China. Hafnium gelang es, sich Zugang zu E-Mail-Konten zu verschaffen, Benutzerdaten zu stehlen und Geräte mit Malware zu infizieren. Der Angriff betraf Zehntausende von Unternehmen auf der ganzen Welt und veranlasste Microsoft, Notfall-Patches zur Behebung von Sicherheitslücken zu veröffentlichen. Ebenfalls in diesem Jahr wurde eine Reihe von Schwachstellen entdeckt, die als ProxyLogon bekannt sind und es Hackern ermöglichen könnten, auf Daten auf lokalen Exchange-Servern zuzugreifen  (siehe auch BSI: Zehntausende Server von Exchange-Lücken betroffen).

Im Jahr 2020 nahm die Cyberspionage-Gruppe APT29, die auch als Cozy Bear bekannt ist und bei der es vermutlich um eine Gruppe russischer Hacker handelt, Organisationen ins Visier, die an der COVID-19-Impfstoffforschung beteiligt waren. Obwohl Exchange nur eine der ausgenutzten Anwendungen war, konnte die Gruppe die Schwachstellen ausnutzen, um sich unbefugten Zugang zu sensiblen Informationen über die Impfstoffentwicklung und Forschungsdaten zu verschaffen. APT29 wurde auch mit früheren Angriffen in den USA in Verbindung gebracht.

Versionsgeschichte von Exchange Server

Die folgende Liste zeigt die Versionsentwicklung von Exchange Server mit dem entsprechenden Veröffentlichungsdatum und Software-Build:

• Exchange Server 4.0 Standard Edition wurde erstmals am 11. Juni 1996 als Build 4.0.837 veröffentlicht.
• Exchange Server 5.0 wurde erstmals am 23. Mai 1997 als Build 5.0.1457 veröffentlicht.
• Exchange Server 5.5 wurde erstmals am 3. Februar 1998 als Build 5.5.1960 veröffentlicht.
• Exchange Server 2000 wurde erstmals am 29. November 2000 als Build 6.0.4417 veröffentlicht.
• Exchange Server 2003 wurde erstmals am 28. September 2003 als Build 6.5.6944 veröffentlicht.
• Exchange Server 2007 wurde erstmals am 8. März 2007 als Build 8.0.685.25 veröffentlicht.
• Exchange Server 2010 wurde erstmals am 9. November 2009 als Build 14.0.639.21 veröffentlicht.
• Exchange Server 2013 wurde erstmals am 3. Dezember 2012 als Build 15.0.516.32 veröffentlicht.
• Exchange Server 2016 wurde erstmals am 1. Oktober 2015 als Build 15.1.225.42 veröffentlicht.
• Exchange Server 2019 wurde erstmals am 22. Oktober 2018 als Build 15.2.221.12 veröffentlicht.