Назад | Перейти на главную страницу

Рекомендуемая стратегия миграции с Dovecot / Thunderbird на Exchange / Outlook

Мы перемещаем ~ 60 почтовых ящиков пользователей из установки Postfix / Dovecot / Maildir в Exchange 2007. Мне известно о Пакет Microsoft Transporter Suite, что позволит выполнять массовое преобразование почтовых ящиков из IMAP в Exchange. Однако существует проблема, как очистить неудачный процесс, если возникнет непредвиденная проблема. По-видимому, попытка удалить поврежденный почтовый ящик Exchange для пользователя также приводит к довольно пугающему звуковому диалогу, который подразумевает учетная запись пользователя также будет удалена, а не только сам поврежденный ящик. Несмотря на то, что исходное хранилище электронной почты (в формате Maildir) доступно, нам понадобится возможность удалить рассматриваемые плохие ящики и повторить процесс, поэтому этот метод не является жизнеспособным вариантом.

На данный момент у меня есть серьезные опасения по поводу влияния на пакетный или массовый переход без массивного ручного вмешательства. Мы стараемся избегать посещения 50+ рабочих столов и ручного перемещения по электронной почте с помощью Outlook, или Thunderbird в качестве «шарнира» агента; Хотя это на 100% гарантированно работает, для перемещения более 2,5 миллионов сообщений по одной учетной записи за раз могут потребоваться недели или месяцы.

Поэтому я начал изучать другие инструменты и методы, как с открытым исходным кодом, так и коммерческие.

Первый, который я попробовал, был OfflineIMAP, который, как оказалось, не очень удобен для обмена; тонкий эффект процесса миграции приводит к исчерпанию Именованные свойства биржи из-за того, что для каждого перемещаемого письма создается уникальный заголовок. Доступен патч для этого, который изменяет уникальный заголовок на один общий заголовок с уникальным идентификатором после него, что позволяет избежать проблемы исчерпания. Тем не менее, после применения патча некоторые проблемы все еще остаются. Жалко, правда, как было бы неплохо синхронизировать их.

Что касается коммерческой стороны, я кратко рассмотрел Трансенд Мигратор в пробном режиме. Результаты были неоднозначными, и, похоже, с двоичным файлом поставляется мало документации. Вряд ли это обнадеживает, особенно для того, что конечные пользователи легко заметят, если что-то пойдет не так.

Есть и другие проблемы. Почтовые ящики хранятся как Maildir, но имена ящиков соответствуют ожиданиям Thunderbird (мы пользуемся TBird несколько лет). Многие имена ящиков не совпадают («Отправленные» и «Отправленные», «Корзина или удаленные» и т. Д.), И их необходимо будет эффективно переводить при переносе. Да, мы так сильно балуем наших конечных пользователей - успешная миграция будет состоять в том, чтобы проинформировать их о том, что мы переключаемся на Outlook, и провести для всех небольшой 30-минутный урок, после чего люди впервые откроют свои новые почтовые ящики на базе Exchange.

Кто-то где-то наверняка что-то это работает...

РЕДАКТИРОВАТЬ: продолжение

Сценарий larch, написанный на Ruby, предоставил самое простое решение, хотя и с некоторыми оговорками. Вот сильно сжатая версия того, что происходит:

  1. Получите имя пользователя и пароль пользователя. Сбросьте пароль после перехода.
  2. Подключитесь к ящику пользователя через IMAP и убедитесь, что на INBOX подписана и все сообщения помечены как прочитанные. На стороне Exchange существует проблема, которая может помешать успешному импорту сообщений, если сообщение не прочитано и находится в определенном состоянии ...
  3. Измените карту транспорта постфикса, чтобы она указывала на сервер обмена, в результате чего все новые доставки будут приходить на сервер Exchange вместо текущего почтового сервера.
  4. Использовать larch , чтобы переместить электронное письмо, пропуская корзину пользователя. Нам пришлось капитулировать и пропустить это, потому что были пользователи, превращавшие корзину в личную файловую систему.
  5. Обратите внимание на все сообщения, которые не были перенесены. Перепроверьте и попытайтесь скопировать их еще раз. Это переместит только новые сообщения.
  6. Создайте запись в MySQL, которая инструктирует Dovecot перейти в режим прокси для этого пользователя, и укажет запись на сервере Exchange. Это позволяет существующим клиентам подключаться без изменений, пока мы не будем готовы настроить их установку Outlook.
  7. Повторно подключитесь к папке «Входящие» пользователя и убедитесь, что все сообщения скопированы.

