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:

• Client Access
  Diese Rolle stellt alle Endpunkte für Client-Verbindungen zur Verfügung, arbeitet aber als reiner Proxy, da das Rendering für Clients in der Mailbox-Rolle stattfindet
   
• Mailbox
  Diese Rolle wird auch als Back-End Rolle bezeichnet, da sie alle Funktionen für den Exchange Betrieb beinhaltet: Postfachdatenbanken (MBX), Nachrichtenfluss (HUB), Unified Message (UM) und Client Rendering
  
  
• Edge
  Optionale Rolle für den Einsatz in der DMZ als E-Mail Gateway Server zum/vom Internet

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

• Live Migration
  Exchange 2013 Server können mit Live Migration (vMotion bei VMware) zwischen Hypervisor-Hosts verschoben werden. Live Migration kann auch mit Mitgliedsservern einer Database Availability Group (DAG) durchgeführt werden.
   
• Hypervisor HA
  Virtualisierte Exchange Server können mit HA Funktionen der Hypervisor-Plattform, z.B. vSphere HA bei VMware, kombiniert werden.
  Wichtig ist, dass bei den virtualisierten System der Disk State nicht gespeichert und wiederhergestellt wird. Hierbei wird ein System "suspended", auf einen anderen Hypervisor-Host verschoben und wieder "resumed". Dieser Vorgang stellt kein unterstütztes Szenario für Exchange Server 2013 dar. Im Rahmen von vSphere HA wird ein System im ausgeschalteten Zustand ("Power Off") recovered, was einem Kaltstart gleichkommt. Diese Vorgehensweise ist ein unterstütztes Szenario für virtualisierte Exchange Server.
   
• Snapshots
  Die Verwendung von Snapshots ist kein unterstütztes Szenario. Da ein Exchange Server in Abhängigkeit zu zahlreichen externen Systemen und Konfigurationen steht, führt ein zurückgerollter Snapshot zum Verlust von Konfigurationen und Instabilität der gesamten Exchange-Umgebung. Snapshots von virtualisierten Exchange Servern sind kein Mittel für Exchange-Backup und -Restore.
   
• CPU-Verhältnis (Virtuell/Physisch)
  Microsoft und VMware empfehlen ein CPU Core Verhältnis (Virtuell : Physisch) von 1:1. Dies erleichtert grundsätzlich die Planung der Exchange Umgebung. Ein Verhältnis von 2:1 ist möglich, sollte aber nicht überschritten werden. Ebenso ist dringend anzuraten, eine Monitoring-Lösung einzusetzen, um die CPU Auslastung stetig zu protokollieren. Ein Anpassung bzw. Verdichtung der Ressourcen empfiehlt sich erst, nachdem ein Baseline für den Betrieb erstellt wurde.
   
• Speichermedien
  Durch die stark gesunkenen Anforderungen an den Datendurchsatz für Postfachdatenbanken und Protokolldateien (Disk IO) können virtualisierte Exchange System mit einer Vielzahl unterschiedlicher Disksysteme betrieben werden. In der Vergangenheit wurde primär SAN Speicher entweder als DAS oder als virtualisiertes SAN (z.B. HP EVA) verwendet und als RAW Volume eingebunden. Mögliche Arten sind Fiber Channel, iSCSI VMFS, iSCSI PassThrough, iSCSI Initiator im OS, Flat File VHDX. Welche Variante zum Einsatz kommt hängt somit noch stärker von der jeweiligen lokalen Infrastruktur ab. Dynamisch erweiterte Disks sollten aus Performancegründen nicht zum Einsatz kommen. Microsoft unterstützt keine "Thin Disks" für Exchange Datenpartitionen (Postfachdatenbanken, Protokolldateien)
   
• Netzwerkspeicher
  NAS Speicher, also VMDK Dateien, die sich auf NFS Speicher befinden und die im Gastbetriebssystem direkt eingebunden werden, sind nicht von Microsoft unterstützt. Virtuelle VHDX Festplatten, die sich auf SMB 3.0 Speichermedien befinden werden von Hyper-V unterstützt.
   
• Arbeitsspeicher
  Hypervisor-Plattformen unterstützen Funktionen zur dynamischen RAM-Zuweisung oder zum Overcommitment von Ram-Ressourcen. Die sog. Dynamic Memory Funktionen in Hyper-V sind für den Betrieb eines virtualisierten Exchange-Servers nicht unterstützt. Auch die Funktionen zur Verwaltung des Arbeitsspeichers in VMware führen zu einem nicht-performanten Betriebszustand von Exchange. Der Arbeitsspeicher sollte im Rahmen einer festen Reservierung dem System zugewiesen werden.
  Auch hier gilt die Empfehlung, die RAM-Nutzung und -Auslastung mit einer Monitoring-Lösung zu überwachen. Das Verhalten mit und ohne Dynamic Memory lässt sich so auch gut einem A/B-Test unterziehen.

Planung für Exchange Server 2013

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.

• 100% Virtualisierung
  • CAS- und Mailbox-Rolle auf getrennten virtuellen Systemen installiert Ermöglicht die Skalierung von zusätzlichen CAS Systemen getrennt von Mailbox-Servern
  • CAS- und Mailbox-Rolle als Multi-Role System installiert Ermöglicht eine vereinfachte Skalierung mit System-Template und anschließender automatischer Verteilung von Postfächer über alle Mailbox-Server
    
    
• Gemischter Betrieb
  • CAS-Rolle virtualisiert, Mailbox-Rolle als physischer Server Ermöglich das einfach Skalieren von CAS Servern, die physischen Mailbox-Server arbeiten bevorzugt mit DAS Speicher für Postfachdatenbanken. Dieser Ansatz unterstützt den "klassischen" Administrator, der Exchange Server "lieber" physisch betreibt
    
    
