Effizient mailen

von Christian Schulenburg

Die Anzahl der täglich eintreffenden E-Mails nimmt stetig zu und die 2-GByte-Grenze bei der Postfachgröße ist in den meisten Fällen gezählt. Dieser Workshop beleuchtet neben Empfehlungen zur Storage-Konfiguration von Exchange 2019 auch die Nutzung von Größenbeschränkungen und der Archivfunktion, um das Wachstum koordiniert zu lenken. Grundlage bildet dabei die Prefered Architecture für Exchange-Storage und das Handling der Datenbanken, bevor wir im weiteren Verlauf aufzeigen, wie Sie bei der täglichen E-Mail-Flut das Wachstum in Grenzen halten können.

Microsoft hat bereits viele White Paper und Best-Practice-Anleitungen für Exchange 2019 veröffentlicht, das wichtigste mit dem empfohlenen Deployment ist die "Preferred Architecture" [1]. Darin gehen die Autoren davon aus, dass je komplexer eine Umgebung ist, desto unvorhersehbarer sind deren Fehler. Es gibt keinen Bereich in der IT, der gegen Fehler gefeit ist. Microsoft hat dies als Grundsatz genommen, um die Architektur der empfohlenen Installation deutlich zu verändern. Redundanzen, angefangen von einem zweiten Netzteil bis hin zu einer ausgereiften SAN-Infrastruktur, spielen in der Betrachtung für Exchange 2019 keine Rolle. Die Umgebung wird vereinfacht und der Fehlerfall planbar, sodass alles in einem vorhersehbaren Wiederherstellungsmodel mündet. Gerade die Vereinfachung ist ein sehr wichtiger Punkt und bezieht sich nicht nur auf die reine Konfiguration, sondern auch auf die Ausstattung der Server.

Reduzierte Anforderungen an Exchange-Speicher

Physisch oder virtuell ist heute kaum noch eine Frage, denn in die meisten Rechenzentren haben virtuelle Strukturen Einzug gehalten, um Ressourcen effizient zu nutzen. Im Bereich von Exchange 2019 hat Microsoft diesen Pfad verlassen und bevorzugt den Einsatz von physischen Low-Cost-Servern. Dies vor allem, um Ressourcen umfänglicher zu nutzen und die Komplexität durch die zusätzliche Virtualisierungsschicht zu entfernen. Dabei wird auf verschiedenste Redundanzen auf Serverebene verzichtet und auf integrierte native Exchange-Sicherungsmechanismen gesetzt. In diesem Zusammenhang spricht Microsoft von "Exchange Native Data Protection", das auch ohne Backup die Mailbox-Datenbank umfänglich schützt. Dabei müssen mindestens drei Kopien einer Mailbox-Datenbank vorhanden sein, damit im Fehlerfall eine andere Datenbank aktiviert wird und ein Reseed der defekten Datenbank nach Fehlerbeseitigung erfolgt. Eine vierte Kopie läuft zusätzlich als "Lagged Mailbox Database Copy". Ein Backup ist nur noch optional und richtet sich an die Bedürfnisse der Organisation.

Ein wichtiger Faktor bei der Konfiguration eines Exchange-Servers war bisher die Festplattenperformance. Diese Anforderungen hat Microsoft in Exchange 2019 bezogen auf ältere Versionen deutlich reduziert. Im Vergleich zu Exchange 2003 verringern sich die notwendigen IOPS um über 90 Prozent. Dies hat auch Auswirkungen auf die Speicherarchitektur: Für das Betriebssystem sowie die Exchange-Dateien und -Protokolle sollte jedem Server ein RAID1-Festplattenpaar zur Verfügung stehen. Neu ist seit Exchange 2013, dass die Datenbanken auf möglichst große SAS-Festplatten mit 7200 RPM in einem JBOD verteilt werden. SAS-Festplatten sind SATA-Festplatten aufgrund der besseren Performance und der geringeren Fehlerrate vorzuziehen. Als Dateisystem sollte für die Datenbanken das Resilient File System (ReFS) zum Einsatz kommen und BitLocker sorgt dabei für die Verschlüsselung der Daten. Eine teure SAN-Umgebung ist für einen hochverfügbaren Betrieb von Exchange nicht nötig.

