Ausgangssituation:
Kundenseitig besteht der Wunsch, die Funktion seines bestehenden on premises SEPPmail Secure E-Mail Gateway zukünftig Service in der Cloud zu buchen.
Frage:
Was muss für eine Migration vom on premises SEPPmail Secure E-Mail Gateway hin zu seppmail.cloud, beziehungsweise gegebenenfalls zu einem anderen SEPPmail-Cloud Partner vorbereitet werden.
Vorgehen:
Basis für das Migrieren hin zur seppmail.cloud stellt das SEPPMAIL.CLOUD HANDBUCH dar. Diese beinhaltet bereits in Teilen Punkte dieser Beschreibung.
Für das Migrieren zu einem anderen MSP ist generell die enge Zusammenarbeit und das konkrete Abstimmen zwischen den Parteien als Basis für eine erfolgreiche Migration zu empfehlen.
Folgende Punkte des Zielsystems (Cloud) sollten vor Beginn der Migration bekannt sein:
•Welche Firmware Version des SEPPmail Secure E-Mail Gateway ist im Einsatz. => in der seppmail.cloud ist das immer die aktuellste.
•(Optional) „Zukünftige Bezeichnung des Mandanten“ (siehe Customer)
•(Optional) „Zukünftiger Name des Mandanten“ (siehe Customer Name)
•Ist für das Hosting der GINA-Domain „Virtual Hosting“ (siehe Use virtual hosting)
odeaktiviert (Off for all domains)
oaktiviert (On for all domains)
=> dies ist die Standardeinstellung in seppmail.cloud und ist auch für alle anderen MSPs empfohlen.
ofrei wählbar (Use domain settings)
•Von der „Virtual Hosting Einstellung“ abhängiger Hostname
oEinstellung „Off“
=> In der Regel wird hier der Firmenname des Mandanten in Kleinschrift verwendet, für „Meine Firma AG“ also beispielsweise „meinefirma“.
oEinstellung „On“
=> Ein FQDN, der sich in der Regel aus dem prefix „securemail“ und der Firmen-Domäne zusammensetzt, beispielsweise „securemail.meinefirma.tld“.
•Erforderliche Anpassungen im DNS für
oden E-Mail Fluss (MX Einträge)
odie Erreichbarkeit von GINA.
Gegebenenfalls ist an dieser Stelle ein weiterer Eintrag erforderlich (siehe „Virtual Hosting Einstellung“ oben).
Vom Bestandssystem (on premises) sollten vor Beginn der Migration folgende Punkte bekannt sein:
•FQDN unter welcher die GINA-Oberfläche bislang erreichbar war (Hostname) (siehe auch Warnung in Punkt „c)“)
•Erreichbarkeit des eigenen E-Mail Servers für den MSP (siehe auch Forwarding Server)
Sofern der eigene E-Mail Server auch durch den MSP betrieben wird, entfällt dieser Punkt.
•Export-Datei (siehe „j)“)
Um zu vermeiden, dass sensible Daten in die falschen Hände geraten, sollte die Export-Datei und das zugehörige Passwort möglichst auf zwei unterschiedlichen Kommunikationskanälen mitgeteilt werden.
Im Detail ist wie folgt vorzugehen:
Erforderliche Aktionen auf dem „on premises SEPPmail Secure E-Mail Gateway“
a)Sollte auf dem on premises SEPPmail Secure E-Mail Gateway die Mandantenfähigkeit noch nicht freigeschaltet sein (siehe gegebenenfalls Multitenancy), so muss diese durch eine E-Mail an support@seppmail.com mit dem Betreff „Migrationsvorbereitung“ und dem Wunsch des Freischaltens der Mandantenfähigkeit gesendet werden.
Nach Freischalten der Mandantenfähigkeit kann diese Lizenzänderung gegebenenfalls adhoc durch Klicken von View release notes der Sektion Update des Menüs Administration übernommen werden.
b)Zunächst ist sicherzustellen, dass das SEPPmail Secure E-Mail Gateway mit keinem höheren Firmware Stand betrieben wird als dem des MSPs (siehe oben). Generell ist jedoch darauf zu achten, dass der Unterschied der Versionsstände so gering wie möglich ist. Der aktuelle Stand kann unter Home System Firmware version geprüft werden
Für eine Migration in die seppmail.cloud ist die Firmware stets auf den aktuellsten Stand zu bringen (siehe Administration Update).
c)Falls ausschließlich die [default] GINA-Domain eingesetzt wurde (siehe GINA Domains Domains GINA name), ist eine neue GINA-Domain via Create new GINA domain anzulegen. Noch vor dem Anlegen muss darauf geachtet werden, dass die Option Use virtual hosting auf Use domain settings steht.
Im Menü zum Anlegen neuer GINA-Domains () sollte unter Description möglichst bereits ein Name vergeben werden, welcher den Konventionen des MSPs entspricht (in der Regel ist dies die Bezeichnung des Mandanten )(siehe oben.
Analog zu den vom MSP angebotenen Virtual Hosting Einstellungen (siehe oben), ist die Einstellung Use virtual hosting vorzunehmen.
Abhängig von der vorgenommenen Virtual Hosting Einstellungen (siehe oben) ist nun der Hostname einzutragen .
Damit die Einstellungen von der [default] GINA-Domain übernommen werden, sollte als Master template „[default]“ gewählt werden.
Damit bereits versendete GINA-Nachrichten auch nach der Migration weiterhin gelesen werden können, muss die bislang für GINA verwendete FQDN (Hostname) später auf das SEPPmail Secure E-Mail Gateway des MSPs zeigen. Dies erfordert ein Anpassen des/der DNS Einträge. Weiterhin ist dieser FQDN dem MSP mitzuteilen, da dieser diesen FQDN bei der Migration unter Additional hostnames aufnehmen muss. |
Andernfalls kann mit Punkt „e)“ fortgefahren werden
d)Übernehmen der neu erzeugten GINA-Domain für die verwalteten Domänen
-> Mail System Managed domains die zu bearbeitende verwaltete Domäne anklicken und im Folgemenü unter Settings unter GINA domain die neu erstellte GINA auswählen. Der Vorgang muss für jede verwaltete Domäne wiederholt werden.
i.Wird - sofern möglich - bereits vor dem Export der Forwarding Server angepasst (und sofern vorhanden der Smarthost (siehe auch Send ALL outgoing mails from this domain to the following SMTP server) gelöscht), so kann dem Anpassen dieser Option beim MSP vorgegriffen werden (siehe gegebenenfalls „Erreichbarkeit des eigenen E-Mail Servers für den MSP“).
e)Aktivieren der Mandantenfähigkeit auf der „on premises SEPPmail Secure E-Mail Gateway“
-> Customers Multiple Customers Enable
Soll eine bereits mandantenfähige Maschine, komplett oder auch nur zu Teilen in die seppmail.cloud umgezogen werden sollen, so kann für die zu migrierenden Mandanten mit Schritt „k)“ fortgefahren werden. Voraussetzung für eine erfolgreiche Migration ist an dieser Stelle, dass das zu migrierende SEPPmail Secure E-Mail Gateway korrekt konfiguriert ist (siehe Notes, insbesondere die Warnung). |
Wurde das zu migrierende SEPPmail Secure E-Mail Gateway vor der geplanten Migration in die seppmail.cloud zwar für mehrere Mandanten betrieben, jedoch ohne dabei die Mandantenfähigkeit (Customers) zu verwenden, so muss die Mandantentrennung noch vor der Migration hergestellt werden. Beim Herstellen der Mandantentrennung ist unbedingt die Sektion Notes und insbesondere die darin befindliche Warnung zu beachten!
An dieser Stelle sei erwähnt, dass sowohl die vorangegangenen, als auch die nachfolgenden Punkte jeweils pro - neu angelegten - Mandant auszuführen sind. Auch die erforderlichen Zuordnungen (beispielsweise GINA domain, Assigned managed domains, Assigned GINA accounts, ...) müssen natürlich getrennt nach Mandanten erfolgen! |
f)Einrichten eines Mandanten auf dem SEPPmail Secure E-Mail Gateway, wobei die Namensgebung bereits den Konventionen des MSPs (siehe oben „Zukünftige Bezeichnung...“, beziehungsweise „Zukünftiger Name des Mandanten“) entsprechen sollte.
Eine hier eingetragene optional einzutragende Customer Admin E-Mail kann auf Wunsch später täglich automatisiert ein Mandanten Backup erhalten.
-> Customers Multiple Customers Create new customer...
g)Öffnen der Eigenschaften für den neu angelegten Mandanten
-> Customers Multiple Customers, in der Tabelle unter Customer auf den Customer klicken.
h)Zuordnen aller auf der Appliance verwalteten Domänen
-> Assigned managed domains, Auswahl der zu migrierenden Managed Domains über das DropDown Menü unter Domain name. Das Abschließen des Zuordnens erfolgt durch Klicken von Assign.
i)Zuordnen aller auf der Appliance vorhandenen GINA Accounts
-> Assigned GINA accounts, Manage accounts im Folgemenü Assign other GINA accounts alle in der ersten Tabelle angezeigten GINA-Accounts durch Klicken von Assign all proposed accounts zuordnen. Sofern in der zweiten Tabelle noch GINA-Accounts gelistet sein, so sollten diese durch Klicken von Assign all unassigned accounts ebenfalls zugeordnet werden.
-> nach Abschluss dieser Aktion zurück in das übergeordnete Menü via Back
j)Export des/der neuen Mandanten
--> Customers Multiple Customers, in der Tabelle in der Zeile des neu angelegten Mandanten unter Action auf die Schaltfläche für den Export klicken
i.Im erscheinenden Folgemenü unter Export password ein „sicheres“ Passwort (der Export enthält das gesamte Schlüsselmaterial, also auch die sensiblen privaten Schlüssel!) vergeben und durch Klicken von Export abschließen.
ii.Die Export-Datei wird unter dem Namen „<Name des Mandanten>-<jjjjmmdd>.zip“ gespeichert.
auf dem SEPPmail Secure E-Mail Gateway Zielsystem (Cloud)
Die erforderlichen Aktionen und Anpassungen auf dem SEPPmail Secure E-Mail Gateway des MSPs sind in der Regel stark von der zu migrierenden Maschine, insbesondere der Architektur, wie diese in den E-Mail Fluss eingebunden ist, abhängig. Gegebenenfalls müssen hier auch Sonderfälle wie beispielsweise eine Microsoft 365 Anbindung (siehe auch Anbinden von MS Office365 unter Beibehaltung von ATP /EOP) berücksichtigt werden.
Weiterhin muss gegebenenfalls berücksichtigt werden, ob alle in dem zu migrierenden SEPPmail Secure E-Mail Gateway aktiven Zusätzliche Features auch vom MSP angeboten werden.
Anpassungen, welche gegebenenfalls bereits vor dem Export (siehe beispielsweise „d) i.“) vorgenommen wurden, entfallen auf dem Zielsystem.
k)Import der Export Datei
-> Customers Multiple Customers Import Customer
Derzeit steht mit der Funktion die Möglichkeit zur Verfügung, einen kompletten Mandanten zu Importieren. Das impliziert, dass die oben erwähnten, erforderlichen Aktionen im Nachgang auf dem MSP-System durchgeführt werden.
Wie jedoch bereits in der Dokumentation des Untermenüs zu ersehen, wird in Kürze ein granularerer Import möglich sein.
l)Prüfen der Einstellungen für den E-Mail Fluss
•Ist der korrekte Forwarding Server eingetragen? (siehe „d) i.“ und die „Erreichbarkeit des eigenen E-Mail Servers für den MSP“ gegeben?
•Zeigt jeweils der MX-Eintrag für die zu migrierenden E-Mail Domänen auf das Zielsystem (siehe „Erforderliche Anpassungen im DNS“)
oWurden dabei auch die gegebenenfalls erforderlichen Anpassungen der TXT-Einträge für SPF, DKIM, DMARC, und so weiter berücksichtigt?
m)Sind die „Erforderliche Anpassungen im DNS“ vorhanden, damit die - gegebenenfalls neu angelegten (siehe „e)“) - GINA-Domain(s) auf dem Zielsystem erreichbar sind?
•Sofern auf dem Zielsystem der Eintrag von Additional hostnames erforderlich ist (siehe Warnung aus „c)“)
oWurde der Eintrag in der/n GINA-Domain(s) korrekt vorgenommen?
oIst der entsprechende DNS Eintrag dahingehend geändert worden, dass dieser auf das Zielsystem zeigt?
oIst der Additional hostname auch im CN, beziehungsweise SAN des Zertifikates der jeweiligen GINA-Domain vorhanden?
Aufgrund der zahlreichen Einflussfaktoren, erhebt diese Liste der erforderlichen Anpassungen keinen Anspruch auf Vollständigkeit. |