• Physischer Betrieb
  • CAS- und Mailbox-Rolle als Multi-Role Server auf einem System Wie bereits beim gemischten Betrieb mit virtualisierter CAS-Rolle sollte auch hier der Exchange Server mit DAS betrieben werden. Durch die HA Funktionen von Exchange ist SAN Speicher entschieden zu teuer.

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.

Links

• Server Virtualization Validation Program, http://www.windowsservercatalog.com/svvp.aspx
• Exchange 2013 Server Role Requirements Calculator v6.3, http://gallery.technet.microsoft.com/office/Exchange-2013-Server-Role-f8a61780
• Ask the Perf Guy: Sizing Exchange 2013 Deployments, http://bit.ly/PerfGuyExchange2013Deployments
• ENow Monitoring und Management Suite, http://www.granikos.eu/de/Mailscape
• PRTG System Moniroting, http://www.paessler.com/prtg
• Microsoft Clustering on VMware vSphere: Guidelines for supported configurations, http://bit.ly/MSClusterOnvSphere
• Licensing Microsoft server products for use in virtual environments, http://bit.ly/ServerVirtualizationLicenseMobility
• Standard Performance Evaluation Corporation (SPEC), http://www.spec.org

Warum gibt es die Preferred Architecture?

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?

• Standardisiert
  Exchange Online bietet eine standardisierte Nutzung von Exchange Server Funktionen im Rahmen des Software-as-a-Service Angebotes von Office 365. Hierbei nutzen Sie nur die Funktionen von Exchange und haben keinerlei direkten Zugriff auf die Server Systeme. Die gesamte Verwaltung des Betriebssystems und das Patchen von Exchange Server führt Microsoft für Sie durch. Sie können sich so ganz auf die Konfiguration Ihrer Exchange Online Organisation oder aber den Hybrid-Verbund mit Ihrer lokalen Exchange Organisation konzentrieren.
   
• Strukturiert
  Die strukturierte Implementierung einer Exchange Server Plattform folgt der Preferred Architecture der Exchange Produktgruppe oder der Product Line Architecture, basierend auf den Empfehlungen und Erkenntnissen von Microsoft Architekten. Eine solche Implementierung ist, ebenso wie die Nutzung von Exchange Online, als Lösung für einen optimalen Betrieb anzusehen. Wie sich die Preferred Architecture im Detail darstellt wird weiter unten beschrieben.
   
• Empfohlen
  Eine On-Premises Exchange Server Implementierung, die den Best Practices folgt, weicht in signifikanten Punkten von der Preferred Architecture ab und bietet trotzdem einen sicheren und stabilen Betrieb. Eine solche Abweichung ist z.B. der Betrieb auf einem Hypervisor, jedoch unter Anwendung der Betriebsparameter für den Betrieb von Exchange Server auf physikalischen Systemen (Stichwort: feste Ressourcenzuweisung). Der Exchange Server Best Practices Analyzer ist eine Click-To-Run Applikation, die direkt aus dem Exchange Admin Center einer On-Premises Implementierung heraus aufgerufen werden kann. Alternativ kann hierzu auch das Exchange Analyzer Script von Paul Cunningham aus der TechNet Gallery verwendet werden.
   
• Unterstützt
  Eine unterstützte Implementierung von Exchange Server weicht in zahlreichen Punkten von der Preferred Architecture ab, bewegt sich aber immer noch im durch Microsoft unterstützten Betrieb. Solch ein unterstützter Betrieb folgt den Exchange Server Systemanforderungen und den Exchange Server Speicherkonfigurationsoptionen. Diese Art der Implementierung ist als absolutes Mindestmaß anzusehen.
   
• Funktioniert (irgendwie)
  Natürlich kann man Exchange Server auch irgendwie zum Laufen bringen. Dies ist die letzte Kategorie. In diese Kategorie fallen Einzelserver Implementierungen unter Verwendung von redundanten Speichersystemen oder der grundsätzlich Betrieb von Exchange Server mit nicht unterstützten Speichersystemen (siehe Exchange Server Speicherkonfigurationsoptionen). In diesem Bereich fallen aber auch Exchange Server Implementierung auf AWS oder Microsoft Azure ohne Premium Storage. Ihre produktive Exchange Server Plattform sollte nicht zu dieser letzten Kategorie gehören, da Sie ansonsten ein unnötig hohes Betriebsrisiko eingehen.

Was ist die Preferred Architecture?

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:

• Namensraum-Design
• Rechenzentrumsdesign
• Server-Design
• DAG-Design

Namensraum-Design

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:

1. AutoDiscover Endpunkt: autodiscover.varunagroup.de
2. Client Endpunkt für alle Exchange Dienste: mail.varunagroup.de
3. Office Online Server Endpunkt Rechenzentrum A: oos-a.varunagroup.de
4. Office Online Server Endpunkt Rechenzentrum B: oos-b.varunagroup.de

Rechenzentrumsdesign

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:

• Die Funktionen für einen ausfallsicheren Betrieb des E-Mail Transports mit Shadow Redundancy und Saftety Net
• Der Active Directory Design Empfehlung folgend müssen Netzwerkesegmente mit einer Gesamtlaufzeit von mehr als 10ms in separaten Active Directory Site platziert werden

Server-Design

In der Preferred Architecture werden alle Exchange Server mit Postfachrolle als physikalische Systeme betrieben. Die Hauptgründe hierfür sind:

• Jeder Server ist für eine 80% Auslastung bei größtmöglichem Ausfallszenario berechnet
• Virtualisierung stellt eine zusätzliche Komplexität im Falle einer Wiederherstellung dar, die keinerlei Vorteil bringt (siehe auch Hauptgrundsatz von Exchange Server)

Die physikalischen Server, die für eine Preferred Architecture Implementierung verwendet werden, haben keine allzu besonderen Anforderungen. Solch ein Standard-Server besteht aus:

• 2HE Server, Dual-Sockel mit 20-24 Prozessorkernen
• Maximal 192GB Arbeitsspeicher
• Festplattencontroller mit Batterie-abgesichertem Schreib-Cache
• 12 oder mehr Festplatteneinschübe im Servergehäuse

Die weiteren Konfigurationen des Servers sind:

• Einzelner RAID1 Verbund aus zwei Festplatten für das Betriebssystem, Exchange Server Installation, Protokolldateien und Transportdatenbanken
• Alle weiteren SAS Festplatten sind als JBOD konfiguriert
• Dateisystem für Datenlaufwerke ist ReFS
• Schutz der Daten durch BitLocker Festplattenverschlüsselung
• Absicherung gegen Festplattenausfall durch DAG AutoReseed

DAG-Design

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. 

DAG Netzwerkdesign

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.

Witness Server

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.

Zusammenfassung

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

• PA | Preferred Architecture
• PLA | Product Line Architecture

Links

• The Exchange 2016 Preferred Architecture
• Introducing the Microsoft Product Line Architecture
• Exchange Server 2016 Architecture
• BRK3158 - Do Exchange Right Or Move to Office 365

Viel Spaß beim Betrieb von Exchange Server.

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

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.

Job-Rollen und Herausforderungen

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.

Der IT- / Exchange- / Office 365-Administrator

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.

Der IT- / Exchange- / Office 365-Administrator mit ENow Mailscape 365

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.

Verantwortlicher zur Einführung des modernen digitatlen Arbeitsplatzes

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.

Verantwortlicher zur Einführung des modernen digitalten Arbeitsplatzes mit ENow Mailscape 365

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.

Der Software-Asset-Manager

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.

Der Software-Asset-Manager mit ENow Mailscape 365

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.

Installation und Konfiguration von Mailscape 365

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.

Zusammenfassung

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

Die Migration von E-Mail Postfächern von alternativen E-Mail Servern, wie z.B. Lotus Notes, zu Office 365 ist über das Protokoll IMAP möglich. Die Möglichkeit zur Datenmigration ist in das Office 365 Admin Center implementiert. Über den Menüpunkt Datenmigration können Office 365 Administratoren Postfach-Migrationen zu Office 365 starten. Hierbei werden im Hintergrund die notwendigen Konfigurationen in Exchange Online vorgenommen.

Die nachfolgenden Schritte beschreiben die Migration von Postfächern von einem E-Mail Server mit einer IMAP-Migration, beginnend mit dem Hinzufügen einer neuen Domäne zu Office 365. Für die Einrichtung der IMAP-Migration ist keine vollständige DNS-Konfiguration der Domäne erforderlich. Die Validierung der neuen Domäne ist ausreichend.

An welchem Schritt Sie nun die DNS-Einträge für die MX Ressource Records umstellen, ist Ihnen überlassen und hängt vom Migrationsszenario ab. Sollte die betroffene Domäne weiterhin aktiv für die E-Mail Zustellung verwendet werden, so empfehle ich ein Umstellung der MX-Einträge direkt nach Einrichtung aller Postfächer in Office 365.

Voraussetzungen

Für eine erfolgreiche Migration sind folgende Voraussetzungen notwendig

• Adminkonto auf dem IMAP-Server, um den IMAP-Endpunkt für den Zugriff in Office 365 (Exchange Online) zu konfigurieren
  • E-Mail Adresse und Kennwort
• Liste der zu migrierenden IMAP-Benutzerpostfächer für
  • Anlage neuer Office 365 Benutzer mit zugewiesener Office 365 Lizenz, die einen Exchange Plan enthält
  • IMAP E-Mail-Adresse und Benutzerkennwort zur Synchronisation der Postfachdaten
• Erreichbarkeit des IMAP Endpunktes per TCP 993 aus dem Internet
• Umstellung der MX DNS Ressource Records zur Umstellung der E-Mail Zustellung

Hinzufügen der Domäne zu Office 365

In den folgenden Schritten wird die Domäne azure-usergroup.de als neue Domäne zu einem Office 365 Tenant hinzugefügt.

Schritt 1

Rufen Sie im Office 365 Admin Center den Menüpunkt Setup > Domänen auf und klicken Sie auf Domäne hinzufügen, um den Wizard für eine neue Domäne zu starten.

Geben Sie den Domänennamen ein und klicken Sie auf Weiter.

Schritt 2

Es ist erforderlich, dass Sie die Eigentümerschaft für die Domäne, die Sie hinzufügen möchten, nachweisen. HIerzu stehen Ihnen drei Möglichkeiten zur Verfügung.

1. Validierung mit Hilfe eines TXT Resource Record Eintrages in der Internet DNS Zone der hinzuzufügenden Domäne
2. Validierung mit Hilfe eines MX Resource Record Eintrages in der Internet DNS Zone der hinzuzufügenden Domäne
3. Validierung mit Hilfe eines per E-Mail zu gesandten Codes - Diese Methode steht nur zur Verfügung und wird nur dann angezeigt, wenn die entsprechenden Daten in der DNS Zone hinterlegt sind

Kopieren Sie den TXT-Wert, im aktuellen Beispiel MS=ms81514861 und tragen Sie diesen als Wert für den TXT Resource Record ein.

Je nach DNS Anbieter, kann es mehrere Minuten dauern, bis der Eintrag für Server von Microsoft abrufbar ist. Bei einigen DNS Anbietern kann dies bis zu 24 Stunden in Anspruich nehmen. Wenn Sie bei solch einem Anbieter Ihre DNS Zonen pflegen, sollten Sie über einen Wechsel nachdenken.

Klicken Sie auf Überprüfen, um den TXT Resource Record Eintrag prüfen zu lassen. Wenn der Eintrag erfolgreich geprüft wurde, gelangen Sie zum nächsten Schritt.