Mit Exchange 2019 hat sich das Storage-Design weiterentwickelt und setzt auf das Tiering mit SSDs. Nachdem die Exchange-Entwickler über Jahre rein auf Low-Cost-Speicher gesetzt hatten, kam es hier zu einer Strategieänderung. Auf den SSDs werden bestimmte Daten ausgelagert, um die Nutzererfahrung zum Beispiel bei der Anmeldung oder den Datenabruf weiter zu verbessern. Die neue Cache-Datenbank hat den Namen MetaCache Database (MCDB), läuft auf schnellen SSDs und enthält bis zu zehn Prozent der eigentlichen Postfachdaten. Ein Disklayout nach Microsoft Best Practices sieht zukünftig wie folgt aus:

- Zwei HDDs für das Betriebssystem und Exchange 2019

- Zwölf HDDs für Exchange-Datenbanken und -Logs

- Eine HDD als DAG AutoReseed Spare Disk

- Vier SSDs für die Metacache-DB

Microsoft hat für das Sizing einen Requirement Calculator für Exchange 2019 veröffentlicht, an dem Sie sich zu den Anforderungen an den Storage und die Hardware orientieren sollten. Den Rechner finden Sie unter [2], aber auch weiterhin auf dem Installationsmedium von Exchange im Unterordner "Support". Eine Anleitung dazu bietet [3].

Ablage der Datenbanken

Jede Neuinstallation eines Exchange-Servers legt automatisch eine Postfachdatenbank im Installationsverzeichnis von Exchange an. Bei Exchange 2019 finden Sie diese unter dem Pfad "C:\Program Files \ Microsoft \ Exchange Server \ V15 \ Mailbox\". In dem Verzeichnis befinden sich ebenfalls die Transaktionsprotokolle. Als Dateisystem für Postfachdatenbanken empfiehlt Microsoft unter Exchange 2019 das Resilient File System (ReFS). ReFS wurde mit Windows Server 2012 eingeführt und ist für große Datenmengen optimiert. Es empfiehlt sich, die Verteilung von Datenbanken und Protokollen nach dem "Exchange Server Role Requirements Calculator" durchzuführen. Dieser ist wie erwähnt Bestandteil der ISO-Datei.

Bei der Verteilung der Datenbanken beziehungsweise der Logs ist es immer eine gute Empfehlung, Datenbanken von Protokollen zu trennen. Im Fehlerfall ist nur ein Teil betroffen, sodass Sie entweder eine recht aktuelle Datenbank haben oder alternativ den aktuellen Stand mithilfe einer älteren DB und den Logs wiederherstellen können. Die Aussage kann aber nicht mehr pauschal im Raum stehen, da sie in einer Database Availability Group (DAG) nicht relevant ist und es immer eine funktionierende Kopie gibt.

Datenbanken verschieben

Nach der Neuinstallation eines Exchange-Servers liegt, wie bereits beschrieben, automatisch eine Datenbank im Installationsverzeichnis. Dieser Pfad ist nicht optimal, weshalb Sie die Datenbank verschieben sollten. Die Aktion ist über das Exchange Administration Center (EAC) nicht möglich und Sie müssen die Exchange Management Shell (EMS) mit dem PowerShell-Befehl "Move-Data-basePath" ausführen. Geben Sie dabei den Pfad für die Datenbanken als auch die Protokolldateien an. Den Namen der EDB-Datei müssen Sie dabei explizit nutzen und dieser lässt sich über diesen Weg auch ändern. So wird aus dem kryptischen Dateinamen "Mailbox Database 123456789.edb" automatisch "MBXDB01. edb". Im folgenden Beispiel finden Sie den kompletten Aufruf:

Den Namen der DB ändern Sie in diesem Zusammenhang am schnellsten so:

Prüfen Sie das Ergebnis in der EAC in den Eigenschaften der Datenbank oder in der EMS:

Sofern Sie in einer DAG arbeiten, ist das Verschieben der Datenbank nicht ohne Weiteres möglich. Hier entfernen Sie zunächst alle Kopien einer Datenbank. Im Anschluss verschieben Sie die aktive DB und erstellen von dieser neue Kopien auf den anderen Exchange-Servern.

