Scalix zu Exchange

Ich bin derzeit in einem Projekt damit beschäftigt über 12.000 Mailboxen von Scalix (ehemals HP Openmail) zu Exchange zu migrieren. In diesem Artikel berichte ich davon:

Wir hatten uns zuerst diverse IMAP Migrations Tools angeschaut, die wir alle nach einigen Test-Tagen über Bord geworfen haben. Keines dieser Tools arbeitete wirklich zuverlässig, was ich allerdings nicht wirkich den Tools als vielmehr Scalix zuschreibe. Aber diese Erkenntnis brachte uns auch nicht weiter. Klar war, dass es bei dieser Masse an Usern (die auch noch weltweit verteilt sind) keine Big-Bang Migration an einem Wochenende geben kann. Es wird also eine Co-Existence Phase geben. Außerdem – um ganz ehrlich zu sein – habe ich in meiner Zeit als Berater auch mittlerweile genügend “Migrations-Wochenend-Erfahrung” gesammelt, als dass da noch ein paar weitere hinzu kommen müssten.

Das Verschieben der Mailbox würde einige Schritte mit sich bringen, die man eigentlich alle zeitlich mit dem User abstimmen müsste. Da dies viel zu kompliziert erschien, kam die Idee auf den User die Migration selbst erledigen zu lassen. Natürlich wollten wir den User dabei nicht mit den Outlook-Bordmitteln (Export/Import Pst) alleine lassen und außerdem musste auch auf Server Seite einiges umgestellt werden. Also haben wir ein Tool entwickelt, dass zum einen die Datenmigration auf Clientseite durchführt und zum anderen (per Webservice) auf Server Seite z.B. die Routinginformationen umbiegt.

Der Webservice führt auf einem Server entweder Scalix-Shell Befehle (z.B. Weiterleitung in der Mailbox einrichten, Routing umstellen, OOF Text Abfrage, …) oder Exchange Powershell Befehle (Erstellen der Mailbox,  OOF Text setzen, …) aus.

Co-Existence

Was das Routing angeht, wird ja in den meisten Projekten die grundlegende Struktur beibehalten. Man fügt Exchange hinzu und leitet von Scalix einfach alles weiter was der nicht kennt. Exchange selbst sagt man auch, dass es nicht “authoritative” für die Domain ist und erstellt einen SMTP Connector nach Scalix.

Scalix arbeitet mit einer eigenen Schema Erweiterung. Die relevanten Email – Adressen stehen zum Beispiel in ScalixEmailAddresses. “ProxyAddresses”, “TargetAddress” und “Mail” interessiert Scalix nicht die Bohne. User die also nach Exchange Verschoben werden sehen erstmal nur sich selbst, aber das will man ja nicht (Nobody is an Island). Deshalb haben wir ein Script gebaut, dass
durch alle relevanten AD User durchgeht und diese mit den Adressen aus “ScalixEmailAddresses” mail-enabled (nicht Mailbox-Enabled). Dabei wird die TargetAddress, die Primary SMTP und ShowInAddressbook gesetzt. Damit tauchen alles Scalix User im Exchange Addressbook auf, und mails an sie sind route-bar.

Fehlt nur noch eine “Kleinigkeit”: Ich hatte erwähnt, dass in den Scalix-Mailboxen bei der Migration (Tool) einfach eine Weiterleitung eingerichtet wird. Diese geht an eine Subdomain und wird dann so an Exchange weitergeleitet (Exchange User müssen natürlich diese Subdomain als zusätzliche SMTP bekommen). Das funktioniert für neue wie für alte Mails. Auf Exchange Seite sieht das anders aus. Neue Emails werden zwar über die TargetAddress an Scalix zurück geliefert – aber ein Reply auf eine Alte Mail (aus Zeiten in denen der User noch selbst auf Scalix war) landen im Nirvana.

Warum? Scalix arbeitet intern mit einem OPENMAIL format (ähnlich den X.400 Adressen). Die alten Mails in Outlook haben nur diese als Absender gespeichert (man kennt das aus Exchange 2003 Migrationszeiten). Deshalb muss unser Script dafür sorgen, dass die User alle auch Ihre alte OPENMAIL Adresse als zusätzliche SMTP bekommen. Dann klappen die Replys auch in alle Richtungen.

Migration

Der User wird im Vorfeld per EMail über die anstehende Migration informiert und ihm wird erklärt, dass er diese selbst durchführen kann. Sobald er freigeschaltet ist (wir wollen ja nicht alle gleichzeitig auf unsere Server loslassen ) kann er das sogenannte CMT (Client Migration Tool) starten und sich selbst per Benutzeroberfläche mit wenigen Click migrieren. Dabei passiert im Hintergrund folgendes:

1. User (Outlook) Sprache wird detected
2. CMT holt sich die alten Scalix Attribute und erstellt (über Powershellscripts und Webservice) neue Mailboxen (vorher hatten wir ja nur Mailenabled User)
3. CMT checkt ob der User Out-Of-Office ist – wenn ja wird es auf Exchange per Powershell gesetzt
4. Checkt ob es Forwards auf der Scalix Mailbox gab – wenn ja – wird es auf Exchange per Powershell gesetzt
5. CMT ändert per Webservice und Scalix Scripten das Externe Routing – direkt auf die Exchange Server
6. CMT triggert auf Serverseite ein Backup der Scalix Mailbox
7. CMT fügt ein neues Outlook Profil auf dem Client hinzu und fängt an alle Daten zu verschieben
8. CMT löscht das Scalix Outlook Profil

Das ganze erfordert einen sehr hohen Planungsaufwand. Es muss einiges programmiert, gescripted und vor allem getestet werden. Aber all das kann völlig ohne Zeitdruck geschehen. Solche Migrationen sind viel berechenbarer und stressfreier – außerdem erlauben sie mehr freie Wochenenden - in diesem Sinne: Have a nice one !