Schritt 3

Da Sie die DNS Einträge für Ihre Domäne selber veralten, wählen Sie den Punkt Ich verwalte meine eigenen DNS-Einträge aus und klicken Sie auf Weiter.

Schritt 4

Die Migration der IMAP-Postfachdaten erfordert keine Anpassung der DNS-Einträge für Ihre Domäne. Diese sind erst erforderlich, wenn Sie die Office 365 Dienste bereitstellen und die E-Mail Zustellung zu Exchange Online Protection umstellen möchten.

Wählen Sie die Checkbox am Ende der Seite, um die Aktualisierung der DNS-Einstellungen auszulassen und klicken Sie auf Überspringen. 

Schritt 5

Damit ist die Ersteinrichtung der neuen Domäne in Office 365 abgeschlossen.

Klicken Sie auf Fertig stellen.

IMAP Postfach-Migration 

Nachdem die neue Domäne erfolgreich zu Office 365 hinzugefügt wurde, kann mit der IMAP Migration begonnen werden.

Zur geführten IMAP-Datenmigration zu Office 365 gelangen Sie über den Menüpunkt Setup > Datenmigration.

Einrichtung Benutzerkonten

Vor der Einrichtung der IMAP-Datenmigration über das Office 365 Admin Center müssen Sie die Benutzer in Office 365 anlegen, einen Benutzernamen mit der zu migrierenden Domäne vergeben und eine Office 365 Lizenz zuweisen. Durch diese Zuweisung wird das erforderliche Ziel-Postfach für die Datenmigration erstellt. Der Benutzername in Office 365 kann vom Benutzernamen auf IMAP-Quellseite abweichen.

Im folgenden Beispiel sehen Sie die Erstellung eines Benutzers unter Verwendung der neu hinzugefügten Domäne. Diese Adresse ist sowohl der Office 365 Anmeldename, als auch die neue primäre E-Mail Adresse des Benutzers. 

Optional können Sie neue Benutzer natürlich auch mit Hilfe eines CSV-Datei Imports erstellen.

Schritt 1 : Einrichtung Datenmigration

Im Bereich der Datenmigration bietet Microsoft eine Unterstützung für gängige E-Mail Plattformen an. Die allgemeine E-Mail Datenmigration mit IMAP verbirgt sich unter dem Auswahlpunkt Weitere E-Mail-Quellen.    

Geben Sie den IMAP-Servernamen, den IMAP-Port und die verwendete Sicherheitsmethode an. Eine IMAP-Verbindung ohne Verbindungsverschlüsselung wird nicht unterstützt.

Tragen Sie die E-Mail Adresse des IMAP-Administratorkontos und das dazugehörige Kennwort ein. Klicken Sie anschließend auf Speichern. 

Schritt 2: Start der IMAP-Migration

Wählen Sie das Office 365 Ziel-Konto aus und geben Sie die passende E-Mail Adresse des Quell-Postfaches an. Nach Eingabe der dazugehörigen Kennwortes wird die IMAP-Verbindung zum Postfach überprüft. Wiederholen Sie diesen Schritt für jedes zu migrierende Postfach.

Nach der erfolgreichen Überprüfung des IMAP-Zugriffes können Sie die Migration der Postfachinhalte durch einen Klick auf Migration starten auslösen.

Nach dem Start der Migration erfolgt eine Rückmeldung im Office 365 Admin-Center, dass die Migration in Bearbeitung ist. 

Springen Sie zu Schritt 3, um das nachfolgende Exchange Online Intermezzo zu überspringen.

Intermezzo 1: IMAP-Migration und Exchange Online

Natürlich führt nicht das Office 365 Admin-Center die Migration der Postfächer durch, sondern Exchange Online. Das Office 365 Admin-Center übernimmt die Konfiguration des Migrationsendpunktes, die Erstellung und die Steuerung des Migrationsbatches. Aber wie sieht solch eine erstelle Konfiguration in Exchange Online aus?

Schauen wir uns die Migrationsendpunkte im Exchange Online Admin-Center (EAC) genauer an. Sie finden die Konfiguration der Migrationsendpunkte in der EAC unter:

Empfänger > Migration > ... > Migrationsendpunkte

In der Übersicht der Migrationsendpunkte wurde ein neuer Endpunkt vom Typ IMAP erstellt.

Die Übersicht der Migrationsbatche zeigt den durch das Office 365 Admin-Center konfigurierten Batch und man erkennt, dass in diesem Batch ein Postfach enthalten ist, jedoch noch nicht synchronisiert wurde.

Wählen Sie das IMAP_Batch in der Übersichtsliste aus, um im rechten Fenster die Zusammenfassung des Batches anzuzeigen. Man sieht z.B. die Richtung der Migration (Onboarding) und den aktuellen Gesamtstatus des Batches (Synchronisierung). Hier finden Sie auch Informationen zur zeitlichen Dauer der Migration.

Klicken Sie unterhalb von Postfachstatus auf Details anzeigen, um sich die Liste der im Batch konfigurierten Postfächer und deren Details anzeigen zu lassen. 

Aber nun zurück zum Office 365 Admin-Center.

Schritt 3: Synchronisierte Postfächer

Nachdem im Hintergrund der Migrationsendpunkt in Exchange Online eingerichtet und das Migrationsbatch erstellt wurde, gilt es zu warten. Exchange Online verarbeitet Migrationsbatche in Abhängigkeit der aktuellen Serverlast. Das bedeutet, dass die Einrichtung und der Start einer Migration nicht gleichzusetzen ist mit dem Start der Ausführung. 

Sobald die Erstsynchronisierung abgeschlossen ist, wird das IMAP-Postfach alle 24 Stunden automatisch synchronisiert. Im Office 365 Admin-Center wird im Kopftext zwar angezeigt, dass die Migration erfolgreich abgeschlossen ist, dies ist aber nicht korrekt.   

