Definition

Microsoft Exchange Server

Microsoft Exchange Server ist eine E-Mail-, Kalender-, Kontakt-, Terminplanungs- und Kollaborationsplattform von Microsoft. Die Anwendung wird auf dem Betriebssystem Windows Server installiert. Microsoft hat Exchange Server so konzipiert, dass Benutzer von Mobilgeräten, Desktops und Websystemen aus auf die Messaging-Plattform zugreifen können. Die Telefonfunktionen in Exchange Server unterstützen Sprachnachrichten.

Exchange-Benutzer können mit gemeinsamen Kalendern und Dokumenten zusammenarbeiten. Speicher- und Sicherheitsfunktionen in der Plattform ermöglichen es Unternehmen, Inhalte zu archivieren, zu suchen und Compliance-Vorgaben zu erfüllen. Exchange Server hat sich im Laufe der Zeit weiterentwickelt und ist heute eine grundlegende Komponente von Office 365 als Software as a Service (SaaS) in der Microsoft-Cloud, wobei das Softwareunternehmen als Serviceanbieter fungiert.

Wie funktioniert Exchange Server?

Exchange Server ist ein Enterprise-Collaboration-Produkt, das sich hauptsächlich 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 an, zum Beispiel Kalender und die enge Integration mit anderen Microsoft Office-Anwendungen.

Das zentrale Merkmal von Exchange Server ist Hochverfügbarkeit (High Availability, HA), die einen kontinuierlichen Dienst in verschiedenen Ausfallszenarien gewährleistet. Dazu gehören entsprechende Architekturpfade, welche die Funktion des Dienstes bei Serverausfällen oder Ausfällen des Rechenzentrums gewährleisten.

Merkmale von Exchange Server 2019

Die Version 2019 bietet eine wesentlich schnellere und zuverlässigere Ausfallsicherung zwischen Servern. Sie wurde entwickelt, um die Gesamtleistung zu verbessern und die Vorteile der neuesten Speicherhardware, einschließlich größerer Festplatten und Solid-State Drives (SSDs), auszunutzen.

Zu den neuen Features von Exchange Server 2019 gehören unter anderem:

  • bietet Unterstützung für bis zu 256 GB Arbeitsspeicher und 48 CPU-Kerne;
  • ermöglicht Installationen auf Windows Server Core;
  • ermöglicht es, den externen Zugriff auf das Exchange Admin Center (EAC) und die Exchange Management Shell nativ zu blockieren;
  • verwendet dynamische Cache-Zuweisung zur Optimierung der Speichernutzung für aktive Datenbanken;
  • verhindert, dass Teilnehmer Besprechungseinladungen weiterleiten;
  • bietet Endanwendern zusätzliche Abwesenheitsoptionen;
  • ermöglicht es Administratoren, Besprechungen abzusagen, die von einem Benutzer organisiert wurden, der das Unternehmen verlassen hat; und
  • ermöglicht es Administratoren, Berechtigungen zu delegieren.

Zusammen mit diesen zusätzlichen Funktionen in Exchange 2019 wurden die Unified-Messaging-Rolle (UM) und alle damit verbundenen Funktionen aus Exchange 2019 entfernt. In einem Blogbeitrag vom 16. September 2019 auf der Exchange-Website hieß es, Microsoft werde die erweiterte Unterstützung von Exchange Server 2010 vom 14. Januar 2020 bis zum 13. Oktober 2020 gewährleisten, um Kunden von Exchange Server 2010 mehr Zeit für eine Migration zu geben. Administratoren, die Exchange Server 2010 Workloads auf Windows Server 2008 ausführen, müssen allerdings Anpassungen vornehmen, da der Support am 14. Januar 2020 für dieses Betriebssystem eingestellt wurde.