Während des Verschiebens ist die Datenbank nicht verfügbar, was gerade bei großen DBs mit vielen Nutzern ein Problem ist. Sofern es der Speicherplatz zulässt, erstellen Sie am Zielort eine neue Datenbank und verschieben Sie die Mailboxen aus der alten in die neuen DBs. Das Bewegen der Postfächer erfolgt online und beeinflusst die Benutzer nicht. Außerdem bietet das Vorgehen den Vorteil, dass Speicherplatz freigegeben und die neue Datenbank neu befüllt wird. Den Verschiebevorgang von Benutzerpostfächern starten Sie in der EAC direkt am Postfach.

Verwalten der Datenbanken

Die Datenbanken verwalten Sie über das EAC unter dem Punkt "Server". Hier sehen Sie alle auf einem Server vorhandenen Datenbanken. In dem EAC lassen sich verschiedene Aktionen ausführen, wie das Erstellen, Löschen, Mounten oder Unmounten. Die Administration ist ebenfalls über die EMS möglich und die aktuellen Datenbanken zeigen Sie sich zum Beispiel über an. Mit passen Sie die Einstellungen an.

In dem EAC fasst "Allgemein" viele wichtige Informationen wie den Datenbankpfad und zum Thema Backup zusammen. Eine Anpassung ist in diesem Bereich nur beim Namen möglich. Neben dieser Einstellung legen Sie in den anderen Menüpunkten weitere Konfigurationen zu den Grenzwerten und zur Wartung fest. Mit den Grenzwerten verhindern Sie, dass die Postfächer unkontrolliert anwachsen. Dadurch planen Sie indirekt das Wachstum der Datenbanken und verhindern ein unkontrolliertes Ansteigen eines Postfaches. Definieren Sie immer eine Maximalgrenze, damit das Datenbanklaufwerk nicht vollläuft, auch wenn es Ihnen utopisch vorkommt. Nichts ist schlimmer als ein überfülltes Postfach durch eine E-Mail-Schleife, die Exchange gegebenenfalls nicht erkennt, und die zu einem Volllaufen der Festplatte mit den Datenbanken führt.

Bei jeder neuen Datenbank werden die Einstellungen der Datenbank automatisch auf eine maximale Postfachgröße von 2 GByte festgelegt. Sie finden die Einstellung in der Eigenschaft der Datenbank im Abschnitt "Server / Datenbanken". Dabei unterscheidet das System, wann ein Nutzer zunächst nur eine Warnung über das Volllaufen erhält, ab welcher Größe er nicht mehr senden darf und wann zum Schluss auch der Empfang nicht mehr möglich ist. Die Einstellungen setzen Sie ebenfalls über die EAC oder die Shell, zum Beispiel:

Die Datenbankeinstellungen fragen Sie über die gleichen Parameter, aber mit dem zugehörigen Get-Befehl ab:

Ausnahmen für Grenzwerte von Postfächern in einer Datenbank lassen sich über die Eigenschaften des Postfachs einrichten. Die Einstellung legen Sie über die EAC in den Postfacheinstellungen eines Benutzers unter "Empfänger / Postfächer / Postfachnutzung" fest. Die Konfiguration der Mailbox setzen oder prüfen Sie ebenfalls über die PowerShell mit dem Get-Mailbox- beziehungsweise dem Set-Mailbox-Cmdlet. Über das Attribut "UseDatabaseQuotaDefaults" definieren Sie, ob der Datenbankstandard genutzt wird oder die individuellen Einstellungen zur Anwendung kommen:

Das folgende Beispiel listet die Einstellungen aller Mailboxen einer Datenbank auf, die nicht die Standardeinstellungen nutzen. Dies erreichen wir über eine einfache where-Bedingung. Auf diesem Weg bekommen Sie schnell Klarheit, wer die Einstellungen der Datenbank nutzt und bei wem eigene Grenzwerte definiert sind:

Sofern Sie unterschiedliche Limits benötigen, fassen Sie die Mailboxen in eigenen Datenbanken zusammen, damit Sie die Rechte nicht an jedem Postfach explizit setzen müssen.

