BARBRI, ein Unternehmen zur Schulungs- und Prüfungsvorbereitung mit Hauptsitz in Dallas, Texas, nutzt Mailscape 365 von ENow zur Überwachung und zum Monitoring der E-Mail Postfächer in Office 365. Das Unternehmen ist seit mehr als 50 Jahren am Markt tätig und einer der führernden Anbieter für Schulungsdienstleistungen.
Durch das Monitoring mit Mailscape 365 erhält das Helpdesk-Team proaktiv Informationen über den Betriebszustand von Exchange Online und potentielle Probleme mit Benutzerpostfächern.
Lesen Sie die ganze Pressemitteilung auf der Website von ENow.
Test Sie Mailscape oder Mailscape 365 unverbindlich für 21 Tage. Mehr über den kostenlosen Test erfahren Sie hier.
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
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.
Exchange Server ist eine der erfolgreichsten Serverlösungen von Microsoft, obwohl das Produkt immer wieder funktionale Lücken hinsichtlich Sicherheit, Archivierung, Datensicherung/Wiederherstellung, Überwachung und Berichterstellung hatte. Einige dieser funktionalen Lücken existieren selbst in der aktuellen Version Exchange Server 2019. Infolgedessen entwickelte sich rund um Exchange Server über die Jahre ein Ökosystem von Softwarelösungen, um diese Lücken zu schließen und den gewünschten Mehrwert zu bieten.
Selbst mit einem Wechsel zu Exchange Online besteht weiterhin Bedarf für eine bessere Überwachung und Berichterstellung. Microsoft bietet für Exchange Online nur einige rudimentäre Ansätze, die Administratoren nicht die Informationen bieten, die wirklich benötigt werden. Diese Informationslücken schließt ENow mit Mailscape 365 und liefert einen umfassenden Einblick in den Betrieb von Exchange Online und Microsoft 365.
ENow Software ist kein Neuling am Markt der Monitoring-Lösungen für Microsoft Serverprodukte. Ich kenne das Unternehmen und die Lösungen bereits seit mehr als zehn Jahren. Mich beeindruckt die Entstehungsgeschichte von ENow. Jay Gundotra, Gründer und Exchange-Geek, startete mit seinem Unternehmen nicht mit dem Anspruch ein Softwareanbieter zu sein. Die erste Lösung entstand durch den Bedarf, den er während seiner Arbeit als Service-Anbieter für Exchange sah. Es fehlte eine Monitoring-Lösung, die alle notwendigen Informationen in einem Dashboard zusammenfasst und so einen schnellen Überblick über den aktuellen Betriebsstatus ermöglicht.
Hieraus entwickelte sich das bekannte OneView-Dashboard des ENow Management Systems, mit dem eine ganze Plattform übersichtlich dargestellt und überwacht werden kann. Rot blinkende Signale und die Möglichkeit des Drill-Downs ermöglichen eine schnelle Identifikation von Problemen. Die Lösung wurde unter der Maßgabe entwickelt, so zu funktionieren, wie ein Administrator denken würde, um ein Problem zu identifizieren und zu beheben. Man muss nur der Spur der roten Ampelsignale folgen, um die Ursache zu finden. Dies Einfacheit ist der Grund, warum Network Operating Center (NOC) zahlreicher Unternehmen auf diese Lösung setzen. Die ENow-Lösung wurde und wird auf der Basis von Feedback aus der Exchange-Community stetig entwickelt. Unternehmen in über 130 Länder auf der ganzen Welt, wie z.B. VMware, Wendy’s und Facebook, vertrauen der Lösung.
Auf ENow und Mailscape bin ich im Jahr 2009, während eines Exchange Migrationsprojektes, gestoßen. Seinerzeit löste die Software das alltägliche Problem des Monitorings von lokalen Exchange Server Plattformen. Über die Jahre hat ENow den Umfang der Monitoring-Lösung weiterentwickelt, um immer komplexere Anforderungen und mögliche Probleme im Betrieb von Exchange Server zu überwachen, z.B. wurde die Lösung um das Monitoring von Active Directory Gesamtstrukturen ergänzt. Es darf nicht vergessen werden, dass Exchange Server eine sehr tolerante Serverlösung ist und in ganz unterschiedlichen Konstellationen betrieben werden kann. Dies birgt naturgemäß besondere Herausforderungen für das Monitoring.
Der Wert einer Plattformüberwachung mit der ENow Monitoring-Lösung wird deutlich, wenn wir uns drei beteiligte Job-Rollen, mit ganz unterschiedlichen Interessen, anschauen. So erkennen Sie vielleicht einen vertrauten Anwendungsfall aus Ihrer eigenen Betriebsumgebung wieder.
In einer lokalen IT-Infrastruktur haben IT- und Exchange-Administratoren meist eine gute Monitoring-Übersicht über Server und Dienste. Das Standard-Monitoring wird, aufgrund fehlender Integration, oft durch zusätzliche Tools ergänzt, um neben einem klassischen System-Monitoring auch ein Applikations-Monitoring zu ermöglichen.
Bei einem Wechsel zu Microsoft 365 und Exchange Online ist die Frustration auf Administrator-Seite groß. Es besteht keine Möglichkeit mehr, sich mal schnell per RDP auf einem Server anzumelden, um ein Problem zu identifizieren und zu beheben. Gleichzeitig ist der Druck unverändert hoch, bei einer Störung das Management und die Mitarbeiter informieren zu müssen. Das Microsoft 365 Admin Center stellt keine zeitnahen Informationen zum aktuellen Dienststatus bereit. Störungen, die früher schnell als Dienst- oder Hardwarestörungen identifiziert werden konnten, verstecken sich nun in einer großen (dunklen) Wolke. Office 365 Störungen können den ganzen Dienst betreffen oder nur Teilbereiche oder einzelne Dienste. In den letzten Jahren haben wir unterschiedliche Ausfälle erlebt, die das Resultat von Azure AD- oder Azure DNS-Problemen waren und die Identitätsverwaltung oder den Zugriff auf die gesamte Microsoft 365-Plattform beeinträchtigten. Andere Ausfälle betrafen nur einzelne Dienste, wie z.B. Microsoft Teams, oder einzelne Komponenten, wie die jüngsten MFA-Ausfälle.
Der obige Screenshot des ENow Dashboards zeigt, dass Microsoft Teams und SharePoint Online für Anwender in Salzburg gestört sind (3), jedoch nicht für Anwender in Wien. Die allgemeine Verfügbarkeit in Office 365 ist nicht gestört (1). Es scheint sich um ein lokales Netzwerkproblem zu handeln (2). Den Status der Dienstverfügbarkeit erkennen Sie auf einen Blick. Für ein international arbeitendes Unternehmen sind rollierende Störungen, bei denen Mitarbeiter einer Region nicht wie gewohnt arbeiten können, während andere Regionen keine Probleme haben, eine besondere Herausforderung. Denn dies stellt keinen direkter Ausfall von Office 365 dar.
In solch einem Fall fragt sich ein IT- oder Exchange-Administrator, „Haben WIR ein Problem, oder ist es ein Microsoft-Problem?“ Viele Überwachungslösungen betrachten nicht alle notwendigen Komponenten einer lokalen IT-Infrastruktur oder haben keine Kenntnis über die technischen Abhängigkeiten der eingesetzten Komponenten, wie z.B. beim Betrieb einer Hybrid-Konfiguration (AD FS, AAD Connect) und den erforderlichen Netzwerkverbindungen. Sie möchten sich nicht in der Situation wiederfinden, in der Sie denken, dass eine Störung durch ein Microsoft 365-Problem ausgelöst wurde, es sich aber in Wirklichkeit um eine Störung in Ihrer lokalen IT-Infrastruktur handelt.
Office 365 und Exchange Online verfügen über kein eigenständiges Monitoring je Mandanten. Bei einer offiziellen Störung gibt es für Administratoren keine Möglichkeit meistens keine schnelle und einfach Lösung, um den Grund der Störung zu ermitteln. Sie können keine Aussage darüber treffen, wer Schuld ist, welche Dienst gerade nicht verfügbar ist und für wen es Auswirkungen hat. Hier hilft ENow bei der Isolierung des Problems durch sog. Remote-Sonden und synthetische Transaktionen. Diese Funktionen imitieren Anwenderzugriffe auf Office 365-Dienste, wie z.B. Microsoft Teams. In einer cloudbasierten Welt benötigen Sie intelligentere Überwachungsfunktionen als eine „Dienst verfügbar/nicht verfügbar“-Lösung. Ebenso wichtig ist, sich nicht nur auf die Cloud-Endpunkte zu konzentrieren.
Die Verfügbarkeit der Office 365-Dienste ist zu einem großen Teil von der Funktionalität der lokalen Active Directory Gesamtstruktur und der Netzwerk-Infrastruktur abhängig. Da die ENow Lösung in Ihrer lokalen Infrastruktur betrieben wird, kann sie genau das leisten. Der Mehrwert liegt darin, dass Sie eine belastbare Aussage über den Grund der Störung abgeben können und sich nicht auf eine „Microsoft ist Schuld“-Begründung zurückziehen müssen, selbst wenn dies sehr bequem ist. Aber was ist, wenn der Fehler nicht bei Microsoft liegt, sondern bei Ihnen? Die Gründen hierfür sind vielfältig, wie z.B. abgelaufenen Zertifikate, ungewöhnlich hohe Netzwerklatenzen, AD FS Authentifizierungsfehler oder Azure AD Connect Synchronisationsprobleme, um nur einige zu nennen. Es ist kein eindimensionales Problem. Die von Ihnen gewählte Überwachungslösung für Office 365 muss mehrdimensional sein und auf die gleiche Weise testen, wie Anwender eine Verbindung zu den verschiedenen Office 365-Diensten herstellen.
Die oben dargestellte Störung signalisiert eine Störung von Microsoft Teams und SharePoint Online. Wenn Sie der Störungssignalisierung im Dashboard folgen, erhalten Sie die notwendige Sicherheit.
DIe Detailinformatiom zeigt, dass eine Störung beim Zugriff auf Microsoft Teams vorliegt.
Sie kennen die Schlagworte „digitaler Arbeitsplatz“, „digitale Transformation“ und all die anderen zu Genüge. Das gemeinsame Ziel ist die Einführung eines modernen Arbeitsplatzes und die umfassend integrierte Nutzung von Office 365. Ihr Unternehmen investiert mit den Abonnementkosten nicht nur in die Cloud-Plattform an sich, sondern auch in die Weiterentwicklung der Mitarbeiter. Daher ist es so wichtig, dass Sie wissen, wie die einzelnen Komponenten der Office 365-Plattform verwendet werden. Und hier spreche ich nicht nur von den Standardauswertungen, die Ihnen z.B. eine Microsoft Teams Nutzung vorgaukeln, nur weil Anwender einmal in dreißig Tagen Microsoft Teams gestartet haben.
Wenn Sie für die Einführung von Office 365 verantwortlich sind, sind Sie davon überzeugt, dass die Kommunikations- und Kollaborationssuite die Zusammenarbeit in Ihrem Unternehmen revolutionieren wird. Der Schlüssel hierzu ist jedoch, dass die Produkte der Office 365-Suite von allen Mitarbeitern angenommen und genutzt werden. Um eine breite Akzeptanz und Nutzung zu erreichen, muss Office 365 planvoll eingeführt und mit angemessenen Lernangeboten begleitet werden. Ein „probiert es einfach aus“-Ansatz wird scheitern. Sie benötigen ausführliche Berichte, wie die Office 365-Plattform von Anwendern genutzt wird. Dies dient auch der Erfolgskontrolle von Schulungen und Lernmaterialien.
Die Standardberichte der Office 365-Plattform geben Ihnen nur rudimentär Auskunft, meist stehen detaillierte Informationen nur per PowerShell zur Verfügung. Administratoren verfügen oftmals über das notwendige Knowhow, um diese Informationen abzurufen. Als Verantwortlicher für die Einführung von Office 365 benötigen Sie meist Hilfe, um die notwendigen Informationen zu erhalten und die Statusberichte für das Management zu erstellen.
Die ENow Mailscape 365 Suite verfügt über Hunderte von integrierten Berichten, die Sie für Ihre individuelle Bedürfnisse anpassen können. Ergänzt wird diese Lösung durch ein zentrales Repository für PowerShell-Skripte und einem Dashboard zur Verwaltung. Sie sehen z.B. nicht nur, ob Microsoft Teams selbst verwendet wurde, sondern auch wie viele Chat-Nachrichten gesendet wurden, wie viel Anrufzeit bereits aus dem Anrufguthaben genutzt wurde oder wie oft das Teilen von Bildschirminhalten eingesetzt wird. Mithilfe dieser Auswertungen stellen Sie schnell fest, ob es ein Problem mit den Schulungen und Schulungsinhalten gibt.
Bei einer einfach zu nutzenden Lösung wie OneDrive erkennen Sie, ob Personen überhaupt Dateien in ihrem persönlichen OneDrive-Speicher ablegen. Wenn dies nicht der Fall ist, ist dies ein Indikator, dass Anwender höchstwahrscheinlich eine Schatten-IT-Lösung wie Dropbox verwenden. Liegt das Problem nun darin, dass sich Anwender mit der neuen OneDrive-Lösung nicht wohlfühlen?
Mit dem Wissen über die Nutzung der Office 365-Suite können Sie proaktiv auf Ihre Schulungen einwirken und so sicherstellen, dass Ihre Mitarbeiter alle bereitgestellten Lösungen nutzen, für die das Unternehmen bezahlt.
Weitere Berichte geben Ihnen Auskunft darüber, welche Apps oder Geräte für den Zugriff auf die Office 365-Dienste verwendet werden. Erfolgt der Postfachzugriff mit Outlook für Desktop, Outlook on the Web oder die Outlook Mobile App? Welches Betriebssystem oder welches Endgerät kommt zum Einsatz? Ähnliche Auswertungen stehen für Microsoft Teams und andere Dienste zur Verfügung. Auf Basis dieser Informationen können Sie entscheiden, ob bestimmte Apps und Geräte in Schulungen stärker berücksichtigt werden müssen. Wenn Sie feststellen, dass mehr Personen iOS- oder Android-Apps für den Zugriff auf Office 365 Dienste verwenden, können Sie Ihren IT-Support für diese Nutzungsszenarien optimieren.
Die Lizenzierung von Office 365 ist ein bisschen wie ein schwarzes Loch und es ist nicht ungewöhnlich, dass ein Unternehmen mehr zahlt, als notwendig ist. Dies können im Einzelfall Tausende von Euros sein.
Genauso wie Nutzungsinformationen, werden Lizenzinformationen in Office 365 nicht sinnvoll dargestellt. Oberflächlich betrachtet, denken Sie möglicherweise, dass Ihre Lizenzierung richtig dimensioniert ist. Stellen Sie sich vor, dass von zugewiesenen 1.000 Microsoft 365 E5-Lizenzen nicht alle inkludierten E5-Funktionen durch die Anwender genutzt werden. Stattdessen wäre eine Microsoft 365 E3-Lizensierung für z.B. 300 Anwender vollkommen ausreichend. Bei einer Preisdifferenz EUR 22,00 je Anwender und Monat, könnten Sie EUR 79.920,00 pro Jahr einsparen, ohne dass sich dies auf die zur Verfügung stehenden Funktionen auswirkt.
Die richtige Lizensierung bietet ein großes Potential zur Kostenoptimierung und ist daher von großem Interesse für Software-Asset-Management Teams. Wenn Sie jedoch für die Einführung von Office 365 verantwortlich sind, möchten Sie die Lizensierung gar nicht erst reduzieren. Sie möchten viel lieber sicherstellen, dass die Anwender die lizensierten Funktionen ausgiebig nutzen.
Ein weiteres Problem sind überlappende Lizenzen. Kennen Sie alle Produkte und Dienste, die in einer E3- oder E5-Lizenz enthalten sind? Wahrscheinlich nicht. Es ist also möglich, dass Sie eine Lizenz für eine Add-On-Funktion kaufen und verwenden, die bereits in der E3- oder E5-Lizenz eines Anwenders enthalten ist? Sie erhalten bei der Zuweisung einer Add-On-Lizenz keinen Warnhinweis, dass diese Funktion dem Anwender bereits zur Verfügung steht. Möglicherweise gibt es bei Ihnen auch Anwender, die Visio Online oder Project Online benötigen, so dass Sie Lizenzen für diese Anwender erwerben. Aber vielleicht gibt es gleichzeitig andere Anwender, denen eine Visio Online- oder Project Online-Lizenz zugewiesen ist, diese aber gar nicht verwenden. Das Auffinden dieser Art von inaktiven Lizenzen ist mit den von Office 365 bereitstellten Tools nicht immer nativ möglich.
Die Berichte der ENow Management Suite bieten eine einfache und auf einen Blick verständliche Möglichkeit, Möglichkeiten zur Kostenoptimierungen zu messen und umzusetzen. Alle Probleme mit der richtigen Dimensionierung von Lizenzen, überlappenden Lizenzen oder der erneuten Bereitstellung nicht verwendeter Lizenzen können mit diesen Berichten gelöst werden. Sie erhalten einen exakten Einblick, wie Ihre Lizenzen in Ihrem Unternehmen verwendet werden. Diese Informationen helfen Ihnen bei Lizenzverhandlungen, ROI- oder TCO-Modelle zu formulieren und bieten reale Einblicke in Ihre digitalen Investitionen.
Der Einrichtungsprozess der ENow Management Suite und Mailscape 365 war sehr einfach. Der Installationsassistent führt Sie durch jeden einzelnen Schritt des Prozesses. Nach der Einrichtung der erforderlichen Dienstkonten für den Zugriff auf Ihren Office 365-Mandanten ist die Lösung betriebsbereit. Die Installationsroutine bietet sogar die Möglichkeit, eine Express-Installation durchzuführen, die weniger Rückfragen zur Installation notwendig macht. Die proaktive Office 365-Überwachung Ihres Mandanten wird innerhalb weniger Minuten aktiviert und die Berichte zur Lizenzverwaltung sind schon kurz nach Abschluss der Installation verfügbar.
Die ENow Management Suite macht mit Mailscape 365 genau das, was es soll. Es bietet eine Überwachung auf einen Blick, die Administratoren dabei hilft, ein Problem schnell zu erkennen und zum eigentlichen Kern des Problems zu gelangen. Hierzu müssen Administratoren nur dem Pfad der „roten Warnmeldungen“ folgen.
Ergänzt wird die Überwachung Ihres Office 365.Mandaten durch die Bereitstellung von aussagekräftigen Berichten, die Ihnen bei der Einführung und Nutzung von Office 365 helfen und sogar Geld sparen können. Sie erhalten eine Lösung, die Ihnen dabei hilft, Ihre tägliche Arbeit ohne unnötige Komplexität zu erledigen, ganz unabhängig davon, ob Sie ein IT-/Exchange- /Office 365-Administrator, für die Einführung moderner Arbeitsplätze verantwortlich oder ein Software-Asset-Manager sind.
Besuchen Sie die Produkt-Website für weitere Informationen: https://www.enowsoftware.com/products/office365-monitoring-and-reporting
Beginnen Sie mit einem 14-Tage Test: https://www.enowsoftware.com/get-started
Foto von Christina Morillo von Pexels
Mit Exchange Version 2013 wurden die sog. Modernen Öffentlichen Ordner (Modern Public Folder) eingeführt. In den vorherigen Produktversionen von Exchange Server erfolgte die Replikation der Öffentlichen Ordner mit einer eigenen Replikationstechnologie. Die öffentlichen Ordner bis einschließlich Exchange Server 2010 bezeichnet man als Legacy Public Folder oder als Öffentliche Ordner alter Bauart.
Im April 2017 habe ich bereits die Herausforderungen aufgezeigt, die bei der Migration von Öffentlichen Ordner innerhalb einer lokalen Exchange Organisation auftauchen. Dieser Blogartikel behandelt die Migration von Legacy Public Foldern zu Exchange Online.
Exchange Online unterstützt die direkte Migration von Legacy Public Foldern aus der lokalen Exchange Organisation zu Modern Public Foldern in Exchange Online. Da es sich hierbei technisch um eine Migration über Exchange Organisationsgrenzen hinweg (sog. Cross-Forest Migration) handelt, ergeben sich ganz eigene Herausforderungen.
Die Postfach-Migration aus einer lokalen Exchange Organisation hin zu Exchange Online erfordert immer die Konfiguration eines Migrationsendpunktes. Über diesen Endpunkt greift Exchange Online auf einen lokal installiert Exchange Server 2016 mit Hybrid Funktion zu.
Das nachfolgende Schaubild zeigt die Zugriffswege für die Migration von Postfächern und die Migration von Öffentlichen Ordnern von Exchange Server 2010 zu Exchange Online. Der Zugriffsweg zur die Migration von Exchange-Postfächern ist grün dargestellt, der für die Migration von Öffentlichen Ordner blau.
Exchange Server 2016 arbeitet bei der Migration von Postfächern als Proxy und nimmt in unserem Beispiel Verschiebeanforderungen von Exchange Online per Exchange Web Service (EWS) unter dem Hostnamen ews.varunagroup.de entgegen. Der Migrationsendpunkt für Exchange-Postfächer kann nicht für die Migration von Legacy Public Foldern verwendet werden. Die Migration der Legacy Public Foldern erfolgt über einen OutlookAnywhere Migrationsendpunkt vom Typ Public Folder. Ein Endpunkt dieses Typs kann im Exchange Admin Center nicht manuell erstellt werden. Die Erstellung erfolgt im Rahmen der Einrichtung des Migrationsbatchs mit Hilfe der Exchange Online Remote PowerShell. Für die Einrichtung des Migrationsendpunktes wird ein Benutzerkonto (Migrationskonto) im lokalen Active Directory benötigt, dass Organisationsadministrator ist.
Wenn Sie den externen OutlookAnywhere Zugriff auf Exchange Server 2010 bereits entfernt haben oder ihn noch nie in Betrieb hatten, so müssen Sie diesen Zugriff konfigurieren. Die externe Verfügbarkeit eines OutlookAnywhere Endpunktes ist für die Migration der Legacy Public Folder zu Exchange Online eine Voraussetzung.
Ein Wort zu E-Mail-aktivierten Öffentlichen Ordnern. E-Mail-aktivierte Öffentliche Ordner hatten in der Vergangenheit ihre Daseinsberechtigung, sind aber in der heutigen Zeit nicht mehr State-of-the-Art. Sie sollten darüber nachdenken, E-Mail-aktivierte Öffentliche Ordner durch eine zeitgemäße Lösung ersetzen. Wenn Sie die Öffentlichen Ordner Hierarchie zu Office 365 migrieren und anschließend zu etwas Neuem wechseln möchten, bringen Sie vielleicht die Funktionen von Microsoft Teams weiter.
Im Beispiel dieses Artikels gab es zu Beginn der Postfach-Migration in der Exchange Organisation E-Mail-aktivierte Öffentlichen Ordner, die mit Hilfe des Scripts Sync-MailPublicFolders.ps1 (Download) zu Office 365 manuell synchronisiert wurden. Dies war erforderlich, damit Anwender mit einem Postfach in Exchange Online E-Mail-Nachrichten an diese Öffentlichen Ordner senden konnten.
Als Teil der Vorbereitungen zur Migration der Öffentlichen Ordner zu Exchange Online wurden Funktionen der E-Mail-aktivierten Ordner in Freigegebene Postfächer migriert. Hierzu gehörte damit auch die Deaktivierung der E-Mail Funktionen der betroffenen Öffentlichen Ordner.
Der Ablauf einer Migration der Öffentlichen Ordner von Exchange Server 2010 zu Exchange Online ist im Grundsatz identisch zur Migration zu Exchange Server 2016 in einer lokalen Exchange Organisation. Der Hauptunterschied liegt in der Konfiguration des Migrationsendpunktes und des Remote-Migrationsbatches.
Die Schritte sind:
# Quota für die Migration ganz aufheben Set-OrganizationConfig -DefaultPublicFolderProhibitPostQuota Unlimited -DefaultPublicFolderIssueWarningQuota Unlimited
# Erste Public Folder Mailbox freigeben Set-Mailbox Mailbox1 -PublicFolder -IsExcludedFromServingHierarchy:$false # Default Public Folder Mailbox für Test-Benutzer setzen Set-Mailbox -Identity JohneDoe@varunagroup.de -DefaultPublicFolderMailbox Mailbox1
# Alle Public Folder Postfächer für den Hierarchie-Zugriff freigeben Set-Mailbox -PublicFolder -IsExcludedFromServingHierarchy:$false # Öffentlichen Ordner Zugriff auf "local" setzen (aus Sicht der Office 365 E-Mail Postfächer) Set-OrganizationConfig -PublicFoldersEnabled Local
Wie bereits erwähnt, wurden alle E-Mail-aktivierten Ordner vor der Migration zu Exchange Online deaktiviert und das Skript zur Synchronisation der E-Mail-aktivierten Öffentlichen Ordner mit Office 365 ausgeführt. Leider führt das Skript nicht alle notwendigen Schritte aus, um die Informationen in Exchange Online korrekt zu entfernen.
Fehlermeldung im Migrationsbatch:
"Error: More than N mail public folders in Active Directory were not linked to any public folder during migration. Mail flow will stop working for these public folders after the migration is finalized. Please check whether these are important"
Sie müssen die nicht mehr vorhanden Ordner manuell mit Hilfe der Exchange Online Remote PowerShell löschen. Mit dem nachfolgenden Beispiel löschen Sie alle E-Mail aktivierten Öffentlichen Ordner, die mit Hilfe des Skriptes Sync-MailPublicFolders.ps1 in Exchange Online erstellt wurden.
# Löschung eines einzelnen ehemals E-Mail-aktivieren Öffentlichen Ordners in Exchange Online Get-MailPublicFolder 'My Mail Public Folder' | Remove-SyncMailPublicFolder # Löschung aller ehemals E-Mail-aktivierten Öffentlichen Ordner in Exchange Online Get-MailPublicFolder -ResultSize Unlimited | Remove-SyncMailPublicFolder
Die Migration von Legacy Public Foldern zu Exchange Online ist nicht schwer. Sie erfordert aber, dass die zu migrierende Hierarchie der Öffentlichen Ordner vorbereitet wird und Ordnernamen keinen unzulässigen Zeichen enthalten. Ebenso muss ein passender OutlookAnywhere Endpunkt aus dem Internet erreichbar sein. Ohne einen OutlookAnywhere Endpunkt und ohne ein berechtigtes Migrationskonto kann der Migrationsbatch von Exchange Online keine Daten kopieren.
Stellen Sie die E-Mail-Aktivierung von Öffentlichen Ordnern in Frage und suchen Sie modernere Lösungen. Eventuell notwendige Umzüge von E-Mail-Adressen müssen vor der Migration der Öffentlichen Ordner abgeschlossen sein.
Planen Sie für die Finalisierung der Migration genügend Zeit ein. Im direkten Vergleich zu lokale durchgeführten Modern Public Folder Migrationen benötigten Finalisierungen von Migrationen zu Exchange Online das Vierfache an Zeit. Bedenken Sie, dass nach einer Umstellung des Public Folder Zugriffes für die Postfachnutzer in Exchange Online es noch mehrere Stunden dauern kann, bis die Konfigurationsänderungen durch Outlook Clients genutzt werden.
Viel Spaß mit modernen Öffentlichen Ordnern.
In ihrem Blogartikel Improving Security - Together hat die Exchange Produktgruppe angekündigt, die unsichere Authentifizierungsmethode Basic Authentication zum 13. Oktober 2020 nicht nur für die Exchange Web Services (EWS) abzuschalten, sondern zusätzlich auch für Exchange ActiveSync (EAS), POP, IMAP und Remote Exchange PowerShell.
Bei der Basic Authentication handelt es sich um eine in die Jahre gekommene Authentifizierungsmethode, die im Vergleich zu modernen Authentifizierungsmethoden Schwächen hat. Diese Schwächen führen dazu, dass diese Authentifizierungsmethode immer wieder von Angreifern verwendet wird, um unberechtigten Zugriff auf Ressourcen zu erlangen. Exchange Online und Azure AD sind, als globale Clouddienste, immens vielen Angriffen dieser Art ausgesetzt.
Die moderne Authentifizierung (Modern Auth), basierend auf OAuth 2.0, bietet im Zusammenspiel mit Multi-Faktor-Authentifizierung (MFA) einen umfassenderen Schutz für den Zugriff auf Exchange Online und andere Cloud-Ressourcen. Diese Art der Authentifizierung ist nicht neu, setzt sich für bestimmte Zugriffsarten aber nur langsam durch. Die Unterstützung für Modern Auth wird bereits seit Office 2013 unterstützt und ist seit Version 2016 nativ in das Produkt integriert.
Für mobile Endgeräte stellt sich die Situation etwas anders dar. In vielen Fällen erfolgt der Zugriff auf Exchange Online Postfächer mit nativen E-Mail-Clients der mobilen Endgeräte statt. Diese verwenden in den meisten Fällen das ActiveSync-Protokoll (EAS). EAS wiederum bedient sich standardmäßig der Basic Authentifizierung und ist daher für die Zukunft nicht mehr das passende Protokoll für den Zugriff auf Exchange Online. Hier ist Outlook Mobile (Android/iOS) die bessere Alternative. Mit Outlook Mobile haben Sie die Möglichkeit, die Authentifizierung der Benutzerkonten zusätzlich mit MFA abzusichern.
Für die Protokolle SMTP, POP und IMAP gibt es eine besondere Herausforderungen. Diese Protokolle unterstützen heute die moderne Authentifizierung (noch) nicht. Für den Zugriff auf Mitarbeiter-Postfächer stellt dies noch keine Problem dar, da dieser Zugriff immer über das Protokoll MAPIoverHTTP erfolgen sollte. Das eigentliche Problem sind all die anderen Applikationen, die Sie gegenwärtig für einen POP/IMAP-Postfachzugriff und SMTP-Mailversand über ein Exchange Online Postfach konfiguriert haben. Hierzu gehören z.B. Ticketsysteme, ERP-Lösungen oder individuell programmierte Line-of-Business-Applikationen (LOB).
Ähnlich sieht es für die Authentifizierung von PowerShell-Skripten aus, die auf einem Ihrer internen Skript-Server ausgeführt werden und Aktionen gegen Exchange Online ausführen. Für die direkte Anmeldung an die Exchange Online PowerShell mit Modern Auth können Sie bereits heute das Exchange Online PowerShell Modul mit MFA oder die Azure Cloud Shell verwenden.
Die Deaktivierung der Basic Authentication für Exchange Online hat direkte Auswirkungen auf die von Ihnen betreute IT-Infrastruktur. Um eine Unterbrechung im Zugriff auf Exchange Online-Ressourcen zu vermeiden, müssen Sie wissen, mit welchen Protokollen Anwender und Applikationen auf Exchange Online-Endpunkte zugreifen. Die Exchange Produktgruppe plant ein Software-Tool zur Auswertung bereitzustellen, dass Sie bei der Analyse der Zugriffsarten unterstützt.
Für den Zugriff auf Exchange Postfächer von Windows Desktops ist die Maßnahme einfach. Wenn Sie noch ältere Windows Desktop Betriebssystem im Unternehmen einsetzen, wechseln Sie auf Windows 10 als Standard-Betriebssystem und migrieren Sie die Office-Installation zu Office 2019 bzw. Office 365 ProPlus.
Nutzen Sie Outlook Mobile für den Zugriff auf Exchange Online Postfächer. Outlook Mobile lässt sich über die gängigen Mobile Device Management (MDM) Lösungen zentral auf mobile Endgeräte verteilen und konfigurieren. Mit Hilfe von Mobile Application Management (MAM) und Conditional Access können Sie die Sicherheit beim mobilen Zugriff auf Exchange Online Postfächer noch weiter erhöhen.
Für automatisierte PowerShell-Skripte wird die Anpassung auf Modern Auth schwieriger. Sie können für die Ausführung der Skripte in der lokalen IT-Infrastruktur das Exchange Online PowerShell Modul mit MFA implementieren. Hierbei müssen Sie allerdings bedenken, dass Skripte mit einer längeren Ausführungszeit in technische Probleme laufen werden. Wenn Ihre Skripte von Timeouts und Skriptverzögerungen, sog. Micro Delays, betroffen sind, müssen Sie die Strategie zur Skriptausführung überdenken und den Skript-Code anpassen. Eventuell ist es vorteilhafter, eine professionelle Softwarelösung zur Ausführung von Skripten einzusetzen, die Modern Auth nativ unterstützt. PowerShell-Skripte, die nur Aktionen gegen Exchange Online oder anderen Office 365 Endpunkten ausführen, können auch in Azure Automation betrieben werden.
Wichtig ist auch noch einmal der Hinweis, dass sich die Deaktivierung der Basic Authentifizierung auf Exchange Online bezieht. Die On-Premises Variante von Exchange Server 2019 ist davon nicht betroffen.
Die Exchange Produktgruppe ist sich der Herausforderungen für die Kunden bewusst. Der Titel des Original-Artikels Improving Security - Together ist mit Bedacht gewählt. Ein besserer Schutz von Exchange Online Postfächern und Ressourcen ist nur möglich, wenn die Erhöhung der Sicherheit gemeinsam, also von Ihnen als Office 365 Kunde und der Exchange Produktgruppe, umgesetzt wird.
Bereiten Sie sich und Ihre IT-Infrastruktur rechtzeitig auf die Abschaltung der Basic Authentication vor. Erstellen Sie einen realistischen Zeitplan für die notwendigen Konfigurationen und Anpassungen, um spätestens im Juli 2020 die Umstellung abgeschlossen zu haben. Es hat sich schon immer bewährt, einen zeitliche Puffer einzuplanen.
Die Erhöhung der Sicherheit geht immer mit Komfortverlust einher. Dieser Komfortverlust ist jedoch zu verschmerzen, wenn man den Sicherheitsgewinn gegenüberstellt.
Viel Spaß mit Exchange Online!
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.