Datamigration von OX SE 6.18 zur OX AE?

[silvio]

Existiert ein Migrationspfad von OX 6 SE zu OX 6 AE.
Wir haben uns nach dem Test der Server Edition auf anraten eines OX Partners entschlossen die Appliance zu verwenden.
Die Migration sollte kein Problem darstellen.
Leider sind alle Dokus zur Datenmigration für OX 5 zu OX6 geschrieben und wir sind uns daher nicht sicher ob dieser Weg gangbar ist.
Ein Export der Kalenderdaten über den Webmailzugang der User, mit anschliessendem Import in die AE ist jedenfalls erfolglos geblieben. Die Daten werden nicht importiert.

Danke für die Hinweise

Silvio

[Martin Heiland]

Hallo Silvio,

wir bieten keinen automatisierte Umstellung einer OXSE auf OXAE an, da es sich um sehr unterschiedliche Produkte mit unterschiedlichen Backends (E-Mail, Authentification, Betriebssystem) für ganz unterschiedliche Anforderungsprofilen handelt. Sollten die OX Versionen identisch sein, wird der Partner sicherlich in der Lage sein die Daten zu übernehmen. Konkret müssen nur die Benutzer, die Datenbankinhalte und der Inhalt des Dateispeichers auf OXAE kopiert werden. E-Mail können mit Tools wie imapsync übernommen werden. Falls der Partner dazu nicht in der Lage ist, kannst du dich gerne mit unserem Vertrieb in Verbindung setzen um einen anderen Partner zu finden der euch behilflich ist.

Gruß
Martin

[silvio]

Hallo Martin,

danke für die Antwort.
Das hatte ich schon vermutet. Nach Aussage unseres Partners stelle die Migration kein Problem dar, leider ist es bei der Aussage geblieben und ich versuche gerade die Daten zu übernehmen.
Die Benutzer habe ich schon migriert bekommen, da wir im Unternehmen ebenfalls Ldap verwenden. Es ginge also "nur" um die Kontakt und Kalenderdaten.
Aus diesem Grund war mein erster Versuch auch die Exportfunktion des Webmail Frontends.

Silvio

[Martin Heiland]

Hi,

was für ein Problem tritt denn beim Import auf? Vielleicht können wir das analysieren und Abhilfe schaffen.

Gruß

[silvio]

Ich habe gerade die Prozedur nocheinmal wiederholt.
Vorgehen:
1. User meldet sich am OX SE Systeme an und exportiert über Erweitert --> Export seinen Kalender als export.ics
2. User meldet sich am OX AE an und nutzt die Importfunktion
Nach dem Speichern erfolgt keine Fehlermeldung, es wurde aber auch keine Kalendereintrag übernommen.
Im Logfile findet sich folgendes:

SCHWERWIEGEND: Should not be possible to find a user by it's alias and then be unable to remove that alias from list
java.lang.IllegalStateException: Should not be possible to find a user by it's alias and then be unable to remove that alias from list
at com.openexchange.data.conversion.ical.ical4j.inter nal.calendar.Participants.parse(Participants.java: 275)
at com.openexchange.data.conversion.ical.ical4j.ICal4 JParser.convertAppointment(ICal4JParser.java:204)
at com.openexchange.data.conversion.ical.ical4j.ICal4 JParser.parseAppointments(ICal4JParser.java:144)
at com.openexchange.groupware.importexport.importers. ExtraneousSeriesMasterRecoveryParser.parseAppointm ents(ExtraneousSeriesMasterRecoveryParser.java:84)
at com.openexchange.groupware.importexport.importers. ICalImporter.importData(ICalImporter.java:249)
at com.openexchange.groupware.importexport.ImporterEx porter.importData(ImporterExporter.java:153)
at com.openexchange.ajax.ImportServlet.doPost(ImportS ervlet.java:164)
at javax.servlet.http.HttpServlet.service(HttpServlet .java:616)
at com.openexchange.ajax.AJAXServlet.service(AJAXServ let.java:386)
at com.openexchange.ajax.SessionServlet.service(Sessi onServlet.java:165)
at javax.servlet.http.HttpServlet.service(HttpServlet .java:689)
at com.openexchange.ajp13.najp.AJPv13RequestHandlerIm pl.doServletService(AJPv13RequestHandlerImpl.java: 504)
at com.openexchange.ajp13.AJPv13Request.response(AJPv 13Request.java:129)
at com.openexchange.ajp13.najp.AJPv13RequestHandlerIm pl.createResponse(AJPv13RequestHandlerImpl.java:31 6)
at com.openexchange.ajp13.najp.AJPv13ConnectionImpl.c reateResponse(AJPv13ConnectionImpl.java:207)
at com.openexchange.ajp13.najp.AJPv13Task.call(AJPv13 Task.java:346)
at java.util.concurrent.FutureTask$Sync.innerRun(Futu reTask.java:269)
at java.util.concurrent.FutureTask.run(FutureTask.jav a:123)
at com.openexchange.threadpool.internal.CustomThreadP oolExecutor$Worker.runTask(CustomThreadPoolExecuto r.java:737)
at com.openexchange.threadpool.internal.CustomThreadP oolExecutor$Worker.run(CustomThreadPoolExecutor.ja va:763)
at java.lang.Thread.run(Thread.java:595)
31.01.2011 13:05:25 com.openexchange.ajp13.najp.AJPv13Task call
SCHWERWIEGEND: Should not be possible to find a user by it's alias and then be unable to remove that alias from list
javax.servlet.ServletException: Should not be possible to find a user by it's alias and then be unable to remove that alias from list
at com.openexchange.ajax.AJAXServlet.service(AJAXServ let.java:391)
at com.openexchange.ajax.SessionServlet.service(Sessi onServlet.java:165)
at javax.servlet.http.HttpServlet.service(HttpServlet .java:689)
at com.openexchange.ajp13.najp.AJPv13RequestHandlerIm pl.doServletService(AJPv13RequestHandlerImpl.java: 504)
at com.openexchange.ajp13.AJPv13Request.response(AJPv 13Request.java:129)
at com.openexchange.ajp13.najp.AJPv13RequestHandlerIm pl.createResponse(AJPv13RequestHandlerImpl.java:31 6)
at com.openexchange.ajp13.najp.AJPv13ConnectionImpl.c reateResponse(AJPv13ConnectionImpl.java:207)
at com.openexchange.ajp13.najp.AJPv13Task.call(AJPv13 Task.java:346)
at java.util.concurrent.FutureTask$Sync.innerRun(Futu reTask.java:269)
at java.util.concurrent.FutureTask.run(FutureTask.jav a:123)
at com.openexchange.threadpool.internal.CustomThreadP oolExecutor$Worker.runTask(CustomThreadPoolExecuto r.java:737)
at com.openexchange.threadpool.internal.CustomThreadP oolExecutor$Worker.run(CustomThreadPoolExecutor.ja va:763)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.IllegalStateException: Should not be possible to find a user by it's alias and then be unable to remove that alias from list
at com.openexchange.data.conversion.ical.ical4j.inter nal.calendar.Participants.parse(Participants.java: 275)
at com.openexchange.data.conversion.ical.ical4j.ICal4 JParser.convertAppointment(ICal4JParser.java:204)
at com.openexchange.data.conversion.ical.ical4j.ICal4 JParser.parseAppointments(ICal4JParser.java:144)
at com.openexchange.groupware.importexport.importers. ExtraneousSeriesMasterRecoveryParser.parseAppointm ents(ExtraneousSeriesMasterRecoveryParser.java:84)
at com.openexchange.groupware.importexport.importers. ICalImporter.importData(ICalImporter.java:249)
at com.openexchange.groupware.importexport.ImporterEx porter.importData(ImporterExporter.java:153)
at com.openexchange.ajax.ImportServlet.doPost(ImportS ervlet.java:164)
at javax.servlet.http.HttpServlet.service(HttpServlet .java:616)
at com.openexchange.ajax.AJAXServlet.service(AJAXServ let.java:386)
... 12 more

Silvio

[Tobias Prinz]

Hallo Silvio.

Das ist mein Bug. Den habe ich am 24.11.2010 erschlagen, hat die Nummer 17634. Der müßte im 6.18.2 Release gefixt sein, vorher gibt es leider diesen Fehler.

Hintergrund: OX-intern wird der local part einer E-Mail Adresse case-insensitive behandelt. Wenn jetzt eine andere Schreibweise kommt, geht das kaputt. Will sagen: tobias.prinz@host.invalid wird nicht auf Tobias.Prinz@host.invalid gemapped. Ich hab noch keinen Fall erlebt, wo das etwas anderes ist, als diese Schreibweisen-Sache.