Definieren Sie nicht nur die Grenzen, sondern beschreiben Sie auch, wie die Mitarbeiter beim Erreichen dieser Werte handeln sollen. Nichts ist schlimmer, als die Kollegen in eine Schatten-IT zu zwingen, denn schneller als Sie denken, werden E-Mail-Ablagen in Netzlaufwerken geschaffen oder durch die Nutzung von PST-Files dem Echtsystem entrissen. Auf diesem Weg verliert der Exchange-Administrator die Kontrolle über sein wichtigstes Gut. Um rechtzeitig informiert zu sein, dass ein Postfach aus dem Ruder läuft, definieren Sie bei den Grenzwerten noch die Zeitspanne und die Häufigkeit der Warnmeldungen.

Damit ebenfalls ein Administrator rechtzeitig in Kenntnis gesetzt wird, tragen Sie einen Journaling-Benutzer in den Eigenschaften der Datenbank beim Punkt "Wartung" ein. Dadurch wird neben dem Benutzer auch der angegebene Journaling-Benutzer benachrichtigt. Die Informationen zu den Grenzwerten finden die Anwender auch in Outlook unter "Datei" in den "Postfacheinstellungen". Auch Benutzer haben so einen Überblick über den freien Speicherplatz und können bei Bedarf rechtzeitig reagieren.

Als Letztes sei noch auf die Konfiguration der Aufbewahrungsfristen hingewiesen. In den Eigenschaften der Datenbanken definieren Sie zentral, wie lange eine gelöschte E-Mail in dem serverseitigen Papierkorb aufbewahrt und wie lange ein gelöschtes Postfach vorgehalten wird. Dies hat Auswirkung darauf, wie schnell Exchange Speicherplatz in einer Datenbank freigibt und diesen wiederverwenden kann, sodass Postfachdatenbanken langsamer wachsen. Beim Löschen von E-Mails sensibilisieren Sie unbedingt Ihre Benutzer, damit Sie regelmäßig den Ordner "Gelöschte Elemente" in Outlook leeren. Andernfalls hat Microsoft Exchange kaum etwas, was es nach der Aufbewahrungsfrist löschen kann.

Pflege der Datenbanken

Die Wartung der Datenbanken war bis Exchange 2007 ein wichtiger Aspekt, der zeitlich gut geplant werden musste. In diesem Zeitfenster erfolgte unter anderem die Onlinedefragmentierung der Datenbank und die Bereinigung des Dumpsters. Seit Exchange 2010 läuft die Wartung im 24x7 Betrieb, sodass Amins diese nicht mehr fest planen mussten. Mit Version 2019 haben Sie in der EAC aber weiterhin die Möglichkeit, die Wartung in ein festes Zeitfenster zu legen. Dies konfigurieren Sie in den Eigenschaften der Datenbank unter "Wartung". Damit der Zeitplan aktiv wird, deaktivieren Sie die Hintergrundwartung an der gleichen Stelle. Folgendes Kommando liefert Ihnen freien Speicherplatz für alle Datenbanken:

Auf diesem Weg haben Sie jedoch nur die Größe und den freien Speicherplatz ermittelt. Die detaillierten Informationen zu den enthaltenen Postfächern rufen Sie einzeln über deren Eigenschaften im EAC ab. Es empfiehlt sich aber auch in diesem Fall die Nutzung der EMS, da Sie alle Postfächer auf einmal abfragen und das Ergebnis tabellarisch sortiert nach der Postfachgröße erhalten:

Haben Sie in einer Datenbank sehr viel Speicherplatz, verzichten Sie auf die Nutzung von Eseutil, um diesen zu bereinigen Das Tool ist ein wertvoller Helfer in einer Umgebung ohne DAG, aber der Einsatz wird durch eine sehr lange Offlinezeit der Exchange-DB erkauft. Während der Nutzung des Tools wird eine komplett neue Datenbank mit einer neuen Signatur erstellt, weshalb diese nicht mehr mit den Kopien in einer DAG kompatibel ist. Einfacher und besser ist daher der Weg über eine neue Datenbank, wie von uns bereits beim Verschieben einer Datenbank skizziert. Erstellen Sie zunächst eine neue Mailbox-DB, kopieren Sie die Postfächer und löschen Sie im Anschluss die alte Datenbank mit den dazugehörigen Kopien. So erhalten Sie eine neue DB ohne freien Speicherplatz und die Benutzer arbeiten während des gesamten Prozesses ungestört weiter.

