Traktorist, я не до конца понимаю ваше упорное нежелание использовать штатные методы. Если выполнить миграцию по всем правилам, т.е. так, как это описано в документации - перерыв в сервисе можно реально свести к нулю. Т.е. в старом лесу уйти на 2003, перевестись в Native Mode, проапгрейдить АД до уровня WS 2003 R2, а потом ШТАТНО, при помощи Active Directory Migration Tool провести миграцию ВСЕХ ресурсов, включая учетные записи пользователей с паролями, рабочие станции пользователей, их профили, документы, почтовые ящики и всякие сервисы, в новый домен. В идеале пользователи даже не заметят, что что-то изменилось. Пришли на работу - а они уже в новом домене.
Ну если у вашей позиции есть железные аргументы (которые я, честно говоря, не прочь услышать) вы столкнетесь с главной проблемой - единым адресным пространством. Т.е. на старом сервере
user@domain.com, на новом
user2@domain.com. Вся фишка в @domain.com. Предлагаю делать следующим образом:
1. В интернет вы выставляете новый сервер, через него будет происходить отправка и приём почты. Записи в DNS менять не надо, достаточно подменить внешний адрес - забрать его у старого сервера и отдать новому.
2. Отключить фильтрацию по существующим получателям.
3. Настроить перенаправление почты для несуществующих получателей на сервер партнер.
4. Настроить отправку во внешний мир с Exchange 5.5 через Exchange 2010, прописав его в качестве почтового релея (предварительно разрешив релей на сервере Exchange 2010)
Ну и собственно все. Не забывайте после переноса данных пользователя в новый ящик удалять его на старом.
Логика работы в этом случае будет такой:
1. user1 с ящиком на 5.5 отправляет почту для user2, с ящиком на 5.5. В этом случае логика не меняется, будет такой же, как и раньше.
2. user1 отправляет почту для user3, с ящиком на 2010, в этом случае сервер 5.5 пытается искать ящик у себя (@domain.com - это же обслуживаемый домен, т.е. сервер считает, что это внутри его организации), не находит, и по правилу для несуществующих адресов отправляет ее на 2010.
3. Обратный сценарий, когда user3 отправляет почту для user1 выглядит ровным счетом так же, только в обратной последовательности.
4. user 1 отправляет почту для user4, ящик которого на внешнем сервере, ну например на mail.ru - сервер 5.5, понимает, что эта почта вне его организации и толкает ее во внешний коннектор, у которого релеем прописан E2010, а тот в свою очередь релеит во внешний мир.
5. User4 отправляет почту для user1 и user3. Для user 3 все просто: Е2010 принимает почту, находит ящик у себя и все пучком. Для user1 он ящик не находит, но по правилу для несуществующих пользователей - отправляет ее на Е5.5, где и находится этот ящик.
Минус этого сценария:
- нет общей адресной книги. Можно наверное ее сделать - но это надо думать и пробовать отдельно и долго.
- Вся почта на несуществующие адреса будет приниматься, и если пользователей реально нет - сообщения будут висеть в очередях на доставку до истечения времени жизни сообщения. Это лишняя нагрузка и траффик, придется с этим мириться.
- ну и вообще сценарий неблагодатный... Это мое личное мнение
Документации в открытом доступе нет, в архивах тоже нет. У вас чудная способность искать то, чего нет
Попробуйте поискать по торрентам, вдруг вам опять повезет. Я нашел у своих буржуйских коллег Help File и архив TechNet, но пока еще не скачал. Если напомните ближе к следующему понедельнику - попробую поделиться
Правда об этом лучше писать в почту (есть в профиле).
