The mailbox default folders like Inbox or Sent Items are labeled depending on the locale settings of the mailbox.
Mailbox users are able to change the default user names by changing the primary language of the Office setup and starting Outlook with the command line parameter /resetfoldernames.
The same can be achieved by the Exchange Administrator by running the Exchange cmdlet Set-MailboxRegionalConfiguration.
When moving mailbox content to a new Exchange mailbox using a PST export/import approach it is important (besides other things) that the export and import mailbox locale match. Otherwise you will end up with new folders being imported into the target mailbox. Folders are being mapped by the folder name during import.
The following screenshot shows the default folders of the mailbox in the locale de-DE.
The regional configuration settings can be checked on the Exchange Server.
[PS] C:\>Get-Mailbox askywalker | Get-MailboxRegionalConfiguration | fl
RunspaceId : f739bd99-9940-4dcf-abd5-6de080ac312d DateFormat : dd.MM.yyyyLanguage : de-DE
DefaultFolderNameMatchingUserLanguage : False TimeFormat : HH:mm TimeZone : W. Europe Standard Time Identity : contoso.com/Test/Anakin Skywalker IsValid : True ObjectState : New
Changing the default folder names to en-US is straight forward.
[PS] C:\>Get-Mailbox askywalker | Set-MailboxRegionalConfiguration -LocalizeDefaultFolderName:$true -Language en-us
The changes are reflected in Outlook without restarting Outlook.
RunspaceId : f739bd99-9940-4dcf-abd5-6de080ac312d DateFormat : M/d/yyyy Language : en-US DefaultFolderNameMatchingUserLanguage : False TimeFormat : h:mm tt TimeZone : W. Europe Standard Time Identity : contoso.com/Test/Anakin Skywalker IsValid : True ObjectState : New
When you now try to revert the configuration to de-DE receive an error that the locale does not match the current date and time format. This is even more interesting that the cmdlet was not complaining about the same issue when converting to the en-US locale.
[PS] C:\>Get-Mailbox askywalker | Set-MailboxRegionalConfiguration -LocalizeDefaultFolderName:$true -Language de-de
DateFormat "M/d/yyyy" isn't valid for current language setting "de-DE". Valid formats include "dd.MM.yyyy, dd.MM.yy, yyyy-MM-dd, dd. MMM. yyyy". + CategoryInfo : NotSpecified: (contoso.com/Test/Anakin Skywalker:ADObjectId) [Set-MailboxRegionalConfiguration], DataValidationException + FullyQualifiedErrorId : [Server=CT01,RequestId=3bcd1191-c547-45ec-a7ad-dc5e8a1e34db,TimeStamp=05.02.2014 11:19:11] [FailureCategory=Cmdlet-DataValidationException] 2161B69F,Microsoft.Exchange.Management.StoreTasks.SetMailboxRegionalConfiguration + PSComputerName : CT01.contoso.com The TimeFormat "h:mm tt" isn't valid for current language setting "de-DE". Valid formats include "HH:mm, HH:mm' Uhr'". + CategoryInfo : NotSpecified: (contoso.com/Test/Anakin Skywalker:ADObjectId) [Set-MailboxRegionalConfiguration], DataValidationException + FullyQualifiedErrorId : [Server=CT01,RequestId=3bcd1191-c547-45ec-a7ad-dc5e8a1e34db,TimeStamp=05.02.2014 11:19:11] [FailureCategory=Cmdlet-DataValidationException] D603E2E8,Microsoft.Exchange.Management.StoreTasks.SetMailboxRegionalConfiguration + PSComputerName : CT01.contoso.com
To successfully convert back to the de-DE locale it is required to specify a valid date and time format for the target locale.
[PS] C:\>Get-Mailbox askywalker | Set-MailboxRegionalConfiguration -LocalizeDefaultFolderName:$true -Language de-de -DateFormat dd.MM.yyyy -TimeFormat HH:mm
When setting the regional time zone information, the time zone name must be used. A Granikos FAQ post lists the available time zones.
The following PowerShell scripts have been published by our Exchange and Office 365 experts to the technical community at TechNet Gallery. Please use the GitHub repositories to report issues or to file feature requests.
Please send comments, wishes, and ideas to support@granikos.eu.
Enjoy!
Need assistance with your Exchange Server Organization? You plan to upgrade your Exchange Server Organization? You plan to migrate to Office 365? Contact us: info@granikos.eu
Update 2019-05-07: Export mailbox delegates and SMTP forwarding information added Update 2018-09-04: Add remote IP-address ranges to a receive connector added Update 2018-06-16: Manage Master Category List for Shared Mailboxes and Teams added Update 2018-04-29: Convert Word documents using PowerShell and Set Mailbox Item Private Flag added Update 2018-01-24: Create a new Room Mailbox with Security Groups added Update 2017-11-11: Export all user mailbox permissions added Update 2017-09-22: Remove Out-Of-Office rules from user mailbox added Update 2017-05-20: Parse email messages content for further processing and Update OWA vDir config across multiple servers added Update 2017-03-18: Fetch recently created public folders and Clear Private Flag on Mailbox Messages added Update 2017-02-22: Remove Orphaned HealthMailbox and SystemMailbox Accounts from MESO Container added Update 2017-02-17: Test Office 365 Domain Availability added Update 2017-02-13: Connect to Exchange Server 2013+ using remote PowerShell added Update 2017-02-07: Create Exchange internal/external Url based certificate requests, Create a scheduled task for Exchange Server 2013 added Update 2017-01-24: Gather Exchange Configuration Data added Update 2017-01-05: Export Messages from Transport Queue added Update 2016-11-29: Clean legacy public folder ACL added, Scripts categorized Update 2016-11-28: Add multiple legacy public folder replicas added Update 2016-08-18: Simple import of multiple PST files for a single user added Update 2016-07-28: Change IIS Log File settings Github Url added, Create a new Team Mailbox with Security Groups added Update 2016-06-04: GlobalFunctions added Update 2015-06-18: Copy-ReceiveConnector updated Update 2015-06-01: Exchange 2010 Public Folder Replication Report (UTF8 support) Update 2015-05-21: Copy anti-virus pattern to Exchange 2010/Exchange 2013 servers added Update 2014-12-10: Copy a receive connector from one Exchange Server to multiple Exchange Servers added
Exchange Server 2019 ist die aktuelle Version der E-Mail-Messaging Plattform für die Installation in der lokalten IT-Infrastruktur (aka On-Premises). Als lokale Infrastruktur gilt auch die Nutzung von Exchange Server 2019 auf virtualisiserten Serversystemen in Microsoft Azure. Bei Microsoft handelt sich, technisch gesehen, nur um ein ausgelagertes Rechenzentrum. Als wirkliche Alternative zu einem eigenen Betrieb von Exchange Server 2019 steht Ihnen Exchange Online, als Bestandteil des Software-as-a-Service Angebotes von Office 365, zur Verfügung.
Der Betrieb von Exchange Server 2019, die hybride Verbindung zwischen einer lokalen Exchange Organisation und Exchange Online oder die alleinige Nutzung von Exchange Online erfordern eine detaillierte Planung und Vorbereitung.
Auf dieser Seite finden Sie die wichtigsten Referenz-Links zu Online Ressourcen von Microsoft und anderen Quellen, um das für Sie richtige Exchange Produkt zu installieren, einzurichten und zu betreiben.
Wie einleitend schon ausgeführt, kann Exchange grundsätzlich in vier unterschiedlichen Architekturmodellen betrieben werden, die ihre ganz individuellen Vor- und Nachteile bieten. Diese sind:
= kontrolliert durch Microsoft = kontrolliert durch Kunden
Der Betrieb und die vollständige Verwaltung von Exchange Server erfordern die Verwendung der Exchange Management Shell (EMS). Mit Hilfe des browserbasierten Exchange Admin Center (EAC) können Sie Gelegenheitsaufgaben durchführen. Dies gilt für Exchange Server 2019 ebenso wie für Exchange Online.
Viel Spaß mit Exchange Server 2019 und Exchange Online.
Sie benötigen Hilfe bei der Planung und Installation Ihrer Exchange Server Installation? Sie haben Fragen über Ihre bestehende Exchange Server Infrastruktur und möchten Exchange Online implementieren? Kontaktieren Sie uns per E-Mail info@granikos.eu oder besuchen Sie unsere Webseite http://www.granikos.eu
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.
Mit Exchange Version 2013 wurden die sog. Modernen Öffentlichen Ordner (Modern Public Folder) eingeführt. In den vorherigen Produktversionen von Exchange Server erfolgte die Replikation der Öffentlichen Ordner mit einer eigenen Replikationstechnologie. Die öffentlichen Ordner bis einschließlich Exchange Server 2010 bezeichnet man als Legacy Public Folder oder als Öffentliche Ordner alter Bauart.
Im April 2017 habe ich bereits die Herausforderungen aufgezeigt, die bei der Migration von Öffentlichen Ordner innerhalb einer lokalen Exchange Organisation auftauchen. Dieser Blogartikel behandelt die Migration von Legacy Public Foldern zu Exchange Online.
Exchange Online unterstützt die direkte Migration von Legacy Public Foldern aus der lokalen Exchange Organisation zu Modern Public Foldern in Exchange Online. Da es sich hierbei technisch um eine Migration über Exchange Organisationsgrenzen hinweg (sog. Cross-Forest Migration) handelt, ergeben sich ganz eigene Herausforderungen.
Die Postfach-Migration aus einer lokalen Exchange Organisation hin zu Exchange Online erfordert immer die Konfiguration eines Migrationsendpunktes. Über diesen Endpunkt greift Exchange Online auf einen lokal installiert Exchange Server 2016 mit Hybrid Funktion zu.
Das nachfolgende Schaubild zeigt die Zugriffswege für die Migration von Postfächern und die Migration von Öffentlichen Ordnern von Exchange Server 2010 zu Exchange Online. Der Zugriffsweg zur die Migration von Exchange-Postfächern ist grün dargestellt, der für die Migration von Öffentlichen Ordner blau.
Exchange Server 2016 arbeitet bei der Migration von Postfächern als Proxy und nimmt in unserem Beispiel Verschiebeanforderungen von Exchange Online per Exchange Web Service (EWS) unter dem Hostnamen ews.varunagroup.de entgegen. Der Migrationsendpunkt für Exchange-Postfächer kann nicht für die Migration von Legacy Public Foldern verwendet werden. Die Migration der Legacy Public Foldern erfolgt über einen OutlookAnywhere Migrationsendpunkt vom Typ Public Folder. Ein Endpunkt dieses Typs kann im Exchange Admin Center nicht manuell erstellt werden. Die Erstellung erfolgt im Rahmen der Einrichtung des Migrationsbatchs mit Hilfe der Exchange Online Remote PowerShell. Für die Einrichtung des Migrationsendpunktes wird ein Benutzerkonto (Migrationskonto) im lokalen Active Directory benötigt, dass Organisationsadministrator ist.
Wenn Sie den externen OutlookAnywhere Zugriff auf Exchange Server 2010 bereits entfernt haben oder ihn noch nie in Betrieb hatten, so müssen Sie diesen Zugriff konfigurieren. Die externe Verfügbarkeit eines OutlookAnywhere Endpunktes ist für die Migration der Legacy Public Folder zu Exchange Online eine Voraussetzung.
Ein Wort zu E-Mail-aktivierten Öffentlichen Ordnern. E-Mail-aktivierte Öffentliche Ordner hatten in der Vergangenheit ihre Daseinsberechtigung, sind aber in der heutigen Zeit nicht mehr State-of-the-Art. Sie sollten darüber nachdenken, E-Mail-aktivierte Öffentliche Ordner durch eine zeitgemäße Lösung ersetzen. Wenn Sie die Öffentlichen Ordner Hierarchie zu Office 365 migrieren und anschließend zu etwas Neuem wechseln möchten, bringen Sie vielleicht die Funktionen von Microsoft Teams weiter.
Im Beispiel dieses Artikels gab es zu Beginn der Postfach-Migration in der Exchange Organisation E-Mail-aktivierte Öffentlichen Ordner, die mit Hilfe des Scripts Sync-MailPublicFolders.ps1 (Download) zu Office 365 manuell synchronisiert wurden. Dies war erforderlich, damit Anwender mit einem Postfach in Exchange Online E-Mail-Nachrichten an diese Öffentlichen Ordner senden konnten.
Als Teil der Vorbereitungen zur Migration der Öffentlichen Ordner zu Exchange Online wurden Funktionen der E-Mail-aktivierten Ordner in Freigegebene Postfächer migriert. Hierzu gehörte damit auch die Deaktivierung der E-Mail Funktionen der betroffenen Öffentlichen Ordner.
Der Ablauf einer Migration der Öffentlichen Ordner von Exchange Server 2010 zu Exchange Online ist im Grundsatz identisch zur Migration zu Exchange Server 2016 in einer lokalen Exchange Organisation. Der Hauptunterschied liegt in der Konfiguration des Migrationsendpunktes und des Remote-Migrationsbatches.
Die Schritte sind:
# Quota für die Migration ganz aufheben Set-OrganizationConfig -DefaultPublicFolderProhibitPostQuota Unlimited -DefaultPublicFolderIssueWarningQuota Unlimited
# Erste Public Folder Mailbox freigeben Set-Mailbox Mailbox1 -PublicFolder -IsExcludedFromServingHierarchy:$false # Default Public Folder Mailbox für Test-Benutzer setzen Set-Mailbox -Identity JohneDoe@varunagroup.de -DefaultPublicFolderMailbox Mailbox1
# Alle Public Folder Postfächer für den Hierarchie-Zugriff freigeben Set-Mailbox -PublicFolder -IsExcludedFromServingHierarchy:$false # Öffentlichen Ordner Zugriff auf "local" setzen (aus Sicht der Office 365 E-Mail Postfächer) Set-OrganizationConfig -PublicFoldersEnabled Local
Wie bereits erwähnt, wurden alle E-Mail-aktivierten Ordner vor der Migration zu Exchange Online deaktiviert und das Skript zur Synchronisation der E-Mail-aktivierten Öffentlichen Ordner mit Office 365 ausgeführt. Leider führt das Skript nicht alle notwendigen Schritte aus, um die Informationen in Exchange Online korrekt zu entfernen.
Fehlermeldung im Migrationsbatch:
"Error: More than N mail public folders in Active Directory were not linked to any public folder during migration. Mail flow will stop working for these public folders after the migration is finalized. Please check whether these are important"
Sie müssen die nicht mehr vorhanden Ordner manuell mit Hilfe der Exchange Online Remote PowerShell löschen. Mit dem nachfolgenden Beispiel löschen Sie alle E-Mail aktivierten Öffentlichen Ordner, die mit Hilfe des Skriptes Sync-MailPublicFolders.ps1 in Exchange Online erstellt wurden.
# Löschung eines einzelnen ehemals E-Mail-aktivieren Öffentlichen Ordners in Exchange Online Get-MailPublicFolder 'My Mail Public Folder' | Remove-SyncMailPublicFolder # Löschung aller ehemals E-Mail-aktivierten Öffentlichen Ordner in Exchange Online Get-MailPublicFolder -ResultSize Unlimited | Remove-SyncMailPublicFolder
Die Migration von Legacy Public Foldern zu Exchange Online ist nicht schwer. Sie erfordert aber, dass die zu migrierende Hierarchie der Öffentlichen Ordner vorbereitet wird und Ordnernamen keinen unzulässigen Zeichen enthalten. Ebenso muss ein passender OutlookAnywhere Endpunkt aus dem Internet erreichbar sein. Ohne einen OutlookAnywhere Endpunkt und ohne ein berechtigtes Migrationskonto kann der Migrationsbatch von Exchange Online keine Daten kopieren.
Stellen Sie die E-Mail-Aktivierung von Öffentlichen Ordnern in Frage und suchen Sie modernere Lösungen. Eventuell notwendige Umzüge von E-Mail-Adressen müssen vor der Migration der Öffentlichen Ordner abgeschlossen sein.
Planen Sie für die Finalisierung der Migration genügend Zeit ein. Im direkten Vergleich zu lokale durchgeführten Modern Public Folder Migrationen benötigten Finalisierungen von Migrationen zu Exchange Online das Vierfache an Zeit. Bedenken Sie, dass nach einer Umstellung des Public Folder Zugriffes für die Postfachnutzer in Exchange Online es noch mehrere Stunden dauern kann, bis die Konfigurationsänderungen durch Outlook Clients genutzt werden.
Viel Spaß mit modernen Öffentlichen Ordnern.
Auf der Microsoft Ignite 2015 Konferenz in Chicago wurden erste Informationen über Exchange Server 2016 veröffentlicht.
Es wurde klar artikuliert, dass keine Abkehr von On-Premise Versionen geplant ist. Die Anforderungen der Microsoft Kunden werden auch in der Zukunft On-Premise Versionen von Exchange Server erforderlich machen. Wie neue Funktionen ihren Weg in die On-Premise Version von Exchange finden, hat sich aber bereits mit Exchange Server 2013 geändert. Neue Funktionen werden zuerst in Office 365 (Exchange Online) entwickelt, bereitgestellt und stabilisert. Nachfolgend wird entschieden, ob eine Funktion den Weg in die On-Premise Variante von Exchange Server findet. Microsoft beschreibt diesen Weg als "Delivering Innovation".
Das nachfolgende Schaubild verdeutlicht diesen Prozess:
Jede Version von Exchange Server ging mit einer Änderung der Server Architektur einher. Mit Exchange Server 2016 lassen wir das mit mit Exchange Server 2007 eingeführte Konzept der Rollen fast komplett hinter uns. In Exchange Server 2016 exisitiert nur noch eine intere Rolle, der Mailbox Server. Hinzu kommt nur noch die Edge Rolle für den bereits bekannten Einsatz in der DMZ.
In der Mailbox Rolle sind nun alle Funktionen zusammengefasst, die in Exchange Server 2013 noch auf CAS und Mailbox aufgeteilt waren. Exchange Server 2016 nutzt eine tiefe Integration mit dem Office Web Apps Server, um in Outlook Web App 2016 eine direkte Bearbeitungsmöglichkeit für Office Dokumente anzubieten.
Die nachfolgenden beiden Schaubilder verdeutlichen die Architekturunterschiede zwischen Exchange Server 2013 und Exchange Server 2016.
Mit Exchange Server 2016 ergeben sich keine grundlegenden Änderungen für die Kommunikation von Clients zum Exchange Server. Clients verbinden sich weiterhin über einen Load Balancer mit dem "Proxy" Endpunkt. Im Gegensatz zu Exchange Server 2013 kann der Proxy-Layer aber nicht mehr auf dedizierte Server installiert werden. Die Separierung von CAS und Mailbox-Rollen wurde bereits in der Preferred Architecture für Exchange Server 2013 nicht mehr empfohlen.
Exchange Server 2016 arbeitet mit einem Proxy-Layer. Dieser ist jedoch in einem Building Block auf dem Server integriert.
Auch für die Konnektivität für Unified Messaging ergeben sich keine Änderungen. Verbindungen zum Proxy-Layer werden zum direkten UM-Endpunkt umgeleitet.
Die beiden nachfolgenden Schaubilder verdeutlichen die Unterschiede in der Client Konnektivität zwischen Exchange Server 2013 und Exchange Server 2016.
Was bietet Exchange Server 2016 jenseits der Veränderungen in der Architektur? Die großen Themenblöcke, die Microsoft mit Exchange Server 2016 besetzen möchte sind:
Unter dem Titel Better Collabiration soll durch die Integration von Exchange und SharePoint das Arbeiten mit Dateianhängen grundlegend verändert werden. Anstatt Office Dateien in unterschiedlichen Versionen per E-Mail zu versenden und so die Postfächer mit unnnötigen Daten zu füllen, sollen nur noch Links zu den entsprechenden Dateien versendet werden. Die Dateien werden hierzu in SharePoint bzw. OneNote for Business gespeichert. Die erforderlichen Berechtigungen zum Bearbeiten oder zur Ansicht werden für die E-Mail Empfänger automatisch vergeben. Dies ermöglicht den Anwendern, an einer Version des Dokumenten gemeinsam zu arbeiten. Diese Funktionen werden durch den Einsatz des Office Web Apps Servers ermöglicht.
Selbst mit externen Kommunikationspartnern ist solch eine Kollaboration möglich. Hier ergeben sich für Unternehmen aber auch neue Herausforderungen. Die Veröffentlichung der Funktionen und die Möglichkeit, dass externe Anwender Zugriff auf Dokumente erhalten können, erfordern eine detaillierte Planung der Infrastruktur und der notwendigen Konfigurationen.
Das nachfolgende Schaubild zeigt die erforderlichen Komponenten:
Die Nutzung des Posteinganges unterscheidet sich grundlegend in zwei Varianten:
Es existieren zahlreiche Ratgeber zum effizienten Arbeiten mit E-Mail und dem Posteingang. Leider gibt es nicht die eine Antwort und E-mail wird aus unterschiedlichsten Gründen noch ein lange Zeit der primäre Weg der digitalen Kommunikation sein.
Exchange Server 2016 versucht mit einem intelligenteren Posteingang das Arbeiten mit Outlook zu verbessern. Hierzu gehört eine Verbesserung bei den Suchergebnissen und Beschleunigung der Suche selber. Hinzu kommt eine bessere Unterstützung für Add-Ins in Outlook.
Die neue REST API von Exchange Server 2016 erleichtert die Entwicklung von einheitlichen Add-Ins für Outlook Add-ins mit Anbindung an Exchange On-Premise oder Exchange Online.
Weitere Verbesserungen sind:
Zu den OWA Verbesserungen gehören:
Durch den immer größeren Verbreitungsgrad von mobilen Endgeräten, erfolgt auch der Zugriff auf E-Mails immer mehr von diesen Geräten. Nach einer Studie von Experian erfolgten in Q3 2014 53% aller Zugriffe auf E-Mails von Telefonen oder Tablets.
Hier ist das Ziel, eine einheitliche Erfahrungswelt über alle Gerätetypen hinweg zu schaffen. Anstatt wie in der Vergangenheit unterschiedliche Exchange ActiveSync Clients auf mobilen Endgeräten zu haben, möchte Microsoft die einheitliche Outlook Erfahrung ermöglichen. Dies wird erreicht durch:
Exchange Server 2016 wurde für den Betrieb in modernen Datacentern entwickelt. Dieses Anspruch wird Exchange hauptsächlich durch die vereinfachte Softwarearchitektur und die vereinfachten Hardwareanforderungen erreicht. Die Preferred Architecture für Exchange Server 2016 setzt nicht auf komplexe Virtualisierung, sondern auf den Einsatz von einfachen Standardservern und JBOD als Speichermedium.
Exchange Server 2016 soll auf Standardhardware betrieben werden und so zusätzliche Single-Point of Failures vermeiden helfen.
Die Koexistenz mit Exchange Server 2013 ist einfacher zu implementieren als die Koexistenz in vorherigen Exchange Versionen. Grund hierfür ist einfach die starke Ähnlichkeit zwischen Exchange Server 2013 und 2016.
Die automatische Reparatur von Postfachdatenbanken erhöht die Verfügbarkeit und vermindert das Risiko von Datenverlusten. Dies wird erreicht durch "DB Divergence Detection", "Loose Trunctation" und den Einsatz des ReFS Dateisystems für Datenlaufwerke.
Für ein modernes Deployment von Exchange Server 2016 stehen der Betrieb einer DAG ohne adminstrativen Endpunkt und die Unterstützung von Azure File Share Witness zur Verfügung. Unternehmen, die noch ein klassisches Backup vewenden, werden von einer DAG ohne administrativen Endpunkt nicht profitieren können, da die Hersteller von Backup-Software sich mit dieser neuen Cluster-Variante (Funktion von Windows Server 2012 R2) schwer tun. Ebenso ist die Funktion eines Azure File Share Witness nicht für alle Unternehmen möglich.
Die Indizierung der passiven Postfachdatenbanken erforderte in der Vergangenheit immer eine Kommunikation mit der aktiven Kopie. Mit Exchange Server 2016 erfolgt die Indizierung nur direkt in der passiven Kopie, was zu einer Reduzierung des Datenverkehrs führt.
Exchange Server 2016 bringt neue Funktionen zur Data Loss Prevention, zur Auditierung und zu eDiscovery. Die Informationen und Funktionen von DLP Policies stehen nun nicht nur in Outllok zur Verfügung, sondern auch in anderen Office Client Produkten und in SharePoint. Hierdurch ergibt sich eine einheitliche Erfahrung für den Anwender. DLP Policies werden somit nicht erst beim Versenden von Nachrichten angewandt, sondern bereits beim versuchten Aufrufen von Dateien.
Das Auditierungsschema wurde in Anlehnung zu Office 365 vereinheitlicht. Dies erleichtert die Auswertung der Audit/Protokolldateien in einer Hybrid-Konfiguration. Ebenso wurden die Such- und Filterfunktionen verbessert.
Neue Öffentliche Ordner können nun auch auf In-Place Hold gesetzt werden.
Exchange Server 2016 bietet zahlreiche neue Funktionen und Verbesserungen bekannter Funktionen. Jedoch muss man auch die kommende Version von Exchange Server 2016 als Version 1.0 eines On-Premise Produktes sehen. Durch den mit Exchange Server 2013 eingeführten Deployment Zyklus von drei Monaten, müssen sich Unternehmen auf einen schnelleren Rolloutplan einstellen. Rein technisch wird alle drei Monate ein neues Produkt eingeführt. Interne Change Prozesse rund um Exchange müssen auf die neuen Anforderungen hin angepasst werden.
Exchange Server 2016 befindet sich sich gegenwärtig noch im geschlossen TAP Programm mit ausgewählten Kunden. Die öffentliche Beta-Phase für Exchange Server 2016 ist für den Sommer 2015 vorgesehen. Als geplanter Veröffentlichungstermin für Exchange Server 2016 ist Herbst/Winter 2015 vorgesehen.