Die Verwaltung von Exchange Online ist recht einfach. Insbesondere dann, wenn Sie eine reine Cloud-Only-Organisation verwalten. Die Verwaltung täglichen Aufgaben lässt sich inzwischen bequem im Microsoft 365 Admin Center durchführen.
Wenn Sie jedoch eine Legacy Active Directory Umgebung betreiben und Benutzerkonten mit Azure AD Connect synchronisieren, gibt es einige Herausforderungen. Nach dem Umzug der Exchange Postfächer zu Exchange Online werden viele Postfach-relevante Einstellungen weiterhin aus der alten Active Directory Umgebung geführt und eine eine Änderung in der Microsoft 365 ist nicht möglich.
Wenn Sie zum Beispiel eine zusätzlichen E-Mail-Alias hinzufügen möchten, kommt es zu einem Fehler:
Der Grund ist, dass nach der Migration der Postfächer das lokale Active Directory weiterhin die sog. Source of Authority ist. Genau aus diesem Grund haben Sie ja Azure AD Connect im Einsatz. Wenn Sie Änderungen an solchen Attributen durchführen möchten, müssen Sie die Änderungen in der lokalen Active Directory Gesamtstruktur durchführen.
Nein. Eine Anpassung der Postfachberechtigungen, z.B. im Falle einer Urlaubsvertretung, ist ohne Probleme möglich. Der Grund dafür ist, dass Stellvertretungen und Berechtigungen im Postfach gespeichert sind und nicht direkt am Benutzerobjekt, wie es bei E-Mail-Aliasen der Fall ist.
Dies ist am Anfang ein wenig verwirrend. Damit Ihnen der Wechsel in die hybride Exchange Welt einfacher fällt, hat Alex Fields ein Cheat Sheet erstellt, dass ich Ihnen in der übersetzten Form zur Verfügung stelle. Wir nutzen beide immer wieder unsere Pfuschzettel, da man sich einfach nicht immer alles merken kann.
Die folgende Tabelle bietet eine Übersicht über die wichtigsten Aufgaben als Administrator.
Enable-RemoteMailbox [USERNAME] ` -RemoteRoutingAddress user@tentant.mail.onmicrosoft.com
Start-ADSyncSyncCycle -PolicyType Delta
Achten Sie vor der Bearbeitung der Active Directory Attribute darauf, dass Sie die erweiterte Ansicht in der Active Directory Users & Computers MMC aktiviert haben. Onhe diese Ansicht ist der Reiter Attributeditor nicht vorhanden.
Die Best Practice für einen hybriden Active Directory Betrieb mit Azure AD Connect sieht vor, dass Sie einen (den) letzten Exchange Server in der lokalen Exchange Organsation weiter betreiben. Dieser Server dient als Verwaltungsserver für alle Exchange-relevanten Objekte in der lokalen Active Directory Gesamtstruktur.
Die Exchange-relevanten Attribute für Benutzerkonten werden durch Exchange Server Schemaerweiterungen für Active Directory mitgebracht. Wenn Sie die og.g. Exchange-Attribute (msExch*) in Ihrem Active Directory nicht vorhanden sind, müssen Sie die Schemaerweiterungen von Exchange Server 2019 einspielen.
Viel Spaß mit Exchange Server und Exchange Online!
Eine lokale Exchange Organisation eines Unternehmens kann mit Exchange Online, einer der Kernbestandteile von Microsoft 365, verbunden werden. Diese Verbindung erfolgt durch die sog. Hybrid-Konfiguration und ist eine besondere Vertrauensstellung zwischen zwei technisch getrennten Exchange Umgebungen.
Diese besondere Vertrauensstellung zwischen der lokalen Exchange Organisation und Exchange Online ist notwendig, damit E-Mail- und System-Nachrichten, die zwischen beiden Umgebungen unsgetauscht werden, als interne E-Mail-Nachrichten erkannt und verarbeitet werden. Nur so ist es möglich, die korrekte Funktion aller Exchange Komponenten, unabhängig vom Bereitstellungsort der Benutzerpostfächer, zu gewährleisten.
Welche Vorteile ein Exchange Hybrid-Betrieb für die Exchange Umgebung in Ihrem Unternehmen hat, erfahren Sie in diesem Microsoft Docs Artikel.
Das folgende Schaubild verdeutlicht die Hybrid-Konfiguration und die besondere Vertrauensstellung (gepunktete grüne Linie).
Eine Exchange Hybrid-Konfiguration richten Sie mit Hilfe des Hybrid Confguration Wizard (HCW) ein. Während der HCW-Einrichtung müssen Sie sich für eine der zur Verfügung stehenden Möglichkeiten für den Hybrid-Betrieb entscheiden.
Für den Hybrid-Betrieb einer lokalen Exchange Organisation mit Exchange Online gibt es mehrere Möglichkeiten. Wir unterscheiden zwei grundlegende Betriebsvarianten, den klassischen und den modernen Hybrid-Betrieb. Für diese beiden Varianten stehen je bis zu drei Betriebsmodi zur Verfügung.
Das folgende Schaubild verdeutlich die unterschiedlichen Betriebsmodi für die beiden Betriebsvarianten einer Hybrid-Konfiguration.
Nun stellt sich automatisch die Frage, welchen Betriebsmodus soll ich für Hybrid-Konfiguration meiner Exchange Organisation verwenden?
Schauen wir uns zuerst an, welche technischen Voraussetzungen die beiden Betriebsvarianten haben.
Der klassische Hybrid-Betrieb erfordert, dass interne Exchange Server aus dem Internet über das Protokoll HTTPS erreichbar sind. Über diese Verbindung erfolgt die Kommunikation von Exchange Online zur internen Exchange Organisation für Hybrid-Funktionen. Damit einher geht die Anforderung für eine aus dem Internet erreichbare IP-Adresse und die Verwendung eines offiziellen TLS-Zertifkates.
Der moderne Hybrid-Betrieb erfordert keinerlei eingehende HTTPS-Verbindung von Exchange Online zur internen Exchange Organisation.
Die Verbindung zwischen der lokalen Exchange Organisation und Exchange Online erfolgt über den Exchange Hybrid Agent. Die Software für den Exchange Hybrid Agent ist als Dienst auf einem Server installiert und verbindet sich über eine ausgehende HTTPS-Verbindung mit Exchange Online. Die Konfiguration durch den HCW steuert hierbei das Verhalten von Exchange Online. Mit Blick auf den Hybrid-Betrieb von Exchange ist dies die bevorzugte und schnellste Betriebsvariante, da keinerlei zusätzliche Komponenten für eingehende HTTPS-Verbindungen benötigt werden. Wenn Ihr Unternehmen jedoch Microsoft Teams verwenden möchte und weiterhin Postfächer von Teams-Anwendern auf lokalen Exchange Servern betrieben werden sollen, können Sie diese Betriebsvariante nicht nutzen. Microsoft Teams unterstützt für dieses Betriebsszenario nur den klassischen Hybrid-Betrieb.
Für welches Betriebs- und Migrationsszenario passen die fünf Betriebsmodi?
Vollwertige, klassische Hybrid-Konfiguration mit direkter Veröffentlichung der Exchange Organisation ins Internet (SMTP/HTTPS)
Hybrid-Konfiguration, inkl. Azure AD Connect, zum einmaligen Verschieben aller Postfächer zu Exchange Online
Hybrid-Konfiguration, inkl. Azure AD Connect Express Setup, zum einmaligen Verschieben aller Postfächer zu Exchange Online
Vollwertige, klassische Hybrid-Konfiguration für neue Konfigurationen mit Hilfe des Exchange Hybrid-Agenten, jedoch mit Funktionseinschränken
Hybrid-Konfiguration, inkl. Azure AD Connect, zum einmaligen Verschieben aller Postfächer zu Exchange Online mit Hilfe des Exchange Hybrid-Agenten
Die Implementierung eines Hybrid-Betriebes stellt Ihr Unternehmen vor technische Herausforderungen. Daher muss die Einrichtung des hybriden Exchange Betriebes gut geplant werden.
Für den klassischen Hybrid-Betrieb benötigen Sie externe IP-Adressen für die beiden Protokolle HTTPS und SMTP, während für den modernen Hybrid-Betrieb nur eine IP-Adresse für das Protokoll SMTP benötigt wird. Ebenso benötigen Sie TLS-Zertifikate. Für den Nachrichtenfluss zwischen der lokalen Exchange Organisation und Exchange Online empfehle ich, ein separates TLS-Zertifikat zu verwenden, das nicht für das E-Mail-Internet-Gateway verwendet wird.
Die Absicherung der internen Exchange Server vor direkten Zugriffen aus dem Internet hat höchste Priorität. Sichern Sie den E-Mail-Nachrichtenfluss der hybriden Verbindung zwischen der lokalen Exchange Organisation und Exchange Online mit Exchange Edge-Servern ab. Der HTTPS-Zugriff zu den internen Exchange Server von Exchange Online wird über Reverse-Proxies abgesichert.
Bei einem dauerhaften Hybrid-Betrieb ist die lokale Exchange Organisation für die Verwaltung der zu Exchange Online verschobenen Exchange-Objekte zuständig. Im Zusammenspiel mit dem lokalen Active Directory bleibt sie die Source of Authority (SOA). Aus diesem Grund benötigen Sie mindestens einen verbleibenden lokalen Exchange Server, der als sog. Koexistenz-Server betrieben wird. Hierzu sollten Sie einen System mit Exchange Server 2016 oder Exchange Server 2019 verwenden.
Mit einer Auswahl von zwei Betriebsvarianten und insgesamt fünf Betriebsmodi fällt es nicht leicht, die passende Wahl zu treffen. Die wichtigste Frage, die Sie sich zuerst stellen müssen ist, wie soll die Bereitstellung von Exchange Funktionen in Zukunft für das Unternehmen aussehen und welche Anforderungen hat das Unternehmen im Hinblick auf die Absicherung von E-Mail-Nachrichten? Sind Anwender-Postfächer in der lokalen Exchange Organisation bereitgestellt und in Ihrem Unternehmen soll Microsoft Teams genutzt werden, so ist die klassische Voll-Hybrid-Variante die einzige Option.
Die größte Flexibilität erreichen Sie mit dem klassischen Hybrid-Betrieb, jedoch ist dies auch die Variante mit den meisten Anforderungen zur Einrichtung und den dauerhaften Betrieb.
Mit dem modernen Hybrid-Betrieb erreichen Sie schnell eine Hybrid-Konfiguration und können zügig Postfächer zu Exchange Online migrieren. Bei Nutzung von Microsoft Teams und Anwender-Postfächern in der lokalen Exchange Organisation ist dies jedoch keine Option.
Viel Spaß mit einem sicheren Exchange Online.
Die Frage nach dem Warum Exchange Modern Hybrid ist berechtigt.
Exchange Modern Hybrid ist besonders leicht zu implementieren, da die Anforderungen nach eingehenden HTTPS-Verbindungen aus dem Internet zur internen Exchange Organisation entfallen. Diese Erfordernisse einer klassischen Exchange Hybrid-Anbindung ist für viele Unternehmen eine große, oftmals unüberwindbare, Herausforderung. Die technischen Unterschiede dieser beiden Hybrid-Varianten sind im Blog-Artikel Möglichkeiten für Exchange Hybrid beschrieben.
Das nachfolgende, vereinfachte Schaubild verdeutlicht die Konfiguration von Exchange Modern Hybrid für HTTPS- und SMTP-Verbindungen. Basis einer Hybrid-Konfiguration ist immer eine Azure AD Synchronisation mit aktiviertem Exchange Hybrid-Modus (graue Linie).
Die beiden grünen Pfeile symbolisieren ausgehende HTTPS-Verbindungen von der Exchange Organisation zu Exchange Online. Die linke Verbindung dient der direkten HTTPS-Verbindung der On-Premises Exchange Server zu Exchange Online, um Hybrid-Funktionen, wie z.B. Anfragen für Frei-/Gebuchtzeiten der lokalen Exchange Organisation, bereitzustellen. Der rechte Pfeil enspricht der ausgehenden Verbindung der beiden Exchange Hybrid Agenten, die auf den beiden Exchange Servern installiert sind. Über diese Verbindung erfolgt die eingehende Kommunikation für Hybrid-Funktionen von Exchange Online zur lokalen Exchange Organisation.
Exchange Modern Hybrid vereinfacht die Hybrid-Kommunikation für das HTTPS-Protokoll. Der E-Mail-Kommunikation über das SMTP-Protokoll erfordert auch in dieser Hybrid-Variante eine zusätzliche Verbindung zwischen Exchange Online und der lokalen Exchange Organisation. Hier stehen Ihnen zwei Varianten zur Verfügung.
In SMTP Variante A wird eine direkte bidirektionale Verbindung zwischen der lokalen Exchange Organisation und Exchange Online verwendet. Um eine direkte Verbindung durch das Perimeter Netzwerk zu vermeiden, kann die bidirektionale Verbindung über Exchange Edge Transport Server geführt werden. Dies zeigt SMTP Variante B.
Es gibt zwei Haupteinsatzfelder für die Nutzung von Exchange Modern Hybrid.
Mit Exchange Modern Hybrid steht Ihnen eine Funktion zur Verfügung, mit der Sie schnell und einfach eine Hybrid-Konfiguration zwischen Ihrer On-Premises Exchange Organisation und Exchange Online einrichten können. Diese Betriebsart unterstützt jedoch nicht alle Hybrid-Funktionen, die Exchange Online und andere Dienste von Microsoft 365 bereithalten. Eine aktuelle Übersicht der Einschränkungen von Exchange Modern Hybrid finden Sie in der Exchange Hybrid Online Dokumentation.
Vor der Einrichtung einer Exchange Server Hybrid Konfiguration müssen Sie einen klaren Fahrplan, nicht nur für die Einrichtung, sondern auch für den regulären Dauerbetrieb, der Hybrid-Konfiguration haben.
Die Einführung einer Hybrid-Konfiguration besteht nicht nur aus der Umsetzung der technischen Anforderungen, die einen Hybrid-Betrieb ermöglichen. Bevor Sie den Weg zu einem Exchange Hybrid-Betrieb beschreiten, müssen Sie sich u.a. folgende Fragen stellen:
Dies ist nur eine kleine Auswahl der Fragen, die Sie sich vor der Einführung von Exchange Hybrid stellen müssen.
Die Einführung von Exchange Hybrid unterscheidet sich in zwei Prozessphasen:
In der Transitionsphase werden bestehende Prozesse auf die neuen betrieblichen Erfordernisse angepasst. Der Umfang der notwendigen Arbeiten ist für jedes Unternehmen unterschiedlich und hängt im Wesentlichen vom Grad der Prozessautomatisierung, der betrieblichen Softwareanforderungen und der technischen Voraussetzungen der lokalen IT-Infrastruktur ab. Die Transitionsphase dient auch zur Korrektur der zu Planungsbeginn gemachten Überlegungen für einen Exchange Hybrid Betrieb.
Nachdem alle notwendigen Anpassungen der Prozesse und Konfigurationen abgeschlossen sind, erfolgt der Wechsel in die Betriebsphase von Exchange Hybrid. In dieser Phase ist die Sicherstellung des täglichen Exchange Hybrid-Betriebes die Hauptaufgabe der Exchange Administratoren. Die stete Weiterentwicklung von Exchange Online und anderen Microsoft 365 Komponenten erfordert eine regelmäßige Bewertung und Konfiguration der Clouddienste.
Wenn Sie ein anderes Unternehmen im Rahmen einer Übernahme in Ihren Exchange Hybrid-Betrieb integrieren müssen, beginnen Sie mit einer neuen Transitionsphase. Eine Integration oder Migration wirkt sich nicht nur auf die Exchange Umgebung des anderen Unternehmens aus, sondern auch auf die Exchange Umgebung in Ihrem Unternehmen.
Viel Spaß mit Exchange Online und Exchange Modern Hybrid!
Exchange Server 2019 ist die aktuelle Version der E-Mail-Messaging Plattform für die Installation in der lokalten IT-Infrastruktur (aka On-Premises). Als lokale Infrastruktur gilt auch die Nutzung von Exchange Server 2019 auf virtualisiserten Serversystemen in Microsoft Azure. Bei Microsoft handelt sich, technisch gesehen, nur um ein ausgelagertes Rechenzentrum. Als wirkliche Alternative zu einem eigenen Betrieb von Exchange Server 2019 steht Ihnen Exchange Online, als Bestandteil des Software-as-a-Service Angebotes von Office 365, zur Verfügung.
Der Betrieb von Exchange Server 2019, die hybride Verbindung zwischen einer lokalen Exchange Organisation und Exchange Online oder die alleinige Nutzung von Exchange Online erfordern eine detaillierte Planung und Vorbereitung.
Auf dieser Seite finden Sie die wichtigsten Referenz-Links zu Online Ressourcen von Microsoft und anderen Quellen, um das für Sie richtige Exchange Produkt zu installieren, einzurichten und zu betreiben.
Wie einleitend schon ausgeführt, kann Exchange grundsätzlich in vier unterschiedlichen Architekturmodellen betrieben werden, die ihre ganz individuellen Vor- und Nachteile bieten. Diese sind:
= kontrolliert durch Microsoft = kontrolliert durch Kunden
Der Betrieb und die vollständige Verwaltung von Exchange Server erfordern die Verwendung der Exchange Management Shell (EMS). Mit Hilfe des browserbasierten Exchange Admin Center (EAC) können Sie Gelegenheitsaufgaben durchführen. Dies gilt für Exchange Server 2019 ebenso wie für Exchange Online.
Viel Spaß mit Exchange Server 2019 und Exchange Online.
Sie benötigen Hilfe bei der Planung und Installation Ihrer Exchange Server Installation? Sie haben Fragen über Ihre bestehende Exchange Server Infrastruktur und möchten Exchange Online implementieren? Kontaktieren Sie uns per E-Mail info@granikos.eu oder besuchen Sie unsere Webseite http://www.granikos.eu
Exchange Server ist ein sehr tolerantes Produkt und lässt sich in unterschiedlichste IT-Infrastruktur-Varianten installieren. Einige der möglichen Infrastruktur-Varianten sind gut geeignet für den Betrieb von Exchange Server, andere leider weniger gut. Daher ist es immens wichtig, bei der Planung einer Exchange Server Umgebung die notwendige Sorgfalt walten zu lassen.
Basis für die Planung einer Exchange Server Implementierung ist der Hauptgrundsatz für moderne Exchange Server Versionen:
Dieser Hauptgrundsatz wird, wie die Erfahunrg zeigt, leider allzu häufig ignoriert. Dieser Ignoranz wird in vielen Fällen dadurch Vorschub geleistet, dass Hard- und Software-Hersteller ihre ganz eigenen Hochverfügbarkeitslösung (HA) verkaufen möchten. Zu diesen Lösungen gehören sowohl HA-Funktionen von Hypervisor-Plattformen, aber auch, und dies viel häufiger, HA-Lösungsansätze von Storageanbietern.
Die Standardisierung einer Plattform wird nicht dadurch erreicht, indem eine unnötig komplexe Infrastruktur zum Standard erklärt wird, sondern das eine möglichst einfache Implementierung der Exchange Server Plattform zum Standard gemacht wird.
Unzählige Supportanfragen bei der Exchange Produktgruppe (PG) haben die Preferred Architecture Empfehlung über die Jahre reifen lassen. Sie ist daher keine spontan entstandene Empfehlung. Sie ist entstanden aus den Anforderungen und Kenntnisgewinnen im täglichen Betrieb der hochverfügbaren Cloudinfrastruktur von Exchange Online.
Sicherlich werden Sie nun einwenden, dass Sie keine Cloud-Plattform betreiben möchten. Sie dürfen nicht vergessen, dass eine moderne Exchange Server Version hochverfügbar betrieben werden möchte. Vergessen Sie daher nicht den Hauptgrundsatz für moderne Exchange Server Versionen ab Version 2013.
Auf der Microsoft Ignite Konferenz 2017 wurde in zahlreichen Vorträgen auf die Preferred Architecture Bezug genommen. Man konnte dem Eindruck erliegen, dass hier missioniert werden sollte. Am letzten Tag der Konferenz haben Boris Lokhvitsky und Robert Gillies eine sehr interessante Session zur richtigen Implementierung von Exchange Server gehalten. Hierbei wurde auch betrachtet, welche technischen Mindestanforderungen für eine Exchange Server Implementierung gelten und wie eine optimale Betriebsumgebung aussieht. Ein optimaler Betrieb einer On-Premises Implementierung folgt der Preferred Architecture. Ist dies nicht möglich sollte man sich für einen Wechsel zu Exchange Online entscheiden.
Das nachfolgende Diagramm verdeutlicht die unterschiedlichen Design-Optionen für eine Messaging-Plattform auf Basis von Exchange Server 2016.
Was bedeutet das nun im Detail für eine erfolgreiche Exchange Server Implementierung?
Was ist nun die viel zitierte Preferred Architecture und was bedeutet sie für eine erfolgreiche On-Premises Implementierung und den sicheren Betrieb von Exchange Server.
Die Preferred Architecture ist kein starres Gebilde. Vielmehr passt sie sich regelmäßig den technischen Gegebenheiten an. Zuletzt wurde z.B. die Empfehlung für den maximalen Arbeitsspeicher je Server von 96GB auf 192GB angehoben.
Nachfolgend werden die vier Bereiche der Preferred Architecture beschrieben. Ich empfehle aber dringend, immer auf den aktualisierten EHLO Blog Artikel Bezug zu nehmen und sich noch einmal mit der Exchange Server 2016 Architektur vertraut zu machen.
Die Preferred Architecture gliedert sich in die folgenden vier Bereiche:
Der Exchange Namensraum (Namespace) beschreibt die DNS Hostnamen, die erforderlich sind, damit sich Clients (z.B. Outlook, Browser oder mobile Endgeräte) mit den Exchange Servern verbinden können. Im Rahmen des Data Center Designs (s.u.) wird davon ausgegangen, dass diese Verbindungen auf zwei Standorte verteilt werden.
Bei der Planung der Exchange Server Namensräume (Namespaces) unterscheidet man zwischen gebundenen (bound) und ungebundenen (unbound) Namensräumen für Exchange Server in zwei Rechenzentren.
Bei einem gebundenen Namensraum besitzt jedes Rechenzentrum einen eindeutigen Namen für den Zugriff auf Exchange Server Client Access Services. Clientverbindungen erfolgen somit immer zu dem Rechenzentrum, in dem sich auch die aktive Datenbankkopie des angefragten Benutzerpostfaches befindet.
Bei einem ungebunden Namensraum verfügen die Rechenzentren über keine eigenen Namen für den Zugriff auf Exchange Server Client Access Services. Clientverbindungen werden bei jeder Anfrage durch den Load Balancer in eines der beiden Rechenzentren geleitet. Eine Ausnahme bilden hier die Office Online Server (OOS), die immer einen gebundenen Namensraum erfordern.
Das nachfolgende Beispiel für eine Preferred Architecture Namespace Design benötigt vier Namen:
Eine hochverfügbare und ausfallsichere Architektur erfordert den Betrieb von mindestens zwei Rechenzentren. Ob es sich nun um vollwertige und eigenständige Rechenzentren oder um lokale Serverräume in getrennten Brandabschnitte im gleichen Gebäude handelt, lasse ich hier bewusst offen. Die Anforderungen zur Verfügbarkeit von IT-Basisdiensten hängen schließlich nicht nur von einer Exchange Server Implementierung ab.
Eine wichtige Anforderung ergibt sich aber für den Betrieb des Active Directory in der Preferred Architecture.
Der über zwei Rechenzentren gestreckte Betrieb einer einzelnen Active Directory Site wird zwar technisch unterstützt, für die Preferred Architecture ist es aber empfohlen, dass jedes Rechenzentrum in einer eigenen Active Directory Site abgebildet wird. Die Gründe dafür sind:
In der Preferred Architecture werden alle Exchange Server mit Postfachrolle als physikalische Systeme betrieben. Die Hauptgründe hierfür sind:
Die physikalischen Server, die für eine Preferred Architecture Implementierung verwendet werden, haben keine allzu besonderen Anforderungen. Solch ein Standard-Server besteht aus:
Die weiteren Konfigurationen des Servers sind:
Um eine optimale Nutzung der Systemressourcen im ungebundenen Namensraummodell zu gewährleisten, werden die aktiven Kopien der Datenbanken gleichmäßig (symmetrisch) über alle Mitgliedsserver der Database Availability Group (DAG) verteilt. Die maximal 16 Mitgliedsserver einer DAG werden ebenfalls symmetrisch, mit einer geraden Anzahl an Servern je Rechenzentrum über alle Rechenzentren verteilt.
Durch mehr Mitgliedsservern in einer DAG wird eine bessere Redundanz und Nutzung der Ressourcen sichergestellt. Die Preferred Architecture sieht vor, dass eine DAG aus mindestens acht Mitgliedsservern besteht. Bei einem steigenden Ressourcenbedarf wird die DAG um weitere Mitgliedsserver erweitert.
In der Preferred Architecture benötigt Exchange Server für einen sicheren Betrieb nur eine einzelne Netzwerkschnittstelle. Diese Netzwerkschnittstelle wird ohne Teaming betrieben. Diese vereinfachte Netzwerkanforderung erleichtert den Betrieb und auch die Wiederherstellung im absoluten Fehlerfall. Eine separate Heartbeat-Netzwerkschnittstelle für die Cluster-Kommunikation ist nicht erforderlich.
Der Witness Server einer DAG gewährleistet das korrekte Verhalten der DAG bei einem automatischen Failover, sollte es zu einem Ausfall eines Rechenzentrums kommen. Im Idealfall wird der Witness Server an einem dritten Standort in einer anderen Active Directory Site platziert. Sollte kein dritter Standort zur Verfügung stehen, so kann der Witness Server auch in Microsoft Azure betrieben werden.
Was ist nun die richtige Exchange Server Architektur?
Wenn Sie der Preferred Architecture (Blauer Kreis) oder aber der Best Practice Empfehlung (Lila Kreis) folgen, können Sie einen sicheren Betrieb der E-Mail Plattform in Ihrem Unternehmen gewährleisten, ohne unnötige technische Risiken einzugehen. Jenseits einer Nutzung von Exchange Online stellen diesen beiden Design-Optionen das Optimum für einen zuverlässigen Betrieb dar. Je weiter Sie sich von der Preferred Architecture für Exchange Server entfernen, um so mehr steigt das Betriebsrisiko.
Wenn Sie den vollmundigen Produktversprechen von Drittherstellern für Speicherlösungen oder anderen faszinierenden Lösungen zur Hochverfügbarkeit von Exchange Server folgen, so verabschieden SIe sich in eine individuelle "funktioniert irgendwie" Implementierung. Tritt bei solch einer Implementierung ein Fehlerfall auf, so liegt das Problem nicht beim Produkt Exchange Server. Die Erfahrung hat leider gezeigt, dass in solchen Fällen immer von Unzulänglichkeiten in der Implementierung abgelenkt wird.
Als absolute Mindestempfehlung gilt eine Exchange Server Implementierung, die den Exchange Server Systemanforderungen und den Exchange Server Speicherkonfigurationsoptionen folgt.
Abkürzungen
Viel Spaß beim Betrieb von Exchange Server.
Auf der Microsoft Ignite 2015 Konferenz in Chicago wurden erste Informationen über Exchange Server 2016 veröffentlicht.
Es wurde klar artikuliert, dass keine Abkehr von On-Premise Versionen geplant ist. Die Anforderungen der Microsoft Kunden werden auch in der Zukunft On-Premise Versionen von Exchange Server erforderlich machen. Wie neue Funktionen ihren Weg in die On-Premise Version von Exchange finden, hat sich aber bereits mit Exchange Server 2013 geändert. Neue Funktionen werden zuerst in Office 365 (Exchange Online) entwickelt, bereitgestellt und stabilisert. Nachfolgend wird entschieden, ob eine Funktion den Weg in die On-Premise Variante von Exchange Server findet. Microsoft beschreibt diesen Weg als "Delivering Innovation".
Das nachfolgende Schaubild verdeutlicht diesen Prozess:
Jede Version von Exchange Server ging mit einer Änderung der Server Architektur einher. Mit Exchange Server 2016 lassen wir das mit mit Exchange Server 2007 eingeführte Konzept der Rollen fast komplett hinter uns. In Exchange Server 2016 exisitiert nur noch eine intere Rolle, der Mailbox Server. Hinzu kommt nur noch die Edge Rolle für den bereits bekannten Einsatz in der DMZ.
In der Mailbox Rolle sind nun alle Funktionen zusammengefasst, die in Exchange Server 2013 noch auf CAS und Mailbox aufgeteilt waren. Exchange Server 2016 nutzt eine tiefe Integration mit dem Office Web Apps Server, um in Outlook Web App 2016 eine direkte Bearbeitungsmöglichkeit für Office Dokumente anzubieten.
Die nachfolgenden beiden Schaubilder verdeutlichen die Architekturunterschiede zwischen Exchange Server 2013 und Exchange Server 2016.
Mit Exchange Server 2016 ergeben sich keine grundlegenden Änderungen für die Kommunikation von Clients zum Exchange Server. Clients verbinden sich weiterhin über einen Load Balancer mit dem "Proxy" Endpunkt. Im Gegensatz zu Exchange Server 2013 kann der Proxy-Layer aber nicht mehr auf dedizierte Server installiert werden. Die Separierung von CAS und Mailbox-Rollen wurde bereits in der Preferred Architecture für Exchange Server 2013 nicht mehr empfohlen.
Exchange Server 2016 arbeitet mit einem Proxy-Layer. Dieser ist jedoch in einem Building Block auf dem Server integriert.
Auch für die Konnektivität für Unified Messaging ergeben sich keine Änderungen. Verbindungen zum Proxy-Layer werden zum direkten UM-Endpunkt umgeleitet.
Die beiden nachfolgenden Schaubilder verdeutlichen die Unterschiede in der Client Konnektivität zwischen Exchange Server 2013 und Exchange Server 2016.
Was bietet Exchange Server 2016 jenseits der Veränderungen in der Architektur? Die großen Themenblöcke, die Microsoft mit Exchange Server 2016 besetzen möchte sind:
Unter dem Titel Better Collabiration soll durch die Integration von Exchange und SharePoint das Arbeiten mit Dateianhängen grundlegend verändert werden. Anstatt Office Dateien in unterschiedlichen Versionen per E-Mail zu versenden und so die Postfächer mit unnnötigen Daten zu füllen, sollen nur noch Links zu den entsprechenden Dateien versendet werden. Die Dateien werden hierzu in SharePoint bzw. OneNote for Business gespeichert. Die erforderlichen Berechtigungen zum Bearbeiten oder zur Ansicht werden für die E-Mail Empfänger automatisch vergeben. Dies ermöglicht den Anwendern, an einer Version des Dokumenten gemeinsam zu arbeiten. Diese Funktionen werden durch den Einsatz des Office Web Apps Servers ermöglicht.
Selbst mit externen Kommunikationspartnern ist solch eine Kollaboration möglich. Hier ergeben sich für Unternehmen aber auch neue Herausforderungen. Die Veröffentlichung der Funktionen und die Möglichkeit, dass externe Anwender Zugriff auf Dokumente erhalten können, erfordern eine detaillierte Planung der Infrastruktur und der notwendigen Konfigurationen.
Das nachfolgende Schaubild zeigt die erforderlichen Komponenten:
Die Nutzung des Posteinganges unterscheidet sich grundlegend in zwei Varianten:
Es existieren zahlreiche Ratgeber zum effizienten Arbeiten mit E-Mail und dem Posteingang. Leider gibt es nicht die eine Antwort und E-mail wird aus unterschiedlichsten Gründen noch ein lange Zeit der primäre Weg der digitalen Kommunikation sein.
Exchange Server 2016 versucht mit einem intelligenteren Posteingang das Arbeiten mit Outlook zu verbessern. Hierzu gehört eine Verbesserung bei den Suchergebnissen und Beschleunigung der Suche selber. Hinzu kommt eine bessere Unterstützung für Add-Ins in Outlook.
Die neue REST API von Exchange Server 2016 erleichtert die Entwicklung von einheitlichen Add-Ins für Outlook Add-ins mit Anbindung an Exchange On-Premise oder Exchange Online.
Weitere Verbesserungen sind:
Zu den OWA Verbesserungen gehören:
Durch den immer größeren Verbreitungsgrad von mobilen Endgeräten, erfolgt auch der Zugriff auf E-Mails immer mehr von diesen Geräten. Nach einer Studie von Experian erfolgten in Q3 2014 53% aller Zugriffe auf E-Mails von Telefonen oder Tablets.
Hier ist das Ziel, eine einheitliche Erfahrungswelt über alle Gerätetypen hinweg zu schaffen. Anstatt wie in der Vergangenheit unterschiedliche Exchange ActiveSync Clients auf mobilen Endgeräten zu haben, möchte Microsoft die einheitliche Outlook Erfahrung ermöglichen. Dies wird erreicht durch:
Exchange Server 2016 wurde für den Betrieb in modernen Datacentern entwickelt. Dieses Anspruch wird Exchange hauptsächlich durch die vereinfachte Softwarearchitektur und die vereinfachten Hardwareanforderungen erreicht. Die Preferred Architecture für Exchange Server 2016 setzt nicht auf komplexe Virtualisierung, sondern auf den Einsatz von einfachen Standardservern und JBOD als Speichermedium.
Exchange Server 2016 soll auf Standardhardware betrieben werden und so zusätzliche Single-Point of Failures vermeiden helfen.
Die Koexistenz mit Exchange Server 2013 ist einfacher zu implementieren als die Koexistenz in vorherigen Exchange Versionen. Grund hierfür ist einfach die starke Ähnlichkeit zwischen Exchange Server 2013 und 2016.
Die automatische Reparatur von Postfachdatenbanken erhöht die Verfügbarkeit und vermindert das Risiko von Datenverlusten. Dies wird erreicht durch "DB Divergence Detection", "Loose Trunctation" und den Einsatz des ReFS Dateisystems für Datenlaufwerke.
Für ein modernes Deployment von Exchange Server 2016 stehen der Betrieb einer DAG ohne adminstrativen Endpunkt und die Unterstützung von Azure File Share Witness zur Verfügung. Unternehmen, die noch ein klassisches Backup vewenden, werden von einer DAG ohne administrativen Endpunkt nicht profitieren können, da die Hersteller von Backup-Software sich mit dieser neuen Cluster-Variante (Funktion von Windows Server 2012 R2) schwer tun. Ebenso ist die Funktion eines Azure File Share Witness nicht für alle Unternehmen möglich.
Die Indizierung der passiven Postfachdatenbanken erforderte in der Vergangenheit immer eine Kommunikation mit der aktiven Kopie. Mit Exchange Server 2016 erfolgt die Indizierung nur direkt in der passiven Kopie, was zu einer Reduzierung des Datenverkehrs führt.
Exchange Server 2016 bringt neue Funktionen zur Data Loss Prevention, zur Auditierung und zu eDiscovery. Die Informationen und Funktionen von DLP Policies stehen nun nicht nur in Outllok zur Verfügung, sondern auch in anderen Office Client Produkten und in SharePoint. Hierdurch ergibt sich eine einheitliche Erfahrung für den Anwender. DLP Policies werden somit nicht erst beim Versenden von Nachrichten angewandt, sondern bereits beim versuchten Aufrufen von Dateien.
Das Auditierungsschema wurde in Anlehnung zu Office 365 vereinheitlicht. Dies erleichtert die Auswertung der Audit/Protokolldateien in einer Hybrid-Konfiguration. Ebenso wurden die Such- und Filterfunktionen verbessert.
Neue Öffentliche Ordner können nun auch auf In-Place Hold gesetzt werden.
Exchange Server 2016 bietet zahlreiche neue Funktionen und Verbesserungen bekannter Funktionen. Jedoch muss man auch die kommende Version von Exchange Server 2016 als Version 1.0 eines On-Premise Produktes sehen. Durch den mit Exchange Server 2013 eingeführten Deployment Zyklus von drei Monaten, müssen sich Unternehmen auf einen schnelleren Rolloutplan einstellen. Rein technisch wird alle drei Monate ein neues Produkt eingeführt. Interne Change Prozesse rund um Exchange müssen auf die neuen Anforderungen hin angepasst werden.
Exchange Server 2016 befindet sich sich gegenwärtig noch im geschlossen TAP Programm mit ausgewählten Kunden. Die öffentliche Beta-Phase für Exchange Server 2016 ist für den Sommer 2015 vorgesehen. Als geplanter Veröffentlichungstermin für Exchange Server 2016 ist Herbst/Winter 2015 vorgesehen.
Die Virtualisierung von Exchange ist nicht neu und war bereits seit Exchange 2003 mit VMware eine Option, obwohl es damals von Microsoft keine offizielle Unterstützung hierzu gab. Im Rahmen des Microsoft Server Virtualization Validation Program (SVVP) wurde die Virtualisierung von Exchange 2007 Service Pack 2 auf VMware ESX 3.5 Update 2 erstmal offiziell voll unterstützt.
Mit der Veröffentlichung von Exchange Server 2010 wurden alle Serverrollen (Unified Messaging ab Exchange 2010 SP1) auf allen SVVP validierten Hypervisor-Plattformen unterstützt. Die Unterstützung der Virtualisierung von Exchange Server 2010 wurde aber nur langsam adaptiert, da dies eine grundlegende Änderung im Design und der Architektur der Systeminfrastruktur mit sich brachte. Viele Systemadministratoren misstrauten der Virtualisierung und führten häufig die fehlende "Performance" als primären Grund an, sich gegen die Virtualisierung zu entscheiden. Interessant ist, dass "Performance" als genereller Begriff verwendet wurde (wird), um die Virtualisierung von Exchange Systemen abzuwenden. Die technologische Weiterentwicklung von Exchange und die stete Reduzierung der Anforderungen an Speichermedien in Bezug auf den erforderlichen Datendurchsatz, denn diese waren in der Vergangenheit der einzige Grund, sich gegen die Virtualisierung zu entscheiden, wird teilweise immer noch ignoriert.
Mit Exchange Server 2013 können alle Rollen problemlos virtualisiert werden und ermöglichen so eine optimale Ausnutzung der Hardware-Ressourcen in Ihrem Rechenzentrum.
Trotzdem ist es erforderlich, eine Exchange Umgebung korrekt und gewissenhaft zu planen und zu berechnen. Dies hat sich mit der Virtualiserungsoption für Exchange nicht geändert. Nur mit einer gewissenhaften Planung können komplexe Änderungen der Exchange-Landschaft zu einem späteren Zeitpunkt vermieden werden. Exchange Server 2013 besteht aus folgenden Serverrollen:
Die erfolgte Reduzierung von vier Serverrollen in Exchange 2007/2010, hin zu zwei Serverrollen, wenn wir die Edge-Rolle einmal als Sonderfall betrachten, erleichtert die Konzeption einer virtualisierten Exchange-Umgebung erheblich.
Wenn es um das Thema Virtualisierung von Enterprise-Applikation geht, einmal ganz ohne den Fokus Exchange, muss immer geklärt werden, wie die Hochverfügbarkeit (HA) der Applikation gewährleistet wird. Auf der einen Seite existieren HA-Funktionen in der jeweiligen Hypervisor-Plattform selber, auf der anderen Seite stehen die HA-Funktionen der Applikationen. Naiv gesehen könnte man annehmen, dass beides zusammen das Maximum an Hochverfügbarkeit bieten würde. Dies ist jedoch nicht der Fall.
Gerade für den Fall eines Support-Calls mit Microsoft ist es wichtig, dass Exchange in einer Konfiguration betrieben wird, die auch zu 100% unterstützt wird.
Für die Virtualisierung von Exchange Server 2013 gilt es Folgendes für einzelnen Systemkomponenten zu beachten
Exchange Server 2013 kann ebenso wie Vorgängerversionen als Multi-Role Server (Mailbox- und CAS-Rolle auf einem Server) oder als Single-Role Server (Mailbox-Rolle und CAS-Rolle auf separaten Systemen) installiert werden. So wie Exchange Rollen selber aufgeteilt werden können, können auch physische und virtuelle Systeme verteilt betrieben werden.
Natürlich können (sollten) auch die benötigten Load Balancer virtualisiert betrieben werden. Die möglichen Kombinationen mit den o.g. Exchange-Konfigurationen sind zahlreich und werden in diesem Artikel vernachlässigt.
Grundsätzlich gilt die Empfehlung, für das Sizing einer Exchange 2013 Umgebung (physisch oder virtuell), den Exchange 2013 Server Role Requirements Calculator zu verwenden. An diesem Tool führt kein Weg vorbei, wenn man eine verlässliche Aussage zu den Anforderungen für die Exchange Umgebung erhalten möchte. In den aktuellsten Versionen sind notwendige Berechnungskorrekturen für die Virtualisierung bereist enthalten. Microsoft geht von einem zusätzlichen Overhead durch den Hypervisor von 10% aus. VMware wiederum geht von ca. 2% bis 5% Overhead aus.
Wie bereits erwähnt, ist eine 1:1 Zuordnung von virtuellen CPU Cores zu physischen CPU Cores zu empfehlen, da dies die Umsetzung der kalkulierten Anforderungen in den laufenden Betrieb stark vereinfacht.
Microsoft hat empfiehlt beim Einsatz von Exchange Server (2010 und 2013) auf das Hyper-Threading der CPUs zu verzichten. Wichtig ist, dass Hyper-Threading CPUs nicht gleichzusetzen sind mit physischen CPUs. Als Hauptgrund wird angegeben, dass dies die CPU Planung unnötig verkompliziere. Als zweiter Grund wird die .NET Garbage Collection angeführt, die auf Basis der CPU Anzahl arbeitet und entsprechend Arbeitsspeicher allokiert. Durch Hyper-Threading wird allerdings unnötig viel Arbeitsspeicher für die Garbage Collection reserviert.
Im Rahmen einer Virtualisierung besteht das beschriebene Problem nicht im gleichen Ausmaß, wie in einer physischen Umgebung, da der VM eine feste Anzahl an Prozessoren zugeordnet ist. Dies bedeutet, dass Sie das für Ihre Umgebung passende Processor-Ratio finden müssen, wenn Sie nicht der 1:1 Zuordnung folgen möchte. Dies gelingt am besten, indem Sie mit einer 1:1 Zuordnung beginnen und mit einer System-Monitoring Lösung eine Baseline erstellen. Anschließend passen Sie die Prozessorzuordnung an und vergleichen die Auslastung- und Performancediagramme mit der Baseline.
Die nachfolgende Tabelle listet die Mindestanforderungen an Arbeitsspeicher für Exchange Server 2013
Dies sind die absoluten Mindestanforderungen. Ohne Verwendung des Role Requirements Calculators wird eine korrekte Planung für den performanten Betrieb von Exchange nicht gelingen.
Für einen Exchange Mailbox-Server mit 1000 Postfächern mit einem Anwenderprofil von 150 gesendeten und empfangenen Nachrichten pro Tag und einer Anforderung von 36MB Datenbankcache pro Postfach, benötigen Sie bereits mindestens 36GB Arbeitsspeicher. Ergänzend zum Role Requirements Calculator empfehle ich den Blog-Artikel "Ask the Perf Guy: Sizing Exchange 2013 Deployments" (http://bit.ly/PerfGuyExchange2013Deployments).
Ergänzend zu den Speicheranforderungen für Exchange Server 2013 müssen noch 4GB bis 8GB für das Betriebssystem addiert werden.
Für die Planung der Netzwerkverbindungen der virtuellen Systeme gelten die gleichen Anforderungen wie für physische Exchange Server. Exchange Server, die nicht Mitgliedsserver einer DAG sind, können mit einem einzelnen Netzwerkadapter konfiguriert werden. Mitgliedsserver einer DAG sollten immer mit zwei Netzwerkadaptern konfiguriert werden, um die Datenbankreplikation über ein separates Netz zu leiten und vom allgemeinen Zugriff auf die Postfachdatenbanken zu trennen. Der Einsatz von einzelnen Netzwerkadaptern ist zwar unterstützt, sollte sich aber auf Test- und Laborumgebungen beschränken.
Die physischen Netzwerkadapter im Host-System können durch Teaming ausfallsicher konfiguriert werden.
Das nachfolgende Beispiel zeigt, wie ein Exchange 2013 Mailbox Server, der Mitgliedserver einer DAG ist, und ein CAS Server nur durch VLANs getrennt an einem virtuellen Switch verbunden sind. Der virtuelle Switch ist durch NIC-Teaming im Hypervisor redundant mit der physischen Netzwerk Infrastruktur verbunden.
Mit der gleichen Exchange Server-Konstellation kann aber das DAG Netzwerk-Interface zur Datenreplikation über einen separaten virtuellen Switch, der über ein eigenes NIC-Interface im Hypervisor verfügt, mit einem dedizierten Replikationsnetzwerk verbunden werden.
Die zweite Konfiguration stellt sicher, dass die Datenreplikation in einem dedizierten physischen Netzwerk stattfindet. Jedoch erhöht dieser Lösungsansatz auch die Komplexität der Netzwerkinfrastruktur selber. Hinzu kommt, dass standardmäßig das MAPI Netzwerk als Backup für einen möglichen Ausfall des Replikationsnetzwerkes verwendet wird. Wenn Sie ausschließen möchten, dass das MAPI Netzwerk als Backup-Netzwerk verwendet werden kann, müssen Sie die Hochverfügbarkeit des Replikationsnetzwerkes sicherstellen.
In VMware Umgebungen empfiehlt es sich, immer den VMXNET3 Adapter für die virtuellen Maschinen zu verwenden, da der E1000 Adapter im Host-System nur CPU 0 für die Emulation verwendet. Die Nutzung des VMXNET3 Adapters bietet somit eine deutlich bessere Performance gegenüber dem E1000 Adapter.
Ganz unabhängig von der gewählten virtuellen Netzwerkkonfiguration muss immer sichergestellt werden, dass die Host-System sowohl in der Hardware-seitigen, als auch in virtuellen Netzwerkkonfiguration identisch konfiguriert sind. Die virtuellen Gast-Systeme können schließlich nur zwischen Hosts verschoben werden, die auch die notwendigen Ressourcen (virtuelle Switche, VM Port Groups, etc.) zur Verfügung stellen.
Die Bereitstellung des notwendigen Festplattenspeichers für virtualisierte Exchange Server 2013 Systeme bietet vielfältige Optionen. Die rein physischen Optionen, wie z.B. Bereitstellung von Raw LUNs, die in einem SAN Speicher konfiguriert sind, oder VMDK, VHD/VHDX Dateien im SAN oder im DAS, oder aber die direkte Einbindung der Datastore-Volumes per iSCSI im Gast-Betriebssystem selber, unterliegen den Möglichkeiten und Anforderungen Ihrer Unternehmensumgebung. Manchmal unterliegt die Auswahl des Speichermediums aber auch internen politischen Richtlinien, durch die bestimmt wird, dass ein "teurer" SAN Speicher verwendet werden muss, obwohl dies durch die Anforderungen von Exchange Server 2013 selber gar nicht mehr notwendig ist. Eines der Arguments für die Migration zu Exchange Server 2013 ist die Unterstützung von günstigen JBOD Enclosures, die sehr große Datenspeicher sehr günstig (im Vergleich zu klassischem SAN Speicher) bereitstellen können.
Hier muss eine sehr genaue Abwägung zwischen technischem Vorteil/Nutzen und dem zusätzlichen Aufwand und der zusätzlichen Komplexität in der Umgebung für Speichersubsysteme erfolgen. Es ist meist schwierig, die Einführung einer neuen Technologie nur mit den Anforderungen einer einzigen Applikation zu begründen. Es ist hilfreich zu prüfen, ob nicht auch andere Applikationen, die in naher Zukunft migriert werden sollen (z.B. von SharePoint 2010 auf SharePoint 2013), von dem neuen Speichermedium profitieren können. Eine stärkere strategische Ausrichtung hilft bei der Argumentation sehr.
Zusammenfassend kann man sagen, dass die Virtualisierung eine große Flexibilität im Sizing und im Betrieb einer Exchange Plattform mit sich bringt. Jedoch birgt eine Virtualisierung schnell auch Risiken. Dieses Risiken wirken sich nicht unbedingt auf den sicheren Betrieb von Exchange aus, sondern vielmehr auf die Reaktionszeit, also die Performance der Exchange Umgebung.
Grundsätzlich darf man aber nicht vergessen, dass gemessene Performance nicht gleichzusetzten ist, mit subjektiv gefühlter Performance. Insbesondere Endanwender sind sehr empfindlich und reagieren kritisch, wenn "Ihr" Outlook nicht in der gleichen Zeitspanne startet, wie "gestern". Ähnlich sieht es aus, wenn Nachrichten durch mangelhafte Ressourcenverfügbarkeit zu lange in einer Warteschlange verweilen, bevor sie zugestellt werden. Auch wenn Administratoren wissen, dass E-Mail (oder besser SMTP) ein Warteschlangen-basierende Kommunikation ist, ist dies Endanwendern meist nur sehr schwer zu vermitteln.
Viel Spaß bei der Virtualisierung von Exchange Server 2013.