none
Перенос почтовых ящиков с сервера на сервер между доменами по одному пользователю RRS feed

  • Вопрос

  •   Добрый день всем.

      Имеется такая ситуация:

      Имеется домен AD oldcorp.local, с AD и MS Exchange 2010, к которому подключено порядка 500 пользователей, а в качестве почтового домена настроен newcorp.com. Работает Exchange весьма неуверенно, так как он падал, поднимался из бэкапов, переносился между виртуалками и вообще, жизненный путь его был тернист и извилист.

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

      Отсюда созрел план:

    - развернуть новый лес и домен hq.newcorp.com

    - настроить доверительные отношения между старым и новым доменом

    - настроить Exchange 2016 (также с почтовым доменом newcorp.com), адекватно сконфигурированный, без упоминания oldcorp и всяческих local'ов

    - потихоньку мигрировать пользователей

      Почему потихоньку - потому как из 500 сотрудников 350 находятся в филиалах, до которых физически не добраться и в которых нет людей, способных выполнить задачи сложнее чем перезагрузка или предоставление тимвьювера. В центральном офисе (порядка 150 человек) примерно на половине пользовательских компов групповые политики не отрабатывают, об автоматизированной миграции из домена в домен речь пока не идёт.

      А теперь собственно вопрос - я никогда не сталкивался с двумя Exchange серверами в одном namespace (не могу подобрать русский аналог), подскажите, пожалуйста, в какую сторону копать, если я хочу переносить пользователей из  старого домена в новый (со сменой используемого сервера Exchange) по одному, при этом работа почтовой системы вцелом не должна останавливаться (точнее, простои возможны на выходных), а сами пользователи не должны потерять свои почтовые базы (из плюсов всего этого правала - календари работают криво, поэтому ими никто не пользуется).

      Общеобразовательные статьи я на эту тему уже почитал, база мне известна и понятна. Тестовую среду пока не разворачивал, так как не могу сложить для себя как-раз логику процесса. Если ткнёте в ссылку на аналогичный прожэкт или дадите общий план хотя бы с минимальной конкретикой - буду очень благодарен. Если мой подход неверен в принципе, то за конструктивную критику быду благодарен не меньше.

      Заранее спасибо.

    17 июня 2018 г. 13:09

Ответы

  • На тему "сосуществования", логика работы та же самая, как если вместе с Exchange, для обслуживания того же домена, используется почтовая система на другой платформе. То есть, сообщения для отсутствующих (в конкретной системе) адресов/ящиков, пересылаются на указанный смартхост. Сейчас, в Exchange, для этих целей используется обслуживаемый домен Internal Relay.

    То есть, когда новый Exchange готов для обслуживания пользователей (внешние коммуникации для него лучше настраивать позже), на старом указываете для своего внутреннего домена тип Internal Relay и создаёте коннектор отправки для этого домена на "смартхост" (новый Exchange). На новом делаете то же самое в обратную сторону, если хотите, чтобы внутренняя почта от уже живущих на новом сервере пользователей доходила до ещё живущих на старом.

    И начинаете миграцию (эккаунтов и перенос ящиков). Когда большая часть окажется на новом Exchange (в новом домене/лесу), можете перенастроить внешние коммуникации - отправку и приём почты новой системой.

    Если на старом Exchange была сделана настройка отказа в приёме сообщений на несуществующие ящики (вместо отправки NDR), возможно, её понадобится явно отключить (не помню).

    По завершению удаляете лишний коннектор и делаете домен Authoritative.

    На время совместной работы, сообщения на реально не существующие адреса своего домена, будут умирать, без NDR, по превышению допустимого количества узлов пересылки, соответствующие сообщения об ошибках будут в логах. На "недолгое время миграции", таки можно проигнорировать такое нарушение RFC :).


    S.A.

    • Помечено в качестве ответа Nick Sverdel 18 июня 2018 г. 14:04
    17 июня 2018 г. 15:54

Все ответы

  • На тему "сосуществования", логика работы та же самая, как если вместе с Exchange, для обслуживания того же домена, используется почтовая система на другой платформе. То есть, сообщения для отсутствующих (в конкретной системе) адресов/ящиков, пересылаются на указанный смартхост. Сейчас, в Exchange, для этих целей используется обслуживаемый домен Internal Relay.

    То есть, когда новый Exchange готов для обслуживания пользователей (внешние коммуникации для него лучше настраивать позже), на старом указываете для своего внутреннего домена тип Internal Relay и создаёте коннектор отправки для этого домена на "смартхост" (новый Exchange). На новом делаете то же самое в обратную сторону, если хотите, чтобы внутренняя почта от уже живущих на новом сервере пользователей доходила до ещё живущих на старом.

    И начинаете миграцию (эккаунтов и перенос ящиков). Когда большая часть окажется на новом Exchange (в новом домене/лесу), можете перенастроить внешние коммуникации - отправку и приём почты новой системой.

    Если на старом Exchange была сделана настройка отказа в приёме сообщений на несуществующие ящики (вместо отправки NDR), возможно, её понадобится явно отключить (не помню).

    По завершению удаляете лишний коннектор и делаете домен Authoritative.

    На время совместной работы, сообщения на реально не существующие адреса своего домена, будут умирать, без NDR, по превышению допустимого количества узлов пересылки, соответствующие сообщения об ошибках будут в логах. На "недолгое время миграции", таки можно проигнорировать такое нарушение RFC :).


    S.A.

    • Помечено в качестве ответа Nick Sverdel 18 июня 2018 г. 14:04
    17 июня 2018 г. 15:54
  • Привет.

    У вас будут проблемы. :)

    Перед миграцией cross-forest, в лесу где у вас стоит Exchange 2010, рекомендую провести обновление до Exchange 2016 а потом мигрировать.

    ЗЫ. Я думаю, что вам делать нечего и вы решили оторвать у танка бышню со своей cross forest миграцией.

    ЗЫ. Подумаешь плитики не применяются, в чем проблема пофиксить. Если есть лицензии на Exchange 2016, то обновите, а потом посмотрите на cross-forest. 


    MCITP, MCSE. Regards, Oleg

    18 июня 2018 г. 15:47
    Модератор