Automatische Migration von E-Mails, Terminen und Aufgaben

Fabian Schmidt, 123RF

Kein Umzugsstress

Auf der einen Seite locken neue Features oder ein besserer Support, doch auf der anderen Seite wirkt ein starkes Trägheitsmoment: Was wird aus meinen Mails, Aufgaben und Terminen, wenn ich den Service-Provider wechsele? Ein Portal hilft beim Umzug.
Termine planen, Nachrichten austauschen, Kundendaten verwalten, am besten auch vom Smartphone aus. Das alles und noch viel mehr sollen moderne ... (mehr)

Ein Anwender berichtet: Von Zimbra zu Exchange

Der Lahn-Kinderkrippen e.V. betreibt als gemeinnütziger Verein mehrere Kindertagesstätten und nutzt 17 Groupware-Konten für interne Zwecke und um mit den Eltern zu kommunizieren. Ursprünglich setzte der Verein auf eine Hosted-Zimbra-Lösung, wollte aber wegen häufiger Ausfälle zu Microsoft Exchange Online wechseln.

Zunächst versuchte man die Sache mit einem IT-Dienstleister anzugehen, der die 22 GByte an existierenden E-Mails, Kontakten und Kalenderdaten ex- und dann wieder importieren wollte. Das erwies sich allerdings als zu aufwendig und zu kostenintensiv. Schließlich stießen die Kindergärtner auf den SaaS-Migrationsdienst www.groupware-umzug.de als Alternative.

Nach erfolgreichem Testlauf mit einem Konto lief dann die komplette Umstellung an einem Wochenende durch. Dazu wurden die Passwörter der Nutzer zurückgesetzt und der MX-Eintrag der Domain geändert. Die Migration der 17 Konten richtete man über die webbasierte Oberfläche des audriga-Dienstes ein. Aufgrund der Erfahrungen mit Zimbra ließ man vorsichtshalber immer nur einen Umzugsauftrag laufen, sodass der vollautomatische Datentransfer knapp 48 Stunden dauerte. Der verantwortliche Admin bei Lahn-Kinderkrippen konnte dabei den Umzugsstatus anhand der von audriga automatisch generierten Protokolle jederzeit nachvollziehen.

Die Umzüge liefen wie geplant und ohne große Schwierigkeiten durch. Nur eine kleine Anzahl von E-Mails wurde aufgrund von Verbindungsproblemen und trotz mehrfacher automatischer Wiederholung nicht übertragen. Diese Daten wurden später manuell anhand der Protokolle des Umzugs nachgezogen. Da der Standardordner für »Gesendete E-Mails« in Quelle und Ziel unterschiedlich benannt war, waren zudem die gesendeten Nachrichten im neuen Postfach zunächst nicht am erwarteten Ort.

Insgesamt schätzt Lahn-Kinderkrippen die Vorteile des automatisierten SaaS-Umzugs gegenüber der Lösung des IT-Dienstleisters hoch ein. Weniger Arbeitsaufwand und um den Faktor fünf verminderte Kosten standen am Ende zu Buche. Alle Daten ließen sich in weniger als einem Manntag migrieren. Die automatisch zur Verfügung gestellten Protokolle ermöglichten außerdem eine zuverlässige Kontrolle.

Was also wird aus den Bestandsdaten bei einem Providerwechsel? "Ganz einfach" – das ist jedenfalls die Antwort der Karlsruher audriga GmbH, die ein Self-Service-Portal für E-Mail-Umzüge betreibt. Sie verspricht, dass der Anbieterwechsel damit schnell, einfach und sicher gelingt. Das ADMIN-Magazin hat den Service getestet.

Erster Versuch

Ausgangspunkt für unseren Versuch war ein E-Mail-Konto bei Strato, mit dem wir zu Host Europe umziehen wollten. Quelle und Ziel sind selbstverständlich austauschbar und wurden von uns rein zufällig gewählt, ohne dass wir damit irgendeine Aussage über die Servicequalität der Anbieter verbinden wollen. Das Zielkonto muss dabei über das IMAP-Protokoll erreichbar sein. Wir haben es vorher mit einer bunten Auswahl an gelesenen, ungelesenen und gesendeten Mails versehen, mit erledigten, unerledigten und wiederkehrenden Aufgaben sowie mit einer Reihe fiktiver Kontakte (Abbildung 1).

Abbildung 1: Ein Beispiel-Kontakt im umzuziehenden Strato-Account.

Das Ausgangskonto muss übrigens nicht bei einem öffentlicher Provider beheimatet sein, man kann mithilfe des Portals auch von seinem eigenen Mailserver zu einem Hoster umziehen. Wer mitsamt der Domain migrieren will, sollte mit den Mails beginnen – mit einem Delta-Umzug können später die in der Zwischenzeit aufgelaufenen Mails nachgeholt werden.

Bevor man mit dem Umzug beginnt, sollte man sich die Adressen der beteiligten Anbieter (oder des eigenen IMAP-Servers) sowie die Namen und Passwörter der Accounts zurechtlegen. Aus Sicherheitsgründen und im Interesse des Datenschutzes empfehlen sich temporäre Passwörter für den Umzug, die ihre Nutzer später wieder ändern können. Auch ist es ratsam, zunächst mit einem Account zu beginnen und den Rest erst dann in Angriff zu nehmen, wenn sich beim Testfall keine Probleme ergeben haben.