Da ist dann auch schon die hausgemachte Lösung für das Problem (neben dem üblichen "auf 6.18.2 updaten"): Einfach die Shreibweise der E-Mail-Adresse anpassen (auf die Schreibweise, die in Eurem LDAP steht, vermute ich mal). Ich denke, durchgehende Kleinschreibung müssen klappen.

Allerdings noch eine Anmerkung: Ich persönlich rate zu einem Test, ob der Export und Import via ICAL und VCard in Eurem Fall Sinn macht:

* Bei Serien mit Änderung-Ausnahmen wird es sicherlich Probleme geben, da haben wir noch einen Bug offen. Dass der erst jetzt mal aufgetreten ist, läßt mich aber vermuten, dass diese Funktion eher selten benutzt wird, also könnte es klappen. Falls der Kalenderbestand komplex ist: Ich persönlich würde gucken, ob ich den Kram einfach auf DB-Ebene migrieren kann. Zumindest das Layout hat sich seit bestimmt einem halben Jahr nicht mehr geändert. Ist aber... kompliziert.

* Statt VCard würde ich das OX-CSV probieren - ganz einfach, weil man in VCard nicht alle Felder von OX (oder Outlook) abbilden kann, unser CSV aber natürlich perfekt für OX-Bedürfnisse passt. Alternativ kannst Du auch Publish&Subscribe benutzen, auch da passt (so Du nicht ein hCard-Template benutzt) das Format perfekt.

MfG,
Tobias

[silvio]

Hallo Tobias,

danke für den Hinweis zu den Mailadressen. Ich habe gerade beide Systeme verglichen und die Adressen stimmen überein :-( .
Was noch interessant ist, müssen die IDs identisch sein? Mein Testaccount hat im alten System die ID 4 und im neuen System die ID 14.

Ein Update auf die 6.18.2 ist bei der AE nicht so einfach möglich, dort bewegen wir uns noch in der 6.16 Region. Insofern ......

Da unsere User den OX Server sofort zum testen und arbeiten genutzt haben, handelt es sich auch um einige Daten. Ich denke daher auch das eine Lösung über den Mysql Weg langsam immer wahrscheinlicher wird. Leider habe ich im Wiki bis jetzt noch nichts gefunden was mir den Einstieg in diese Lösung etwas erleichtert.

Silvio

[Martin Heiland]

Die "Migration" über die Datenbank ist zwar technisch möglich, wir raten aber generell davon ab solche Stunts zu machen. Um Daten von A nach B zu bekommen haben wir eine API und div. export/import Funktionen. Meinen Informationen zufolge soll ein Update von OXAE auf 6.18.2 noch im Februar kommen.

Gruß

[Tobias Prinz]

Da hat der Herr Braun natürlich recht. Von Arbeit auf der Datenbank-Ebene raten wir ab - nicht nur aus Selbstschutz, sondern weil es echt kompliziert ist. Da bin ich nur von ausgegangen, weil im ersten Posting "Migration der Datenbankinhalte" steht, was für mich so klang wie der beliebte Fall "einen Dump der DB haben wir noch, den OX aber nicht mehr".

Wenn an der Migration jemand mit auch nur rudimentären Programmierkenntnissen beteiligt ist und der OX noch läuft, ist meine persönliche Empfehlung, das über die HTTP-API zu machen. Da ist kein Zwischenformat drin, bei dem Informationen verloren gehen. Und es ist meine Lieblingsschnittstelle.

Nun zu dem ICal-Problem: Wenn es sich wirklich nicht auf unterschiedliche Schreibweisen zurückführen läßt, dann würde mich ein Bugreport freuen. Das ist dann ein wirklich seltsamer Fall, den ich damals nicht bedacht habe.

MfG,
Tobias

[silvio]

Vielen Dank für die Antworten.
Wir haben uns nach entschlossen die alten Daten nach der Verfügbarkeit von OX AE 6.18.2 zu migrieren und die User jetzt an das "leere" System heranzuführen. Die Migration der Maildaten stellte kein Problem dar, ein Arbeiten ist also möglich.

Bezüglich des ical Exportes werde ich einen Bugreport erstellen.

MfG

Silvio