Microsoft Exchange Server

Microsoft Exchange Server ist die E-Mail-, Kalender-, Kontakt-, Zeitplanungs- und Kollaborationsplattform von Microsoft. Es wird auf dem Windows Server-Betriebssystem (OS) für den geschäftlichen Einsatz bereitgestellt. Microsoft hat Exchange Server so konzipiert, dass Benutzer von mobilen Geräten, Desktops und webbasierten Systemen aus auf die Messaging-Plattform zugreifen können. Die Telefoniefunktionen in Exchange Server unterstützen Sprachnachrichten.

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

Wie funktioniert Exchange Server?

Exchange Server ist ein Collaboration-Produkt der Enterprise-Klasse, das sich hauptsächlich auf das Senden, Empfangen und Speichern von E-Mail-Nachrichten konzentriert. Neben der Verwaltung des Messaging-Datenverkehrs bietet Exchange Server mehrere weitere Funktionen für die Zusammenarbeit, z. B. Kalender und eine enge Integration mit anderen Microsoft Office-Anwendungen.

Exchange Server ist bekannt für seine Hochverfügbarkeitsfunktionen (HA), die einen kontinuierlichen Dienst in verschiedenen Ausfallszenarien gewährleisten. Dazu gehören Entwurfspfade, die den Service bei Ausfällen einzelner Server oder Rechenzentrumsausfällen sicherstellen können.

Exchange Server 2019-Funktionen

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

Weitere Features in Exchange Server 2019 sind die folgenden:

• bietet Unterstützung für bis zu 256 GB Arbeitsspeicher und 48 CPU-Kerne;
• ermöglicht Installationen auf Windows Server Core;
• ermöglicht das native Blockieren des externen Zugriffs auf Exchange Admin Center (EAC) und die Exchange-Verwaltungsshell;
• verwendet die dynamische Speichercache-Zuweisung, um die Speichernutzung für aktive Datenbanken zu optimieren;
• verhindert, dass Teilnehmer Besprechungseinladungen weiterleiten;
• bietet Endbenutzern zusätzliche Abwesenheitsoptionen;
• ermöglicht Administratoren das Abbrechen von Besprechungen, die von einem Benutzer organisiert wurden, der das Unternehmen verlassen hat;
• ermöglicht Administratoren das Zuweisen von Delegiertenberechtigungen; und
• ermöglicht die native Weiterleitung und Zustellung von E-Mail-Adressen, die keine englischen Zeichen enthalten.

Zusammen mit diesen zusätzlichen Features in Exchange 2019 wurden die Rolle Unified Messaging (UM) und alle zugehörigen Funktionen aus Exchange 2019 entfernt. Ein Sept. 16, 2019, Blog auf der Exchange-Team-Website angegeben Microsoft die erweiterte Unterstützung von Exchange Server schieben würde 2010 von Jan. 14, 2020, bis Okt. 13, 2020, um Exchange Server 2010-Kunden mehr Zeit für den Abschluss ihrer Migrationen zu geben.

Administratoren, die Exchange Server 2010-Workloads unter Windows Server 2008 ausführen, müssen aufgrund der Änderungen Anpassungen vornehmen. 14, 2020, Ende der Lebensdauer für dieses Serverbetriebssystem.

Exchange Server 2019-Anforderungen

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

• Exchange 2019 kann in Active Directory (AD)-Gesamtstrukturen mit vorhandenen Exchange 2016- und/oder 2013-Servern installiert werden. Frühere Versionen von Exchange dürfen nicht in derselben 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 AD-Gesamtstrukturfunktionsebene 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, auf dem Exchange 2019 gehostet wird, sollte über einen Arbeitsspeicher (RAM) zwischen 128 und 256 Gigabyte (GB) verfügen.
• New Technology File System (NTFS) ist auf allen Festplattenpartitionen erforderlich, die die Systempartition, Exchange-Binärdateien, Diagnoseprotokolle und die Transportdatenbank enthalten. Resilient File System (ReFS) kann auf Partitionen verwendet werden, die Postfachdatenbanken und Transaktionsprotokolle enthalten.

Exchange Server Hochverfügbarkeit

Exchange Server verfügt über mehrere wichtige Funktionen zur Aufrechterhaltung der Ausfallsicherheit und HA. Die Postfachserverkomponenten von Exchange basieren auf Database Availability Groups (DAGs). Clientzugriffsserverkomponenten sind auf Lastenausgleich angewiesen.

Database availability groups