Anforderungen für Exchange Server 2019

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

  • Exchange 2019 kann in Active Directory (AD) Gesamtstrukturen mit vorhandenen Exchange 2016- und/oder 2013-Servern installiert werden. Es dürfen keine früheren Versionen von Exchange in der gleichen Gesamtstruktur wie Exchange 2019 installiert werden.
  • Auf allen Domänencontrollern (DCs) in der AD-Gesamtstruktur muss Windows Server 2019 Standard oder Datacenter, Windows Server 2016 Standard oder Datacenter oder Windows Server 2012 R2 Standard oder Datacenter ausgeführt werden.
  • Die Funktionsebene der AD-Gesamtstruktur muss Windows Server 2012 R2 oder höher sein.
  • Der Server, auf dem Exchange 2019 gehostet wird, muss einen 64-Bit-Prozessor verwenden.
  • Der Server, der Exchange 2019 hostet, sollte zwischen 128 und 256 Gigabyte (GB) Arbeitsspeicher (RAM) haben.
  • Das New Technology File System (NTFS) ist auf allen Festplattenpartitionen erforderlich, die die Systempartition, Exchange-Binärdateien, Diagnoseprotokolle und die Transportdatenbank enthalten. Das Resilient File System (ReFS) kann auf Partitionen verwendet werden, die Mailbox-Datenbanken und Transaktionsprotokolle enthalten.

Hochverfügbarkeit von Exchange Server

Exchange Server verfügt über mehrere wichtige Funktionen zur Aufrechterhaltung von Ausfallsicherheit und Hochverfügbarkeit (High Availability, HA). Die Postfachserverkomponenten von Exchange beruhen auf Datenbankverfügbarkeitsgruppen (DAGs). Clientzugriffsserver-Komponenten sind auf Lastausgleich angewiesen.

Datenbankverfügbarkeitsgruppen

Datenbankverfügbarkeitsgruppen (Database Availability Group, DAG) sind das grundlegende Exchange-Subsystem zur Sicherstellung der Hochverfügbarkeit. Datenbankverfügbarkeitsgruppen wurde erstmals in Exchange Server 2010 eingeführt und entwickelten sich schnell zu einem der wichtigsten Subsysteme innerhalb von Exchange.

Eine Datenbankverfügbarkeitsgruppe ist eine Gruppe von bis zu 16 Exchange-Servern, die Datenbanken automatisch zwischen den Mitgliedern kopiert, um im Falle eines Ausfalls auf Datenbank- oder Serverebene Redundanz zu gewährleisten. Jeder Mitgliedsserver einer DAG kann eine Kopie einer Datenbank von jedem anderen Mitgliedsserver 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. Dies bedeutet, dass Funktionen und Fehler in Windows Server einen 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 innerhalb einer Exchange-Umgebung verantwortlich ist. AM läuft im Microsoft Exchange Replikationsdienst auf allen Exchange-2016-Servern. Wenn ein Exchange-Server mit einem DAG verbunden wird, werden zwei AM-Rollen auf diesem Server ausgeführt: Primary Active Manager (PAM) und Standby Active Manager (SAM).

Der DAG-Mitgliedsserver, der die Cluster-Quorum-Ressource hat, wird die PAM-Rolle innehaben. Wenn der DAG-Knoten, der die Quorum-Ressource hält, ausfällt, wird die PAM-Rolle auf den Server verlegt, der die Quorum-Ressource in Besitz nimmt.

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

Best Copy Selection

Wenn ein Datenbankfehler entdeckt wird, unternimmt der Active Manager Schritte, um den Fehler zu beheben, indem es die beste Kopie der betroffenen Datenbank zur Aktivierung auswählt. Der BCSS-Prozess läuft wie folgt ab:

  1. Ein Ausfall wird von Active Manager oder von Managed Availability erkannt. Dieser Prozess kann auch von einem Administrator gestartet werden, der eine ziellose Umschaltung einleitet.
  2. Der Primary Active Manager startet den internen BCSS-Algorithmus.
  3. Der Unterprozess attempt copy last logs (ACLL) versucht, alle fehlenden Protokolldateien von dem Server zu kopieren, auf dem zuletzt die aktive Kopie der Datenbank gehostet wurde.
  4. Wenn der ACLL-Prozess abgeschlossen ist, wird ein AutoDatabaseMountDial-Wert für Server, auf denen Kopien der Datenbank gehostet werden, ü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, geht AM zu Schritt fünf über. Wenn nicht, beginnt AM diesen Prozess erneut bei Schritt zwei.
  5. Der PAM gibt eine Mount-Anforderung an den Informationsspeicher aus. Wenn die Datenbank nicht gemountet wird, geht AM zu Schritt zwei zurück.

