Tu das NICHT! in Exchange Online
Krähe mit Hut
In der IT gibt es oftmals nicht nur "die eine" Lösung für alles. Konfigurationen, Störungen und Probleme können auf unterschiedliche Arten behandelt werden, beispielsweise über grafische Oberflächen, Kommandozeilen-Lösungen oder Dritthersteller-Werkzeuge. Auch mag die persönliche Herangehensweise sehr unterschiedlich sein. Das hat viel mit der eigenen Erfahrung, aber auch damit zu tun, wann man in die IT eingestiegen ist.
Daher ist eine Vorgehensweise nicht per se richtig oder falsch, nur weil sie nicht dem eigenen Ansatz entspricht. Es gibt jedoch Dinge, die IMMER falsch sind - unabhängig von Erfahrung, Einstieg oder persönlichen Vorlieben. Ja, es gibt sogar Dinge, die regelrecht Quatsch sind und daher auf keinen Fall gemacht werden sollten.
Dieser Beitrag ist Teil einer Serie von Dingen, die Du lieber nicht oder AUF KEINEN FALL tun solltest. In diesem Beitrag geht es um Exchange Online.
Modifiziere NICHT die Rolle "Organization Management"!
Diese Ermahnung könnte man eigentlich für alle Rollen in der Microsoft Cloud anwenden. Es soll aber einmal am Beispiel von Exchange Online erklärt werden, warum es eine schlechte Idee ist, Standardrollen zu modifizieren.
Das rollenbasierte Zugriffsmodell (RBAC)
Microsoft verwendet für seine Dienste das sogenannte rollenbasierte Zugriffsmodell (RBAC, Role Based Access Control). Die Rollen werden hierbei in Form von Gruppen bereitgestellt. Diesen Gruppen ist ein vordefinierter Satz an Berechtigungen für den jeweiligen Dienst zugewiesen. Benutzer können wiederum diesen Rollen zugewiesen werden und erhalten dadurch die Berechtigungen der Rolle.
Nun sind einige Rollen natürlich mit sehr weitreichenden Berechtigungen ausgestattet. Die Rolle Organization Management verfügt beispielsweise über vollständige administrative Berechtigungen für Exchange Online. Darüber hinaus - und da kommt bereits ein erster Knackpunkt ins Spiel - erteilt diese Rolle auch Berechtigungen für weitere Dienste wie bspw. das Defender-Portal (E-Mail-Sicherheit über Defender for Office 365) und das Purview-Portal (Aufbewahrungs- und MRM-Richtlinien).
Des Weiteren werden diese Rollen nicht nur für die Berechtigung von Benutzerkonten, sondern auch Microsoft-intern für automatisierte Prozesse genutzt.
Bitte nicht verändern!
Nun könnte jemand zu der Ansicht gelangen: "Die Rolle hat ja viel zu viele Rechte und Purview setzen wir eh nicht ein. Dann entferne ich mal diese Rollen!" Oder man entfernt die Rolle "Globaler Administrator" aus der Zuweisung, um dort Rechte zu beschränken.
Dies ist jedoch definitiv keine gute Idee!
Wie bereits ausgeführt, werden die Rollen auch im Hintergrund verwendet, um automatisiert Aufgaben auszuführen. Wenn nun Änderungen vorgenommen werden, kann es passieren, dass diese Aufgaben nicht mehr ausgeführt werden können und es zu Störungen kommt. Das Gefährliche hierbei ist, dass diese Störungen nicht immer sofort auftreten. Daher kann es zu einem späteren Zeitpunkt schwierig sein, die tatsächliche Ursache zu ermitteln.
Der folgende Beitrag zeigt anschaulich, welche Auswirkungen es haben kann, wenn Änderungen an der Rolle vorgenommen werden. In diesem Beispiel funktioniert der Exchange-Hybridbereitstellungsassistent nicht mehr, da ein Befehl nicht mehr gefunden wird: The term Get-OrganizationConfig is not recognized - ALI TAJRAN
Aus diesem Grund: lass die Rollen, wie sie sind! Wenn Du individuelle Anforderungen hast, erstelle stattdessen zusätzliche, benutzerdefinierte Rollen und verwende diese für Euer Rechte- und Rollenkonzept.
Führe KEINE Postfachverschiebungen durch!
In lokalen Exchange Server-Umgebungen ist es durchaus üblich, Postfächer zwischen Datenbanken zu verschieben. Dies kann sowohl über die grafische Oberfläche als auch mittels Exchange Management Shell beispielhaft wie folgt durchgeführt werden.
# Zunächst Exchange Management Shell starten oder zu Exchange Server verbinden, dann den folgenden Befehl ausführen
New-MoveRequest -Identity 'max.mustermann@microwsoft.de' -TargetDatabase 'MBX-DB-01'Wann brauche ich Postfachverschiebungen?
Es kann unterschiedliche Gründe geben, ein Postfach in eine andere Datenbank zu verschieben. Als Beispiele seien genannt:
- Leistungsprobleme in einer Datenbank
- Der Speicherplatz für die Datenbank geht zur Neige
- Es wird auf eine neuere Exchange-Version umgestellt (dies sollte jedoch spätestens mit der Subscription Edition ein Ende haben 😉)
Es ist jedoch ein Irrglaube, dass im Rahmen von Postfachverschiebungen auch Reparaturmaßnahmen am Postfach durchgeführt werden. Das Postfach wird einfach 1:1 - inklusive aller Fehler, soweit möglich - in die neue Datenbank übertragen. Treten hierbei zu viele Fehler auf, können diese ignoriert werden. Dies behebt sie jedoch nicht. Stattdessen werden die betroffenen Elemente nicht migriert.
Für Reparaturen steht ein eigener PowerShell-Befehl zur Verfügung. Details zu den Parametern können dem offiziellen Artikel entnommen werden: New-MailboxRepairRequest (ExchangePowerShell) | Microsoft Learn
# Neue Reparaturanforderung erstellen - der Parameter -Archive ist nur nötig, wenn das Postfach über ein Online-Archiv verfügt
New-MailboxRepairRequest -Mailbox 'max.mustermann@microwsoft.de' -CorruptionType AggregateCounts,FolderView,ProvisionedFolder,SearchFolder -ArchiveLass Exchange Online das selbst machen!
In Exchange Online hingegen gibt es diese Funktionalität so nicht - zumindest nicht in der grafischen Oberfläche. Hier können nur Verschiebungsanforderungen von/zu anderen Systemen (z.B. Exchange Server, Google Workspace) eingerichtet werden.
Exchange Online stellt wie Exchange Server auch einen Zugriff mittels PowerShell bereit. Da es einige weitere Funktionen gibt, die ausschließlich über PowerShell verfügbar sind, könnte man zur Ansicht gelangen, dass man auch hier weiterhin Verschiebungsanforderungen erstellen kann, beispielsweise im Fall einer Störung.
Dies ist jedoch definitiv keine gute Idee!
Exchange Online ist so konzipiert, dass Postfächer bis hin zu ganzen Organisationen intelligent und automatisch zwischen den Exchange-Clustern ausbalanciert werden. Hierfür sind entsprechende Automatismen eingerichtet. Wird nun manuell eine Verschiebungsanforderung eingerichtet, kann das diese Prozesse erheblich behindern. Der folgende Artikel beschreibt dies und Aussagen von Microsoft hierzu anschaulich: Microsoft warns IT admins against using this unsupported Exchange Online configuration - Neowin
Ebenso gibt Microsoft einen Hinweis auf die vorgesehene Verwendung im offiziellen Artikel zum Befehl: New-MoveRequest (ExchangePowerShell) | Microsoft Learn
Hinweis: Nach dem 15. April 2020 sollten Sie dieses Cmdlet nicht verwenden, um Postfächer innerhalb eines Exchange Online organization manuell zu verschieben. Sie können dieses Cmdlet nur für die Migration zu und von Exchange Online verwenden. Wenn Sie Probleme mit einem Postfach haben und dies durch Verschieben des Postfachs innerhalb Ihres Exchange Online organization beheben möchten, öffnen Sie stattdessen eine Microsoft-Support Anforderung.
Aus diesem Grund: vertraue den eingerichteten Automatismen in Exchange Online! Vergewissere Dich vor Benutzung eines PowerShell-Befehls immer, ob dieser für Exchange Online freigegeben ist oder nicht.
Importiere NICHT PST-Dateien über Outlook!
PST-Dateien waren früher ein weitverbreitetes Mittel, um Postfacharchive anzulegen. Somit konnten Benutzer ihr Postfach einigermaßen schlank halten und trotzdem weiterhin auf alle Mails zugreifen. Weiterhin werden PST-Dateien gern für Migrationen genutzt, da sich hier alle Inhalte eines Postfachs mitnehmen lassen. Migrationslösungen haben hier oftmals ein Problem, wenn in der Quellumgebung veraltete Protokolle wie POP und IMAP eingesetzt werden.
Von Benutzern geliebt, von der IT gehasst
Für Mitarbeitende im IT-Support sind sie jedoch meistens ein Gegenstand des Hasses, da sie einige Probleme mit sich bringen:
- Eine Ablage auf Netzlaufwerken wird nicht unterstützt
- Eine Ablage in OneDrive wird nicht empfohlen, da PST-Dateien ein älteres Format verwenden, welches für Synchronisationsprobleme sorgen kann
- Die Archivdateien sind sehr fragil und können schnell beschädigt werden. Dies macht eine Reparatur erforderlich, die bei größeren Dateien sehr lange dauern kann.
Aus diesen Gründen wird mittlerweile vom Einsatz von PST-Dateien generell abgeraten. Microsoft hat mit dem Online-Archiv eine moderne und einfach zu verwendende Alternative geschaffen. Die Empfehlung lautet daher, PST-Dateien in das Online-Archiv zu importieren.
PST-Dateien importieren - aber NICHT über Outlook!
Auch in lokalen Exchange Server-Umgebungen war es schon keine gute Idee, die PST-Dateien einfach wieder über Outlook zu importieren. Die Gründe dafür sind einfach:
- Die Import-Funktion ist nicht für große Datenmengen ausgelegt. Bricht der Import vorzeitig ab (bspw. aufgrund eines Programmabsturzes), muss er vollständig von neu gestartet werden. Zwar bietet die Import-Funktion eine Duplikaterkennung, dies beschleunigt den Import jedoch nicht wesentlich.
- Outlook ist für die Dauer des Imports vollständig blockiert. Daher kann der Benutzer Outlook solange nicht verwenden und muss auf Alternativen ausweichen (und nein, Vollzugriff auf das Postfach für den Admin und Import auf einem anderen System ist aus Gründen des Datenschutzes auch keine gute Idee! 😉).
- Der Exchange Cache-Modus ist nicht für das Hochladen größerer Datenmengen ausgelegt. Daher kann es im Anschluss an den Import zu erheblichen Leistungsproblemen in Outlook kommen.
Aus diesem Grund gibt es speziell hierfür einen eigenen PowerShell-Befehl in Exchange Server (erfordert die Zuweisung der Rolle 'Mailbox Import Export'):
# Zunächst eine Ordnerfreigabe anlegen und die zu importierenden PST-Dateien darin platzieren, dann den folgenden Befehl ausführen
New-MailboxImportRequest -Mailbox 'max.mustermann@microwsoft.de' -FilePath '\\<Servername>\<Freigabename>\Archive.pst -IsArchiveIn Exchange Online gibt es diesen Befehl leider nicht mehr - wahrscheinlich aus den gleichen Gründen wie New-MoveRequest (siehe oben). Hier ist stattdessen der Netzwerkupload-Dienst zu verwenden. Dabei werden die zu importierenden PST-Dateien in ein automatisch dafür bereitgestelltes Azure-Speicherkonto hochgeladen und mithilfe einer CSV-Datei zu den Postfächern zugeordnet, in die sie importiert werden sollen. Weitere Details hierzu enthält der folgende Artikel: Verwenden des Netzwerkuploads zum Importieren von PST-Dateien | Microsoft Learn
Verwende NICHT ein Mailsystem mit mehreren Exchange Online-Mandanten!
Exchange Online muss nicht in jedem Fall als primäres E-Mail-System verwendet werden. Es kann Fälle geben, in denen weiterhin ein lokales Mail-Gateway bereitgestellt wird, beispielsweise
- wenn eine Applikation oder ein System keine oder nur Basis-Authentifizierung beherrscht
- wenn ein E-Mail-Massenversand benötigt wird
- wenn Exchange Web Services verwendet werden müssen (diese werden in Exchange Online voraussichtlich Ende 2026 abgeschaltet).
Nutzung von Exchange Online für ausgehenden E-Mail-Verkehr
Man kann ein lokales Mail-Gateway hierbei so konfigurieren, dass ausgehende Mails über Exchange Online versendet werden, damit beispielsweise der dortige Mailfilter verwendet wird. Hierzu muss in Exchange Online ein Connector erstellt werden. Für die Autorisierung von Drittsystemen kann die öffentliche IP-Adresse des Systems oder ein Zertifikat verwendet werden,
Ein Zertifikat ist hierfür der wesentlich bessere Ansatz, da es ein höheres Maß an Sicherheit hinzufügt. Ein System muss zwingend über ein passendes Zertifikat verfügen, ansonsten wird die Verbindung abgelehnt. Bei öffentlichen IP-Adressen können keine weiteren Einschränkungen vorgenommen werden, so dass sich hinter der öffentlichen IP-Adresse auch ein Schadsystem verbergen könnte.
Das Zertifikat sollte so gewählt werden, dass es eine der akzeptierten Domänen enthält, da dies das höchste Maß an Sicherheit bietet. Prinzipiell kann jedoch auch nur auf Gültigkeit des Zertifikats geprüft werden.
Verwende ein passendes Zertifikat und eine 1:1-Beziehung!
Aus diesen beiden Abschwächungen (IP-Adresse und Verwendung eines beliebigen gültigen Zertifikats) können sich jedoch einige Fehlkonfigurationen ergeben.
Fall 1: Mehrere Systeme verwenden das gleiche Zertifikat, um sich gegenüber mehreren Exchange Online-Mandanten zu authentifizieren. Das Zertifikat enthält KEINE oder nur eine der akzeptierten Domänen aus einem der Mandanten.
Fall 2: Eine öffentliche IP-Adresse ist in mehreren Exchange Online-Mandanten für die E-Mail-Übermittlung erlaubt. Das kann z.B. dann auftreten, wenn ein Unternehmen im Zuge einer Integration bzw. einer Ausgliederung von einem Mandanten in einen anderen Mandanten migriert wird und Connectors doppelt angelegt werden.
Da Exchange Online eine Multi-Mandanten-Umgebung ist, greifen hier spezielle Mechanismen, um zu ermitteln, zu welchem Mandanten eine Nachricht gehört. Liegt eine der oben geschilderten Fehlkonfigurationen vor, kann Exchange Online eventuell nicht mehr den richtigen Mandanten ermitteln und die Übermittlung schlägt fehl. Ebenso können interne Prozesse wie Verschiebevorgänge zwischen den Exchange-Clustern dazu führen, dass solche Konfigurationen plötzlich nicht mehr funktionieren.
Microsoft beschreibt dies anschaulich in einem Beitrag im M365-Nachrichtencenter: https://admin.cloud.microsoft/?ref=MessageCenter/:/messages/MC1226222
Aus diesen Gründen:
- Verwende für jedes System ein individuelles Zertifikat, das eine akzeptierte Domäne beinhaltet. Konfiguriere den Connector so, dass er den Namen des Zertifikats prüft, nicht nur die Gültigkeit.
- Wenn Du öffentliche IP-Adressen verwenden musst, stelle sicher, dass diese nur in einem einzigen Exchange Online-Mandanten freigegeben sind.
Kennst Du noch weitere Dinge, die man NICHT in Exchange Online tun sollte? Dann lass einen Kommentar da!
Gefällt Dir der Beitrag? Lass es andere wissen!