Die DAG ist das grundlegende Exchange-Subsystem zur Sicherstellung 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 Datenbanken automatisch zwischen Mitgliedern kopiert, um Redundanz im Falle eines Ausfalls auf Datenbank- oder Serverebene bereitzustellen. 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 und nicht auf Technologie, die für das Exchange-Team selbst spezifisch ist. Dies kann bedeuten, dass Funktionen und Fehler in Windows Server manchmal erhebliche Auswirkungen auf die Funktionsweise von Exchange haben können.

Active Manager

Active Manager (AM) ist die Exchange-Komponente, die für die Verwaltung von Failoverereignissen 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 ist, werden auf diesem Server zwei AM-Rollen ausgeführt: Primary Active Manager (PAM) und Standby Active Manager (SAM).

Der DAG-Mitgliedsserver, dem die Clusterquorumressource gehört, hat die PAM-Rolle inne. Wenn der DAG-Knoten, der die Quorumressource enthält, ausfällt, wird die PAM-Rolle auf den Server verschoben, der Eigentümer der Quorumressource ist.

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-Ereignis zu initiieren. Der SAM ist nicht verantwortlich für die Auswahl, welche Kopie der Datenbank nach einem Fehler aktiviert wird. Dieser Vorgang wird als Best Copy and Server Selection (BCSS) bezeichnet.

Auswahl der besten Kopie

Wenn ein Datenbankfehler erkannt wird, führt AM Schritte zur Wiederherstellung des Fehlers durch, indem die beste Kopie der betroffenen Datenbank ausgewählt wird, die aktiviert werden soll. Der BCSS-Prozess geht so:

1. Ein Fehler wird von AM oder Managed Availability erkannt. Dieser Prozess kann auch von einem Administrator gestartet werden, der einen ziellosen Switchover initiiert.
2. Der PAM startet den internen BCSS-Algorithmus.
3. Der ACLL-Unterprozess (attempt copy last logs) versucht, fehlende Protokolldateien vom Server zu kopieren, auf dem die aktive Kopie der Datenbank zuletzt gehostet wurde.
4. Wenn der ACLL-Prozess abgeschlossen ist, wird ein AutoDatabaseMountDial-Wert für Server überprüft, die Kopien der Datenbank hosten, 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, fahren Sie mit Schritt fünf fort. Wenn nicht, beginne ich diesen Vorgang bei Schritt zwei.
5. Der PAM gibt eine Mount-Anforderung an den Informationsspeicher aus. Wenn die Datenbank nicht bereitgestellt wird, kehrt AM zu Schritt zwei zurück.

Dieser Prozess enthält eine zusätzliche Logik, wenn das Failover-Ereignis durch ein Ü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 stammt.

DAG-Quorummodi

Eine DAG ist eine spezifische Implementierung eines Windows Server-Clusters. Die Exchange-Komponenten von DAGs basieren auf der zugrunde liegenden Windows Server-Clustertechnologie. Das Konzept des Quorums ist wichtig, um zu verstehen, wie DAGs implementiert und verwaltet werden.

Quorum ist die Idee, dass es im Falle eines Ausfalls einiger DAG-Mitglieder Regeln gibt, welche Ressourcen die verbleibenden Mitglieder bereitstellen können. Diese Quorumregelsätze sorgen für einen konsistenten Betrieb einer DAG und fungieren als Tiebreaker in Situationen, in denen DAG-Knoten die Kommunikation miteinander verlieren.

Wenn eine DAG eine gerade Anzahl von Knoten hat, verwendet sie den Knoten & File Share Majority quorum mode. In diesem Modus fungiert ein externer Zeugenserver als Tiebreaker. Wenn in diesem Modus ausgeführt wird, erhält jedes DAG-Knotenmitglied eine einzelne Stimme, aber der Zeugenserver gibt einem der DAG-Knoten eine zusätzliche Stimme. Die Clusterquorumdaten werden auf der lokalen Systemfestplatte jedes Mitglieds gespeichert, der Zeugenserver verfügt jedoch über eine separate Datei, die auf ein DAG-Mitglied als zuletzt aktualisierte Kopie der DAG-Clusterquorumdaten verweist.

Wenn eine DAG eine ungerade Anzahl von Mitgliedern hat, verwendet sie den Knotenmehrheitsquorumsmodus. In diesem Modus erhält jedes DAG-Mitglied eine Stimme, und die lokale Systemfestplatte jedes Mitglieds wird zum Speichern von Cluster-Quorumdaten verwendet.