Dies wird im nächsten Exchange Online Intermezzo deutlich. Springen Sie zu Schritt 4, wenn Sie die IMAP-Migration abgeschliessen möchten.

Intermezzo 2: Status des IMAP-Migrationbatch

In der Übersicht der Exchange Online Migrationsbatche wird deutlich angezeigt, dass das Batch synchronisierte, aber keine finalisierten (abgeschlossenen) Postfächer enthält.

Schritt 4: IMAP-Migration beenden

Über das Office 365 Admin-Center können Sie die IMAP-Migration für jeden Benutzer getrennt beenden. Hierzu wählen Sie einen Benutzer aus, dessen Postfach im Status Synchronisiert ist und klicken auf Migration beenden. Nach der Bestätigung mit Ja wird das ausgewählte Postfach innerhalb des Migrationsbatches finalisiert.

Das bedeutet, dass für diesen Bentuzer eine letzte IMAP-Synchronisierung durchgeführt wird und dieser Benutzer nach Abschluss der Synchronisierung aus dem Migrationsbatch entfernt wird. Alle im Batch verbleibenden Postfächer werden weiterhin alle 24 Stunden synchronisiert.

Wenn kein Postfach mehr Migrationsbatch enthalten ist, haben Sie die Möglichkeit, neue Benutzer auszuwählen und eine Migration zu starten. 

Über die Schaltfläche Verbindung schließen wird die Information über eine laufenden IMAP-Migration aus dem Office 365 Admin-Center entfernt. Nach dem Schließen der Verbindung erreichen Sie über den Menüpunkt Datenmigration die Einstiegsseite der Datenmigration, wie in Schritt 1 beschrieben.

Nachdem alle IMAP-Postfächer zu Office 365 migriert wurden, können Sie mit dem Rückbau der Postfächer auf den Quellsystemen beginnen. 

Intermezzo 3: Exchange Online und der leere IMAP-Migrationbatch

Nach dem Beenden der IMAP-Migrationen und dem Schließen der Verbindung über das Office 365 Admin-Center verbleibt ein leerer IMAP-Migrationsbatch in Exchange Online. Diesen können Sie bedenkenlos über das Papierkorbsymbol löschen. 

Links

• Exchange Online Admin-Center
• Wie funktioniert eine IMAP-Migration

Sie haben Fragen zur IMAP Migration zu Office 365? Nutzen Sie bitte die Kommentarfunktion dieses Blogbeitrages.

Viel Spaß mit Office 365!

Vom 4. - 8. November fand die diesjährige Microsoft Ignite Konferenz statt. Ein großes Thema war natürlich auch der Hybrid Betrieb von Exchange Server mit Exchange Online und die neuen Funktionen für Outlook für Desktop, Outlook für Mac, Outlook Mobile und Outlook on the Web..

Die folgenden Liste bietet einen Überblick über die wichtigsten Sessions zu diesen Themen.

Der jeweilige Link führt Sie zu den detaillierten Session-Informationen, inklusive der Session-Aufzeichnung und PowerPoint-Präsentation, falls vorhanden. Hinter jedem Titel ist der Themenlevel für die Zielgruppe vermerkt.
 

• BRK2002 | There is a new Outlook on the web: See what's new, fresh, and exciting | Intermediate (200)
  In dieser Session erfahren Sie, welche neuen AI-gestützten Funktionen in Outlook on the Web integriert wurden und welche Sicherheitsfunktionen demnächst zur Verfügung stehen, um Postfachanwender und -daten noch besser zu schützen.
   
• BRK2003 | Get ahead with Outlook mobile: Intelligent technology that helps you stay on top of your day | Intermediate (200)
  Informieren Sie sich in dieser Session über die neuen Funktionen, die nur in Outlook für iOS und Android verfügbar sind. Werfen Sie einen kurzen Blick auf die zukünftigen Funktionen von Outlook Mobile. Hierzu gehören u.a. die Integration in Microsoft-Teams und AI-gesteuerte Möglichkeiten zur Interaktion mit Ihrem persönlichen Posteingang.
   
• BRK2005 | Outlook for Mac - re-invented | Intermediate (200)
  Outlook für Mac erfreut sich großer Beliebtheit. Microsoft hat eine neue Version entwickelt, die aktuell für Testbenutzer zur verfügung steht. Erfahren Sie in dieser Session mehr über die nächste Version von Outlook für Mac.
   
• BRK2058 | Deploy Office 365 groups at scale to power Microsoft Teams, Outlook, Yammer, and SharePoint | Intermediate (200)
  Wie können Sie Office 365 Gruppen effektiv verwalten und damit die Akzeptanz und Netzung von Teamwork-Applikation fördern? In dieser Session werden Best Practices aus unterschiedlien Unternehmen vorgestellt. An Anwendungsbeispielen wird Ihnen gezeigt, wie Sie mit Office 365 Gruppen die Sicherheit und Datenverwaltung verbessern können.
   
• BRK2090 | Will Microsoft Teams take over from email? | Intermediate (200)
  Einige sagen voraus, dass Microsoft Teams E-Mails in großen Organisationen ersetzen wird. Es ist sicher richtig, dass Microsoft Teams den Austausch von Informationen zwischen internen Anwendern und externen Partnern vereinfacht. Schwieriger wird es jedoch, wenn die externe Kommunikation im Mittelpunkt steht. In dieser Sitzung wird erläutert, wie eine Bereitstellung von Microsoft Teams angegangen wird, wenn Ihre Organisation Exchange Server und Outlook seit vielen Jahren verwendet.
   