Es gibt eine zusätzliche Logik in diesem Prozess, wenn das Failover Event durch ein Monitoring Event 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 sie stammt.

DAG-Quorum-Modus

Eine Datenbankverfügbarkeitsgruppe ist eine spezifische Implementierung eines Windows Server Clusters. Die Exchange-Komponenten von DAGs sind auf die zugrunde liegende Windows Server Cluster-Technologie angewiesen, um zu funktionieren. Das Konzept des Quorums ist wesentlich für das Verständnis der Implementierung und Verwaltung von Datenbankverfügbarkeitsgruppen.

Quorum ist der Gedanke, dass es im Falle des Ausfalls einiger DAG-Mitglieder Regeln dafür gibt, welche Ressourcen die verbleibenden Mitglieder zur Verfügung stellen können. Diese Quorum-Regelsätze existieren, um einen konsistenten Betrieb einer Datenbankverfügbarkeitsgruppe zu gewährleisten und in Situationen, in denen DAG-Knoten die Kommunikation untereinander verlieren, als ein Tiebreaker zu fungieren.

Wenn eine DAG eine gerade Anzahl von Knoten hat, verwendet sie den Node & File Share Majority Quorum-Modus. In diesem Modus fungiert ein externer Zeugenserver als Tiebreaker. Wenn er in diesem Modus läuft, erhält jedes Mitglied eines DAG-Knotens eine einzige Stimme, aber der Zeugenserver gibt einem der DAG-Knoten eine zusätzliche Stimme. Die Cluster-Quorum-Daten werden auf der lokalen Systemfestplatte jedes Mitglieds gespeichert, aber der Zeugenserver hat eine separate Datei, die auf ein DAG-Mitglied als die aktuellste Kopie der DAG-Cluster-Quorum-Daten verweist.

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

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

Datacenter Activation Coordination Modus

Der DAC-Modus (Datacenter Activation Coordination) ist eine Funktion der Datenbankverfügbarkeitsgruppen, der Situationen verhindern soll, in denen 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, auf dem die Datenbank gehostet wird, eine Mehrheit der DAG-Mitgliedsserver nicht erreichen kann.

Die Best Practices von Microsoft sehen vor, dass der DAC-Modus bei jeder Datenbankverfügbarkeitsgruppe aktiviert werden muss, die zwei oder mehr Mitglieder hat und kontinuierliche Replikation verwendet. 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 der DAC-Modus aktiviert ist, findet beim Start eine zusätzliche Kommunikation zwischen DAG-Knoten statt, die das DAC-Protokoll (DACP) verwenden. DACP wird beim Start auf 0 gesetzt. Wenn das DACP-Bit auf 0 bleibt, versucht AM nicht, Datenbanken auf diesem Knoten zu starten. Das DACP-Bit kann auch auf 1 gesetzt werden, wenn ein anderes DAG-Mitglied sein DACP-Bit auf 1 gesetzt hat oder wenn ein DAG-Knoten alle Server auf 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 ist. Wenn die Stromversorgung wiederhergestellt ist und Server hochgefahren werden, bevor die WAN-Verbindung (Wide Area Network) wieder online ist, verhindert der DAC-Modus, dass unterschiedliche Kopien derselben Datenbanken in beiden Rechenzentren aktiv werden.

