Die nachfolgende Präsentation wurde im Rahmen des Treffens der Exchange User Group Berlin am 11. Mai 2017 geboten.
Thema ist ein Überlick zu Active Directory Federation Services. Ergänzt wird die Präsentation durch einen AD FS Deep Dive Abschnitt, der mehr die technischen Details und Abläufe von AD FS darstellt.
Viel Spaß.
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
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 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.
Am 18 Oktober 2018 fand in den Räumlichkeiten der WIPA das Q3 2018 Treffen der Exchange User Group Berlin statt. (Der Termin wurde verschoben)
Die Präsenation behandelt die Migration von Öffentlichen Ordner alter Bauart (bis Exchange 2010) zu Öffentliche Ordnern neuer Bauart (ab Exchange Server 2013).
Am 22. Februar 2018 fand im Microsoft Accelerator Berlin das Q1 2018 Treffen der Exchange User Group Berlin statt.
Mein Vortrag zum Thema Bessere Zusammenarbeit mit OneDrive for Business | Moderne Dateianhänge mit Exchange 2016 und Office 365 steht als PowerPoint Präsenation bei Slideshare bereit und kann dort direkt heruntergeladen werden.
Am 31. Mai 2018 fand in den Räumlichkeiten der JAEMACOM das Q2 2018 Treffen der Exchange User Group Berlin statt.
Torsten Schlopsnies und ich haben das Open Source Projekt Master Category List Manager vorgestellt. Das Tool dient zum exportieren oder importieren der Hauptkategorieliste eines Exchange Postfaches. Die Kategorieliste eines Quellpostfaches kann direkt in ein anderes Benutzerpostfach oder geteiltes Postfach kopiert werden. Ebenso wird das Kopieren in einen Microsoft Teams Kalender unterstützt.
Der Quellcode wird in ca. 14 Tagen veröffentlicht.