Im ersten Schritt muss man dann auf dem Zielsystem für jeden umzuziehenden Account ein leeres Pendant anlegen. Danach gibt man im Browser die Adresse des Umzugs-Portals ein. Nachdem die Nutzungsbedingungen akzeptiert sind – denen zufolge audriga übrigens nur dann in voller Höhe haften würde, wenn Vorsatz oder die Verletzung einer schriftlichen Garantie der Geschäftsleitung vorliegen würde – wählt man Quell- und Zielsystem. Eine Reihe großer Provider (Strato, 1&1, GMX, Google Mail, Host Europe, Web.de und Yahoo!Mail) sind voreingestellt. Danach werden die Daten zu den umzuziehenden Accounts eingegeben (Abbildung 2). Die Gültigkeit der Passwörter muss via Klick auf einen entsprechenden Button geprüft werden. Dabei übermittelt das Portal die Logindaten SSL-verschlüsselt an einen Rechner in Amazons AWS-Cloud, in der der Umzugsservice läuft. Dieser Rechner wiederum wählt sich dann in Quell- und Zielkonten ein.

Abbildung 2: Hier werden die Daten zum Account hinterlegt, der migriert werden soll.

Noch ein paar Klicks und Eingabe einer E-Mail-Adresse, an die ein Protokoll der Aktion gemailt werden soll, und es kann losgehen (Abbildung 3). Während des Umzugs informiert ein Fortschrittsbalken über den Status (Abbildung 4). Schon vor Umzugsbeginn erhält der zuvor angegebene E-Mail-Adressat erst eine Bestell-, dann eine Auftragsbestätigung und nach Beendigung einen kurzen Schlussbericht.

Abbildung 3: Vor dem Umzug schätzt das Portal auch die voraussichtliche Dauer der Aktion.
Abbildung 4: Ein Fortschrittsbalken zeigt an, wie weit der Umzug bereits gediehen ist.

Die Kür

Das alles funktionierte im ersten Anlauf reibungslos, allerdings war der getestete Fall insofern recht einfach, als dass beide Partner Open Xchange als Groupware-Applikation in ihren Angeboten einsetzen. Damit sind die zu übertragenden Felder auf beiden Seiten identisch. In vielen Fällen wird es dagegen auch ganz unterschiedliche oder zumindest unterschiedlich benannte Felder geben oder auch Felder mit gleichem Namen, die aber verschiedene Datenformate oder -typen erwarten oder aber verschiedene Mechanismen kennen, etwa um Kontakte zu gruppieren.

Um diesen Fall nachzustellen, wollten wir ein Gmail-Konto zu Web.de transferieren. Die erste Hürde bestand schon darin, dass Web.de nicht in der Auswahlliste der Zielplattformen auftaucht (wohl aber als Quelle). Die Ausgangs- und Endpunkte der Migration sind also offenbar weitgehend, aber nicht vollkommen austauschbar. Einige Anbieter eignen sich vor allem deswegen nicht als Zielplattform, weil sie entweder nur POP3 statt IMAP anbieten oder beispielsweise mit großen Datenmengen nicht gut klarkommen.

Im Fall von web.de wird IMAP zwar nicht garantiert, funktioniert aber. Hier kann man »imap.web.de« auf eigene Gefahr von Hand eingeben. Gesagt, getan. Dann ergab sich aber die zweite Schwierigkeit: Google wertete den Login-Versuch beim obligatorischen Prüfen des Passworts während der Konfiguration als Hacker-Angriff und unterband ihn. Das wissen wir aus einer entsprechenden Mail von Google (siehe Kasten »Mail von Google« ). Audriga informiert den Anwender nur durch das rote Kreuz anstelle des grünen Häkchens als Zeichen des Misserfolgs beim Prüfen des Passworts.

Mail von Google

… Vor Kurzem hat jemand versucht, sich mit Ihrem Passwort in Ihrem Google-Konto mailto:xxxxxxxx@gmail.com anzumelden. Dieser Nutzer hat dazu eine Anwendung wie einen E-Mail-Client oder ein Mobilgerät verwendet.

Der Anmeldeversuch wurde aufgrund der Möglichkeit unterbunden, dass es sich um einen Hacker handelt, der versucht, auf Ihr Konto zuzugreifen. Bitte lesen Sie die Details zu diesem Anmeldeversuch:

Samstag, 19. Oktober 2013 11:13 Uhr UTC IP-Adresse: 54.247.175.161 (ec2-54-247-175-161.eu-west-1.compute.amazonaws.com.) Standort: unbekannt

Warum genau Google hier einen Hacker vermutet, ist nicht genau nachvollziehbar, aber Anhaltspunkte könnten sein: Die IP-Adresse wurde noch nie für ein Login verwendet und sie gehört auch nicht zu einem ISP, Mobilfunker oder einem bekannten Unternehmensnetz; der Browser ist unbekannt oder der geografische Standort kann nicht ermittelt werden. Andere Provider mögen andere Vorsichtsmaßnahmen treffen und beispielsweise das Datenvolumen begrenzen.

comments powered by Disqus

Artikel der Woche

Setup eines Kubernetes-Clusters mit Kops

Vor allem für Testinstallationen von Kubernetes gibt es einige Lösungen wie Kubeadm und Minikube. Für das Setup eines Kubernetes-Clusters in Cloud-Umgebungen hat sich Kops als Mittel der Wahl bewährt. Wir beschreiben seine Fähigkeiten und geben eine Anleitung für den praktischen Einsatz. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018

Microsite