Bei einem DAG mit zwei Knoten verwendet der DAC-Modus einen Vergleich der Boot-Zeit des alternativen Zeugenservers und der Zeit, zu der das DACP-Bit auf 1 gesetzt wurde, um festzustellen, ob er Datenbanken mounten kann. Wenn das DACP-Bit vor der Boot-Zeit des alternativen Zeugenservers auf 1 gesetzt wurde, geht das System davon aus, dass die beiden Server gleichzeitig neu gestartet wurden – möglicherweise aufgrund eines Stromausfalls im primären Data Center – und das DAG-Mitglied keine Datenbanken mounten darf. Wenn das DACP-Bit nach der Boot-Zeit des alternativen Zeugenservers auf 1 gesetzt wurde, geht das System davon aus, dass es sicher ist, Datenbanken zu mounten.

DatabaseAvailabilityGroup-Cmdlets und Split-Brain-Bedingungen

Split Brain ist eine Situation, in der zwei verschiedene Kopien derselben Datenbank zur gleichen Zeit in verschiedenen Rechenzentren aktiv werden. Wenn dies geschieht, weichen die beiden unterschiedlichen Kopien der Datenbank voneinander ab, was zu einem potenziellen Verlust von Benutzerdaten führt, wenn die beiden unterschiedlichen Kopien versuchen, sich abzustimmen.

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

Hierfür sollte man sich eine Situation vorstellen, in der eine Exchange-Umgebung aus vier Servern besteht, von denen jeder eine Kopie derselben Datenbank besitzt. Zwei dieser Server befinden sich in Rechenzentrum A und zwei in Rechenzentrum B. In der Verbindung zwischen den beiden Rechenzentren tritt ein Netzwerkausfall ein. Ohne aktivierten DAC-Modus könnten die Server in jedem Data Center davon ausgehen, sie müssten eine Kopie der Datenbank aktivieren.

Der DAC-Modus verhindert dieses Split-Brain-Szenario, indem er eine Node Majority erfordert, bevor eine Datenbank aktiviert werden kann. Node Majority bedeutet, dass die meisten Knoten im Cluster – oder in diesem Fall DAG – online und erreichbar sein müssen, damit ein DAG-Knoten eine Datenbankkopie aktivieren kann. Wenn es eine gerade Anzahl von Knoten in der DAG gibt, dann wird der Zeuge der Dateifreigabe auch als stimmberechtigtes Mitglied arbeiten, um die Knotenmehrheit zu bestimmen.

In dem oben beschriebenen Fall mit einem Cluster mit vier Knoten und zwei Knoten in jedem Data Center wären nur die Exchange-Server im Rechenzentrum mit dem Dateifreigabe-Zeugen in der Lage, Datenbanken zu aktivieren. Die DAG-Knoten in dem anderen Rechenzentrum wären an der Aktivierung von Datenbanken solange gehindert, bis sie in der Lage sind, alle Server zu kontaktieren, die als Mitglieder der DAG aufgeführt sind.

Zeugenserver an einem drittem Standort

Eine Funktion, die Microsoft in Exchange 2013 hinzugefügt hat, war die Unterstützung eines Zeugenserver an einem dritten Standort, der alle Ressourcen ohne Eingreifen des Administrators online schalten kann.

Wenn jeder Standort einen unabhängigen Netzwerkpfad zum Zeugenserver des dritten Standorts hat, können die Knoten an einem Standort das Quorum über den Zeugenserver aufrechterhalten. Der Nachteil bei der Verwendung eines Zeugenserver an einem dritten Standorts besteht darin, dass sich Exchange-Administratoren die erforderliche Zeit nehmen müssen, um sich mit ihrem Netzwerkverhalten vertraut zu machen.

Load Balancing

Load Balancing ist eine Möglichkeit für Administratoren, zu verwalten, welcher Netzwerkverkehr letztendlich zu jedem Exchange-Server innerhalb eines Netzwerks geleitet wird. In der Regel ist es aus zwei Gründen wünschenswert, die Verteilung eingehender Client-Verbindungen zwischen Exchange 2016-Servern zu verwalten:

  1. Um Workloads zu verteilen: Wenn sich jemand die Mühe macht, mehrere Exchange-Server einzurichten und zu warten, ist es eine gute Idee, alle Exchange-Server regelmäßig arbeiten zu lassen.
  2. Um Auswirkungen eines Fehlers zu reduzieren: Wenn etwas schief geht, ist es schön, ein redundantes System zu haben, das die Arbeitslast des ausgefallenen Systems übernimmt.