Es ist möglich, bestimmte DAG-Mitglieder mit gewichteten Quorumstimmen manuell zuzuweisen. Dies wird in den meisten Fällen nicht empfohlen und sollte nur nach direkter Rücksprache mit dem Microsoft-Support erfolgen.

Koordinierungsmodus für die Aktivierung des Rechenzentrums

Der DAC-Modus (Datacenter Activation Coordination) ist eine Funktion von DAGs, die 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 manuelle Eingriffe, wenn der Server, auf dem die Datenbank gehostet wird, die Mehrheit der DAG-Mitgliedsserver nicht erreichen kann.

Microsoft Best Practices fordern, dass der DAC-Modus auf jeder DAG aktiviert wird, die zwei oder mehr Mitglieder hat und die kontinuierliche Replikation verwendet. Der DAC-Modus für eine DAG wird nur dann nicht empfohlen, wenn der Administrator ein Replikationstool eines Drittanbieters verwendet.

Wenn DAC aktiv ist, erfolgt beim Start eine zusätzliche Kommunikation zwischen DAG-Knoten, die das DAC-Protokoll (DACP) verwenden. DACP wird beim Start auf 0 gesetzt. Wenn das DACP-Bit bei 0 bleibt, versucht AM nicht, 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 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 der Strom wieder anläuft und die Server hochfahren, bevor die WAN-Verbindung (Wide Area Network) wieder online ist, verhindert der DAC-Modus, dass verschiedene Kopien derselben Datenbanken in beiden Rechenzentren aktiv werden.

Für eine DAG mit zwei Knoten verwendet der DAC-Modus einen Vergleich der Startzeit des alternativen Zeugenservers und der Zeit, zu der das DACP-Bit auf 1 gesetzt wurde, um festzustellen, ob Datenbanken bereitgestellt werden können. Wenn das DACP-Bit vor der Startzeit 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 Rechenzentrum – und das DAG-Mitglied darf keine Datenbanken bereitstellen. Wenn das DACP-Bit nach dem Booten des alternativen Zeugenservers auf 1 gesetzt wurde, geht das System davon aus, dass das Mounten von Datenbanken sicher ist.

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 weichen die beiden verschiedenen Kopien der Datenbank voneinander ab, was zu einem potenziellen Verlust von Benutzerdaten führt, wenn die beiden verschiedenen Kopien versuchen, einen Abgleich durchzuführen.

Zusätzlich zur Vermeidung von Split-Brain-Zuständen ermöglicht der DAC-Modus das Starten, Stoppen und Wiederherstellen von DatabaseAvailabilityGroup-Cmdlets. Diese Cmdlets werden verwendet, um manuelle Rechenzentrumsumstellungen 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 mit jeweils einer Kopie derselben Datenbank besteht. Zwei dieser Server befinden sich im Rechenzentrum A und zwei im Rechenzentrum B. In der Verbindung zwischen den beiden Rechenzentren tritt ein Netzwerkfehler auf. Ohne den aktivierten DAC-Modus wäre es für Server in jedem Rechenzentrum möglich zu glauben, dass sie eine Kopie der Datenbank aktivieren müssten.

Der DAC-Modus verhindert dieses Split-Brain-Szenario, indem eine Knotenmehrheit erforderlich ist, bevor eine Datenbank aktiviert werden kann. Knotenmehrheit bedeutet, dass die meisten Knoten im Cluster – in diesem Fall die DAG – online und erreichbar sein müssen, damit ein DAG-Knoten eine Datenbankkopie aktivieren kann. Wenn eine gerade Anzahl von Knoten in der DAG vorhanden ist, fungiert der File Share Witness auch als stimmberechtigtes Mitglied, um die Knotenmehrheit zu bestimmen.

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

Third-site Witness

Eine Funktion, die Exchange in der Ära 2013 hinzugefügt wurde, war die Unterstützung eines Third-Site Witness, der alle Ressourcen ohne Administratoreingriff online stellen kann. Wenn jeder Standort über einen unabhängigen Netzwerkpfad zum Zeugen des dritten Standorts verfügt, können die Knoten an einem Standort das Quorum mithilfe des Zeugenservers verwalten. Der Nachteil bei der Verwendung eines Zeugen eines Drittanbieters besteht darin, dass Exchange-Administratoren sich die erforderliche Zeit nehmen müssen, um ihr Netzwerkverhalten gründlich zu verstehen.

Lastenausgleich