Umlaufprotokollierung

Die Exchange-Protokolle werden immer weiter fortgeschrieben und damit die Protokolle nicht endlos anwachsen, schneidet das System diese nach einer Sicherung ab. Es ist daher unbedingt auf ein funktionierendes Onlinebackup zu achten. Sie prüfen den Stand der letzten Sicherung in den Eigenschaften der Datenbank in der EAC oder über die EMS mit

Neben dem Fortschreiben der Protokolle gibt es die Umlaufprotokollierung. Diese löscht alle Protokolle, sofern die Änderungen in die Datenbank erfasst sind. Befindet sich die DB in einer DAG, wird zunächst abgewartet, bis alle Protokolle repliziert sind und diese nicht mehr benötigt werden. Die große Gefahr besteht bei der Umlaufprotokollierung darin, dass im Fehlerfall keine Protokolle mehr vorhanden sind, um Änderungen in die Datenbank wieder einzuspielen. Hierdurch kann es zu einem Datenverlust kommen. Aus diesem Grund sollten Sie die Umlaufprotokollierung nur mit viel Bedacht und nach Möglichkeiten nur in Test- und Entwicklungsumgebungen aktivieren.

Anders kann es sich in hochverfügbaren Umgebungen mit ausreichend Datenbankkopien verhalten, hier kann die Aktivierung sinnvoll sein. Die Umlaufprotokollierung starten Sie in den Wartungseinstellungen der Datenbank. Öffnen Sie hierfür in der EAC unter "Server / Datenbanken" die Eigenschaften der Ziel-DB. Dort richten Sie unter "Wartung" die Umlaufprotokollierung ein. In der PowerShell erreichen Sie dasselbe via:

Damit die Einstellung greift, remounten Sie die Datenbank. Um die Umlaufprotokollierung wieder zu deaktivieren, setzen Sie den Wert auf "$false".

Neben dem Abschneiden über das Backup ist das Aktivieren der Umlaufprotokollierung der einzige von Microsoft unterstützte Weg, um die Anzahl der Protokolle zu reduzieren. Gerade bei einer volllaufenden Festplatte kann das Löschen der Logs über die Umlaufprotokollierung ein schneller Weg sein, um alte Protokolle zu löschen und wieder ausreichend Festplattenspeicher für den fehlerfreien Betrieb zu erhalten. Ein anderer Fall, in dem es sinnvoll sein kann die Umlaufprotokollierung zu aktivieren, ist die Migration. Das Verschieben einer großen Anzahl von Postfächern erzeugt viele Logs. Hierbei kann es ebenfalls von Vorteil sein temporär die Umlaufprotokollierung zu aktivieren, um ein Volllaufen des Laufwerkes mit den Transaktionsprotokollen zu verhindern.

E-Mails archivieren

Die Postfächer wachsen stetig an und das Löschen ist oft keine Option, da Unternehmen in vielen Fällen einer Aufbewahrungspflicht unterliegen. Wie bereits erwähnt, ist das Exportieren von E-Mails in PSTs ebenfalls keine Alternative. Auch Microsoft hat sich dem Thema gewidmet und mit Exchange 2013 eine Archivfunktion eingeführt, die vielen Anforderungen gerecht wird. Dabei handelt es sich um Archivpostfächer, die einer Mailbox fest zugordnet sind. Das Archivpostfach verfügt über ein eigenes Kontingent und Benutzer können bequem E-Mails zwischen Archiv und Postfach verschieben. Das Archiv lässt sich in einer eigenen Datenbank ablegen, sodass Sie diese gezielt auf Low-Cost-Speicher oder einem eigenen Server auslagern. Ein Archiv aktivieren Sie für ein Postfach in dessen Eigenschaften unter " Postfachfunktionen". Dies ist jedoch recht gut versteckt und schneller klappt es mit

