In ihrem Blogartikel Improving Security - Together hat die Exchange Produktgruppe angekündigt, die unsichere Authentifizierungsmethode Basic Authentication zum 13. Oktober 2020 nicht nur für die Exchange Web Services (EWS) abzuschalten, sondern zusätzlich auch für Exchange ActiveSync (EAS), POP, IMAP und Remote Exchange PowerShell.
Bei der Basic Authentication handelt es sich um eine in die Jahre gekommene Authentifizierungsmethode, die im Vergleich zu modernen Authentifizierungsmethoden Schwächen hat. Diese Schwächen führen dazu, dass diese Authentifizierungsmethode immer wieder von Angreifern verwendet wird, um unberechtigten Zugriff auf Ressourcen zu erlangen. Exchange Online und Azure AD sind, als globale Clouddienste, immens vielen Angriffen dieser Art ausgesetzt.
Die moderne Authentifizierung (Modern Auth), basierend auf OAuth 2.0, bietet im Zusammenspiel mit Multi-Faktor-Authentifizierung (MFA) einen umfassenderen Schutz für den Zugriff auf Exchange Online und andere Cloud-Ressourcen. Diese Art der Authentifizierung ist nicht neu, setzt sich für bestimmte Zugriffsarten aber nur langsam durch. Die Unterstützung für Modern Auth wird bereits seit Office 2013 unterstützt und ist seit Version 2016 nativ in das Produkt integriert.
Für mobile Endgeräte stellt sich die Situation etwas anders dar. In vielen Fällen erfolgt der Zugriff auf Exchange Online Postfächer mit nativen E-Mail-Clients der mobilen Endgeräte statt. Diese verwenden in den meisten Fällen das ActiveSync-Protokoll (EAS). EAS wiederum bedient sich standardmäßig der Basic Authentifizierung und ist daher für die Zukunft nicht mehr das passende Protokoll für den Zugriff auf Exchange Online. Hier ist Outlook Mobile (Android/iOS) die bessere Alternative. Mit Outlook Mobile haben Sie die Möglichkeit, die Authentifizierung der Benutzerkonten zusätzlich mit MFA abzusichern.
Für die Protokolle SMTP, POP und IMAP gibt es eine besondere Herausforderungen. Diese Protokolle unterstützen heute die moderne Authentifizierung (noch) nicht. Für den Zugriff auf Mitarbeiter-Postfächer stellt dies noch keine Problem dar, da dieser Zugriff immer über das Protokoll MAPIoverHTTP erfolgen sollte. Das eigentliche Problem sind all die anderen Applikationen, die Sie gegenwärtig für einen POP/IMAP-Postfachzugriff und SMTP-Mailversand über ein Exchange Online Postfach konfiguriert haben. Hierzu gehören z.B. Ticketsysteme, ERP-Lösungen oder individuell programmierte Line-of-Business-Applikationen (LOB).
Ähnlich sieht es für die Authentifizierung von PowerShell-Skripten aus, die auf einem Ihrer internen Skript-Server ausgeführt werden und Aktionen gegen Exchange Online ausführen. Für die direkte Anmeldung an die Exchange Online PowerShell mit Modern Auth können Sie bereits heute das Exchange Online PowerShell Modul mit MFA oder die Azure Cloud Shell verwenden.
Die Deaktivierung der Basic Authentication für Exchange Online hat direkte Auswirkungen auf die von Ihnen betreute IT-Infrastruktur. Um eine Unterbrechung im Zugriff auf Exchange Online-Ressourcen zu vermeiden, müssen Sie wissen, mit welchen Protokollen Anwender und Applikationen auf Exchange Online-Endpunkte zugreifen. Die Exchange Produktgruppe plant ein Software-Tool zur Auswertung bereitzustellen, dass Sie bei der Analyse der Zugriffsarten unterstützt.
Für den Zugriff auf Exchange Postfächer von Windows Desktops ist die Maßnahme einfach. Wenn Sie noch ältere Windows Desktop Betriebssystem im Unternehmen einsetzen, wechseln Sie auf Windows 10 als Standard-Betriebssystem und migrieren Sie die Office-Installation zu Office 2019 bzw. Office 365 ProPlus.
Nutzen Sie Outlook Mobile für den Zugriff auf Exchange Online Postfächer. Outlook Mobile lässt sich über die gängigen Mobile Device Management (MDM) Lösungen zentral auf mobile Endgeräte verteilen und konfigurieren. Mit Hilfe von Mobile Application Management (MAM) und Conditional Access können Sie die Sicherheit beim mobilen Zugriff auf Exchange Online Postfächer noch weiter erhöhen.
Für automatisierte PowerShell-Skripte wird die Anpassung auf Modern Auth schwieriger. Sie können für die Ausführung der Skripte in der lokalen IT-Infrastruktur das Exchange Online PowerShell Modul mit MFA implementieren. Hierbei müssen Sie allerdings bedenken, dass Skripte mit einer längeren Ausführungszeit in technische Probleme laufen werden. Wenn Ihre Skripte von Timeouts und Skriptverzögerungen, sog. Micro Delays, betroffen sind, müssen Sie die Strategie zur Skriptausführung überdenken und den Skript-Code anpassen. Eventuell ist es vorteilhafter, eine professionelle Softwarelösung zur Ausführung von Skripten einzusetzen, die Modern Auth nativ unterstützt. PowerShell-Skripte, die nur Aktionen gegen Exchange Online oder anderen Office 365 Endpunkten ausführen, können auch in Azure Automation betrieben werden.
Wichtig ist auch noch einmal der Hinweis, dass sich die Deaktivierung der Basic Authentifizierung auf Exchange Online bezieht. Die On-Premises Variante von Exchange Server 2019 ist davon nicht betroffen.
Die Exchange Produktgruppe ist sich der Herausforderungen für die Kunden bewusst. Der Titel des Original-Artikels Improving Security - Together ist mit Bedacht gewählt. Ein besserer Schutz von Exchange Online Postfächern und Ressourcen ist nur möglich, wenn die Erhöhung der Sicherheit gemeinsam, also von Ihnen als Office 365 Kunde und der Exchange Produktgruppe, umgesetzt wird.
Bereiten Sie sich und Ihre IT-Infrastruktur rechtzeitig auf die Abschaltung der Basic Authentication vor. Erstellen Sie einen realistischen Zeitplan für die notwendigen Konfigurationen und Anpassungen, um spätestens im Juli 2020 die Umstellung abgeschlossen zu haben. Es hat sich schon immer bewährt, einen zeitliche Puffer einzuplanen.
Die Erhöhung der Sicherheit geht immer mit Komfortverlust einher. Dieser Komfortverlust ist jedoch zu verschmerzen, wenn man den Sicherheitsgewinn gegenüberstellt.
Viel Spaß mit Exchange Online!
Exchange Server 2019 ist die aktuelle Version der E-Mail-Messaging Plattform für die Installation in der lokalten IT-Infrastruktur (aka On-Premises). Als lokale Infrastruktur gilt auch die Nutzung von Exchange Server 2019 auf virtualisiserten Serversystemen in Microsoft Azure. Bei Microsoft handelt sich, technisch gesehen, nur um ein ausgelagertes Rechenzentrum. Als wirkliche Alternative zu einem eigenen Betrieb von Exchange Server 2019 steht Ihnen Exchange Online, als Bestandteil des Software-as-a-Service Angebotes von Office 365, zur Verfügung.
Der Betrieb von Exchange Server 2019, die hybride Verbindung zwischen einer lokalen Exchange Organisation und Exchange Online oder die alleinige Nutzung von Exchange Online erfordern eine detaillierte Planung und Vorbereitung.
Auf dieser Seite finden Sie die wichtigsten Referenz-Links zu Online Ressourcen von Microsoft und anderen Quellen, um das für Sie richtige Exchange Produkt zu installieren, einzurichten und zu betreiben.
Wie einleitend schon ausgeführt, kann Exchange grundsätzlich in vier unterschiedlichen Architekturmodellen betrieben werden, die ihre ganz individuellen Vor- und Nachteile bieten. Diese sind:
= kontrolliert durch Microsoft = kontrolliert durch Kunden
Der Betrieb und die vollständige Verwaltung von Exchange Server erfordern die Verwendung der Exchange Management Shell (EMS). Mit Hilfe des browserbasierten Exchange Admin Center (EAC) können Sie Gelegenheitsaufgaben durchführen. Dies gilt für Exchange Server 2019 ebenso wie für Exchange Online.
Viel Spaß mit Exchange Server 2019 und Exchange Online.
Sie benötigen Hilfe bei der Planung und Installation Ihrer Exchange Server Installation? Sie haben Fragen über Ihre bestehende Exchange Server Infrastruktur und möchten Exchange Online implementieren? Kontaktieren Sie uns per E-Mail info@granikos.eu oder besuchen Sie unsere Webseite http://www.granikos.eu
Eine lokale Exchange Organisation eines Unternehmens kann mit Exchange Online, einer der Kernbestandteile von Microsoft 365, verbunden werden. Diese Verbindung erfolgt durch die sog. Hybrid-Konfiguration und ist eine besondere Vertrauensstellung zwischen zwei technisch getrennten Exchange Umgebungen.
Diese besondere Vertrauensstellung zwischen der lokalen Exchange Organisation und Exchange Online ist notwendig, damit E-Mail- und System-Nachrichten, die zwischen beiden Umgebungen unsgetauscht werden, als interne E-Mail-Nachrichten erkannt und verarbeitet werden. Nur so ist es möglich, die korrekte Funktion aller Exchange Komponenten, unabhängig vom Bereitstellungsort der Benutzerpostfächer, zu gewährleisten.
Welche Vorteile ein Exchange Hybrid-Betrieb für die Exchange Umgebung in Ihrem Unternehmen hat, erfahren Sie in diesem Microsoft Docs Artikel.
Das folgende Schaubild verdeutlicht die Hybrid-Konfiguration und die besondere Vertrauensstellung (gepunktete grüne Linie).
Eine Exchange Hybrid-Konfiguration richten Sie mit Hilfe des Hybrid Confguration Wizard (HCW) ein. Während der HCW-Einrichtung müssen Sie sich für eine der zur Verfügung stehenden Möglichkeiten für den Hybrid-Betrieb entscheiden.
Für den Hybrid-Betrieb einer lokalen Exchange Organisation mit Exchange Online gibt es mehrere Möglichkeiten. Wir unterscheiden zwei grundlegende Betriebsvarianten, den klassischen und den modernen Hybrid-Betrieb. Für diese beiden Varianten stehen je bis zu drei Betriebsmodi zur Verfügung.
Das folgende Schaubild verdeutlich die unterschiedlichen Betriebsmodi für die beiden Betriebsvarianten einer Hybrid-Konfiguration.
Nun stellt sich automatisch die Frage, welchen Betriebsmodus soll ich für Hybrid-Konfiguration meiner Exchange Organisation verwenden?
Schauen wir uns zuerst an, welche technischen Voraussetzungen die beiden Betriebsvarianten haben.
Der klassische Hybrid-Betrieb erfordert, dass interne Exchange Server aus dem Internet über das Protokoll HTTPS erreichbar sind. Über diese Verbindung erfolgt die Kommunikation von Exchange Online zur internen Exchange Organisation für Hybrid-Funktionen. Damit einher geht die Anforderung für eine aus dem Internet erreichbare IP-Adresse und die Verwendung eines offiziellen TLS-Zertifkates.
Der moderne Hybrid-Betrieb erfordert keinerlei eingehende HTTPS-Verbindung von Exchange Online zur internen Exchange Organisation.
Die Verbindung zwischen der lokalen Exchange Organisation und Exchange Online erfolgt über den Exchange Hybrid Agent. Die Software für den Exchange Hybrid Agent ist als Dienst auf einem Server installiert und verbindet sich über eine ausgehende HTTPS-Verbindung mit Exchange Online. Die Konfiguration durch den HCW steuert hierbei das Verhalten von Exchange Online. Mit Blick auf den Hybrid-Betrieb von Exchange ist dies die bevorzugte und schnellste Betriebsvariante, da keinerlei zusätzliche Komponenten für eingehende HTTPS-Verbindungen benötigt werden. Wenn Ihr Unternehmen jedoch Microsoft Teams verwenden möchte und weiterhin Postfächer von Teams-Anwendern auf lokalen Exchange Servern betrieben werden sollen, können Sie diese Betriebsvariante nicht nutzen. Microsoft Teams unterstützt für dieses Betriebsszenario nur den klassischen Hybrid-Betrieb.
Für welches Betriebs- und Migrationsszenario passen die fünf Betriebsmodi?
Vollwertige, klassische Hybrid-Konfiguration mit direkter Veröffentlichung der Exchange Organisation ins Internet (SMTP/HTTPS)
Hybrid-Konfiguration, inkl. Azure AD Connect, zum einmaligen Verschieben aller Postfächer zu Exchange Online
Hybrid-Konfiguration, inkl. Azure AD Connect Express Setup, zum einmaligen Verschieben aller Postfächer zu Exchange Online
Vollwertige, klassische Hybrid-Konfiguration für neue Konfigurationen mit Hilfe des Exchange Hybrid-Agenten, jedoch mit Funktionseinschränken
Hybrid-Konfiguration, inkl. Azure AD Connect, zum einmaligen Verschieben aller Postfächer zu Exchange Online mit Hilfe des Exchange Hybrid-Agenten
Die Implementierung eines Hybrid-Betriebes stellt Ihr Unternehmen vor technische Herausforderungen. Daher muss die Einrichtung des hybriden Exchange Betriebes gut geplant werden.
Für den klassischen Hybrid-Betrieb benötigen Sie externe IP-Adressen für die beiden Protokolle HTTPS und SMTP, während für den modernen Hybrid-Betrieb nur eine IP-Adresse für das Protokoll SMTP benötigt wird. Ebenso benötigen Sie TLS-Zertifikate. Für den Nachrichtenfluss zwischen der lokalen Exchange Organisation und Exchange Online empfehle ich, ein separates TLS-Zertifikat zu verwenden, das nicht für das E-Mail-Internet-Gateway verwendet wird.
Die Absicherung der internen Exchange Server vor direkten Zugriffen aus dem Internet hat höchste Priorität. Sichern Sie den E-Mail-Nachrichtenfluss der hybriden Verbindung zwischen der lokalen Exchange Organisation und Exchange Online mit Exchange Edge-Servern ab. Der HTTPS-Zugriff zu den internen Exchange Server von Exchange Online wird über Reverse-Proxies abgesichert.
Bei einem dauerhaften Hybrid-Betrieb ist die lokale Exchange Organisation für die Verwaltung der zu Exchange Online verschobenen Exchange-Objekte zuständig. Im Zusammenspiel mit dem lokalen Active Directory bleibt sie die Source of Authority (SOA). Aus diesem Grund benötigen Sie mindestens einen verbleibenden lokalen Exchange Server, der als sog. Koexistenz-Server betrieben wird. Hierzu sollten Sie einen System mit Exchange Server 2016 oder Exchange Server 2019 verwenden.
Mit einer Auswahl von zwei Betriebsvarianten und insgesamt fünf Betriebsmodi fällt es nicht leicht, die passende Wahl zu treffen. Die wichtigste Frage, die Sie sich zuerst stellen müssen ist, wie soll die Bereitstellung von Exchange Funktionen in Zukunft für das Unternehmen aussehen und welche Anforderungen hat das Unternehmen im Hinblick auf die Absicherung von E-Mail-Nachrichten? Sind Anwender-Postfächer in der lokalen Exchange Organisation bereitgestellt und in Ihrem Unternehmen soll Microsoft Teams genutzt werden, so ist die klassische Voll-Hybrid-Variante die einzige Option.
Die größte Flexibilität erreichen Sie mit dem klassischen Hybrid-Betrieb, jedoch ist dies auch die Variante mit den meisten Anforderungen zur Einrichtung und den dauerhaften Betrieb.
Mit dem modernen Hybrid-Betrieb erreichen Sie schnell eine Hybrid-Konfiguration und können zügig Postfächer zu Exchange Online migrieren. Bei Nutzung von Microsoft Teams und Anwender-Postfächern in der lokalen Exchange Organisation ist dies jedoch keine Option.
Viel Spaß mit einem sicheren Exchange Online.
Die Exchange Web Services (EWS) sind seit Exchange Server 2007 ein integraler Bestandteil von Exchange. Sie werden nicht nur von Exchange Server und Exchange Online für die Kommunikation zwischen Exchange Servern und als Teil der Hybrid-Kommunikation verwendet. Die Web-Services werden ebenfalls von E-Mail-Clients verwendet. EWS ist ein SOAP-basiertes API und ist inzwischen durch modernere Protokolle überholt worden. Bereits im Jahr 2018 hat die Exchange Produktgruppe angekündigt, dass es keine Weiterentwicklung für das EWS-Protokoll in Exchange Online geben wird. Indirekt wurde diese Änderung auch für Exchange Server angekündigt, nachdem die EWS Managed API auf GitHub veröffentlicht wurde.
Der EWS-Zugriff auf Exchange Online wird ersetzt durch Microsoft Graph. Diese Änderung wurde ebenfalls bereits im Sommer des Jahres 2018 im Microsoft Developer Blog angekündigt. In diesem Zusammenhang haben sowohl die Exchange als auch die Microsoft Graph Produktgruppen auf das nahende Ende der Unterstützung der Basic Authentifizierung für EWS in Exchange Online hingewiesen.
Die vollständige Außerbetriebnahme der Exchange Web Services in Exchange Online ist kein leichtes Unterfangen. Da zahlreiche E-Mail-Clients und andere Softwareprodukte auf dem EWS API-Zugriff basieren, erfolgt die Außerbetriebnahme phasenweise.
Ab wo starten? Die Online-Dokumentation für Exchange Online bietet Ihnen hier mehrere Einstiegspunkte, um sich mit den der Microsoft Graph API für Exchange Online und der REST-API für die lokale Exchange Organisation vertraut zu machen.
Im ersten Schritt betreffen die Änderungen der EWS-Schnittstelle hauptsächlich Partner, die Softwarelösungen für Exchange Online entwickeln. Diese Partner wissen bereits seit 2018, dass es Änderungen geben wird.
Die API-Funktionen, die ab September 2022 außer Betrieb genommen werden, sind Funktionen, die nur selten oder gar nicht verwendet werden. Dies betrifft insbesondere Unified Messaging-Funktionen, die inzwischen nicht mehr durch Exchange Online realisiert werden. Jedes API-Interface stellt auch ein potenzielles Sicherheitsrisiko dar. Somit führt die Reduzierung der EWS API automatisch zu einer Reduzierung der Angriffsfläche von Exchange Online.
Ab September 2022 werden folgende EWS APIs abgeschaltet:
Für einige dieser API-Funktionen finden Sie Informationen in der veralteten EWS XML-Dokumentation. Diese Dokumentation ist seit dem Jahr 2015 nicht mehr aktualisiert worden.
Wenn Sie eine Softwarelösung für Exchange Online entwickelt haben und die Funktion auch für die Zukunft sicherstellen möchten, so müssen Sie Ihren Code für die Nutzung von Microsoft Graph umstellen. Dies betrifft nicht nur serverbasierte Softwarelösungen, sondern ebenfalls moderne Outlook Add-Ins, die mit Exchange Online interagieren sollen.
Die Abkündigung der EWS-API kommt nicht überraschend. Sie ist Teil des Maßnahmenkataloges, die Angriffsoberfläche des Clouddienstes Exchange Online zu reduzieren. Hierzu gehört auch die Deaktivierung der Basic Authentifizierung. Es ist wichtig, dass Sie beide Themen, EWS API und Basic Auth, bei Ihren Architekturplanungen für eine Softwarelösung berücksichtigen. Die Nutzung von Microsoft Graph bedeutet auch eine Umstellung der Authentifizierung.
Die Funktionsreduzierung der Exchange Web Services in Exchange Online hat eine direkte Auswirkung auf die von Exchange Online unterstützten E-Mail-Clients. Die für 2022 angekündigten Änderungen haben somit nicht nur Auswirkungen für Softwareentwickler. Um Ihren Anwendern weiterhin einen funktionieren E-Mail-Client bereitstellen zu können, müssen Sie sich mit dem Life-Cycle der unterstützen E-Mail-Clients auseinandersetzen.
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.
Die Auswirkung der COVID-19 Krise treffen auch die IT-Abteilungen der Unternehmen. Die Prioritäten von Aufgaben und Projekten haben sich in den letzten Wochen "spontan" geändert. Ehemals wichtige Projekte wurden auf "unbestimmte Zeit" verschoben.
Diese Situation ist der Exchange Produktgruppe bei Microsoft ebenfalls bewusst. Als Reaktion auf die aktuellen Herausforderungen für IT-Abteilungen ändert die Produktgruppe den Fahrplan für die geplante Deaktivierung der Basic Authentifizierung in Exchange Online.
Basic Authentication ist eine unsichere Authentifizierungsmethode und stellt grundsätzlich ein Risiko für die gesamte Exchange Online Plattform dar. Diese Authentifizierung stellt einen der größten Angriffsvektoren für Exchange Online dar.
Im Rahmen seiner Präsentation Securing Exchange Online from Modern Threats stellte Brandon Koeller (BRK3248) auf der Ignite 2019 vor, welche Angriffsszenarien Microsoft in Exchange Online beobachtet, wie darauf in der Plattform reagiert.
Die Deaktivierung von Basic Authentication für Exchange Online ist in diesem Zusammenhang ein große Aufgabe, die keinerlei Aufschub erlaubt.
Folgende Zeilen aus meinen Blogartikel von Oktober 2019:
Die Exchange Produktgruppe ist sich der Herausforderungen für die Kunden bewusst. Der Titel des Original-Artikels Improving Security - Together ist mit Bedacht gewählt. Ein besserer Schutz von Exchange Online Postfächern und Ressourcen ist nur möglich, wenn die Erhöhung der Sicherheit gemeinsam, also von Ihnen als Office 365 Kunde und der Exchange Produktgruppe, umgesetzt wird. Bereiten Sie sich und Ihre IT-Infrastruktur rechtzeitig auf die Abschaltung der Basic Authentication vor. Erstellen Sie einen realistischen Zeitplan für die notwendigen Konfigurationen und Anpassungen, um spätestens im Juli 2020 die Umstellung abgeschlossen zu haben. Es hat sich schon immer bewährt, einen zeitliche Puffer einzuplanen. Die Erhöhung der Sicherheit geht immer mit Komfortverlust einher. Dieser Komfortverlust ist jedoch zu verschmerzen, wenn man den Sicherheitsgewinn gegenüberstellt.
Die aktuellen Herausforderungen der COVID-19 Krise haben uns in der IT zum großen Teil kalt erwischt. In kürzester Zeit mussten Möglichkeiten zur Remote-Arbeit für MItarbeiter eingerichtet und technische Implementierungen skaliert werden. Diese Arbeiten bestimmen zum großen Teil auch aktuell noch das tägliche Arbeitsleben in den IT-Abteilungen weltweit.
Nichtsdestotrotz sollten Sie dem Thema Deaktivierung von Basic Authentication für meinen Microsoft 365-Mandaten keinen Aufschub gönnen. Bewerten Sie die Wichtigkeit der aktuell pausierten IT-Projekte auch vorausschauend hinsichtlich der Sicherheitsrisiken für Ihre Exchange Online Ressourcen. Bewerten Sie in diesem Zusammenhang insbesondere das Verhalten der Anwender in Ihrem Unternehmen.
Je nach Größe des Unternehmens ist das Thema komplex. Sie müssen sich einen Überblick über die Clients und die Applikationen verschaffen, die auf Exchange Online Ressourcen zugreifen und welche Authentifizierungsverfahren im Einzelnen verwendet werden. Hierzu finden Sie in meinem Blogartikel von Oktober 2019 weitere Informationen im Abschnitt Was muss ich tun?.
Sie werden sicher denken, dass bis zur zweiten Jahreshälfte 2021 noch ausreichend Zeit zur Umsetzung dieses Thema ist. Dieses Gefühl teile ich nicht. Wir können aktuell nicht absehen, wie lange die COVID-19 Krise vorhalten wird und wie sie sich in den nächsten Monaten auf unsere Arbeit in der IT auswirken wird. Daher ist eine rechtzeitige Planung und Durchführung des Projektes zur Abschaltung der Basic Authentication dringend geboten.
Denken Sie auch daran, dass Sie auch vor der zweiten Jahreshälfte 2021 eigenständig die Auithentifizierung per Basic Auth für Ihren Microsoft 365 Mandaten blockieren können.
Viel Spaß mit Exchange Online. Stay safe.
Sie benötigen Hilfe bei der Entscheidung für oder gegen einen Wechel zu Microsoft 365? Unser Microsoft 365 Workshop hilft Ihnen, die für Ihr Unternehmen passenden Entscheidungen zu treffen.
Melden Sie sich bei uns: info@granikos.eu
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.