Mit dem Lastenausgleich können Administratoren verwalten, welcher Netzwerkverkehr an jeden Exchange-Server innerhalb eines Netzwerks geleitet wird. Normalerweise ist es aus zwei Gründen wünschenswert, die Verteilung eingehender Clientverbindungen zwischen Exchange 2016-Servern zu verwalten:

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

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

Der Lastenausgleich kann sich über zwei oder mehr Exchange-Server an einem einzelnen Standort oder über mehrere Standorte erstrecken. Eine bevorzugte Architektur (PA) Exchange-Bereitstellung würde vier Exchange-Server umfassen, die auf zwei separate AD-Standorte verteilt sind. Aktuelle Versionen von Exchange unterstützen Layer 4, Layer 7 und Domain Name System (DNS) Round-Robin-Lastenausgleich.

Exchange Preferred Architecture

Exchange PA ist die ideale Exchange-Bereitstellung, wie sie sich das Exchange-Team von Microsoft vorgestellt hat. Die PA wurde unter Berücksichtigung der Gesamtbetriebskosten (TCO), HA, Ausfallsicherheit, Redundanz und Wiederherstellung entwickelt. Die PA soll nicht als Reifegradmodell verwendet werden; es wurde entwickelt, um als Inspiration verwendet zu werden.

Exchange Server-Clients

Exchange-Benutzer greifen über einen E-Mail-Client auf Nachrichten zu und interagieren mit ihnen. Microsoft Outlook ist der häufigste Client. Exchange Server 2016 unterstützt außerdem Folgendes:

• 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 namens Outlook on the Web – früher Outlook Web App und allgemein abgekürzt OWA – verfügbar, damit Benutzer von vielen verschiedenen Webbrowsern aus auf Nachrichten zugreifen und mit ihnen interagieren können. Mit Outlook im Web können Benutzer in OneDrive for Business gespeicherte Dokumente auf einem lokalen SharePoint-Server verknüpfen und freigeben. Dies schafft eine einfachere und direktere Möglichkeit für Endbenutzer, Dateien zu speichern und an E-Mails anzuhängen.

Vor- und Nachteile von Exchange Server

Es ist zwar einfach, über die Vorteile der Verwendung von Microsoft Exchange zu sprechen, es kann jedoch schwierig sein, neben den Lizenzkosten auch Nachteile zu identifizieren. Im Moment gibt es nur wenige – wenn überhaupt – echte Konkurrenten, die ausgetauscht werden können.

Exchange on-premises – alle Versionen zusammengerechnet – hat wahrscheinlich die größte aktive Benutzerbasis, aber Microsoft veröffentlicht keine Zahlen zur Anzahl der aktiven Benutzer in Exchange On-Premises oder Exchange Online. Outlook.com läuft jetzt auf Exchange, also Exchange on-premises, Exchange Online und Outlook.com sie haben wahrscheinlich mehr Benutzer (geschäftlich und privat) als Google Mail (geschäftlich und privat). Jede andere konkurrierende Messaging-Plattform nach Microsofts und Googles Angeboten hat vergleichsweise kleine Geschäftsbenutzer.

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

Zimbra ist die größte Linux-basierte Messaging-Lösung. Es gibt sowohl lokale als auch Serial Attached SCSI (SAS) -basierte Zimbra-Lösungen. Es gibt Open-Source-Versionen von Zimbra, die verschiedene Lizenzoptionen enthalten.

All die verschiedenen Messaging-Lösungen mit unterschiedlichen Funktionen und Schwerpunkten machen einen direkten Pro- und Contra-Vergleich schwierig. Im Folgenden finden Sie einige hochrangige Pro- und Contra-Vergleiche. Diese Listen sollen nicht endgültig sein.

Exchange on-premises vs. Exchange Online

Die häufigste Wahl für Unternehmen, die nach einer Messaging-Lösung suchen, ist Exchange on-Premises und Exchange Online.

Austausch vor Ort
Vorteile	Nachteile
Administratoren können den Upgrade-Zeitplan und die Verfügbarkeit von Funktionen steuern	Hardwarereparaturen liegen in der Verantwortung des Administrators
Einmalige Lizenzgebühr	Muss vor Ort gewartet werden
Niemand außerhalb der Organisation hat Zugriff auf Server oder Daten	Hardware- und Softwarekosten müssen abgeschrieben werden

Austausch Online
Vorteile	Nachteile
Keine Wartung von Hard- oder Software erforderlich	Unflexible Lösung
Monatliche Lizenzkosten	Potenzieller Verlust der Kontrolle über Ihre Daten
99.9% uptime Service-Level Agreement (SLA)	Potenziell teurer
	Möglicherweise muss die zugehörige lokale Software auf dem neuesten Stand gehalten werden