Load Balancing ergänzt Datenbankverfügbarkeitsgruppen. Die Aufgabe einer Datenbankverfügbarkeitsgruppe besteht darin, (1) sicherzustellen, dass mehrere Kopien jedes Postfachs aktiviert werden können, und um (2) Client-Anforderungen zu akzeptieren, falls die aktive Kopie nicht mehr verfügbar ist. Load Balancing funktioniert ähnlich. Die Aufgabe von Load Balancing ist es, sicherzustellen, dass es andere Orte gibt, an denen Client-Datenverkehr gesendet werden kann, falls ein Ort nicht mehr verfügbar ist.

Das Load Balancing kann sich zwischen zwei oder mehr Exchange-Servern an einem einzelnen Standort oder auf mehrere Standorte erstrecken. Eine Exchange-Bereitstellung mit einer bevorzugten Architektur (Preferred Architecture, PA) würde vier Exchange-Server umfassen, die auf zwei separate Active-Directory-Standorte verteilt sind. Aktuelle Versionen von Exchange unterstützen das Round Robin Load Balancing für Layer 4, Layer 7 und DNS (Domain Name System).

Exchange Preferred Architecture

Exchange Preferred Architecture (PA) ist laut Microsoft das ideale Exchange-Deployment. Die PA wurde unter Berücksichtigung von Gesamtbetriebskosten (TCO), Hochverfügbarkeit, Ausfallsicherheit, Redundanz und Wiederherstellung entwickelt. PA soll als eine Art Architekturvorbild dienen.

Exchange Server Clients

Exchange-Benutzer greifen über einen E-Mail-Client auf Nachrichten zu. Microsoft Outlook ist dabei der am häufigsten verwendete Client. Exchange Server 2016 unterstützt:

  • Outlook 2016
  • Outlook 2013
  • Outlook 2010 Service Pack 2 (SP2)
  • Outlook für Mac für Office 365
  • Outlook für Mac 2011

Outlook ist auch als webbasierte Anwendung mit dem Namen Outlook on the Web/Outlook im Web – früher Outlook Web App (OWA) abgekürzt – verfügbar, mit der Benutzer über viele verschiedene Webbrowser auf Nachrichten zugreifen und mit ihnen interagieren können. Mit Outlook im Web können Benutzer Dokumente, die in OneDrive for Business auf einem lokalen SharePoint-Server gespeichert sind, verknüpfen und gemeinsam nutzen. Dadurch wird eine einfachere und direktere Möglichkeit für Endbenutzer geschaffen, Dateien zu speichern und an E-Mails anzuhängen.

Vor- und Nachteile von Exchange Server

Während es einfach ist, über die Vorteile der Verwendung von Microsoft Exchange zu sprechen, kann es schwierig sein, neben den Lizenzkosten auch die Nachteile zu erkennen. Im Moment gibt es nur wenige - wenn überhaupt - echte Exchange-Konkurrenten.

Exchange On-Premises-Editionen – alle Versionen zusammen – haben wahrscheinlich die größte aktive Benutzerbasis, doch Microsoft veröffentlicht keine Zahlen über die Anzahl der aktiven Benutzer, weder für lokale Exchange-Versionen noch für Exchange Online.

Outlook.com läuft mittlerweile ebenfalls auf Exchange, so dass Exchange On-Premises, Exchange Online und Outlook.com wahrscheinlich insgesamt mehr Benutzer (geschäftlich und privat) als Google Mail (geschäftlich und privat) haben. Jede andere konkurrierende Messaging-Plattform nach den Angeboten von Microsoft und Google hat eine vergleichsweise kleine geschäftliche Nutzerbasis.

