Einen MailStore Server auf eine andere oder neue Maschine zu migrieren ist keine große Sache. Je nach Ausgangslage und Vorbereitung muss nicht all zu viel getan werden und der Vorgang geht schnell über die Bühne.

Im Grunde sind alle notwendigen Schritte in der MailStore Server Hilfe beschrieben. Konkret unter

Umziehen des Archivs – Das Archiv auf eine andere Maschine verschieben

MailStore-typisch ist die Dokumentation sehr gut und die einzelnen Schritte funktionieren so wie es beschrieben ist. Nachfolgend also zum einen wie dokumentiert der Umzug mit ein paar Anmerkungen und Erfahrungswerten aus der Praxis.

Es wird von der OnPrem-Installation eines MailStore Servers in der Version 13 mit eigenem Zertifikat (kein Let’s Encrypt) ausgegangen, der Postfächer eines OnPrem- oder Provider-Mailservers archiviert.

Ausgangslage(n)

Wie einfach oder aufwendig der Umzug eines MailStore Servers ist hängt unter anderem davon ab wie dieser bislang angesprochen wurde. Gemeint ist ob die Clients den Server mit einem FQDN wie z.B. “srv04.domain.tld” verwenden oder ob eher einer wie “mailstoreserver.domain.tld” zum Einsatz kommt.

Bei ersterem muss man beim Umzug ein neues Zertifikat ausstellen bzw. vorhalten und nach der Migration den Clients beispielsweise via GPO den neuen Servernamen mitteilen. Bei letzterem kann man das vorhandene Zertifikat weiter verwenden und muss nur den Host A-Eintrag im DNS aktualisieren.

Die Nutzung von “mailstoreserver.domain.tld” ist dabei unsere Best Practice. Zugegeben, früher haben wir das auch anders gehandhabt, mittlerweile passen wir dies bei jeder Migration an, sofern das für den Kunden OK ist versteht sich.

Ebenfalls ist es möglich, das letztlich der neue Server den gleichen FQDN bzw. Hostname (und ggf. IP-Konfiguration) erhält wie der Alte, dann kann man das bestehende Zertifikat ebenfalls übernehmen.

Vorbereitung

Da eine E-Mail-Archivierung recht viele Daten bedeutet, macht es Sinn bereits bei Zeiten, zum Beispiel ein paar Tage vor der eigentlichen Migration, den neuen Windows Server (ohne MailStore Server) aufzusetzen und den Datenbestand zu synchronisieren.

Hierzu kann man auf das Bordmittel robocopy zurückgreifen und z.B. so einen regelmäßigen Abgleich via Aufgabe durchführen:

robocopy "C:\MailArchive" "\\<NeuerServer>\C$\MailArchive" /ZB /COPY:DAT /MIR /MT:8 /R:0 /W:0 /NP /LOG:MailStoreServer.log /TEE /COMPRESS

Bemerkung: Etwaige Fehler wegen Dateien die noch im Zugriff sind kann man zunächst ignorieren. Relevant ist, dass das Groß der Daten schon mal synchronisiert ist.

Ggf. kann man bereits der Zertifikat samt privaten Schlüssel vom alten Server exportieren (ohne dieses dort zu löschen) und dieses schonmal auf dem neuen Server importieren.

Wichtig ist den Kunden mitzunehmen! Das bedeutet: Teilt mit wann die Migration durchgeführt wird und folglich der MailStore Server nicht zur Verfügung steht.

Die eigentliche Migration

Um Tag der eigentlichen Migration geht man fast genauso vor wie es der Hersteller in der Dokumentation (s.o.) angibt.

Alter Server

  • Die Konfiguration des MailStore Server-Dienste überprüfen und dokumentieren.
  • Den MailStore Server-Dienst beenden und auf “Deaktiviert” setzen.
  • Den finalen Datenabgleich durchführen.
  • Den MailStore Server deinstallieren.
    Bemerkung: Diesen Schritt kann man auch später durchführen, wichtig ist, das der Dienst nicht aus versehen oder anderweitig automatisch wieder gestartet wird.
  • Über das Lizenzportal die Lizenz für den Transfer freigeben.

Neuer Server

  • Den MailStore Server installieren und ggf. den Pfad der Datenbank sowie die weitere Dienst-Konfiguration anpassen.
  • Sofern noch nicht geschehen das Zertifikat samt privaten Schlüssel auf dem alten Server ex- und auf dem neuen Server importieren.
  • Sofern die Archivverschlüsselung nicht mit dem Lizenzschlüssel durchgeführt wurde, muss hier noch eine Anpassung erfolgen. Siehe:
    MailStore Server Dienst-Konfiguration – Sicherheit und Verschlüsselung
  • Ggf. den MailStore Server-Dienst einmal neu starten.

Nacharbeiten

Folgt man der Best Practice muss nun im DNS der Host A-Eintrag für den MailStore Server angepasst, d.h. die neue IP-Adresse eingetragen werden. Erfolgt ein Monitoring des MailStore Servers und des zugrundeliegenden Systems, so muss dieses angepasst werden um Fehleralarme zu vermeiden. Ebenfalls sollte das Backup angepasst bzw. aktualisiert werden.

Nun sollte überprüft werden ob die Archivierungsaufgaben erfolgreich abgeschlossen werden und ob ein Zugriff auf das oder die Archive erfolgreich möglich ist.

Last but not least müssen, sofern nicht die Best Practice genutzt wird, den Clients der neue FQDN des Servers und der neue Zertifikats-Fingerabdruck beispielsweise via GPO mitgeteilt werden.

Läuft soweit alles, kann der alte MailStore Server (gemeint ist der Windows Server) außer Betrieb genommen oder eine anderen Aufgabe zugewiesen werden.

Abschließende Worte

Wir haben den Vorgang mittlerweile soweit optimiert, das die finale Migration sogar unterm Tag stattfinden kann, so ist keine Nachschicht oder kein Wochenende-Einsatz mehr notwendig. Der finale Abgleich, die De-/Installation des MailStore Servers, die Freigabe der Lizenz sind in der Regel in ein paar Minuten durch.

Bei einer der letzten Migrationen hatte gerade mal eine Mitarbeiterin des Kunden gemerkt, das da was nicht geht. Fünf Minuten später war dann schon alles wieder gut.