2 getrennte Mailstore zusammenführen - Erfahrungswerte gesucht
Hallo,
ich habe hier einen Kunden der, durch die Zusammenführung zweier Firmen aktuell zwei ADs hat und für jedes AD einen eigenen Mailstore-Server.
AD1 hat Exchange onpremise (Mailstore ca. 800 GB)
AD2 hat Exchange bei Busymouse ohne AD-Anbindung + viele Postfächer von AD1 einzeln eingebunden. (Mailstore ca. 1.4 TB)
Einige Mitarbeiter arbeiten für beide Firmen und haben von beiden Postfächer.
Wie bekomme ich die ca. 60 Archive nun am schlausten von AD1 zu AD2?
Hat das schon mal Jemand gemacht und hat Erfahrugnswerte?
A) Archive aushängen bei AD1 und bei AD2 einhängen.
Klingt einfach, aber funktioniert das auch mit bestehenden Archiven (Mustermann AD1 und Mustermann AD2)?
Dabei geht natürlich die Deduplizierung von diese doppelten Postfächern hops. Vermutlich wäre Mailstore dann 400 GB größer als notwendig.
B) Export als PST und Import.
Vermutlich unkritischer, aber viel aufwendiger.
Bleiben dabei Informationen erhalten wie z.B. wann archiviert? Vermutlich ja nicht.
C) Export als EML/MSG und Import.
Wie PST aber ohne dass man Outlook als Konverter braucht.
Schön wäre ja ein Mailstore eigenen transferformat oder ein Importer für Datendateien.
Danke
Stefan
ich habe hier einen Kunden der, durch die Zusammenführung zweier Firmen aktuell zwei ADs hat und für jedes AD einen eigenen Mailstore-Server.
AD1 hat Exchange onpremise (Mailstore ca. 800 GB)
AD2 hat Exchange bei Busymouse ohne AD-Anbindung + viele Postfächer von AD1 einzeln eingebunden. (Mailstore ca. 1.4 TB)
Einige Mitarbeiter arbeiten für beide Firmen und haben von beiden Postfächer.
Wie bekomme ich die ca. 60 Archive nun am schlausten von AD1 zu AD2?
Hat das schon mal Jemand gemacht und hat Erfahrugnswerte?
A) Archive aushängen bei AD1 und bei AD2 einhängen.
Klingt einfach, aber funktioniert das auch mit bestehenden Archiven (Mustermann AD1 und Mustermann AD2)?
Dabei geht natürlich die Deduplizierung von diese doppelten Postfächern hops. Vermutlich wäre Mailstore dann 400 GB größer als notwendig.
B) Export als PST und Import.
Vermutlich unkritischer, aber viel aufwendiger.
Bleiben dabei Informationen erhalten wie z.B. wann archiviert? Vermutlich ja nicht.
C) Export als EML/MSG und Import.
Wie PST aber ohne dass man Outlook als Konverter braucht.
Schön wäre ja ein Mailstore eigenen transferformat oder ein Importer für Datendateien.
Danke
Stefan
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 41658103992
Url: https://administrator.de/forum/2-getrennte-mailstore-zusammenfuehren-erfahrungswerte-gesucht-41658103992.html
Ausgedruckt am: 29.03.2025 um 11:03 Uhr
12 Kommentare
Neuester Kommentar
Hallo,
Gruß,
Peter
Zitat von @StefanKittel:
Schön wäre ja ein Mailstore eigenen transferformat oder ein Importer für Datendateien.
Der Hersteller sollte wissen ob der soetwas hat. Mal Anrufen.Schön wäre ja ein Mailstore eigenen transferformat oder ein Importer für Datendateien.
Gruß,
Peter
Ich muss bald noch migrieren (wegen neuem Exchange) und wollte von GFI zu Mailstore wechseln. In dem Zusammenhang habe ich ein paar Antworten von Mailstore bekommen die interessant sein könnten:
Das mit dem IMAP werde ich nicht machen, ich werde alles als einzelne EML-Dateien exportieren. Aber das mit der IMAP Verbindung geht eventuell auch von Mailstore zu Mailstore?
Bei einzelnen Dateien gibt es noch die Besonderheit das einige E-Mails mehrfach exportiert werden da mehreren internen Postfächern zugeordnet. Das soll aber kein Problem sein und auf MIME-Ebene dedupliziert werden.
(1) Migration GFI zu MailStore
Sie können entweder direkt über eine IMAP-Verbindung auf GFI zugreifen: https://manuals.gfi.com/de/mar14admin/content/administrator/topics/configuration/configuringimap.htm
Im MailStore Server müsste dann für jeden Benutzer ein Einzelpostfach-Profil eingerichtet werden bzw. den Abruf per Stapelarchivierung realisieren:
https://help.mailstore.com/de/server/Serverpostf%C3%A4cher_archivieren
https://help.mailstore.com/de/server/Stapelarchivierung_von_IMAP-Postf%C3%A4chern#Mehrere_IMAP-Postf.C3.A4cher_.28CSV-Datei.29
Der andere Weg ist, alle E-Mails aus GFI Archiver ( https://manuals.gfi.com/de/mar14admin/content/administrator/topics/importexport/exportemailsfromarchivestores.htm ) im EML oder PST-Format zu exportieren und mit MailStore zu archivieren ( https://help.mailstore.com/de/server/Massenimport_von_E-Mail-Dateien ).
Bei einzelnen Dateien gibt es noch die Besonderheit das einige E-Mails mehrfach exportiert werden da mehreren internen Postfächern zugeordnet. Das soll aber kein Problem sein und auf MIME-Ebene dedupliziert werden.
Hallo
Wir haben solche Migrationen, und ähnliche schon ein paar mal gemacht. Es gibt diverse Möglichkeiten.
B) und C) ist nicht gut, das verändert die Mails.
A) ist theoretisch möglich, wenn beide Versionen exakt gleich sind und die Schlüssel vorhanden sind. Man endet aber auch mit 2 logischen Archivspeichern (Domänen) wenn Namensunterschiede da sind und muss für manche Accounts statische Passworte setzen, weil ja der Domain Lookup weg ist. Auch Deduplizierung geht nicht richtig über verschiedene Domänen. Und User suchen entweder in einer Domäne, oder der anderen.
Lange Rede, wenig Sinn. Wir waren mit Anbietern konfrontiert, welche die Speicher nicht rausgeben wollten, oder die Schlüssel, dann war der Anbieter auf einem anderen Kontinent, oder der Versand einer HDD mit Daten wurde abgelehnt etc.
Wie haben wir es gemacht? Wir haben im Testlab immer eine gleichlautende Exchange Domäne hochgezogen (wie die Hauptdomäne), oder eine Kerio Instanz oder Mdaemon etc. Dann haben wir den Anbieter gebeten/gezwungen, den imap Server zu aktivieren und für die Migration im Mailstore statische Passworte zu setzen. So hatte der nur einen Port offen und musste weiter nix machen.
Dann mit Transend (andere Tools gehen natürlich auch) alles in das Testexchange importieren. Läuft halt ewig, aber automatisch. Danach haben wir im Hauptmailstore für den Zeitraum des Imports das eigentliche Profil deaktiviert, und vom Testexchange jahresweise in die Archive der letzten 10 Jahre dazu importiert. Durch die gleichlautende Domäne wurde sofort die Deduplizierung durchgeführt und alles war am richtigen Platz und im richtigen Archivspeicher. Aufwändig aber eine saubere, universelle Lösung.
MfG,
MacLeod
Wir haben solche Migrationen, und ähnliche schon ein paar mal gemacht. Es gibt diverse Möglichkeiten.
B) und C) ist nicht gut, das verändert die Mails.
A) ist theoretisch möglich, wenn beide Versionen exakt gleich sind und die Schlüssel vorhanden sind. Man endet aber auch mit 2 logischen Archivspeichern (Domänen) wenn Namensunterschiede da sind und muss für manche Accounts statische Passworte setzen, weil ja der Domain Lookup weg ist. Auch Deduplizierung geht nicht richtig über verschiedene Domänen. Und User suchen entweder in einer Domäne, oder der anderen.
Lange Rede, wenig Sinn. Wir waren mit Anbietern konfrontiert, welche die Speicher nicht rausgeben wollten, oder die Schlüssel, dann war der Anbieter auf einem anderen Kontinent, oder der Versand einer HDD mit Daten wurde abgelehnt etc.
Wie haben wir es gemacht? Wir haben im Testlab immer eine gleichlautende Exchange Domäne hochgezogen (wie die Hauptdomäne), oder eine Kerio Instanz oder Mdaemon etc. Dann haben wir den Anbieter gebeten/gezwungen, den imap Server zu aktivieren und für die Migration im Mailstore statische Passworte zu setzen. So hatte der nur einen Port offen und musste weiter nix machen.
Dann mit Transend (andere Tools gehen natürlich auch) alles in das Testexchange importieren. Läuft halt ewig, aber automatisch. Danach haben wir im Hauptmailstore für den Zeitraum des Imports das eigentliche Profil deaktiviert, und vom Testexchange jahresweise in die Archive der letzten 10 Jahre dazu importiert. Durch die gleichlautende Domäne wurde sofort die Deduplizierung durchgeführt und alles war am richtigen Platz und im richtigen Archivspeicher. Aufwändig aber eine saubere, universelle Lösung.
MfG,
MacLeod
Hallo
Kann man so machen, wenn man physischen Zugriff auf alles hat. Hat bei uns in der Realität nur schlecht bis gar nicht funktioniert, weil sowohl Export als auch Import durch die irre Filemenge ewig gedauert hat. Und gerade der import hat häufig abgebrochen wegen Speicherproblemen Python. Mussten diverse Neustarts rein weil die Migrationsmaschine stehen blieb. Immer wieder neu aufsetzen. Anders sind es reine Datenbankzugriffe und es läuft sehr schnell.
Erfahrungswerte von uns. Bitte berichte weiter, wie es funktioniert hat .
MfG,
MacLeod
Kann man so machen, wenn man physischen Zugriff auf alles hat. Hat bei uns in der Realität nur schlecht bis gar nicht funktioniert, weil sowohl Export als auch Import durch die irre Filemenge ewig gedauert hat. Und gerade der import hat häufig abgebrochen wegen Speicherproblemen Python. Mussten diverse Neustarts rein weil die Migrationsmaschine stehen blieb. Immer wieder neu aufsetzen. Anders sind es reine Datenbankzugriffe und es läuft sehr schnell.
Erfahrungswerte von uns. Bitte berichte weiter, wie es funktioniert hat .
MfG,
MacLeod
Hallo Stefan,
Auch uns sind die Details von Mailstore bestens bekannt, wir betreiben u.a. die MSP Edition.
Du unterliegst hier einem Irrtum. Der signierte Export bestätigt nur den unveränderten Export aus dem Archiv zur Vorlage bei Streitfällen (die wir sowohl arbeitsrechlich als auch seit kurzem finanzrechtlich begleitet haben). Mailstore per se ist zertifiziert, aber wenn Du Rechtssicherheit möchtest musst Du beide Archive komplett als Instanzen erhalten. Die Signatur ist nicht gleichzusetzen einer DKIM, also der Unveränderbarkeit seit Versand. Sobald Du ein Archiv auflöst durch Export verlässt Du den Pfad der Tugend, äh Rechtssicherheit, denn alle logs und Audits der Spenderinstanz gehen verloren. Wie dir vielleicht schon aufgefallen ist, gibt es bei Mailstore keinen rechtssicheren Import. Kann es ja auch nicht geben, denn wie sollte Mailstore die Qualität und Vollständigkeit einer losen Sammlung von Quelldateien garantieren, auch wenn diese von einer anderen Instanz gestempelt wurden.
Es bleibt spannend. Ob der signierte Export den langwierigen Prozess rechtfertigt gegenüber einem streamen in einen temporären Mailserver bleibt abzuwarten. Bitte berichte über Umsatz pro Stunde. So etwas sind wertvolle Erfahrungswerte.
MfG, MacLeod
(Erfahrungswert: Schiesst sich übrigens ein gegenerischer Anwalt auf die Thematik ein, wird prinzipiell alles angezweifelt. Hat man nicht seinen eigenen MX im Haus und liegt kein DKIM vor vom Versender, dann wird die Ablaufkette über Mailprovider, Popcon Import, Exchange in Frage gestellt und Manipulation unterstellt. Es ist nahezu unmöglich hier den Beweis einer Nicht-Manipulation zu erbringen.)
Auch uns sind die Details von Mailstore bestens bekannt, wir betreiben u.a. die MSP Edition.
Du unterliegst hier einem Irrtum. Der signierte Export bestätigt nur den unveränderten Export aus dem Archiv zur Vorlage bei Streitfällen (die wir sowohl arbeitsrechlich als auch seit kurzem finanzrechtlich begleitet haben). Mailstore per se ist zertifiziert, aber wenn Du Rechtssicherheit möchtest musst Du beide Archive komplett als Instanzen erhalten. Die Signatur ist nicht gleichzusetzen einer DKIM, also der Unveränderbarkeit seit Versand. Sobald Du ein Archiv auflöst durch Export verlässt Du den Pfad der Tugend, äh Rechtssicherheit, denn alle logs und Audits der Spenderinstanz gehen verloren. Wie dir vielleicht schon aufgefallen ist, gibt es bei Mailstore keinen rechtssicheren Import. Kann es ja auch nicht geben, denn wie sollte Mailstore die Qualität und Vollständigkeit einer losen Sammlung von Quelldateien garantieren, auch wenn diese von einer anderen Instanz gestempelt wurden.
Es bleibt spannend. Ob der signierte Export den langwierigen Prozess rechtfertigt gegenüber einem streamen in einen temporären Mailserver bleibt abzuwarten. Bitte berichte über Umsatz pro Stunde. So etwas sind wertvolle Erfahrungswerte.
MfG, MacLeod
(Erfahrungswert: Schiesst sich übrigens ein gegenerischer Anwalt auf die Thematik ein, wird prinzipiell alles angezweifelt. Hat man nicht seinen eigenen MX im Haus und liegt kein DKIM vor vom Versender, dann wird die Ablaufkette über Mailprovider, Popcon Import, Exchange in Frage gestellt und Manipulation unterstellt. Es ist nahezu unmöglich hier den Beweis einer Nicht-Manipulation zu erbringen.)