Nach den Business-Messaging-Plattformen von Microsoft und Google ist die größte Lösung, gemessen an der installierten Nutzerbasis, wahrscheinlich Lotus Notes. Vergleiche zwischen Notes und Exchange sind schwierig, da Notes nicht in erster Linie eine Messaging-Lösung ist, sondern eine Datenbanklösung, die Messaging-Funktionalität enthält. Darüber hinaus hat IBM zum 30. Juni 2019 Lotus Notes an HCL verkauft und wird dieses Produkt nicht mehr aktualisieren.

Zimbra ist die größte Linux-basierte Messaging-Lösung, die sowohl als On-Premises- als auch SAS-basierte (Serial-Attached SCSI) Lösung erhältlich ist. Die Open-Source-Lösung Zimbra ist über verschiedene Lizenzoptionen verfügbar.

All die verschiedenen Messaging-Lösungen mit unterschiedlichen Funktionen und Schwerpunkten erschweren einen direkten Pro- und Kontra-Vergleich.

Microsoft Exchange Online

Microsoft bietet Exchange als Software as a Service (SaaS) unter dem Namen Exchange Online an. Es ist als eigenständiger Service oder als Teil der Office-365-Suite verfügbar. Endanwender stellen die Verbindung zu Exchange Online über den Outlook-Client oder Outlook im Web her.

Administratoren mit entsprechenden Berechtigungen für Office 365 konfigurieren und verwalten den Dienst. Microsoft bietet Exchange als gehosteten Dienst an, um den Verwaltungsaufwand bei der Bereitstellung von Exchange vor Ort zu reduzieren.

Exchange On-Premises versus Exchange Online

Die häufigste Wahl für Unternehmen wird zwischen Exchange On-Premises und Exchange Online ausfallen.

Exchange On-Premises
Pro Kontra
Administratoren können den Upgrade-Zeitplan und die Verfügbarkeit von Funktionen kontrollieren Hardwarereparaturen liegen in der Verantwortung des Administrators

Einmalige Lizenzgebühren

Muss lokal gewartet werden

Niemand außerhalb einer Organisation hat Zugang zu Servern oder Daten
Es entstehen sowohl Software- als auch Hardwarekosten

Exchange Online
Pro Kontra
Keine Notwendigkeit, Hardware oder Software zu warten
Unflexible Lösung
Monatliche Lizenzkosten
Potenzieller Verlust der Kontrolle über die Daten
99,9 Prozent Verfügbarkeit laut Service-Level-Agreement (SLA)
Potenziell teurer
Erfordert möglicherweise, dass die zugehörige lokale Software auf dem neuesten Stand gehalten werden muss

Exchange Online versus Gmail

Exchange Online
Pro Kontra
Integration mit Office-365-Anwendungen Teurer als Gmail
Hybrid-Integration mit der lokalen Exchange-Version

Gmail
Pro Kontra
Günstiger als Gmail
Keine komplette Software-Suite
Keine Hybrid-Optionen
Keine Active-Directory-Integration

Preise für Exchange Server

Die Preise für Exchange Server können stark variieren, je nachdem, wie der Server gekauft wird und welche Version gekauft wird.

Die lokale Version von Exchange wird auf einer Pro-Server-Basis verkauft. Zusätzlich ist für jeden Benutzer, der auf Exchange zugreift, eine Client Access License (CAL) erforderlich. Exchange Server muss auf einem Server installiert sein, auf dem das Windows-Server-Betriebssystem läuft, das ebenfalls mit einem Pro-Server- plus CAL-Modell lizenziert werden muss. Der Server muss in einer Active-Directory-Gesamtstruktur mit mindestens einem Domain Controller (DC) installiert sein.

Exchange Server selbst wird in zwei Lizenzstufen angeboten: Standard und Enterprise. Exchange-CALs gibt es auch in Standard und Enterprise. Jeder Benutzer muss über eine Windows Server Standard CAL verfügen und kann eine Enterprise CAL für zusätzliche Funktionalität haben. Sowohl die Standard- als auch die Enterprise-CALs können mit beiden Server-Editionen verwendet werden.

