none
Миграция 10 2 16 (не явная) RRS feed

  • Вопрос

  • Привет.

    Ситуация следующая.

    Готовится миграция пользователей в новый домен (мелкая контора, до 100 юз.).  Основной вопрос по почте.

    Старый домен: x.ru, новый y.com (в старом домене имя домена локальное - x.loc (+в старом домене у почты е. такой адрес, но основной @x.ru))

    Новый, соответственно: y.com (внутр. и внешний, настроен правильно), т.е. снаружи и внутри совпадают, только днс разные (внутр.\внешн.).

    Планируется перенос юзеров со старой почты в новую, _по одному_. Перенос содержимого ящиков из старого в новый - проблем не вызывает.

    Поднято доверие - новому (верхнему\ведущий) домену доверяет старый (нижний\ведомый). Ибо есть основания полагать, что в старом е. троян или что-то типа этого. Явно пока не прописывал, но как адм. везде. на срв. старого домена адм. нового уже е.

    Сейчас соответственно, работает 2 exchange сервера (пока норм.):

    1. старый, 2010, адреса x.ru (основной), x.loc (внутр.), внешние днс и ип слушают и отправляют с адресов домена x.ru

    2. новый, 2016, адреса y.com (основной), x.ru (доп.), внешние днс и ип слушают и отправляют с адресов домена y.com, но можно выбрать при отправке старый адрес ОТ (x.ru)

    Итого.

    1. Старый домен и ech. 10 (OS 2008r2+все обновы на сегодня) пока работают и все там Ок, почту получают-отправляют.

    2. Новый домен готов, юзеры заведены (отличаются от старого по имени, но не почте (нач.имя до @)), есть ech. 16 (OS 2016+все обновы на сегодня), почта работает, получаем-отправляем (можно выбрать с какого домена отправлять, при этом, если выбрать старый "vasa.pupkin@x.ru" и отправить, то письмо "как бы должно доставиться", но адресом доставки\обратной проверки будет домен y.com, т.е. теоретически у некоторых контор может спам фильтр сработать). Это пока мелочь, но как часть вопроса.

    3. Основное. Как бы сделать так, чтоб основным стал новый почтовик для всех? А НЕ после смерти старого, когда всех юзеров переключим?

    Т.е. хочется что:

    а) ввели пользователя (старого из старого домена) в н.домен, ему создалась почта (с новым и старым адресом)

    б) отправлять с нового почтовика он может со старого и нового адреса, но отпр. мыло со старого адр., к нек. адресам оно может дойти не сможет, т.к. отпр. с ип н. домена, кот <> с.домену (x.ru<>y.com), но теоретически должно дойти

    в) ящик между н. и ст. почтовиком - перенести не проблема

    г) как правильно сделать - чтобы:

    г1. почта приходящая на старый домен по его адресу (и группы рассылки!) - падала в новый ящик

    г2. на новый - тоже туда

    г3. отправка была бы со старого адреса с валидным доменом

    г4. т.е. хочется: при переводе юзера в новый домен (до перевода всех и пока оставляем старый exch.10) чтоб почта ему со старого ему лилась уже в н.ящик (н. домен, но без скопления в его старом ящике -в идеале старый ящик кокнуть), отправлять он мог валидные письма через старый, а также новый.

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

    Научите, как правильно сделать?



    • Изменено GuSoft 16 сентября 2019 г. 21:06
    16 сентября 2019 г. 20:52

Ответы

  • 1. Чтобы почта ходила между старым и новым лесом, нужно в каждом лесу изменить в Accepted Domains тип старого почтового домена на Internal Relay и создать Send Connector с адресным пространством SMTP для старого домена и отправкой на сервер Exchange другого леса как на смарт-хост. В таком случае вся почта для старого домена, кроме той, что для направлена в существующие в нем п/я, будет отправляться на другой сервер Exchange.

    2. Имеет смысл в новом лесу сделать дополнительную политику почтовых адресов таким образом, чтобы п/я (именно п/я, в политике есть фильтр по типу получателя) получали основной адрес SMTP из старого домена, а из нового - дополнительный. Тогда для всех перенесенных п/я в качестве адреса отправителя будет использоваться адрес из старого домена.

    3. Чтобы уходящая из нового леса почта с отправителем из старого домена не отвергалась антиспамом, надо исправить запись SPF (она обычно имеет тип TXT) так, чтобы включить в нее и внешний IP нового Exchange. А если выполнить следующий пункт, то новый Exchange можно будет добавить как дополнительный MX в новый домен.

    4. Имеет смысл создать в новом лесу сделать записи пользователей, соответствующих п/я в старом лесу как Mail-enabled user (это такая форма контакта, указывающая, куда отправлять почту, направленную на его адреса) с внешним адресом - адресом пользователя в старом домене. Это можно (и рекомендуется, см. следующий пункт) сделать с помощью стандартного скрипта Exchange Prepare-MoveRequest.ps1 (см. например - https://docs.microsoft.com/en-us/exchange/architecture/mailbox-servers/prep-mailboxes-for-cross-forest-moves-in-powershell?view=exchserver-2019) - для него совсем не требуется доверие между лесами, т.к. в нем можно указать учетные данные для обоих лесов, и он AFAIK может как создавать соотвествующие учетные записи, так и использовать существующие, в т.ч. - перенесенные с помощью ADMT(для работы которой двустороннее доверие тоже не нужно, кстати).

    5. Как именно переносить содержимое п/я - это дело ваше, конечно. Но хочу сообщить, что это можно сделать штатыми средствами: включить в старом Exchange MRS Proxy  (Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory  -MRSProxyEnabled $true ) и использовать запрос на перемещение п/я между лесами (минимальная команда, запускаемая с нового Exchange - примерно такая (всё - в одну строчку):

    New-MailboxMoveRequest -Identity <distiguishedName п/я> -RemoteHostName <FQDN старого Exchange(CAS)> -RemoteLegacy -RemoteCredential (Get-Credential) -RemoteGlobalCatalog <FQDN GC в старом лесу> -TargetDatabase <БД на новом Exchange> -TargetDeliveryDomain <новый почтовый домен>

    Она попросит логин и пароль - введите данные администратора Exchange в старом лесу.  Перенос стандартыми средствами как раз обеспечит вам желаемое - п/я в старом домене будет ликвидирован (заменен на Mail-Enabled user) одновременно с созданием п/я в новом.


    Слава России!


    17 сентября 2019 г. 11:49