• BRK3012 | Exchange hybrid: Advanced scenarios, roadmap, and real-world stories | Advanced (300)
  Der Microsoft Exchange-Hybridagent ist seit Beginn des Sommers für alle Kunden verfügbar und beseitigt einen wichtigen Blocker für Kunden, die eine kompakte Konfiguration für Hybridszenarien in ihren Umgebungen verwenden wollen. In dieser Session werden bewährte Methoden für die Verwendung der Hybridkonfiguration zum Verschieben von lokalen Exchange-Postfächern in die Cloud gezeigt. Zusätzlich erfahren Sie, wie sich Microsoft Hybridkonfigurationen in der Zukunft vorstellt und wie sich komplexere Organisationskonfigurationen, wie z.B. bei Unternehmensübernahmen, realisieren lassen.
   
• BRK3013 | Modern Exchange IT admin experiences | Advanced (300)
  In dieser Session erhalten Sie einen Einblick, wie das in die Jahre gekommene Exchange Admin Center (EAC) in die Neuzeit überführt wird. Ebenso wird gezeigt warum es neue und leistungsstärkere PowerShell Cmdlets zur verwaltung von Exchange Online gibt.
   
• BRK3144 | The MVP guide to Office 365 security, Exchange Online edition | Advanced (300)
  In dieser Dession erfahren Sie, wie Microsoft Advanced Threat Protection (ATP) Ihnen hilft, sich vor modernen E-mail-basierten Bedrohungsszenarien zu schützen. Zusätzlich wird gezeigt, wie Sie mit DMARC, DKIM und SPF die E-mail-Sicherheit noch weiter erhöhen können.
   
• BRK3248 | Securing Exchange Online from modern threats | Advanced (300)
  E-Mails gibt es schon seit langer Zeit und sie sind immer noch ein wichtiges Medium für die Zusammenarbeit am modernen Arbeitsplatz. Selbst nach all den Jahren ist E-Mail immer noch ein vorrangiges Ziel für Angreifer und eine sehr effektive Möglichkeit um Ihre Daten und Ihr Geld zu stehlen. In dieser Session wird gezeigt, wie Aktionen von Administratoren, Partnern und interne Mitarbeitern zu Datenverletzungen in Exchange Online führen und wie externe Angreifer Produktfunktionen ausnutzen. Natürlich wird auch gezeigt, was Sie tun können, um solche Angriffe festzustellen und sie zu verhindern.
   
• BRK3311 | Outlook mobile: The gold standard for secure communications in the enterprise | Advanced (300)
  Outlook für iOS und Android ermöglicht die Trennung von Arbeits- und persönlichen Daten, auch ohne Geräteregistrierung. Stellen Sie die Produktivität Ihrer Anwender und gleichzeitig die Sicherheit Ihrer Daten sicher. Durch die zentrale Verwaltung der mobilen Einstellen legen Sie fest, welche Daten zwischen mobilen Anwendungen übertragen werden können und welche nicht. Erfahren Sie außerdem mehr über zukünftigen Funktionen von Outlook Mobile, wie z.B. den Schutz vertraulicher Daten durch App-Konfiguration und -Schutzfunktionen, die Vertraulichkeitskennzeichnung von Microsoft Information Protection und S/MIME für mobile Endgeräte.
   
• THR2008 | You do meetings? So do we! Come see new meeting features in Outlook on the web! | Intermediate (200)
  In dieser Theater-Session erfahren Sie, welche neue Funktionen in Outlook on the Web Ihnen helfen, einfach und schnell eine Besprechung zu planen. Erfahren Sie, wie Outlook eine Besprechungszeit empfehlen kann und wie Sie schnell eine Besprechung über die Kalenderoberfläche erstellen können. Ebenso wird gezeigt, wie Sie bei der Planung der Besprechung mit Informationen aus Meeting Insights unterstützen werden, um den richtigen Raum für die Besprechung zu finden.
   
• THR2017 | Contact management in Microsoft Outlook | Intermediate (200)
  In dieser Theater-Sitzung werden Ihnen gezeigt, wie Sie über Ihre Outlook-Kontakte mit den Menschen in Ihrem Arbeits- und Privatleben in Verbindung bleiben. Ebenso wird gezeigt, welche Funktionen zukünftig zur Verwaltung und Nutzung der Kontakte aussehen wird. Der Schwerpunkt liegt hierbei auf Outlook Mobile.
   
• THR2025 | A new way to manage your inbox | Intermediate (200)
  Auf Basis von AI-Auswertungen weiß Outlook wie Sie mit anderen Personen in Verbinding stehen und kann Ihnen so dabei helfen, die Kommunikation mit wichten Personen aufrechtzuerhalten und zu organisieren. Diese Theater-Session zeigt, wie Ihnen diese Funktionen dabei helfen, sich wieder auf die wichtigen Dinge zu konzentrieren.
   
• THR2252 | How Microsoft manages its own employee Office 365 tenancy | Intermediate (200)
  In dieser Theater-Sitzung geben Experten von Microsoft Core Services Engineering und Operations (CSEO) - die Experten, die die Microsoft-Lösungen erstellen, bereitstellen und betreiben - Auskunft darüber, wie der eigene Office 365-Tenant in Microsoft Exchange, Teams und SharePoint verwaltet wird.
   
• THR3003 | New, fast, and reliable Exchange Online PowerShell cmdlets | Advanced (300)
  Für Exchange Online stehen neuen PowerShell-Cmdlets zur verfügung, mit denen Probleme in Bezug auf Leistung, Verbindungstrennung und -zeitüberschreitung behoben werden, die bisher Administratoren bei der Verwaltung ihrer EXO-Umgebung beeinträchtigt haben. Erfahren Sie in dieser Theater-Session, wie Sie die neuen Cmdlets nutzen können, um Produktivitätssteigerungen zu erzielen.
   
