Die Herausforderungen der COVID-19 Krise sind gerade für Schulen eine besondere Herausforderung. Die meisten Schulen sind auf die aktuelle Situation nicht vorbereitet und können keinen Fernunterricht für die Lernenden professionell und sicher anbieten. Als spontane Reaktion auf hieraus werden kurzfristige Lösungen, wie z.B. Zoom, Jitsi und andere Plattformen aktiviert und genutzt. In der Vergangenheit haben sich für die direkte Lehrer-Schüler-Kommunikation Dienste wie WhatsApp oder direkte E-Mail-Kommunikation etabliert. Diese werden ohne ein Hinterfragen verwendet.
Mit der Notwendigkeit Fernunterricht zum Alltag werden zu lassen und diese Option als als zusätzliches Unterrichtsmedium mit aufzunehmen kommen Schulverantwortliche an ihre Grenzen. Nach einer Idee der Kultusministerkonferenz aus dem Jahr 2016 sollten sich die Schulen auf den Weg in die Digitalisierung machen. Diese Weg haben nur einige Schulen begonnen.
Schulen können heute aus einem breitgefächerten Portfolio an unterschiedlich guten Lösung für den Unterricht und die Schulorganisation wählen. Sie tun dies im besten Wissen und auf Basis des technischen Fachwissens. Eine passende Lösung wird durch klassisches Ausprobieren gefunden, da für eine langwierige Vergleichsphase keine Zeit ist. Hat sich eine Schule für eine Lösung entschieden und ist von der Qualität des gewählten Produktes überzeugt, werden die Bemühungen zunichte gemacht. Die DSGVO spaziert herein.
Die Unwissenheit über die DSGVO, als europäische Verordnung, führt zu teils bizarren Situationen. Sie wird oftmals derart interpretiert, dass Informationen und Daten nur in Deutschland gespeichert werden dürfen oder, wie auch schon gehört, gar keine Daten erfasst werden dürfen. Privatschulen stecken hier in einem besonderen Dilemma, da sie als Unternehmen einen Datenschutzbeauftragen benennen müssen, an dessen "Expertise" sie sich ohne Nachfragen halten. Hierbei kommt es auch vor, dass vorauseilend agiert wird, da jede Nachfrage beim Datenschutzbeauftragten mit Kosten verbunden ist. In dieser Diskussion zeigt sich das erste Versagen bei der Umsetzung der Rolle des "Datenschutzbeauftragen", da es keine bundeseinheitliche Definition zur Eignung als Datenschutzbeauftragter gibt.
Mit Stand Anfang Mai 2020, nachdem sich der ersten Staub der COVID-19 Spontaneinführungen von Softwarelösungen gelegt hat, werden diese Lösungen durch Mitteilungen von unwissenden Datenschutzbeauftragen der Länder in Frage gestellt. Gerade im Fall des Landes Berlin muss man unterstellen, dass die Aussagen zum Thema „Berliner Datenschutzbeauftragte zur Durchführung von Videokonferenzen während der Kontaktbeschränkungen“ politisch getrieben sind. Diese Vermutung liegt leider nahe, da es in Kombination mit Schreiben der Schulbehörden direkte Empfehlungen für staatlich geförderte Projekte gibt. Hierbei wird nur Vergessen, dass es sich um zeitlich begrenzte Projekte handelt. Lösungen die heute an Schulen eingeführt werden, müssen aber über eine Laufzeit von mindestens zehn Jahren oder mehr zur Verfügung stehen, insbesondere dann, wenn es sich um eine Lösung zur Verwaltung handelt. Zu viele unterschiedliche Lösungen einzusetzen ist, im Sinne der IT-Administration, nicht sinnvoll.
Oftmals sind die Schulverwaltungen heillos überfordert. Hier ergreifen Lehrer die Initiative, finden Lösungen und probieren sie aus. Schließlich sind es die Lehrenden, die ihre und die Bedürfnisse ihrer Schüler kennen. Wer, wenn nicht sie, sollten in die Entscheidung über Softwarelösungen eingebunden sein.
Über all dem hängt das Damoklesschwert der DSGVO. Die verantwortlichen Gremien fürchten die Landesdatenschutzbeauftraten. In persönlichen Gesprächen wird das Wort "Angst" durchaus verwendet. Mit dieser Angst werden die Betroffenen alleingelassen und agieren auf Basis eines halbseidenen Wissens über die DSGVO. Mit dem Wunsch nach vermeintlicher Sicherheit entscheidet man ich gegen etablierte Lösungen, die auf eine mehr als fünfzehnjährige Erfahrung zurückblicken können, insbesondere auf eine Erfahrung im Schutz von Daten. Stattdessen wählt man kleine oder lokale Lösungen, die schon im Ansatz den Anforderungen der DSGVO hinsichtlich Zugriffskontrolle nicht gerecht werden.
Die Angebote der großen Anbieter werden ohne eine ausführliche Betrachtung der Sicherheits- und Schutzfunktionen mit Hinweis auf die DSGVO ignoriert oder dort, wo schon eingeführt, wieder zurückgefahren. Hier zeigt sich das irrationale Verhalten der "Entscheider". Sie entscheiden auf der Basis von "Nichtwissen", getrieben durch Angst etwas falsch zu machen. Hierbei wird völlig außer Acht gelassen, dass fast jede Schule tagtäglich gegen die DSGVO verstösst. Hier seien genannt: klassen- und schulweite WhatsApp-Kanäle, Speicherung von E-Mail-Adressen der Schüler ohne Einwilligung, Versand von unverschlüsselten E-Mail-Nachrichten, die Speicherung und der anonyme Austausch von Werturteilen über DropBox usw.
Die DSGVO ist in ihrer föderalen Interpretation das entscheidende Hindernis für die Digitalisierung der Schulen in Deutschland. Es fehlt an Aufklärung, fachliche Unterstützung und Hilfestellung für Schulen. Schulen können dies nicht aus eigener Kraft leisten.
Schulen brauchen Hilfe bei der Digitalisierung.
Bild von Benedikt Geyer auf Pixabay
Die Virtualisierung von Exchange ist nicht neu und war bereits seit Exchange 2003 mit VMware eine Option, obwohl es damals von Microsoft keine offizielle Unterstützung hierzu gab. Im Rahmen des Microsoft Server Virtualization Validation Program (SVVP) wurde die Virtualisierung von Exchange 2007 Service Pack 2 auf VMware ESX 3.5 Update 2 erstmal offiziell voll unterstützt.
Mit der Veröffentlichung von Exchange Server 2010 wurden alle Serverrollen (Unified Messaging ab Exchange 2010 SP1) auf allen SVVP validierten Hypervisor-Plattformen unterstützt. Die Unterstützung der Virtualisierung von Exchange Server 2010 wurde aber nur langsam adaptiert, da dies eine grundlegende Änderung im Design und der Architektur der Systeminfrastruktur mit sich brachte. Viele Systemadministratoren misstrauten der Virtualisierung und führten häufig die fehlende "Performance" als primären Grund an, sich gegen die Virtualisierung zu entscheiden. Interessant ist, dass "Performance" als genereller Begriff verwendet wurde (wird), um die Virtualisierung von Exchange Systemen abzuwenden. Die technologische Weiterentwicklung von Exchange und die stete Reduzierung der Anforderungen an Speichermedien in Bezug auf den erforderlichen Datendurchsatz, denn diese waren in der Vergangenheit der einzige Grund, sich gegen die Virtualisierung zu entscheiden, wird teilweise immer noch ignoriert.
Mit Exchange Server 2013 können alle Rollen problemlos virtualisiert werden und ermöglichen so eine optimale Ausnutzung der Hardware-Ressourcen in Ihrem Rechenzentrum.
Trotzdem ist es erforderlich, eine Exchange Umgebung korrekt und gewissenhaft zu planen und zu berechnen. Dies hat sich mit der Virtualiserungsoption für Exchange nicht geändert. Nur mit einer gewissenhaften Planung können komplexe Änderungen der Exchange-Landschaft zu einem späteren Zeitpunkt vermieden werden. Exchange Server 2013 besteht aus folgenden Serverrollen:
Die erfolgte Reduzierung von vier Serverrollen in Exchange 2007/2010, hin zu zwei Serverrollen, wenn wir die Edge-Rolle einmal als Sonderfall betrachten, erleichtert die Konzeption einer virtualisierten Exchange-Umgebung erheblich.
Wenn es um das Thema Virtualisierung von Enterprise-Applikation geht, einmal ganz ohne den Fokus Exchange, muss immer geklärt werden, wie die Hochverfügbarkeit (HA) der Applikation gewährleistet wird. Auf der einen Seite existieren HA-Funktionen in der jeweiligen Hypervisor-Plattform selber, auf der anderen Seite stehen die HA-Funktionen der Applikationen. Naiv gesehen könnte man annehmen, dass beides zusammen das Maximum an Hochverfügbarkeit bieten würde. Dies ist jedoch nicht der Fall.
Gerade für den Fall eines Support-Calls mit Microsoft ist es wichtig, dass Exchange in einer Konfiguration betrieben wird, die auch zu 100% unterstützt wird.
Für die Virtualisierung von Exchange Server 2013 gilt es Folgendes für einzelnen Systemkomponenten zu beachten
Exchange Server 2013 kann ebenso wie Vorgängerversionen als Multi-Role Server (Mailbox- und CAS-Rolle auf einem Server) oder als Single-Role Server (Mailbox-Rolle und CAS-Rolle auf separaten Systemen) installiert werden. So wie Exchange Rollen selber aufgeteilt werden können, können auch physische und virtuelle Systeme verteilt betrieben werden.
Natürlich können (sollten) auch die benötigten Load Balancer virtualisiert betrieben werden. Die möglichen Kombinationen mit den o.g. Exchange-Konfigurationen sind zahlreich und werden in diesem Artikel vernachlässigt.
Grundsätzlich gilt die Empfehlung, für das Sizing einer Exchange 2013 Umgebung (physisch oder virtuell), den Exchange 2013 Server Role Requirements Calculator zu verwenden. An diesem Tool führt kein Weg vorbei, wenn man eine verlässliche Aussage zu den Anforderungen für die Exchange Umgebung erhalten möchte. In den aktuellsten Versionen sind notwendige Berechnungskorrekturen für die Virtualisierung bereist enthalten. Microsoft geht von einem zusätzlichen Overhead durch den Hypervisor von 10% aus. VMware wiederum geht von ca. 2% bis 5% Overhead aus.
Wie bereits erwähnt, ist eine 1:1 Zuordnung von virtuellen CPU Cores zu physischen CPU Cores zu empfehlen, da dies die Umsetzung der kalkulierten Anforderungen in den laufenden Betrieb stark vereinfacht.
Microsoft hat empfiehlt beim Einsatz von Exchange Server (2010 und 2013) auf das Hyper-Threading der CPUs zu verzichten. Wichtig ist, dass Hyper-Threading CPUs nicht gleichzusetzen sind mit physischen CPUs. Als Hauptgrund wird angegeben, dass dies die CPU Planung unnötig verkompliziere. Als zweiter Grund wird die .NET Garbage Collection angeführt, die auf Basis der CPU Anzahl arbeitet und entsprechend Arbeitsspeicher allokiert. Durch Hyper-Threading wird allerdings unnötig viel Arbeitsspeicher für die Garbage Collection reserviert.
Im Rahmen einer Virtualisierung besteht das beschriebene Problem nicht im gleichen Ausmaß, wie in einer physischen Umgebung, da der VM eine feste Anzahl an Prozessoren zugeordnet ist. Dies bedeutet, dass Sie das für Ihre Umgebung passende Processor-Ratio finden müssen, wenn Sie nicht der 1:1 Zuordnung folgen möchte. Dies gelingt am besten, indem Sie mit einer 1:1 Zuordnung beginnen und mit einer System-Monitoring Lösung eine Baseline erstellen. Anschließend passen Sie die Prozessorzuordnung an und vergleichen die Auslastung- und Performancediagramme mit der Baseline.
Die nachfolgende Tabelle listet die Mindestanforderungen an Arbeitsspeicher für Exchange Server 2013
Dies sind die absoluten Mindestanforderungen. Ohne Verwendung des Role Requirements Calculators wird eine korrekte Planung für den performanten Betrieb von Exchange nicht gelingen.
Für einen Exchange Mailbox-Server mit 1000 Postfächern mit einem Anwenderprofil von 150 gesendeten und empfangenen Nachrichten pro Tag und einer Anforderung von 36MB Datenbankcache pro Postfach, benötigen Sie bereits mindestens 36GB Arbeitsspeicher. Ergänzend zum Role Requirements Calculator empfehle ich den Blog-Artikel "Ask the Perf Guy: Sizing Exchange 2013 Deployments" (http://bit.ly/PerfGuyExchange2013Deployments).
Ergänzend zu den Speicheranforderungen für Exchange Server 2013 müssen noch 4GB bis 8GB für das Betriebssystem addiert werden.
Für die Planung der Netzwerkverbindungen der virtuellen Systeme gelten die gleichen Anforderungen wie für physische Exchange Server. Exchange Server, die nicht Mitgliedsserver einer DAG sind, können mit einem einzelnen Netzwerkadapter konfiguriert werden. Mitgliedsserver einer DAG sollten immer mit zwei Netzwerkadaptern konfiguriert werden, um die Datenbankreplikation über ein separates Netz zu leiten und vom allgemeinen Zugriff auf die Postfachdatenbanken zu trennen. Der Einsatz von einzelnen Netzwerkadaptern ist zwar unterstützt, sollte sich aber auf Test- und Laborumgebungen beschränken.
Die physischen Netzwerkadapter im Host-System können durch Teaming ausfallsicher konfiguriert werden.
Das nachfolgende Beispiel zeigt, wie ein Exchange 2013 Mailbox Server, der Mitgliedserver einer DAG ist, und ein CAS Server nur durch VLANs getrennt an einem virtuellen Switch verbunden sind. Der virtuelle Switch ist durch NIC-Teaming im Hypervisor redundant mit der physischen Netzwerk Infrastruktur verbunden.
Mit der gleichen Exchange Server-Konstellation kann aber das DAG Netzwerk-Interface zur Datenreplikation über einen separaten virtuellen Switch, der über ein eigenes NIC-Interface im Hypervisor verfügt, mit einem dedizierten Replikationsnetzwerk verbunden werden.
Die zweite Konfiguration stellt sicher, dass die Datenreplikation in einem dedizierten physischen Netzwerk stattfindet. Jedoch erhöht dieser Lösungsansatz auch die Komplexität der Netzwerkinfrastruktur selber. Hinzu kommt, dass standardmäßig das MAPI Netzwerk als Backup für einen möglichen Ausfall des Replikationsnetzwerkes verwendet wird. Wenn Sie ausschließen möchten, dass das MAPI Netzwerk als Backup-Netzwerk verwendet werden kann, müssen Sie die Hochverfügbarkeit des Replikationsnetzwerkes sicherstellen.
In VMware Umgebungen empfiehlt es sich, immer den VMXNET3 Adapter für die virtuellen Maschinen zu verwenden, da der E1000 Adapter im Host-System nur CPU 0 für die Emulation verwendet. Die Nutzung des VMXNET3 Adapters bietet somit eine deutlich bessere Performance gegenüber dem E1000 Adapter.
Ganz unabhängig von der gewählten virtuellen Netzwerkkonfiguration muss immer sichergestellt werden, dass die Host-System sowohl in der Hardware-seitigen, als auch in virtuellen Netzwerkkonfiguration identisch konfiguriert sind. Die virtuellen Gast-Systeme können schließlich nur zwischen Hosts verschoben werden, die auch die notwendigen Ressourcen (virtuelle Switche, VM Port Groups, etc.) zur Verfügung stellen.
Die Bereitstellung des notwendigen Festplattenspeichers für virtualisierte Exchange Server 2013 Systeme bietet vielfältige Optionen. Die rein physischen Optionen, wie z.B. Bereitstellung von Raw LUNs, die in einem SAN Speicher konfiguriert sind, oder VMDK, VHD/VHDX Dateien im SAN oder im DAS, oder aber die direkte Einbindung der Datastore-Volumes per iSCSI im Gast-Betriebssystem selber, unterliegen den Möglichkeiten und Anforderungen Ihrer Unternehmensumgebung. Manchmal unterliegt die Auswahl des Speichermediums aber auch internen politischen Richtlinien, durch die bestimmt wird, dass ein "teurer" SAN Speicher verwendet werden muss, obwohl dies durch die Anforderungen von Exchange Server 2013 selber gar nicht mehr notwendig ist. Eines der Arguments für die Migration zu Exchange Server 2013 ist die Unterstützung von günstigen JBOD Enclosures, die sehr große Datenspeicher sehr günstig (im Vergleich zu klassischem SAN Speicher) bereitstellen können.
Hier muss eine sehr genaue Abwägung zwischen technischem Vorteil/Nutzen und dem zusätzlichen Aufwand und der zusätzlichen Komplexität in der Umgebung für Speichersubsysteme erfolgen. Es ist meist schwierig, die Einführung einer neuen Technologie nur mit den Anforderungen einer einzigen Applikation zu begründen. Es ist hilfreich zu prüfen, ob nicht auch andere Applikationen, die in naher Zukunft migriert werden sollen (z.B. von SharePoint 2010 auf SharePoint 2013), von dem neuen Speichermedium profitieren können. Eine stärkere strategische Ausrichtung hilft bei der Argumentation sehr.
Zusammenfassend kann man sagen, dass die Virtualisierung eine große Flexibilität im Sizing und im Betrieb einer Exchange Plattform mit sich bringt. Jedoch birgt eine Virtualisierung schnell auch Risiken. Dieses Risiken wirken sich nicht unbedingt auf den sicheren Betrieb von Exchange aus, sondern vielmehr auf die Reaktionszeit, also die Performance der Exchange Umgebung.
Grundsätzlich darf man aber nicht vergessen, dass gemessene Performance nicht gleichzusetzten ist, mit subjektiv gefühlter Performance. Insbesondere Endanwender sind sehr empfindlich und reagieren kritisch, wenn "Ihr" Outlook nicht in der gleichen Zeitspanne startet, wie "gestern". Ähnlich sieht es aus, wenn Nachrichten durch mangelhafte Ressourcenverfügbarkeit zu lange in einer Warteschlange verweilen, bevor sie zugestellt werden. Auch wenn Administratoren wissen, dass E-Mail (oder besser SMTP) ein Warteschlangen-basierende Kommunikation ist, ist dies Endanwendern meist nur sehr schwer zu vermitteln.
Viel Spaß bei der Virtualisierung von Exchange Server 2013.
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.
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
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.
Für eine erfolgreiche Migration sind folgende Voraussetzungen notwendig
In den folgenden Schritten wird die Domäne azure-usergroup.de als neue Domäne zu einem Office 365 Tenant hinzugefügt.
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.
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.
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.
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.
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.
Damit ist die Ersteinrichtung der neuen Domäne in Office 365 abgeschlossen.
Klicken Sie auf Fertig stellen.
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.
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.
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.
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.
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.
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.
In der Übersicht der Exchange Online Migrationsbatche wird deutlich angezeigt, dass das Batch synchronisierte, aber keine finalisierten (abgeschlossenen) Postfächer enthält.
Ü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.
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.
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.
Intermediate (200)
Advanced (300)
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:
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.
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.
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.
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.
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 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.
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.
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.
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.