Я сделал много таких миграций на гораздо более крупные системы; 300+ почтовых ящиков, и я мигрировал во многих направлениях: Courier -> Cyrus, Exchange -> Cyrus, Courier -> Exchange и Cyrus -> Exchange ...

Наш любимый инструмент называется imapsync; сценарий Perl с открытым исходным кодом. Он использует фактический протокол IMAP для обработки миграций, что устраняет необходимость иметь дело с базовыми особенностями каждой реализации (форматы aildir, аннотации почтовых ящиков, такие как разделители DONT (.) По сравнению с косой чертой (/)).

IMAPSYNC также безопасен для повторного въезда. Вы можете запускать его несколько раз для одних и тех же учетных записей, и он будет копировать только то, что не было скопировано в первый раз, или любые новые электронные письма, которые могли прибыть.

Обычно мы выгружаем все учетные записи пользователей в сценарий BASH, который, в конце концов, выполняется следующим образом:

./imapsync --host1 mail.pozicom.net --user1 someone@domain --password1 mypassword \
           --host2 localhost --user2 someone@domain --password2 mypassword

Где host1 - это место, куда вы копируете с host2, - это то место, куда вы копируете.

Вы можете получить IMAPSYNC отсюда: http://freshmeat.net/projects/imapsync/

У нас есть огромная почтовая система, и мы регулярно получаем пользователей из других почтовых систем (обычно Notes или Groupwise). Одна общая черта всех этих миграций заключается в том, что часть миграции данных всегда является катастрофой. Всегда есть неразрешимые проблемы, VIP-вопросы в конечном итоге становятся приоритетными, и обычные пользователи страдают. В инструментах миграции есть ошибки, которые никогда не исправляются, потому что никто не выполняет миграцию Notes-> Exchange дважды!

В качестве будущей стратегии мы ищем почтовый ящик с нуля, в котором пользователи будут определять электронную почту, которая должен быть сохраненным. Для вас это просто - оставьте серверы dovecot работающими в течение 6 месяцев, настройте профили Outlook, указывающие на старую систему imap (я считаю, что это можно сделать с помощью сценариев в Outlook 2007) и разрешите пользователям мигрировать в свое время.

Вы обнаружите, что большинству людей действительно не нужно то, что, по их словам, им нужно, и через 6 месяцев любая законная потребность в переносе данных в новую систему будет устранена.

Другой вариант - использовать решение для архивирования почты. Мы должны архивировать всю электронную почту из-за судебных разбирательств, и часто вы можете «перенести» сообщения из старой системы в размещенное решение для архивирования. Ознакомьтесь с услугами Postini и Microsoft Hosted.

Я использовал "imapsync" перед миграцией с сервера IMAP на Scalix (систему, подобную Exchange). Подумайте о rsync для почтовых ящиков IMAP.

Джим.

Лучше всего использовать imap!

Вы МОЖЕТЕ позволить каждому пользователю перемещать сообщения самостоятельно, предоставив ему обе учетные записи в Outlook.

Я выполнил миграцию с Cyrus на Exchange 2003, используя отдельный Linux-сервер с пакетом Debian «uw-mailutils» и этой командой:

mailutil transfer -verbose {imap.xxx.org:143/imap/user=m_xxx}INBOX {exchange.xxxx.org:143/imap/user=m_xxx@exchange.xxxx.org} INBOX

mailutil из проекта UW-IMAP. Его должен содержать каждый дистрибутив Linux.

Когда это не удалось (а это не так), я просто зашел в учетную запись Exchange и удалил "INBOX"

Использовать Транспортер Люкс. Он был написан специально для этого.

Обычно вы импортируете CSV-файл с пользователями и паролями IMAP, и он будет импортировать данные правильно. Вы также можете импортировать пользователей по одному, если боитесь выполнять пакетную обработку. На самом деле испортить импорт довольно сложно.

Не используйте imapsync или любой другой механизм синхронизации на основе IMAP в IMAP. Это вроде работает, но большая часть метаданных будет испорчена, особенно даты. Даже с параметром --syncinternaldates Exchange все равно перезапишет даты на текущую дату, и у вас будет неудачная миграция.