• THR3034 | Twenty minutes to a secure environment | Advanced (300)
  Die Legacy-Authentifizierung ist der beste Freund eines Angreifers. In dieser Theater-Session erfahren Sie, wie Sie mit moderner Authentifizierung in der Cloud und hybrider moderner Authentifizierung für lokale Umgebungen Ihre Daten besser schützen können.

Legende

TK = Technical Keynote
THR = Theater Session (20 Minuten)
BRK = Breakout Session (45 Minuten)

Nutzen Sie für Fragen zu den einzelnen Sessions gerne direkt die Kommentarmöglichkeit unterhalb Sessionbeschreibung. Hierzu ist allerdings eine Anmeldung erforderlich,

Für Fragen rund um Exchange, Exchange Online und Outlook stehen Ihnen die Conversation Spaces der Tech Community zur Verfügung:

• Conversation Spaces Exchange
• Conversation Spaces Outlook

Viel Spaß mit Microsoft 365, Exchange Online und Outlook.

Sie benötigen Hilfe bei der Entscheidung für oder gegen einen Wechsel zu Office 365 oder Microsoft 365? Unser Microsoft Cloud Workshop hilft Ihnen, die für Ihr Unternehmen passenden Entscheidungen zu treffen. Melden Sie sich bei uns: info@granikos.eu

Am 24. Juli 2018 wurde die Preview Version von Exchange Server 2019 veröffentlicht. Exchange Server 2019 ist eine Weiterentwicklung von Exchange Server 2016 und somit bereits die dritte Version moderner Exchange Server. Wie schon die Vorversionen profitiert auch Exchange Server 2019 von den Entwicklungen in Office 365. Naturgemäß werden wir aber nicht alle Funktionen, die Exchange Online bietet, in der On-Premises Variante von Exchange Server zur Verfügung haben. Ebenso können wir, wie die Erfahrung der letzten beiden Versionen gezeigt hat, davon ausgehen, dass mit der Veröffentlichung der RTM Version noch nicht alle angekündigten Funktionen im Produkt aktiv sind. Vielmehr wird der Funktionsumfang mit den nachfolgenden Kumulativen Aktualisierungen stetig erweitert.

Lohnt sich ein Wechsel?

Aber was hat uns Exchange Server 2019 anzubieten und warum sollte man auf die neue Version wechseln? Werfen wir einen Blick auf die Unterschiede zwischen Exchange Server 2019 und den Vorversionen.

Exchange Server und Windows Server Core

Die wichtigste Neuerung in Exchange Server 2019 ergibt sich für den Betrieb des Produktes. Endlich ist es möglich, Exchange Server auf Windows Server Core zu betreiben. Durch den Verzicht auf eine Betriebssystemvariante mit grafischer Benutzeroberfläche (GUI) wird die potentielle Angriffsoberfläche stark reduziert. Ich empfehle den Einsatz von Exchange Server auf Windows Server 2019 Core, um die maximale Sicherheit für den Betrieb von Exchange Server zu erreichen. Diese Möglichkeit steht uns allerdings erst zur Verfügung, sobald Windows Server 2019 veröffentlicht wurde. Die aktuelle Preview Version von Exchange Server 2019 erlaubt daher die Installation auf Windows Server 2016 und Windows Server 2016 Core. Ob dies auch noch für die RTM Version von Exchange Server 2019 gelten wird, bleibt abzuwarten. Auf jeden Fall sollte Ihnen der Einsatz von Windows Server Core Varianten keine Angst machen, da Sie mit dem Windows Admin Center eine sehr gute Web-Verwaltungsoberfläche zur Verfügung haben.

Prozessor und Arbeitsspeicher

Nach der Sicherheit im Betrieb ist die Leistungsfähigkeit von Exchange Server immer wieder ein Thema. Mit jeder Produktversion hat das Exchange Team weitere Leistungssteigerungen ermöglicht. Ob Sie von diesen Verbesserungen immer profitiert haben, hängt immer davon ab, wie Sie Exchange Server implementiert haben.

Auch für Betrieb von Exchange Server 2019 gelten die Empfehlungen für die Preferred Architecture. Wie Sie sicher wissen, empfiehlt das Produkt Team den Betrieb von Exchange Server auf echter Hardware. Der Hauptgrund für diese Empfehlung ist, dass die Hochverfügbarkeit auf Applikationsebene (Stichwort DAG) realisiert ist und ein Hypervisor nur die Komplexität erhöht, ohne einen echten Nutzen zu bieten. Die nächste Version von Exchange Server unterstützt Serversystem mit bis zu 48 Prozessor-Cores und 256GB Arbeitsspeicher. Bei einem virtualisierten Betrieb von Exchange Server, unabhängig von der CPU- und Arbeitsspeicherkonfiguration, müssen Sie sowohl die Prozessor-Cores als auch den Arbeitsspeicher als fest reservierte Ressourcen konfigurieren. An dieser Anforderung ändert sich mit Exchange Server 2019 nichts.

SSD Cache-Speicher

In den letzten Jahren sind Postfächer immer größer geworden und damit auch der benötigte Festplattenspeicher. Um nun eine weitere Leistungssteigerung erreichen zu können, bietet Exchange Server 2019 einen SSD basierten Cache-Speicher an. Wie bei den HDDs kommen bei den SSDs kostengünstige Komponenten zum Einsatz, um ein gutes Kosten-/Nutzen-Verhältnis zu gewährleisten. Dieser Cache-Speicher steht in der Preview Version von Exchange Server 2019 leider noch nicht zur Verfügung.

Die Suche