Exchange Online wird pro Benutzer und pro Monat entweder als eigenständiges Angebot oder als Teil eines Office-365-Pakets verkauft. Es gibt zwei eigenständige Angebote: Exchange Online Plan 1 bietet einen sicheren und verfügbaren Business-E-Mail-Service mit einem Postfach von 50 GB pro Benutzer. Exchange Online Plan 2 baut auf Plan 1 auf und umfasst unbegrenzten Speicherplatz, gehostetes Voicemail und Data Loss Prevention (DLP).

Geschichte von Exchange Server

Exchange Server wurde erstmals 1993 in einer privaten Preview veröffentlicht. Im Jahr 1996 wurde die erste öffentlich verfügbare Version von Exchange Server als Exchange 4.0 veröffentlicht. Die Versionsnummer 4.0 in der ersten Version von Exchange sollte bedeuten, dass es sich um das Upgrade von Microsoft Mail 3.5 handelte, aber es handelte sich dabei um zwei unterschiedliche Programme. Exchange 4.0 verwendete das X.500-Protokoll für Verzeichnisdienste und E-Mail-Zustellung.

1997 wurde Exchange 5.0 veröffentlicht. Dies war die erste Version von Exchange, die das Simple Mail Transfer Protocol (SMTP) als Mailserver-Zustellungsprotokoll verwendete. SMTP machte Exchange 5.0 zur ersten Version, die in der Lage war, mit anderen Messaging-Plattformen über das Internet zu kommunizieren. Mit Exchange 5.0 wurde OWA auch in Exchange 5.0 in einem Service Pack nach der Veröffentlichung eingeführt.

Exchange 5.5 wurde weniger als ein Jahr nach Exchange 5.0 veröffentlicht und war die erste Version von Exchange, die in den Editionen Standard und Enterprise erhältlich war. Exchange 5.5 beinhaltete die Einführung der Wiederherstellung gelöschter Elemente und die Unterstützung der Clients Internet Message Access Protocol 4 (IMAP4) und Lightweight Directory Access Protocol (LDAP) v3.

Exchange Server 2000 wurde zwei Jahre später, zeitgleich mit der Veröffentlichung von Active Directory, herausgegeben. Exchange 2000 enthielt eine Instant-Messaging-Funktion, die später in Office Communications Server ausgegliedert wurde. Exchange Server 2000 war allerdings nicht sehr erfolgreich.

Exchange Server 2003 war ein großer Schritt vorwärts für Exchange, sowohl in Bezug auf die Funktionalität als auch Akzeptanz. Mit Exchange Server 2003 begann der Trend, Exchange-Server zu unterscheiden, um unterschiedlichen Funktionen gerecht zu werden. Während auf allen Exchange-Servern dieselbe Software installiert wurde, unterstützte 2003 die Idee, einige Server als Frontend-Server für das Hosting von Client-Verbindungen zu bestimmen. Exchange 2003 erleichterte auch Migrationen von früheren Versionen von Exchange, indem es die Koexistenz von 2003-Servern in Organisationen ermöglichte, die noch mit früheren Versionen arbeiteten.

Exchange Server 2007 war eine weitere Hauptversion, die eine Menge neuer Funktionen enthielt. Bei der Veröffentlichung unterstützte Exchange 2007 keine öffentlichen Ordner, aber diese Unterstützung wurde nach Kundenbeschwerden mit Service Pack 1 (SP1) zurückgegeben. Exchange 2007 war das erste größere Microsoft-Produkt, das PowerShell vollständig umfasste. Zum ersten Mal war die gesamte Funktionalität von Exchange als PowerShell-Befehle verfügbar, obwohl einige Funktionen nicht über Steuerelemente der grafischen Benutzeroberfläche (GUI) verfügten.