Exchange Online vs. Gmail

Exchange Online
Pros	Con
Integration with other Office 365 applications	More expensive than Gmail
Hybrid integration with Exchange on-premises

Gmail
Pro	Cons
Less expensive than Exchange Online	Less complete suite of software
	No hybrid options
	Keine Anzeigenintegration

Microsoft Exchange Online

Microsoft bietet Exchange als SaaS-Angebot namens Exchange Online an. Es ist als eigenständiger Dienst oder als Teil der Office 365-Suite verfügbar. Endbenutzer stellen über den Outlook-Client oder Outlook im Web eine Verbindung zu Exchange Online her. Administratoren mit Administratorberechtigungen für Office 365 konfigurieren und verwalten den Dienst. Microsoft bietet Exchange als gehosteten Dienst an, um den Verwaltungsaufwand für lokale Exchange-Bereitstellungen zu reduzieren.

Preise für Exchange Server

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

Exchange on-Premises wird pro Server verkauft. Darüber hinaus ist für jeden Benutzer, der auf Exchange zugreift, eine Clientzugriffslizenz (CAL) erforderlich. Exchange Server muss auf einem Server installiert sein, auf dem das Windows Server-Betriebssystem ausgeführt wird, das auch mit einem Pro-Server-Plus-CAL-Modell lizenziert sein muss. Der Server muss in einer AD-Gesamtstruktur mit mindestens einem DC installiert sein.

Exchange Server selbst ist in zwei Lizenzstufen erhältlich: 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 über eine Enterprise-CAL für zusätzliche Funktionen verfügen. Sowohl die Standard- als auch die Enterprise-CALs können mit beiden Server-Editionen verwendet werden.

Exchange Online wird pro Benutzer und Monat entweder als eigenständiges Angebot oder als Teil eines Office 365-Pakets verkauft. Es gibt zwei eigenständige Pläne. Exchange Online Plan 1 – 4 USD pro Benutzer und Monat – bietet sichere und verfügbare geschäftliche E-Mails mit einem Postfach von 50 GB pro Benutzer. Exchange Online Plan 2 – 8 USD pro Benutzer und Monat – baut auf Plan 1 auf und umfasst unbegrenzten Speicherplatz, gehostete Voicemail- und DLP-Funktionen (Data Loss Prevention).

Geschichte von Exchange Server

Exchange Server wurde erstmals 1993 in einer privaten Vorschau veröffentlicht. 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 dies waren zwei drastisch unterschiedliche Programme. Exchange 4.0 verwendet 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 enthielt. SMTP machte Exchange 5.0 zur ersten Version, die mit anderen Messaging-Plattformen über das Internet kommunizieren konnte. Exchange 5.0 führte auch OWA in Exchange 5.0 in einem Service Pack nach der Veröffentlichung ein.

Exchange 5.5 wurde weniger als ein Jahr nach Exchange 5.0 veröffentlicht und war die erste Version von Exchange in den Editionen Standard und Enterprise. Austausch 5.5 beinhaltete auch die Einführung von Recovery for Deleted Items und die Unterstützung für Internet Message Access Protocol 4 (IMAP4) und Lightweight Directory Access Protocol (LDAP) v3-Clients.

Exchange Server 2000 wurde zwei Jahre später zeitgleich mit der Veröffentlichung von AD veröffentlicht. Exchange 2000 enthielt eine Instant Messaging-Funktion, die später in Office Communications Server ausgegliedert wurde. Exchange Server 2000 war nicht weit verbreitet.

Exchange Server 2003 war ein großer Schritt nach vorn für Exchange, sowohl in Funktionalität und Annahme. Exchange Server 2003 startete den Trend, verschiedene Exchange-Server zu unterscheiden, um verschiedene Funktionen zu erfüllen. Während auf allen Exchange-Servern dieselbe Software installiert war, unterstützte 2003 die Idee, einige Server als Front-End-Server zum Hosten von Clientverbindungen festzulegen. Exchange 2003 erleichterte auch die Migration von früheren Versionen von Exchange erheblich, indem die Koexistenz von 2003-Servern in Organisationen aktiviert wurde, auf denen noch frühere Versionen ausgeführt wurden.