Outlook blendet das Archivpostfach beim Benutzer automatisch ein und bietet eine neue Ablagemöglichkeit. Mit einem Standardkontingent von 90 GByte hat das Postfach im Auslieferungszustand deutlich mehr Platz als das Hauptpostfach des Benutzers. Beachten Sie, dass Sie für die Archivfunktion eine Enterprise-CAL benötigen. Vor allem die fehlende Offlineverfügbarkeit und die doppelte Struktur sind die Defizite der integrierten Archivfunktion.

Nachdem Benutzer ein Archiv erhalten haben, sorgen Sie dafür, dass E-Mails nach Möglichkeit automatisch in das Archiv verschoben werden. Für diese Aufgabe stehen Ihnen Aufbewahrungsrichtlinien zur Verfügung, mit denen Sie auf Postfachebene Richtlinien definieren. Die Standardrichtlinien zeigen Sie sich über an. Dort sehen Sie unter " RetentionPolicyTagLinks" die mit der Richtlinie verknüpften Einstellungen, die in einem Aufbewahrungstag definiert sind. Die einzelnen Tags liefert Ihnen . Alternativ verwenden Sie in der EAC "Verwaltung der Richtlinientreue".

Es wird dabei je nach Wirkungskreis zwischen folgenden Aufbewahrungstags unterschieden, die sowohl Archivierungs- als auch Löschtags enthalten können:

- Aufbewahrungsrichtlinien-Tags (Retention Policy Tag): Auf Standardordner in einem Postfach, wie zum Beispiel "Posteingang" und "Gelöschte Elemente", anzuwenden.

- Persönliche Tags: Möglichkeit für Benutzer, benutzerdefinierten Ordnern und einzelnen Elementen persönliche Tags zuzuweisen. Benutzer können die Kennzeichnung mithilfe von Posteingangsregeln automatisieren, um eine Nachricht entweder in einen Ordner zu verschieben oder um ein persönliches Tag auf die Nachricht anzuwenden.

- Standardrichtlinientags: Zielt auf Elemente, auf die Aufbewahrungstags weder direkt noch durch Vererbung über den Ordner wirken.

Die Richtlinien greifen dabei auf dem Postfach als auch im Archiv, sodass Lösch-Tags auch für das Archiv gelten und Elemente nach der definierten Zeit gelöscht werden. Über das New-RetentionPolicyTag-Cmdlet können Sie auch eigene Aufbewahrungstags erstellen, die Ihren Anforderungen entsprechen und in einer eigenen Richtlinie zusammengefasst werden. Nachdem Sie Aufbewahrungsrichtlinien erstellt haben, weisen Sie diese den Postfächern über die EAC oder über die PowerShell zu:

Der Mitarbeiter bekommt im Anschluss in Outlook und OWA die Möglichkeit, mit den persönliche Tags gezielt zu arbeiten.

Der Assistent für verwaltete Ordner läuft auf dem Postfachserver permanent im Hintergrund und verarbeitet die Postfächer, auf die eine Aufbewahrungsrichtlinie wirkt. Um nicht zu warten, bis der Assistent ein Postfach durchläuft, starten Sie die Verarbeitung mit folgendem PowerShell-Befehl direkt:

Haben Sie Aufbewahrungsrichtlinien definiert, orientieren sich diese am Datum der Zustellung oder dem Erstellen von Elementen, wie beispielsweise Entwürfe.

Fazit

Unsere Best Practices zum Aufbau und Handhabung von Exchange-Speicher und -Datenbanken lenken das Speicherwachstum in geordnete Bahnen. Damit sollten die meisten Storage-Probleme unter Microsoft Exchange 2019 der Vergangenheit angehören.

Speicherverwaltung unter Exchange 2019

Effizient mailen

Reduzierte Anforderungen an Exchange-Speicher

Reduzierte Anforderungen an Exchange-Speicher

Ablage der Datenbanken

Datenbanken verschieben

Verwalten der Datenbanken

Pflege der Datenbanken

Umlaufprotokollierung

E-Mails archivieren

Fazit