Kürzlich bat uns ein Kunde, eine Kopano-Installation mit ~ 250 Postfächern zu Grommunio zu migrieren.

Besonderheiten waren eine sehr individuelle Postfix-Konfiguration, sowie ein Mailvolumen von ~ 1.1TB.

Wir konnten mit dem Kunden eine Migrationsstrategie entwickeln und zuvor die Umstellung in einer Testumgebung durchführen. Der grobe Ablauf war ein Freeze des Quellsystems für ~ 12 Stunden sowie die gesamte Migration aller Postfächer.

Wir konnten die Migrationszeit deutlich reduzieren, indem wir die gesamte Datenbank des Zielsystems, temporär im Arbeitsspeicher vorgehalten haben.

Auf welche Herausforderungen sind wir gestoßen? Was hat uns geholfen?

  • Das Default-Grommunio-System ist ein SUSE LEAP-System mit Besonderheiten bei der Konfiguration. Speziell beim Einsatz von Puppet, gibt es hier keine offiziellen Paketquellen.
  • Das vorhandene LDAP-Schema für Kopano, kann durch Grommunio weiter verwendet werden. Der Kunde nutzt openldap (slapd).
  • Der Betrieb der EWS-Schnittstelle (Outlook) erforderte Anpassungen am vorhandenen Reverse-Proxy (NGINX).
  • Die Postfix-Authentifizierung (SASLAUTHD) ist standardmäßig nicht konfiguriert bei einer Neuinstallation und erfordert manuellen Anpassungen.
  • Die LDAP-Authentifizierung für SMTP-User ggü. LDAP, erfordert angepasste Konfigurationen, aufgrund des Betriebes von postfix in einer chroot.
  • Der Platten-Speicherplatz durch Grommunio hat sich massiv reduziert. (1.1T ./. 300G). Dies liegt an einem sehr effektiven Datenbankschema in Grommunio. Bei der Migration gingen wir hier erst davon aus, dass nicht alle Postfächer migriert wurden 🙂
  • Die LDAP-Synchronisation in das Grommunio-System hat einen Default-Timer von ~ 15 Minuten. Diese Zeiten muss man kennen, wartet man auf die Anlage von neuen Usern.
  • Grommunio nutzt standardmäßig RSPAMD als integrierter spamfilter. Dieser musste deaktiviert werden, da der Kunde bereits einen vorgelagerten Spamfilter besitzt.
  • Grommunio bietet ein zentrales Admin-Interface. Dies ist sehr hilfreich, können darüber an zentraler Stelle auch Dinge wie Abwesenheit von Usern gepflegt werden.

Zusammenfassung & Ausblick:

Alle beschriebenen Probleme konnten entweder mit dem Support geklärt werden, oder wurden durch uns mit dem Kunden neu bewertet und Alternativen gefunden.

Der Kunde hat jetzt wieder ein on-premise Mailsystem mit nativer Outlook-Unterstützung durch die EWS-Schnittstelle.

Planen Sie auch eine Migration, freuen wir uns über Ihre Anfrage.

Categories: BlogNews