Exchange Server 2007 war eine weitere Hauptversion, die viele neue Funktionen enthielt. Bei der Veröffentlichung unterstützte Exchange 2007 keine öffentlichen Ordner, diese Unterstützung wurde jedoch nach Kundenbeschwerden mit Service Pack 1 (SP1) zurückgegeben. Exchange 2007 war das erste große Microsoft-Produkt, das PowerShell vollständig unterstützte. Zum ersten Mal standen alle Funktionen von Exchange als PowerShell-Befehle zur Verfügung, obwohl einige Funktionen keine Steuerelemente für die grafische Benutzeroberfläche (GUI) enthielten.

Exchange 2007 führte auch das Konzept vollständig getrennter Exchange Server-Rollen ein. 2007 umfasste fünf verschiedene Exchange Server-Rollen, für die separate Software auf dem physischen Server installiert war. Auf Wunsch können vier dieser Rollen auf einem einzelnen physischen Server installiert werden, aber jede Rolle kann auch auf einem eigenen physischen Server installiert werden.

Exchange 2007 führte auch UM ein, um Telefoniedienste „nach Beantwortung des Anrufs“ bereitzustellen, und enthielt mehrere Datenbank-HA-Optionen. Diese Optionen, die mehrere Möglichkeiten zum Erstellen eines Datenbankclusters enthielten, waren kompliziert und verwirrend in der Bereitstellung und Wartung.

Exchange 2010 war eine Nebenversion von Exchange Server. Die wichtigste Änderung in Exchange Server 2010 war die Einführung der DAG und die Einstellung der komplizierten Clusteroptionen von Exchange 2007. Exchange 2010 enthielt und verbesserte die Serverrollentrennung von Exchange 2007 und verbesserte die verfügbaren Lastenausgleichsoptionen für eine bessere Verfügbarkeit des Clientzugriffs. Office 365 wurde erstmals im Exchange 2010-Zeitrahmen veröffentlicht, und Exchange 2010 enthielt die erste Exchange-Hybridfunktionalität zwischen Exchange On-Premises und Exchange Online.

Exchange 2013 wurde am Okt. 11, 2012, neben neuen Versionen von SharePoint und Skype for Business. Diese Version bedeutete Microsofts Absicht, eine engere Integration zwischen den drei Office Server-Produkten und ihren Office 365 Online-Versionen zu schaffen. Websitepostfächer wurden in Exchange 2013 eingeführt und enthielten Funktionen, die den gemeinsamen Zugriff auf Exchange-Postfächer und SharePoint-Inhalte ermöglichten.

Exchange 2013 enthielt eine wesentliche Änderung an öffentlichen Ordnern, die als moderne öffentliche Ordner bezeichnet werden. Während die Grundfunktionalität öffentlicher Ordner gleich blieb, wurde die Architektur hinter den Kulissen geändert, um öffentliche Ordner in denselben Postfachdatenbanken wie Benutzerpostfächer aufzunehmen. Während des Lebenszyklus von Exchange 2013 fragten sich Microsoft-Kunden, ob Microsoft weiterhin neue Versionen von Exchange lokal entwickeln oder nur Exchange Online unterstützen würde. Die Spekulationen ereigneten sich hauptsächlich, weil neue Exchange-Funktionen zuerst in Exchange Online angezeigt wurden und dann in lokale Versionen der Software integriert wurden.

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

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. In dieser Version wurden alle UM-Funktionen aus Exchange 2019 entfernt und neue Funktionen für Exchange 2019 hinzugefügt.

Exchange Server-Versionen

Die folgende Liste zeigt den Versionsverlauf von Exchange Server mit dem entsprechenden Veröffentlichungsdatum und dem entsprechenden 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 im Februar veröffentlicht. 3, 1998, als Build 5.5.1960.
• Exchange 2000 Server wurde erstmals im November veröffentlicht. 29, 2000, als Build 6.0.4417.
• Exchange Server 2003 wurde erstmals im September veröffentlicht. 28, 2003, als Build 6.5.6944.
• Exchange Server 2007 wurde erstmals am 8. März 2007 als Build 8.0.685.25 veröffentlicht.
• Exchange Server 2010 wurde erstmals im November veröffentlicht. 9, 2009, als Build 14.00.0639.021.
• Exchange Server 2013 wurde erstmals im Dezember veröffentlicht. 3, 2012, als Build 15.00.0516.032.
• Exchange Server 2016 wurde erstmals im Oktober veröffentlicht. 1, 2015, als Build 15.01.0225.042.
• Exchange Server 2019 wurde erstmals im Oktober veröffentlicht. 14, 2018, als Build 15.2.221.12.