Die bisher in Exchange Server verwendete Suchfunktion basierte auf der FAST-Engine und hat so manchem Exchange Administrator schlaflose Nächte bereitet. Im Blog-Artikel des Exchange-Teams wird nun die Integration einer Suchmaschine mit Bing-Technologie angekündigt. Zum einen ist es gut, die FAST-Suche loszuwerden und sich nicht mehr um korrupte Suchindizes kümmern zu müssen, zum anderen werden einige Leser sicher bei dem Begriff “Bing-Technologie” zusammenzucken. Die im Web verfügbare Bing-Suchmaschine hat, je nach Land, eine sehr unterschiedliche Wahrnehmung hinsichtlich der Qualität der Suchergebnisse. Im Zusammenhang mit Exchange Server liegt der Schwerpunkt aber weniger auf dem Wort “Bing” sondern auf dem Begriff “Bing-Technologie”. Der entscheidende Vorteil der neuen Suche ist, dass die Speicherung der Metadaten und Indizes nicht mehr in einer separaten Ordnerstruktur je Server gespeichert wird, sondern in der jeweiligen Postfachdatenbank. Damit erfolgt die Synchronisierung dieser Informationen mit Hilfe des normalen Log-Shipping-Mechanismus. Dieser technologische Kniff ermöglicht eine im Falle eines Switch- oder Fail-Overs eine noch schnellere Aktivierung einer passiven Datenbankkopie. Durch die Speicherung in der Datenbank sind die Suchinformationen somit auch automatisch Bestandteil einer Datensicherung.

Für Anwender

Als neue Funktionen für Anwender wird es hauptsächlich Änderungen im Bereich der Kalenderfunktionen und der Freigabe von Kalenderinformationen für Dritte geben. Eine wichtige Funktion, die ihren Weg aus Exchange Online zu Exchange 2019 findet, ist "DoNotForward". Mit dieser Funktion kann eine Weiterleitung einer Nachricht, und damit z.B. auch von Termineinladungen, an weitere Empfänger unterbunden werden. Zusätzlich wird die nachträgliche Konfiguration von bestehenden (Serien-)Terminen in Kalendern durch Exchange Administratoren ermöglicht. Dies ist ja gerade bei Austritten von Anwendern immer wieder ein anstrengendes Thema.

Outlook on the Web wird immer mehr zur zentralen Schnittstelle für den Zugriff auf E-Mails und funktioniert mit allen gängigen Browserversionen tadellos. Bedenken Sie bitte, dass die korrekte Nutzung aller Postfachfunktionen von Exchange Server 2019 nur gewährleistet werden kann, wenn eine aktuelle Outlook for Deskop (Windows/Mac) Version eingesetzt wird.

Was fehlt?

Keine Exchange Version ohne einen Wegfall von Funktionen. Nein, die Öffentlichen Ordner sind immer noch vorhanden.

Die Unfied Messaging Funktion, die ja bereits in den Vorversionen nicht mehr als separate Funktionsrolle zur Verfügung stand, zur Bereitstellung von VoiceMail-Funktionen, ist in Exchange Server 2019 nicht mehr vorhanden. Microsoft lässt Ihnen die Wahl, sich für eine Anbindung von Cloud VoiceMail bei gleichzeitiger Nutzung von Skype for Business Server 2019 zu entscheiden, oder eine Drittanbieter Lösung einzubinden.

Eine Alternative ist der Weiterbetrieb von Exchange Server 2016, bis diese Version das Support-Ende erreicht hat. Eine Vergleichstabelle über die Möglichkeiten zur VoiceMail-Nutzung finden Sie hier.

Weitere Informationen und Empfehlungen zum Umgang mit dem Wegfall der Unified Messaging-Funktionen wird es auf der Ignite 2018 Konferenz geben.

Koexistenz

Welche Möglichkeiten ergeben sich mit Exchange Server 2019 für die Co-Existenz der Exchange Versionen während der Transitionsphase?

Auch Exchange Server 2019 folgt dem seit Jahren bekannten N-2 Prinzip. Eine Koexistenz der aktuellen Exchange Server Version (N) ist nur mit den beiden letzten Exchange Versionen (-2) möglich. Das bedeutet, dass Sie Exchange Server 2019 nicht in einer direkten Koexistenz mit Exchange Server 2010 installieren können. Wenn Sie noch Exchange Server 2010 betreiben und auf Exchange Server 2019 wechseln möchten, müssen Sie eine Zwischenmigration über Exchange Server 2016 durchführen. Für Exchange Server 2013 ist ja seit Juni 2018 der Mainstream-Support beendet.

Weitere Informationen und Empfehlungen zur Co-Existenz wird es auch hier auf der Ignite 2018 Konferenz geben.

Zusammenfassung

Auch mit Exchange Server 2019 wird die produktinterne Hauptversionsnummer nicht hochgezählt. Die Programmversion wird als 15.2 gezählt. Böse Stimmen werden nun lamentieren, dass es sich, der alten Microsoft Notation folgend, um Service Pack 2 für Exchange Server 2013 handeln muss. Das ist natürlich nicht der Fall. Exchange Server 2019 ist ein eigenständiges Produkt.

Die Neuerungen in der Architektur und die Unterstützung von Windows Server Core versprechen einen leistungsstarken und sicheren Betrieb von Exchange Server 2019, der von den Erfahrungen im Clouddienst von Office 365 profitiert. Insbesondere die neue Suche ist ein Ergebnis aus dem betrieb einer sehr großen Exchange Umgebung.

Die Vorteile für Endanwender sind aus meiner Sicht eher Komfortverbesserungen. Ob diese alleinig einen Wechsel zu Exchange Server 2019 rechtfertigen lassen, müssen Sie entscheiden.

Ende September findet die Microsoft Ignite 2018 Konferenz in Orlando statt. Es wird eine spannende Woche mit interessanten Vorträgen zu den Neuerungen und Änderungen im Vergleich zu Exchange Server 2016 werden. Wir dürfen gespannt sein. Ich werde dort sein.

Sie haben Fragen zu Ihrer bestehenden Exchange Server Umgebung? Sie möchten auf eine neue Version von Exchange Server wechseln? Kontaktieren Sie uns. info@granikos.eu.