Exchange 2007 führte auch das Konzept vollständig getrennter Exchange-Serverrollen ein. 2007 umfasste fünf verschiedene Exchange-Serverrollen, bei denen separate Software auf dem physischen Server installiert war. Vier dieser Rollen konnten auf Wunsch auf einem einzigen physischen Server installiert werden, aber jede Rolle konnte auch auf einem eigenen physischen Server installiert werden.

Exchange 2007 führte auch Unified Messaging ein, um Telefondienste bereitzustellen, und umfasste mehrere Datenbank-HA-Optionen. Diese Optionen, die mehrere Möglichkeiten zum Aufbau eines Datenbank-Clusters beinhalteten, erwiesen sich bei der Bereitstellung und Wartung als kompliziert und verwirrend.

Exchange 2010 war eine kleinere Version von Exchange Server. Die wichtigste Änderung in Exchange Server 2010 war die Einführung der DAG und die Abschaffung der komplizierten Clustering-Optionen von Exchange 2007. Exchange 2010 beinhaltete die Trennung der Serverrollen von Exchange 2007 und verbesserte die verfügbaren Load-Balancing-Optionen für eine bessere Verfügbarkeit des Client-Zugriffs. Office 365 wurde erstmals im Zeitrahmen von Exchange 2010 veröffentlicht, und Exchange 2010 enthielt die erste hybride Exchange-Funktionalität zwischen der lokalen Exchange-Server-Version und Exchange Online.

Exchange 2013 wurde am 11. Oktober 2012 zusammen mit neuen Versionen von SharePoint und Skype for Business veröffentlicht. Mit dieser Veröffentlichung brachte Microsoft seine Absicht zum Ausdruck, eine engere Integration zwischen den drei Office-Serverprodukten und ihren Office-365-Online-Versionen zu schaffen. Websitepostfächer wurden mit Exchange 2013 eingeführt und enthielten Funktionen, die den gemeinsamen Zugriff auf Exchange-Postfächer und SharePoint-Inhalte ermöglichten.

Exchange 2013 beinhaltete eine bedeutende Änderung der öffentlichen Ordner. Während die Grundfunktionalität von öffentlichen Ordnern unverändert blieb, wurde die Architektur dahingehend geändert, dass öffentliche Ordner in denselben Postfachdatenbanken wie Benutzerpostfächer enthalten sind. Während des Lebenszyklus von Exchange 2013 begannen sich die Kunden von Microsoft zu fragen, ob das Unternehmen weiterhin neue Versionen von Exchange On-Premises entwickeln oder nur Exchange Online unterstützen würde. Die Spekulationen traten in erster Linie deshalb auf, weil die neuen Exchange-Funktionen zuerst in Exchange Online auftauchten und dann in lokalen Versionen der Software umgesetzt würden.

Exchange 2016 entfernte die Möglichkeit, separate Exchange Serverrollen auf separaten physischen Servern zu installieren, mit Ausnahme der Edge-Transport-Rolle.

Exchange Server 2019 enthielt die Möglichkeit, Exchange Server auf Windows Server Core zu installieren. Dies war die erste Version von Exchange, die mit einer GUI ausgeführt und verwaltet werden konnte. Alle UM-Funktionen wurden in dieser Version aus Exchange 2019 entfernt, und neue Funktionen für Exchange 2019 wurden hinzugefügt.

Exchange-Server-Versionen

Die folgende Liste zeigt den Versionsfortschritt von Exchange Server mit dem entsprechenden Veröffentlichungsdatum und dem 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 2000 Server 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.00.0639.021 veröffentlicht.
  • Exchange Server 2013 wurde erstmals am 3. Dezember 2012 als Build 15.00.0516.032 veröffentlicht.
  • Exchange Server 2016 wurde zum ersten Mal am 1. Oktober 2015 als Build 15.01.0225.042 veröffentlicht.
  • Exchange Server 2019 wurde zum ersten Mal am 14. Oktober 2018 als Build 15.2.221.12 veröffentlicht.
Diese Definition wurde zuletzt im April 2020 aktualisiert

Erfahren Sie mehr über Business-Software

ComputerWeekly.de
Close