Mich hat eine eher ungewöhnliche Kundenanfrage erreicht. Einer meiner Kunden betreibt eine M365-Umgebung mit Exchange Online und macht sich Gedanken über die Verfügbarkeit der E-Mail Kommunikation im Falle eines Ausfalls der Microsoft Azure und / oder M365 Umgebung.
Vorwort:
Microsoft macht meiner Meinung nach seinen sehr guten Job was die Verfügbarkeit von Service innerhalb der Microsoft-Cloud global angeht. Es gibt die Möglichkeit, die einzelnen Services individuell abzusichern und auch sicherzustellen, dass Services innerhalb einzelner RZs, Regionen oder auch global mehrstufig redundant ausgelegt sind und somit das Risiko von Dienstausfällen rapide gesenkt wird.
Des Weiteren ist der Ausfall von Microsoft-Diensten oft zwar global, jedoch binnen kürzester Zeit wieder behoben. Erfahrungsgemäß sind etwaige Störungen binnen Stunden behoben, da Microsoft selbst natürlich Spezialisten vorhält, die Ausfälle schnell troubleshooten und beheben, um den globalen Impact so gering wie möglich zu halten.
Oft liegt es eher an fehlendem oder mangelndem Vertrauen, sofern ein Kunde dennoch die Anforderung hat, sich vor einem derartigen Vorfall abzusichern. Geht das überhaupt? Das finden wir heraus!
Tests:
Als Basis des folgenden Tests habe ich einen Microsoft CDX Tentant (Demotentant mit vollen Rechten und bereits fertig bestückten Demo-Postfächern) verwendet und Veeam für M365 in der v7 installiert. Ebenfalls habe ich in einer On-Premise vSphere-Umgebung einen Exchange Server 2019 installiert und in der Basis konfiguriert.
Ziel ist, ein innerhalb von M365 verwaltetes und mit Veeam gesichertes Postfach auf einen On-Premise Exchange-Server wiederherzustellen und dort produktiv zu betreiben.
Vorgehen:
Hinzufügen des On-Premise Exchange-Servers:
Im ersten Schritt habe ich den On-Premise Exchange-Server innerhalb der Veeam für M365 Umgebung hinzugefügt:
Hierbei bin ich auf den folgenden Fehler gestoßen:
Dies hängt u.a. mit fehlenden Berechtigungen des Service Accounts und eine bestimmten Konfiguration innerhalb des On-Premise Exchange-Servers zusammen. Ich habe den Exchange-Server für den Test für „Basic Authentication“ konfiguriert und der Wizard konnte erfolgreich durchlaufen:
Da ich für diesen Text keine CA angelegt habe, habe ich die folgende Zertifikatswarnung ignoriert:
Der Exchange-Server konnte somit fehlerfrei angelegt werden:
Anlage des zu wiederherstellenden Postfaches auf dem On-Premise Exchange-Server:
Um zu gewährleisten, dass eine gleichnamige Mailbox (mit entsprechendem Account) auf beiden Umgebungen vorhanden ist, habe ich die zu wiederherstellende Mailbox manuell auf dem Exchange-Server angelegt:
Hinweis: Der CDX-Tentant bietet wie oben erwähnt diverse Demo-Mailboxen, die auch Inhalte zum Testen bereitstellen. Für diesen Restore-Test habe ich eine beliebige, vorhandene Mailbox mit dem Alias „ChristieC“ ausgewählt.
Durchführung des Restores:
Ich habe mich hier des Restore-Wizards innerhalb der Veeam-Oberfläche bedient und den Versuch einer Wiederherstellung gestartet:
Als Ziel habe ich hier den On-Premise Exchange-Server ausgewählt:
Nun kommen wir sehr schnell und unspektakulär zu dem finalen Fehler:
Erklärung:
Veeam verwendet für den Restore als Vergleichsparameter die GUID des Accounts bzw. des Postfaches, nicht den Namen. Was letztlich absolut sinnvoll ist, bestätigt sich hier und stellt sich für das Szenario als Limitierung dar.
Trotz dass die Mailbox mit identischem Namen (und identischer Mail-Adresse) existiert, ist ein Restore ohne Weiteres nicht möglich.
Workaround / Idee:
Da ein Export eines gebackupten Posftaches innerhalb von Veeam als PST-Datei möglich ist, könnte es seine Option sein, die entsprechende Mailbox aus dem Backup als PST-Datei zu speichern und diese dann in das On-Premise Postfach zu integrieren. Dies erfordert entsprechende Kenntnisse im Microsoft-Umfeld und kann bei einer Massenwiederherstellung aufwendig und fehleranfällig sein.
Vorteile:
Die Daten sind nicht weg! Man kann trotz eines „Failovers“ (der im Grunde genommen nur ein Ausweichen auf den On-Premise Exchange-Server darstellt) die Daten lesen und selbst mit einer lediglich angehangenen PST-Datei wertvolle Informationen einlesen und mit diesen manuell weiterarbeiten.
Nachteile:
Der dadurch entstehende Workload für Admins und auch für Enduser, die teilweise den Unterschied zwischen PST-Datei und „echtem“ Postfach nicht kennen, kann enorm hoch und wenig wirtschaftlich sein.
Es gilt außerdem zu bedenken, dass die dann im K-Fall betriebene On-Premise Exchange-Infrastruktur ebenfalls gebackuped werden muss. Da die Organisation bereits vorab im Veeam für M365 angelegt werden kann, ist der Workload etwas geringer, jedoch müssen zwei Kernpunkte betrachtet werden:
Erstens: Ich benötige Backups der K-Fall Infrastruktur, sobald diese produktiv betrieben wird
Zweitens: Ich benötige einen Weg zurück in die Exchange-Online Infrastruktur, was im Zweifel und je nach Dauer des K-Fall Szenarios einen enormen Aufwand darstellt.
Fazit:
Funktioniert das Szenario, ein Exchange-Online Postfach auf einen On-Premise Exchange-Server wiederherzustellen?
Nicht ohne weiteres!
Das heißt im Grunde folgendes: Es ist extrem wichtig, sich Strategien für den Notfall und für Ausfälle größerer Kernkomponenten der IT-Infrastruktur zu definieren und diese auch zu validieren. Dies hier ist offenbar für einige Europäische Kunden eine Limitierung.
Wie im Vorwort erwähnt gilt es den Aufwand abzuwägen, der betrieben werden muss, um ein solches Szenario unternehmensweit und vollumfänglich umzusetzen und auch K-Fall-tauglich zu machen. Dies ist zu vergleichen mit der Tatsache, dass Microsoft viele Spezialisten vorhält, die dafür sorgen, dass alle Dienste die höchstmögliche Verfügbarkeit haben und somit auch stabil laufen und permanent weiterentwickelt und verbessert werden.
Da gerade der Europäische Markt als sehr preissensibel gilt, ist das Szenario meiner Meinung nach für die Praxis kaum bis gar nicht tauglich.
Hybrid-Infrastrukturen:
Ein wichtiger Hinweis an dieser Stelle:
Das o.g. Szenario beschreibt eine reine Exchange-Online Quell-Infrastruktur und geht nicht weiter auf hybride Szenarien ein, da der Anteil an hybrid betriebenen Exchange-Infrastrukturen sinkt.
Da die Mailbox GUID bei Hybrid-Deployments identisch ist (da es sich um die selbe Mailbox und den selben Account handelt), kann das o.g. Szenario bedingt für solche Umgebungen umgesetzt werden.